Die häufigste Frage, die ich über Couchbase und andere NoSQL-Datenbanken erhalte, ist die Generierung eindeutiger Schlüssel für Datensätze - oder genauer gesagt, die AUTO INCREMENT-Funktion einer allgemeinen Relation Datenbanken.Verwenden eines Inkrementierungszählers für die Generierung eines eindeutigen Schlüssels in einem Couchbase-Cluster
Die Lösung in Couchbase, die oft erwähnt wird, ist die Inkrement-Funktion, wo Sie Inkrement auf einer numerischen Taste aufrufen können, und es wird eine neue eindeutige Nummer in Folge generieren.
Meine Frage zu diesem Thema ist, dass ich das massive Problem, das ich bei der Replikation voraussehe, nicht verstehen kann.
Stellen Sie sich vor, Sie haben einen Cluster von drei Couchbase-Knoten und Sie speichern ein Anforderungsprotokoll. Sie möchten dieses Protokoll eingeben, um einen Eintrag namens "requestlog_counter" zu erstellen.
Jetzt sagen wir, wir haben 4 Web-Knoten, die jeweils 20 Anfragen pro Sekunde erhalten und jede davon muss als "Anfrage :: {ID})" aufgezeichnet werden. Das sind 80 Anfragen pro Sekunde.
Angenommen, die Knoten 1 und 3 haben ein kleines bisschen Netzwerklatenz, aber beide empfangen eine dieser 40 Anfragen zur gleichen Zeit. Ihr Skript inkrementiert den Anforderungszähler (sagen wir für dieses Beispiel ist es zZ bei 1500) und erhält eine ID. Sicherlich ist es jetzt möglich, dass BEIDe Couchbase-Instanzen 1501 zu den Web-Knoten 1 und 3 zurückbringen und beide Server versuchen nun, die Anfrage, die sie behandeln, als "request: 1501" zu speichern.
Jetzt wird die Replikation damit umgehen und im Wesentlichen wird die neueste gewinnen. Aber Sie haben jetzt den Datensatz einer Anfrage verloren.
Bedeutet das nun, dass Sie in der Realität eine bessere Möglichkeit zum Eintippen wichtiger Daten benötigen und dass die Verwendung von Autoinkrementen für absolute Werte und eine eindeutige Schlüsselgenerierung in einer NoSQL-Clusterumgebung vermieden werden sollte?
Oder - gibt es etwas, was Sie als Teil Ihrer Schlüsselgenerierungsprozedur tun können, die diese 100% zuverlässig macht.
Bitte berücksichtigen Sie auch eine multiple Cluster-Umgebung, die auch die cross-rechenzentrums-Replikation verwendet.
Danke.
Mike
OK Berücksichtigen Sie das Replikationsbeispiel für das Cross-Data Center. Angenommen, die Verbindung zwischen DC1 und DC2 wird für 5 Sekunden unterbrochen, und während dieser Zeit empfangen und verarbeiten DC1 und DC2 jeweils 200 Anfragen. Was passiert jetzt mit unserem Auto-Inc, dann sind die Autoinkremente beide auf 1700 gestiegen und beide DC's haben Records mit dieser ID gespeichert. Was passiert dann? Ein Speicherbefehl wird in dieser Situation nicht fehlschlagen und so, atomar oder nicht, wird die Operation zu etwas ziemlich Schrecklichem führen, das mit der Datenkonsistenz passiert? –
Wie gesagt, Inkrement ist atomar in einem Cluster.Wenn Sie planen, XDCR zu verwenden, müssen Sie etwas wie Cluster-ID in Ihr "Autoincrement" hinzufügen. I.e. 'Anfrage:: ' oder 'Anfrage: : '. In diesem Fall wird Ihr Schlüssel, auch wenn Sie zwei identische automatisch inkrementierte IDs erhalten, eindeutig sein, weil er eine eindeutige 'cluster_id' hat. Aber für mich, wenn ich XDCR brauche, werde ich nur GUIDs verwenden und etwas wie Zeitstempel hinzufügen, um Werte zu sortieren und sich nicht um atomare Operationen zu kümmern. –
m03geek
OK, das klärt es auf. Ich habe angenommen, dass dies der Fall ist, wenn ich die Frage stelle, und ich bin mir sicher, dass andere in Zukunft die gleichen Fragen stellen werden, wenn sie von einem RDB zu NoSQL wechseln. Oder was eher passiert, ist, dass jemand dies nicht berücksichtigt und es wird alles auseinander fallen, sobald sie XDCR einführen - hoffentlich wird dies ihnen erklären, was schief gelaufen ist und ihnen eine Möglichkeit zur Lösung des Problems bieten. Danke für die Bestätigungen und Hinweise m03geek. –