MongoDB
 sql >> Datenbank >  >> NoSQL >> MongoDB

Vorbereiten eines MongoDB-Servers für die Produktion

Nachdem Sie Ihre Anwendung und Ihr Datenbankmodell entwickelt haben (wenn es an der Zeit ist, die Umgebung in die Produktion zu verlagern), müssen zunächst einige Dinge erledigt werden. Entwickler versäumen es oft, weitere wichtige MongoDB-Schritte zu berücksichtigen, bevor sie die Datenbank in der Produktion bereitstellen. Folglich stoßen sie im Produktionsmodus auf grundlegende Rückschläge, die im Entwicklungsmodus nicht dargestellt werden. Manchmal kann es zu spät sein, oder vielmehr würden viele Daten verloren gehen, wenn eine Katastrophe eintritt. Außerdem werden einige der hier besprochenen Schritte es einem ermöglichen, den Zustand der Datenbank einzuschätzen und somit notwendige Maßnahmen zu planen, bevor eine Katastrophe eintritt.

Aktuelle Version und neueste Treiber verwenden

Im Allgemeinen verfügen die neuesten Versionen jeder Technologie über verbesserte Funktionen in Bezug auf die zugrunde liegende Funktionalität als ihre Vorgänger. Die neuesten Versionen von MongoDB sind robuster und verbessert als ihre Vorgänger in Bezug auf Leistung, Skalierbarkeit und Speicherkapazität. Dasselbe gilt für die zugehörigen Treiber, da sie von den Kerndatenbankingenieuren entwickelt und sogar häufiger aktualisiert werden als die Datenbank selbst.

Native Erweiterungen, die für Ihre Sprache installiert sind, können leicht eine Plattform für schnelle und standardmäßige Verfahren zum Testen, Genehmigen und Aktualisieren der neuen Treiber bilden. Es gibt auch Automotive-Software wie Ansible, Puppet, SaltStack und Chef, die für ein einfaches Upgrade der MongoDB in all Ihren Knoten verwendet werden kann, ohne dass professionelle Kosten und Zeit anfallen.

Erwägen Sie auch die Verwendung der WiredTiger-Speicher-Engine, da sie die am weitesten entwickelte mit modernen Funktionen ist, die den Erwartungen moderner Datenbanken entsprechen

Abonnieren Sie eine MongoDB-Mailingliste, um die neuesten Informationen in Bezug auf Änderungen an neuen Versionen und Treibern sowie Fehlerbehebungen zu erhalten und somit auf dem Laufenden zu bleiben.

Verwenden Sie ein 64-Bit-System, um MongoDB auszuführen

In 32-Bit-Systemen sind MongoDB-Prozesse auf etwa 2,5 GB an Daten beschränkt, da die Datenbank speicherabgebildete Dateien für die Leistung verwendet. Dies wird zu einer Einschränkung für Prozesse, die die Grenze überschreiten könnten, was zu einem Crush führt. Die Hauptauswirkung wird sein:Im Falle eines Fehlers können Sie den Server erst neu starten, wenn Sie Ihre Daten entfernen oder Ihre Datenbank auf ein höheres System wie 64-Bit migrieren, was zu einer höheren Ausfallzeit für Ihre Anwendung führt.

Wenn Sie weiterhin ein 32-Bit-System verwenden müssen, muss Ihre Codierung sehr einfach sein, um die Anzahl der Fehler und die Latenz für Durchsatzvorgänge zu reduzieren.

Für komplexe Codes wie Aggregations-Pipeline und Geodaten ist es jedoch ratsam, das 64-Bit-System zu verwenden.

Stellen Sie sicher, dass Dokumente auf eine Größe von 16 MB begrenzt sind

MongoDB-Dokumente sind auf eine Größe von 16 MB beschränkt, aber Sie müssen sich dieser Grenze nicht nähern, da dies zu Leistungseinbußen führt. In der Praxis haben die Dokumente meistens eine Größe von KB oder weniger. Die Dokumentgröße hängt von der Datenmodellierungsstrategie zwischen Einbettung und Referenzierung ab. Das Einbetten wird bevorzugt, wenn erwartet wird, dass die Dokumentgröße nicht stark anwächst. Wenn Sie beispielsweise eine Social-Media-Anwendung haben, in der Benutzer posten und die Kommentare enthält, besteht die beste Vorgehensweise darin, zwei Sammlungen zu haben, eine, um Post-Informationen zu speichern.

  {

   _id:1,

   post: 'What is in your mind?',

   datePosted: '12-06-2019',

   postedBy:'xyz',

   likes: 10,

   comments: 30

}

und der andere, um Kommentare für diesen Beitrag zu speichern.

     {

   _id: ObjectId('2434k23k4'),

   postId: 1,

   dateCommented: '12-06-2019',

   commentedBy:'ABCD',

   comment: 'When will we get better again',

}

Durch solche Datenmodelle werden Kommentare in einer anderen Sammlung als der Beitrag gespeichert. Dadurch wird verhindert, dass das Dokument in der Post-Sammlung über die Grenzen hinauswächst, falls es so viele Kommentare geben wird. Stellen Sie sicher, dass Sie Anwendungsmuster vermeiden, die ein unbegrenztes Wachstum von Dokumenten ermöglichen würden.

Stellen Sie sicher, dass der Arbeitssatz in den Speicher passt

Die Datenbank kann möglicherweise keine Daten aus dem virtuellen Speicher (RAM) lesen, was zu Seitenfehlern führt. Seitenfehler zwingen die Datenbank, Daten von einer physischen Festplatte zu lesen, was zu einer erhöhten Latenz und folglich zu einer Verzögerung der Gesamtleistung der Anwendung führt. Seitenfehler treten auf, wenn mit einem großen Satz gearbeitet wird, der nicht in den Speicher passt. Dies kann darauf zurückzuführen sein, dass einige Dokumente eine unbegrenzte Größe oder eine schlechte Sharding-Strategie haben. Abhilfemaßnahmen für Seitenfehler sind:

  • Sicherstellen, dass Dokumente auf die Größe von 16 MB begrenzt sind.
  • Gewährleistung einer guten Sharding-Strategie durch Auswahl eines optimalen Sharding-Schlüssels, der die Anzahl der Dokumente begrenzt, denen ein Durchsatzvorgang unterzogen wird.
  • Erhöhen Sie die Größe der MongoDB-Instanz, um mehr Arbeitssätze aufzunehmen.

Stellen Sie sicher, dass Sie Replik-Sets vorhanden sind

In der Welt der Datenbanken ist es nicht ideal, sich auf eine einzelne Datenbank zu verlassen, da eine Katastrophe eintreten kann. Außerdem würden Sie erwarten, dass die Anzahl der Benutzer der Datenbank zunimmt, und müssen daher eine hohe Datenverfügbarkeit sicherstellen. Die Replikation ist ein entscheidender Ansatz, um im Falle eines Failovers eine hohe Verfügbarkeit sicherzustellen. MongoDB kann Daten geografisch bereitstellen:Das bedeutet, dass Benutzer von verschiedenen Standorten vom nächstgelegenen Cloud-Host bedient werden, um die Latenz für Anfragen zu reduzieren.

Falls der primäre Knoten ausfällt, können die sekundären Knoten einen neuen auswählen, um mit den Schreibvorgängen Schritt zu halten, anstatt dass die Anwendung während des Failovers eine Ausfallzeit hat. Tatsächlich unterstützen einige Cloud-Hosting-Plattformen, die bei der Replikation sehr rücksichtsvoll sind, nicht repliziertes MongoDB für Produktionsumgebungen.

Journaling aktivieren

Journaling führt zwar zu Leistungseinbußen, ist aber auch wichtig. Das Journaling verbessert die Write-Ahead-Operationen, was bedeutet, dass, falls die Datenbank bei der Durchführung einer Aktualisierung fehlschlägt, die Aktualisierung irgendwo gespeichert wurde und wenn sie wieder aktiv wird, der Vorgang abgeschlossen werden kann. Journaling kann die Wiederherstellung nach einem Absturz erleichtern und sollte daher standardmäßig aktiviert sein.

Stellen Sie sicher, dass Sie eine Backup-Strategie aufstellen

Viele Unternehmen können nach Datenverlust aufgrund fehlender oder schlechter Sicherungssysteme nicht weiterarbeiten. Stellen Sie vor dem Bereitstellen Ihrer Datenbank in der Produktion sicher, dass Sie eine dieser Sicherungsstrategien verwendet haben:

  • Mongodump :optimal für kleine Bereitstellungen und bei der Erstellung von Backups, die nach bestimmten Anforderungen gefiltert werden.
  • Grundlegendes kopieren :optimal für große Bereitstellungen und effizienter Ansatz, um vollständige Backups zu erstellen und wiederherzustellen.
  • MongoDB-Verwaltungsdienst (MMS) :bietet kontinuierliches Online-Backup für MongoDB als vollständig verwalteten Dienst. Optimal für Sharding-Cluster und Replikatsätze.

Sicherungsdateien sollten auch nicht beim selben Hostanbieter der Datenbank gespeichert werden. Backup Ninja ist ein Dienst, der dafür verwendet werden kann.

Seien Sie auf langsame Abfragen vorbereitet

Langsame Abfragen sind in der Entwicklungsumgebung aufgrund der geringen Datenmenge kaum zu realisieren. Dies ist jedoch in der Produktion möglicherweise nicht der Fall, wenn man bedenkt, dass Sie viele Benutzer haben oder viele Daten beteiligt sind. Langsame Abfragen können auftreten, wenn Sie keine Indizes oder einen nicht optimalen Indizierungsschlüssel verwendet haben. Trotzdem sollten wir einen Weg finden, der Ihnen den Grund für langsame Abfragen zeigt.

Wir beschließen daher, MongoDB Query Profiler zu aktivieren. So sehr dies zu Leistungseinbußen führen kann, hilft der Profiler beim Aufdecken von Leistungsproblemen. Bevor Sie Ihre Datenbank bereitstellen, müssen Sie den Profiler für die Sammlungen aktivieren, von denen Sie vermuten, dass sie langsame Abfragen haben, insbesondere solche, die Dokumente mit vielen Einbettungen beinhalten.

Mit einem Überwachungstool verbinden

Kapazitätsplanung ist ein sehr wichtiges Unterfangen in MongoDB. Sie müssen auch jederzeit den Zustand Ihrer Datenbank kennen. Der Einfachheit halber sparen Sie Zeit, wenn Sie Ihre Datenbank mit einem Überwachungstool verbinden, um zu erkennen, was Sie brauchen, um Ihre Datenbank mit der Zeit zu verbessern. Beispielsweise weist eine grafische Darstellung, die auf eine langsame CPU-Leistung als Ergebnis erhöhter Abfragen hinweist, Sie an, Ihrem System mehr Hardwareressourcen hinzuzufügen.

Überwachungstools verfügen auch über ein Warnsystem durch E-Mail oder Kurznachrichten, die Sie bequem über einige Probleme auf dem Laufenden halten, bevor sie sich zu einer Katastrophe entwickeln. Stellen Sie daher in der Produktion sicher, dass Ihre Datenbank mit einem Überwachungstool verbunden ist.

ClusterControl bietet kostenlose MongoDB-Überwachung in der Community Edition.

Implementieren Sie Sicherheitsmaßnahmen

Datenbanksicherheit ist ein weiteres wichtiges Merkmal, das unbedingt berücksichtigt werden muss. Sie müssen die MongoDB-Installation in der Produktion schützen, indem Sie sicherstellen, dass einige Sicherheitschecklisten vor der Produktion eingehalten werden. Einige der Überlegungen sind:

  • Rollenbasierte Zugriffskontrolle konfigurieren
  • Zugriffskontrolle aktivieren und Authentifizierung erzwingen
  • Eingehende und ausgehende Verbindungen verschlüsseln (TLS/SSL)
  • Begrenzen der Netzwerkexposition
  • Daten verschlüsseln und schützen
  • Haben Sie einen Trackplan für den Zugriff und Änderungen an Datenbankkonfigurationen

Vermeiden Sie externe Injektionen, indem Sie MongoDB mit sicheren Konfigurationsoptionen ausführen. Beispielsweise das Deaktivieren von serverseitigem Scripting, wenn keine serverseitigen JavaScript-Operationen wie mapReduce und $where verwendet werden. Verwenden Sie den JSON-Validator für Ihre Sammlungsdaten über einige Module wie Mongoose, um sicherzustellen, dass alle gespeicherten Dokumente im gültigen BSON-Format vorliegen.

Überlegungen zu Hardware und Software 

MongoDB hat nur wenige Hardware-Voraussetzungen, da es explizit mit großer Rücksicht auf die notwendige Commodity-Hardware entwickelt wurde. Im Folgenden finden Sie die wichtigsten Hardwareüberlegungen für MongoDB, die Sie vor der Bereitstellung in der Produktion berücksichtigen müssen.

  • Ordnen Sie ausreichend RAM und CPU zu
  • Verwenden Sie die WiredTiger-Speicher-Engine. Entwickelt, um den Dateisystem-Cache und den internen WiredTiger-Cache zu verwenden, wodurch die Leistung gesteigert wird. Wenn Sie beispielsweise mit einem System mit 4 GB RAM arbeiten, verwendet der WiredTiger-Cache 1,5 GB RAM (0,5 * (4 GB - 1 GB) =1,5 GB), während ein System mit 1,2 GB RAM WiredTiger-Cache nur 256 MB verwendet.
  • NUMA-Hardware. Es gibt zahlreiche betriebliche Probleme, darunter eine langsame Leistung und eine hohe Systemprozessauslastung. Daher sollte man erwägen, eine Speicherverschachtelungsrichtlinie zu konfigurieren.
  • Festplatten- und Speichersystem:Solid State Disk (SSDs) verwenden:MongoDB zeigt besseres Preis-Leistungs-Verhältnis mit SATA-SSD

Fazit

Datenbanken in der Produktion sind sehr wichtig, um einen reibungslosen Geschäftsbetrieb zu gewährleisten, und sollten daher mit vielen Überlegungen behandelt werden. Man sollte einige Verfahren festlegen, die helfen können, Fehler zu reduzieren, oder vielmehr einen einfachen Weg bieten, diese Fehler zu finden. Außerdem ist es ratsam, ein Warnsystem einzurichten, das den Zustand der Datenbank mit Zeit für die Kapazitätsplanung und das Erkennen von Problemen anzeigt, bevor sie zu einer Katastrophe werden.