Um eine MongoDB auf Geschwindigkeit zu bekommen ist das Thema Ressourcen nicht zu unterschätzen. Zum Beispiel: In der BestPractice benötigt man im Sharding (d.h. die Verteilung der Daten auf verschiedene Knoten in einem Cluster) eine Computereinheit je Knoten („Shard“). Wenn man noch eine Replikation einplant, so kommt man schnell auf eine nicht unerhebliche Anzahl von Computereinheiten.
Abbildung: Beispiel einer hochverfügbaren MongoDB Architektur mit drei Zonen, drei Replikation-Sets zwei Konfigurations Servern, zwei Routern und ein Applikationsserver für Compass und den Opsmanager auf AWS-Instanzen
Ein zweiter wichtiger Aspekt ist der Arbeitsspeicher. Man muss grundsätzlich davon ausgehen, dass die MongoDB aus Performanzgründen sehr viele Daten in den Arbeitsspeicher läd.
Wirklich relevant sind dabei die Indizes und die „Worksets“. Indizes werden komplett geladen, während die Worksets nur die Daten beinhaltet, die bei den Abfragen genutzt werden. D.h. Wenn immer nur ein einzelnes Dokument abgefragt wird, dann ist der Workset relativ klein, wenn aber Abfragen auf dem kompletten Datenbestand erfolgt (z.B. in der Aggregation-Pipeline), dann ist der Workset groß.
Um dies zu Unterstützen allokiert die MongoDB erst mal mehr als 50% der RAMs eines Rechners. Dies ist zu beachten, wenn man konkurrierende Systeme auf einen Rechner hochläd. Dies beeinflusst deutlich die Stabilität der Datenbank. Man bewerte dieses Verhalten mit einer Architektur auf Dockerbasis. Hier muss man aufpassen, da einem einzelnen Dockercontainer grundsätzlich immer die Ressource des Hostrechners zur Verfügung steht. Eine Überallokierung von Arbeitsspeicher eines Hostsystems ist in dem Fall wahrscheinlich, kann aber durch geeignete Konfigurationsmaßnahmen auf Seiten der MongoDB verhindert werden.
Um Anhaltspunkte bzgl. der Dimensionierung einer MongoDb zu geben, möchte ich hier ein paar Kenngrößen aus der Praxis zeigen:
- Datenbankgröße: ~ 60 Gb
- Anzahl Dokumente: ~ 14 Mio.
- Durchschnittliche Dokumentengröße: ~ 4 kB
- Index Anzahl: 9
- Indexgröße auf „_id“: ~ 160 Mb
- Indexgröße „Compound“ (zusammengesetzt): ~ 110 Mb
- Indexgröße Single (geringe Kardinalität): ~ 60 Mb
- Indexgröße Single (hohe Kardinalität): ~ 122 Mb
- Indexgröße total: ~ 500 Mb
- Bytes im Cache (im Arbeitsspeicher): ~ 3,4 Gb
Zusammenfassung
Ressourcen sind ein großes Thema. Abhängig vom Anwendungsfall ist die Anzahl der Computereinheiten (CU) wichtig, aber auch die Höhe des Arbeitsspeichers je Einheit. Die Architektur einer MongoDB ist darauf abzustimmen. Grundsätzlich sollten
- Konkurrenzen verhindert
- ausreichend Arbeitsspeicher vorhanden
sein um eine performante und stabile MongoDB-Infrastruktur zu gewährleisten.
