Wann sind Sie wirklich gezwungen, UUID als Teil des Designs zu verwenden?

123

Ich verstehe den Sinn der UUID nicht wirklich . Ich weiß, dass die Wahrscheinlichkeit einer Kollision praktisch Null ist , aber effektiv Null ist nicht einmal annähernd unmöglich.

Kann jemand ein Beispiel nennen, bei dem Sie keine andere Wahl haben, als UUID zu verwenden? Aus all den Anwendungen, die ich gesehen habe, kann ich ein alternatives Design ohne UUID erkennen. Sicher, das Design ist vielleicht etwas komplizierter, aber zumindest hat es keine Ausfallwahrscheinlichkeit ungleich Null.

UUID riecht für mich nach globalen Variablen. Es gibt viele Möglichkeiten, wie globale Variablen das Design vereinfachen, aber es ist nur faul.

Pyrolistisch
quelle
23
Alles hat eine Ausfallwahrscheinlichkeit ungleich Null. Ich würde mich auf weitaus wahrscheinlichere Probleme konzentrieren (dh auf fast alles, was Sie sich
vorstellen
16
Tatsächlich ist "effektiv Null" nahezu unmöglich.
mqp
21
Nein, es ist eigentlich unendlich
alles andere als
32
@Pyrolistical Wenn Sie anfangen, Wörter wie "unendlich" herumzuwerfen, haben Sie die Welt der Softwareentwicklung verlassen. Die Informatik-Theorie ist eine ganz andere Diskussion als das Schreiben von echter Software.
Rex M
2
Ich werde meistens schließen, weil gits sha1 mich von der Güte eines Hash überzeugt hat
Pyrolistical

Antworten:

617

Ich habe den UUID-Generator / Parser für Ruby geschrieben und halte mich daher für einigermaßen gut informiert. Es gibt vier Haupt-UUID-Versionen:

UUIDs der Version 4 sind im Wesentlichen nur 16 Byte Zufälligkeit, die aus einem kryptografisch sicheren Zufallszahlengenerator abgerufen werden. Es ist äußerst unwahrscheinlich, dass diese kollidieren, aber es kann passieren, dass ein PRNG verwendet wird oder dass Sie einfach wirklich, wirklich, wirklich, wirklich, wirklich Pech haben.

UUIDs der Versionen 5 und 3 verwenden die Hash-Funktionen SHA1 und MD5, um einen Namespace mit bereits eindeutigen Daten zu kombinieren und eine UUID zu generieren. Auf diese Weise können Sie beispielsweise eine UUID aus einer URL erstellen. Kollisionen sind hier nur möglich, wenn die zugrunde liegende Hash-Funktion auch eine Kollision aufweist.

UUIDs der Version 1 sind am häufigsten. Sie verwenden die MAC-Adresse der Netzwerkkarte (die, sofern nicht gefälscht, eindeutig sein sollte) sowie einen Zeitstempel und das übliche Bit-Twiddling zum Generieren der UUID. Bei einem Computer ohne MAC-Adresse werden die 6 Knotenbytes mit einem kryptografisch sicheren Zufallszahlengenerator generiert. Wenn zwei UUIDs nacheinander so schnell generiert werden, dass der Zeitstempel mit der vorherigen UUID übereinstimmt, wird der Zeitstempel um 1 erhöht. Kollisionen sollten nur auftreten, wenn eine der folgenden Situationen eintritt: Die MAC-Adresse wird gefälscht. Ein Computer, auf dem zwei verschiedene UUID-generierende Anwendungen ausgeführt werden, erzeugt UUIDs genau zum gleichen Zeitpunkt. Zwei Computer ohne Netzwerkkarte oder ohne Zugriff auf Benutzerebene auf die MAC-Adresse erhalten dieselbe zufällige Knotenfolge und generieren UUIDs genau zum gleichen Zeitpunkt.

Realistisch gesehen tritt keines dieser Ereignisse versehentlich im ID-Bereich einer einzelnen Anwendung auf. Wenn Sie IDs nicht beispielsweise im Internet oder in einer nicht vertrauenswürdigen Umgebung akzeptieren, in der böswillige Personen im Falle einer ID-Kollision möglicherweise etwas Schlechtes tun können, sollten Sie sich darüber keine Sorgen machen. Es ist wichtig zu verstehen, dass es in den meisten Fällen keine Rolle spielt, wenn Sie dieselbe UUID der Version 4 wie ich generieren. Ich habe die ID in einem völlig anderen ID-Bereich als Ihrem generiert. Meine Anwendung wird nie etwas über die Kollision erfahren, daher spielt die Kollision keine Rolle. Ehrlich gesagt, wird in einem einzigen Anwendungsbereich ohne böswillige Akteure das Aussterben allen Lebens auf der Erde lange vor einer Kollision eintreten, selbst bei einer UUID der Version 4, selbst wenn Sie '

Außerdem sind 2 ^ 64 * 16 256 Exabyte. Wie in müssen Sie IDs im Wert von 256 Exabyte speichern, bevor Sie eine 50% ige Chance auf eine ID-Kollision in einem einzelnen Anwendungsbereich haben.

Bob Aman
quelle
8
Dies ist bei weitem die beste Erklärung. Ich weiß nicht, warum dies nicht an die Spitze gewählt wird. Ein großes Lob an Sie Sporkmonger.
Brad Barker
1
@Chamnap Ich habe UUIDTools geschrieben. UUIDs können in eine Ganzzahl oder ihre Rohbyteform konvertiert werden und wären als Binärdatei wesentlich kleiner.
Bob Aman
1
@Chamnap uuid.rawgibt Ihnen die Byte-Zeichenfolge. Die hashMethode ist für Sie nicht nützlich. Es wird intern in Ruby für Hash-Tabellen und Vergleichsoperationen verwendet. Alle Methoden zum Konvertieren in und aus verschiedenen UUID-Darstellungen sind als Klassenmethoden definiert und sollten mit einem Präfix versehen werden "parse".
Bob Aman
3
@BobAman im Jahr 1990 Ich hatte 12 UUID-Kollisionen auf einem Aegis-System, stellte sich als fehlerhafte FPU heraus, dachte aber, ich würde Sie wissen lassen, dass dies passieren kann (außer in den letzten mehr als 30 Jahren der Programmierung ist nichts anderes passiert). . Nizza Erklärung, auch übrigens, dies ist jetzt mein defacto UUID Refence Post, um Menschen zu geben :)
GMasucci
2
@kqr Sie haben absolut Recht, dass es sich um das Geburtstagsproblem handelt. Bei einem n-Bit-Code reduziert sich das Problem des Geburtstagsparadoxons jedoch auf 2 ^ (n / 2), was in diesem Fall 2 ^ 64 ist, wie in meiner Antwort angegeben .
Bob Aman
69

Die Sache, die UUIDs Ihnen kaufen, was sonst sehr schwierig ist, ist, eine eindeutige Kennung zu erhalten, ohne eine zentrale Behörde konsultieren oder koordinieren zu müssen . Das allgemeine Problem, so etwas ohne eine verwaltete Infrastruktur zu bekommen, ist das Problem, das die UUIDs lösen.

Ich habe gelesen, dass gemäß dem Geburtstagsparadoxon die Wahrscheinlichkeit einer UUID-Kollision 50% beträgt, sobald 2 ^ 64 UUIDs generiert wurden. Jetzt ist 2 ^ 64 eine ziemlich große Zahl, aber eine 50% ige Kollisionswahrscheinlichkeit scheint viel zu riskant (zum Beispiel, wie viele UUIDs vorhanden sein müssen, bevor eine 5% ige Kollisionswahrscheinlichkeit besteht - selbst das scheint eine zu große Wahrscheinlichkeit zu sein). .

Das Problem bei dieser Analyse ist zweierlei:

  1. UUIDs sind nicht völlig zufällig - es gibt Hauptkomponenten der UUID, die zeit- und / oder ortsbezogen sind. Um eine echte Chance auf eine Kollision zu haben, müssen die kollidierenden UUIDs genau zur gleichen Zeit von verschiedenen UUID-Generatoren generiert werden. Ich würde sagen, dass es zwar eine vernünftige Chance gibt, dass mehrere UUIDs gleichzeitig generiert werden, aber es gibt genug andere Gunk (einschließlich Standortinformationen oder zufällige Bits), um die Wahrscheinlichkeit einer Kollision zwischen diesem sehr kleinen Satz von UUIDs nahezu unmöglich zu machen .

  2. Genau genommen müssen UUIDs nur unter den anderen UUIDs eindeutig sein, mit denen sie verglichen werden können. Wenn Sie eine UUID zur Verwendung als Datenbankschlüssel generieren, spielt es keine Rolle, ob an einem anderen Ort in einem bösen alternativen Universum dieselbe UUID zur Identifizierung einer COM-Schnittstelle verwendet wird. Genauso wie es keine Verwirrung stiftet, wenn jemand (oder etwas anderes) namens "Michael Burr" auf Alpha-Centauri ist.

Michael Burr
quelle
1
Konkretes Beispiel? COM / DCE-UUIDs - es gibt keine Berechtigung, sie zuzuweisen, und niemand wollte die Verantwortung übernehmen und / oder niemand wollte, dass es eine Berechtigung gibt. Verteilte Datenbanken ohne zuverlässige Links und ohne Master.
Michael Burr
3
Konkreteres Beispiel - eine Bankanwendung. Es werden mehrere Rechenzentren installiert, eines für jedes Land, wobei jedes Rechenzentrum über eine Datenbank verfügt. Die mehreren Installationen dienen dazu, unterschiedliche Vorschriften einzuhalten. Es kann nur einen Kundendatensatz im gesamten Satz für jeden Kunden geben .....
Vineet Reynolds
(Fortsetzung des vorherigen Kommentars) Sie benötigen einen zentralen Server, um die Kunden-ID für allgemeine Berichts- und Nachverfolgungszwecke (über alle Installationen hinweg) zu generieren, oder die einzelnen Installationen müssen UUIDs generieren, die als Kunden-IDs dienen (offensichtlich können die UUIDs nicht wie in verwendet werden in Berichten).
Vineet Reynolds
Wenn Sie eine 50% ige Chance auf Vervielfältigung haben, ertrinken Sie bereits. Jemand weist auf das Volumen hin, das erforderlich ist, um eine Chance von 0,0000001% zu erreichen. Mehrere Auto-Inkrement-Datenbanken, die bei 1 bis n beginnen und jedes Mal um n erhöht werden, lösen das gleiche Problem effektiv.
Gordon
2
Die Wahrscheinlichkeit, ein Duplikat zu erhalten, ist weitaus geringer als die Wahrscheinlichkeit, dass die zentrale Behörde auf
geschäftskritische
33

Alles hat eine Ausfallwahrscheinlichkeit ungleich Null. Ich würde mich auf weitaus wahrscheinlichere Probleme konzentrieren (dh auf fast alles, was Sie sich vorstellen können) als auf die Kollision von UUIDs

DanSingerman
quelle
Als Antwort auf Anfrage von
Pyrolistical
16

Eine Betonung auf "vernünftig" oder, wie Sie sagen, "effektiv": Gut genug ist, wie die reale Welt funktioniert. Der Rechenaufwand, der erforderlich ist, um diese Lücke zwischen "praktisch einzigartig" und "wirklich einzigartig" zu schließen, ist enorm. Einzigartigkeit ist eine Kurve mit sinkenden Renditen. Irgendwann auf dieser Kurve gibt es eine Grenze zwischen "einzigartig genug" ist immer noch erschwinglich, und dann biegen wir SEHR steil ab. Die Kosten für das Hinzufügen von mehr Einzigartigkeit werden ziemlich hoch. Unendliche Einzigartigkeit hat unendliche Kosten.

UUID / GUID ist relativ gesehen eine rechnerisch schnelle und einfache Möglichkeit, eine ID zu generieren, von der vernünftigerweise angenommen werden kann , dass sie universell eindeutig ist. Dies ist in vielen Systemen sehr wichtig, die Daten von zuvor nicht verbundenen Systemen integrieren müssen. Beispiel: Wenn Sie ein Content Management System haben, das auf zwei verschiedenen Plattformen ausgeführt wird, aber irgendwann den Inhalt von einem System in das andere importieren müssen. Sie möchten nicht, dass sich IDs ändern, daher bleiben Ihre Referenzen zwischen Daten aus System A erhalten, aber Sie möchten keine Kollisionen mit Daten, die in System B erstellt wurden. Eine UUID löst dies.

Rex M.
quelle
Lösung. Seien Sie nicht faul und aktualisieren Sie die Referenzen. Mach es richtig.
Pyrolistical
8
Dies hat nichts mit Faulheit zu tun. Wenn die Richtlinie lautet, dass eine ID für ein Element als dauerhaft und unveränderlich angesehen wird, ändert sich die ID nicht. Sie möchten also, dass die IDs von Anfang an eindeutig sind, und Sie möchten dies tun, ohne dass alle Systeme von Anfang an auf irgendeine Weise verbunden werden müssen.
Michael Burr
Sie brauchen dann Kontext. Wenn Sie zwei Gruppen eindeutiger IDs haben, die möglicherweise in Konflikt stehen, benötigen Sie ein hohes Maß an Kontext, um sie zu trennen
Pyrolistical
23
Oder Sie können das System einfach so bauen, dass es UUIDs verwendet und versendet, verkauft, eine Million Dollar verdient und nie eine einzige Beschwerde hört, dass zwei IDs kollidieren, weil dies nicht der Fall ist.
Rex M
16

Es ist niemals unbedingt erforderlich, eine UUID zu erstellen. Es ist jedoch praktisch, einen Standard zu haben, bei dem Offline- Benutzer jeweils einen Schlüssel für etwas mit einer sehr geringen Kollisionswahrscheinlichkeit generieren können.

Dies kann bei der Auflösung der Datenbankreplikation usw. hilfreich sein.

Es wäre für Online- Benutzer einfach , eindeutige Schlüssel für etwas zu generieren, ohne den Overhead oder die Möglichkeit einer Kollision, aber dafür sind UUIDs nicht gedacht.

Wie auch immer, ein Wort zur Kollisionswahrscheinlichkeit aus Wikipedia:

Um diese Zahlen ins rechte Licht zu rücken, wird das jährliche Risiko, von einem Meteoriten getroffen zu werden, auf eine Chance von 17 Milliarden geschätzt, was der Wahrscheinlichkeit entspricht, in einem Jahr einige zehn Billionen UUIDs zu erstellen und ein Duplikat zu haben. Mit anderen Worten, erst nachdem in den nächsten 100 Jahren pro Sekunde 1 Milliarde UUIDs generiert wurden, würde die Wahrscheinlichkeit, nur ein Duplikat zu erstellen, bei etwa 50% liegen.

John Gietzen
quelle
4
Lassen Sie Offline-Benutzer keine Schlüssel generieren. Lassen Sie die temporären Schlüssel zuweisen, bis das System online geht, damit die echten Schlüssel generiert werden können.
Pyrolistical
Dies ist meiner Meinung nach eine sehr hilfreiche Antwort ... würde eine Art Analogie zur Wahrscheinlichkeit selbst bieten, da das OP anscheinend seine Bedeutung nicht ganz verstanden hat, aber Sie scheinen das getan zu haben.
Noldorin
Ich verstehe ruhig, dass die Wahrscheinlichkeit effektiv gleich Null ist. Für mich ist die Verwendung von UUID ein faules Design, und ich wollte nur sehen, ob Sie es immer vermeiden können
Pyrolistical
Das ist fair genug, solange Sie sehen, dass die geringe Wahrscheinlichkeit auch unter extremsten Umständen berücksichtigt werden muss, wie ich jetzt annehme.
Noldorin
13

Ein klassisches Beispiel ist das Replizieren zwischen zwei Datenbanken.

DB (A) fügt einen Datensatz mit der int ID 10 ein und gleichzeitig erstellt DB (B) einen Datensatz mit der ID 10. Dies ist eine Kollision.

Bei UUIDs geschieht dies nicht, da sie nicht übereinstimmen. (Fast sicher)

Johnno Nolan
quelle
1
Ok, dann lassen Sie DB A gerade ID und DB B ungerade IDs verwenden. Fertig, keine UUID.
Pyrolistical
2
Verwenden Sie mit drei
DBs
20
Was passiert, wenn Sie später einen neuen Server zum Mix hinzufügen, wenn Sie das 2/3 / was auch immer-Vielfache verwenden? Sie müssen einen Switch so koordinieren, dass Sie auf dem neuen Server n + 1-Vielfache verwenden, und alle alten Server auf den neuen Algorithmus verschieben. Dabei müssen Sie alles herunterfahren, um Kollisionen während des Vorgangs zu vermeiden der Algorithmusschalter. Oder ... Sie könnten einfach UUIDs wie EVERYONE ELSE verwenden.
Bob Aman
3
Es ist noch schlimmer als das, denn wie würden Sie zwischen Vielfachen von 2 und Vielfachen von 4 unterscheiden? Oder Vielfache von 3 gegen Vielfache von 6? Tatsächlich müssten Sie sich an ein Vielfaches von Primzahlen halten. Blech! Verwenden Sie einfach UUID, es funktioniert. Microsoft, Apple und unzählige andere verlassen sich auf sie und vertrauen ihnen.
Sidewinderguy
2
@sidewinderguy, in GUID vertrauen wir! :)
Ron Klein
13

Es besteht auch eine Wahrscheinlichkeit ungleich Null, dass jedes Partikel in Ihrem Körper gleichzeitig durch den Stuhl tunnelt, auf dem Sie sitzen, und dass Sie plötzlich auf dem Boden sitzen.

Machst du dir darüber Sorgen?

user21714
quelle
7
Natürlich nicht, das kann ich nicht kontrollieren, aber Designs kann ich.
Pyrolistical
4
@Pyrolistical Ist das wirklich der Grund, warum du dir darüber keine Sorgen machst? Dann bist du ziemlich seltsam. Und außerdem hast du nicht recht. Sie können es steuern. Wenn Sie ein paar Pfund zunehmen, verringern Sie die Wahrscheinlichkeit eines solchen Ereignisses erheblich. Denken Sie, Sie sollten dann zunehmen? :-)
Veky
8

Ich habe ein Schema zur Vermeidung von UUIDs. Richten Sie irgendwo einen Server ein und haben Sie ihn so, dass jedes Mal, wenn eine Software eine universell eindeutige Kennung wünscht, sie diesen Server kontaktiert und eine austeilt. Einfach!

Abgesehen davon, dass es dabei einige echte praktische Probleme gibt, auch wenn wir die völlige Bosheit ignorieren. Insbesondere kann dieser Server ausfallen oder von einem Teil des Internets aus nicht mehr erreichbar sein. Der Umgang mit Serverausfällen erfordert eine Replikation, und das ist sehr schwer zu finden (siehe Literatur zum Paxos-Algorithmus, warum die Konsensbildung umständlich ist) und auch ziemlich langsam. Wenn nicht alle Server von einem bestimmten Teil des Netzes aus erreichbar sind, kann keiner der mit diesem Subnetz verbundenen Clients etwas tun, da alle auf neue IDs warten.

Also ... verwenden Sie einen einfachen probabilistischen Algorithmus, um sie zu generieren, die während der Lebensdauer der Erde wahrscheinlich nicht versagen, oder (finanzieren und) bauen Sie eine wichtige Infrastruktur, die eine Bereitstellungs-PITA sein wird und häufig ausfällt. Ich weiß, für welches ich mich entscheiden würde.

Donal Fellows
quelle
2
Tatsächlich bestand der gesamte Sinn der Erfindung von UUID darin, Ihren Ansatz zu vermeiden. Wenn Sie die Geschichte der UUIDs untersuchen, werden Sie feststellen, dass sie aus den frühesten Experimenten zur Erstellung anspruchsvoller und aussagekräftiger Computernetzwerke stammt. Sie wussten, dass Netzwerke von Natur aus unzuverlässig und kompliziert sind. UUIDs waren die Antwort auf die Frage, wie Daten zwischen Computern koordiniert werden können, wenn Sie wissen, dass sie nicht in ständiger Kommunikation stehen können.
Basil Bourque
7
@BasilBourque Ich habe in diesem ersten Absatz Sarkasmus verwendet, falls es nicht offensichtlich war.
Donal Fellows
5

Ich verstehe nicht alles über die Wahrscheinlichkeit einer Kollision. Kollisionen sind mir egal. Die Leistung ist mir jedoch wichtig.

https://dba.stackexchange.com/a/119129/33649

UUIDs sind eine Leistungskatastrophe für sehr große Tabellen. (200K Zeilen sind nicht "sehr groß".)

Ihre Nummer 3 ist wirklich schlecht, wenn das CHARCTER SET utf8 ist - CHAR (36) belegt 108 Bytes!

UUIDs (GUIDs) sind sehr "zufällig". Ihre Verwendung als EINZIGARTIGER oder PRIMÄRER Schlüssel für große Tabellen ist sehr ineffizient. Dies liegt daran, dass Sie jedes Mal, wenn Sie eine neue UUID einfügen oder nach UUID AUSWÄHLEN, um die Tabelle / den Index springen müssen. Wenn die Tabelle / der Index zu groß ist, um in den Cache zu passen (siehe innodb_buffer_pool_size, der kleiner als RAM sein muss, normalerweise 70%), wird die 'nächste' UUID möglicherweise nicht zwischengespeichert, was zu einem langsamen Festplattentreffer führt. Wenn die Tabelle / der Index 20-mal so groß wie der Cache ist, werden nur 1/20 (5%) der Treffer zwischengespeichert - Sie sind E / A-gebunden.

Verwenden Sie daher nur UUIDs

Sie haben "kleine" Tabellen, oder Sie brauchen sie wirklich, weil Sie eindeutige IDs von verschiedenen Orten generieren (und haben keinen anderen Weg gefunden, dies zu tun). Weitere Informationen zu UUIDs: http://mysql.rjweb.org/doc.php/uuid (Enthält Funktionen zum Konvertieren zwischen Standard-UUIDs mit 36 ​​Zeichen und BINARY (16).)

Es ist eine Verschwendung, sowohl eine EINZIGARTIGE AUTO_INCREMENT als auch eine EINZIGARTIGE UUID in derselben Tabelle zu haben.

Wenn ein INSERT auftritt, müssen alle eindeutigen / Primärschlüssel auf Duplikate überprüft werden. Jeder eindeutige Schlüssel reicht aus, um InnoDBs Anforderung eines PRIMARY KEY zu erfüllen. BINARY (16) (16 Bytes) ist etwas sperrig (ein Argument gegen die PK), aber nicht so schlimm. Die Sperrigkeit ist wichtig, wenn Sie Sekundärschlüssel haben. InnoDB steckt die PK stillschweigend an das Ende jedes Sekundärschlüssels. Die Hauptlektion besteht darin, die Anzahl der Sekundärschlüssel zu minimieren, insbesondere bei sehr großen Tabellen. Zum Vergleich: INT UNSIGNED ist 4 Bytes mit einem Bereich von 0,4 Milliarden. BIGINT ist 8 Bytes.

Toskan
quelle
4

Wenn Sie sich nur die Alternativen ansehen, z. B. für eine einfache Datenbankanwendung, um die Datenbank jedes Mal abfragen zu müssen, bevor Sie ein neues Objekt erstellen, werden Sie bald feststellen, dass die Verwendung von UUID die Komplexität Ihres Systems effektiv reduzieren kann. Zugegeben - wenn Sie int-Schlüssel verwenden, sind dies 32-Bit-Schlüssel, die in einem Viertel der 128-Bit-UUID gespeichert werden. Zugegeben - UUID-Generierungsalgorithmen beanspruchen mehr Rechenleistung als nur das Inkrementieren einer Zahl. Aber wen interessiert das schon? Der Aufwand für die Verwaltung einer "Autorität" zur Zuweisung ansonsten eindeutiger Nummern überwiegt leicht um Größenordnungen, abhängig von Ihrem beabsichtigten Eindeutigkeits-ID-Bereich.

Mirko Klemm
quelle
3

Auf UUID == faules Design

Ich bin nicht einverstanden, dass es darum geht, deine Kämpfe auszusuchen. Wenn eine doppelte UUID statistisch unmöglich ist und die Mathematik bewiesen ist, warum dann? Es ist unpraktisch, Zeit mit dem Entwerfen Ihres kleinen N UUID-Generierungssystems zu verbringen. Es gibt immer ein Dutzend anderer Möglichkeiten, wie Sie Ihr System verbessern können.

Johnno Nolan
quelle
1

Bei meinem letzten Job erhielten wir Objekte von Dritten, die eindeutig mit UUID identifiziert wurden. Ich habe eine UUID-> Long Integer Lookup-Tabelle eingefügt und Long Integer als Primärschlüssel verwendet, weil es auf diese Weise viel schneller war.

Paul Tomblin
quelle
Ja sicher, Dritte, die Sie zur Verwendung von UUID zwingen, sind ein weiteres Problem, auf das ich nicht eingehen möchte. Angenommen, Sie haben die Kontrolle über die Verwendung der UUID oder nicht.
Pyrolistical
Nun, eine "lange Ganzzahl" (128 Bit) ist eigentlich das, was eine UUID ist. Es wird lediglich als Zeichenfolge für den menschlichen Verzehr angezeigt. Manchmal kann es auf diese Weise übertragen werden, aber zum Speichern und Indizieren ist es sicherlich in ganzzahliger Form schneller, als Sie gefunden haben.
Nicole
1

Unter Verwendung des Algorithmus der Version 1 scheint es unmöglich zu sein, unter der Bedingung zu kollidieren, dass weniger als 10 UUIDs pro Millisekunde von derselben MAC-Adresse generiert werden

Konzeptionell bestand das ursprüngliche Generierungsschema (Version 1) für UUIDs darin, die UUID-Version mit der MAC-Adresse des Computers zu verketten, der die UUID generiert, und mit der Anzahl der 100-Nanosekunden-Intervalle seit der Einführung des Gregorianischen Kalenders im Westen . In der Praxis ist der eigentliche Algorithmus komplizierter. Dieses Schema wurde dahingehend kritisiert, dass es nicht ausreichend „undurchsichtig“ ist. Es zeigt sowohl die Identität des Computers an, der die UUID generiert hat, als auch den Zeitpunkt, zu dem dies geschehen ist.

Jemand korrigiert mich, wenn ich falsch interpretiert habe, wie es funktioniert

Davy8
quelle
Es gibt viele Versionen, und viele Softwaresysteme (z. B. Java) können Version 1 nicht verwenden, da es keine reine Java-Methode für den Zugriff auf die Mac-Adresse gibt.
Pyrolistical
In Bezug auf die Unfähigkeit von Java, die MAC-Adresse zu erhalten: Nicht ganz richtig. Hierfür gibt es Workarounds. Sie können die vom Generator verwendete MAC-Adresse manuell über eine Konfigurationsdatei einstellen. Sie können auch ifconfig aufrufen und die Ausgabe analysieren. Der von mir geschriebene Ruby-UUID-Generator verwendet beide Ansätze.
Bob Aman
Wenn Sie, wie in meiner Antwort erwähnt, keine MAC-Adresse für eine UUID der Version 1 erhalten können, verwenden Sie stattdessen 6 zufällige Bytes gemäß Abschnitt 4.5 von RFC 4122. Selbst wenn Sie keines von beiden verwenden möchten Mit den beiden Problemumgehungen für Java können Sie weiterhin eine gültige UUID der Version 1 generieren.
Bob Aman
MS GUIDs sind nur Zufallszahlen. Sie haben keinen MAC-Teil mehr, da dadurch die MAC-Adresse des Servers rückentwickelt werden konnte (was sich als sehr gefährlich herausstellte).
Stefan Steiger
1

Für diejenigen, die sagen, dass UUIDs ein schlechtes Design haben, weil sie (mit einer lächerlich geringen Wahrscheinlichkeit) kollidieren könnten , während Ihre von der DB generierten Schlüssel nicht ... Sie kennen die Möglichkeit menschlicher Fehler, die aufgrund einiger Un eine Kollision mit Ihren von der DB generierten Schlüsseln verursachen - Der voraussichtliche Bedarf ist weitaus höher als die Wahrscheinlichkeit einer UUID4-Kollision. Wir wissen, dass wenn die Datenbank neu erstellt wird, die IDs erneut bei 1 beginnen und wie viele von uns mussten eine Tabelle neu erstellen, als wir sicher waren, dass wir das niemals brauchen würden? Ich würde mein Geld auf UUID-Sicherheit setzen, wenn jeden Tag etwas mit Unbekannten-Unbekannten schief geht.

Iain Duncan
quelle
0

Abgesehen von Fällen, in denen Sie die API einer anderen Person verwenden müssen, die eine UUID erfordert, gibt es natürlich immer eine andere Lösung. Aber werden diese Alternativen alle Probleme lösen , die UUIDs machen? Werden Sie am Ende mehr Schichten von Hacks hinzufügen, um jeweils ein anderes Problem zu lösen, wenn Sie alle auf einmal hätten lösen können?

Ja, es ist theoretisch möglich, dass UUIDs kollidieren. Wie andere angemerkt haben, ist es lächerlich unwahrscheinlich, dass es einfach nicht erwägenswert ist. Es ist bisher noch nie passiert und wird es höchstwahrscheinlich nie tun. Vergiss es.

Der "offensichtlichste" Weg, um Kollisionen zu vermeiden, besteht darin, einen einzelnen Server auf jeder Einfügung eindeutige IDs generieren zu lassen, was offensichtlich schwerwiegende Leistungsprobleme verursacht und das Problem der Offline-Generierung überhaupt nicht löst. Hoppla.

Die andere "offensichtliche" Lösung ist eine zentrale Behörde, die Blöcke mit eindeutigen Nummern im Voraus verteilt. Dies ist im Wesentlichen das, was UUID V1 unter Verwendung der MAC-Adresse der Erzeugungsmaschine (über die IEEE-OUI) tut. Es kommt jedoch zu doppelten MAC-Adressen, weil jede zentrale Behörde irgendwann Fehler macht. In der Praxis ist dies weitaus wahrscheinlicher als eine UUID V4-Kollision. Hoppla.

Das beste Argument gegen die Verwendung von UUIDs ist, dass sie "zu groß" sind, aber ein (erheblich) kleineres Schema wird die interessantesten Probleme unweigerlich nicht lösen können. Die Größe von UUIDs ist ein inhärenter Nebeneffekt ihrer Nützlichkeit bei der Lösung genau dieser Probleme.

Möglicherweise ist Ihr Problem nicht groß genug, um das zu benötigen, was UUIDs bieten. In diesem Fall können Sie auch etwas anderes verwenden. Wenn Ihr Problem jedoch unerwartet auftritt (und die meisten auch), wechseln Sie später - und treten sich selbst dafür, dass Sie sie überhaupt nicht verwendet haben. Warum für Misserfolg entwerfen, wenn es genauso einfach ist, für Erfolg zu entwerfen?

StephenS
quelle
-10

UUIDs verkörpern alle schlechten Codierungspraktiken, die mit globalen Variablen verbunden sind, nur schlimmer, da es sich um superglobale Variablen handelt, die auf verschiedene Teile des Kits verteilt werden können.

Vor kurzem trat ein solches Problem beim Ersetzen eines Druckers durch ein genaues Ersatzmodell auf und stellte fest, dass keine der Client-Software funktionieren würde.

John Doe
quelle
2
Ich bin froh, dass wir in einer Gesellschaft leben, die sich immer noch auf Fakten konzentriert, im Gegensatz zu zufälligen Meinungen, sonst wären wir alle, wenn es um Stapelüberlauf geht, arbeitslos. :)
Makarand