MongoDB in kleinen Umgebungen laufen lassen

Gepostet am 11. Dezember 2023 • 6 Minuten • 1161 Wörter • Andere Sprachen: English

Ich mag MongoDB sehr gerne und habe die Datenbank in den letzten 12 Jahren in einer Vielzahl von Projekten verwendet. So basiert MemArc beispielsweise seit seinen Anfängen auf MongoDB und ich habe diese Entscheidung niemals bereut.

In diesem Artikel gehe ich auf einige Optionen ein und erkläre, wie man Mongo in kleinen Umgebungen wie virtuellen Maschinen oder Raspberry Pis einrichten kann. Ich habe keine wirklich guten Anleitungen für diesen speziellen Anwendungsfall gefunden, also habe ich mein eigenes Tutorial verfasst.

Warum?

Warum sollte man Mongo in einer kleinen Umgebung einrichten wollen? Hier einige Ideen:

Mongo für kleine Anwendungen, die nicht besonders viele Daten benötigen. Es macht Spaß, Mongo zu verwenden, also warum nicht auch für ein kleines Projekt mit ein paar hundert oder tausend Datensätzen?
Einrichten einer kleinen Entwicklungsumgebung, die nicht den Großteil des RAMs beansprucht.
Aggregieren von Zeitreihen auf einem Raspi-Server im Keller – wenn das Modell allerdings nur über 2 GB RAM verfügt, will man es vielleicht trotzdem für ein cooles Projekt nutzen.

Vorbereitungen und Vorüberlegungen

Ich nehme an, dass Mongo-Datenbank auf irgendeine Weise eingerichtet wurde, entweder als Einzelserver oder als Replica Set. Es gibt viele Anleitungen im Internet dazu. Als Referenz kann außerdem die Installationsanleitung auf der Mongo Website dienen. Es spielt keine Rolle, ob der Server direkt oder als Container (Docker oder Podman) eingerichtet wurde.

In der Grundkonfiguration verhält sich Mongo folgendermaßen:

RAM-Nutzung: Standardmäßig verwendet Mongo bis zu 50% von (RAM - 1 GB) und mindestens 256 MB für den Cache. Wenn der eine Rechner also 8 GB RAM besitzt, dann wird Mongo bis zu 3 GB für seinen WiredTiger-Cache (Indizes) veranschlagen. Dies ist der einfachste und wichtigste Parameter zum Anpassen (siehe unten).
Festplattengröße: Alle modernen Mongo-Implementierungen verwenden den WiredTiger-Speicher-Engine, was bedeutet, dass die Daten auf der Festplatte standardmäßig komprimiert werden (standardmäßig mit Snappy-Kompression, es sei denn, man ändert das). Kleine Datenbestände verwenden damit nur wenige Kilobyte (wie 20 kb), daher muss man sich im Allgemeinen keine Gedanken über die Festplattenbelegung machen. Indizes erhöhen dies, und wie bei anderen Datenbank-Engines können viele Indizes auf großen Datensätzen die Festplattenbelegung erheblich erhöhen. Dennoch, wenn wir mit relativ kleinen Datenmenge hantieren, ist die Belegung des Festplattenspeichers zweitrangig (ignorieren Sie alte Anleitungen, die empfehlen, den Parameter smallFiles` festzulegen: Er wird seit Version 4.2 nicht mehr unterstützt).
CPU: Im Leerlauf verbraucht Mongo nicht viel CPU. Lediglich Abfragen verbrauchen relativ viel CPU und ähnlich wie bei anderen Datenbanksystemem ist CPU weniger wichtig als der Datendurchsatz der Festplatten. Wenn Sie also keine völlig verrückten Abfragen planen, können Sie den CPU vernachlässigen - und in kleinen Datenbeständen plant man ja eh keine wilden Abfragen, richtig?

Replica Set oder nicht?

Sollten man in kleinen Umgebungen ein Replikatsatz verwenden? Nun, das hängt vom Anwendungsfall ab. Ich betreibe einige kleine Instanzen als eigenständige Server, und kann ziemlich ruhig schlafen. Ich erstelle einmal täglich ein Backup und schiebe es auf eine entfernten Maschine. Diese Instanzen sind weder geschäftskritisch noch enthalten sie viele veränderliche Daten. Und bei solchen kleinen Datensätzen sind Backups nicht wirklich umständlich, daher ist der Betrieb als einzelne Node in einem solchen Szenario meiner Meinung nach völlig in Ordnung. In den letzten 12 Jahren habe ich nie Daten auf einer Mongo-Maschine aufgrund von Softwarefehlern oder einer Beschädigung der Datenbank verloren, ich habe da durchaus Vertrauen in den Speichermechanismus von Mongo. Wenn man Replikation verwendet, sollte man sicher stellen, dass die Instanzen auf verschiedenen Maschinen laufen und die Speicherung auf unterschiedlichen physischen Speicherorten erfolgt. Andernfalls macht ein Replica Set nicht viel Sinn, außer dass es Upgrades auf der zugrunde liegenden Infrastruktur erleichtert.

Kurz, man benötigt kein Replica Set, wenn:

sich die Daten nicht allzu oft ändern.
Backups schnell und leicht zu machen sind (kleine Datenbestände).
Downtimes von einigen Minuten kein Problem sind (während Updates).

Wenn eine dieser Bedingungen nicht erfüllt ist, sollte man die Verwendung eines Replica Sets erwägen. Es sollte dann halt korrekt eingerichtet sein (mehrere Server, verschiedene Speicherorte usw.)!

RAM-Benutzung anpassen

Wer eine begrenzte Menge an RAM zur Verfügung hat, dem hilft die wichtigste Option des Tages: wiredTigerCacheSizeGB. In den meisten Szenarien ist ausreichend, diesen Parameter zu setzen. Der einfachste Weg erfolgt über die Kommandozeile: Starten Sie Ihren Mongo-Server einfach mit --wiredTigerCacheSizeGB 0.5, um den Cache auf 0,5 GB RAM zu begrenzen. Das Minimum beträgt 0,25 GB (was für sehr kleine Datensätze völlig ausreichend ist).

Alternativ kann der Parameter auch in der Konfigurationsdatei festgelegt werden (normalerweise /etc/mongod.conf):

storage:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 0.5

Weitere Informationen dazu in der offiziellen Dokumentation .

Wer diesen Wert sehr niedrig setzt, sollte verstehen, dass die Cachegröße recht begrenzt sein wird. Wenn die Datensätze wachsen, kann diese zu Performanceproblemen führen. Wer lediglich einige tausend Datensätze verwaltet, muss sich darüber in der Regel keine Gedanken machen.

Um sicher zu gehen, kann man seine Insanz(en) auf der Mongo Shell nach ihrem Befinden befragen:

db.serverStatus().tcmalloc.tcmalloc.formattedString

Dies erzeugt eine hübsche Übersicht über die aktuelle Benutzung des Speichers. Weitere Parameter können in der Dokumentation abgefragt werden.

Weitere Einstellungen

Es gibt noch einige weitere Einstellungen, die man anpassen kann. Meistens mache ich mir nicht die Mühe, sie für kleine Datensätze oder Server zu ändern. Der Vollständigkeit halber seien sie hier jedoch aufgeführt.

Als erstes sollte man über den virtuellen Speicher nachdenken und wie er auf der Maschinen gehandhabt wird. Die “dirty ratio” ist der Prozentsatz des gesamten Systemspeichers, der “schmutzige Speicherseiten” halten kann, bevor diese auf die Festplatte gebannt werden. Viele Anleitungen empfehlen für MongoDB Folgendes (in der Datei /etc/sysctl.conf oder via sysctl):

vm.dirty_background_ratio = 5
vm.dirty_ratio = 15

swappiness ist eine weitere Einstellung. Damit beeinflusst man, wie eifrig Speicherseiten auf die Festplatte auslagert werden. Die folgende Einstellung wird im Allgemeinen für Datenbankserver empfohlen (1 bedeutet, den Auslagerungsspeicher nur zu verwenden, um Probleme mit nicht ausreichendem Arbeitsspeicher (OOM) zu vermeiden):

vm.swappiness = 1

Mongo kann sich beim Start auch über die NUMA (Non-Uniform Access)-Architektur oder die Verwendung von “Transparent HugePages” beschweren. Informationen dazu finden Sie in der Dokumentation. Bei NUMA muss man den Mongo-Prozess mit numactl --interleave=all starten. Transparent HugePages können über eine Einstellung in Grub deaktiviert werden (transparent_hugepage=never).

Mongo wird sich auch beschweren, wenn man auf seinem Linux-Server kein XFS verwendet. WiredTiger und EXT4 haben einige Randprobleme in Bezug auf die Leistung. Bei kleinen Projekten würde ich mir darüber allerdings keine Gedanken machen. Wer keine Möglichkeit hat, eine hübscge XFS-Partition auf seinem virtuellen Server einzurichten, muss dies also nicht tun. Das gleiche gilt für Instanzen, die nicht auf einer SSD laufen. Kleine Instanzen laufen ohne Probleme auf der SD-Karte eines Raspis oder auf einem USB-Stick (würg).

Alle Optionen und Dinge, an die man denken sollte, befinden sich in der Dokumentation zum Betrieb von Mongo .

Fazit

Es ist völlig in Ordnung, MongoDB auf einem kleinen Server oder einer virtuellen Maschine mit sehr begrenztem Speicher laufen zu lassen. Solange die Datenmenge klein ist, gibt es in der Regel keine Probleme. Die wichtigste Einstellung in einer solchen Umgebung ist die Befehlszeilenoption wiredTigerCacheSizeGB. Sie ist Ihr Freund, um Mongo so anzupassen, dass es nicht zu viel Speicher verbraucht. Über die weiteren Einstellungen kann man sich Gedanken machen, muss man aber nicht.

Durch die Einloggen bei den Kommentaren werden zwei Cookies gesetzt. Mehr Informationen im Impressum.