Unique integer counter in RethinkDb

Question

Let's say I want to model building some widgets in RethinkDB. The building process starts, get's an unique ID, goes to work for a while, then when it's done writes data in the database under the ID it was given. There are many types of widgets, and the ID should be unique across all of them.

If I were doing it in Postgres, I would probably have one main widget table, with one table per widget type (widget_x, widget_y, etc.) inheriting from that main table. The ID would be a SERIAL type on the main widget table. When the building process starts, I'd insert some data, get my unique ID, start working, and when the building is finished update the table. I probably wouldn't use transactions across the entire process because the building can take a long while.

How would one do this in RethinkDB? I really need the ID to be a increasing integer, so I can't use the default UUID keys. I want each widget type to be in it's own table.

If I do this query before every widget building starts:

r.table("counters")
    .get("some-uuid-key")
    .update({ widget_counter: r.row("widget_counter").add(1) }, {return_vals: true})

will that work as I hope it will, giving me database wide unique ID, without any possibility of a ID conflict?

Thanks...

Answer 1

What you have there will work and is as close to a canonical solution to that problem as I think there is. Globally unique ascending ids are more or less impossible in a clustered environment which is why we don't have them as an option by default. What you have here works because every single request has to go through a single machine to get its id (the master machine for the "counters" table. This has the downside that if that machine dies every query that needs to get an id will start failing.

Answer 2

Having a counters table in the DB has a guarantee of sequence at the cost of better HA (high availability).

If you don't require absolute incremental numbers, just prefer a short integer for records that are publicly exposed, you can also setup a set of ticket servers.. each giving out every Nth number. You will get redundancy and lower numbers to start with, but you won't have a guarantee of order, and may have significant drift over time. I thought about such a system, where each client can also pass the last id that it got... in this way if drift is greater than X, it can skip forward to keep drift in check.

If you have IDs that aren't being exposed (such as on a query string, and even then), I find that UUID is just about the best supported option as a key for most types of database records.