# ElasticSearch as a blazing fast primary key ticket server **URL:** \ **Category:** Elasticsearch\ **Created:** [October 22, 2011, 2:42pm UTC](https://discuss.elastic.co/t/elasticsearch-as-a-blazing-fast-primary-key-ticket-server/5659 "2011-10-22T14:42:40Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Clinton\_Gormley](https://avatars.discourse-cdn.com/v4/letter/c/50afbb/32.png) [@Clinton\_Gormley](https://discuss.elastic.co/u/Clinton_Gormley)\ **Post date:** [October 22, 2011, 2:42pm UTC](https://discuss.elastic.co/t/elasticsearch-as-a-blazing-fast-primary-key-ticket-server/5659/1 "2011-10-22T14:42:40Z")
Hi all I thought some of you may be interested in a blog post I've just published about how to use ElasticSearch as a primary key ticket server (think auto-increment in MySQL). [http://blogs.perl.org/users/clinton\_gormley/2011/10/elasticsearchsequence---a-blazing-fast-ticket-server.html](http://blogs.perl.org/users/clinton_gormley/2011/10/elasticsearchsequence---a-blazing-fast-ticket-server.html) Using ES as a backend, I can get almost double the performance that I get out of MySQL clint ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [October 22, 2011, 3:56pm UTC](https://discuss.elastic.co/t/elasticsearch-as-a-blazing-fast-primary-key-ticket-server/5659/2 "2011-10-22T15:56:14Z")
Thanks Clint. It's a nice post and shows that we can use ES to do many other things than searches ! To be fast, you write that you have to use bulk. I am wondering if you can also group your mysql calls with only one commit at end and if so, is MySql still "slow" ? BTW, I strongly think that ES will be used in the next years as a primary database and not only for indexes and searches. David 😉 Le 22 oct. 2011 à 16:42, Clinton Gormley [clint@traveljury.com](mailto:clint@traveljury.com) a écrit : > Hi all > > I thought some of you may be interested in a blog post I've just > published about how to use Elasticsearch as a primary key ticket server > (think auto-increment in MySQL). > > [ElasticSearch::Sequence - a blazing fast ticket server | Clinton Gormley [blogs.perl.org]](http://blogs.perl.org/users/clinton_gormley/2011/10/elasticsearchsequence---a-blazing-fast-ticket-server.html) > > Using ES as a backend, I can get almost double the performance that I > get out of MySQL > > clint ---
**Author:** ![Clinton\_Gormley](https://avatars.discourse-cdn.com/v4/letter/c/50afbb/32.png) [@Clinton\_Gormley](https://discuss.elastic.co/u/Clinton_Gormley)\ **Post date:** [October 22, 2011, 4:15pm UTC](https://discuss.elastic.co/t/elasticsearch-as-a-blazing-fast-primary-key-ticket-server/5659/3 "2011-10-22T16:15:49Z")
Hi David > Thanks Clint. It's a nice post and shows that we can use ES to do many other things than searches ! thanks 🙂 > To be fast, you write that you have to use bulk. I am wondering if you > can also group your mysql calls with only one commit at end and if so, > is MySql still "slow" ? According to the MySQL docs: ``` If you insert multiple rows using a single INSERT statement, LAST_INSERT_ID() returns the value generated for the first inserted row only. The reason for this is to make it possible to reproduce easily the same INSERT statement against some other server. ``` > So it looks like the answer is no. But my point wasn't to show that MySQL was slow, but to show that ES can keep up with an already fast solution, and in fact do better. > BTW, I strongly think that ES will be used in the next years as a > primary database and not only for indexes and searches. Yeah - the only thing in the way for me now is the 1 second delay on searching after indexing a doc, ie that is something I have to code around, rather than having it "just work". clint > David 😉 > > Le 22 oct. 2011 à 16:42, Clinton Gormley [clint@traveljury.com](mailto:clint@traveljury.com) a écrit : > > > Hi all > > > > I thought some of you may be interested in a blog post I've just > > published about how to use Elasticsearch as a primary key ticket server > > (think auto-increment in MySQL). > > > > [ElasticSearch::Sequence - a blazing fast ticket server | Clinton Gormley [blogs.perl.org]](http://blogs.perl.org/users/clinton_gormley/2011/10/elasticsearchsequence---a-blazing-fast-ticket-server.html) > > > > Using ES as a backend, I can get almost double the performance that I > > get out of MySQL > > > > clint ---
**Author:** ![Karussell1](https://avatars.discourse-cdn.com/v4/letter/k/50afbb/32.png) [@Karussell1](https://discuss.elastic.co/u/Karussell1)\ **Post date:** [October 23, 2011, 9:26pm UTC](https://discuss.elastic.co/t/elasticsearch-as-a-blazing-fast-primary-key-ticket-server/5659/4 "2011-10-23T21:26:34Z")
> Yeah - the only thing in the way for me now is the 1 second delay on > searching after indexing a doc, ie that is something I have to code > around, rather than having it "just work". Couldn't you use the realtime get feature instead of search for DB- like commands? Regards, Peter. BTW: I blogged about ES as the new kid on the nosql horizont some times ago 😉 > **[Jetslide uses ElasticSearch as Database](https://karussell.wordpress.com/2011/07/13/jetslide-uses-elasticsearch-as-database/)** > > GraphHopper – A Java routing engine karussell ads This post explains how one could use the search server ElasticSearch as a database. I’m using ElasticSearch as my only data storage sys… ---
**Author:** ![Clinton\_Gormley](https://avatars.discourse-cdn.com/v4/letter/c/50afbb/32.png) [@Clinton\_Gormley](https://discuss.elastic.co/u/Clinton_Gormley)\ **Post date:** [October 23, 2011, 10:03pm UTC](https://discuss.elastic.co/t/elasticsearch-as-a-blazing-fast-primary-key-ticket-server/5659/5 "2011-10-23T22:03:07Z")
Hi Peter On Sun, 2011-10-23 at 14:26 -0700, Karussell wrote: > > Yeah - the only thing in the way for me now is the 1 second delay on > > searching after indexing a doc, ie that is something I have to code > > around, rather than having it "just work". > > Couldn't you use the realtime get feature instead of search for DB- > like commands? You can't use get when you don't know what you're getting. A simple example is: the user adds a new comment, you return the page, showing all comments (which should include the new comment left by the user). A simple query won't include your newly added comment (or might, depending on whether the index was refreshed automatically or not). Instead you need to include the newly added comment in the list manually. I haven't yet thought through all the consequences of this 1 second delay - they may all be as simple as the example I give above, but maybe not. In my current framework, I use memcached in front of the database, so there is an added complication of cache expiry of collections when adding new objects. Some queries are frequently used, and faster to return from memcached than from the DB. As fast as ES is, the same may be true when using just ES as your datastore. Perhaps not. I very much doubt that doing a query in ES can be as fast as getting cached results from memcached. But maybe it is fast enough (and scalable enough) to allow me to remove memcached from the infrastructure. If so, that would really simplify the architecture: no RDBM, no memcached, no cache expiry. But my gut instinct says that there is always likely to be a role for caching. I'm definitely going down the route of using ES as my only data store for my next application, so I'll report back my experiences when I've collected them 🙂 clint ---
**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/elasticsearch-as-a-blazing-fast-primary-key-ticket-server/5659/6 "2017-07-06T03:51:07Z")