Es gibt drei häufig verwendete Replikationsroutinen: Die Datenbank stellt sicher, dass alle Daten auf drei unabhängige Festplatten auf drei verschiedenen Computern kopiert werden. Der Grund dafür ist einfach: Festplatten fallen nur zu einem bestimmten Zeitpunkt aus. Wenn eine Festplatte ausfällt, haben Sie Zeit, sie zu ersetzen, und Sie können immer noch eine Ihrer beiden anderen Kopien nehmen, um die Daten wiederherzustellen und auf die neue Festplatte zu schreiben . Die Wahrscheinlichkeit, dass die zweite Festplatte stirbt, bevor Sie sie wiederherstellen, ist so gering, dass die Wahrscheinlichkeit, dass beide Festplatten gleichzeitig sterben, so gering ist wie die eines Asteroideneinschlags auf die Erde.
Wir haben außerdem speziell berechnet, dass die Wahrscheinlichkeit, dass eine Festplatte ausfällt, fast 0,1 % (vielleicht grob) beträgt, die Wahrscheinlichkeit, dass zwei Festplatten ausfallen, fast 10 hoch 6 beträgt und die Wahrscheinlichkeit, dass drei Festplatten gleichzeitig ausfallen, Sex beträgt etwa 10 hoch -9, was einem Teil einer Milliarde entspricht. Diese Berechnung zeigt, dass der Ausfall einer Festplatte unabhängig vom Ausfall anderer Festplatten ist. Dies ist nicht sehr genau. Wenn Ihre Festplatten beispielsweise alle in derselben Produktionslinie hergestellt werden, sind möglicherweise alle fehlerhaft. Das reicht jedoch aus für unsere Idee.
Bisher erscheint dies sinnvoll, leider gilt dies jedoch nicht für viele Datenspeichersysteme. In diesem Blog zeige ich Ihnen, warum.
Wenn Ihr Datenbankcluster nur drei Maschinen enthält, ist die Wahrscheinlichkeit, dass alle Maschinen gleichzeitig abstürzen, zu gering (ausgenommen damit verbundene Fehler, wie z. B. die Zerstörung eines Rechenzentrums). Sobald Sie jedoch einen größeren Cluster verwenden, ändert sich das Problem entsprechend. Je mehr Knoten und Festplatten Sie im Cluster verwenden, desto wahrscheinlicher ist es, dass Sie Daten verlieren.
Dies basiert möglicherweise auf Berechnungen. „Wirklich? Ich habe die Daten auf drei Festplatten kopiert. Wie kann die Ausfallwahrscheinlichkeit mit zunehmender Clusterkapazität höher werden?“ Aber ich habe die Möglichkeiten berechnet und angezeigt Sie wissen warum mit dem folgenden Symbol:
Offensichtlich besteht nicht die Möglichkeit, dass ein Knoten ausfällt – es besteht die Möglichkeit, dass alle drei Kopien der Daten dauerhaft verloren gehen. Daher ist die Wiederherstellung der Daten aus einem Backup nur der konservative Ansatz. Je größer Ihr Cluster ist, desto wahrscheinlicher ist es, dass Sie Daten verlieren. Daran denken Sie vielleicht nicht, wenn Sie darüber nachdenken, für die Replikation Ihrer Daten zu zahlen.
Die Y-Achse des Diagramms ist etwas willkürlich und erfordert viel Fantasie, aber die Richtung der Linien ist unglaublich. Basierend auf bisherigen Annahmen beträgt die Wahrscheinlichkeit, dass ein Knoten irgendwann ausfällt, 0,1 %. Die Abbildung zeigt jedoch, dass in einem Cluster mit 8.000 Knoten die Wahrscheinlichkeit, drei Kopien von Daten dauerhaft zu verlieren, etwa 0,2 % beträgt. Ja, das stimmt, das Risiko, alle drei Kopien zu verlieren, ist doppelt so hoch wie das Risiko, die Daten eines Knotens zu verlieren. Wofür werden diese Kopien verwendet?
Wenn man dieses Bild intuitiv betrachtet: In einem Cluster mit 8.000 Knoten kommt es häufig vor, dass einige Knoten zu bestimmten Zeiten ausfallen. Dies stellt möglicherweise kein Problem dar: Eine gewisse Wahrscheinlichkeit von Chaos und Knotenaustausch kann abgeleitet werden, und ein Teil davon ist routinemäßige Wartung. Wenn Sie jedoch Pech haben und der Zielknoten der von Ihnen kopierten Knotendaten ausgefallen ist, werden Ihre Daten nie abgerufen. Der Datenverlust macht einen relativ kleinen Teil des gesamten Datensatzes des Clusters aus, aber wenn Sie drei Replikate verlieren, denken Sie vielleicht: „Ich möchte diese Daten wirklich nicht verlieren“ und nicht: „Das habe ich nicht erwartet.“ Verlieren Sie versehentlich einige Daten, obwohl sie nicht sehr groß sind. „Vielleicht ist dieser Teil der fehlenden Daten ein wichtiger Teil der Daten.“
Die Möglichkeit, dass alle drei Replikate fehlerhafte Knoten sind, hängt vom vom System verwendeten Replikationsalgorithmus ab. Das obige Diagramm basiert einfach darauf, dass die Daten in eine bestimmte Anzahl von Partitionen (oder Shards) aufgeteilt werden, sodass jede Partition drei zufällig ausgewählte Knoten speichert (oder eine pseudozufällige Hash-Funktion). Dies ist ein Sonderfall von konsistentem Hashing, das (soweit ich weiß) in Cassandra und Riak verwendet wird. Ich bin mir nicht sicher, wie andere Systeme die Replikationsarbeit verteilen, daher schaue ich mir das von jemandem an, der sich mit den Interna eines Multi-Storage-Systems auskennt.
Lassen Sie mich Ihnen zeigen, wie ich die obige Grafik mithilfe eines probabilistischen Modells einer replizierten Datenbank berechnet habe.
Angenommen, die Wahrscheinlichkeit, dass ein unabhängiger Knoten Daten verliert, beträgt p=P (Knotenverlust). Ich werde in diesem Modell die Zeit ignorieren und kurz auf die Ausfallwahrscheinlichkeit in bestimmten Zeiträumen eingehen. Wir können beispielsweise davon ausgehen, dass p=0,001 die Wahrscheinlichkeit ist, dass ein Knoten an einem bestimmten Tag ausfällt. Es ist sinnvoll, einen Tag damit zu verbringen, den Knoten auszutauschen und die verlorenen Daten auf den neuen Knoten zu übertragen. Um es einfach auszudrücken: Ich möchte nicht zwischen Knotenfehlern und Festplattenfehlern unterscheiden, sondern nur von dauerhaften Fehlern sprechen.
Sei n die Anzahl der Knoten im Cluster. f ist die Anzahl der ausgefallenen Knoten (unter der Annahme, dass Ausfälle relativ unabhängig sind) und ist binomialverteilt:
Der Ausdruck ist die Wahrscheinlichkeit des Ausfalls von f Knoten. Der Ausdruck ist die Wahrscheinlichkeit, sicherzustellen, dass n-f Knoten nicht ausfallen. Es ist die Anzahl der f Knoten, die auf unterschiedliche Weise extrahiert werden. Ausgesprochen „n wähle f“ ist es definiert als:
. . . . . .
Der konkrete Ableitungsprozess wird hier nicht im Detail beschrieben. Basierend auf der obigen Formel können wir die Wahrscheinlichkeit des Verlusts einer oder mehrerer Partitionen in einem Cluster mit n Knoten und einem Replikationsfaktor von (Anzahl der replizierten Backup-Knoten) ableiten. Wenn die Anzahl der ausgefallenen Knoten f kleiner als der Replikationsfaktor ist, können wir sicher sein, dass keine Daten verloren gegangen sind. Allerdings müssen wir alle Möglichkeiten addieren, wenn f zwischen r und n liegt:
Das ist etwas wortreich, aber ich denke, es ist zutreffend. Wenn Sie r=3, p=0,001, k=256n und n zwischen 3 und 10000 lassen, erhalten Sie das obige Bild. Ich habe einige Ruby-Programme geschrieben, um diese Berechnung umzusetzen.
Wir verwenden die Union-Bindung, um eine einfachere Vermutung zu erhalten:
Obwohl der Ausfall einer Partition nicht völlig unabhängig von anderen Partitionen ist, gilt diese Vermutung dennoch. Es scheint näher an den experimentellen Ergebnissen zu liegen: Auf dem Weg dorthin ähnelt die Wahrscheinlichkeit eines Datenverlusts eher einer geraden Linie, die proportional zur Anzahl der Knoten ist. Die Vermutung zeigt, dass die Wahrscheinlichkeit positiv mit der Zahl zusammenhängt, und wir gehen davon aus, dass jeder Knoten feste 256 Partitionen hat.
Wie es in der Praxis funktionieren wird, weiß ich nicht genau. Aber ich denke, dass dies ein interessantes rechenempfindliches Phänomen ist. Ich habe von Situationen gehört, in denen es bei Unternehmen mit großen Datenbankclustern zu echten Datenverlusten kam. In Artikeln und Berichten kommt es jedoch nicht sehr häufig vor. Wenn Sie sich derzeit mit diesem Thema befassen, können Sie es mir sagen.
Die berechneten Ergebnisse zeigen, dass Sie die Anzahl der Partitionen reduzieren und den Replikationsfaktor erhöhen sollten, wenn Sie die Möglichkeit eines Datenverlusts verringern möchten. Die Verwendung mehrerer Backups kostet mehr, daher ist dies bei großen Clustern bereits kostspielig. Die Anzahl der Partitionen weist jedoch auf einen sinnvollen Lastausgleichsprozess hin. Cassandra hatte ursprünglich eine Partition pro Knoten, später wurden es jedoch 256 Partitionen pro Knoten, um eine bessere Lastverteilung und einen effizienten Sekundärausgleich zu ermöglichen.
Sie müssen einigermaßen große Cluster finden, bevor diese wirklich funktionieren können, aber Cluster mit Tausenden von Ebenen werden von vielen großen Unternehmen verwendet. Deshalb bin ich daran interessiert, von Menschen mit praktischer Erfahrung in diesem Bereich zu hören. Wenn die Wahrscheinlichkeit eines dauerhaften Datenverlusts für 10.000 Knoten jeden Tag innerhalb von 0,25 % liegt, bedeutet dies, dass 60 % der Daten in einem Jahr verloren gehen.
Was denken Sie als Designer verteilter Datensysteme nach der Lektüre dieses Artikels? Wenn das, was ich sage, richtig ist, sollte der Entwurf von Replikationsschemata stärker berücksichtigt werden. Ich hoffe, dass dieser Artikel Ihr Bewusstsein für die Realität schärfen kann. Denn 3 Replikationsknoten sind wirklich nicht so sicher.
Das obige ist der detaillierte Inhalt vonZum Datenverlust in großen Clustern. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
