ElasticSearch::Sequence - a blazing fast ticket server

I'm considering ditching my RDBM for my next application and using ElasticSearch as my only data store.

My home-grown framework uses unique IDs for all objects, which currently come from a MySQL auto-increment column, and my framework expects the unique ID to be an integer.

ElasticSearch has its own unique auto-generated IDs, but:

they look like this 'KpSb_Jd_R56dH5Qx6TtxVA' and I'd say are less human-readable than an integer

I would need to change a fair bit of legacy code to migrate to non-integer IDs

Initially I thought I could keep MySQL around as a ticket server, as described by Flickr but then I wondered if I could achieve the same thing by abusing ElasticSearch's built-in versioning, allowing me to ditch MySQL completely, and give me a distributed ticket server with high availability into the bargain.

The logic is simple: when you index a document in ElasticSearch, it returns a new version number for the document, which is always incrementing and is guaranteed to be unique across the cluster.

ElasticSearch enables a bunch of features by default, which are very useful for using it as a document store and a full text search server, but aren't relevant in this situation, and will just slow it down.

The amount of data will tiny, so our index only needs one primary shard, not the 5 that are created by default in ElasticSearch. But for high-availability purposes, we'd like this shard to be replicated across all nodes in our cluster. So the index settings look like this:

For the type mapping (like a schema in a database) we want to turn off the _all field and _source field, disable _type indexing, and disable indexing for the document (which is only ever going to be an empty hashref):

Requesting a single ID (indexing the doc to get a new version) at a time is going to be relatively slow, as there is a fair bit of HTTP latency per request. This is fine for normal use, but our ticket server has to be super fast.

So instead, I'm going to request several new version numbers at once using the bulk API, and buffer them.

If you are already using ElasticSearch as your search server, (and if you're not, you should be - it's fantastic), and you're currently using your DB as a ticket server, I'd consider moving this function over to ElasticSearch instead.