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

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.

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.

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.

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

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.

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.

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)

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?

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.

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.

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.

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.

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.

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

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.

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?

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.