One of the simplest queries that can be run is a query matching documents in a given range of values. Usually, such queries are a part of a larger query or a filter. For example, a query that would return books with the number of copies from 1 to 3 inclusive would look as follows:

curl -XGET 'localhost:9200/library/_search?pretty' -d '{
 "query" : {
  "range" : {
   "copies" : {
    "gte" : 1,
    "lte" : 3
   }
  }
 }
}'

Imagine a situation where your users can show a number of tags the books returned by what the query should contain. The thing is that we require only 75 percent of the provided tags to be matched if the number of tags provided by the user is higher than three, and all the provided tags to be matched if the number of tags is three or less. We could run a bool query to allow that, but Elasticsearch provides us with the terms query that we can use to achieve the same requirement. The command that sends such query looks as follows:

curl -XGET 'localhost:9200/library/_search?pretty' -d '{
 "query" : {
  "terms" : {
   "tags" : [ "novel", "polish", "classics", "criminal", "new" ],
   "minimum_should_match" : "3<75%"
  }
 }
}'

One of the simplest examples is using the bool query to boost some documents by including not mandatory query part that is used for boosting. For example, if we would like to find all the books that have at least a single copy and boost the ones that are published after 1950, we could use the following query:

curl -XGET 'localhost:9200/library/_search?pretty' -d '{
 "query" : {
  "bool" : {
   "must" : [
    { 
     "range" : {
      "copies" : {
       "gte" : 1
      } 
     }
    }
   ],
   "should" : [
    {
     "range" : {
      "year" : {
       "gt" : 1950
      }
     }
    }
   ]
  }
 }
}'

The dis_max query, as we have already covered, allows us to control how influential the lower scoring partial queries are. For example, if we only want to assign the score of the highest scoring partial query for the documents matching crime punishment in the title field or raskolnikov in the characters field, we would run the following query:

curl -XGET 'localhost:9200/library/_search?pretty' -d '{
 "fields" : [ "_id", "_score" ],
 "query" : {
  "dis_max" : {
   "tie_breaker" : 0.0,
   "queries" : [
    {
     "match" : {
      "title" : "crime punishment"
     } 
    },
    {
     "match" : {
      "characters" : "raskolnikov"
     }
    }
   ]
  }
 }
}'

The result for the preceding query should look as follows:

{
  "took" : 3,
  "timed_out" : false,
  "_shards" : {
    "total" : 5,
    "successful" : 5,
    "failed" : 0
  },
  "hits" : {
    "total" : 1,
    "max_score" : 0.2169777,
    "hits" : [ {
      "_index" : "library",
      "_type" : "book",
      "_id" : "4",
      "_score" : 0.2169777,
      "fields" : {
        "_id" : "4"
      }
    } ]
  }
}

Now let's see the score of the partial queries alone. To do that we will run the partial queries using the following commands:

curl -XGET 'localhost:9200/library/_search?pretty' -d '{
 "fields" : [ "_id", "_score" ],
 "query" : {
  "match" : {
   "title" : "crime punishment"
  }
 }
}'

The response for the preceding query is as follows:

{
  "took" : 2,
  "timed_out" : false,
  "_shards" : {
    "total" : 5,
    "successful" : 5,
    "failed" : 0
  },
  "hits" : {
    "total" : 1,
    "max_score" : 0.2169777,
    "hits" : [ {
      "_index" : "library",
      "_type" : "book",
      "_id" : "4",
      "_score" : 0.2169777,
      "fields" : {
        "_id" : "4"
      }
    } ]
  }
}

And the next command is as follows:

curl -XGET 'localhost:9200/library/_search?pretty' -d '{
 "fields" : [ "_id", "_score" ],
 "query" : {
  "match" : {
   "characters" : "raskolnikov"
  }
 }
}'

And the response is as follows:

{
  "took" : 1,
  "timed_out" : false,
  "_shards" : {
    "total" : 5,
    "successful" : 5,
    "failed" : 0
  },
  "hits" : {
    "total" : 1,
    "max_score" : 0.15342641,
    "hits" : [ {
      "_index" : "library",
      "_type" : "book",
      "_id" : "4",
      "_score" : 0.15342641,
      "fields" : {
        "_id" : "4"
      }
    } ]
  }
}

As you can see, the score of the document returned by our dis_max query is equal to the score of the highest scoring partial query (the first partial query). That is because we've set the tie_breaker property to 0.0.

One of the simplest examples of the not analyzed query is the term query provided by Elasticsearch. You'll probably very rarely use the term query alone; however, it may be commonly used in compound queries. For example, let's assume that we would like to search for all the books with the novel value in the tags field. To do that, we would run the following command:

curl -XGET 'localhost:9200/library/_search?pretty' -d '{
 "query" : {
  "term" : {
   "tags" : "novel"
  }
 }
}'

Elasticsearch provides the common terms query, which allows us to handle query time stopwords in an efficient way. It divides the query terms into two groups—more important terms and less important terms. The more important terms are the ones that have a lower frequency; the less important terms are the opposite. Elasticsearch first executes the query with important terms and calculates the score for those documents. Then, a second query with the less important terms is executed, but the score is not calculated and thus the query is faster.

For example, the following two queries should be similar in terms of results, but not in terms of score computation. Please also note that to see the differences in scoring we would have to use a larger data sample and not use index time stopwords:

curl -XGET 'localhost:9200/library/_search?pretty' -d '{
 "query" : {
  "common" : {
   "title" : {
   "query" : "the western front",
   "cutoff_frequency" : 0.1,
   "low_freq_operator": "and"
   }
  }
 }
}'

And the second query would be as follows:

curl -XGET 'localhost:9200/library/_search?pretty' -d '{
 "query" : {
  "bool" : {
   "must" : [
    {
     "term" : { "title" : "western" }
    },
    {
     "term" : { "title" : "front" }
    }
   ],
   "should" : [
    {
     "term" : { "title" : "the" }
    }
   ]
  }
 }
}'

Sometimes, it is good to be able to use Lucene query syntax as it is. We talked about this syntax in the Lucene query language section in Chapter 1, Introduction to Elasticsearch. For example, if we would like to find books having sorrows and young terms in their title, von goethe phrase in the author field and not having more than five copies we could run the following query:

curl -XGET 'localhost:9200/library/_search?pretty' -d '{
 "query" : {
  "query_string" : {
   "query" : "+title:sorrows +title:young +author:"von goethe" - copies:{5 TO *]"
  }
 }
}'

As you can see, we've used the Lucene query syntax to pass all the matching requirements and we've let query parser construct the appropriate query.

Sometimes, queries coming from users can contain errors. For example, let's look at the following query:

curl -XGET 'localhost:9200/library/_search?pretty' -d '{
 "query" : {
  "query_string" : {
   "query" : "+sorrows +young "",
   "default_field" : "title"
  }
 }
}'

The response would contain the following:

"error" : "SearchPhaseExecutionException[Failed to execute phase  [query]

This means that the query was not properly constructed and parse error happened. That's why the simple_query_string query was introduced. It uses a query parser that tries to handle user mistakes and tries to guess how the query should look. Our query using that parser would look as follows:

curl -XGET 'localhost:9200/library/_search?pretty' -d '{
 "query" : {
  "simple_query_string" : {
   "query" : "+sorrows +young "",
   "fields" : [ "title" ]
  }
 }
}'

If you run the preceding query, you would see that the proper document has been returned by Elasticsearch, even though the query is not properly constructed.

A very common use case provides autocomplete functionality on the indexed data. As we know, the prefix query is not analyzed and works on the basis of terms indexed in the field. So the actual functionality depends on what tokens are produced during indexing. For example, let's assume that we would like to provide autocomplete functionality on any token in the title field and the user provided wes prefix. A query that would match such a requirement looks as follows:

curl -XGET 'localhost:9200/library/_search?pretty' -d '{
 "query" : {
  "prefix" : {
   "title" : "wes"
  }
 }
}'

If we need to match a certain pattern and our analysis chain is not producing tokens that allow us to do so, we can turn into the regexp query. One should remember, though, that this kind of query can be expensive during execution and thus should be avoided. Of course, this is not always possible. One thing to remember is that the performance of the regexp query depends on the chosen regular expression. If you choose a regular expression that will be rewritten into a high number of terms, then performance will suffer.

Let's now see the example usage of the regexp query. Let's assume that we would like to find documents that have a term starting with wat, then followed by two characters and ending with the n character, and those terms should be in the characters field. To match this requirement, we could use a regexp query like the one used in the following command:

curl -XGET 'localhost:9200/library/_search?pretty' -d '{
 "query" : {
  "regexp" : {
   "characters" : "wat..n"
  }
 }
}'

A very simple example is using the fuzzy query to find documents having a term similar to a given one. For example, if we would like to find all the documents having a value similar to crimea, we could run the following query:

curl -XGET 'localhost:9200/library/_search?pretty' -d '{
 "query" : {
  "fuzzy" : {
   "title" : {
    "value" : "crimea",
    "fuzziness" : 3,
    "max_expansions" : 50
   }
  }
 }
}'

Another example of similarity queries is a use case when we want to find all the documents having field values similar to what we provided in a query. For example, if we would like to find books having a title similar to the western front battles name, we could run the following query:

curl -XGET 'localhost:9200/library/_search?pretty' -d '{
 "query" : {
  "fuzzy_like_this_field" : {
   "title" : {
    "like_text" : "western front battles",
    "max_query_terms" : 5
   }
  }
 }
}'

The result of the preceding query would be as follows:

{
  "took" : 10,
  "timed_out" : false,
  "_shards" : {
    "total" : 5,
    "successful" : 5,
    "failed" : 0
  },
  "hits" : {
    "total" : 2,
    "max_score" : 1.0162667,
    "hits" : [ {
      "_index" : "library",
      "_type" : "book",
      "_id" : "1",
      "_score" : 1.0162667,
      "_source":{ "title": "All Quiet on the Western  Front","otitle": "Im Westen nichts Neues","author": "Erich  Maria Remarque","year": 1929,"characters": ["Paul B├Ąumer",  "Albert Kropp", "Haie Westhus", "Fredrich M├╝ller",  "Stanislaus Katczinsky", "Tjaden"],"tags":  ["novel"],"copies": 1,
      "available": true, "section" : 3}
    }, {
      "_index" : "library",
      "_type" : "book",
      "_id" : "5",
      "_score" : 0.4375,
      "_source":{"title" : "The Sorrows of Young Werther","author"  : "Johann Wolfgang von Goethe","available" :  true,"characters" : ["Werther","Lotte","Albert","Fraulein  von B"],"copies" : 1, "otitle" : "Die Leiden des jungen  Werthers","section" : 4,"tags" : ["novel",  "classics"],"year" : 1774,"review" : [{"nickname" :  "Anna","text" : "Could be good, but not my style","stars" :  3}]}
    } ]
  }
}

As you can see, sometimes the results are not as obvious as we would expect (look at the second book title). This is because of what Elasticsearch thinks is similar to each other. In the case of the preceding query, Elasticsearch will take all the terms, run a fuzzy search on them, and choose a number of best differentiating terms for documents matching.

Let's assume that we would like to favor books that are newer, so that a book from the year 1986 is higher in the results list than a book from 1870. The query that would match that requirement looks as follows:

curl -XGET 'localhost:9200/library/_search?pretty' -d '{ 
 "query" : {
  "function_score" : {
   "query" : {
    "match_all" : {}
   },
   "score_mode" : "multiply",
   "functions" : [
    {
     "gauss" : {
      "year" : {
       "origin" : 2014,
       "scale" : 2014,
       "offset" : 0,
       "decay": 0.5
      }
     }
    }
   ]
  }
 }
}'

We will discuss the function_score query in Chapter 3, Not Only Full Text Search. For now, if you look at the results returned by the preceding query, you can see that the newer the book, the higher in the results it will be.

Sometimes, it is good to be able to decrease the importance of certain documents, while still showing them in the results list. For example, we may want to show all books, but put the ones that are not available on the bottom of the results list by lowering their score. We don't want sorting on availability because sometimes use may know what he or she is looking for and the score of a full text search query should be also important. However, if our use case is that we want the books that are not available on the bottom of the results list, we could use the following command to get them:

curl -XGET 'localhost:9200/library/_search?pretty' -d '{ 
 "query" : {
  "boosting" : {
   "positive" : {
    "match_all" : {}
   },
   "negative" : {
    "term" : {
     "available" : false
    }
   },
   "negative_boost" : 0.2
  }
 }
}'

The simplest position aware query possible and the most performing one from the queries assigned in this group. For example, a query that would only match document leiden des jungen phrase in the otitle field would look as follows:

curl -XGET 'localhost:9200/library/_search?pretty' -d '{
 "query" : {
  "match_phrase" : {
   "otitle" : "leiden des jungen"
  }
 }
}'

Of course, the phrase query is very simple when it comes to position handling. What if we would like to run a query to find documents that have des jungen phrase not more than two positions after the die term and just before the werthers term? This can be done with span queries, and the following command shows how such a query could look:

curl -XGET 'localhost:9200/library/_search?pretty' -d '{
 "query" : {
  "span_near" : {
   "clauses" : [
    {
     "span_near" : {
      "clauses" : [
       {
        "span_term" : {
         "otitle" : "die"
        }
       },
       {
        "span_near" : {
         "clauses" : [
          {
           "span_term" : {
            "otitle" : "des"
           }
          },
          {
           "span_term" : {
            "otitle" : "jungen"
           }
          }
         ],
         "slop" : 0,
         "in_order" : true
        }
       }
      ],
      "slop" : 2,
      "in_order" : false
     }
    },
    {
     "span_term" : {
      "otitle" : "werthers"
     }
    }
   ],
   "slop" : 0,
   "in_order" : true
  }
 }
}'

Please note that span queries are not analyzed. We can see that by looking at the response of the Explain API. To see that response, we should run the same request body (our query) to the /library/book/5/_explain REST endpoint. The interesting part of the output looks as follows:

"description" : "weight(spanNear([spanNear([otitle:die,  spanNear([otitle:des, otitle:jungen], 0, true)], 2, false),  otitle:werthers], 0, true) in 1) [PerFieldSimilarity], result  of:",

The first example will be a very simple one. Let's return all the books that have at least a single review that was given four stars or more. The query that does that looks as follows:

curl -XGET 'localhost:9200/library/_search?pretty' -d '{
 "query" : {
  "nested" : {
   "path" : "review",
   "query" : {
    "range" : {
     "stars" : {
      "gte" : 4
     }
    }
   }
  }
 }
}'

Let's assume that we want to find all the available books that have reviews and let's sort them on the maximum number of stars given in the review. The query that would fill such a requirement looks as follows:

curl -XGET 'localhost:9200/library/_search?pretty' -d '{
 "query" : {
  "nested" : {
   "path" : "review",
   "score_mode" : "max",
   "query" : {
    "function_score" : {
     "query" : { "match_all" : {} },
     "score_mode" : "max",
     "boost_mode" : "replace",
     "field_value_factor" : {
      "field" : "stars",
      "factor" : 1,
      "modifier" : "none"
     }
    }
   }
  }
 }
}'