Cluster-Bereitstellungen sind von großer Bedeutung, um die Hochverfügbarkeit von Daten zu gewährleisten und diese zu schützen. MongoDB verbessert dies durch Replikation und Sharding, wobei die Replikation die vertikale Skalierung durch das Aufheben von Redundanz gewährleistet, während das Sharding die horizontale Skalierung aufbläht.
Im Allgemeinen versuchen beide Ansätze, die Arbeitslast auf die Mitglieder zu verteilen und somit die Arbeitslast zu reduzieren, der ein einzelner Knoten ausgesetzt sein könnte. Die Datenbankleistung kann dann als schnell angesehen werden, wenn Benutzer mit Durchsatzvorgängen bedient werden. Ohne eine erstklassige Cluster-Architektur sehen Sie jedoch möglicherweise nicht die gleichen Ergebnisse, selbst wenn Sie Sharding und Replikation versuchen.
Wenn die Replikat-Set-Mitglieder ausgeglichen sind, wird es für die Mitglieder schwierig sein, für eine neue Primäre zu stimmen und zu wählen, wenn die bestehende irgendwann ausfällt. In diesem Blog werden wir die Standard-Bereitstellungsarchitektur diskutieren, die man verwenden kann, aber diese kann je nach Anwendungsanforderungen variieren.
MongoDB-Bereitstellungsstrategien
Die Architektur von Replikatsätzen ist sehr ausschlaggebend für die Kapazität und Leistungsfähigkeit von MongoDB.
Ein Replica-Set mit drei Knoten ist die Standard-Cluster-Bereitstellung für MongoDB in jeder Produktionsumgebung, da es Datenredundanz und Fehlertoleranz bietet. Redundanz ist besonders bei der Datenbankwiederherstellung nach einem Katastrophenfall wichtig. Ein Replikatsatz mit drei Knoten kann die grundlegende Bereitstellungsarchitektur sein, aber dies kann je nach Anwendungsspezifikationen und -anforderungen variieren. Machen Sie es jedoch nicht zu komplex, da dies zu größeren Konfigurationsproblemen führen kann.
MongoDB-Sharding-Strategien
Sharding reduziert die Arbeitslast, die die Datenbank für eine bestimmte Abfrage bearbeiten muss, indem die Anzahl der zu bearbeitenden Dokumente reduziert wird. Es erhöht daher die horizontale Skalierung, sodass die Datenbank über die Hardwaregrenzen eines einzelnen Servers hinaus wachsen kann. Je nach Workload-Anforderung können Knoten zum Cluster hinzugefügt oder daraus entfernt werden, und MongoDB gleicht die Daten auf optimale Weise ohne Eingreifen des Betriebs neu aus.
Einige der besten Bereitstellungsstrategien für einen Sharding-Cluster sind:
Sicherstellen, dass Shard Keys einheitlich verteilt werden
Der Grund für das Sharding besteht darin, die Datenbank horizontal zu skalieren und die Anzahl der Durchsatzvorgänge zu reduzieren, denen eine einzelne Instanz ausgesetzt sein könnte. Wenn Sie die Shard-Schlüssel nicht einheitlich verteilen, erhalten Sie möglicherweise eine kleine Anzahl von Shards. Bei wenigen Shards können Vorgänge durch die Kapazität eines einzelnen Shards begrenzt sein, wodurch Lese- und Schreibvorgänge langsam werden.
Chunks sollten vorab aufgeteilt und zuerst verteilt werden
Shards haben Datenblöcke, die nach einigen Shard-Schlüsselkriterien gruppiert sind. Beim Erstellen einer neuen Shard-Sammlung sollten Sie vor dem Laden mit Daten leere Chunks erstellen und diese gleichmäßig auf alle Shards verteilen. Wenn Sie MongoDB mit Daten füllen, ist es einfach, die Last auf die beteiligten Shards auszugleichen. Die Option numInitialChunks kann verwendet werden, um dies automatisch zu tun, wenn Sie Hash-basiertes Sharding verwenden. Der ganzzahlige Wert sollte jedoch kleiner als 8192 pro Shard sein.
Anzahl der Scherben
Zwei Shards sind häufig als Mindestanzahl erforderlich, damit die Sharding-Signifikanz erreicht wird. Ein einzelner Shard ist nur nützlich, wenn Sie die Grundlage für die zukünftige Aktivierung von Sharding legen möchten und während der Bereitstellungszeit keinen Bedarf haben.
Range-basiertes Sharding dem Hash-basierten Sharding vorziehen
Bereichsbasiertes Sharding ist vorteilhaft, da es mehr Shards bereitstellt, sodass Operationen an die wenigsten erforderlichen Shards und häufiger an ein einzelnes Shard geleitet werden können. In der Praxis kann dies schwierig sein, es sei denn, Sie haben ein gutes Verständnis der beteiligten Daten- und Abfragemuster. Hash-Sharding verbessert die gleichmäßige Verteilung des Durchsatzvorgangs auf Kosten der Bereitstellung schlechterer bereichsbasierter Vorgänge.
Verwenden Sie Scatter-Gather-Abfragen nur für große Aggregationsabfragen
Abfragen, die nicht basierend auf einem Shard-Schlüssel weitergeleitet werden können, sollten zur Auswertung an alle Shards gesendet werden, und da sie mehrere Shards für jede Anfrage umfassen, skalieren sie nicht linear, wenn mehr Shards hinzugefügt werden, wodurch ein Overhead entsteht die die Leistung der Datenbank beeinträchtigen. Dieser Vorgang wird als Scatter-Gather bezeichnet und kann nur vermieden werden, wenn Sie den Shard-Schlüssel in Ihre Abfrage einbeziehen.
Der Ansatz ist nur nützlich, wenn es um große Aggregationsabfragen geht, bei denen jede Abfrage parallel auf allen Shards ausgeführt werden kann.
MongoDB-Replikationsstrategien
Die Replikation verbessert die vertikale Skalierung in MongoDB, sodass die Arbeitslast auf die beteiligten Mitglieder verteilt wird. In der Produktionsumgebung sind dies einige der Überlegungen, die man für eine optimale Cluster-Architektur anstellen sollte.
Anzahl der Knoten
Ein Replikatsatz kann maximal 50 Knoten mit 7 stimmberechtigten Mitgliedern haben. Jedes Mitglied nach dem 7. gilt als nicht stimmberechtigt. Ein guter Cluster sollte daher 7 stimmberechtigte Mitglieder haben, um den Wahlprozess bequem zu gestalten.
Stellen Sie eine ungerade Anzahl an stimmberechtigten Mitgliedern ein und wenn Sie nur weniger als 7, aber eine gerade Anzahl an Mitgliedern haben, müssen Sie einen Schiedsrichter als weiteres stimmberechtigtes Mitglied einsetzen. Arbiter speichern keine Kopie der Daten und benötigen daher weniger Ressourcen für die Verwaltung. Außerdem kann man sie einer Umgebung aussetzen, der man die anderen Mitglieder nicht aussetzen könnte.
Überlegungen zur Fehlertoleranz
Manchmal können einige Mitglieder aufgrund von Faktoren wie Stromausfällen oder Netzwerktransienten und -trennungen nicht mehr verfügbar sein. Die Anzahl der Mitglieder, die in der Gruppe verbleiben und in der Lage sind, einen Primären zu wählen, schafft eine Situation, die als Fehlertoleranz bekannt ist. Es ist daher die Differenz zwischen der Gesamtzahl der Nachbildungssatzmitglieder und der Mehrheit der stimmberechtigten Mitglieder, die erforderlich ist, um eine Primärwahl zu wählen. Das Fehlen eines Primärnamens bedeutet, dass Schreibvorgänge nicht ausgeführt werden können.
Die folgende Tabelle zeigt eine beispielhafte Beziehung zwischen den dreien.
| Gesamtzahl der Replikat-Set-Mitglieder | Mehrheit erforderlich, um neue Vorwahlen zu wählen | Fehlertoleranz |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
| 6 | 4 | 2 |
| 7 | 5 | 2 |
Die Beziehung ist insofern nicht so direkt, als Sie der Menge weitere Mitglieder hinzufügen, dass die Fehlertoleranz nicht erhöht wird, wie aus der Tabelle ersichtlich ist. Zusätzliche Mitglieder bieten Unterstützung für dedizierte Funktionen wie Sicherungen und Berichterstellung.
Kapazitätsplanung und Lastenausgleich für starke Lesevorgänge
Sie müssen eine freie Kapazität für Ihre Bereitstellung haben, indem Sie neue Mitglieder hinzufügen, bevor die aktuelle Nachfrage die Kapazität des vorhandenen Satzes sättigt.
Verteilen Sie bei sehr hohem Leseverkehr die Durchsatz-Lesevorgänge auf die sekundären Mitglieder, und wenn der Cluster wächst, fügen Sie Mitglieder hinzu oder verschieben Sie sie in alternative Rechenzentren, um Redundanz zu erreichen und die Datenverfügbarkeit zu erhöhen.
Sie können auch Zieloperationen mit Tag-Sets verwenden, um Leseoperationen auf bestimmte Mitglieder auszurichten, oder Schreibanliegen ändern, um eine Bestätigung von bestimmten Mitgliedern anzufordern.
Knoten sollten geografisch verteilt sein
Rechenzentren können auch aufgrund einer Katastrophe ausfallen . Es wird daher empfohlen, mindestens ein oder zwei Mitglieder aus Datenschutzgründen in einem separaten Rechenzentrum zu halten. Verwenden Sie nach Möglichkeit eine ungerade Anzahl von Rechenzentren und wählen Sie eine Verteilung, die die Wahrscheinlichkeit maximiert, dass selbst bei Verlust eines Rechenzentrums die verbleibenden Mitglieder des Replikatsatzes eine Mehrheit bilden oder zumindest eine Kopie der Daten bereitstellen können.
Benutzen Sie Journaling für unerwartete Fehler
Standardmäßig ist dies in MongoDB aktiviert. Stellen Sie sicher, dass diese Option aktiviert ist, um Datenverlusten im Falle von Dienstunterbrechungen wie plötzlichen Neustarts und Stromausfällen vorzubeugen.
Bereitstellungsmuster
Es gibt hauptsächlich zwei Bereitstellungsansätze, nämlich:
- Drei Mitgliedsreplikatsätze, die die empfohlene Mindestarchitektur für einen Replikatsatz bereitstellen.
- Replikatsatz verteilt auf zwei oder mehr Rechenzentren zum Schutz vor einrichtungsspezifischen Ausfällen wie Stromausfällen.
Die Muster sind jedoch von den Anwendungsanforderungen abhängig, aber wenn möglich, können Sie die Funktionen dieser beiden in Ihrer Bereitstellungsarchitektur kombinieren.
Hostnamen und Replica-Set-Benennung
Verwenden Sie einen logischen DNS-Hostnamen anstelle einer IP-Adresse, wenn Sie Replikatsatzmitglieder oder Sharding-Clustermitglieder konfigurieren. Dies soll den Aufwand vermeiden, der mit Konfigurationsänderungen verbunden ist, die Sie aufgrund geänderter IP-Adressen vornehmen müssen.
Verwenden Sie im Fall der Benennung von Replikatgruppen unterschiedliche Namen für die Gruppen, da einige Treiber Replikatgruppenverbindungen nach Replikatgruppennamen gruppieren.
Fazit
Das Architekturlayout für einen Replikatsatz bestimmt die Kapazität und Leistungsfähigkeit Ihrer Bereitstellung. Datenschutz und Systemleistung sind die Kernüberlegungen beim Aufbau der Architektur. Man sollte wichtige Faktoren wie Fehlertoleranz, Anzahl der Replikatsatzmitglieder, optimalen Sharding-Schlüssel und Bereitstellungsmuster für Hochverfügbarkeit und Datenschutz berücksichtigen. Die geografische Verteilung der Replica-Set-Knoten kann viele dieser Faktoren angehen, indem Redundanz sichergestellt und Fehlertoleranz bereitgestellt wird, wenn eines der Rechenzentren fehlt.
