Earlier quoted context omitted.
That’s an excellent point; that can end up being a bottleneck across many systems.
What can?
Unique ID generation.
You Don't Need UUID
131–140 of 199 posts
Re: You Don't Need UUID
#132The crux of this argument seems to be that UUIDs are too long? Which I disagree with. I can't memorize them, no, and it would be cumbersome to try to say one aloud, but these aren't situations I've ever found myself in. Does it make the URL in the URL bar longer? Yeah, but does that matter?
> Does it make the URL in the URL bar longer? Yeah, but does that matter? I appreciate shorter URLs any time I copy and paste them, which always involves looking at them and sometimes involves scrolling to the end to remove tracking- and search-related fluff. 128 bits is an absurd amount for a unique ID within a single system. Even 48 bits is very, very large -- enough to provide a unique ID (MAC address) to every Et…
> 128 bits is an absurd amount for a unique ID within a single system. Even 48 bits is very, very large -- enough to provide a unique ID (MAC address) to every Ethernet device made for something like 100 years.
What you want is that the number of possible items to enumerate is significantly less than the square root of the cardinality of the ID range, means you can relatively safely randomly generate IDs with few collissions.
Re: You Don't Need UUID
#133Author here. I posted this because I've witnessed many systems in companies I've worked for where our end-users needed UUID to communicate with it (technical support, customer ID, etc.) in a way that makes communication harder. We could've used another shorter ID scheme, which would be fine. The good thing about UUID is that it's omnipresent. From what I've heard, it's this lengthy (2^32) because it was hard to guara…
> it's this lengthy (2^32)
UUIDs are 128 bits, so it's 2^128 rather than 2^32
Re: You Don't Need UUID
#134Author here. I posted this because I've witnessed many systems in companies I've worked for where our end-users needed UUID to communicate with it (technical support, customer ID, etc.) in a way that makes communication harder. We could've used another shorter ID scheme, which would be fine. The good thing about UUID is that it's omnipresent. From what I've heard, it's this lengthy (2^32) because it was hard to guara…
There is no fundamental tech advance that caa make the birthday paradox irrelevant or obsolete, and there never will be.
Re: You Don't Need UUID
#135IMO, a good middleground is using schemes like TypeID[0], ulid[1], or KSUID[2] that provides a more compact and readable (base32) representation and provides better database locality (K-sortable). [0] https://github.com/jetpack-io/typeid [1] https://github.com/ulid/spec [2] https://github.com/segmentio/ksuid
ulids are beautiful little ids without many of the drawbacks and risks of other id systems. They are sufficiently unique for most work (anywhere that you don't need to actually uniquely engineer your ids) and their built in ordering and slick encoding are just icing on the cake.
Re: You Don't Need UUID
#136An issue that is not solved by either UUIDv4 or the proposed solution (random base58 strings) is indexing performance. Both of those solutions typically make it hard for a DB if you write new entries, assuming you have an index on the ID. In addition it might be more calming to actually be sure that a particular ID is not in use without doing a round-trip. Is it practical to pre-allocate empty entries and reserve a s…
Are there modern databases that can’t readily index on a 128-bit value?
Random ids require random inserts and that is bad for performance. It isn't a deal-breaker in most situations but it is a real cost that you do pay.
Re: You Don't Need UUID
#137I completely agree. UUIDs are almost always evidence of overengineering, especially when user-facing. 64-bits is "enough" of an address space for almost any purpose, even global. And while it seems like speaking an ID over the phone or having to scan it manually is something you'd never have to do, in practice it happens all the time. Cut-and-paste is not always an option on all platforms.
128 bits versus 64 bits is a deal breaker?
Yes. Even 64 bits is too many, really: at 6 bits per human-recognizable token, it's more than 10 tokens, which is outside the range of what almost any human can keep in their working memory. You can't even hold it in your head long enough to type it in a different window. 128 bits is completely beyond that; when confronted with 128-bits like a UUID, people just give up. Seriously, try actually typing in a UUID sometime. Even with the grouping it's incredibly difficult. Between 64-bits and 128-bits you discover that you absolutely need an automated way to transmit the data, and then how do you get it to that airgapped computer?
Re: You Don't Need UUID
#138For the web, sequential ID attacks represent a significant problem in terms of a Resource Enumeration Attack. It gets worse when auth isn’t even in play yet (the user isn’t logged in, or doesn’t even have an account yet, or this info is meant to be available outside of auth but to only one specific user), but you need to display only the current item, and not any others. Having a sequential ID of any kind allows the user to trivially hack their way into any other item they wish by just incrementing or decrementing that ID.
UUIDs represent a trivially easy way of implementing a non-incrementing ID with a ridiculously unwieldy address space that makes it supremely unrealistic for the vast majority of users to mess with. They’re just going to give up long before the first successful hit.
Re: You Don't Need UUID
#139I'm building an object database. In different places, it uses four different categories of IDs, depending on requirements:
1. Compact sequential is used, obviously, where order matters. It has the drawback of requiring a coordination with a singleton. (This can be sharded/vectorized, of course.) Aside from that, it also leaks the number of objects/transactions, just by looking for the highest number available. Can be varint-encoded very nicely.
2. Compact non-sequential is used where I need a small identifier, but not leak the number of objects. Since it's compact, I must still guarantee uniqueness as in (1). This is currently implemented using a block cipher on top of the compact sequential ID generator. The drawback of this is that the domain may still be in guessable territory, depending on how much is generated. A 64-bit integer filled with 4B only requires 4B guesses to hit a collision. I don't use this much. The key can never be rotated: a key number would eat up precious bits.
3. Sparse random, used where non-guessability is important, aside from not leaking rates/counts. Take a Google Docs sharable link as an example. I doubt YouTube cares about this. This is where something like a 128-bit number like UUID or ULID shines. The space is large enough that uniqueness is assumed, given a decent PRNG.
Sure, I try to use the nicest one at any given point (e.g. using a compact sequential instead of non-sequential during debugging.) But fact is that sparse random just tick more boxes.
4) Sparse, human readable. For "vouchers". They are bearer tokens that give requests more powers, e.g. to create an account or act as admin. These should be reasonably human readable, so they can be spoken. They obviously need to be sparse and hard to guess, which requires a trade-off in length.
I present them in three ways: base32, english words and QR-code. Pick one; they all do the same. For copy-pasting, base32 might be best (or base58, by all means.)
For shouting to a colleague, the sequence of english words might be better. I'd add other languages as needed: it's just a fixed list of words. The nice thing is it can encode the sequence in base-500 or base-1000 without being obnoxious. (The Matrix protocol and others use emoji lists, but it's the same idea. [1]) Finally, if you have a phone in your pocket or camera on your computer, perhaps the QR-code is the easiest way to use the voucher code.
[1] Actually, IIRC, Matrix only uses 64 emojis, which feels a bit wasteful.
Re: You Don't Need UUID
#140An issue that is not solved by either UUIDv4 or the proposed solution (random base58 strings) is indexing performance. Both of those solutions typically make it hard for a DB if you write new entries, assuming you have an index on the ID. In addition it might be more calming to actually be sure that a particular ID is not in use without doing a round-trip. Is it practical to pre-allocate empty entries and reserve a s…
> An issue that is not solved by either UUIDv4 or the proposed solution (random base58 strings) is indexing performance.
Lots of languages are catching up to UUIDv7, which solves the indexing issue.