it-swarm.com.de

Wo steht Mongodb im GAP-Theorem?

Überall, wo ich hinschaue, sehe ich, dass MongoDB CP ist. Aber wenn ich mich eingrabe, sehe ich, dass es irgendwann konsistent ist. Ist es CP, wenn Sie safe = true verwenden? Wenn ja, bedeutet dies, dass beim Schreiben mit safe = true alle Replikate aktualisiert werden, bevor das Ergebnis angezeigt wird?

101
Gluz

MongoDB ist standardmäßig stark konsistent. Wenn Sie erst schreiben und dann lesen, können Sie bei erfolgreichem Schreiben immer das Ergebnis des gerade gelesenen Schreibvorgangs lesen. Dies liegt daran, dass MongoDB ein Single-Master-System ist und alle Lesevorgänge standardmäßig zum primären System gehen. Wenn Sie optional das Lesen von Sekundärdaten aktivieren, wird MongoDB schließlich konsistent, wenn es möglich ist, veraltete Ergebnisse zu lesen.

MongoDB wird auch durch automatisches Failover in Replikatsätzen hochverfügbar: http://www.mongodb.org/display/DOCS/Replica+Sets

88
stbrody

Dies sollte helfen, die Frage zusammen mit anderen NoSQL- und anderen beständigen Speichersystemen zu beantworten.

enter image description here

115
Timothy Perez

Ich bin mit Luccas Post einverstanden. Sie können nicht einfach sagen, dass MongoDB CP/AP/CA ist, da es sich tatsächlich um einen Kompromiss zwischen C, A und P handelt, abhängig von der Datenbank-/Treiberkonfiguration und der Art der Katastrophe : Hier ist eine visuelle Zusammenfassung und unten eine detailliertere Erklärung.

    Scenario                   | Main Focus | Description
    ---------------------------|------------|------------------------------------
    No partition               |     CA     | The system is available 
                               |            | and provides strong consistency
    ---------------------------|------------|------------------------------------
    partition,                 |     AP     | Not synchronized writes 
    majority connected         |            | from the old primary are ignored                
    ---------------------------|------------|------------------------------------
    partition,                 |     CP     | only read access is provided
    majority not connected     |            | to avoid separated and inconsistent systems

Konsistenz:

MongoDB ist stark konsistent, wenn Sie eine einzelne Verbindung oder die richtige Write / Read Concern Level ( was Sie Ausführungsgeschwindigkeit kosten wird ) verwenden. Sobald Sie diese Bedingungen nicht erfüllen (insbesondere wenn Sie von einem sekundären Replikat lesen), wird MongoDB schließlich konsistent.

Verfügbarkeit:

MongoDB wird durch Replica-Sets hochverfügbar. Sobald die Primärdatenbank ausfällt oder nicht mehr verfügbar ist, bestimmen die Sekundärdatenbanken, dass eine neue Primärdatenbank wieder verfügbar ist. Dies hat einen Nachteil: Jeder Schreibvorgang, der von der alten Primärdatenbank ausgeführt, aber nicht mit den Sekundärdatenbanken synchronisiert wurde, wird rückgängig gemacht und in einer Rollback-Datei gespeichert, sobald die Verbindung zur Gruppe wiederhergestellt wird (Das alte Primär ist jetzt ein Sekundär). In diesem Fall wird also ein gewisses Maß an Konsistenz aus Gründen der Verfügbarkeit geopfert.

Partitionstoleranz:

Durch die Verwendung dieser Replica-Sets erreicht MongoDB auch die Partitionstoleranz: Solange mehr als die Hälfte der Server eines Replica-Sets miteinander verbunden sind, ein neuer Primärserver kann gewählt werden . Warum? Um sicherzustellen, dass zwei getrennte Netzwerke nicht beide ein neues Primärnetzwerk auswählen können. Wenn nicht genügend Secondaries miteinander verbunden sind, können Sie trotzdem von ihnen lesen (die Konsistenz ist jedoch nicht gewährleistet), aber nicht schreiben. Das Set ist aus Gründen der Konsistenz praktisch nicht verfügbar.

25
JoCa

Als brillanter neuer Artikel aufgetaucht ist und auch einige großartige Experimente von Kyle in diesem Bereich, sollten Sie vorsichtig sein, wenn Sie MongoDB und andere Datenbanken als C oder A bezeichnen.

Natürlich hilft CAP dabei, ohne viele Worte herauszufinden, was die Datenbank darüber ausmacht, aber die Leute vergessen oft, dass C in CAP zum Beispiel atomare Konsistenz (Linearisierbarkeit) bedeutet. Und das hat mir sehr wehgetan, als ich versuchte zu klassifizieren. Abgesehen davon, dass MongoDB eine starke Konsistenz aufweist, heißt das nicht, dass es C ist. Auf diese Weise empfahl ich, wenn man diese Klassifizierungen vornimmt, auch genauer zu erläutern, wie es tatsächlich funktioniert, um keine Zweifel zu hinterlassen.

16
Luccas

Ja, bei Verwendung von safe=true Ist es CP. Dies bedeutet einfach, dass die Daten auf der Festplatte des Masters gespeichert wurden. Wenn Sie sicherstellen möchten, dass es auch auf einem Replikat angekommen ist, überprüfen Sie den Parameter 'w = N', wobei N die Anzahl der Replikate ist, auf denen die Daten gespeichert werden müssen.

weitere Informationen finden Sie unter this und this .

10
Jan Prieser

Ich bin mir bei P für Mongo nicht sicher. Stellen Sie sich die Situation vor:

  • Ihre Replik wird in zwei Partitionen aufgeteilt.
  • Die Schreiben an beide Seiten werden fortgesetzt, wenn neue Meister gewählt wurden
  • Die Partition ist aufgelöst - alle Server sind jetzt wieder verbunden
  • Was passiert, ist, dass ein neuer Master gewählt wird - derjenige, der das höchste Oplog hat, aber die Daten des anderen Masters werden vor der Partition in den gemeinsamen Zustand zurückgesetzt und zur manuellen Wiederherstellung in eine Datei kopiert
  • alle Secondaries holen den neuen Master ein

Das Problem hierbei ist, dass die Größe der Speicherauszugsdatei begrenzt ist und Sie Ihre Daten für immer verlieren können, wenn Sie über eine lange Zeit eine Partition verfügten.

Man kann sagen, dass es unwahrscheinlich ist - ja, es sei denn, in der Cloud ist es üblicher, als man denkt.

Aus diesem Grund würde ich sehr vorsichtig sein, bevor ich einen Brief einer Datenbank zuweisen würde. Es gibt so viele Szenarien und Implementierungen, die nicht perfekt sind.

Wenn jemand weiß, ob dieses Szenario in späteren Versionen von Mongo behoben wurde, kommentieren Sie bitte! (Ich habe seit einiger Zeit nicht mehr alles verfolgt, was geschah.)

4
kubal5003

Mongodb erlaubt niemals das Schreiben in die Sekundärseite. Es ermöglicht optionale Lesevorgänge von sekundären, aber nicht von Schreibvorgängen. Wenn also Ihre primäre ausfällt, können Sie erst schreiben, wenn eine sekundäre wieder zur primären wird. Auf diese Weise opfern Sie die Hochverfügbarkeit im CAP-Theorem. Indem Sie Ihre Lesezugriffe nur von der Primärdatenbank behalten, können Sie eine starke Konsistenz erzielen.

0
sn.anurag