181–190 of 246 posts
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…
I recently read a book by Google’s head guy on API design that was specifically about designing APIs and it had a big section on what makes a good identifier and why people reach for UUIDs and why specifically it is a problem on multiple levels. The thing that he ended up recommending however was super interesting in that I had never seen it mentioned before but it was basically to use this instead http://www.crockfo…
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…
Earlier quoted context omitted.
If the column is UNIQUE there’s no collisions it will just fail to INSERT.
Then it doesn't have the same quality as a UUID which is supposedly guaranteed to be unique across space _and_ time[1]. [1] https://datatracker.ietf.org/doc/html/rfc4122
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.
F and S sound similar over the phone, at least on POTS landlines, as they don't carry the higher frequencies (> 4 kHz) that distinguish the S from the F. Note that cat names tend to have S sounds. POTS = Plain old telephony service is restricted to a narrow frequency range of 300–3,300 Hz, called the voiceband, which is much less than the human hearing range of 20–20,000 Hz [from https://en.wikipedia.org/wiki/Plain_o…
That's the reason I've chosen postgres over mysql years ago and I don't use clustered indexes.
Earlier quoted context omitted.
What? Really? Naïve in this context means a general purpose solution that doesn't "know" about your use case. Have people never heard of a naïve algorithm or solution? Distributed relational databases aren't naïve in this context. MySQL is.
> Have people never heard of a naïve algorithm or solution? I have a fairly recent PhD in algorithms and I haven't heard naïve used this way. When I hear naïve, it usually just means "does the immediately obvious thing". For what you're trying to say, the term I'm familiar with is "oblivious", e.g. "oblivious routing" or "oblivious local search", occasionally with modifiers such as "cache-oblivious".
Earlier quoted context omitted.
Length isn't the primary issue. Locality is. UUIDs are generally generated randomly. This results in terrible insert performance into B+tree-based indexes, and terrible (= no) lookup locality with basically any database. In a large table, successive entries ends up in separate disk pages. Even with time-based UUIDs, the time fields are ordered backward, which produces the same issue. One way to fix this (beside the m…
Firestore has exactly the opposite problem - indexed sequential values put pressure on the "last tablet" and require the same tablet to repeatedly split. This becomes the limiting factor on insert volume. Random generated keys are better, because they spread inserts across multiple tablets (ie servers). I don't know for certain, but I suspect DynamoDB and most other databases that can trace their origins to the bigta…
Earlier quoted context omitted.
Yeah. The main problem is people using them as primary keys in naïve systems like relational databases. You can't just expect a relational database to magically become a distributed system just by using UUIDs. There is a bit more work to do than that.
People use UUIDs for more reasons than just making things distributed. You can generate them client side if that's advantageous, you prevent leaking information about how many records there are in the system and prevent guessing of other potential PKs and potential unauthorized access, and there's some optimization strategies that benefit from not relying on a serial PK.