64 ms·
How so? It seems like the only real use case for these timestamps is to get data from around the same time together. A second is fine for that. It's not about c
by travisjungroth 3y ago
How so? It seems like the only real use case for these timestamps is to get data from around the same time together. A second is fine for that. It's not about concurrency or avoiding collisions. A second can't handle that, but neither can a millisecond.
- kiitos 3y ago> It seems like the only real use case for these timestamps is to get data from around the same time together. Yep. > A second is fine for that. Not when you're doing O(1k-1M) operations per second, it isn't!
- travisjungroth 3y agoI’d think that the locality would only matter at the scale of your query. I’m sure someone has queries with a window less than a second and so much traffic, but it seems niche enough to not optimize the standard for it. I could definitely be off. I work at a company that gets those levels of traffic but don’t deal with it directly.
- kiitos 3y agoFor me the whole value prop for ULIDs is that they can be generated by any node in a distributed system without coordination, while roughly preserving time order. "Roughly" meaning: all IDs will be globally ordered at millisecond precision, subject to the accuracy of each node's system clock; and IDs from a specific node will be locally ordered, subject to the details of the monotonicity part of the ID generator. This is important for me, because most of the things I attach IDs to will happen many many many times per second.