Wie funktioniert MongoDB gleichzeitig sharding und replication?

Für Skalierung/Failover verwendet mongodb einen "Replikatsatz", in dem es einen primären und einen oder mehrere sekundäre Server gibt. Primary wird für Schreibvorgänge verwendet. Secondaries werden für Lesevorgänge verwendet. Dies ist ziemlich viel Master-Slave-Muster in SQL-Programmierung verwendet. Wenn der Primärwert sinkt, tritt ein Sekundärwert im Cluster der Sekundärteile an seine Stelle. So ist das Problem der horizontalen Skalierung und Failover erledigt. Dies ist jedoch keine Lösung, die das Sharding ermöglicht. Ein echter Shard enthält nur einen Teil der gesamten Daten. Wenn also die sekundäre in einer Replikatmenge shard ist, wie kann sie dann als primär eingestuft werden, wenn sie nicht alle Daten enthält, die für die Bearbeitung der Anforderungen benötigt werden?Wie funktioniert MongoDB gleichzeitig sharding und replication?

Müssen wir nicht für jeden der Shards eine Replik erstellen?

Dies ist offensichtlich eine Anfängerfrage, also ein Link, der visuell oder anderweitig veranschaulicht, wie dies getan wird, wäre hilfreich.

Quelle

2013-02-06 alex sundukovskiy

Dieser Shard wird die Daten haben, die benötigt werden, um die Anfragen zu erfüllen, und ja, Sie können eine Replik pro Shard haben, hier ist ein Kochbuch Tutorial: http://cookbook.mongodb.org/operations/convert-replica Set-to-replicated-shard-cluster/ – Sammaye

Ihre Annahme ist korrekt, jeder Shard enthält einen separaten Replikatsatz. Wenn eine Schreibanforderung eingeht, findet Mongos auf der Grundlage des Shard-Schlüssels den richtigen Shard dafür, und die Daten werden in das Primärverzeichnis des in diesem Shard enthaltenen Replikatsatzes geschrieben. Dies führt zu Schreibskalierung, da ein (gut gewählter) Shard-Schlüssel Schreibvorgänge auf alle Ihre Shards verteilen sollte.

Quelle

2013-02-06 21:57:39

Danke! Kann es umgekehrt gemacht werden? Jeder Server in einem Replikatgruppen-Cluster ist sharded. Detaillierte Beschreibung: Angenommen, wir haben einen Replikatsatz. Großartig, wir haben die Fähigkeit, mehr Reads zu warten, wir haben Failover. Jetzt ist unser Problem, dass die Größe der Daten auf jedem Server (der ich als Server bezeichnet) ziemlich groß wird. Also haben wir die Daten auf jedem Server getauscht. Ist das nicht das Gegenteil von dem, was du beschrieben hast? Oder ist es aus der Sicht der Implementierung das gleiche "Ding"? –

@alexsundukovskiy Ich bin mir nicht sicher, was du meinst, aber du kannst keine Replik selbst setzen – Sammaye

@alexsundukovskiy Nehmen wir an, SHARD_KEY hat mögliche Werte {A, B, C, D} und du hast 2 Shards. Jeder Splitter hat ein Replikat-Set bestehend aus 3 Maschinen. Nun sollten Ihre Dokumente theoretisch gleichmäßig über Ihren SHARD_KEY verteilt sein, d. H.Anzahl der Dokumente, die mit SHARD_KEY ankommen = A, SHARD_KEY = B usw. sollten gleich sein. Nehmen wir an, diese glückliche Situation dauert eine Weile an. Dann beginnt eines von zwei Dingen: (weiter unten) –

Normalerweise würden Sie einzelne Shards einzelnen Replikatgruppen zuordnen. Eine Übersicht über MongoDB Sharding finden Sie unter http://docs.mongodb.org/manual/core/sharded-clusters/.

Quelle

2013-02-06 21:50:51 epc

Danke, ich frage mich, ob es jemals anders herum passiert. Mit anderen Worten: Könnten wir jeden Knoten im Replikat-Set sharded haben? Und wenn nicht, was ist daran falsch? –

Ich bin mir nicht sicher, ob ich deine Frage verstehe. Sie shard-Sammlungen innerhalb einer Datenbank und Sharting-Läufen über Replikat-Gruppen. MongoDB hat kein Konzept zum Teilen eines Knotens. Sie können sicher alle Sammlungen in allen Ihren Datenbanken sharding, aber das ist wahrscheinlich Overkill abhängig von Ihrer Auslastung. – epc

Angenommen, wir haben einen Replikatsatz. Großartig, wir haben die Fähigkeit, mehr Reads zu warten, wir haben Failover. Jetzt ist unser Problem, dass die Größe der Daten auf jedem Server (den ich als Knoten bezeichnete) ziemlich groß wird. Also haben wir die Daten auf jedem Server getauscht. Ist das nicht das Gegenteil von dem, was du beschrieben hast? Oder ist es aus der Sicht der Implementierung das gleiche "Ding"? –

Ein Shard ist die Summe einer primären und Secondaries (Replikat), also ja, Sie müssten ein Replikat in jedem Shard gesetzt haben.

Der Teil der gesamten Daten wird in der Primärdatenbank gespeichert und mit den Sekundärteilen geteilt, um Konsistenz zu gewährleisten. Wenn der primäre Server ausfällt, wird ein sekundärer Server als neuer primärer Server ausgewählt und hat die gleichen Daten wie sein Vorgänger, um sofort mit dem Serving zu beginnen. Das bedeutet, dass die geschichteten Daten immer noch vorhanden und nicht verloren sind.

Quelle

2013-02-06 21:59:09

Ein Shard ist ein Bereich von Daten der sharded-Sammlung, ein Replikat kann ohne Shard existieren und ein Shard kann ohne Replikat existieren. – Sammaye

@Sammaye Ich verstehe nicht, wie ein Replikat-Set in einer Shard-Umgebung selbst existieren kann. (Könnten Sie meinen, dass es in einer Umgebung ohne Shared kein Shard sein muss?) Wenn wir "Shard" sagen, meinen wir nicht, dass das Replikat-Set Teil eines größeren Datenbereichs ist? Über die Tatsache, dass die Shards in der Lage sind, ohne eine Replik zu existieren, stimme ich jedoch zu. Aber das war nicht der Fall, den er durchsetzte, also passte ich meine Antwort auf sein Szenario an, das Repliken, keine einzelnen Einheiten umfasste. –

Genau die Definition von Shard befindet sich nicht immer in einer replizierten Umgebung, es klang wie die "Definition" eines Shards in einer Replik. Ich bin immer noch unsicher, was Sie mit der "Summe eines Primär- und Sekundärteils" meinen, denn wenn das der Fall wäre, hätte das Primärgerät (der Splitter) keine doppelten Daten. Die Secondaries sind Replikate des Primärs, der Shard, naja, irgendwie, hängt von der Replikation ab – Sammaye

Wie funktioniert MongoDB gleichzeitig sharding und replication?

Antwort

Verwandte Themen