Zum Hauptinhalt springen

2. Motivation (Motivation)

2. Motivation (Motivation)​

Einer der Hauptgründe für die Verwendung von UUIDs ist, dass keine zentrale Behörde erforderlich ist, um sie zu verwalten (obwohl zwei Formate optionale IEEE 802-Knoten-IDs nutzen können, tun dies andere nicht). Dadurch kann die Generierung bei Bedarf vollständig automatisiert und für verschiedene Zwecke verwendet werden. Der hier beschriebene UUID-Generierungsalgorithmus unterstützt bei Bedarf sehr hohe Zuweisungsraten von 10 Millionen pro Sekunde pro Maschine oder mehr, sodass sie sogar als Transaktions-IDs verwendet werden könnten.

UUIDs haben eine feste Größe (128 Bit), die im Vergleich zu anderen Alternativen relativ klein ist. Dies eignet sich gut zum Sortieren, Ordnen und Hashen aller Art; zum Speichern in Datenbanken; zur einfachen Zuweisung; und zur allgemeinen Programmierfreundlichkeit.

Da UUIDs einzigartig und persistent sind, eignen sie sich hervorragend als URNs. Die einzigartige Fähigkeit, eine neue UUID ohne Registrierungsprozess zu generieren, ermöglicht es UUIDs, eine der URNs mit den niedrigsten Prägungskosten zu sein.

2.1. Motivation für die Aktualisierung​

Seit der ursprünglichen Erstellung von UUIDs hat sich vieles geändert. Moderne Anwendungen müssen UUIDs als primären Bezeichner für eine Vielzahl verschiedener Elemente in komplexen Rechensystemen erstellen und verwenden, einschließlich, aber nicht beschränkt auf Datenbankschlüssel, Dateinamen, Maschinen- oder Systemnamen und Bezeichner für ereignisgesteuerte Transaktionen.

Ein Bereich, in dem UUIDs an Popularität gewonnen haben, sind Datenbankschlüssel. Dies ergibt sich aus der zunehmend verteilten Natur moderner Anwendungen. In solchen Fällen funktionieren "Auto-Increment"-Schemata, die häufig von Datenbanken verwendet werden, nicht gut: Der Aufwand zur Koordinierung sequenzieller numerischer Bezeichner über ein Netzwerk kann leicht zur Belastung werden. Die Tatsache, dass UUIDs verwendet werden können, um eindeutige, angemessen kurze Werte in verteilten Systemen ohne Koordinierung zu erstellen, macht sie zu einer guten Alternative, aber die UUID-Versionen 1-5, die ursprünglich durch [RFC4122] definiert wurden, fehlen bestimmte andere wünschenswerte Eigenschaften, wie zum Beispiel:

  1. UUID-Versionen, die nicht zeitlich geordnet sind, wie UUIDv4 (beschrieben in Abschnitt 5.4), haben eine schlechte Datenbankindex-Lokalität. Dies bedeutet, dass neue Werte, die nacheinander erstellt werden, im Index nicht nahe beieinander liegen; daher müssen Einfügungen an zufälligen Stellen durchgeführt werden. Die daraus resultierenden negativen Leistungsauswirkungen auf die für diesen Zweck verwendeten gemeinsamen Strukturen (B-Baum und seine Varianten) können dramatisch sein.

  2. Die in UUIDv1-Zeitstempeln verwendete 100-Nanosekunden-Gregorianische Epoche (beschrieben in Abschnitt 5.1) ist ungewöhnlich und schwierig genau mit einem Standardzahlenformat wie dem in [IEEE754] beschriebenen darzustellen.

  3. Zur Sortierung nach Zeitfolge ist eine Introspektion/Parsing erforderlich, im Gegensatz zur Möglichkeit, einen einfachen Byte-für-Byte-Vergleich durchzuführen.

  4. Datenschutz- und Netzwerksicherheitsprobleme ergeben sich aus der Verwendung einer Media Access Control (MAC)-Adresse im Knotenfeld von UUIDv1. Exponierte MAC-Adressen können als Angriffsfläche verwendet werden, um Netzwerkschnittstellen zu lokalisieren und verschiedene andere Informationen über solche Maschinen zu enthüllen (mindestens den Hersteller und möglicherweise andere Details). Darüber hinaus ist mit dem Aufkommen virtueller Maschinen und Container die Eindeutigkeit der MAC-Adresse nicht mehr garantiert.

  5. Viele der in [RFC4122] spezifizierten Implementierungsdetails beinhalteten Kompromisse, die weder für alle Anwendungen spezifiziert werden können noch notwendig sind, um interoperable Implementierungen zu erstellen.

  6. [RFC4122] unterschied nicht zwischen den Anforderungen zum Generieren einer UUID und denen zum einfachen Speichern einer UUID, obwohl sie oft unterschiedlich sind.

Aufgrund der oben genannten Probleme haben viele weit verbreitete Datenbankanwendungen und große Anwendungsanbieter versucht, das Problem der Erstellung eines besseren zeitbasierten, sortierbaren eindeutigen Bezeichners zur Verwendung als Datenbankschlüssel zu lösen. Dies hat in den letzten 10+ Jahren zu zahlreichen Implementierungen geführt, die dasselbe Problem auf leicht unterschiedliche Weise lösen.

Bei der Vorbereitung dieser Spezifikation wurden die folgenden 16 verschiedenen Implementierungen auf Trends in Bezug auf Gesamt-ID-Länge, Bit-Layout, lexikalische Formatierung und Codierung, Zeitstempeltyp, Zeitstempelformat, Zeitstempelgenauigkeit, Knotenformat und -komponenten, Kollisionsbehandlung und Multi-Zeitstempel-Tick-Generierungssequenzierung analysiert:

  1. [ULID]
  2. [LexicalUUID]
  3. [Snowflake]
  4. [Flake]
  5. [ShardingID]
  6. [KSUID]
  7. [Elasticflake]
  8. [FlakeID]
  9. [Sonyflake]
  10. [orderedUuid]
  11. [COMBGUID]
  12. [SID]
  13. [pushID]
  14. [XID]
  15. [ObjectID]
  16. [CUID]

Eine Untersuchung dieser Implementierungen und der oben beschriebenen Probleme hat zu diesem Dokument geführt, in dem neue UUIDs angepasst wurden, um diese Probleme anzugehen.

Darüber hinaus benötigte [RFC4122] selbst eine Überarbeitung, um eine Reihe von Themen anzugehen, wie zum Beispiel, aber nicht beschränkt auf, die folgenden:

  1. Implementierung verschiedener Errata-Berichte. Hauptsächlich um Klarstellungen zum Bit-Layout, die zu inkonsistenten Implementierungen führten [Err1957], [Err3546], [Err4975], [Err4976], [Err5560] usw.

  2. Entkopplung anderer UUID-Versionen vom UUIDv1-Bit-Layout, sodass Felder wie "time_hi_and_version" nicht innerhalb einer UUID referenziert werden müssen, die nicht zeitbasiert ist, während gleichzeitig Definitionsabschnitte ähnlich dem für UUIDv1 für UUIDv3, UUIDv4 und UUIDv5 bereitgestellt werden.

  3. Bereitstellung von Implementierungs-Best-Practices für viele reale Szenarien und Grenzfälle, die von bestehenden und Prototyp-Implementierungen beobachtet wurden.

  4. Behandlung von Sicherheits-Best-Practices und -Überlegungen für das moderne Zeitalter in Bezug auf MAC-Adressen, Hashing-Algorithmen, sichere Zufälligkeit und andere Themen.

  5. Bereitstellung einer standardbasierten Option für implementierungsspezifische und/oder experimentelle UUID-Designs für Implementierungen.

  6. Bereitstellung weiterer Testvektoren, die echte gemäß der Spezifikation erstellte UUIDs veranschaulichen.

Letztes Update am