Best Practices für die Ausführung von MongoDB in einem Cluster

Das Bereitstellen einer geclusterten Datenbank ist eine Sache, aber wie Sie Ihr DBM im Cluster verwalten, kann ein großes Unterfangen für eine konsistente Bereitstellung Ihrer Anwendungen sein. Man sollte häufig über den Status der Datenbank informiert sein, insbesondere über die wichtigsten Metriken, um einen Hinweis darauf zu erhalten, was aktualisiert oder besser gesagt geändert werden muss, um eventuell auftretende Engpässe zu vermeiden.

Es gibt viele Überlegungen in Bezug auf MongoDB, die man berücksichtigen sollte, insbesondere die Tatsache, dass die Installation und Ausführung recht einfach sind. Die Wahrscheinlichkeit, dass grundlegende Datenbankverwaltungspraktiken vernachlässigt werden, ist hoch.

Viele Entwickler versäumen es manchmal, zukünftiges Wachstum und eine erhöhte Nutzung der Datenbank zu berücksichtigen, was folglich zu einem Absturz von Anwendungen oder Daten mit einigen Integritätsproblemen führt, abgesehen davon, dass sie inkonsistent sind.

In diesem Artikel werden wir einige der Best Practices diskutieren, die man für MongoDB-Cluster anwenden sollte, um eine effiziente Leistung Ihrer Anwendungen zu gewährleisten. Zu den Faktoren, die man berücksichtigen sollte, gehören...

1. Upgrade auf die neueste Version
2. Geeignete Speicher-Engine
3. Hardware-Ressourcenzuweisung
4. Replikation und Sharding
5. Serverkonfigurationsdatei niemals ändern
6. Gute Sicherheitsstrategie

Upgrade auf die neueste Version

Ich habe mit MongoDB von Versionen vor 3.2 gearbeitet und ehrlich gesagt war es damals nicht einfach. Mit großartigen Entwicklungen, behobenen Fehlern und neu eingeführten Funktionen rate ich Ihnen, Ihre Datenbank immer auf die neueste Version zu aktualisieren. So wirkte sich die Einführung des Aggregation-Frameworks besser auf die Performance aus, als auf das bereits vorhandene Map-Reduce-Konzept zu setzen. Mit der neuesten Version 4.0 hat man jetzt die Möglichkeit, die Multi-Dokument-Transaktionsfunktion zu nutzen, die den Durchsatz im Allgemeinen verbessert. Die neueste Version hat auch einige zusätzliche neue Typkonvertierungsoperatoren wie $toInt, $toString, $trim und $toBool. Diese Operatoren werden bei der Validierung von Daten sehr hilfreich sein und somit ein gewisses Gefühl der Datenkonsistenz schaffen. Wenn Sie ein Upgrade durchführen, beziehen Sie sich bitte auf die Dokumentation, damit Sie kleine Fehler vermeiden können, die sich als Fehler eskalieren könnten.

Wählen Sie eine geeignete Speicher-Engine aus

MongoDB unterstützt derzeit 3 ​​Speicher-Engines:WiredTiger, In-Memory und MMAPv1-Speicher-Engines. Jede dieser Speicher-Engines hat Vorzüge und Einschränkungen gegenüber der anderen, aber Ihre Wahl hängt von Ihrer Anwendungsspezifikation und der Kernfunktionalität der Engine ab. Ich persönlich bevorzuge jedoch die WiredTiger-Speicher-Engine und würde sie jedem empfehlen, der sich nicht sicher ist, welche er verwenden soll. Die WiredTiger-Speicher-Engine ist für die meisten Workloads gut geeignet und bietet ein Parallelitätsmodell auf Dokumentebene, Checkpointing und Komprimierung.

Einige der Überlegungen zur Auswahl der Speicher-Engine hängen von diesen Aspekten ab:

1. Transaktionen und Atomizität: Bereitstellung von Daten während einer Einfügung oder Aktualisierung, die nur dann begangen wird, wenn alle Bedingungen und Anwendungsschritte erfolgreich ausgeführt wurden. Operationen werden daher in einer unveränderlichen Einheit gebündelt. Damit können Transaktionen mit mehreren Dokumenten unterstützt werden, wie in der neuesten Version von MongoDB für die WiredTiger-Speicher-Engine zu sehen ist.
2. Sperrtyp: es ist eine Kontrollstrategie für den Zugriff oder die Aktualisierung von Informationen. Während der Sperrdauer kann keine andere Operation die Daten des ausgewählten Objekts ändern, bis die aktuelle Operation ausgeführt wurde. Folglich sind Abfragen zu diesem Zeitpunkt betroffen, daher ist es wichtig, sie zu überwachen und den Umfang des Sperrmechanismus zu reduzieren, indem Sie sicherstellen, dass Sie die am besten geeignete Speicher-Engine für Ihre Daten auswählen.
3. Indexierung: Speicher-Engines in MongoDB bieten abhängig von den Datentypen, die Sie speichern, unterschiedliche Indizierungsstrategien. Die Effizienz dieser Datenstruktur sollte mit Ihrer Arbeitslast recht freundlich sein, und Sie können dies feststellen, indem Sie jeden zusätzlichen Index als leistungssteigernd betrachten. Schreiboptimierte Datenstrukturen haben einen geringeren Overhead für jeden Index in einer Anwendungsumgebung mit vielen Einfügungen als nicht schreiboptimierte Datenstrukturen. Dies wird ein großer Rückschlag sein, insbesondere wenn eine große Anzahl von Indizes beteiligt ist und eine ungeeignete Speicher-Engine ausgewählt wird. Daher kann die Auswahl einer geeigneten Speicher-Engine dramatische Auswirkungen haben.

Hardware-Ressourcenzuweisung

Wenn sich neue Benutzer bei Ihrer Anwendung anmelden, wächst die Datenbank mit der Zeit und es werden neue Shards eingeführt. Sie können sich jedoch nicht auf die Hardwareressourcen verlassen, die Sie während der Bereitstellungsphase eingerichtet haben. Die Arbeitslast wird entsprechend zunehmen und erfordert daher mehr Verarbeitungsressourcen wie CPU und RAM, um Ihre großen Datencluster zu unterstützen. Dies wird oft als Kapazitätsplanung in MongoDB bezeichnet. Zu den Best Practices rund um die Kapazitätsplanung gehören:

• Überwachen Sie Ihre Datenbank ständig und passen Sie sie entsprechend den Erwartungen an. Wie bereits erwähnt, wird eine Zunahme der Benutzerzahl fortan mehr Abfragen mit einer erhöhten Arbeitslast auslösen, insbesondere wenn Sie Indizes verwenden. Sie können diese Auswirkungen am Anwendungsende bemerken, wenn es beginnt, eine Änderung des Prozentsatzes von Schreibvorgängen im Vergleich zu Lesevorgängen mit der Zeit aufzuzeichnen. Sie müssen daher Ihre Hardwarekonfigurationen neu konfigurieren, um dieses Problem zu beheben. Verwenden Sie mongoperf und das MMS-Tool, um Änderungen der Systemleistungsparameter zu erkennen.
• Dokumentieren Sie alle Ihre Leistungsanforderungen im Voraus. Wenn Sie auf dasselbe Problem stoßen, haben Sie zumindest einen Anhaltspunkt, der Ihnen Zeit spart. Ihre Aufzeichnung sollte die Größe der Daten, die Sie speichern möchten, die Analyse der Abfragen in Bezug auf die Latenz und die Datenmenge, auf die Sie zu einem bestimmten Zeitpunkt zugreifen möchten, beinhalten. In der Produktionsumgebung müssen Sie bestimmen, wie viele Anfragen Sie pro Sekunde verarbeiten und wie viel Latenz Sie tolerieren werden.
• Inszenieren Sie einen Machbarkeitsnachweis. Führen Sie ein Schema-/Indexdesign durch, verstehen Sie die Abfragemuster und verfeinern Sie dann Ihre Schätzung der Arbeitssatzgröße. Notieren Sie diese Konfiguration als Referenzpunkt für Tests mit nachfolgenden Überarbeitungen der Anwendung.
• Führen Sie Ihre Tests mit echter Arbeitsbelastung durch. Stellen Sie nach Durchführung der Phase des Proof-Konzepts erst bereit, nachdem Sie umfangreiche Tests mit realen Daten und Leistungsanforderungen durchgeführt haben.

Replikation und Sharding

Dies sind die beiden Hauptkonzepte zur Gewährleistung einer Hochverfügbarkeit von Daten bzw. einer erhöhten horizontalen Skalierbarkeit im MongoDB-Cluster.

Sharding partitioniert im Grunde genommen Daten serverübergreifend in kleine Portionen, die als Shards bezeichnet werden. Der Datenausgleich zwischen Shards erfolgt automatisch, Shards können hinzugefügt oder entfernt werden, ohne dass die Datenbank unbedingt offline geschaltet werden muss.

Die Replikation am anderen Ende bewahrt mehrere redundante Kopien der Daten für hohe Verfügbarkeit. Es ist eine integrierte Funktion in MongoDB und funktioniert über Weitverkehrsnetzwerke, ohne dass spezialisierte Netzwerke erforderlich sind. Für ein Cluster-Setup empfehle ich, dass Sie mindestens 2+ Mongos, 3 Konfigurationsserver, 1 Shard haben und die Konnektivität zwischen den am Sharding-Cluster beteiligten Computern sicherstellen. Verwenden Sie in der Konfiguration einen DNS-Namen anstelle von IPs.

Verwenden Sie für Produktionsumgebungen einen Replikatsatz mit mindestens 3 Mitgliedern und denken Sie daran, mehr Konfigurationsvariablen wie oplog-Größe zu füllen.

Wenn Sie Ihre Mongod-Instanzen für Ihre Mitglieder starten, verwenden Sie dieselbe Schlüsseldatei.

Einige der Überlegungen zu Ihrem Shardkey sollten Folgendes beinhalten:

• Schlüssel und Wert sind unveränderlich
• Erwägen Sie immer die Verwendung von Indizes in einer fragmentierten Sammlung
• Der Befehl zum Aktualisieren des Treibers sollte einen Shard-Schlüssel enthalten
• Eindeutige Einschränkungen, die vom Shard-Schlüssel verwaltet werden müssen.
• Ein Shard-Schlüssel darf keine speziellen Indextypen enthalten und darf 512 Byte nicht überschreiten.

Serverkonfigurationsdatei niemals ändern

Nach der ersten Bereitstellung ist es ratsam, nicht viele Parameter in der Konfigurationsdatei zu ändern, da Sie sonst Probleme bekommen können, insbesondere mit Shards. Das schwächste Glied beim Sharding sind die Konfigurationsserver. Das heißt, alle Mongod-Instanzen müssen laufen, damit Sharding funktioniert.

Gute Sicherheitsstrategie

MongoDB war in den letzten Jahren anfällig für externe Angriffe, daher ist es wichtig, dass Ihre Datenbank über einige Sicherheitsprotokolle verfügt. Abgesehen davon, dass die Prozesse in verschiedenen Ports ausgeführt werden, sollte man mindestens eine der 5 verschiedenen Möglichkeiten zum Sichern von MongoDB-Datenbanken anwenden. Sie können Plattformen wie MongoDB Atlas in Betracht ziehen, die Datenbanken standardmäßig durch Verschlüsselung der Daten sowohl während der Übertragung als auch im Ruhezustand sichern. Sie können Strategien wie TLS/SSL für alle eingehenden und ausgehenden Verbindungen verwenden.

Schlussfolgerung

Die MongoDB-Clustersteuerung ist keine leichte Aufgabe und erfordert viele Problemumgehungen. Datenbanken wachsen als Folge von mehr Benutzern und damit einer erhöhten Arbeitsbelastung. On hat daher den Auftrag, sicherzustellen, dass die Leistung des DBM dieser gestiegenen Anzahl von Benutzern entspricht. Die Best Practices gehen über die Erhöhung der Hardwareressourcen und die Anwendung einiger MongoDB-Konzepte wie Sharding, Replikation und Indizierung hinaus. Viele der möglicherweise auftretenden Unannehmlichkeiten lassen sich jedoch gut durch ein Upgrade Ihrer MongoDB-Version beheben. Häufiger haben die neuesten Versionen Fehler behoben, neue Feature-Anforderungen integriert und fast keine negativen Auswirkungen auf das Upgrade, selbst bei größeren Revisionsnummern.