4 ms·
We have used ULIDs in production for over a year now-- and have generated millions of these. First, the main benefit of ULID is that you can generate the IDs w
by brdd 8y ago
We have used ULIDs in production for over a year now-- and have generated millions of these.
First, the main benefit of ULID is that you can generate the IDs within your own software rather than rely on the database. We can queue them or even reference them before they land in the database. The traditional roundtrip has been eliminated.
Secondly, being able to sort ULIDs is a nice plus, although not that big of a deal. It makes it relatively easy to shard or partition databases, and it provides a convenient sort if you're not looking for extreme accuracy.
ULIDs are also shorter and slightly more user friendly than UUIDs.
In some circumstances we found the actual implementations to be slightly lacking. For example, the JS library for ULID once returned a 25 character string rather than the standard 26 characters, causing a big ruckus that we had to manually resolve.
- munk-a 8y ago> First, the main benefit of ULID is that you can generate the IDs within your own software rather than rely on the database. We can queue them or even reference them before they land in the database. The traditional roundtrip has been eliminated. No you cannot, unless you're running a single threaded server process on a single machine. What you can do is _gamble_ that you probably won't have a collision, which is the same thing you could do with regular UUIDs and you'd be (nearly) guaranteed to never hit a conflict with UUID4 (or probably UUID1/2 if you trusted your mac address uniqueness). You may find this gamble acceptable and many people do, but you should be aware that pre-generation of UUIDs on independent systems without coordination is not a solvable problem - all attempts to do so rely on the extreme unlikelihood of a collusion to feel good about it or use some coordinated information (like a guaranteed unique mac address). (Again, if it's good enough for you, right on - but it isn't theoretically safe)
- deleted 8y ago[deleted]
- deleted 8y ago[deleted]
- jakevn 8y agoI don't see how it is at all a gamble if you understand the trade-offs. If there is no fatal flaw with the inaccurate/non-deterministic sorting that wall-clock prefix provides and one is utilizing optimistic concurrency (strict create on PK, abort/retry on conflict), I don't see how it is unsafe
- munk-a 8y agoThe gamble is the removal of a central key registry. If you are assigning these UUID/ULIDs as... UIDs then you need to be able to assign them uniquely... if multiple servers/threads/whatevers can generate and assign them independently then there is a chance you'll suffer from ID collision... it's incredibly rare though.
- jakevn 8y agoBut with optimistic concurrency, why is this a gamble? It's an overhead that comes as a result of the trade-offs, sure, but it's a finite cost. Collision can be handled without breaking anything at the cost of implementation complexity.
- warmwaffles 8y ago> What you can do is _gamble_ that you probably won't have a collision, which is the same thing you could do with regular UUIDs and you'd be (nearly) guaranteed to never hit a conflict with UUID4 (or probably UUID1/2 if you trusted your mac address uniqueness). UUID4 is no more safer than ULID since they both rely on randomness.
- bearmcbearsly 8y ago> No you cannot, unless you're running a single threaded server process on a single machine. What you can do is _gamble_ that you probably won't have a collision This seems like a pointless distinction. If I did the math right, you can generate 1,000,000 ULIDs per second (1000 per millisecond) for around 50 million years before you can expect to hit your first collision. I don't know about you, but I'm pretty sure any system I build won't be running 50 million years from now. Not to mention that the timestamp portion of the ULID will overflow in a mere 9000 years.
- deleted 8y ago[deleted]
- yen223 8y agoDoes your math rely on perfect entropy on machines you don't control?
- ngrilly 8y agoYes. I did the math and got the same result, relying on a perfect entropy hypothesis.
- InGodsName 8y agoDid you account for long tail events?
- dtech 8y agoThe point was that this was not an advantage of ULID over UUID. You need 2.7 * 10^18 v4 UUIDs for a 50% collision chance.
- espadrine 8y agoI agree that collision is not an issue. On the other hand, your consistency assumptions may be broken if you rely on the sort order for causality relationship. You can have ULID1 < ULID2 and yet the event associated with ULID1 may be caused by the ULID2 event.
- ngrilly 8y ago