Generating sortable unique ID(primary key) across the cluster in an entity-relationship model

Using FoundationDB
1

I am very new to FDB, and trying to understand what is the recommended strategy to generate sortable IDs across the cluster.

Say, for example, I want to create an entity-relationship model on top of FDB. For each entity I would like to assign a sortable unique ID(primary key) across a cluster. What is the idiomatic way of generating this ID for FDB? Or does FDB provide a way to request a sortable unique ID from the cluster that can be used as a primary key of an entity?

2

It depends what you need… If you need something unique that preserves insert ordering you can use a version stamp. You could also use an atomic op to just have a counter, but that might generate a hot key which is non-optimal. Read-modify-write is also possible, but due to concurrency control it will limit your throughput and is only a good option for low-throughput workloads. So in most cases I would say using a version stamp is the best option.

3

Thank you for the reply.

Please could you point me to an example on how to use version stamp for primary key?

4

You can do that with an atomic operation (look for Transaction.set_versionstamped_key(key, param) in the documentation),

5

From what I understand, when using versionstamp, we need to be careful if our transaction block is non-idempotent. Quoting from this link,

Avoid generating IDs within the retry loop. Instead, create them prior to the loop and pass them in. For example, if your transaction records an account deposit with a deposit ID, generate the deposit ID outside of the loop.

So, when creating a primary key for the entity that contains a versionstamp, I think you will need to factor in the possibility that you could have two primary keys referring to the same entity, if the transaction retried when the entity was created.

6

I would just use an id generator that is independent of commit versions, like GitHub - f4b6a3/tsid-creator: A Java library for generating Time-Sorted Unique Identifiers (TSID). or Twitter’s snowflake algorithm, which are sorted by creation time. If you do not use auto-generated ids, it is easier to write tests too.