Die nächste HighLoad++-Konferenz findet am 6. und 7. April 2020 in St. Petersburg statt.
Details und Tickets . HighLoad++ Sibirien 2019. Halle „Krasnojarsk“. 25. Juni, 12:00 Uhr. Thesen und .
Es kommt vor, dass praktische Anforderungen mit der Theorie im Widerspruch stehen und Aspekte, die für ein kommerzielles Produkt wichtig sind, nicht berücksichtigt werden. Dieser Vortrag stellt einen Prozess zur Auswahl und Kombination verschiedener Ansätze zur Erstellung kausaler Konsistenzkomponenten vor, die auf akademischer Forschung basieren und auf den Anforderungen eines kommerziellen Produkts basieren. Die Zuhörer erfahren mehr über bestehende theoretische Ansätze zu logischen Uhren, Abhängigkeitsverfolgung, Systemsicherheit, Uhrensynchronisation und warum sich MongoDB für bestimmte Lösungen entschieden hat.
Mikhail Tyulenev (im Folgenden MT genannt): – Ich werde über kausale Konsistenz sprechen – das ist eine Funktion, an der wir in MongoDB gearbeitet haben. Ich arbeite in einer Gruppe verteilter Systeme. Wir haben das vor etwa zwei Jahren gemacht.
Dabei musste ich mich in viele wissenschaftliche Untersuchungen einarbeiten, da diese Funktion recht gut untersucht ist. Es stellte sich heraus, dass aufgrund der sehr spezifischen Anforderungen, die wahrscheinlich in jeder Produktionsanwendung vorhanden sind, kein einziger Artikel in die Anforderungen der Produktion, die Datenbank, passt.
Ich werde darüber sprechen, wie wir als Konsumenten akademischer Forschung daraus etwas zubereiten, das wir dann unseren Nutzern als Fertiggericht präsentieren können, das bequem und sicher zu verwenden ist.
Kausale Konsistenz. Lassen Sie uns die Konzepte definieren
Zunächst möchte ich allgemein sagen, was kausale Konsistenz ist. Es gibt zwei Charaktere – Leonard und Penny (TV-Serie „The Big Bang Theory“):
Nehmen wir an, Penny ist in Europa und Leonard möchte ihr eine Überraschungsparty schmeißen. Und ihm fällt nichts Besseres ein, als sie von seiner Freundesliste zu streichen und allen seinen Freunden im Feed ein Update zu schicken: „Lasst uns Penny glücklich machen!“ (Sie ist in Europa, während sie schläft, sieht sie das alles nicht und kann es nicht sehen, weil sie nicht dort ist). Letztendlich löscht sie diesen Beitrag, löscht ihn aus dem Feed und stellt den Zugriff wieder her, sodass sie nichts merkt und es keinen Skandal gibt.
Das ist alles schön und gut, aber gehen wir davon aus, dass das System verteilt ist und etwas schief gelaufen ist. Es kann beispielsweise vorkommen, dass Pennys Zugangsbeschränkung nach Erscheinen dieses Beitrags erfolgte, wenn die Ereignisse nicht durch Ursache und Wirkung zusammenhängen. Tatsächlich ist dies ein Beispiel dafür, wann kausale Konsistenz erforderlich ist, um eine Geschäftsfunktion auszuführen (in diesem Fall).
Tatsächlich sind dies keine trivialen Eigenschaften der Datenbank – nur sehr wenige Menschen unterstützen sie. Kommen wir zu den Modellen.
Konsistenzmodelle
Was genau ist ein Konsistenzmodell in Datenbanken? Dies sind einige der Garantien, die ein verteiltes System darüber gibt, welche Daten der Client in welcher Reihenfolge empfangen kann.
Grundsätzlich kommt es bei allen Konsistenzmodellen darauf an, wie ähnlich ein verteiltes System einem System ist, das beispielsweise auf einem Knoten auf einem Laptop läuft. Und so ähnlich ist ein System, das auf Tausenden von geografisch verteilten „Nodes“ läuft, einem Laptop, bei dem alle diese Eigenschaften im Prinzip automatisch ausgeführt werden.
Daher werden Konsistenzmodelle nur auf verteilte Systeme angewendet. Bei allen zuvor existierenden und mit der gleichen vertikalen Skalierung betriebenen Systemen traten solche Probleme nicht auf. Es gab einen Puffercache, aus dem immer alles gelesen wurde.
Modell Stark
Tatsächlich ist das allererste Modell Strong (oder die Aufstiegsfähigkeitslinie, wie es oft genannt wird). Hierbei handelt es sich um ein Konsistenzmodell, das sicherstellt, dass jede Änderung, sobald sie bestätigt wurde, für alle Benutzer des Systems sichtbar ist.
Dadurch wird eine globale Reihenfolge aller Ereignisse in der Datenbank erstellt. Dies ist eine sehr starke Konsistenzeigenschaft und im Allgemeinen sehr teuer. Es wird jedoch sehr gut unterstützt. Es ist einfach sehr teuer und langsam – es wird nur selten verwendet. Dies nennt man Aufstiegsfähigkeit.
Es gibt eine weitere, stärkere Eigenschaft, die in Spanner unterstützt wird – die sogenannte externe Konsistenz. Wir werden etwas später darüber reden.
Kausal
Das nächste ist Kausal, und das ist genau das, worüber ich gesprochen habe. Es gibt mehrere weitere Unterebenen zwischen Stark und Kausal, auf die ich nicht näher eingehen werde, aber sie alle laufen auf Kausal hinaus. Dies ist ein wichtiges Modell, da es das stärkste aller Modelle ist und die stärkste Konsistenz bei Vorhandensein eines Netzwerks oder von Partitionen aufweist.
Kausalitäten sind eigentlich Situationen, in denen Ereignisse durch eine Ursache-Wirkungs-Beziehung verbunden sind. Sehr oft werden sie aus Sicht des Kunden als Leserechte wahrgenommen. Wenn der Klient einige Werte beobachtet hat, kann er keine Werte sehen, die in der Vergangenheit lagen. Er fängt bereits an, Präfix-Lesungen zu erkennen. Es läuft alles auf dasselbe hinaus.
Kausalitäten als Konsistenzmodell sind eine teilweise Reihenfolge von Ereignissen auf dem Server, bei der Ereignisse von allen Clients in derselben Reihenfolge beobachtet werden. In diesem Fall Leonard und Penny.
Eventuell
Das dritte Modell ist Eventual Consistency. Das ist es, was absolut alle verteilten Systeme unterstützen, das Minimalmodell, das überhaupt Sinn macht. Das bedeutet Folgendes: Wenn sich die Daten ändern, werden sie irgendwann konsistent.
In einem solchen Moment sagt sie nichts, sonst würde sie sich in externe Konsistenz verwandeln – das wäre eine ganz andere Geschichte. Dennoch ist dies ein sehr beliebtes und am weitesten verbreitetes Modell. Standardmäßig verwenden alle Benutzer verteilter Systeme Eventual Consistency.
Ich möchte einige Vergleichsbeispiele nennen:
Was bedeuten diese Pfeile?
- Latenz. Mit zunehmender Konsistenzstärke wird sie aus offensichtlichen Gründen größer: Sie müssen mehr Datensätze erstellen und von allen Hosts und Knoten, die am Cluster teilnehmen, eine Bestätigung erhalten, dass die Daten bereits vorhanden sind. Die schnellste Antwort gibt dementsprechend Eventual Consistency, denn dort kann man es sich in der Regel sogar einprägen und das wird im Prinzip auch ausreichen.
- Verfügbarkeit. Wenn wir darunter die Fähigkeit des Systems verstehen, auf Netzwerkunterbrechungen, Partitionen oder irgendeine Art von Fehler zu reagieren, steigt die Fehlertoleranz mit abnehmendem Konsistenzmodell, da es für uns ausreicht, dass ein Host gleichzeitig lebt Die Zeit produziert einige Daten. Eventual Consistency garantiert überhaupt nichts über die Daten – es kann alles sein.
- Anomalien. Gleichzeitig nimmt natürlich die Zahl der Anomalien zu. Bei starker Konsistenz sollten sie fast gar nicht existieren, aber bei eventueller Konsistenz können sie alles sein. Es stellt sich die Frage: Warum entscheiden sich Menschen für Eventual Consistency, wenn sie Anomalien enthält? Die Antwort ist, dass Eventual Consistency-Modelle anwendbar sind und Anomalien beispielsweise in einem kurzen Zeitraum auftreten; Mit dem Assistenten ist es möglich, mehr oder weniger konsistente Daten auszulesen. Es ist oft möglich, starke Konsistenzmodelle zu verwenden. In der Praxis funktioniert das, und oft ist die Anzahl der Anomalien zeitlich begrenzt.
CAP-Theorem
Was kommt Ihnen in den Sinn, wenn Sie die Worte Konsistenz und Verfügbarkeit sehen? Das ist richtig – CAP-Theorem! Jetzt möchte ich mit dem Mythos aufräumen... Das bin nicht ich, sondern Martin Kleppmann, der einen wunderbaren Artikel, ein wunderbares Buch geschrieben hat.
Das CAP-Theorem ist ein in den 2000er Jahren formuliertes Prinzip: Konsistenz, Verfügbarkeit, Partitionen: Nehmen Sie zwei beliebige, und Sie können nicht drei auswählen. Es war ein bestimmtes Prinzip. Es wurde einige Jahre später von Gilbert und Lynch als Theorem bewiesen. Dann wurde dies als Mantra verwendet – Systeme wurden in CA, CP, AP usw. unterteilt.
Dieses Theorem wurde tatsächlich für die folgenden Fälle bewiesen: Erstens wurde die Verfügbarkeit nicht als kontinuierlicher Wert von Null bis Hunderten betrachtet (0 – das System ist „tot“, 100 – reagiert schnell; wir sind es gewohnt, es so zu betrachten) , sondern als Eigenschaft des Algorithmus, die garantiert, dass er für alle seine Ausführungen Daten zurückgibt.
Zur Reaktionszeit gibt es überhaupt kein Wort! Es gibt einen Algorithmus, der Daten nach 100 Jahren zurückgibt – ein absolut wunderbarer verfügbarer Algorithmus, der Teil des CAP-Theorems ist.
Zweitens: Der Satz wurde für Änderungen der Werte desselben Schlüssels bewiesen, obwohl diese Änderungen in der Größe veränderbar sind. Dies bedeutet, dass sie in der Realität praktisch nicht verwendet werden, da die Modelle unterschiedliche Eventual Consistency und Strong Consistency (vielleicht) sind.
Wofür ist das alles? Darüber hinaus ist das CAP-Theorem in genau der Form, in der es bewiesen wurde, praktisch nicht anwendbar und wird selten verwendet. In theoretischer Form schränkt es irgendwie alles ein. Es stellt sich heraus, dass es sich um ein bestimmtes Prinzip handelt, das intuitiv richtig ist, aber im Allgemeinen nicht bewiesen wurde.
Kausale Konsistenz ist das stärkste Modell
Was jetzt passiert, ist, dass Sie alle drei Dinge erreichen können: Konsistenz, Verfügbarkeit mithilfe von Partitionen. Insbesondere ist die kausale Konsistenz das stärkste Konsistenzmodell, das auch bei Vorhandensein von Partitionen (Unterbrechungen im Netzwerk) noch funktioniert. Deshalb ist es von so großem Interesse und deshalb haben wir es aufgegriffen.
Erstens vereinfacht es die Arbeit der Anwendungsentwickler. Insbesondere das Vorhandensein einer großartigen Unterstützung durch den Server: Wenn alle Datensätze, die innerhalb eines Clients auftreten, garantiert in der gleichen Reihenfolge auf einem anderen Client ankommen. Zweitens hält es Trennwänden stand.
MongoDB Interne Küche
Als wir uns daran erinnern, dass es Mittagessen ist, gehen wir in die Küche. Ich werde Ihnen etwas über das Systemmodell erzählen, nämlich was MongoDB für diejenigen ist, die zum ersten Mal von einer solchen Datenbank hören.
MongoDB (im Folgenden „MongoDB“ genannt) ist ein verteiltes System, das horizontale Skalierung, also Sharding, unterstützt; und innerhalb jedes Shards unterstützt es auch Datenredundanz, also die Replikation.
Sharding in MongoDB (keine relationale Datenbank) führt einen automatischen Ausgleich durch, d. h. jede Sammlung von Dokumenten (oder „Tabelle“ im Sinne relationaler Daten) wird in Teile geteilt und der Server verschiebt sie automatisch zwischen Shards.
Der Query Router, der Anfragen für einen Client verteilt, ist ein Client, über den er arbeitet. Es weiß bereits, wo und welche Daten sich befinden und leitet alle Anfragen an den richtigen Shard weiter.
Ein weiterer wichtiger Punkt: MongoDB ist ein Single Master. Es gibt eine primäre Datenbank – sie kann Datensätze aufnehmen, die die darin enthaltenen Schlüssel unterstützen. Sie können keinen Multi-Master-Schreibvorgang ausführen.
Wir haben Version 4.2 erstellt – dort sind neue interessante Dinge aufgetaucht. Insbesondere fügten sie Lucene – eine Suche – ein, nämlich ausführbares Java direkt in Mongo, und dort wurde es möglich, Suchvorgänge über Lucene durchzuführen, genau wie in Elastica.
Und sie haben ein neues Produkt entwickelt – Charts, es ist auch auf Atlas (Mongos eigener Cloud) verfügbar. Sie haben ein kostenloses Kontingent – Sie können damit herumspielen. Charts hat mir sehr gut gefallen – Datenvisualisierung, sehr intuitiv.
Zutaten Kausale Konsistenz
Ich habe etwa 230 Artikel gezählt, die zu diesem Thema veröffentlicht wurden – von Leslie Lampert. Aus meiner Erinnerung werde ich Ihnen nun einige Teile dieser Materialien übermitteln.
Alles begann mit einem Artikel von Leslie Lampert, der in den 1970er Jahren geschrieben wurde. Wie Sie sehen, ist die Forschung zu diesem Thema noch im Gange. Mittlerweile erfährt die kausale Konsistenz im Zusammenhang mit der Entwicklung verteilter Systeme Interesse.
Einschränkungen
Welche Einschränkungen gibt es? Dies ist tatsächlich einer der Hauptpunkte, denn die Einschränkungen, die ein Produktionssystem auferlegt, unterscheiden sich stark von den Einschränkungen, die in wissenschaftlichen Artikeln bestehen. Sie sind oft ziemlich künstlich.
- Erstens ist „MongoDB“, wie ich bereits sagte, ein einzelner Master (das vereinfacht dies erheblich).
- Wir glauben, dass das System etwa 10 Shards unterstützen sollte. Wir können keine architektonischen Entscheidungen treffen, die diesen Wert explizit einschränken.
- Wir haben eine Cloud, aber wir gehen davon aus, dass eine Person immer noch die Möglichkeit haben sollte, wenn sie Binärdateien herunterlädt, sie auf ihrem Laptop ausführt und alles großartig funktioniert.
- Wir gehen von etwas aus, von dem Research selten ausgeht: Externe Kunden können tun und lassen, was sie wollen. MongoDB ist Open Source. Dementsprechend können Klienten so schlau und wütend sein, dass sie den Wunsch haben, alles kaputt zu machen. Wir spekulieren, dass byzantinische Feiloren ihren Ursprung haben könnten.
- Für externe Clients, die sich außerhalb des Perimeters befinden, gibt es eine wichtige Einschränkung: Wenn diese Funktion deaktiviert ist, sollte keine Leistungseinbuße zu beobachten sein.
- Ein weiterer Punkt ist generell antiakademisch: die Kompatibilität früherer und zukünftiger Versionen. Alte Treiber müssen neue Updates unterstützen und die Datenbank muss alte Treiber unterstützen.
Im Allgemeinen bringt dies alles Einschränkungen mit sich.
Kausale Konsistenzkomponenten
Ich werde jetzt auf einige der Komponenten eingehen. Wenn wir kausale Konsistenz im Allgemeinen betrachten, können wir Blöcke auswählen. Wir haben aus Werken ausgewählt, die zu einem bestimmten Block gehören: Dependency Tracking, Uhren auswählen, wie diese Uhren miteinander synchronisiert werden können und wie wir Sicherheit gewährleisten – das ist ein grober Überblick darüber, worüber ich sprechen werde:
Vollständige Abhängigkeitsverfolgung
Warum wird es benötigt? Wenn also Daten repliziert werden, enthält jeder Datensatz und jede Datenänderung Informationen darüber, von welchen Änderungen sie abhängt. Die allererste und naive Änderung besteht darin, dass jede Nachricht, die einen Datensatz enthält, Informationen über vorherige Nachrichten enthält:
In diesem Beispiel handelt es sich bei der Zahl in geschweiften Klammern um die Datensatznummern. Manchmal werden diese Datensätze mit Werten sogar vollständig übertragen, manchmal werden einige Versionen übertragen. Die Quintessenz ist, dass jede Änderung Informationen über die vorherige enthält (offensichtlich alles in sich trägt).
Warum haben wir uns entschieden, diesen Ansatz (vollständiges Tracking) nicht zu verwenden? Offensichtlich, weil dieser Ansatz unpraktisch ist: Jede Änderung an einem sozialen Netzwerk hängt von allen vorherigen Änderungen an diesem sozialen Netzwerk ab, wobei beispielsweise Facebook oder VKontakte bei jedem Update übertragen werden. Dennoch gibt es eine Menge Forschung zum Thema „Full Dependency Tracking“ – dabei handelt es sich um vorsoziale Netzwerke; in manchen Situationen funktioniert es wirklich.
Explizite Abhängigkeitsverfolgung
Der nächste ist begrenzter. Dabei wird auch die Weitergabe von Informationen berücksichtigt, jedoch nur die, die eindeutig abhängig sind. Was davon abhängt, wird in der Regel durch den Antrag bestimmt. Wenn Daten repliziert werden, gibt die Abfrage nur dann Antworten zurück, wenn vorherige Abhängigkeiten erfüllt, also angezeigt, wurden. Dies ist die Essenz der Funktionsweise der kausalen Konsistenz.
Sie sieht, dass Datensatz 5 von den Datensätzen 1, 2, 3, 4 abhängt – dementsprechend wartet sie, bis der Client Zugriff auf die durch Pennys Zugriffsentscheidung vorgenommenen Änderungen hat, wenn alle vorherigen Änderungen bereits die Datenbank durchlaufen haben.
Das passt auch nicht zu uns, denn es gibt immer noch zu viele Informationen, und das wird die Dinge verlangsamen. Es gibt noch einen anderen Ansatz...
Lamport-Uhr
Sie sind sehr alt. Lamport Clock bedeutet, dass diese Abhängigkeiten in eine Skalarfunktion gefaltet werden, die Lamport Clock genannt wird.
Eine Skalarfunktion ist eine abstrakte Zahl. Sie wird oft als logische Zeit bezeichnet. Mit jedem Ereignis erhöht sich dieser Zähler. Der dem Prozess aktuell bekannte Zähler sendet jede Nachricht. Es ist klar, dass Prozesse nicht synchron sein können, sie können völlig unterschiedliche Zeiten haben. Dennoch gleicht das System mit solchen Nachrichten irgendwie die Uhr aus. Was passiert in diesem Fall?
Ich habe diesen großen Shard zur Verdeutlichung in zwei Teile geteilt: Freunde können in einem Knoten leben, der einen Teil der Sammlung enthält, und Feed kann in einem anderen Knoten leben, der einen Teil dieser Sammlung enthält. Ist klar, wie sie aus der Reihe geraten können? Zuerst wird im Feed „Repliziert“ und dann „Freunde“ angezeigt. Wenn das System keine Garantie dafür bietet, dass der Feed nicht angezeigt wird, bis auch die Friends-Abhängigkeiten in der Friends-Sammlung bereitgestellt werden, dann haben wir genau die Situation, die ich erwähnt habe.
Sie sehen, wie sich die Zählerzeit im Feed logischerweise erhöht:
Die Haupteigenschaft dieser Lamport-Uhr und der Kausalkonsistenz (erklärt durch die Lamport-Uhr) ist also diese: Wenn wir Ereignisse A und B haben und Ereignis B von Ereignis A* abhängt, dann folgt daraus, dass die logische Zeit von Ereignis A kleiner als ist LogicalTime von Ereignis B.
* Manchmal sagt man auch, dass A vor B passiert ist, das heißt, A ist vor B passiert – dies ist eine bestimmte Beziehung, die die gesamte Reihe von Ereignissen, die im Allgemeinen passiert sind, teilweise ordnet.
Das Gegenteil ist falsch. Dies ist tatsächlich einer der Hauptnachteile der Lamport-Uhr – die teilweise Ordnung. Es gibt ein Konzept über gleichzeitige Ereignisse, also Ereignisse, bei denen weder (A vor B geschah) noch (A vor B geschah). Ein Beispiel wäre Leonards paralleles Hinzufügen einer anderen Person als Freund (nicht einmal Leonard, sondern zum Beispiel Sheldon).
Dies ist die Eigenschaft, die häufig bei der Arbeit mit Lamport-Uhren verwendet wird: Sie betrachten speziell die Funktion und schließen daraus, dass diese Ereignisse möglicherweise abhängig sind. Denn ein Weg ist wahr: Wenn LogicalTime A kleiner als LogicalTime B ist, kann B nicht vor A passieren; und wenn mehr, dann vielleicht.
Vektoruhr
Die logische Weiterentwicklung der Lamport-Uhr ist die Vector Clock. Sie unterscheiden sich dadurch, dass jeder Knoten, der sich hier befindet, seine eigene separate Uhr enthält und sie als Vektor übertragen werden.
In diesem Fall sehen Sie, dass der nullte Index des Vektors für Feed verantwortlich ist und der erste Index des Vektors für Friends (jeder dieser Knoten) ist. Und jetzt werden sie zunehmen: Der Nullindex von „Feed“ steigt beim Schreiben – 1, 2, 3:
Warum ist Vector Clock besser? Weil Sie damit herausfinden können, welche Ereignisse gleichzeitig stattfinden und wann sie auf verschiedenen Knoten auftreten. Dies ist für ein Sharding-System wie MongoDB sehr wichtig. Wir haben uns jedoch nicht dafür entschieden, obwohl es eine wunderbare Sache ist, großartig funktioniert und wahrscheinlich zu uns passen würde ...
Wenn wir 10 Shards haben, können wir keine 10 Komponenten übertragen, selbst wenn wir sie komprimieren oder uns etwas anderes einfallen lassen – die Nutzlast wird immer noch um ein Vielfaches kleiner sein als das Volumen dieses gesamten Vektors. Deshalb haben wir mit zusammengebissenen Herzen und Zähnen diesen Ansatz aufgegeben und sind zu einem anderen übergegangen.
Schraubenschlüssel TrueTime. Atomuhr
Ich sagte, es würde eine Geschichte über Spanner geben. Das ist eine coole Sache, direkt aus dem XNUMX. Jahrhundert: Atomuhren, GPS-Synchronisation.
Was ist die Idee? „Spanner“ ist ein Google-System, das seit kurzem sogar für Menschen verfügbar ist (sie haben SQL hinzugefügt). Jede Transaktion dort hat einen Zeitstempel. Da die Zeit synchronisiert ist*, kann jedem Ereignis eine bestimmte Zeit zugeordnet werden – Atomuhren haben eine Wartezeit, nach der garantiert eine andere Zeit „eintritt“.
Somit wird die Serialisierbarkeit des Ereignisses automatisch gewährleistet, indem einfach in die Datenbank geschrieben und einige Zeit gewartet wird. Sie verfügen über das stärkste Konsistenzmodell, das man sich im Prinzip vorstellen kann – es ist die externe Konsistenz.
* Dies ist das Hauptproblem bei Lampart-Uhren – sie sind auf verteilten Systemen niemals synchron. Sie können voneinander abweichen; selbst mit NTP funktionieren sie immer noch nicht sehr gut. „Spanner“ hat eine Atomuhr und die Synchronisation scheint im Mikrosekundenbereich zu liegen.
Warum haben wir uns nicht entschieden? Wir gehen nicht davon aus, dass unsere Nutzer über eine eingebaute Atomuhr verfügen. Wenn sie auftauchen und in jeden Laptop eingebaut sind, wird es eine Art supercoole GPS-Synchronisierung geben – dann ja … Aber im Moment ist das Beste, was möglich ist, Amazon, Basisstationen – für Fanatiker … Also haben wir andere Uhren verwendet .
Hybriduhr
Dies ist tatsächlich das, was in MongoDB tickt, wenn es um die Gewährleistung der kausalen Konsistenz geht. Wie sind sie hybrid? Hybrid ist ein Skalarwert, der jedoch aus zwei Komponenten besteht:
- Die erste ist die Unix-Epoche (wie viele Sekunden sind seit dem „Beginn der Computerwelt“ vergangen).
- Das zweite ist ein Inkrement, ebenfalls ein 32-Bit-Int ohne Vorzeichen.
Das ist eigentlich alles. Es gibt diesen Ansatz: Der Teil, der für die Zeit verantwortlich ist, ist ständig mit der Uhr synchronisiert; Bei jeder Aktualisierung wird dieser Teil mit der Uhr synchronisiert und es stellt sich heraus, dass die Zeit immer mehr oder weniger korrekt ist. Mithilfe der Inkrementierung können Sie zwischen Ereignissen unterscheiden, die zum gleichen Zeitpunkt aufgetreten sind.
Warum ist das für MongoDB wichtig? Denn es ermöglicht Ihnen, zu einem bestimmten Zeitpunkt eine Art Ersatzrestaurant zu erstellen, das heißt, das Ereignis wird nach Zeit indiziert. Dies ist wichtig, wenn bestimmte Ereignisse erforderlich sind; Bei einer Datenbank handelt es sich bei Ereignissen um Änderungen in der Datenbank, die in bestimmten Zeitintervallen auftreten.
Den wichtigsten Grund verrate ich nur Ihnen selbst (bitte niemandem erzählen)! Wir haben dies getan, weil organisierte, indizierte Daten in MongoDB OpLog so aussehen. OpLog ist eine Datenstruktur, die absolut alle Änderungen in der Datenbank enthält: Sie gehen zuerst zu OpLog und werden dann auf den Speicher selbst angewendet, falls es sich um ein repliziertes Datum oder einen replizierten Shard handelt.
Dies war der Hauptgrund. Dennoch gibt es auch praktische Anforderungen an die Entwicklung einer Datenbank, das heißt, sie sollte einfach sein – wenig Code, möglichst wenig kaputte Dinge, die neu geschrieben und getestet werden müssen. Die Tatsache, dass unsere Oplogs durch Hybriduhren indiziert wurden, hat uns sehr geholfen und uns ermöglicht, die richtige Wahl zu treffen. Es hat sich wirklich gelohnt und beim allerersten Prototyp irgendwie wie von Zauberhand funktioniert. Es war sehr cool!
Uhrzeitsynchronisation
In der wissenschaftlichen Literatur werden mehrere Synchronisationsmethoden beschrieben. Ich spreche von Synchronisierung, wenn wir zwei verschiedene Shards haben. Wenn ein Replikatsatz vorhanden ist, ist keine Synchronisierung erforderlich: Dies ist ein „einzelner Master“. wir haben ein OpLog, in das alle Änderungen fallen – in diesem Fall ist alles bereits im „Oplog“ selbst sequentiell geordnet. Aber wenn wir zwei verschiedene Shards haben, ist hier die Zeitsynchronisation wichtig. Hier hat die Vektoruhr mehr geholfen! Aber wir haben sie nicht.
Der zweite ist geeignet – das ist „Heartbeats“. Es ist möglich, einige Signale, die in jeder Zeiteinheit auftreten, auszutauschen. Aber Heartbeats sind zu langsam, wir können unserem Kunden keine Latenz bieten.
Wahre Zeit ist natürlich eine wunderbare Sache. Aber auch das ist wahrscheinlich die Zukunft ... Obwohl dies bereits in Atlas möglich ist, gibt es bereits schnelle „Amazon“-Zeitsynchronisierer. Aber es wird nicht für jeden verfügbar sein.
Klatschen ist, wenn alle Nachrichten Zeit enthalten. Das ist ungefähr das, was wir verwenden. Jede Nachricht zwischen Knoten, ein Treiber, ein Datenknoten-Router, einfach alles für MongoDB ist eine Art Element, eine Datenbankkomponente, die eine Uhr enthält, die läuft. Sie haben überall die Bedeutung hybrider Zeit, sie wird übertragen. 64 Bit? Das erlaubt, das ist möglich.
Wie funktioniert das alles zusammen?
Hier schaue ich mir ein Replika-Set an, um es etwas einfacher zu machen. Es gibt Primär- und Sekundärschulen. Der sekundäre Server repliziert und ist nicht immer vollständig mit dem primären Server synchronisiert.
Es erfolgt eine Einfügung in die „Primery“ mit einem bestimmten Zeitwert. Dieser Einsatz erhöht die interne Zählung um 11, wenn dies das Maximum ist. Oder es überprüft die Uhrwerte und synchronisiert sich mit der Uhr, wenn die Uhrwerte größer sind. Dies ermöglicht Ihnen eine zeitliche Organisation.
Nachdem er die Aufnahme gemacht hat, geschieht ein wichtiger Moment. Die Uhr liegt in „MongoDB“ und wird nur beim Schreiben nach „Oplog“ erhöht. Dies ist das Ereignis, das den Zustand des Systems ändert. In absolut allen klassischen Artikeln wird es als Ereignis angesehen, wenn eine Nachricht einen Knoten erreicht: Die Nachricht ist angekommen, was bedeutet, dass das System seinen Zustand geändert hat.
Dies liegt daran, dass bei der Recherche nicht ganz klar ist, wie diese Botschaft interpretiert wird. Wir wissen mit Sicherheit, dass es, wenn es nicht im „Oplog“ widergespiegelt wird, in keiner Weise interpretiert wird und eine Änderung des Systemzustands nur ein Eintrag im „Oplog“ ist. Das vereinfacht alles für uns: Das Modell vereinfacht es und ermöglicht es uns, es in einem Replikatsatz zu organisieren und viele andere nützliche Dinge.
Der Wert, der bereits in das „Oplog“ geschrieben wurde, wird zurückgegeben – wir wissen, dass das „Oplog“ diesen Wert bereits enthält und seine Zeit 12 beträgt. Nun beginnt das Lesen beispielsweise von einem anderen Knoten (Sekundär) und es wird afterClusterTime in übertragen die Nachricht. Er sagt: „Ich brauche alles, was mindestens nach 12 oder während zwölf passiert ist“ (siehe Bild oben).
Dies wird als Causal a Consistency (CAT) bezeichnet. In der Theorie gibt es ein solches Konzept, dass es sich um einen Zeitabschnitt handelt, der in sich konsistent ist. In diesem Fall können wir sagen, dass dies der Zustand des Systems ist, der zum Zeitpunkt 12 beobachtet wurde.
Jetzt gibt es hier noch nichts, denn diese Art simuliert die Situation, in der Sie die Sekundärseite benötigen, um Daten von der Primärseite zu replizieren. Er wartet... Und nun sind die Daten angekommen – er gibt diese Werte zurück.
So ungefähr funktioniert alles. Fast.
Was bedeutet „fast“? Nehmen wir an, dass es jemanden gibt, der gelesen und verstanden hat, wie das alles funktioniert. Mir wurde klar, dass jedes Mal, wenn ClusterTime auftritt, die interne logische Uhr aktualisiert wird und der nächste Eintrag dann um eins erhöht wird. Diese Funktion benötigt 20 Zeilen. Nehmen wir an, diese Person übermittelt die größte 64-Bit-Zahl minus eins.
Warum „minus eins“? Da die interne Uhr durch diesen Wert ersetzt wird (dies ist natürlich der größtmögliche Wert und größer als die aktuelle Zeit), erfolgt ein Eintrag in „Oplog“ und die Uhr wird um eine weitere Einheit erhöht – und das wird auch schon der Fall sein ein Maximalwert sein (es gibt einfach alle Einheiten, es gibt keinen anderen Ort, an den man gehen kann), ungeheiligte Ints).
Es ist klar, dass das System danach für irgendetwas absolut unzugänglich wird. Es kann lediglich entladen und gereinigt werden – viel Handarbeit. Volle Verfügbarkeit:
Wenn dies außerdem woanders repliziert wird, fällt der gesamte Cluster einfach zusammen. Eine absolut inakzeptable Situation, die jeder ganz schnell und einfach organisieren kann! Daher betrachteten wir diesen Moment als einen der wichtigsten. Wie kann man es verhindern?
Unser Weg besteht darin, ClusterTime zu signieren
So wird es in der Nachricht übermittelt (vor dem blauen Text). Aber wir haben auch begonnen, eine Signatur zu generieren (blauer Text):
Die Signatur wird durch einen Schlüssel generiert, der in der Datenbank innerhalb eines sicheren Bereichs gespeichert wird; selbst wird generiert und aktualisiert (Benutzer sehen nichts davon). Es wird ein Hash generiert und jede Nachricht wird beim Erstellen signiert und beim Empfang validiert.
In den Köpfen der Menschen stellt sich wahrscheinlich die Frage: „Wie sehr verlangsamt das die Dinge?“ Ich habe Ihnen gesagt, dass es schnell funktionieren sollte, insbesondere wenn diese Funktion nicht vorhanden ist.
Was bedeutet es in diesem Fall, kausale Konsistenz zu verwenden? Hiermit wird der Parameter afterClusterTime angezeigt. Ohne dies werden ohnehin einfach Werte übergeben. Klatschen funktioniert ab Version 3.6 immer.
Wenn wir auf die ständige Generierung von Signaturen verzichten, verlangsamt dies das System auch dann, wenn ein Feature fehlt, das nicht unseren Ansätzen und Anforderungen entspricht. Was haben wir also gemacht?
Mach es schnell!
Es ist eine ziemlich einfache Sache, aber der Trick ist interessant – ich werde ihn teilen, vielleicht hat es jemanden interessiert.
Wir haben einen Hash, der die signierten Daten speichert. Alle Daten durchlaufen den Cache. Der Cache signiert nicht die konkrete Zeit, sondern den Bereich. Wenn ein Wert eintrifft, generieren wir einen Bereich, maskieren die letzten 16 Bits und signieren diesen Wert:
Durch den Erhalt einer solchen Signatur beschleunigen wir das System (relativ) um das 65-fache. Es funktioniert großartig: Als wir Experimente durchführten, verkürzte sich die Zeit tatsächlich um das Zehntausendfache, als wir ein sequentielles Update hatten. Es ist klar, dass dies nicht funktioniert, wenn sie uneins sind. Aber in den meisten praktischen Fällen funktioniert es. Die Kombination der Range-Signatur mit der Signatur löste das Sicherheitsproblem.
Was haben wir gelernt?
Lehren, die wir daraus gezogen haben:
- Wir müssen Materialien, Geschichten und Artikel lesen, weil wir viele interessante Dinge haben. Wenn wir an einer Funktion arbeiten (insbesondere jetzt, wenn wir Transaktionen usw. durchgeführt haben), müssen wir sie lesen und verstehen. Es braucht Zeit, ist aber tatsächlich sehr nützlich, weil es deutlich macht, wo wir stehen. Uns schien nichts Neues eingefallen zu sein – wir haben einfach die Zutaten genommen.
Im Allgemeinen gibt es bei einer akademischen Konferenz (z. B. Sigmon) einen gewissen Denkunterschied – jeder konzentriert sich auf neue Ideen. Was ist neu an unserem Algorithmus? Hier gibt es nichts besonders Neues. Das Neue liegt vielmehr in der Art und Weise, wie wir bestehende Ansätze miteinander vermischt haben. Daher ist das erste, was Sie tun müssen, die Klassiker zu lesen, beginnend mit Lampart.
- In der Produktion sind die Anforderungen völlig anders. Ich bin sicher, dass viele von Ihnen nicht mit „sphärischen“ Datenbanken im abstrakten Vakuum konfrontiert sind, sondern mit normalen, realen Dingen, die Probleme mit Verfügbarkeit, Latenz und Fehlertoleranz haben.
- Der letzte Punkt ist, dass wir uns verschiedene Ideen ansehen und mehrere völlig unterschiedliche Artikel in einem Ansatz zusammenfassen mussten. Die Idee zum Signieren stammt beispielsweise im Allgemeinen aus einem Artikel, der sich mit dem Paxos-Protokoll befasste, das für nicht-byzantinische Fehler innerhalb des Autorisierungsprotokolls liegt, für byzantinische Fehler außerhalb des Autorisierungsprotokolls ... Im Allgemeinen ist dies genau das, was wir tun endete damit.
Hier gibt es absolut nichts Neues! Aber sobald wir alles zusammengemischt haben ... Das ist das Gleiche, als würde man sagen, dass das Olivier-Salat-Rezept Unsinn ist, weil Eier, Mayonnaise und Gurken bereits erfunden wurden ... Es ist ungefähr die gleiche Geschichte.
Damit komme ich zum Schluss. Danke!
Fragen
Frage aus dem Publikum (im Folgenden B genannt): – Danke, Mikhail, für den Bericht! Das Thema Zeit ist interessant. Sie verwenden Klatsch. Sie sagten, dass jeder seine eigene Zeit hat, jeder kennt seine Ortszeit. So wie ich es verstehe, haben wir einen Treiber – es kann viele Clients mit Treibern geben, auch Abfrageplaner, auch Shards ... Und worauf kommt es im System an, wenn wir plötzlich eine Diskrepanz haben: Jemand entscheidet, dass es sich um einen handelt Minute voraus, jemand eine Minute dahinter? Wo werden wir landen?
MT: – Wirklich tolle Frage! Ich wollte nur über Scherben sprechen. Wenn ich die Frage richtig verstehe, haben wir die folgende Situation: Es gibt Shard 1 und Shard 2, das Lesen erfolgt von diesen beiden Shards – sie haben eine Diskrepanz, sie interagieren nicht miteinander, weil die Zeit, die sie kennen, unterschiedlich ist, vor allem die Zeit, in der sie in Oplogs existieren.
Nehmen wir an, Shard 1 hat eine Million Datensätze erstellt, Shard 2 hat überhaupt nichts getan und die Anfrage hat zwei Shards erreicht. Und der erste hat eine AfterClusterTime von über einer Million. In einer solchen Situation wird Shard 2, wie ich erklärt habe, überhaupt nicht reagieren.
in: – Ich wollte wissen, wie sie sich synchronisieren und eine logische Zeit auswählen?
MT: - Sehr einfach zu synchronisieren. Shard, wenn afterClusterTime zu ihm kommt und er keine Zeit im „Oplog“ findet, initiiert keine Genehmigung. Das heißt, er erhöht seine Zeit mit seinen Händen auf diesen Wert. Das bedeutet, dass es keine Ereignisse gibt, die dieser Anfrage entsprechen. Er erzeugt dieses Ereignis künstlich und wird so kausalkonsistent.
in: – Was wäre, wenn danach noch andere Ereignisse zu ihm kämen, die irgendwo im Netzwerk verloren gingen?
MT: – Shard ist so konzipiert, dass sie nicht wiederkommen, da es sich um einen einzelnen Meister handelt. Wenn er sich bereits angemeldet hat, werden sie nicht kommen, sondern später. Es kann nicht passieren, dass irgendwo etwas hängen bleibt, er dann nicht schreibt und dann diese Ereignisse eintreten – und die kausale Konsistenz gebrochen ist. Wenn er nicht schreibt, sollten sie alle als nächstes kommen (er wird auf sie warten).
in: – Ich habe mehrere Fragen zu den Warteschlangen. Kausale Konsistenz geht davon aus, dass es eine bestimmte Warteschlange von Aktionen gibt, die ausgeführt werden müssen. Was passiert, wenn eines unserer Pakete verschwindet? Hier kommt der 10., 11. ... der 12. ist verschwunden und alle anderen warten darauf, dass er wahr wird. Und plötzlich ist unser Auto kaputt, wir können nichts mehr tun. Gibt es eine maximale Länge der Warteschlange, die sich vor der Ausführung ansammelt? Welcher schwerwiegende Fehler tritt auf, wenn ein Zustand verloren geht? Wenn wir außerdem aufschreiben, dass es einen früheren Zustand gibt, sollten wir dann irgendwie damit beginnen? Aber sie haben ihn nicht weggestoßen!
MT: – Auch eine tolle Frage! Was machen wir? MongoDB hat das Konzept von Quorum-Schreibvorgängen und Quorum-Lesevorgängen. In welchen Fällen kann eine Nachricht verloren gehen? Wenn ein Schreibvorgang kein Quorum ist oder wenn ein Lesevorgang kein Quorum ist (es kann auch eine Art Müll hängen bleiben).
Bezüglich der Kausalkonsistenz wurde ein großer experimenteller Test durchgeführt, der zu dem Ergebnis führte, dass es bei Schreib- und Lesevorgängen ohne Quorum zu Verstößen gegen die Kausalkonsistenz kommt. Genau das, was Sie sagen!
Unser Rat: Verwenden Sie mindestens Quorum Reading, wenn Sie kausale Konsistenz verwenden. In diesem Fall geht nichts verloren, selbst wenn der Quorum-Datensatz verloren geht ... Dies ist eine orthogonale Situation: Wenn der Benutzer nicht möchte, dass Daten verloren gehen, muss er einen Quorum-Datensatz verwenden. Kausale Konsistenz garantiert keine Dauerhaftigkeit. Die Haltbarkeit wird durch die Replikation und die mit der Replikation verbundenen Maschinen gewährleistet.
in: – Wenn wir eine Instanz erstellen, die das Sharding für uns durchführt (nicht Master, sondern Slave), verlässt sie sich auf die Unix-Zeit ihrer eigenen Maschine oder auf die Zeit des „Masters“; Wird es zum ersten Mal oder regelmäßig synchronisiert?
MT: – Ich werde es jetzt klarstellen. Shard (d. h. horizontale Partition) – es gibt immer eine primäre Partition. Und ein Shard kann einen „Master“ haben und es kann Replikate geben. Der Shard unterstützt jedoch immer die Aufzeichnung, da er eine bestimmte Domäne unterstützen muss (der Shard verfügt über eine primäre Domain).
in: – Also hängt alles nur vom „Meister“ ab? Wird immer die Masterzeit verwendet?
MT: - Ja. Im übertragenen Sinne kann man sagen: Die Uhr tickt, wenn ein Eintrag in den „Master“, in den „Oplog“, erfolgt.
in: – Wir haben einen Kunden, der sich verbindet und nichts über die Uhrzeit wissen muss?
MT: – Sie müssen überhaupt nichts wissen! Wenn wir darüber sprechen, wie es beim Client funktioniert: Wenn der Client kausale Konsistenz verwenden möchte, muss er eine Sitzung eröffnen. Jetzt ist alles da: Transaktionen in der Sitzung und das Abrufen von Rechten ... Eine Sitzung ist die Reihenfolge logischer Ereignisse, die beim Client auftreten.
Wenn er diese Sitzung öffnet und dort sagt, dass er kausale Konsistenz möchte (sofern die Sitzung standardmäßig kausale Konsistenz unterstützt), funktioniert alles automatisch. Der Fahrer merkt sich diese Zeit und erhöht sie, wenn er eine neue Nachricht erhält. Es merkt sich, welche Antwort die vorherige vom Server zurückgegeben hat, der die Daten zurückgegeben hat. Die nächste Anfrage enthält afterCluster("Zeit größer als diese").
Der Kunde muss absolut nichts wissen! Für ihn ist das völlig undurchsichtig. Was können Menschen tun, wenn sie diese Funktionen nutzen? Erstens können Sie Secondaries sicher lesen: Sie können auf Primary schreiben und von geografisch replizierten Secondaries lesen und sicher sein, dass es funktioniert. Gleichzeitig können Sitzungen, die auf der Primärseite aufgezeichnet wurden, sogar auf die Sekundärseite übertragen werden, d. h. Sie können nicht eine Sitzung, sondern mehrere verwenden.
in: – Eine neue Ebene der Informatik – CRDT-Datentypen (Conflict-free Replicated Data Types) – ist eng mit dem Thema Eventual Consistency verbunden. Haben Sie darüber nachgedacht, diese Art von Daten in die Datenbank zu integrieren, und was können Sie dazu sagen?
MT: - Gute Frage! CRDT ist bei Schreibkonflikten sinnvoll: in MongoDB Single Master.
in: – Ich habe eine Frage von den Entwicklern. In der realen Welt gibt es solche jesuitischen Situationen, in denen es zu einem byzantinischen Misserfolg kommt und böse Menschen innerhalb des geschützten Umkreises beginnen, in das Protokoll einzudringen und auf besondere Weise Handwerkspakete zu versenden?
MT: – Böse Menschen innerhalb des Perimeters sind wie ein Trojanisches Pferd! Böse Menschen innerhalb des Perimeters können viele schlimme Dinge tun.
in: – Es ist klar, dass, grob gesagt, ein Loch im Server entsteht, durch das man einen Elefantenzoo stecken und den gesamten Cluster für immer zusammenbrechen lassen kann … Die manuelle Wiederherstellung wird einige Zeit dauern … Das ist, gelinde gesagt, so falsch. Andererseits ist das interessant: Gibt es im wirklichen Leben, in der Praxis, Situationen, in denen natürlicherweise ähnliche interne Angriffe auftreten?
MT: – Da ich im wirklichen Leben selten auf Sicherheitsverletzungen stoße, kann ich nicht sagen, ob sie tatsächlich passieren. Aber wenn wir über die Entwicklungsphilosophie sprechen, denken wir so: Wir haben einen Perimeter, der den Leuten, die für Sicherheit sorgen, eine Burg bietet, eine Mauer; Und innerhalb des Umkreises können Sie tun und lassen, was Sie wollen. Es ist klar, dass es Benutzer gibt, die nur die Möglichkeit haben, das Verzeichnis anzuzeigen, und es Benutzer gibt, die die Möglichkeit haben, das Verzeichnis zu löschen.
Abhängig von den Rechten kann der Schaden, den Benutzer anrichten können, eine Maus oder ein Elefant sein. Es ist klar, dass ein Benutzer mit vollen Rechten überhaupt alles tun kann. Ein Benutzer mit eingeschränkten Rechten kann deutlich weniger Schaden anrichten. Insbesondere kann es das System nicht zerstören.
in: – Im geschützten Perimeter hat jemand versucht, unerwartete Protokolle für den Server zu erstellen, um den Server vollständig zu zerstören, und wenn Sie Glück haben, den gesamten Cluster ... Wird es jemals so „gut“?
MT: „Von solchen Dingen habe ich noch nie gehört.“ Dass man auf diese Weise einen Server zum Absturz bringen kann, ist kein Geheimnis. Im Inneren scheitern, aus dem Protokoll stammen, ein autorisierter Benutzer sein, der so etwas in die Nachricht schreiben kann ... Tatsächlich ist es unmöglich, weil es trotzdem überprüft wird. Es ist möglich, diese Authentifizierung für Benutzer zu deaktivieren, die sie nicht möchten – dann ist das ihr Problem; Sie haben, grob gesagt, die Mauern selbst zerstört und man kann dort einen Elefanten hineinschieben, der zertrampelt... Aber im Allgemeinen kann man sich als Handwerker verkleiden, kommen und es herausziehen!
in: – Danke für den Bericht. Sergey (Yandex). In Mong gibt es eine Konstante, die die Anzahl der stimmberechtigten Mitglieder im Replikatsatz begrenzt, und diese Konstante ist 7 (sieben). Warum ist das eine Konstante? Warum ist das kein Parameter?
MT: – Wir haben Replikat-Sets mit 40 Knoten. Es gibt immer eine Mehrheit. Ich weiß nicht welche Version...
in: – Im Replica Set können Sie nicht stimmberechtigte Mitglieder betreiben, es gibt jedoch maximal 7 stimmberechtigte Mitglieder. Wie können wir in diesem Fall die Abschaltung überleben, wenn unser Replica Set auf 3 Rechenzentren verteilt ist? Ein Rechenzentrum kann leicht abschalten und eine andere Maschine kann ausfallen.
MT: – Das sprengt schon ein wenig den Rahmen des Berichts. Dies ist eine allgemeine Frage. Vielleicht kann ich dir später davon erzählen.
Einige Anzeigen 🙂
Vielen Dank, dass Sie bei uns geblieben sind. Gefallen Ihnen unsere Artikel? Möchten Sie weitere interessante Inhalte sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder an Freunde weiterempfehlen. , ein einzigartiges Analogon von Einstiegsservern, das von uns für Sie erfunden wurde: (verfügbar mit RAID1 und RAID10, bis zu 24 Kerne und bis zu 40 GB DDR4).
Dell R730xd 2-mal günstiger im Equinix Tier IV-Rechenzentrum in Amsterdam? Nur hier in den Niederlanden! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbit/s 100 TB – ab 99 $! Lesen über
Source: habr.com