# Using ElasticSearch as a Object Cache **URL:** \ **Category:** Elasticsearch\ **Created:** [December 4, 2012, 9:05pm UTC](https://discuss.elastic.co/t/using-elasticsearch-as-a-object-cache/9939 "2012-12-04T21:05:30Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Andy\_3](https://avatars.discourse-cdn.com/v4/letter/a/c57346/32.png) [@Andy\_3](https://discuss.elastic.co/u/Andy_3)\ **Post date:** [December 4, 2012, 9:05pm UTC](https://discuss.elastic.co/t/using-elasticsearch-as-a-object-cache/9939/1 "2012-12-04T21:05:30Z")
We use ElasticSearch to supplement our large legacy DB, and the search features are nice. However we also just need a fast object cache. I'm curious anyone else use ElasticSearch as a cache, like as a replacement for memcached or ehcache. Any advice on optimizing an index to act like a cache, is it possible to configure an expulsion policy? I think a memory store would be best probably. Thanks in advance! -- ---
**Author:** ![Ivan](https://avatars.discourse-cdn.com/v4/letter/i/df788c/32.png) [@Ivan](https://discuss.elastic.co/u/Ivan)\ **Post date:** [December 4, 2012, 9:55pm UTC](https://discuss.elastic.co/t/using-elasticsearch-as-a-object-cache/9939/2 "2012-12-04T21:55:50Z")
I use caches to cache Elasticsearch data, so that should tell you what I think. 🙂 Search engines are databases with one important extra feature: scoring. Documents are returned sorted according to their score. Take away scoring/ordering and I do not see a use case for a search engine. Of course, if you already have ES up and running, it might be easier to use existing technology and not use another stack, but I would look into memcached, ehcache or even Redis. Cheers, Ivan On Tue, Dec 4, 2012 at 1:05 PM, Andy [apryor48@gmail.com](mailto:apryor48@gmail.com) wrote: > We use Elasticsearch to supplement our large legacy DB, and the search > features are nice. However we also just need a fast object cache. I'm > curious anyone else use Elasticsearch as a cache, like as a replacement > for memcached or ehcache. Any advice on optimizing an index to act like a > cache, is it possible to configure an expulsion policy? I think a memory > store would be best probably. > > Thanks in advance! > > -- -- ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [December 5, 2012, 1:01am UTC](https://discuss.elastic.co/t/using-elasticsearch-as-a-object-cache/9939/3 "2012-12-05T01:01:27Z")
Elasticsearch is not a cache, but it can be configured for similar fast response times. - much RAM, large heap, large direct memory - index type memory, force RAM resident process with mlockall() - restrict yourself to relativeley small & simple docs (not MB size) - rare inserts/updates (compared to number of requests) So, with the data in the index not exceeding your resources, almost all disk accesses and almost all the serialization overhead can be eliminated, and as a result, you would have something like a "memory object cache". There are of course challenges unknown to memcached and the like. If you have a common Elasticsearch workload with ingests and queries on the Elasticsearch cluster beside such a "cache", the cache construction tends to get trashed in favor of Lucene doing indexing and search. It is a bit harder to persuade Lucene not to do what it was invented for, that is, building an inverted index and doing fast search 🙂 But the future is bright, with the DocValues feature of the Lucene 4 codec framework - here is a great presentation of Simon Willnauer - > **[DocValues aka. Column Stride Fields in Lucene 4.0 - By Willnauer Simon](https://de.slideshare.net/lucenerevolution/willnauer-simon-doc-values-column-stride-fields-in-lucene)** > > See conference video - https://www.lucidimagination.com/devzone/events/conferences/revolution/2011 Lucene 4.0 is on its way to deliver a tremendous amount of ne… key/value structured data will perform better, together with efficient value updating. Lucene is no longer forced to reindex the whole document again. In most cases, you will be able to store/fetch simple values from Elasticsearch DocValue fields very fast like if it was a memory cache. Ivan pointed to Redis. Lucene codecs will be very powerful. Some people were curious, they even have started a Lucene 4 codec with Redis as a backend > **[Updating individual fields in Lucene with a Redis-backed codec -](http://www.flax.co.uk/blog/2012/06/22/updating-individual-fields-in-lucene-with-a-redis-backed-codec/)** > > A customer of ours has a potential search application which requires (largely for reasons of performance) the ability to update specific individual fields of Apache Lucene documents. This is not the first time that someone has asked for this... Note, a simple eviction policy is available in Elasticsearch on document level by the ttl field mechanism. Internally, it works like an automatic bulk delete, triggered once a minute or so. [http://www.elasticsearch.org/guide/reference/mapping/ttl-field.html](http://www.elasticsearch.org/guide/reference/mapping/ttl-field.html) Cheers, Jörg -- ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 3:01am UTC](https://discuss.elastic.co/t/using-elasticsearch-as-a-object-cache/9939/4 "2017-07-06T03:01:28Z")