In the beginning of the book, we discussed that Elasticsearch uses the so called inverted index data structure to quickly and efficiently search through the documents. This is very good when searching and filtering the data, but for features such as aggregations, sorting, or script usage, Elasticsearch needs an un-inverted data structure, because these functions rely on per document data information.

Because of the need for uninverted data, when Elasticsearch was first released it contained and still contains an in memory data structure called fielddata. Fielddata is used to store all the values of a given field to memory to provide very fast document based lookup. However, the cost of using fielddata is memory and increased garbage collection. Because of memory and performance cost, starting from Elasticsearch 2.0, each indexed, not analyzed field uses doc values by default. Other fields, such as analyzed text fields, still use fielddata and because of that it is good to know how to handle fielddata.

As we already discussed, instead of fielddata cache, doc values can be used. Of course, this is only true for not analyzed fields and ones using numeric data types and not multivalued ones. This will save memory and should be faster than the fielddata cache during query time, at the cost of slight indexing speed degradations (very small) and a slightly larger index. If you can use doc values, do that – it will help your Elasticsearch cluster to maintain stability and respond to queries quickly.

The first of the caches that operates on the queries. The shard request cache caches the aggregations and suggestions resulted by the query, but, when writing this book, it was not caching query hits. When Elasticsearch executes the query, this cache can save the resource consuming aggregations for the query and speed up the subsequent queries by retrieving the aggregations or suggestions from memory.

The shard request cache, as its name says, caches the results of the queries on each shard, before they are returned to the node that aggregates the results. This can be very good when your aggregations are heavy, like the ones that do a lot of computation on the data returned by the query. If you run a lot of aggregations with your queries and the queries can be repeated, think about using the shard request cache as it should help you with queries latency.

curl -XPUT 'localhost:9200/new_library' -d '{
 "settings": {
  "index.requests.cache.enable": true
 }
}'

curl 'localhost:9200/_stats/request_cache?pretty'

curl 'localhost:9200/_nodes/stats/indices/request_cache?pretty'

The node query cache is responsible for holding the results of queries for the whole node. Its size is defined using indices.queries.cache.size, defaulting to 10%, and is sharable across all the shards present on the node. We can set it both to the percentage of the heap memory given to Elasticsearch, like the default one, or to an explicit value, like 1024mb. One thing to remember about the cache is that its configuration is static, it can't be updated dynamically and should be set in the elasticsearch.yml file. The node query cache uses the least recent used eviction policy, which means that, when full, it removes the data that was used the least.

This cache is very useful when you run queries that are repetetive and heavy, such as the ones used to generate category pages or the main page in an e-commerce application.

The last cache we want to discuss is the indexing buffer that allows us to improve indexing throughput. The indexing buffer is divided between all the shards on the node and is used to store newly indexed documents. Once the cache fills up, Elasticsearch flushes the data from the cache to disk, creating a new Lucene segment in the index.

There are four static properties that allow us to configure the indexing buffer size. They need to be set in the elasticsearch.yml file and can't be changed dynamically using the Settings API. These properties are:

When it comes to indexing performance, if you need higher indexing throughput, consider setting the indexing buffer size to a value higher than the default size. It will allow Elasticsearch to flush the data to disk less often and create fewer segments. This will result in less merges, thus less I/O and CPU intensive operations. Because of that, Elasticsearch will be able to use more resources for indexing purposes.

The usual question that may be asked by users is if they should really cache all their requests. The answer is obvious – of course, caches are not the tool for everyone. Using caching is not free – it requires memory and additional operations to put the data to cache or get the data out of there.

What's more, you should remember that Elasticsearch round robins queries between primary shards are replicas, so, if you have replicas, not every request after the first one will use the cache. Imagine that you have an index which has a single primary shard and two replicas. When the first request comes, it will hit a random shard, but the next request, even with the same query, will hit another shard, not the same one (unless routing is used). You should take this into consideration when using caches, because if your queries are not repeated, you may have them running longer because of a cache being used.

So to answer the question if you should use caching or not, we would advise taking your data, taking your queries, and running performance tests using tools such as JMeter (http://jmeter.apache.org). This will let you see how your cluster behaves with real data under a test load and see if the queries are actually faster with or without the caches.