Tipps zur MongoDB-Schemaplanung

Eines der am meisten beworbenen Merkmale von MongoDB ist seine Fähigkeit, „schemalos“ zu sein. Dies bedeutet, dass MongoDB kein Schema für Dokumente auferlegt, die in einer Sammlung gespeichert sind. Normalerweise speichert MongoDB Dokumente in einem JSON-Format, sodass jedes Dokument verschiedene Arten von Schemas/Strukturen speichern kann. Dies ist für die Anfangsphasen der Entwicklung von Vorteil, aber in späteren Phasen möchten Sie möglicherweise eine gewisse Schemavalidierung erzwingen, während Sie neue Dokumente für eine bessere Leistung und Skalierbarkeit einfügen. Kurz gesagt bedeutet „schemalos“ nicht, dass Sie Ihr Schema nicht entwerfen müssen. In diesem Artikel werde ich einige allgemeine Tipps für die Planung Ihres MongoDB-Schemas erörtern.

Das Herausfinden des besten Schemadesigns, das zu Ihrer Anwendung passt, kann manchmal mühsam werden. Hier sind einige Punkte, die Sie beim Entwerfen Ihres Schemas berücksichtigen können.

Vermeiden Sie wachsende Dokumente

Wenn Ihr Schema das Erstellen von Dokumenten zulässt, deren Größe kontinuierlich zunimmt, sollten Sie Maßnahmen ergreifen, um dies zu vermeiden, da dies zu einer Verschlechterung der DB- und Festplatten-E / A-Leistung führen kann. Standardmäßig erlaubt MongoDB eine Größe von 16 MB pro Dokument. Wenn Ihre Dokumentgröße im Laufe der Zeit um mehr als 16 MB ansteigt, ist dies ein Zeichen für ein schlechtes Schemadesign. Dies kann manchmal zum Fehlschlagen von Abfragen führen. Sie können Dokument-Buckets oder Techniken zur Vorabzuordnung von Dokumenten verwenden, um diese Situation zu vermeiden. Falls Ihre Anwendung Dokumente mit einer Größe von mehr als 16 MB speichern muss, können Sie die Verwendung der MongoDB GridFS-API in Betracht ziehen.

Vermeiden Sie es, ganze Dokumente zu aktualisieren

Wenn Sie versuchen, das gesamte Dokument zu aktualisieren, schreibt MongoDB das gesamte Dokument an einer anderen Stelle im Speicher neu. Dies kann die Schreibleistung Ihrer Datenbank drastisch beeinträchtigen. Anstatt das gesamte Dokument zu aktualisieren, können Sie Feldmodifikatoren verwenden, um nur bestimmte Felder in den Dokumenten zu aktualisieren. Dadurch wird ein direktes Update im Arbeitsspeicher ausgelöst, wodurch die Leistung verbessert wird.

Versuchen Sie Verknüpfungen auf Anwendungsebene zu vermeiden

Wie wir alle wissen, unterstützt MongoDB keine Joins auf Serverebene. Daher müssen wir alle Daten aus der DB abrufen und dann Join auf Anwendungsebene durchführen. Wenn Sie Daten aus mehreren Sammlungen abrufen und eine große Datenmenge zusammenführen, müssen Sie die DB mehrmals anrufen, um alle erforderlichen Daten zu erhalten. Dies wird natürlich mehr Zeit in Anspruch nehmen, da es das Netzwerk betrifft. Als Lösung für dieses Szenario ist es sinnvoller, das Schema zu denormalisieren, wenn Ihre Anwendung stark auf Verknüpfungen angewiesen ist. Sie können eingebettete Dokumente verwenden, um alle erforderlichen Daten in einem einzigen Abfrageaufruf abzurufen.

Verwenden Sie die richtige Indexierung

Bei der Suche oder Aggregation sortiert man oft Daten. Auch wenn Sie die Sortierung in der letzten Phase einer Pipeline beantragen, benötigen Sie dennoch einen Index, um die Sortierung abzudecken. Wenn der Index im Sortierfeld nicht verfügbar ist, wird MongoDB gezwungen, ohne Index zu sortieren. Es gibt eine Speichergrenze von 32 MB der Gesamtgröße aller Dokumente, die an der Sortieroperation beteiligt sind. Wenn MongoDB dieses Limit erreicht, kann es entweder einen Fehler erzeugen oder einen leeren Satz zurückgeben.

Nachdem wir das Hinzufügen von Indizes besprochen haben, ist es auch wichtig, keine unnötigen Indizes hinzuzufügen. Für jeden Index, den Sie der Datenbank hinzufügen, müssen Sie alle diese Indizes aktualisieren, während Sie Dokumente in der Sammlung aktualisieren. Dies kann die Datenbankleistung beeinträchtigen. Außerdem belegt jeder Index etwas Platz und Speicherplatz, sodass die Anzahl der Indizes zu speicherbezogenen Problemen führen kann.

Eine weitere Möglichkeit, die Verwendung eines Index zu optimieren, besteht darin, das Standardfeld _id zu überschreiben. Der einzige Zweck dieses Felds besteht darin, ein eindeutiges Feld pro Dokument beizubehalten. Wenn Ihre Daten einen Zeitstempel oder ein beliebiges ID-Feld enthalten, können Sie das _id-Feld überschreiben und einen zusätzlichen Index speichern.

Verhältnis Lesen vs. Schreiben

Das Entwerfen von Schemas für eine beliebige Anwendung hängt stark davon ab, ob eine Anwendung leselastig oder schreiblastig ist. Wenn Sie beispielsweise ein Dashboard zum Anzeigen von Zeitreihendaten erstellen, sollten Sie Ihr Schema so entwerfen, dass der Schreibdurchsatz maximiert wird. Wenn Ihre Anwendung E-Commerce-basiert ist, werden die meisten Vorgänge Lesevorgänge sein, da die meisten Benutzer alle Produkte durchgehen und verschiedene Kataloge durchsuchen werden. In solchen Fällen sollten Sie ein denormalisiertes Schema verwenden, um die Anzahl der DB-Aufrufe zum Abrufen relevanter Daten zu reduzieren.

BSON-Datentypen

Stellen Sie sicher, dass Sie BSON-Datentypen für alle Felder richtig definieren, während Sie das Schema entwerfen. Denn wenn Sie den Datentyp eines beliebigen Felds ändern, schreibt MongoDB das gesamte Dokument in einen neuen Speicherplatz. Wenn Sie beispielsweise versuchen, (int)0 anstelle des Felds (float)0.0 zu speichern, schreibt MongoDB das gesamte Dokument aufgrund der Änderung des BSON-Datentyps an einer neuen Adresse neu.

Schlussfolgerung

Kurz gesagt, es ist ratsam, ein Schema für Ihre Mongo-Datenbank zu entwerfen, da dies nur die Leistung Ihrer Anwendung verbessert. Ab Version 3.2 unterstützt MongoDB die Dokumentenvalidierung, bei der Sie definieren können, welche Felder zum Einfügen eines neuen Dokuments erforderlich sind. Ab Version 3.6 führte MongoDB eine elegantere Methode zur Durchsetzung der Schemavalidierung mithilfe der JSON-Schemavalidierung ein. Mit dieser Validierungsmethode können Sie die Überprüfung des Datentyps zusammen mit der Überprüfung der erforderlichen Felder erzwingen. Sie können die obigen Ansätze verwenden, um zu überprüfen, ob alle Dokumente denselben Schematyp verwenden oder nicht.