- Elasticsearch Guide: other versions:
- What is Elasticsearch?
- What’s new in 8.10
- Set up Elasticsearch
- Installing Elasticsearch
- Run Elasticsearch locally
- Configuring Elasticsearch
- Important Elasticsearch configuration
- Secure settings
- Auditing settings
- Circuit breaker settings
- Cluster-level shard allocation and routing settings
- Miscellaneous cluster settings
- Cross-cluster replication settings
- Discovery and cluster formation settings
- Field data cache settings
- Health Diagnostic settings
- Index lifecycle management settings
- Index management settings
- Index recovery settings
- Indexing buffer settings
- License settings
- Local gateway settings
- Logging
- Machine learning settings
- Monitoring settings
- Node
- Networking
- Node query cache settings
- Search settings
- Security settings
- Shard request cache settings
- Snapshot and restore settings
- Transforms settings
- Thread pools
- Watcher settings
- Advanced configuration
- Important system configuration
- Bootstrap Checks
- Heap size check
- File descriptor check
- Memory lock check
- Maximum number of threads check
- Max file size check
- Maximum size virtual memory check
- Maximum map count check
- Client JVM check
- Use serial collector check
- System call filter check
- OnError and OnOutOfMemoryError checks
- Early-access check
- All permission check
- Discovery configuration check
- Bootstrap Checks for X-Pack
- Starting Elasticsearch
- Stopping Elasticsearch
- Discovery and cluster formation
- Add and remove nodes in your cluster
- Full-cluster restart and rolling restart
- Remote clusters
- Plugins
- Upgrade Elasticsearch
- Index modules
- Mapping
- Text analysis
- Overview
- Concepts
- Configure text analysis
- Built-in analyzer reference
- Tokenizer reference
- Token filter reference
- Apostrophe
- ASCII folding
- CJK bigram
- CJK width
- Classic
- Common grams
- Conditional
- Decimal digit
- Delimited payload
- Dictionary decompounder
- Edge n-gram
- Elision
- Fingerprint
- Flatten graph
- Hunspell
- Hyphenation decompounder
- Keep types
- Keep words
- Keyword marker
- Keyword repeat
- KStem
- Length
- Limit token count
- Lowercase
- MinHash
- Multiplexer
- N-gram
- Normalization
- Pattern capture
- Pattern replace
- Phonetic
- Porter stem
- Predicate script
- Remove duplicates
- Reverse
- Shingle
- Snowball
- Stemmer
- Stemmer override
- Stop
- Synonym
- Synonym graph
- Trim
- Truncate
- Unique
- Uppercase
- Word delimiter
- Word delimiter graph
- Character filters reference
- Normalizers
- Index templates
- Data streams
- Ingest pipelines
- Example: Parse logs
- Enrich your data
- Processor reference
- Append
- Attachment
- Bytes
- Circle
- Community ID
- Convert
- CSV
- Date
- Date index name
- Dissect
- Dot expander
- Drop
- Enrich
- Fail
- Fingerprint
- Foreach
- Geo-grid
- GeoIP
- Grok
- Gsub
- HTML strip
- Inference
- Join
- JSON
- KV
- Lowercase
- Network direction
- Pipeline
- Redact
- Registered domain
- Remove
- Rename
- Reroute
- Script
- Set
- Set security user
- Sort
- Split
- Trim
- Uppercase
- URL decode
- URI parts
- User agent
- Aliases
- Search your data
- Collapse search results
- Filter search results
- Highlighting
- Long-running searches
- Near real-time search
- Paginate search results
- Retrieve inner hits
- Retrieve selected fields
- Search across clusters
- Search multiple data streams and indices
- Search shard routing
- Search templates
- Search with synonyms
- Sort search results
- kNN search
- Semantic search
- Searching with query rules
- Query DSL
- Aggregations
- Bucket aggregations
- Adjacency matrix
- Auto-interval date histogram
- Categorize text
- Children
- Composite
- Date histogram
- Date range
- Diversified sampler
- Filter
- Filters
- Frequent item sets
- Geo-distance
- Geohash grid
- Geohex grid
- Geotile grid
- Global
- Histogram
- IP prefix
- IP range
- Missing
- Multi Terms
- Nested
- Parent
- Random sampler
- Range
- Rare terms
- Reverse nested
- Sampler
- Significant terms
- Significant text
- Terms
- Time series
- Variable width histogram
- Subtleties of bucketing range fields
- Metrics aggregations
- Pipeline aggregations
- Average bucket
- Bucket script
- Bucket count K-S test
- Bucket correlation
- Bucket selector
- Bucket sort
- Change point
- Cumulative cardinality
- Cumulative sum
- Derivative
- Extended stats bucket
- Inference bucket
- Max bucket
- Min bucket
- Moving function
- Moving percentiles
- Normalize
- Percentiles bucket
- Serial differencing
- Stats bucket
- Sum bucket
- Bucket aggregations
- Geospatial analysis
- EQL
- SQL
- Overview
- Getting Started with SQL
- Conventions and Terminology
- Security
- SQL REST API
- SQL Translate API
- SQL CLI
- SQL JDBC
- SQL ODBC
- SQL Client Applications
- SQL Language
- Functions and Operators
- Comparison Operators
- Logical Operators
- Math Operators
- Cast Operators
- LIKE and RLIKE Operators
- Aggregate Functions
- Grouping Functions
- Date/Time and Interval Functions and Operators
- Full-Text Search Functions
- Mathematical Functions
- String Functions
- Type Conversion Functions
- Geo Functions
- Conditional Functions And Expressions
- System Functions
- Reserved keywords
- SQL Limitations
- Scripting
- Data management
- ILM: Manage the index lifecycle
- Tutorial: Customize built-in policies
- Tutorial: Automate rollover
- Index management in Kibana
- Overview
- Concepts
- Index lifecycle actions
- Configure a lifecycle policy
- Migrate index allocation filters to node roles
- Troubleshooting index lifecycle management errors
- Start and stop index lifecycle management
- Manage existing indices
- Skip rollover
- Restore a managed data stream or index
- Data tiers
- Autoscaling
- Monitor a cluster
- Roll up or transform your data
- Set up a cluster for high availability
- Snapshot and restore
- Secure the Elastic Stack
- Elasticsearch security principles
- Start the Elastic Stack with security enabled automatically
- Manually configure security
- Updating node security certificates
- User authentication
- Built-in users
- Service accounts
- Internal users
- Token-based authentication services
- User profiles
- Realms
- Realm chains
- Security domains
- Active Directory user authentication
- File-based user authentication
- LDAP user authentication
- Native user authentication
- OpenID Connect authentication
- PKI user authentication
- SAML authentication
- Kerberos authentication
- JWT authentication
- Integrating with other authentication systems
- Enabling anonymous access
- Looking up users without authentication
- Controlling the user cache
- Configuring SAML single-sign-on on the Elastic Stack
- Configuring single sign-on to the Elastic Stack using OpenID Connect
- User authorization
- Built-in roles
- Defining roles
- Role restriction
- Security privileges
- Document level security
- Field level security
- Granting privileges for data streams and aliases
- Mapping users and groups to roles
- Setting up field and document level security
- Submitting requests on behalf of other users
- Configuring authorization delegation
- Customizing roles and authorization
- Enable audit logging
- Restricting connections with IP filtering
- Securing clients and integrations
- Operator privileges
- Troubleshooting
- Some settings are not returned via the nodes settings API
- Authorization exceptions
- Users command fails due to extra arguments
- Users are frequently locked out of Active Directory
- Certificate verification fails for curl on Mac
- SSLHandshakeException causes connections to fail
- Common SSL/TLS exceptions
- Common Kerberos exceptions
- Common SAML issues
- Internal Server Error in Kibana
- Setup-passwords command fails due to connection failure
- Failures due to relocation of the configuration files
- Limitations
- Watcher
- Command line tools
- elasticsearch-certgen
- elasticsearch-certutil
- elasticsearch-create-enrollment-token
- elasticsearch-croneval
- elasticsearch-keystore
- elasticsearch-node
- elasticsearch-reconfigure-node
- elasticsearch-reset-password
- elasticsearch-saml-metadata
- elasticsearch-service-tokens
- elasticsearch-setup-passwords
- elasticsearch-shard
- elasticsearch-syskeygen
- elasticsearch-users
- How to
- Troubleshooting
- Fix common cluster issues
- Diagnose unassigned shards
- Add a missing tier to the system
- Allow Elasticsearch to allocate the data in the system
- Allow Elasticsearch to allocate the index
- Indices mix index allocation filters with data tiers node roles to move through data tiers
- Not enough nodes to allocate all shard replicas
- Total number of shards for an index on a single node exceeded
- Total number of shards per node has been reached
- Troubleshooting corruption
- Fix data nodes out of disk
- Fix master nodes out of disk
- Fix other role nodes out of disk
- Start index lifecycle management
- Start Snapshot Lifecycle Management
- Restore from snapshot
- Multiple deployments writing to the same snapshot repository
- Addressing repeated snapshot policy failures
- Troubleshooting an unstable cluster
- Troubleshooting discovery
- Troubleshooting monitoring
- Troubleshooting transforms
- Troubleshooting Watcher
- Troubleshooting searches
- Troubleshooting shards capacity health issues
- REST APIs
- API conventions
- Common options
- REST API compatibility
- Autoscaling APIs
- Behavioral Analytics APIs
- Compact and aligned text (CAT) APIs
- cat aliases
- cat allocation
- cat anomaly detectors
- cat component templates
- cat count
- cat data frame analytics
- cat datafeeds
- cat fielddata
- cat health
- cat indices
- cat master
- cat nodeattrs
- cat nodes
- cat pending tasks
- cat plugins
- cat recovery
- cat repositories
- cat segments
- cat shards
- cat snapshots
- cat task management
- cat templates
- cat thread pool
- cat trained model
- cat transforms
- Cluster APIs
- Cluster allocation explain
- Cluster get settings
- Cluster health
- Health
- Cluster reroute
- Cluster state
- Cluster stats
- Cluster update settings
- Nodes feature usage
- Nodes hot threads
- Nodes info
- Prevalidate node removal
- Nodes reload secure settings
- Nodes stats
- Cluster Info
- Pending cluster tasks
- Remote cluster info
- Task management
- Voting configuration exclusions
- Create or update desired nodes
- Get desired nodes
- Delete desired nodes
- Get desired balance
- Reset desired balance
- Cross-cluster replication APIs
- Data stream APIs
- Document APIs
- Enrich APIs
- EQL APIs
- Features APIs
- Fleet APIs
- Find structure API
- Graph explore API
- Index APIs
- Alias exists
- Aliases
- Analyze
- Analyze index disk usage
- Clear cache
- Clone index
- Close index
- Create index
- Create or update alias
- Create or update component template
- Create or update index template
- Create or update index template (legacy)
- Delete component template
- Delete dangling index
- Delete alias
- Delete index
- Delete index template
- Delete index template (legacy)
- Exists
- Field usage stats
- Flush
- Force merge
- Get alias
- Get component template
- Get field mapping
- Get index
- Get index settings
- Get index template
- Get index template (legacy)
- Get mapping
- Import dangling index
- Index recovery
- Index segments
- Index shard stores
- Index stats
- Index template exists (legacy)
- List dangling indices
- Open index
- Refresh
- Resolve index
- Rollover
- Shrink index
- Simulate index
- Simulate template
- Split index
- Unfreeze index
- Update index settings
- Update mapping
- Index lifecycle management APIs
- Create or update lifecycle policy
- Get policy
- Delete policy
- Move to step
- Remove policy
- Retry policy
- Get index lifecycle management status
- Explain lifecycle
- Start index lifecycle management
- Stop index lifecycle management
- Migrate indices, ILM policies, and legacy, composable and component templates to data tiers routing
- Ingest APIs
- Info API
- Licensing APIs
- Logstash APIs
- Machine learning APIs
- Machine learning anomaly detection APIs
- Add events to calendar
- Add jobs to calendar
- Close jobs
- Create jobs
- Create calendars
- Create datafeeds
- Create filters
- Delete calendars
- Delete datafeeds
- Delete events from calendar
- Delete filters
- Delete forecasts
- Delete jobs
- Delete jobs from calendar
- Delete model snapshots
- Delete expired data
- Estimate model memory
- Flush jobs
- Forecast jobs
- Get buckets
- Get calendars
- Get categories
- Get datafeeds
- Get datafeed statistics
- Get influencers
- Get jobs
- Get job statistics
- Get model snapshots
- Get model snapshot upgrade statistics
- Get overall buckets
- Get scheduled events
- Get filters
- Get records
- Open jobs
- Post data to jobs
- Preview datafeeds
- Reset jobs
- Revert model snapshots
- Start datafeeds
- Stop datafeeds
- Update datafeeds
- Update filters
- Update jobs
- Update model snapshots
- Upgrade model snapshots
- Machine learning data frame analytics APIs
- Create data frame analytics jobs
- Delete data frame analytics jobs
- Evaluate data frame analytics
- Explain data frame analytics
- Get data frame analytics jobs
- Get data frame analytics jobs stats
- Preview data frame analytics
- Start data frame analytics jobs
- Stop data frame analytics jobs
- Update data frame analytics jobs
- Machine learning trained model APIs
- Clear trained model deployment cache
- Create or update trained model aliases
- Create part of a trained model
- Create trained models
- Create trained model vocabulary
- Delete trained model aliases
- Delete trained models
- Get trained models
- Get trained models stats
- Infer trained model
- Start trained model deployment
- Stop trained model deployment
- Update trained model deployment
- Migration APIs
- Node lifecycle APIs
- Query rules APIs
- Reload search analyzers API
- Repositories metering APIs
- Rollup APIs
- Script APIs
- Search APIs
- Search Application APIs
- Searchable snapshots APIs
- Security APIs
- Authenticate
- Change passwords
- Clear cache
- Clear roles cache
- Clear privileges cache
- Clear API key cache
- Clear service account token caches
- Create API keys
- Create or update application privileges
- Create or update role mappings
- Create or update roles
- Create or update users
- Create service account tokens
- Delegate PKI authentication
- Delete application privileges
- Delete role mappings
- Delete roles
- Delete service account token
- Delete users
- Disable users
- Enable users
- Enroll Kibana
- Enroll node
- Get API key information
- Get application privileges
- Get builtin privileges
- Get role mappings
- Get roles
- Get service accounts
- Get service account credentials
- Get token
- Get user privileges
- Get users
- Grant API keys
- Has privileges
- Invalidate API key
- Invalidate token
- OpenID Connect prepare authentication
- OpenID Connect authenticate
- OpenID Connect logout
- Query API key information
- Update API key
- Bulk update API keys
- SAML prepare authentication
- SAML authenticate
- SAML logout
- SAML invalidate
- SAML complete logout
- SAML service provider metadata
- SSL certificate
- Activate user profile
- Disable user profile
- Enable user profile
- Get user profiles
- Suggest user profile
- Update user profile data
- Has privileges user profile
- Create Cross-Cluster API key
- Update Cross-Cluster API key
- Snapshot and restore APIs
- Snapshot lifecycle management APIs
- SQL APIs
- Synonyms APIs
- Transform APIs
- Usage API
- Watcher APIs
- Definitions
- Migration guide
- Release notes
- Elasticsearch version 8.10.4
- Elasticsearch version 8.10.3
- Elasticsearch version 8.10.2
- Elasticsearch version 8.10.1
- Elasticsearch version 8.10.0
- Elasticsearch version 8.9.2
- Elasticsearch version 8.9.1
- Elasticsearch version 8.9.0
- Elasticsearch version 8.8.2
- Elasticsearch version 8.8.1
- Elasticsearch version 8.8.0
- Elasticsearch version 8.7.1
- Elasticsearch version 8.7.0
- Elasticsearch version 8.6.2
- Elasticsearch version 8.6.1
- Elasticsearch version 8.6.0
- Elasticsearch version 8.5.3
- Elasticsearch version 8.5.2
- Elasticsearch version 8.5.1
- Elasticsearch version 8.5.0
- Elasticsearch version 8.4.3
- Elasticsearch version 8.4.2
- Elasticsearch version 8.4.1
- Elasticsearch version 8.4.0
- Elasticsearch version 8.3.3
- Elasticsearch version 8.3.2
- Elasticsearch version 8.3.1
- Elasticsearch version 8.3.0
- Elasticsearch version 8.2.3
- Elasticsearch version 8.2.2
- Elasticsearch version 8.2.1
- Elasticsearch version 8.2.0
- Elasticsearch version 8.1.3
- Elasticsearch version 8.1.2
- Elasticsearch version 8.1.1
- Elasticsearch version 8.1.0
- Elasticsearch version 8.0.1
- Elasticsearch version 8.0.0
- Elasticsearch version 8.0.0-rc2
- Elasticsearch version 8.0.0-rc1
- Elasticsearch version 8.0.0-beta1
- Elasticsearch version 8.0.0-alpha2
- Elasticsearch version 8.0.0-alpha1
- Dependencies and versions
Multi-match query
editMulti-match query
editThe multi_match
query builds on the match
query
to allow multi-field queries:
$params = [ 'body' => [ 'query' => [ 'multi_match' => [ 'query' => 'this is a test', 'fields' => [ 'subject', 'message', ], ], ], ], ]; $response = $client->search($params);
resp = client.search( body={ "query": { "multi_match": { "query": "this is a test", "fields": ["subject", "message"], } } }, ) print(resp)
response = client.search( body: { query: { multi_match: { query: 'this is a test', fields: [ 'subject', 'message' ] } } } ) puts response
res, err := es.Search( es.Search.WithBody(strings.NewReader(`{ "query": { "multi_match": { "query": "this is a test", "fields": [ "subject", "message" ] } } }`)), es.Search.WithPretty(), ) fmt.Println(res, err)
const response = await client.search({ body: { query: { multi_match: { query: 'this is a test', fields: [ 'subject', 'message' ] } } } }) console.log(response)
GET /_search { "query": { "multi_match" : { "query": "this is a test", "fields": [ "subject", "message" ] } } }
fields
and per-field boosting
editFields can be specified with wildcards, eg:
$params = [ 'body' => [ 'query' => [ 'multi_match' => [ 'query' => 'Will Smith', 'fields' => [ 'title', '*_name', ], ], ], ], ]; $response = $client->search($params);
resp = client.search( body={ "query": { "multi_match": { "query": "Will Smith", "fields": ["title", "*_name"], } } }, ) print(resp)
response = client.search( body: { query: { multi_match: { query: 'Will Smith', fields: [ 'title', '*_name' ] } } } ) puts response
res, err := es.Search( es.Search.WithBody(strings.NewReader(`{ "query": { "multi_match": { "query": "Will Smith", "fields": [ "title", "*_name" ] } } }`)), es.Search.WithPretty(), ) fmt.Println(res, err)
const response = await client.search({ body: { query: { multi_match: { query: 'Will Smith', fields: [ 'title', '*_name' ] } } } }) console.log(response)
GET /_search { "query": { "multi_match" : { "query": "Will Smith", "fields": [ "title", "*_name" ] } } }
Individual fields can be boosted with the caret (^
) notation:
$params = [ 'body' => [ 'query' => [ 'multi_match' => [ 'query' => 'this is a test', 'fields' => [ 'subject^3', 'message', ], ], ], ], ]; $response = $client->search($params);
resp = client.search( body={ "query": { "multi_match": { "query": "this is a test", "fields": ["subject^3", "message"], } } }, ) print(resp)
response = client.search( body: { query: { multi_match: { query: 'this is a test', fields: [ 'subject^3', 'message' ] } } } ) puts response
res, err := es.Search( es.Search.WithBody(strings.NewReader(`{ "query": { "multi_match": { "query": "this is a test", "fields": [ "subject^3", "message" ] } } }`)), es.Search.WithPretty(), ) fmt.Println(res, err)
const response = await client.search({ body: { query: { multi_match: { query: 'this is a test', fields: [ 'subject^3', 'message' ] } } } }) console.log(response)
GET /_search { "query": { "multi_match" : { "query" : "this is a test", "fields" : [ "subject^3", "message" ] } } }
The query multiplies the |
If no fields
are provided, the multi_match
query defaults to the index.query.default_field
index settings, which in turn defaults to *
. *
extracts all fields in the mapping that
are eligible to term queries and filters the metadata fields. All extracted fields are then
combined to build a query.
Field number limit
By default, there is a limit to the number of clauses a query can contain. This
limit is defined by the
indices.query.bool.max_clause_count
setting, which defaults to 4096
. For multi-match queries, the number of
clauses is calculated as the number of fields multiplied by the number of terms.
Types of multi_match
query:
editThe way the multi_match
query is executed internally depends on the type
parameter, which can be set to:
|
(default) Finds documents which match any field, but
uses the |
|
Finds documents which match any field and combines
the |
|
Treats fields with the same |
|
Runs a |
|
Runs a |
|
Creates a |
best_fields
editThe best_fields
type is most useful when you are searching for multiple
words best found in the same field. For instance “brown fox” in a single
field is more meaningful than “brown” in one field and “fox” in the other.
The best_fields
type generates a match
query for
each field and wraps them in a dis_max
query, to
find the single best matching field. For instance, this query:
$params = [ 'body' => [ 'query' => [ 'multi_match' => [ 'query' => 'brown fox', 'type' => 'best_fields', 'fields' => [ 'subject', 'message', ], 'tie_breaker' => 0.3, ], ], ], ]; $response = $client->search($params);
resp = client.search( body={ "query": { "multi_match": { "query": "brown fox", "type": "best_fields", "fields": ["subject", "message"], "tie_breaker": 0.3, } } }, ) print(resp)
response = client.search( body: { query: { multi_match: { query: 'brown fox', type: 'best_fields', fields: [ 'subject', 'message' ], tie_breaker: 0.3 } } } ) puts response
res, err := es.Search( es.Search.WithBody(strings.NewReader(`{ "query": { "multi_match": { "query": "brown fox", "type": "best_fields", "fields": [ "subject", "message" ], "tie_breaker": 0.3 } } }`)), es.Search.WithPretty(), ) fmt.Println(res, err)
const response = await client.search({ body: { query: { multi_match: { query: 'brown fox', type: 'best_fields', fields: [ 'subject', 'message' ], tie_breaker: 0.3 } } } }) console.log(response)
GET /_search { "query": { "multi_match" : { "query": "brown fox", "type": "best_fields", "fields": [ "subject", "message" ], "tie_breaker": 0.3 } } }
would be executed as:
$params = [ 'body' => [ 'query' => [ 'dis_max' => [ 'queries' => [ [ 'match' => [ 'subject' => 'brown fox', ], ], [ 'match' => [ 'message' => 'brown fox', ], ], ], 'tie_breaker' => 0.3, ], ], ], ]; $response = $client->search($params);
resp = client.search( body={ "query": { "dis_max": { "queries": [ {"match": {"subject": "brown fox"}}, {"match": {"message": "brown fox"}}, ], "tie_breaker": 0.3, } } }, ) print(resp)
response = client.search( body: { query: { dis_max: { queries: [ { match: { subject: 'brown fox' } }, { match: { message: 'brown fox' } } ], tie_breaker: 0.3 } } } ) puts response
res, err := es.Search( es.Search.WithBody(strings.NewReader(`{ "query": { "dis_max": { "queries": [ { "match": { "subject": "brown fox" } }, { "match": { "message": "brown fox" } } ], "tie_breaker": 0.3 } } }`)), es.Search.WithPretty(), ) fmt.Println(res, err)
const response = await client.search({ body: { query: { dis_max: { queries: [ { match: { subject: 'brown fox' } }, { match: { message: 'brown fox' } } ], tie_breaker: 0.3 } } } }) console.log(response)
GET /_search { "query": { "dis_max": { "queries": [ { "match": { "subject": "brown fox" }}, { "match": { "message": "brown fox" }} ], "tie_breaker": 0.3 } } }
Normally the best_fields
type uses the score of the single best matching
field, but if tie_breaker
is specified, then it calculates the score as
follows:
- the score from the best matching field
-
plus
tie_breaker * _score
for all other matching fields
Also, accepts analyzer
, boost
, operator
, minimum_should_match
,
fuzziness
, lenient
, prefix_length
, max_expansions
, fuzzy_rewrite
, zero_terms_query
,
auto_generate_synonyms_phrase_query
and fuzzy_transpositions
,
as explained in match query.
operator
and minimum_should_match
The best_fields
and most_fields
types are field-centric — they generate
a match
query per field. This means that the operator
and
minimum_should_match
parameters are applied to each field individually,
which is probably not what you want.
Take this query for example:
$params = [ 'body' => [ 'query' => [ 'multi_match' => [ 'query' => 'Will Smith', 'type' => 'best_fields', 'fields' => [ 'first_name', 'last_name', ], 'operator' => 'and', ], ], ], ]; $response = $client->search($params);
resp = client.search( body={ "query": { "multi_match": { "query": "Will Smith", "type": "best_fields", "fields": ["first_name", "last_name"], "operator": "and", } } }, ) print(resp)
response = client.search( body: { query: { multi_match: { query: 'Will Smith', type: 'best_fields', fields: [ 'first_name', 'last_name' ], operator: 'and' } } } ) puts response
res, err := es.Search( es.Search.WithBody(strings.NewReader(`{ "query": { "multi_match": { "query": "Will Smith", "type": "best_fields", "fields": [ "first_name", "last_name" ], "operator": "and" } } }`)), es.Search.WithPretty(), ) fmt.Println(res, err)
const response = await client.search({ body: { query: { multi_match: { query: 'Will Smith', type: 'best_fields', fields: [ 'first_name', 'last_name' ], operator: 'and' } } } }) console.log(response)
GET /_search { "query": { "multi_match" : { "query": "Will Smith", "type": "best_fields", "fields": [ "first_name", "last_name" ], "operator": "and" } } }
This query is executed as:
(+first_name:will +first_name:smith) | (+last_name:will +last_name:smith)
In other words, all terms must be present in a single field for a document to match.
The combined_fields
query offers a
term-centric approach that handles operator
and minimum_should_match
on a
per-term basis. The other multi-match mode cross_fields
also
addresses this issue.
most_fields
editThe most_fields
type is most useful when querying multiple fields that
contain the same text analyzed in different ways. For instance, the main
field may contain synonyms, stemming and terms without diacritics. A second
field may contain the original terms, and a third field might contain
shingles. By combining scores from all three fields we can match as many
documents as possible with the main field, but use the second and third fields
to push the most similar results to the top of the list.
This query:
$params = [ 'body' => [ 'query' => [ 'multi_match' => [ 'query' => 'quick brown fox', 'type' => 'most_fields', 'fields' => [ 'title', 'title.original', 'title.shingles', ], ], ], ], ]; $response = $client->search($params);
resp = client.search( body={ "query": { "multi_match": { "query": "quick brown fox", "type": "most_fields", "fields": ["title", "title.original", "title.shingles"], } } }, ) print(resp)
response = client.search( body: { query: { multi_match: { query: 'quick brown fox', type: 'most_fields', fields: [ 'title', 'title.original', 'title.shingles' ] } } } ) puts response
res, err := es.Search( es.Search.WithBody(strings.NewReader(`{ "query": { "multi_match": { "query": "quick brown fox", "type": "most_fields", "fields": [ "title", "title.original", "title.shingles" ] } } }`)), es.Search.WithPretty(), ) fmt.Println(res, err)
const response = await client.search({ body: { query: { multi_match: { query: 'quick brown fox', type: 'most_fields', fields: [ 'title', 'title.original', 'title.shingles' ] } } } }) console.log(response)
GET /_search { "query": { "multi_match" : { "query": "quick brown fox", "type": "most_fields", "fields": [ "title", "title.original", "title.shingles" ] } } }
would be executed as:
$params = [ 'body' => [ 'query' => [ 'bool' => [ 'should' => [ [ 'match' => [ 'title' => 'quick brown fox', ], ], [ 'match' => [ 'title.original' => 'quick brown fox', ], ], [ 'match' => [ 'title.shingles' => 'quick brown fox', ], ], ], ], ], ], ]; $response = $client->search($params);
resp = client.search( body={ "query": { "bool": { "should": [ {"match": {"title": "quick brown fox"}}, {"match": {"title.original": "quick brown fox"}}, {"match": {"title.shingles": "quick brown fox"}}, ] } } }, ) print(resp)
response = client.search( body: { query: { bool: { should: [ { match: { title: 'quick brown fox' } }, { match: { "title.original": 'quick brown fox' } }, { match: { "title.shingles": 'quick brown fox' } } ] } } } ) puts response
res, err := es.Search( es.Search.WithBody(strings.NewReader(`{ "query": { "bool": { "should": [ { "match": { "title": "quick brown fox" } }, { "match": { "title.original": "quick brown fox" } }, { "match": { "title.shingles": "quick brown fox" } } ] } } }`)), es.Search.WithPretty(), ) fmt.Println(res, err)
const response = await client.search({ body: { query: { bool: { should: [ { match: { title: 'quick brown fox' } }, { match: { 'title.original': 'quick brown fox' } }, { match: { 'title.shingles': 'quick brown fox' } } ] } } } }) console.log(response)
GET /_search { "query": { "bool": { "should": [ { "match": { "title": "quick brown fox" }}, { "match": { "title.original": "quick brown fox" }}, { "match": { "title.shingles": "quick brown fox" }} ] } } }
The score from each match
clause is added together, just like a bool
query.
Also, accepts analyzer
, boost
, operator
, minimum_should_match
,
fuzziness
, lenient
, prefix_length
, max_expansions
, fuzzy_rewrite
, and zero_terms_query
.
phrase
and phrase_prefix
editThe phrase
and phrase_prefix
types behave just like best_fields
,
but they use a match_phrase
or match_phrase_prefix
query instead of a
match
query.
This query:
$params = [ 'body' => [ 'query' => [ 'multi_match' => [ 'query' => 'quick brown f', 'type' => 'phrase_prefix', 'fields' => [ 'subject', 'message', ], ], ], ], ]; $response = $client->search($params);
resp = client.search( body={ "query": { "multi_match": { "query": "quick brown f", "type": "phrase_prefix", "fields": ["subject", "message"], } } }, ) print(resp)
response = client.search( body: { query: { multi_match: { query: 'quick brown f', type: 'phrase_prefix', fields: [ 'subject', 'message' ] } } } ) puts response
res, err := es.Search( es.Search.WithBody(strings.NewReader(`{ "query": { "multi_match": { "query": "quick brown f", "type": "phrase_prefix", "fields": [ "subject", "message" ] } } }`)), es.Search.WithPretty(), ) fmt.Println(res, err)
const response = await client.search({ body: { query: { multi_match: { query: 'quick brown f', type: 'phrase_prefix', fields: [ 'subject', 'message' ] } } } }) console.log(response)
GET /_search { "query": { "multi_match" : { "query": "quick brown f", "type": "phrase_prefix", "fields": [ "subject", "message" ] } } }
would be executed as:
$params = [ 'body' => [ 'query' => [ 'dis_max' => [ 'queries' => [ [ 'match_phrase_prefix' => [ 'subject' => 'quick brown f', ], ], [ 'match_phrase_prefix' => [ 'message' => 'quick brown f', ], ], ], ], ], ], ]; $response = $client->search($params);
resp = client.search( body={ "query": { "dis_max": { "queries": [ {"match_phrase_prefix": {"subject": "quick brown f"}}, {"match_phrase_prefix": {"message": "quick brown f"}}, ] } } }, ) print(resp)
response = client.search( body: { query: { dis_max: { queries: [ { match_phrase_prefix: { subject: 'quick brown f' } }, { match_phrase_prefix: { message: 'quick brown f' } } ] } } } ) puts response
res, err := es.Search( es.Search.WithBody(strings.NewReader(`{ "query": { "dis_max": { "queries": [ { "match_phrase_prefix": { "subject": "quick brown f" } }, { "match_phrase_prefix": { "message": "quick brown f" } } ] } } }`)), es.Search.WithPretty(), ) fmt.Println(res, err)
const response = await client.search({ body: { query: { dis_max: { queries: [ { match_phrase_prefix: { subject: 'quick brown f' } }, { match_phrase_prefix: { message: 'quick brown f' } } ] } } } }) console.log(response)
GET /_search { "query": { "dis_max": { "queries": [ { "match_phrase_prefix": { "subject": "quick brown f" }}, { "match_phrase_prefix": { "message": "quick brown f" }} ] } } }
Also, accepts analyzer
, boost
, lenient
and zero_terms_query
as explained
in Match, as well as slop
which is explained in Match phrase.
Type phrase_prefix
additionally accepts max_expansions
.
cross_fields
editThe cross_fields
type is particularly useful with structured documents where
multiple fields should match. For instance, when querying the first_name
and last_name
fields for “Will Smith”, the best match is likely to have
“Will” in one field and “Smith” in the other.
One way of dealing with these types of queries is simply to index the
first_name
and last_name
fields into a single full_name
field. Of
course, this can only be done at index time.
The cross_field
type tries to solve these problems at query time by taking a
term-centric approach. It first analyzes the query string into individual
terms, then looks for each term in any of the fields, as though they were one
big field.
A query like:
$params = [ 'body' => [ 'query' => [ 'multi_match' => [ 'query' => 'Will Smith', 'type' => 'cross_fields', 'fields' => [ 'first_name', 'last_name', ], 'operator' => 'and', ], ], ], ]; $response = $client->search($params);
resp = client.search( body={ "query": { "multi_match": { "query": "Will Smith", "type": "cross_fields", "fields": ["first_name", "last_name"], "operator": "and", } } }, ) print(resp)
response = client.search( body: { query: { multi_match: { query: 'Will Smith', type: 'cross_fields', fields: [ 'first_name', 'last_name' ], operator: 'and' } } } ) puts response
res, err := es.Search( es.Search.WithBody(strings.NewReader(`{ "query": { "multi_match": { "query": "Will Smith", "type": "cross_fields", "fields": [ "first_name", "last_name" ], "operator": "and" } } }`)), es.Search.WithPretty(), ) fmt.Println(res, err)
const response = await client.search({ body: { query: { multi_match: { query: 'Will Smith', type: 'cross_fields', fields: [ 'first_name', 'last_name' ], operator: 'and' } } } }) console.log(response)
GET /_search { "query": { "multi_match" : { "query": "Will Smith", "type": "cross_fields", "fields": [ "first_name", "last_name" ], "operator": "and" } } }
is executed as:
+(first_name:will last_name:will) +(first_name:smith last_name:smith)
In other words, all terms must be present in at least one field for a
document to match. (Compare this to
the logic used for best_fields
and most_fields
.)
That solves one of the two problems. The problem of differing term frequencies is solved by blending the term frequencies for all fields in order to even out the differences.
In practice, first_name:smith
will be treated as though it has the same
frequencies as last_name:smith
, plus one. This will make matches on
first_name
and last_name
have comparable scores, with a tiny advantage
for last_name
since it is the most likely field that contains smith
.
Note that cross_fields
is usually only useful on short string fields
that all have a boost
of 1
. Otherwise boosts, term freqs and length
normalization contribute to the score in such a way that the blending of term
statistics is not meaningful anymore.
If you run the above query through the Validate, it returns this explanation:
+blended("will", fields: [first_name, last_name]) +blended("smith", fields: [first_name, last_name])
Also, accepts analyzer
, boost
, operator
, minimum_should_match
,
lenient
and zero_terms_query
.
The cross_fields
type blends field statistics in a complex way that
can be hard to interpret. The score combination can even be incorrect, in
particular when some documents contain some of the search fields, but not all
of them. You should consider the
combined_fields
query as an alternative,
which is also term-centric but combines field statistics in a more robust way.
cross_field
and analysis
editThe cross_field
type can only work in term-centric mode on fields that have
the same analyzer. Fields with the same analyzer are grouped together as in
the example above. If there are multiple groups, the query will use the best
score from any group.
For instance, if we have a first
and last
field which have
the same analyzer, plus a first.edge
and last.edge
which
both use an edge_ngram
analyzer, this query:
$params = [ 'body' => [ 'query' => [ 'multi_match' => [ 'query' => 'Jon', 'type' => 'cross_fields', 'fields' => [ 'first', 'first.edge', 'last', 'last.edge', ], ], ], ], ]; $response = $client->search($params);
resp = client.search( body={ "query": { "multi_match": { "query": "Jon", "type": "cross_fields", "fields": ["first", "first.edge", "last", "last.edge"], } } }, ) print(resp)
response = client.search( body: { query: { multi_match: { query: 'Jon', type: 'cross_fields', fields: [ 'first', 'first.edge', 'last', 'last.edge' ] } } } ) puts response
res, err := es.Search( es.Search.WithBody(strings.NewReader(`{ "query": { "multi_match": { "query": "Jon", "type": "cross_fields", "fields": [ "first", "first.edge", "last", "last.edge" ] } } }`)), es.Search.WithPretty(), ) fmt.Println(res, err)
const response = await client.search({ body: { query: { multi_match: { query: 'Jon', type: 'cross_fields', fields: [ 'first', 'first.edge', 'last', 'last.edge' ] } } } }) console.log(response)
GET /_search { "query": { "multi_match" : { "query": "Jon", "type": "cross_fields", "fields": [ "first", "first.edge", "last", "last.edge" ] } } }
would be executed as:
blended("jon", fields: [first, last]) | ( blended("j", fields: [first.edge, last.edge]) blended("jo", fields: [first.edge, last.edge]) blended("jon", fields: [first.edge, last.edge]) )
In other words, first
and last
would be grouped together and
treated as a single field, and first.edge
and last.edge
would be
grouped together and treated as a single field.
Having multiple groups is fine, but when combined with operator
or
minimum_should_match
, it can suffer from the same problem
as most_fields
or best_fields
.
You can easily rewrite this query yourself as two separate cross_fields
queries combined with a dis_max
query, and apply the minimum_should_match
parameter to just one of them:
response = client.search( body: { query: { dis_max: { queries: [ { multi_match: { query: 'Will Smith', type: 'cross_fields', fields: [ 'first', 'last' ], minimum_should_match: '50%' } }, { multi_match: { query: 'Will Smith', type: 'cross_fields', fields: [ '*.edge' ] } } ] } } } ) puts response
GET /_search { "query": { "dis_max": { "queries": [ { "multi_match" : { "query": "Will Smith", "type": "cross_fields", "fields": [ "first", "last" ], "minimum_should_match": "50%" } }, { "multi_match" : { "query": "Will Smith", "type": "cross_fields", "fields": [ "*.edge" ] } } ] } } }
You can force all fields into the same group by specifying the analyzer
parameter in the query.
$params = [ 'body' => [ 'query' => [ 'multi_match' => [ 'query' => 'Jon', 'type' => 'cross_fields', 'analyzer' => 'standard', 'fields' => [ 'first', 'last', '*.edge', ], ], ], ], ]; $response = $client->search($params);
resp = client.search( body={ "query": { "multi_match": { "query": "Jon", "type": "cross_fields", "analyzer": "standard", "fields": ["first", "last", "*.edge"], } } }, ) print(resp)
response = client.search( body: { query: { multi_match: { query: 'Jon', type: 'cross_fields', analyzer: 'standard', fields: [ 'first', 'last', '*.edge' ] } } } ) puts response
res, err := es.Search( es.Search.WithBody(strings.NewReader(`{ "query": { "multi_match": { "query": "Jon", "type": "cross_fields", "analyzer": "standard", "fields": [ "first", "last", "*.edge" ] } } }`)), es.Search.WithPretty(), ) fmt.Println(res, err)
const response = await client.search({ body: { query: { multi_match: { query: 'Jon', type: 'cross_fields', analyzer: 'standard', fields: [ 'first', 'last', '*.edge' ] } } } }) console.log(response)
GET /_search { "query": { "multi_match" : { "query": "Jon", "type": "cross_fields", "analyzer": "standard", "fields": [ "first", "last", "*.edge" ] } } }
which will be executed as:
blended("will", fields: [first, first.edge, last.edge, last]) blended("smith", fields: [first, first.edge, last.edge, last])
tie_breaker
editBy default, each per-term blended
query will use the best score returned by
any field in a group. Then when combining scores across groups, the query uses
the best score from any group. The tie_breaker
parameter can change the
behavior for both of these steps:
|
Take the single best score out of (eg) |
|
Add together the scores for (eg) |
|
Take the single best score plus |
bool_prefix
editThe bool_prefix
type’s scoring behaves like most_fields
, but using a
match_bool_prefix
query instead of a
match
query.
$params = [ 'body' => [ 'query' => [ 'multi_match' => [ 'query' => 'quick brown f', 'type' => 'bool_prefix', 'fields' => [ 'subject', 'message', ], ], ], ], ]; $response = $client->search($params);
resp = client.search( body={ "query": { "multi_match": { "query": "quick brown f", "type": "bool_prefix", "fields": ["subject", "message"], } } }, ) print(resp)
response = client.search( body: { query: { multi_match: { query: 'quick brown f', type: 'bool_prefix', fields: [ 'subject', 'message' ] } } } ) puts response
res, err := es.Search( es.Search.WithBody(strings.NewReader(`{ "query": { "multi_match": { "query": "quick brown f", "type": "bool_prefix", "fields": [ "subject", "message" ] } } }`)), es.Search.WithPretty(), ) fmt.Println(res, err)
const response = await client.search({ body: { query: { multi_match: { query: 'quick brown f', type: 'bool_prefix', fields: [ 'subject', 'message' ] } } } }) console.log(response)
GET /_search { "query": { "multi_match" : { "query": "quick brown f", "type": "bool_prefix", "fields": [ "subject", "message" ] } } }
The analyzer
, boost
, operator
, minimum_should_match
, lenient
,
zero_terms_query
, and auto_generate_synonyms_phrase_query
parameters as
explained in match query are supported. The
fuzziness
, prefix_length
, max_expansions
, fuzzy_rewrite
, and
fuzzy_transpositions
parameters are supported for the terms that are used to
construct term queries, but do not have an effect on the prefix query
constructed from the final term.
The slop
parameter is not supported by this query type.
On this page