Die Replikation scheint viel einfacher zu sein als das Sharding, es sei denn, ich vermisse die Vorteile dessen, was Sharding tatsächlich zu erreichen versucht. Bieten beide nicht eine horizontale Skalierung?

Im Zusammenhang mit der Skalierung von MongoDB:

• Die Replikation erstellt zusätzliche Kopien der Daten und ermöglicht ein automatisches Failover auf einen anderen Knoten. Die Replikation kann bei der horizontalen Skalierung von Lesevorgängen hilfreich sein, wenn Sie Daten lesen können, die möglicherweise nicht die neuesten sind.

• Sharding ermöglicht die horizontale Skalierung von Datenschreibvorgängen, indem Daten mithilfe eines Shard-Schlüssels auf mehrere Server verteilt werden. Es ist wichtig , einen guten Shard-Schlüssel zu wählen . Beispielsweise kann eine schlechte Auswahl des Shard-Schlüssels dazu führen, dass "Hot Spots" von Daten nur auf einen einzelnen Shard geschrieben werden.

Eine Sharded-Umgebung erhöht die Komplexität, da MongoDB jetzt die Verteilung von Daten und Anforderungen zwischen Shards verwalten muss. Zusätzliche Konfigurations- und Routing-Prozesse werden hinzugefügt, um diese Aspekte zu verwalten.

Replikation und Sharding werden normalerweise kombiniert, um einen Sharded-Cluster zu erstellen, in dem jeder Shard von einem Replikatsatz unterstützt wird.

Aus Sicht der Clientanwendung haben Sie auch eine gewisse Kontrolle in Bezug auf die Replikations- / Sharding-Interaktion, insbesondere:

• Einstellungen lesen
• Schreiben Sie Bedenken

Angenommen, Sie haben eine großartige Musiksammlung auf Ihrer Festplatte. Sie speichern die Musik in logischer Reihenfolge basierend auf dem Erscheinungsjahr in verschiedenen Ordnern. Sie befürchten, dass Ihre Sammlung verloren geht, wenn das Laufwerk ausfällt. Sie erhalten also eine neue Festplatte und kopieren gelegentlich die gesamte Sammlung unter Beibehaltung derselben Ordnerstruktur.

Sharding >> Speichern Sie Ihre Musikdateien in verschiedenen Ordnern

Replikation >> Synchronisieren Sie Ihre Sammlung mit anderen Laufwerken

Bei der Replikation handelt es sich hauptsächlich um ein traditionelles Master / Slave-Setup. Die Daten werden mit den Sicherungsmitgliedern synchronisiert, und wenn die primäre ausfällt, kann einer von ihnen an seine Stelle treten. Es ist ein ziemlich einfaches Werkzeug. Es ist in erster Linie für Redundanz gedacht, obwohl Sie Lesevorgänge skalieren können, indem Sie Replikatsatzmitglieder hinzufügen. Das ist etwas kompliziert, funktioniert aber für einige Apps sehr gut.

Sharding befindet sich normalerweise über der Replikation. "Shards" in MongoDB sind nur Replikatsets mit einem sogenannten "Router" vor sich. Ihre Anwendung stellt eine Verbindung zum Router her, gibt Abfragen aus und entscheidet, an welchen Replikatsatz (Shard) die Dinge weitergeleitet werden sollen. Es ist wesentlich komplexer als ein einzelnes Replikatset, da Sie über den Router und die Konfigurationsserver verfügen müssen (diese verfolgen, welche Daten wo gespeichert sind).

Wenn Sie Mongo horizontal skalieren möchten, würden Sie Scherben. 10gen ruft gerne das automatische Sharding des Routers / Konfigurationsservers auf. Es ist möglich, eine Ghetto-Form des Sharding durchzuführen, bei der die App entscheidet, in welche Datenbank auch geschrieben werden soll.

Scherben

Sharding ist eine Technik zum Aufteilen einer großen Sammlung auf mehrere Server. Beim Shard stellen wir mehrere mongodServer bereit. Und vorne ist mongosdas ein Router. Die Anwendung spricht mit diesem Router. Dieser Router kommuniziert dann mit verschiedenen Servern, den mongods. Die Anwendung und die mongosbefinden sich normalerweise auf demselben Server. mongosAuf demselben Computer können mehrere Dienste ausgeführt werden. Es wird auch empfohlen, mehrere mongods (zusammen als Replikatsatz bezeichnet ) anstelle eines einzelnen s mongodauf jedem Server beizubehalten. Ein Replikatsatz hält die Daten über mehrere verschiedene Instanzen hinweg synchron, sodass wir keine Daten verlieren, wenn eine davon ausfällt. Logischerweise kann jeder Replikatsatz als Shard angesehen werden. Es ist für die Anwendung transparent. Die Art und Weise, MongoDBwie Shard ausgewählt wird, ist die Auswahl eines Shard-Schlüssels .

Angenommen, studentwir haben für die Sammlung stdt_idden Shard-Schlüssel oder es könnte sich um einen zusammengesetzten Schlüssel handeln. Und der mongosServer ist ein bereichsbasiertes System. Basierend auf dem stdt_id, den wir als Shard-Schlüssel senden, wird die Anforderung an die richtige mongodInstanz gesendet.

Was müssen wir als Entwickler wirklich wissen?

• insert muss einen Shard-Schlüssel enthalten. Wenn es sich also um einen mehrteiligen Shard-Schlüssel handelt, müssen wir den gesamten Shard-Schlüssel einschließen
• Wir müssen verstehen, was der Shard-Schlüssel in der Sammlung selbst ist
• für eine update, remove, find- wenn mongosein Shard Schlüssel nicht gegeben - dann es geht zu haben , um die Anfrage an alle die verschiedenen Scherben ausgestrahlt, die die Sammlung decken.
• für eine update- wenn wir nicht die gesamte Scherbe Schlüssel angeben, müssen wir es ein Multi - Update machen , so dass es weiß , dass es sie zu übertragen braucht

Wann immer Sie an Sharding oder Replikation denken, müssen Sie im Kontext von Writern / Update-Vorgängen denken. Wenn Sie keine Schreibvorgänge skalieren müssen, sind Replikationen, da sie ziemlich einfach sind, eine gute Wahl für Sie.

Wenn Sie dagegen hauptsächlich Updates / Schreibvorgänge ausführen, stoßen Sie irgendwann auf einen Schreibengpass. Wenn eine Schreibanforderung kommt, blockiert Mongo eine andere Schreibanforderung. Diese schreiben Anforderungsblöcke, bis die erste Anforderung ausgeführt wird. Wenn Sie diese Schreibvorgänge skalieren und parallelisieren möchten, müssen Sie Sharding implementieren.

Sowohl die Replikation als auch das Sharding können (einzeln oder zusammen) für die horizontale Skalierung einer MongoDB-Installation verwendet werden.

Sharding ist die Lösung von MongoDB, um die Anforderungen des Datenwachstums zu erfüllen. Sharding speichert Datensätze auf mehreren Servern, um einen schnelleren Durchsatz bei Lese- und Schreibabfragen zu erzielen, insbesondere bei sehr großen Datenmengen. Jeder der Server im Sharded-Cluster kann auf einen Lese- oder Schreibvorgang reagieren, wodurch die Abfrageantworten erheblich beschleunigt werden.

Die Replikation ist die Lösung von MongoDB für die Bereitstellung von Stabilität, Sicherung und Notfallwiederherstellung für eine MongoDB-Installation. Dieser Prozess kopiert und synchronisiert den Replikatdatensatz auf mehreren Servern. Dies verhindert Ausfallzeiten, wenn ein Server offline geht.

Jeder der sekundären Server kann auf Leseanfragen antworten, aber nur der primäre Server führt Schreibvorgänge aus. Die Ergebnisse des Schreibvorgangs werden dann an die sekundären Server weitergegeben.

Szenario 1: Fehlertoleranz In diesem Szenario speichert der Benutzer Rechnungsdaten in einer MongoDB-Installation. Diese Daten sind für das Geschäft des Benutzers von entscheidender Bedeutung und müssen rund um die Uhr verfügbar sein, selbst wenn ein Server abstürzt oder offline geschaltet wird.

Die MongoDB-Replikation ist die beste Lösung für diesen Benutzer. Bei der Replikation wird der gesamte Datensatz auf mehreren Servern gespiegelt. Wenn ein Server ausfällt oder offline geschaltet wird, übernehmen die anderen Server im Cluster.

Szenario 2: Hohe Leistung In diesem Szenario führt der Benutzer eine Social-Networking-Site aus, die aus einer MongoDB-Datenbank ausgeführt wird. Mit dem Wachstum des sozialen Netzwerks ist auch der MongoDB-Datensatz gewachsen. Der Benutzer sieht, dass Abfragezeiten und Seitenladevorgänge über einen akzeptablen Punkt hinaus ansteigen. Es ist wichtig, dass die MongoDB-Installation des Benutzers eine erhebliche Leistungssteigerung erhält.

Das Einrichten eines Sharded-MongoDB-Clusters ist die beste Lösung für diesen Benutzer. Der Sharded-Cluster zerlegt den Datensatz des Benutzers und speichert Teile davon auf separaten sekundären Servern. Jeder sekundäre Server kann auf Lese- oder Schreibabfragen für seinen Teil der Daten antworten, was die Antwortzeit der Installation erheblich verlängert

MongoDB Atlas ist eine Datenbank als Service in könnte. Es unterstützt drei große Cloud-Anbieter wie Azure, AWS und GCP. In der Cloud-Umgebung sprechen wir normalerweise von hoher Verfügbarkeit und Skalierbarkeit. In Atlas können „Cluster“ entweder ein Replikatsatz oder ein Sharded-Cluster sein. Diese beiden Funktionen befassen sich mit Hochverfügbarkeits- und Skalierbarkeitsfunktionen unserer Cloud-Umgebung.

Im Allgemeinen ist Cluster eine Gruppe von Servern, mit denen eine bestimmte Aufgabe ausgeführt wird. Sharded-Cluster werden daher zum Speichern von Daten auf mehreren Computern verwendet, um die Anforderungen des Datenwachstums zu erfüllen. Mit zunehmender Datengröße reicht eine einzelne Maschine möglicherweise nicht aus, um die Daten zu speichern oder einen akzeptablen Lese- und Schreibdurchsatz bereitzustellen. Sharded-Cluster unterstützen die horizontale Skalierbarkeit der untergeordneten Cloud-Umgebung.

Ein Replikatsatz in MongoDB ist eine Gruppe von Mongod-Prozessen, die denselben Datensatz verwalten. Replikatsätze bieten Redundanz und Hochverfügbarkeit und bilden die Grundlage für alle Produktionsbereitstellungen. In einem Replikat ist ein Knoten ein Primärknoten, der alle Schreibvorgänge empfängt. Alle anderen Instanzen, z. B. Sekundärinstanzen, wenden Operationen von der Primärinstanz aus an, sodass sie denselben Datensatz haben. Das Replikatset konzentriert sich hauptsächlich auf die Verfügbarkeit von Daten.

Bitte überprüfen Sie die Dokumentation

Vielen Dank.

Nur um das irgendwo hin zu bringen ...

Die einfachste Art, Mongo auszuführen, ist ein eigenständiger Server.

• Sie schreiben eine Konfiguration (Datei- oder CLI-Optionen)
• Starten Sie den Server mit mongod

Für dieses Bild habe ich den "Client" nicht angegeben. Überprüfen Sie den nächsten.

• Ein Replikatsatz ist ein Satz von Servern, die genau wie oben mit einer anderen Konfigurationsdatei initialisiert wurden.
• Um sie zu verknüpfen, stellen wir eine Verbindung zu einem von ihnen her und initialisieren den Replikatsatzmodus.
• Sie spiegeln sich gegenseitig (in der gängigsten Konfiguration). Dieses System garantiert eine hohe Verfügbarkeit der Daten.

Die Initialisierung des Replikatsatzes wird im roten Rahmenfeld dargestellt.

• Beim Sharding geht es nicht um das Replizieren von Daten, sondern um das Fragmentieren von Daten.
• Jedes Datenfragment wird als Chunk bezeichnet und geht zu einem anderen Shard. Shard = jedes Replikatset.
• "Hauptserver", läuft mongosstatt mongod. Dies ist ein Router für Abfragen vom Client.

Offensichtlich : Der Kompromiss ist eine komplexere Architektur. Neuheit : Konfigurationsserver (wieder eine andere Konfigurationsdatei).

Es gibt noch viel mehr hinzuzufügen, aber abgesehen von den Worten sind die Bilder ähnlich.

Sogar mongoDB empfiehlt, Ihren Fall sorgfältig zu untersuchen, bevor Sie mit dem Sharding beginnen. Vertikale Skalierung (vs) ist wahrscheinlich mindestens einmal vor der horizontalen Skalierung (hs) eine gute Idee .

vs ist mit dem Upgrade der Hardware (CPU, RAM usw.) fertig. hs braucht mehr Computer (könnte aber billige Computer sein).