Universell eindeutige Kennung - Universally unique identifier

UUID/GUID wie von UEFI- Variablen verwendet

Ein Universally Unique Identifier ( UUID ) ist ein 128-Bit- Etikett, das für Informationen in Computersystemen verwendet wird. Auch der Begriff Global Unique Identifier ( GUID ) wird häufig in von Microsoft erstellter Software verwendet .

Bei der Generierung nach den Standardmethoden sind UUIDs für praktische Zwecke eindeutig. Ihre Einzigartigkeit hängt im Gegensatz zu den meisten anderen Nummerierungsschemata nicht von einer zentralen Registrierungsstelle oder Koordination zwischen den Parteien ab, die sie generieren. Während die Wahrscheinlichkeit, dass eine UUID dupliziert wird, nicht null ist, liegt sie nahe genug bei null, um vernachlässigbar zu sein.

Somit kann jeder eine UUID erstellen und sie verwenden, um etwas mit ziemlicher Sicherheit zu identifizieren, dass der Identifikator keinen dupliziert, der bereits erstellt wurde oder noch erstellt wird, um etwas anderes zu identifizieren. Informationen, die von unabhängigen Parteien mit UUIDs gekennzeichnet wurden, können daher später mit einer vernachlässigbaren Wahrscheinlichkeit einer Duplizierung in einer einzigen Datenbank zusammengefasst oder auf demselben Kanal übertragen werden.

Die Übernahme von UUIDs ist weit verbreitet, wobei viele Computerplattformen Unterstützung für deren Generierung und das Parsen ihrer Textdarstellung bieten.

Geschichte

In den 1980er Jahren verwendete Apollo Computer UUIDs ursprünglich im Network Computing System (NCS) und später in der Distributed Computing Environment (DCE) der Open Software Foundation (OSF ). Das ursprüngliche Design von DCE-UUIDs basierte auf den NCS-UUIDs, deren Design wiederum von den ( 64-Bit ) eindeutigen Identifikatoren inspiriert wurde, die in Domain/OS , einem von Apollo Computer entwickelten Betriebssystem, definiert und weit verbreitet sind . Später übernahmen die Microsoft Windows- Plattformen das DCE-Design als "Global Unique Identifiers" (GUIDs). RFC 4122 registrierte einen URN- Namensraum für UUIDs und rekapitulierte die früheren Spezifikationen mit demselben technischen Inhalt. Als im Juli 2005 RFC 4122 als vorgeschlagener IETF- Standard veröffentlicht wurde, hatte die ITU auch UUIDs standardisiert, basierend auf den vorherigen Standards und frühen Versionen von RFC 4122.

Normen

UUIDs werden von der Open Software Foundation (OSF) als Teil der Distributed Computing Environment (DCE) standardisiert .

UUIDs sind dokumentiert als Teil der ISO / IEC 11578:1996 „ Informationstechnologie  – Open Systems Interconnection – Remote Procedure Call (RPC)“ und neuerdings in ITU-T Rec. X.667 | ISO / IEC 9834-8:2005.

Die Internet Engineering Task Force (IETF) hat den Standards-Track RFC 4122 veröffentlicht, der technisch äquivalent zu ITU-T Rec ist. X.667 | ISO/IEC 9834-8.

Format

In seiner kanonischen Textdarstellung werden die 16 Oktette einer UUID als 32 hexadezimale (Basis-16) Ziffern dargestellt, die in fünf durch Bindestriche getrennten Gruppen in der Form 8-4-4-4-12 für insgesamt 36 Zeichen angezeigt werden (32 hexadezimale Zeichen und 4 Bindestriche). Zum Beispiel:

123e4567-e89b-12d3-a456-426614174000
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

Die 4-Bit-M- und die 1- bis 3-Bit- N- Felder codieren das Format der UUID selbst.

Die vier Bits der Ziffer Msind die UUID-Version und die 1 bis 3 höchstwertigen Bits des NZifferncodes die UUID-Variante. (Siehe unten. ) Im Beispiel M ist 1, und N ist a(10xx 2 ), was bedeutet , dass es sich um eine Version-1 - Variante-1 UUID; das heißt, eine zeitbasierte DCE/RFC 4122 UUID.

Der kanonische 8-4-4-4-12-Formatstring basiert auf dem Datensatz-Layout für die 16 Bytes der UUID:

UUID-Datensatzlayout
Name Länge (Byte) Länge (Hex-Ziffern) Länge (Bit) Inhalt
time_low 4 8 32 Ganzzahl, die die unteren 32 Bits der Zeit angibt
time_mid 2 4 16 Ganzzahl, die die mittleren 16 Bits der Zeit angibt
time_hi_and_version 2 4 16 4-Bit "Version" in den höchstwertigen Bits, gefolgt von den hohen 12 Bits der Zeit
clock_seq_hi_and_res clock_seq_low 2 4 16 1 bis 3-Bit-„Variante“ in den höchstwertigen Bits, gefolgt von der 13- bis 15-Bit-Taktfolge
Knoten 6 12 48 die 48-Bit-Knoten-ID

Diese Felder entsprechen denen in den UUIDs der Version 1 und 2 (d. h. zeitbasierten UUIDs), aber die gleiche 8-4-4-4-12-Darstellung wird für alle UUIDs verwendet, sogar für UUIDs, die anders konstruiert sind.

RFC 4122 Abschnitt 3 erfordert, dass die Zeichen in Kleinbuchstaben generiert werden, während die Groß-/Kleinschreibung bei der Eingabe nicht beachtet wird.

Microsoft GUIDs werden manchmal mit umgebenden geschweiften Klammern dargestellt:

{123e4567-e89b-12d3-a456-426652340000}

Dieses Format sollte nicht mit " Windows-Registrierungsformat " verwechselt werden , das sich auf das Format innerhalb der geschweiften Klammern bezieht .

RFC 4122 definiert einen Uniform Resource Name (URN)-Namespace für UUIDs. Eine als URN dargestellte UUID sieht wie folgt aus:

urn:uuid:123e4567-e89b-12d3-a456-426655440000

Codierung

Die binäre Codierung von UUIDs variiert zwischen den Systemen. Variante 1 UUIDs, heutzutage die gebräuchlichste Variante, werden im Big-Endian- Format kodiert . Beispielsweise 00112233-4455-6677-8899-aabbccddeeffwird als Bytes codiert 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff.

UUIDs der Variante 2, die in der Vergangenheit in den COM/OLE-Bibliotheken von Microsoft verwendet wurden , verwenden ein Mixed-Endian- Format, wobei die ersten drei Komponenten der UUID Little-Endian und die letzten beiden Big-Endian- Komponenten sind . Beispielsweise 00112233-4455-6677-8899-aabbccddeeffwird als Bytes codiert 33 22 11 00 55 44 77 66 88 99 aa bb cc dd ee ff.

Varianten

Das "Varianten"-Feld von UUIDs oder die N- Position geben ihr Format und ihre Codierung an. RFC 4122 definiert vier Varianten der Längen 1 bis 3 Bit:

  • Variante 0 (angezeigt durch das Ein-Bit-Muster 0xxx 2 , N  =  0..7) dient der Abwärtskompatibilität mit dem mittlerweile veralteten Apollo Network Computing System 1.5 UUID-Format, das um 1988 entwickelt wurde. Die ersten 6 Oktette der UUID sind ein 48-Bit-Zeitstempel ( die Anzahl der 4-Mikrosekunden-Zeiteinheiten seit dem 1. Januar 1980 UTC); die nächsten 2 Oktette sind reserviert; das nächste Oktett ist die "Adressfamilie"; und die letzten 7 Oktette sind eine 56-Bit-Host-ID in der von der Adressfamilie angegebenen Form. Obwohl sie sich im Detail unterscheiden, ist die Ähnlichkeit mit modernen UUIDs der Version 1 offensichtlich. Die Variantenbits in der aktuellen UUID-Spezifikation stimmen mit den High-Bits des Adressfamilien-Oktetts in NCS-UUIDs überein. Obwohl die Adressfamilie Werte im Bereich 0..255 enthalten konnte, wurden immer nur die Werte 0..13 definiert. Dementsprechend 0xxxvermeidet das Variante-0-Bitmuster Konflikte mit historischen NCS-UUIDs, falls noch welche in Datenbanken existieren.
  • Variante 1 (10xx 2 , N  =  8..b, 2 Bit) wird nach den Autoren des ursprünglichen Internet Drafts als RFC 4122/DCE 1.1 UUIDs oder "Leach-Salz" UUIDs bezeichnet .
  • Variante 2 (110x 2 , N  =  c..d, 3 Bits) wird im RFC als "reserviert, Abwärtskompatibilität der Microsoft Corporation" gekennzeichnet und wurde für frühe GUIDs auf der Microsoft Windows- Plattform verwendet. Sie unterscheidet sich von Variante 1 nur durch die Endianness bei der binären Speicherung oder Übertragung: UUIDs der Variante 1 verwenden die Byte-Reihenfolge "Netzwerk" (Big-Endian), während GUIDs der Variante 2 die "native" (Little-Endian) Byte-Reihenfolge für einige Unterfelder verwenden der UUID.
  • Reserviert ist als das 3-Bit-Varianten-Bitmuster 111x 2 ( N  =  e..f) definiert.

Die Varianten 1 und 2 werden von der aktuellen UUID-Spezifikation verwendet. Die Varianten 1 und 2 sind in ihren Textdarstellungen bis auf die Variantenbits gleich. In der binären Darstellung gibt es einen Endianness-Unterschied. Wenn ein Byte-Swapping erforderlich ist, um zwischen der Big-Endian-Byte-Reihenfolge von Variante 1 und der Little-Endian-Byte-Reihenfolge von Variante 2 zu konvertieren, definieren die obigen Felder das Swapping. Die ersten drei Felder sind 32- und 16-Bit-Ganzzahlen ohne Vorzeichen und unterliegen dem Swapping, während die letzten beiden Felder aus uninterpretierten Bytes bestehen und nicht dem Swapping unterliegen. Dieses Byte-Swapping gilt auch für die Versionen 3, 4 und 5, bei denen die kanonischen Felder nicht dem Inhalt der UUID entsprechen.

Während einige wichtige GUIDs, wie der Bezeichner für die IUnknown- Schnittstelle des Component Object Model , nominell UUIDs der Variante 2 sind, sind viele Bezeichner, die in Microsoft Windows-Software generiert und verwendet und als "GUIDs" bezeichnet werden, die Standardvariante 1 RFC 4122/DCE 1.1 Netzwerk-Byte-Reihenfolge-UUIDs anstelle von Little-Endian-Variante-2-UUIDs. Die aktuelle Version des Microsoft- Tools erzeugt Standard-Variante-1-UUIDs. Einige Microsoft-Dokumentationen geben an, dass "GUID" ein Synonym für "UUID" ist, wie in RFC 4122 standardisiert. RFC 4122 selbst besagt, dass UUIDs "auch als GUIDs bekannt sind". All dies deutet darauf hin, dass "GUID", obwohl es sich ursprünglich auf eine von Microsoft verwendete Variante der UUID bezog, einfach zu einem alternativen Namen für UUID geworden ist, wobei sowohl Variante-1- als auch Variante-2-GUIDs vorhanden sind. guidgen

Versionen

Für beide Varianten 1 und 2 sind in den Normen fünf „Versionen“ definiert, von denen jede in bestimmten Anwendungsfällen besser geeignet sein kann als die anderen. Die Version wird durch das Min der String-Darstellung angezeigt .

Version-1-UUIDs werden aus einer Uhrzeit und einer Knoten-ID (normalerweise die MAC-Adresse ) generiert ; Version-2-UUIDs werden aus einem Bezeichner (normalerweise eine Gruppen- oder Benutzer-ID), einer Zeit und einer Knoten-ID generiert; die Versionen 3 und 5 erzeugen deterministische UUIDs, die durch Hashing eines Namespace- Bezeichners und -Namens generiert werden ; und Version-4-UUIDs werden unter Verwendung einer Zufalls- oder Pseudozufallszahl generiert .

Null UUID

Die "nil" UUID, ein Sonderfall, ist die UUID 00000000-0000-0000-0000-000000000000; das heißt, alle Bits werden auf Null gesetzt.

Version 1 (Datum-Uhrzeit und MAC-Adresse)

Version 1 verkettet die 48-Bit- MAC-Adresse des "Knotens" (d. h. des Computers, der die UUID generiert), mit einem 60-Bit-Zeitstempel, der die Anzahl der 100- Nanosekunden- Intervalle seit Mitternacht 15. Oktober 1582 Coordinated Universal Time (UTC ), das Datum, an dem der Gregorianische Kalender erstmals eingeführt wurde. RFC 4122 besagt, dass der Zeitwert je nach verwendetem Algorithmus um 3400 AD rollt, was bedeutet, dass der 60-Bit-Zeitstempel eine vorzeichenbehaftete Größe ist. Einige Software, wie die libuuid-Bibliothek, behandelt den Zeitstempel jedoch als unsigniert und setzt die Rollover-Zeit in 5236 n. Chr. fest. Die Rollover-Zeit gemäß der Definition von ITU-T Rec. X.667 ist 3603 n. Chr.

Eine 13-Bit- oder 14-Bit-"eindeutige" Taktsequenz erweitert den Zeitstempel, um Fälle zu behandeln, in denen der Prozessortakt nicht schnell genug vorrückt oder in denen mehrere Prozessoren und UUID-Generatoren pro Knoten vorhanden sind. Wenn UUIDs schneller generiert werden, als der Systemtakt vorrücken könnte, können die unteren Bits der Zeitstempelfelder generiert werden, indem sie jedes Mal erhöht werden, wenn eine UUID generiert wird, um einen hochauflösenden Zeitstempel zu simulieren. Da jede UUID der Version 1 einem einzelnen Punkt im Raum (dem Knoten) und der Zeit (Intervalle und Taktsequenz) entspricht, ist die Wahrscheinlichkeit, dass zwei richtig erzeugte UUIDs der Version 1 unbeabsichtigt gleich sind, praktisch gleich null. Da die Zeit- und Taktsequenz 74 Bits beträgt , können 2 74 (1,8 × 10 22 oder 18 Sextillionen) UUIDs der Version 1 pro Knoten-ID mit einer maximalen Durchschnittsrate von 163 Milliarden pro Sekunde pro Knoten-ID erzeugt werden.

Im Gegensatz zu anderen UUID-Versionen beruhen die auf MAC-Adressen von Netzwerkkarten basierenden UUIDs der Version 1 und -2 für ihre Eindeutigkeit teilweise auf einer von einer zentralen Registrierungsstelle vergebenen Kennung, nämlich dem Organizationally Unique Identifier (OUI)-Teil der MAC-Adresse , das vom IEEE an Hersteller von Netzwerkgeräten ausgegeben wird . Die Eindeutigkeit von UUIDs der Versionen 1 und 2, die auf MAC-Adressen von Netzwerkkarten basieren, hängt auch davon ab, dass die Hersteller der Netzwerkkarten ihren Karten ordnungsgemäß eindeutige MAC-Adressen zuweisen, was wie bei anderen Herstellungsprozessen fehleranfällig ist. Darüber hinaus erlauben einige Betriebssysteme dem Endbenutzer, die MAC-Adresse anzupassen, insbesondere OpenWRT .

Die Verwendung der MAC-Adresse der Netzwerkkarte des Knotens für die Knoten-ID bedeutet, dass eine UUID der Version 1 bis zu dem Computer zurückverfolgt werden kann, der sie erstellt hat. Dokumente können manchmal durch UUIDs, die von Textverarbeitungsprogrammen in sie eingebettet sind, bis zu den Computern zurückverfolgt werden, auf denen sie erstellt oder bearbeitet wurden . Diese Privatsphärenlücke wurde genutzt, um den Schöpfer des Melissa-Virus ausfindig zu machen .

RFC 4122 erlaubt es, die MAC-Adresse in einer UUID der Version 1 (oder 2) durch eine zufällige 48-Bit-Knoten-ID zu ersetzen, entweder weil der Knoten keine MAC-Adresse hat oder weil es nicht wünschenswert ist, sie offenzulegen. In diesem Fall verlangt der RFC, dass das niedrigstwertige Bit des ersten Oktetts der Node-ID auf 1 gesetzt wird. Dies entspricht dem Multicast- Bit in MAC-Adressen und dient zur Unterscheidung von UUIDs, bei denen die Node-ID zufällig generiert wird von UUIDs basierend auf MAC-Adressen von Netzwerkkarten, die normalerweise über Unicast- MAC-Adressen verfügen .

Version 2 (Datum-Uhrzeit und MAC-Adresse, DCE-Sicherheitsversion)

RFC 4122 reserviert Version 2 für "DCE-Sicherheit"-UUIDs; aber es gibt keine Details. Aus diesem Grund lassen viele UUID-Implementierungen Version 2 weg. Die Spezifikation von Version-2-UUIDs wird jedoch von der DCE 1.1 Authentication and Security Services-Spezifikation bereitgestellt.

UUIDs der Version 2 ähneln Version 1, außer dass die niedrigstwertigen 8 Bits der Taktsequenz durch eine "lokale Domänen"-Nummer ersetzt werden und die niedrigstwertigen 32 Bits des Zeitstempels durch einen ganzzahligen Bezeichner ersetzt werden, der innerhalb der angegebenen Werte sinnvoll ist lokale Domäne. Auf POSIX - Systemen, lokalen Bereichsnummern 0 und 1 sind für Benutzer - IDs ( UIDs ) und Gruppen - IDs ( GID ) bzw., und andere lokale Bereichsnummern sind orts definiert. Auf Nicht-POSIX-Systemen sind alle lokalen Domänennummern standortdefiniert.

Die Möglichkeit, eine 40-Bit-Domäne/-Kennung in die UUID aufzunehmen, ist mit einem Kompromiss verbunden. Einerseits ermöglichen 40 Bits etwa 1 Billion Domain-/Identifier-Werte pro Node-ID. Auf der anderen Seite "tickt" die Uhr in einer UUID der Version 2 nur einmal alle 429,49 Sekunden, also etwas mehr als 7 Minuten, wenn der Taktwert auf die 28 höchstwertigen Bits gekürzt wird, verglichen mit 60 Bits in Version 1, da im Gegensatz zu alle 100 Nanosekunden für Version 1. Und mit einer Taktsequenz von nur 6 Bit, verglichen mit 14 Bit in Version 1, können nur 64 eindeutige UUIDs pro Knoten/Domäne/Kennung pro 7-Minuten-Takt generiert werden, im Vergleich zu 16.384 Taktsequenzwerte für Version 1. Somit ist Version 2 möglicherweise nicht für Fälle geeignet, in denen UUIDs pro Knoten/Domäne/Kennung mit einer Rate von mehr als etwa einer alle sieben Minuten erforderlich sind.

Version 3 und 5 (Namespace-Namensbasiert)

Version-3- und Version-5-UUIDs werden durch Hashing einer Namespace- ID und eines Namens generiert . Version 3 verwendet MD5 als Hashing-Algorithmus und Version 5 verwendet SHA-1 .

Der Namespace-Bezeichner ist selbst eine UUID. Die Spezifikation stellt UUIDs bereit, um die Namespaces für URLs , vollqualifizierte Domänennamen , Objekt-IDs und X.500- Distinguished Names darzustellen . aber jede gewünschte UUID kann als Namespace-Bezeichner verwendet werden.

Um die UUID der Version 3 zu bestimmen, die einem gegebenen Namensraum und Namen entspricht, wird die UUID des Namensraums in eine Bytefolge umgewandelt, mit dem Eingabenamen verkettet und dann mit MD5 gehasht, was 128 Bits ergibt. Dann werden 6 oder 7 Bits durch feste Werte ersetzt, die 4-Bit-Version (zB 0011 2 für Version 3) und die 2- oder 3-Bit-UUID "Variante" (zB 10 2 zeigt eine RFC 4122 UUIDs an, oder 110 2 eine Legacy-Microsoft-GUID angibt). Da somit 6 oder 7 Bit vorgegeben sind, tragen nur 121 oder 122 Bit zur Eindeutigkeit der UUID bei.

Version-5-UUIDs sind ähnlich, aber SHA-1 wird anstelle von MD5 verwendet. Da SHA-1 160-Bit-Digests generiert, wird der Digest auf 128 Bit gekürzt, bevor die Versions- und Variantenbits ersetzt werden.

UUIDs der Versionen 3 und 5 haben die Eigenschaft, dass derselbe Namespace und Name derselben UUID zugeordnet wird. Aus der UUID können jedoch weder Namespace noch Name ermittelt werden, selbst wenn eine davon angegeben ist, außer durch Brute-Force-Suche. RFC 4122 empfiehlt Version 5 (SHA-1) gegenüber Version 3 (MD5) und warnt vor der Verwendung von UUIDs beider Versionen als Sicherheitsanmeldeinformationen.

Version 4 (zufällig)

Eine UUID der Version 4 wird zufällig generiert. Wie bei anderen UUIDs werden 4 Bits verwendet, um Version 4 anzuzeigen, und 2 oder 3 Bits, um die Variante anzuzeigen (10 2 oder 110 2 für die Varianten 1 bzw. 2). Somit hat für Variante 1 (d. h. die meisten UUIDs) eine zufällige Version-4-UUID 6 vorbestimmte Varianten- und Versionsbits, so dass 122 Bits für den zufällig generierten Teil übrig bleiben, also insgesamt 2 122 oder 5,3 × 10 36 (5,3 .).  undecillion ) mögliche Version-4-Variante-1-UUIDs. Es gibt halb so viele mögliche Version-4-Variante-2-UUIDs (Legacy-GUIDs), weil ein Zufallsbit weniger verfügbar ist und 3 Bits für die Variante verbraucht werden.

Kollisionen

Kollision tritt auf, wenn dieselbe UUID mehr als einmal generiert und verschiedenen Referenten zugewiesen wird. Bei Standard-UUIDs der Versionen 1 und 2, die eindeutige MAC-Adressen von Netzwerkkarten verwenden, ist es unwahrscheinlich, dass Kollisionen auftreten, mit einer erhöhten Wahrscheinlichkeit nur, wenn eine Implementierung entweder versehentlich oder absichtlich von den Standards abweicht.

Im Gegensatz zu UUIDs der Version 1 und 2, die mit MAC-Adressen generiert wurden, mit UUIDs der Versionen 1 und 2, die zufällig generierte Knoten-IDs verwenden, Hash-basierten UUIDs der Versionen 3 und 5 und zufälligen UUIDs der Version 4, Kollisionen können auch ohne Implementierungsprobleme auftreten, wenn auch mit einer so geringen Wahrscheinlichkeit, dass sie normalerweise ignoriert werden kann. Diese Wahrscheinlichkeit kann anhand der Analyse des Geburtstagsproblems genau berechnet werden .

Zum Beispiel beträgt die Anzahl der zufälligen UUIDs der Version 4, die generiert werden müssen, um eine 50-prozentige Wahrscheinlichkeit für mindestens eine Kollision zu haben, 2,71 Trillionen, berechnet wie folgt:

Diese Zahl entspricht der Erzeugung von 1 Milliarde UUIDs pro Sekunde für etwa 85 Jahre. Eine Datei mit so vielen UUIDs mit 16 Byte pro UUID würde etwa 45  Exabyte groß sein .

Die kleinste Anzahl von UUIDs der Version 4, die generiert werden muss, damit die Wahrscheinlichkeit, eine Kollision zu finden, p ist, wird durch die Formel

Somit beträgt die Wahrscheinlichkeit, innerhalb von 103 Billionen Version-4-UUIDs ein Duplikat zu finden, eins zu einer Milliarde.

Verwendet

Bedeutende Verwendungen umfassen ext2 / ext3 / ext4- Dateisystem-Userspace-Tools ( e2fsprogs verwendet die von util-linux bereitgestellte Libuuid ), LVM , LUKS- verschlüsselte Partitionen, GNOME , KDE und macOS , von denen die meisten von der ursprünglichen Implementierung von Theodore Ts'o abgeleitet sind .

Eine der Verwendungen von UUIDs in Solaris (unter Verwendung der Open Software Foundation-Implementierung) ist die Identifizierung einer laufenden Betriebssysteminstanz zum Zweck der Paarung von Crash-Dump-Daten mit Fault Management Event im Falle einer Kernel-Panik.

Wird häufig in Bluetooth-Protokollen verwendet, um Dienste und das allgemeine Bluetooth-Profil zu bestimmen.

In COM

Es gibt verschiedene Arten von GUIDs, die im Component Object Model (COM) von Microsoft verwendet werden :

  • IID – Schnittstellenkennung; (Diejenigen , die auf einem System registriert sind , werden in der gespeicherten Windows - Registrierung an [HKEY_CLASSES_ROOT\Interface])
  • CLSID – Klassenkennung; (Gespeichert bei [HKEY_CLASSES_ROOT\CLSID])
  • LIBID – Typbibliothekskennung ; (Gespeichert bei [HKEY_CLASSES_ROOT\TypeLib])
  • CATID – Kategoriekennung; (seine Anwesenheit in einer Klasse identifiziert sie als zu bestimmten Klassenkategorien gehörend, aufgelistet unter [HKEY_CLASSES_ROOT\Component Categories])

Als Datenbankschlüssel

UUIDs werden häufig als eindeutiger Schlüssel in Datenbanktabellen verwendet. Die NEWID- Funktion in Microsoft SQL Server Version 4 Transact-SQL gibt standardmäßige zufällige Version-4-UUIDs zurück, während die NEWSEQUENTIALID- Funktion 128-Bit-Bezeichner ähnlich UUIDs zurückgibt , für die festgeschrieben wird, dass sie bis zum nächsten Systemneustart nacheinander aufsteigen. Die Oracle Database SYS_GUID- Funktion gibt trotz des Namens keine Standard-GUID zurück. Stattdessen gibt es einen 16-Byte 128-Bit-RAW-Wert basierend auf einer Host-ID und einer Prozess- oder Thread-ID zurück, ähnlich einer GUID. PostgreSQL enthält einen UUID- Datentyp und kann die meisten Versionen von UUIDs durch die Verwendung von Funktionen aus Modulen generieren. MySQL bietet eine UUID- Funktion, die Standard-UUIDs der Version 1 generiert.

Die zufällige Natur von Standard UUIDs der Versionen 3, 4 und 5, und die Reihenfolge der Felder innerhalb von Standard - Versionen 1 und 2 können Probleme mit Datenbank erstellen Ort oder Leistung , wenn UUIDs als verwendet werden Primärschlüssel . Im Jahr 2002 berichtete beispielsweise Jimmy Nilsson über eine signifikante Leistungsverbesserung mit Microsoft SQL Server, als die als Schlüssel verwendeten UUIDs der Version 4 so geändert wurden, dass sie ein nicht zufälliges Suffix basierend auf der Systemzeit enthalten. Dieser so genannte „COMB“-Ansatz (combined time-GUID) machte die UUIDs nicht standardisiert und deutlich wahrscheinlicher, dass sie dupliziert wurden, wie Nilsson einräumte, aber Nilsson verlangte nur Eindeutigkeit innerhalb der Anwendung. Durch die Neuordnung und Codierung der UUIDs der Versionen 1 und 2, sodass der Zeitstempel an erster Stelle steht, kann ein Einfügungsleistungsverlust vermieden werden.

Einige Web-Frameworks, wie z. B. Laravel, unterstützen "Timestamp first"-UUIDs, die effizient in einer indizierten Datenbankspalte gespeichert werden können. Dies erzeugt eine COMB-UUID, die das Format der Version 4 verwendet, wobei die ersten 48 Bits jedoch einen Zeitstempel bilden, der wie in UUIDv1 angeordnet ist. Genauere Formate basierend auf der COMB UUID-Idee umfassen:

  • "ULID", das die 4 Bits, die verwendet werden, um Version 4 anzuzeigen, weglässt, verwendet standardmäßig eine Base32-Codierung und fordert volle Monotonie durch Zustandsnähe.
  • UUID-Versionen 6 bis 8, ein formaler Vorschlag von drei COMB-UUID-Formaten.

Siehe auch

Verweise

Externe Links

Normen

ITU-T UUID-Generator

Technische Artikel

Sonstig

Umsetzung in verschiedenen Sprachen