![]() ![]() At the cost of 5 (or 6 if you have plans for year 2400) more characters, you get a more friendly format, ready to be used basically anywhere with no further transformation (url compatible etc) except where case is insensitive. This makes base62 format the second most efficient format for PK after the raw binary form. This should leave enough time to think about left padding old UUIDs in case preserving a consistent ordering still matters at that point. If you start generating now, base62 UUIDs will have a length of 21 chars until the 05:49:06 UTC (base 62 zzzzzzzzz = 13 537 086 546 263 551 µsec or 13 537 086 546 epoch time). $orderedBase62Uuid = str_pad( SoUuid:: generate()-> getBase62(), 22, '0', STR_PAD_LEFT) So all together it felt like there was a room for some simple improvements that hopefully will help out in real life situations. It's also kind of a limitation to be bound to any particular format for something that should belong to the application space, like a worker or job id. So it seems a bit awkward to have to deal with Mac Address format just to store a more meaningful id, especially with PHP where Mac address is a rather distant information. While it may have made more sens at some point to bind UUIDs to some physical Mac Address for eternity, it is quite less obvious now as hardware has become a commodity and that Mac addresses are subject to change frequently with no other meaning than "a deployment was made". ![]() Unless you where planning to simulate pre-70's Mac address (did they even exist before that), it's just a waist of data space. Using the Epoch time seems more reasonable and more convenient to work with. Then, using the Gregorian calendar as origin of time just brings nothing to the table. It's of course ok to trade some performance and even some usability to stay in standards, but all together it also seems weird to be stuck with such an inefficient format that does not even match the level of guarantees defined by the original RFC. Because to start with, PHP is limited to the micro-second, and RFC implementation have to artificially meet the "official" 100ns interval, which actually weakens the uniqueness of the UUID, as the same RFC random bits are now protecting a ten times wider interval against collisions. ![]() It seemed to me that something simpler and more adequate with PHP could be of some use. The order problem has been addressed in various ways in PHP, most being implemented as some extra feature of an RFC compliant implementation. While they focus on Mysql, the problem is similar with other DBMS : lack of UUID order and UUID size are costly, with ordering being critical for massive inserts on a PK. Both includes solutions to handle the matter at the database level. You can find more information and benchmarks in Percona Database Performance Blog or on MariaDb's KB. Insert comes at a terrible cost since UUID PKs are pretty random thus highly scattered across the index. ![]() UUID are 36 characters long, which can grow the index size significantly, especially with InnoDB and alike where every secondary index would also contain the primary key.The reason are well know and goes down to : While UUIDs already have well defined standards, they suffer from quite bad performance when used as a primary key in DBMS. Databases aren't obsolete just because your app can get away with storing some info in a flat text file.SoUuid is a working proposal to generate ordered UUIDs in a simple and efficient way using PHP. If you personally don't need that standard, then it's not useful for you, and never has been. There's a reason why UUIDs are a standard, and what that standard isn't "slam 16 random bytes together and go home". So sure, it'd be accurate to say "in many cases you can just do bin2hex(random_bytes(16)) to get a kinda UUID-ish string instead of generating a proper v4 UUID". (Although if so, I think you may want to rethink some bits of your design!) And as a bonus, maybe those extra 6 bits of entropy are somehow critical to your application. One common type is v4, which is, yes, 16 bytes long and has 122 bits of entropy, and yes, you could easily replace that with 16 bytes of randomness if you have no particular desire to follow a standard, interact with systems that are expecting actual v4 UUIDs, include any sort of versioning info, and have no need for some of the niceties (type hinting, etc.) that a good UUID library provides. There are several different types of UUIDs. ![]()
0 Comments
Leave a Reply. |