# Replacing redis with elasticsearch (GET query speed, counters and lists)? **URL:** \ **Category:** Elasticsearch\ **Created:** [October 16, 2011, 9:20pm UTC](https://discuss.elastic.co/t/replacing-redis-with-elasticsearch-get-query-speed-counters-and-lists/5609 "2011-10-16T21:20:50Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![datadev](https://avatars.discourse-cdn.com/v4/letter/d/ea5d25/32.png) [@datadev](https://discuss.elastic.co/u/datadev)\ **Post date:** [October 16, 2011, 9:20pm UTC](https://discuss.elastic.co/t/replacing-redis-with-elasticsearch-get-query-speed-counters-and-lists/5609/1 "2011-10-16T21:20:50Z")
I am currently considering replacing redis with elasticsearch to simplify the stack and have run into the following 3 use cases: 1. I am currently using redis for caching. Redis is benchmarked at around 100,000 GETs per second when querying by key ([http://redis.io/](http://redis.io/) topics/benchmarks). How does ES stack in terms simple GET by \_id performance (assuming real-time get)? 2. I am currently using redis to store counters (EG: 'foo = foo + 1280' types of commands). Is there any way to implement the concept of counters in ES with support atomic updates (maybe using the script command)? 3. I am currently using redis to store lists for queuing use cases (in which items are added to a list and then popped off). Can something like that be effectively implemented in ES? Thanks and keep up the great work! ---
**Author:** ![karmi](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/karmi/32/44951_2.png) [@karmi](https://discuss.elastic.co/u/karmi)\ **Post date:** [October 17, 2011, 6:08am UTC](https://discuss.elastic.co/t/replacing-redis-with-elasticsearch-get-query-speed-counters-and-lists/5609/2 "2011-10-17T06:08:19Z")
In all three points you mention: GET, INCRBY, atomic LPOP, I'd consider Redis superior to Elasticsearch. I wouldn't get rid of Redis just to "simplify the stack". There's always something where Redis fits as a glove. (And I love Elasticsearch as much as Redis, possible more 🙂 Karel On Oct 16, 11:20 pm, datadev [n...@adinfocenter.com](mailto:n...@adinfocenter.com) wrote: > I am currently considering replacing redis with elasticsearch to > simplify the stack and have run into the following 3 use cases: > > 1. I am currently using redis for caching. Redis is benchmarked at > around 100,000 GETs per second when querying by key ([http://redis.io/](http://redis.io/) > topics/benchmarks). How does ES stack in terms simple GET by \_id > performance (assuming real-time get)? > > 2. I am currently using redis to store counters (EG: 'foo = foo + > 1280' types of commands). Is there any way to implement the concept of > counters in ES with support atomic updates (maybe using the script > command)? > > 3. I am currently using redis to store lists for queuing use cases (in > which items are added to a list and then popped off). Can something > like that be effectively implemented in ES? > > Thanks and keep up the great work! ---
**Author:** ![Karussell1](https://avatars.discourse-cdn.com/v4/letter/k/50afbb/32.png) [@Karussell1](https://discuss.elastic.co/u/Karussell1)\ **Post date:** [October 17, 2011, 3:12pm UTC](https://discuss.elastic.co/t/replacing-redis-with-elasticsearch-get-query-speed-counters-and-lists/5609/3 "2011-10-17T15:12:54Z")
the third one could be handled with one index (instead of the list) and using the \_version field to avoid problems (can be used to solve point 2 as well) when adding or deleting items and sort against a timestamp or similar. the other mentioned points are probably better implemented with redis (there are no transactions in ES) ... you could try point 1 with ES: but even with a ids-request > **[Elasticsearch Platform — Find real-time answers at scale](https://www.elastic.co)** > > Power insights and outcomes with the Elasticsearch Platform and AI. See into your data and find answers that matter with enterprise solutions designed to help you build, observe, and protect. Try Elasticsearch free today. 100k req/sec seems to be high 🙂 of course all depends on a lot things e.g. putting it all into RAM ... let me know how it compares 🙂 ! On 17 Okt., 08:08, karmi [karel.mina...@gmail.com](mailto:karel.mina...@gmail.com) wrote: > In all three points you mention: GET, INCRBY, atomic LPOP, I'd > consider Redis superior to Elasticsearch. > > I wouldn't get rid of Redis just to "simplify the stack". There's > always something where Redis fits as a glove. > > (And I love Elasticsearch as much as Redis, possible more 🙂 > > Karel > > On Oct 16, 11:20 pm, datadev [n...@adinfocenter.com](mailto:n...@adinfocenter.com) wrote: > > > I am currently considering replacing redis with elasticsearch to > > simplify the stack and have run into the following 3 use cases: > > > 1. I am currently using redis for caching. Redis is benchmarked at > > around 100,000 GETs per second when querying by key ([http://redis.io/](http://redis.io/) > > topics/benchmarks). How does ES stack in terms simple GET by \_id > > performance (assuming real-time get)? > > > 1. I am currently using redis to store counters (EG: 'foo = foo + > > 1280' types of commands). Is there any way to implement the concept of > > counters in ES with support atomic updates (maybe using the script > > command)? > > > 1. I am currently using redis to store lists for queuing use cases (in > > which items are added to a list and then popped off). Can something > > like that be effectively implemented in ES? > > > Thanks and keep up the great work! ---
**Author:** ![datadev](https://avatars.discourse-cdn.com/v4/letter/d/ea5d25/32.png) [@datadev](https://discuss.elastic.co/u/datadev)\ **Post date:** [October 18, 2011, 6:46am UTC](https://discuss.elastic.co/t/replacing-redis-with-elasticsearch-get-query-speed-counters-and-lists/5609/4 "2011-10-18T06:46:09Z")
Yes I think using an ES index in association with version should be able to implement a redis-style list. In regards to #2 (implementing an atomic counter), according to [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/reference/api/index_.html) - this seems to imply that it is only possible to pass in a REPLACEMENT version value for the current version value, instead of a positive or negative # to that be added to the existing version number. Or, is there a way in which an increment by X (EG: +200, -150, etc...) can be done? On Oct 17, 11:12 am, Karussell [tableyourt...@googlemail.com](mailto:tableyourt...@googlemail.com) wrote: > the third one could be handled with one index (instead of the list) > and using the \_version field to avoid problems (can be used to solve > point 2 as well) when adding or deleting items and sort against a > timestamp or similar. > > the other mentioned points are probably better implemented with redis > (there are no transactions in ES) ... you could try point 1 with ES: > but even with a ids-request > > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/reference/query-dsl/ids-query.html) > > 100k req/sec seems to be high 🙂 of course all depends on a lot things > e.g. putting it all into RAM ... let me know how it compares 🙂 ! > > On 17 Okt., 08:08, karmi [karel.mina...@gmail.com](mailto:karel.mina...@gmail.com) wrote: > > > In all three points you mention: GET, INCRBY, atomic LPOP, I'd > > consider Redis superior to Elasticsearch. > > > I wouldn't get rid of Redis just to "simplify the stack". There's > > always something where Redis fits as a glove. > > > (And I love Elasticsearch as much as Redis, possible more 🙂 > > > Karel > > > On Oct 16, 11:20 pm, datadev [n...@adinfocenter.com](mailto:n...@adinfocenter.com) wrote: > > > > I am currently considering replacing redis with elasticsearch to > > > simplify the stack and have run into the following 3 use cases: > > > > 1. I am currently using redis for caching. Redis is benchmarked at > > > around 100,000 GETs per second when querying by key ([http://redis.io/](http://redis.io/) > > > topics/benchmarks). How does ES stack in terms simple GET by \_id > > > performance (assuming real-time get)? > > > > 1. I am currently using redis to store counters (EG: 'foo = foo + > > > 1280' types of commands). Is there any way to implement the concept of > > > counters in ES with support atomic updates (maybe using the script > > > command)? > > > > 1. I am currently using redis to store lists for queuing use cases (in > > > which items are added to a list and then popped off). Can something > > > like that be effectively implemented in ES? > > > > Thanks and keep up the great work! ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [October 18, 2011, 5:03pm UTC](https://discuss.elastic.co/t/replacing-redis-with-elasticsearch-get-query-speed-counters-and-lists/5609/5 "2011-10-18T17:03:08Z")
Heya, Well, elasticsearch will definitely be slower than redis, by how much its hard to say. Realtime get is pretty fast, but still goes to disk. Versioning can be used to implement atomic updates. You can get the document you want, change it, and try and index it back with the version you got, if it succeeds, all is well, if not, you need to retry. Note though, that the whole document needs to be reindexed... On Tue, Oct 18, 2011 at 8:46 AM, datadev [nji@adinfocenter.com](mailto:nji@adinfocenter.com) wrote: > Yes I think using an ES index in association with version should be > able to implement a redis-style list. > > In regards to #2 (implementing an atomic counter), according to > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/reference/api/index_.html) - this > seems to imply that it is only possible to pass in a REPLACEMENT > version value for the current version value, instead of a positive or > negative # to that be added to the existing version number. Or, is > there a way in which an increment by X (EG: +200, -150, etc...) can be > done? > > On Oct 17, 11:12 am, Karussell [tableyourt...@googlemail.com](mailto:tableyourt...@googlemail.com) wrote: > > > the third one could be handled with one index (instead of the list) > > and using the \_version field to avoid problems (can be used to solve > > point 2 as well) when adding or deleting items and sort against a > > timestamp or similar. > > > > the other mentioned points are probably better implemented with redis > > (there are no transactions in ES) ... you could try point 1 with ES: > > but even with a ids-request > > > > [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/reference/query-dsl/ids-query.html) > > > > 100k req/sec seems to be high 🙂 of course all depends on a lot things > > e.g. putting it all into RAM ... let me know how it compares 🙂 ! > > > > On 17 Okt., 08:08, karmi [karel.mina...@gmail.com](mailto:karel.mina...@gmail.com) wrote: > > > > > In all three points you mention: GET, INCRBY, atomic LPOP, I'd > > > consider Redis superior to Elasticsearch. > > > > > I wouldn't get rid of Redis just to "simplify the stack". There's > > > always something where Redis fits as a glove. > > > > > (And I love Elasticsearch as much as Redis, possible more 🙂 > > > > > Karel > > > > > On Oct 16, 11:20 pm, datadev [n...@adinfocenter.com](mailto:n...@adinfocenter.com) wrote: > > > > > > I am currently considering replacing redis with elasticsearch to > > > > simplify the stack and have run into the following 3 use cases: > > > > > > 1. I am currently using redis for caching. Redis is benchmarked at > > > > around 100,000 GETs per second when querying by key ( > > > > [http://redis.io/](http://redis.io/) > > > > topics/benchmarks). How does ES stack in terms simple GET by \_id > > > > performance (assuming real-time get)? > > > > > > 1. I am currently using redis to store counters (EG: 'foo = foo + > > > > 1280' types of commands). Is there any way to implement the concept > > > > of > > > > counters in ES with support atomic updates (maybe using the script > > > > command)? > > > > > > 1. I am currently using redis to store lists for queuing use cases > > > > (in > > > > which items are added to a list and then popped off). Can something > > > > like that be effectively implemented in ES? > > > > > > Thanks and keep up the great work! ---
**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:51am UTC](https://discuss.elastic.co/t/replacing-redis-with-elasticsearch-get-query-speed-counters-and-lists/5609/6 "2017-07-06T03:51:34Z")