MongoDB

MongoDB ist die führende Open-Source, Document Datenbank die für einfache Entwicklung und Skalierung aber auch für Big Data Szenarien entwickelt wurde.

Neue Features in 4.2 - Kompression, rotierende Schlüssel, und Konfiguration

Marc-David Militz
Expert
  • Artikel von Dj Walker-Morgan

    • englischer Originalartikel
      https://www.mongodb.com/blog/post/coming-in-42-compression-key-rotation-and-configuration
      Übersetzung mit freundlicher Genehmigung von MongoDB


      MongoDB 4.2 bringt nicht nur neue Features für Entwickler. Einige Änderungen wurden speziell gemacht, um die Administration von MongoDB zu erleichtern. Heute möchte ich mal einige dieser Änderungen wie die Möglichkeiten für Kompression, Möglichkeiten Wartungsaufwände zu verringern und neue Arten der Konfiguration.

      • Zstd Kompression

        • Mit MongoDB wird die Zstd Kompression, als dritte Alternative, verfügbar sein. Bisher waren ja schon snappy und zlib zu Verfügung gestanden. Snappy ist aktuell die Standardkompression für die WiredTiger Storage Engine um Block und Jounal Daten zu komprimieren und außerdem für die Kommunikation mit den MongoDB Clients.

          Die Schwierigkeit mit Kompression ist immer ein Tradeoff zwischen "Wie viel CPU Leistung wird für die Kompression benötigt" und "Wie viel der Arbeit des CPU resultier in weiter komprimierten Daten". Snappy ist dabei die Referenz für moderne Kompressionsmechanismen. Der ältere zlib Kompressor benötigt mehr CPU, kann aber auch die Daten effektiver komprimieren. Beide sind in MongoDB verfügbar, so dass die Nutzer selbst die Entscheidung treffen können.

          Zstandard, in der Regel kurz als "zstd" bezeichnet, ist eine modernerer Kompressor, der eine höhere Kompression ermöglicht und dabei, im Vergleich zu anderen Algorithmen, weniger CPU benötigt. In MongoDB 4.2 wird auch weiterhin Snappy als Standard verwendet. Wenn verwendete Treiber, wie z.B. der MongoDB 3.11 Java Treiber, zstd unterstützen dann kann dieser bereits genutzt werden.
          https://mongodb.github.io/mongo-java-driver/3.11/driver-async/tutorials/compression/

          • rotierende Schlüssel

            • Wer einen MongoDB Cluster oder Shard betreibt und eine Konfiguration gewählt hat, bei der die einzelnen Nodes verschlüsselt miteinander kommunizieren, der hat vielleicht schonmal bemerkt, dass das Ändern dieser Schlüssel wirklich lästig ist. MongoDB Nodes, wie z.B. mongod und mongos, kannten bisher immer nur einen Schlüssel. Eine Änderung der Schlüssel hat deshalb immer ein herunterfahren und neu starten notwendig gemacht.

              Ab MongoDB 4.2 ist das nicht länger notwendig.
              Die Datenbank Nodes sind nun in der Lage Konfigurationsdateien mit mehreren Schlüsseln zu verarbeiten und auch mehrere Schlüssel zu nutzen. Damit können die Nodes nun sowohl den alten als auch den neuen Schlüssel gleichzeitig verwenden. Man muss die Änderungen an den Konfigurationsdateien, nach wie vor, an jedem Node machen und jeden Node neu starten. Der Cluster an sich kann während dieses Prozesses allerding weiterlaufen.

              Die Details, wie genau das gemacht wird findet man in der Dokumentation für
              Replica Sets
              https://docs.mongodb.com/master/tutorial/rotate-key-replica-set/
              Sharded Cluster
              https://docs.mongodb.com/master/tutorial/rotate-key-sharded-cluster/

              • erweiterte Konfiguration

                • Schlüssel in Konfigurationsdateien zu packen ist immer ein schwieriger Balanceakt zwischen Sicherheit der Schlüssel und Aktualität der Konfiguration. Das wird in MongoDB 4.2 wesentlich vereinfacht, da die Möglichkeit zum Auslagern von Konfigurationen in externe Quellen möglich wird.
                  https://docs.mongodb.com/master/reference/expansion-directives/
                  sobald man das Feature aktiviert, ist es möglich Werte für einzelne Konfigurationsparameter von REST Endpunkten, oder ausführbaren Programmen, zu beziehen.

                  Am einfachsten zeigt sich das an einem Beispiel. Hier eine herkömmliche Konfigurationsdatei:
                  storage:
                  dbPath: "/var/lib/mongod/"
                  systemLog:
                  destination: file
                  path: "/var/log/mongod/mongod.log"
                  net:
                  bindIp: 192.168.123.50,127.0.0.1
                  tls:
                  mode: requireTLS
                  certificateKeyFile: "/etc/tls/mongod.pem"
                  certificateKeyFilePassword: "MySecretPassword"

                  Das Passwort für das Zertifikat steht dort im Klartext drin. Idealerweise möchte man das aber an einer zentralen und sicheren Stelle haben. Nutzen wir also den "__rest" Parameter, um das Passwort irgendwo anders abzulegen.
                  net:
                  bindIp: 192.168.123.50,127.0.0.1
                  tls:
                  mode: requireTLS
                  certificateKeyFile: "/etc/tls/mongod.pem"
                  certificateKeyFilePassword:
                  __rest: "https://configserver.example.net/api/passwords/currentKeyPassword"
                  type: "string"

                  Wenn wir den Server mit diesen Einstellungen einfach starten, dann werden wir einen Fehler bekommen. Diese neue Option funktioniert nur, wenn wir mongod oder mongos den Startparameter --configExpand "rest" mitgeben. Der Server wird dann mit dem __rest Parameter einen GET Request, der HTTPS sein muss, absetzen. Die Rückgabe wird als String behandelt, weil wir das im "type" Parameter so festgelegt haben. Natürlich setzt das voraus, dass man über eine REST API verfügt, die angemessen antwortet. Optional kann man für den "type" auch "yaml" verwenden, wenn ein ganzes Set an Parametern zurück geliefert wird. Dadurch wird es auch möglich, die komplette Konfiguration von REST Endpunkt zu beziehen.
                  __rest: "https://configserver.example.net/api/config/fullConfig"
                  type: "yaml"

                  Außerdem gibt es auch noch den "__exec" Parameter. Dieser benötigt statt einer URL den Aufruf eines lokal ausführbaren Programms, das die Werte oder den Wert zurück liefert.

                  Auf der Kommandozeile gibt es zudem eine neue Option "-outputConfig", mit der mongod oder mongos Dienste, die bereits mit dem "--configExpand" Parameter ausgeführt werden, die gesamte Konfiguration durchlaufen und dann ausgeben. Danach wird der jeweilige Server ganz normal gestartet. Damit wird es möglich, die ausgelagerte Konfiguration zu testen und festzustellen ob alles wie erwartet läuft.

                  Die Möglichkeit die Konfiguration, mit dem Ergebnis einer REST Abfrage zu erweitern, eröffnet eine ganze Reihe neuer Integrationsmöglichkeiten.

                  Wenn sie sich zu den Qualiero Angeboten zum Thema MongoDB informieren wollen, so haben sie hier dazu die Möglichkeit
                  https://www.qualiero.com/glossar/mongodb.html

Latest member activities

Tags

Recommend this community post