2
In der MongoDB-Dokumentation, here, wurde erwähnt, dass in einer Replikatmenge sogar mit Majorität readConcern wir endgültige Konsistenz erreichen würden. Ich frage mich, wie ist das möglich, wenn wir in Lese- und Schreibrechten die Mehrheit haben, was zu einem Quorum (R + W> N) in unserem verteilten System führt? Ich erwarte ein starkes konsistentes System in dieser Einstellung. Dies ist die Technik, die auch Cassandra verwendet, um eine starke Konsistenz zu erreichen.Wie erreichen Sie eine starke Konsistenz in MongoDB Replica Sets?
Kann mir bitte jemand dies erklären?
Sie sprechen über Leistung und Skalierbarkeit bei Lese- und Schreibvorgängen, die durch Sharding gehandhabt werden können. Eventuelle Konsistenz ist nur dann von Bedeutung, wenn Sie sekundäre Knoten in einem Replikatsatz für Lesevorgänge verwenden möchten. Meine Frage ist, warum wir keine starke Konsistenz haben, obwohl wir einen Quruom haben? –
Das Quorum ist nur notwendig, wenn eine Primary ausgewählt wird. Es kann Netzwerkverzögerung/-verzögerung nicht berücksichtigen, und das Primärsystem muss nicht darauf warten, dass die Schreibtransaktion auf allen Sekundärteilen nur aus Gründen der Konsistenz wiederholt wird. Stellen Sie sich dieses Szenario vor - mit zwei SSD-basierten Knoten für Leistung und Failover und einem günstigeren HDD-Knoten für Backups. Soll der primäre High-Performance-Knoten auf den Abschluss des Vorgangs auf dem langsamsten Mitglied warten? –
Mehrheitswahl ist für die Vorwahl erforderlich. Quorum bedeutet Leser + Schreiber> Anzahl der Knoten. Dieser Ausdruck ist wahr, wenn wir sowohl readConcern als auch writeConcern auf die Majorität setzen. Wenn wir also von einer Mehrheit von Knoten lesen, gibt es mindestens einen Knoten, der den neuesten Schreibvorgang hat, und daher ist das System stark konsistent. Ich möchte wissen, warum dieser Ausdruck bei MongoDB nicht stimmt? –