MongoDB Sharding: Schritt-für-Schritt-Anleitung mit Beispiel

Was ist Sharding? MongoDB?

Sharding ist ein Konzept in MongoDB, das große Datensätze in mehrere kleine Datensätze aufteilt MongoDB Instanzen.

Manchmal sind die Daten darin MongoDB Die Datenmengen werden so umfangreich sein, dass Abfragen an solch große Datensätze eine hohe CPU-Auslastung des Servers verursachen können. Um diesem Problem zu begegnen, MongoDB verfügt über ein Sharding-Konzept, bei dem es sich im Wesentlichen um die Aufteilung von Datensätzen auf mehrere handelt MongoDB Instanzen.

Die Sammlung, die durchaus groß sein kann, ist tatsächlich auf mehrere Sammlungen, sogenannte Shards, aufgeteilt. Logisch betrachtet funktionieren alle Shards wie eine einzige Sammlung.

Vorteile des Sharding in MongoDB

Vor der Implementierung eines Sharded Clusters ist es hilfreich zu verstehen, warum Teams Sharding einsetzen. Die wichtigsten Vorteile sind:

• Horizontale Skalierbarkeit: Die Daten werden auf viele Standardserver verteilt, anstatt eine einzelne Maschine immer größer werden zu lassen.
• Höherer Durchsatz: Lese- und Schreibvorgänge werden parallel über die Shards hinweg ausgeführt, sodass der Cluster mehr Anfragen pro Sekunde bearbeiten kann.
• Größere Speicherkapazität: Die kombinierte Festplatte aller Shards kann Datensätze speichern, die weitaus größer sind, als ein einzelner Server speichern könnte.
• Hohe Verfügbarkeit: Wenn jeder Shard als Replikatset bereitgestellt wird, führt der Ausfall eines einzelnen Knotens nicht zum Ausfall des gesamten Clusters.
• Ausgeglichene Last: Das MongoDB Der Balancer verteilt Datenblöcke automatisch neu, um zu verhindern, dass ein einzelner Shard zu einem Hotspot wird.

Zusammengenommen machen diese Vorteile Sharding zum Standardansatz für die Skalierung. MongoDB über die Grenzen eines einzelnen Servers hinaus.

So implementieren Sie Sharding

Shards werden mithilfe von Clustern implementiert, die nichts anderes sind als eine Gruppe von MongoDB Instanzen.

Die Bestandteile eines Splitters umfassen:

1. Eine Scherbe – Das ist das Grundlegende, und das ist nichts anderes als ein MongoDB Instanz, die die Teilmenge der Daten enthält. In Produktionsumgebungen müssen alle Shards Teil von Replikatsätzen sein.
2. Konfigurationsserver - Dies ist ein MongoDB Instanz, die Metadaten über den Cluster enthält, im Grunde Informationen über die verschiedenen MongoDB Instanzen, die die Shard-Daten enthalten werden.
3. Ein Router - Dies ist ein MongoDB Die Instanz, die im Wesentlichen dafür zuständig ist, die vom Client gesendeten Befehle an die richtigen Server weiterzuleiten.

Schritt für Schritt Sharding Cluster Beispiel

Schritt 1) Erstellen Sie eine separate Datenbank für den Konfigurationsserver.

mkdir /data/configdb

Schritt 2) Starte das MongoDB Instanz im Konfigurationsmodus. Angenommen, wir haben einen Server namens Server D, der unser Konfigurationsserver sein soll. Wir müssten den folgenden Befehl ausführen, um den Server als Konfigurationsserver zu konfigurieren.

mongod --configdb ServerD:27019

Schritt 3) Starten Sie die Mongos-Instanz, indem Sie den Konfigurationsserver angeben.

mongos --configdb ServerD:27019

Schritt 4) Stellen Sie über die Mongo-Shell eine Verbindung zur Mongos-Instanz her.

mongo --host ServerD --port 27017

Schritt 5) Falls Sie Server A und Server B haben, die dem Cluster hinzugefügt werden müssen, führen Sie die folgenden Befehle aus.

sh.addShard("ServerA:27017")
sh.addShard("ServerB:27017")

Schritt 6) Aktivieren Sie Sharding für die Datenbank. Wenn Sie die Employeedb-Datenbank sharden möchten, führen Sie den folgenden Befehl aus.

sh.enableSharding("Employeedb")

Schritt 7) Aktivieren Sie Sharding für die Sammlung. Wenn Sie also die Mitarbeitersammlung sharden möchten, führen Sie den folgenden Befehl aus.

sh.shardCollection("Employeedb.Employee", { "Employeeid": 1, "EmployeeName": 1 })

Wie man einen Shard Key auswählt MongoDB

Der Shard-Schlüssel ist das indizierte Feld oder die indizierte Feldgruppe, die MongoDB Der Schlüssel bestimmt, welcher Shard welches Dokument speichert. Da der Schlüssel die Datenverteilung steuert, ist seine Wahl die wichtigste Entscheidung bei einer Sharded-Bereitstellung. Ein ungeeigneter Schlüssel konzentriert Daten und Datenverkehr auf einen einzigen Shard und macht so die Vorteile des Shardings zunichte.

Ein starker Shard-Schlüssel weist im Allgemeinen folgende Eigenschaften auf:

• Hohe Kardinalität: Das Feld sollte viele mögliche Werte haben, damit die Daten in viele fein abgestufte Einheiten unterteilt werden können.
• Niedrige Frequenz: Kein einzelner Wert sollte dominieren, da sonst die Dokumente, die diesen Wert teilen, auf einem einzigen Splitter zusammenlaufen.
• Nicht-monotone Veränderung: Schlüssel, die sich ständig erhöhen, wie z. B. Zeitstempel, senden jeden neuen Schreibvorgang an denselben Shard und erzeugen so einen Hotspot.

MongoDB Unterstützt werden zwei Sharding-Strategien basierend auf dem Schlüssel. Ranged Sharding teilt Daten in zusammenhängende Bereiche auf und eignet sich für Bereichsabfragen, während Hashed Sharding eine Hash-Funktion anwendet, um Schreibvorgänge gleichmäßig auf die Shards zu verteilen. Teams beginnen oft mit Hashed Sharding, wenn viele Schreibvorgänge anfallen, und wechseln zu Ranged Sharding, wenn bereichsbasierte Lesevorgänge überwiegen. Unabhängig von der gewählten Strategie sollte der Schlüssel vor der endgültigen Festlegung anhand realistischer Abfragemuster getestet werden, da der Shard-Schlüssel nach dem Laden der Daten nicht mehr ohne Weiteres geändert werden kann.

Sharding vs Replikation in MongoDB

Sharding und Replikation sind komplementäre, aber unterschiedliche Funktionen. Die folgende Tabelle verdeutlicht die Unterschiede, damit Sie die jeweilige Funktion korrekt anwenden können. In der Praxis werden in Produktionsclustern beide Verfahren gemeinsam eingesetzt.

Kurz gesagt, Sharding erfüllt das Bedürfnis nach Skalierbarkeit, während Replikation das Bedürfnis nach Verfügbarkeit erfüllt, und eine robuste Bereitstellung kombiniert beides.

Häufig gestellte Fragen