3 ms·

Maybe I'm way off base here, but this seems like a really really niche solution for a situation you probably(?) won't be in for long. You have a single DB runn

Maybe I'm way off base here, but this seems like a really really niche solution for a situation you probably(?) won't be in for long. You have a single DB running on a single machine. But you also care this much about write performance that you need sequential ids. How much longer is that single DB going to work for you, if write performance has become an issue? I wonder. Because soon you might need to shard, which you will lose sequential ids and benefit of spatial locality right? There seems a narrow band of operation where you're seeing the benefit of performance from sequential ids but can still function on a single DB instance. I feel like you may be painting yourself into an architectural corner and a headache rather than just doing the easy thing first and using UUID.

anarazel 4y ago
> You have a single DB running on a single machine. But you also care this much about write performance that you need sequential ids. How much longer is that single DB going to work for you, if write performance has become an issue? Potentially a long time. Anecdotal: I helped a PG user in ~2012 (+- 2 years) to move to some sequential-ish uuid-like thing because they were facing outages, and as of last year they were still using a single instance for that service. And they grew by a lot. > Because soon you might need to shard, which you will lose sequential ids and benefit of spatial locality right? You don't need (not even want) perfect spatial locality. It's ok as long as it's not uniformly random.
chrismorgan 4y ago
Most projects can reasonably and usefully stick with central ID allocation forever. And even if you want to decentralise ID allocation, so long as you still have control over the nodes, you can still use roughly sequential identifiers if you choose, by multiplying by some standard value and offsetting the sequence by a node ID. You could reserve ten least significant bits for a node ID, for example, allowing up to 1024 nodes to generate IDs. So node 0 would allocate IDs {0, 1024, 2048, …}, node 1 {1, 1025, 2049, …}, &c. This requires more planning and possibly more maintenance, but will have the advantage of producing shorter IDs which can be highly desirable. Random IDs do have a place, but they’re massively overrated. The length required to control the collision risk is very significant.

anarazel 4y ago

> You have a single DB running on a single machine. But you also care this much about write performance that you need sequential ids. How much longer is that single DB going to work for you, if write performance has become an issue? Potentially a long time. Anecdotal: I helped a PG user in ~2012 (+- 2 years) to move to some sequential-ish uuid-like thing because they were facing outages, and as of last year they were still using a single instance for that service. And they grew by a lot. > Because soon you might need to shard, which you will lose sequential ids and benefit of spatial locality right? You don't need (not even want) perfect spatial locality. It's ok as long as it's not uniformly random.

chrismorgan 4y ago

Most projects can reasonably and usefully stick with central ID allocation forever. And even if you want to decentralise ID allocation, so long as you still have control over the nodes, you can still use roughly sequential identifiers if you choose, by multiplying by some standard value and offsetting the sequence by a node ID. You could reserve ten least significant bits for a node ID, for example, allowing up to 1024 nodes to generate IDs. So node 0 would allocate IDs {0, 1024, 2048, …}, node 1 {1, 1025, 2049, …}, &c. This requires more planning and possibly more maintenance, but will have the advantage of producing shorter IDs which can be highly desirable. Random IDs do have a place, but they’re massively overrated. The length required to control the collision risk is very significant.