Open bradleypeabody opened 3 years ago
What about account or license number (hash) for the DBMS or operating system? But I still believe that random number is more convenient.
@sergeyprokhorenko Unfortunately DBMSs and OSs do not contain any values that I'm aware of that have global uniqueness properties. The closest thing I can think of is an IPv6 address, but that's not always available, and is not guaranteed to be unique in cases where multiple programs are running on the same machine. I agree that using a random number instead is convenient and should always be an allowed option.
Recommend the use of MAC addresses Use IPv6 addresses.
This is a non-universal solution (for example, the host may have no public IPv6-address or the application may not be allowed to get it), with the lack of security (the disclosure of IP/MAC-addresses can be considered as a vulnerability).
Problem: MAC addresses don't have uniqueness guarantees these days - random data provides better collision resistance against possible MAC address duplication
Blocks of universally unique MAC addresses/Ethernet addresses are assigned by the IEEE Registration Authority (RA). This clearly shows that a registry is a bad idea for a uniqueness guarantee.
IMO hash of user-provided string is a better idea. It is the responsibility of the user to create a unique string.
Standard can contain a suggestion, e.g. something like Java package/class names could be advised:
com.somenicecompany.dbms.sales.invoice
Yes, this does not guarantee the impossibility of collisions. But the probability of a collision will be so small that it can be considered negligible.
BTW, UUID v3/v5 takes the same approach.
I'll also just add here as another important factor: One should consider what the cost/penalty of getting a duplicate UUID is.
This can be vastly different in different scenarios. Some examples with my opinion on the importance:
Just more food for thought when we talk about the motivations for actual real "global uniqueness".
@edo1 Agreed on IP addresses, it's not practical in many cases.
This clearly shows that a registry is a bad idea for a uniqueness guarantee.
How so? I mean I agree I wouldn't want to have to go through such a registration process very often, but if the stakes are high enough for a given application, I don't see why not. Definitely it's not something everyone would be doing, for sure.
IMO hash of user-provided string is a better idea.
Yeah this basically boils down to the application should pick a sensible approach and stick to it - hashes are certainly one way to go.
How so?
I faced MAC address conflict few times. Therefore, the existence of a MAC address range registry does not guarantee MAC address uniqueness. My guess is that a random address of the same size would have a lower collision rate in the real world.
The local entity type (10 bit) (i.e. database table alias) as a last field of UUID would be a convinient additional "shared knowledge". It can be used to quickly find database tables that contain this UUID.
These values can be used as "shared knowledge":
@broofa , what is the reason of your dislike?
@sergeyprokhorenko Generally speaking, the problem with central authorities is that they require a complex architecture with requirements that are likely to be out of scope of a timestamp-based format. We'd be trying to shoehorn some form of as-yet-unknown identifier alongside the timestamp information without even knowing whether or not (for example) a timestamp is necessary in such a scheme. I mean... if you have a central authority, are you going to need a timestamp even?
For example, I believe Etsy uses a system where blocks of IDs are doled out to the various subsystems. In such a scheme, the best format to use would be something like the forthcoming "experimental" version 8, where the only defined bits are version
and variant
, and everything else is vendor-specific.
As for encoding entity-type information, I believe that is decidedly out of scope. That is not information that makes a meaningful contribution to uniqueness and should be handled external to the UUID format.
@broofa I understand your motives. Almost everyone hates the world of large corporations. I, too, like you. But we have to live with them and try to meet their needs, so as not to be left on the sidelines ourselves. The new RFC should also take into account the quite predictable needs of large corporations, and not leave it all to a vague version 8. It is necessary to list possible UUID components useful for large corporations in the new RFC. It will be like a set of options. It's really easy.
I will describe to you the real problems of one of the largest special depositaries. It monitors compliance with investment declarations by mutual funds and pension funds. All objects in its accounting and information system have their own UUID: securities issues, portfolios, investors, investment declaration rules, etc. UUIDs are the keys in all database tables.
The accounting and information system is very slow because the records in the database tables are not ordered by increasing UUID. They have to buy faster servers, or they could just use UUIDs ordered by creation date and time.
It's very easy and convenient to type any UUID into the search field to get a list of all tables containing it. But I can imagine how difficult it is to provide this, since there are no pointers to tables in the UUID itself.
In addition, the huge and unwieldy posting table contains dozens of fields, and they have to be resourceful not to add more fields. The problem could be easily solved with the help of polymorphic relationships between DB tables. But for this UUID keys must contain pointers to tables (i.e. database table alias).
@sergeyprokhorenko What you're describing has nothing to do with guaranteeing uniqueness via the use of a central authority.
@broofa, "shared knowledge" (in the network) is a broader concept than "central authority"
We disagree. Central authorities serve the entire "Universe" (first "U" of UUID). Your shared knowledge example seems to be implicitly scoped to the "universe" (little "u") of systems that care about these depository tables. You haven't described how they agree on what tables name there are, or what identifiers are to be used to refer to those table names.
If you want to argue your example is relevant to UUIDs, you''ll need to point to some central authority that is responsible for allocating db table name identifiers to ensure their uniqueness across all systems everywhere.
If you want to argue your example is relevant to UUIDs, you''ll need to point to some central authority that is responsible for allocating db table name identifiers to ensure their uniqueness across all systems everywhere.
No. These UUID fragments are governed by the corporation and are used by the same corporation as any of its private classifiers. However, the UUIDs with these fragments are real UUIDs: they are unique and ordered. Thanks to fragments, they also get additional protection against collisions with UUIDs generated for other purposes. Such UUIDs can also be used outside of the generating corporation (with or without reading embedded UUID fragments).
3/1/2022 Update: The latest from Draft 03 on the topic of Shared Knowledge and Node Identifiers is found in the Distributed UUID Generation section.
Premise: Despite the UUID name, "universally unique" values are only achievable with some sort of pre-arranged pattern that decides which systems will provide which values. Adding more bits and entropy to the random parts of a UUID reduces collision probability, but cannot eliminate it. And there is no such thing as "enough collision resistance for any use case anywhere". The use of the MAC address in UUIDv1 was an attempt to use this approach. The drawbacks with it were some security risk in exposing MAC addresses, and the fact that with virtual computing so commonplace these days MAC address uniqueness can no longer be guaranteed. But the core idea behind it is: if you want to guarantee uniqueness, you have to have some sort of global registry or rules system which ensures some part of the UUID will be different from any other system. I'll refer to this approach as "shared knowledge" for lack of a better term (i.e. the different machines on the network share the knowledge of the MAC address registry and depend on it for uniqueness guarantees).
Question/proposition: Should the draft/spec indicate some means guaranteeing global uniqueness through shared knowledge. While the approach of using the MAC address is flawed, it does address a vital need and expose a problem with the current proposal: We still don't have guaranteed universally unique identifiers.
Prior art: A number of "this MUST be unique everywhere" registry systems exist (it's different from UUID generation but the core problem is the same). There are probably a lot more such system than I'm aware of. But just to list a few:
I'm sure there are many more. But you see what's happening here? When people REALLY need uniqueness, they create a registry, because there isn't any other way to achieve uniqueness guarantees.
Possible approaches:
Thoughts? If we really want uniqueness, we need to confront the fact that there's only one way to guarantee it.
EDIT:
Looking at the language of RFC4122 again, it seems like they specifically wanted to avoid any central registry, but made an exception for MAC addresses:
Indeed that's probably one of the main arguments against any such registry: It's inconvenient. And also, if we've learned anything from MAC addresses: If anything goes wrong with the system, using random data (which is generally fast, easy and pretty much always available) is better anyway, i.e. lower collision probability.