241–246 of 246 posts
Earlier quoted context omitted.
People in my industry in my country has specifically avoid using B and D together as they sound too similar over the phone. Also 2 and Z can be similar in writing. However it is nice to not see 0 and O, 1,I,l in the same string.
If you're worried about clarity over the phone, you should look into the NATO phonetic alphabet: https://en.wikipedia.org/wiki/NATO_phonetic_alphabet
This article talks about random IDs leading to page thrashing, and MySQL b-tree indexes not handling them well. They are bad for _MySQL performance_. It doesn't talk about NoSQL or sharding, where random IDs usually perform much better than sequential due to a lack of hot shards. If you distribute your reads and writes at random across N machines you can get ~Nx performance vs one machine. If you make your writes seq…
its a MySQL blog, why would it talk about NoSQL?
Earlier quoted context omitted.
Even in MySQL - one can use Sequential UUIDs.
I never understood why people would use sequential UUIDs. That rather defeats the purpose of a UUID. If you need something sequential then just use a much more simple number
IIRC this is often a mix of hardware network address and a portion that is either random or based on a high-precision time, so it is still unlikely that you'll see collisions between machines.
MS SQL Server's NEWSEQUENTIALID function returns something akin to a v4 UUID (fully random, aside from variant indicator bits, I'm not sure if the variant bits are respected in NEWSEQUENTIALIDs output or if it just returns a 128-bit number) but after the first is generated the rest follow in sequence until the sequence is reset (by a reboot). Assuming the variant indicators are present, there is are 122 random bits. Even if your system is up long enough to use 2^58 (2.8810^17 if you want that in decimal) IDs generated this way, you still effectively have 64-bits of randomness even if the variant bits are present. For most systems the chance of collision with sequential UUIDs is, while larger than with other types, still so small as to be inconsequential. These are "atoms in several galaxies" level numbers.
You don't want to use sequential UUIDs in place of v4 UUIDs where security matters, or course, as it is easy to work the next in sequence.
> If you need something sequential then just use a much more simple number*
Sequential isn't their only property. UUIDs, including those that increment from the start point, are intended not to collide with those generated elsewhere.
Sequential UUIDs are a compromise - giving away a small amount of collision protection in order to gain what could be a significant efficiency boost in some circumstances (DB indexes being the main one).
Earlier quoted context omitted.
UUIDs are integers, they just happen to be 128 bits long instead of the more common 32 or 64, and they are usually printed in a specific way that differs from how integers are usually printed. But that's just smoke and mirrors. UUIDs are generally not guaranteed to be universally unique. The name is misleading marketing. If you generate them randomly, then the probability of collision is small enough not to matter, b…
Yes, of course. But making them sequential does not take away from the universal(ish) uniqueness
Earlier quoted context omitted.
What was the book?
https://www.bookdepository.com/API-Design-Patterns-JJ-Geewax... I loved it, think it all made a ton of sense. Lots of code samples, no weird technology choices (normally they would do it all via protobufs and gRPC but they keep the same principles and just use HTTP instead and Typescript for code samples)
Earlier quoted context omitted.
DynamoDB runs the partition key through a hash function, so sequential values end up being evenly distributed across partitions.
If so, how does it iterate in key order? I should clarify - the problem with Firestore is the index tablets. The indexes inherently need to be inorder or you can't perform ordered queries.
Partitioning is very explicit in DynamoDB, for better or for worse. Harder to shoot yourself in the foot, but also limits what you can do.