Planen Sie Ihre MongoDB Flex-Instanz

STACKIT bietet maximale Flexibilität in Verbindung mit MongoDB. Technische Einschränkungen erfordern jedoch bestimmte Beschränkungen. Um technische Schulden und damit Ausfallzeiten und unerwünschte zukünftige Migrationen zu vermeiden, ist es eine bewährte Methode, Ihre MongoDB Flex-Instanz im Voraus zu planen.

Planen Sie Ihren Bedarf

Bevor Sie die Größe Ihrer MongoDB Flex-Instanz auswählen, müssen Sie Ihre Datenmuster und Anforderungen analysieren:

Analyse des Datenvolumens

Beginnen Sie mit der Schätzung Ihrer aktuellen und prognostizierten Datenmenge. Berücksichtigen Sie die Dokumentengröße, die Anzahl der Collections und die Wachstumsrate in den nächsten 12-24 Monaten. MongoDB Flex speichert Daten im BSON-Format, das 10-15 % größer sein kann als JSON. Berücksichtigen Sie dies bei Ihren Berechnungen. Als Faustregel können Sie mit einem Faktor von 2 bis 2,5 für das Datenwachstum in den nächsten zwei Jahren rechnen.

Abfragemuster

Untersuchen Sie, wie Ihre Anwendung mit der Datenbank interagiert. Häufige komplexe Abfragen, Aggregationen und indexlastige Operationen erfordern mehr CPU- und Arbeitsspeicherressourcen. Anwendungen mit einem großen Verhältnis von Lese- zu Schreibvorgängen können von anderen Skalierungsstrategien profitieren als schreibintensive Workloads. Berücksichtigen Sie auch, ob Ihre Anwendung eher lese- oder schreiblastig ist.

Einschränkungen

Informationen zu den Flexibilitätseinschränkungen finden Sie unter Architektur von MongoDB Flex. Eine schnelle Übersicht finden Sie in dieser Tabelle:

Parameter	Downgrade möglich	Upgrade möglich	Ausfallzeit
type			-
flavor	x	x	x
performance-class	x (außer Single-Instanz)	x (außer Single-Instanz)	x
storage-size		x
version		x	x

Sie können Änderungen an den ACL- und Backup-Einstellungen ohne Einschränkungen und ohne Ausfallzeit vornehmen.

Best Practices

Sie müssen die Einschränkungen im Hinterkopf behalten. Dieser Abschnitt hilft Ihnen, gute Annahmen und Entscheidungen für die Einrichtung einer Instanz zu treffen.

Instanztyp

Wenn Sie eine Instanz für den Produktionseinsatz einrichten möchten, müssen Sie zwischen den Instanztypen Replikatsatz und Sharded Cluster unterscheiden. In den meisten Fällen ist Replikatsatz die bessere Option. In den folgenden Fällen können Sie die Verwendung eines Sharded Cluster in Betracht ziehen:

Geografisches Sharding

• Compliance-Anforderungen (EU-Benutzer bleiben in der EU usw.)
• Daten, auf die von mehreren Regionen aus zugegriffen werden muss

Sharding aufgrund hoher Datenmengen

• Speicherbegrenzungen einzelner Server (Multi-TB-Datensätze)
• Der Arbeitssatz passt nicht in den Arbeitsspeicher einer einzelnen Maschine
• Die Indexgröße übersteigt die Kapazität eines einzelnen Servers

Sharding zur Leistungssteigerung

Lese- & Schreib-Skalierbarkeit: Verteilen von Lese- und Schreibvorgängen auf mehrere Server (nur möglich, wenn die Operationen unabhängig von anderen Shards sind)

Sharding (außer geografisches Sharding) sollte das letzte Mittel sein. Versuchen Sie zuerst, die Ziele mit Replikatsätzen, Indizierung und vertikaler Skalierung zu erreichen.

Nachteile des Shardings:

• Fügt Komplexität hinzu
• Verringert die Leistung bei Abfragen, die von mehreren Shards abhängen

Flavor

Zuerst müssen Sie entscheiden, ob kurze Ausfallzeiten akzeptabel sind. Wenn ja, können Sie mit einem kleinen Flavor beginnen und diesen aufrüsten, wenn Sie konstant 80% der CPU- oder Arbeitsspeicherauslastung erreichen. Wenn keine Ausfallzeit akzeptabel ist, müssen Sie Ihren Bedarf schätzen.

Als Faustregel können Sie dieses Regelwerk verwenden:

CPU

• Leselastig: 2-4 CPUs ausreichend
• Schreiblastig oder Aggregationen: 8+ CPUs
• Sharded Cluster: Zusätzliche CPUs für den mongos-Router

RAM

• Minimum: 25 % der Datenmenge + Indexgröße
• Optimal: 50-75 % der aktiven Datenmenge + Indexgröße
• Faustregel: Mindestens 8 GB RAM, besser 32 GB+ für die Produktion

Sie können davon ausgehen, dass der Index etwa 30 % Ihrer Datenmenge ausmacht.

Performance-Klasse

Für die Performance-Klasse müssen Sie ebenfalls unterscheiden, ob kurze Ausfallzeiten akzeptabel sind. Wenn nicht, müssen Sie Ihren Bedarf schätzen.

Als Faustregel können Sie dieses Regelwerk verwenden:

IOPS:

• Leselastig: 1000-3000 IOPS
• Schreiblastig: 3000-10000+ IOPS
• Gemischte Workloads: 2000-5000 IOPS

Datenspeichergröße

Da die Datenspeichergröße jederzeit ohne Ausfallzeit vergrößert werden kann, ist es sicher, mit einer kleineren Größe zu beginnen. Als Faustregel beginnen Sie mit Ihrer Datenmenge, multipliziert mit 1,3 für den Index und nochmals multipliziert mit 3 für den Wachstumsfaktor.

Version

Beginnen Sie mit der höchsten Version, die Ihre Client-Anwendungen unterstützen.