WARNING: The 2.x versions of Elasticsearch have passed their EOL dates. If you are running a 2.x version, we strongly advise you to upgrade.
This documentation is no longer maintained and may be removed. For the latest information, see the current Elasticsearch documentation.
Combining Filtersedit
The previous two examples showed a single filter in use. In practice, you will probably need to filter on multiple values or fields. For example, how would you express this SQL in Elasticsearch?
SELECT product FROM products WHERE (price = 20 OR productID = "XHDK-A-1293-#fJ3") AND (price != 30)
In these situations, you will need to use a bool
query
inside the constant_score
query. This allows us to build
filters that can have multiple components in boolean combinations.
Bool Filteredit
Recall that the bool
query is composed of four sections:
{ "bool" : { "must" : [], "should" : [], "must_not" : [], "filter": [] } }
-
must
-
All of these clauses must match. The equivalent of
AND
. -
must_not
-
All of these clauses must not match. The equivalent of
NOT
. -
should
-
At least one of these clauses must match. The equivalent of
OR
. -
filter
- Clauses that must match, but are run in non-scoring, filtering mode.
In this secondary boolean query, we can ignore the filter
clause: the queries
are already running in non-scoring mode, so the extra filter
clause is useless.
Each section of the bool
filter is optional (for example, you can have a must
clause and nothing else), and each section can contain a single query or an
array of queries.
To replicate the preceding SQL example, we will take the two term
queries that
we used
previously and
place them inside the should
clause of a bool
query, and add another clause
to deal with the NOT
condition:
GET /my_store/products/_search { "query" : { "constant_score" : { "filter" : { "bool" : { "should" : [ { "term" : {"price" : 20}}, { "term" : {"productID" : "XHDK-A-1293-#fJ3"}} ], "must_not" : { "term" : {"price" : 30} } } } } } }
Note that we still need to use a |
|
These two |
|
If a product has a price of |
Notice how boolean is placed inside the constant_score
, but the individual term
queries are just placed in the should
and must_not
. Because everything is wrapped
with the constant_score
, the rest of the queries are executing in filtering mode.
Our search results return two hits, each document satisfying a different clause
in the bool
query:
Nesting Boolean Queriesedit
You can already see how nesting boolean queries together can give rise to more sophisticated boolean logic. If you need to perform more complex operations, you can continue nesting boolean queries in any combination, giving rise to arbitrarily complex boolean logic.
For example, if we have this SQL statement:
SELECT document FROM products WHERE productID = "KDKE-B-9947-#kL5" OR ( productID = "JODL-X-1937-#pV7" AND price = 30 )
We can translate it into a pair of nested bool
filters:
GET /my_store/products/_search { "query" : { "constant_score" : { "filter" : { "bool" : { "should" : [ { "term" : {"productID" : "KDKE-B-9947-#kL5"}}, { "bool" : { "must" : [ { "term" : {"productID" : "JODL-X-1937-#pV7"}}, { "term" : {"price" : 30}} ] }} ] } } } } }
Because the |
|
These two |
The results show us two documents, one matching each of the should
clauses:
"hits" : [ { "_id" : "2", "_score" : 1.0, "_source" : { "price" : 20, "productID" : "KDKE-B-9947-#kL5" } }, { "_id" : "3", "_score" : 1.0, "_source" : { "price" : 30, "productID" : "JODL-X-1937-#pV7" } } ]
This |
|
These two fields match the |
This was a simple example, but it demonstrates how Boolean queries can be used as building blocks to construct complex logical conditions.
- Elasticsearch - The Definitive Guide:
- Foreword
- Preface
- Getting Started
- You Know, for Search…
- Installing and Running Elasticsearch
- Talking to Elasticsearch
- Document Oriented
- Finding Your Feet
- Indexing Employee Documents
- Retrieving a Document
- Search Lite
- Search with Query DSL
- More-Complicated Searches
- Full-Text Search
- Phrase Search
- Highlighting Our Searches
- Analytics
- Tutorial Conclusion
- Distributed Nature
- Next Steps
- Life Inside a Cluster
- Data In, Data Out
- What Is a Document?
- Document Metadata
- Indexing a Document
- Retrieving a Document
- Checking Whether a Document Exists
- Updating a Whole Document
- Creating a New Document
- Deleting a Document
- Dealing with Conflicts
- Optimistic Concurrency Control
- Partial Updates to Documents
- Retrieving Multiple Documents
- Cheaper in Bulk
- Distributed Document Store
- Searching—The Basic Tools
- Mapping and Analysis
- Full-Body Search
- Sorting and Relevance
- Distributed Search Execution
- Index Management
- Inside a Shard
- You Know, for Search…
- Search in Depth
- Structured Search
- Full-Text Search
- Multifield Search
- Proximity Matching
- Partial Matching
- Controlling Relevance
- Theory Behind Relevance Scoring
- Lucene’s Practical Scoring Function
- Query-Time Boosting
- Manipulating Relevance with Query Structure
- Not Quite Not
- Ignoring TF/IDF
- function_score Query
- Boosting by Popularity
- Boosting Filtered Subsets
- Random Scoring
- The Closer, The Better
- Understanding the price Clause
- Scoring with Scripts
- Pluggable Similarity Algorithms
- Changing Similarities
- Relevance Tuning Is the Last 10%
- Dealing with Human Language
- Aggregations
- Geolocation
- Modeling Your Data
- Administration, Monitoring, and Deployment