Caching vs Indexing

Question

What's the real difference between a caching solution and an indexing solution? It seems to me that an indexing solution is in fact caching with the ability to run search queries (like: Elastic Search). Would there ever be any real reason to use both a caching solution and indexing solution within the same project or does the indexing solution basically make any other caching redundant?

Example: Say I use NEST for ElasticSearch, which would store and return POCOs; if I then query ElasticSearch and have the POCO returned to me, isn't that considered to be using a cached object returned from ElasticSearch?

At the moment, I store data in a cache using an ICacheManager interface I have.. something like this:

return CacheManager.Get(cacheKey, () =>
{
    // return something...
});

Would this become redundant with ElasticSearch?

EDIT

Thanks to all of you for the answers. I am fully aware of what a cache is and already understood the general idea behind an index for textual searching, so I was only really wondering whether the index doubles as a cache already and would therefore make any other cache redundant. After all, I wouldn't want to keep 2 caches in memory (example: ElasticSearch + Redis) when one would do fine. I think I have a better idea now though; especially when I realized that not all fields are always stored in the index and so therefore we need to get the object from a cache or direct from the db anyway - at least in some cases. Thanks all!

given this was asked more than a year ago, I'd be interested to find out whether you have explored ES as a caching solution. — Mark, Jul 26 '17 at 19:42

score 27 · Accepted Answer · answered Dec 21 '15 at 05:45

The whole purpose of a cache is to return already requested data as fast as possible. One constraint of caches is that they cannot be too big either as the lookup time would increase and thus defeat the purpose of having a cache in the first place. That being said, it comes as no surprise that if you plan to have a few million/billion records in your DB, it won't be difficult to index them all but it will be difficult to cache them all, though since RAM is getting cheaper and cheaper, you might be able to store all you need in memory. You also need to ask yourself whether your cache needs to be distributed across several hosts or not (whether now or in the future).

Considering that lookups and queries in ES are extremely fast (+ ES brings you many more benefits in addition to that, such as scoring), i.e. usually faster than retrieving the same data from your DB, it would make sense to use ES as a cache. One issue I see is a common one, i.e. as soon as you start duplicating data (DB -> ES), you need to ensure that both stores don't get out of synch.

Now, if in addition you throw a cache into that mix, it's a third data store to maintain and to ensure is consistent with the main data store. If you know your data is pretty stable, i.e. written and then not updated frequently, then that might be ok, but you need to keep this very concern in mind all the time when designing your data access strategy.

As @paweloque said, in the end it all depends on your exact use case(s). Every problem is different and I can attest that after a few dozen projects around ES over the past five years or so, I've never seen two projects configured the same way. A cache might make sense for some specific cases, but not at all for others.

You need to think hard how and where you need to store your data, who is requesting them (and at what rate), who is creating/updating them (and at what rate), but in the end, the best practice is to keep your stack as lean as possible with only as few components as needed, each one being a potential bottleneck that you have to understand, integrate, maintain, tune and monitor.

Finally, I'd add one more thing: adding a cache or an index should be considered a performance optimization of your software stack. As you probably know the common saying "Premature optimization is root of all evil", you should first go with your database only, measure the performance, load test it, then witness that it might not support the load. Then only, you can decide to throw a cache at it and/or an index depending on the needs. Again, load test, measure, then decide. If you only have ten users making a few requests per day, having only a DB might be perfectly fine. You have to understand when and why you need to add another layer on your Tower of Babel, but most importantly you need to add one layer at a time and see how that layer improves/degrades the stability of the stack.

Last but not least, you can find some online articles from people having used ES as caches (mainly key-value stores, and object caches).

hi Val, i am also thinking of the same question. My use case is for autocomplete, like google's search, whenever a person types, it queries ES for results. Do you think it is beneficial to add redis caching layer in the middle of this? — user1955934, Jun 17 '20 at 23:42
@user1955934 not really because the [completion suggester](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-suggesters.html#completion-suggester) is optimized for speed and the completion data is stored in-memory in an [FST](https://en.wikipedia.org/wiki/Finite-state_transducer) (Finite State Transducer). An [old article](https://www.elastic.co/blog/you-complete-me) explains how the completion data is different from data that is indexed in the inverted index. Also read this: https://stackoverflow.com/a/51085473/4604579 — Val, Jun 18 '20 at 03:15
adding redis caching layer would save work for ES, is it worth it? do we just scale ES if we need to scale up? — user1955934, Jun 18 '20 at 09:34
@user1955934 Read my post again: "Premature optimization is root of all evil". You should first try without and then optimize if necessary as it doesn't make sense to optimize something that you don't know how to optimize and why. — Val, Jun 18 '20 at 10:01

score 9 · Answer 2 · edited Apr 05 '23 at 21:33

Your question:

Q. What's the real difference between a caching solution and an indexing solution?

A. The simple difference is that cache is used to store frequently used data to serve the same requests faster. In essence your cache is faster than your main store but is lower in size, therefore, data it can store (considering the common that it would be more expensive)

Indexing is made on all of the data to make it searchable faster. A simple Hashtable/HashMap have hashes as indexes and in an Array the 0s and 1s are the indexes.

You can index some columns to search them faster. But cache is the place you would want to have your data to fetch them faster. Normally Cache is the RAM and database is from HardDisk

Cache is also usually a key value store so if you know the key then fetch it from the cache, no need to run a query. In NHibernate and EntityFrameworks, Query caches are plugged in with queries as keys and all the data is cached. Now your queries will be fetched from the cache instead of running it through the database.

All Data or data being added to index which is searched frequently ? — Chang Zhao, Dec 04 '18 at 02:48

score 2 · Answer 3 · edited Apr 05 '23 at 21:34

2

Interesting question! Well you could indeed use elasticsearch to implement a cache. It provides some functions with witch you can expire documents, but I'm not sure whether they are well suited to expire the cache. The problem is that elasticsearch is not built to be a caching solution. Its sweet spot is indexing and finding documents.

Indexing is the task of building an index, like it is done for the books: You read the entire text and write down on which page the words were found. This allows us later to find the positions of the words in the text very fast.

Elasticsearch provides a toolbox that will allow you to define how to index and process the text, i.e. apply stemming. Then in the next step, it will provide you different types of queries to find your documents.

You could, however, write documents into elasticsearch and use the id of the document to read it. Like that you could use elasticsearch as a store which might be used as a cache.

edited Apr 05 '23 at 21:34

danronmoon

3,814
5
34
56

answered Dec 20 '15 at 22:01

paweloque

18,466
26
80
136

Thanks. I do understand the point of an index is for searching; the only thing that's unclear is whether it makes caching redundant or not. What is generally done? I can think of 3 possibilities: 1. DB -> Cache -> Search Index 2. DB -> Search Index -> Cache 3. DB -> Search Index (ignore any other cache) So I am really trying to decide if a cache is needed at all and if so, would it be the search index querying the cache or the cache querying the search index? – Matt Dec 20 '15 at 22:06
If using both together, of course for complex queries we'd go directly to the search engine.. but when retrieving by ID, I'm not sure if we should go to the cache first (which would query the index) or the index which would query the cache – Matt Dec 20 '15 at 22:08
I just had a thought: is it the case that the search engine is ONLY used for complex querying (full-text search) and that the traditional caching would be used for returning objects by ID? – Matt Dec 20 '15 at 22:11
You can use elastic as a cache to the db. Store data in elasticsearch, e.g. for a tabular display of the results. Then if you need more data for a detail view, you can get it from the db. It very much depends on your exact use cases. – paweloque Dec 20 '15 at 22:14

Caching vs Indexing

3 Answers3

Linked