MongoDB
 sql >> Datenbank >  >> NoSQL >> MongoDB

Was ist neu in MongoDB 4.2

Datenbankaktualisierungen enthalten verbesserte Funktionen für Leistung, Sicherheit und neue integrierte Funktionen. Es ist immer ratsam, eine neue Version zu testen, bevor Sie sie in der Produktion einsetzen, nur um sicherzustellen, dass sie Ihren Anforderungen entspricht und keine Abstürze möglich sind.

Unter Berücksichtigung vieler Produkte haben diejenigen, die den ersten Nebenversionen einer neuen Hauptversion vorangehen, die wichtigsten Korrekturen. Zum Beispiel würde ich es vorziehen, MongoDB Version 4.2.1 ein paar Tage nach der Veröffentlichung in Produktion zu haben, als dies bei Version 4.2.0 der Fall wäre.

In diesem Blog werden wir besprechen, was in MongoDB Version 4.2 enthalten ist und welche Verbesserungen vorgenommen wurden

Neuerungen in MongoDB 4.2

  1. Verteilte Transaktionen
  2. Wildcard-Indizes
  3. Wiederholbare Lese- und Schreibvorgänge
  4. Automatische clientseitige Verschlüsselung auf Feldebene.
  5. Verbesserte Abfragesprache für aussagekräftige Aktualisierungen
  6. Auf Abruf materialisierte Ansichten
  7. Moderner Wartungsbetrieb

Verteilte Transaktionen

Transaktionen sind wichtige Datenbankfunktionen, die Datenkonsistenz und -integrität sicherstellen, insbesondere diejenigen, die die ACID-Verfahren gewährleisten. MongoDB Version 4.2 unterstützt jetzt Multi-Dokument-Transaktionen auf Replikatsätzen und einem Sharding-Cluster durch den verteilten Transaktionsansatz. Dieselbe Syntax für die Verwendung von Transaktionen wurde beibehalten wie in der vorherigen Version 4.0.

Die Client-Treiberspezifikationen haben sich jedoch ein wenig geändert. Wenn Sie also Transaktionen in MongoDB 4.2 verwenden möchten, müssen Sie die Treiber auf Versionen aktualisieren, die mit 4.2-Servern kompatibel sind.

Diese Version begrenzt die Größe einer Transaktion nicht in Bezug auf die Speichernutzung, sondern hängt nur von der Größe Ihrer Hardware und der Hardware-Handhabungsfähigkeit ab.

Die globale Cluster-Locale-Neuzuweisung ist jetzt mit Version 4.2 möglich. Das heißt für eine Geozonen-Sharding-Implementierung:Wenn ein Benutzer mit Wohnsitz in Region A in Region B wechselt, können die Daten durch Ändern des Werts seines Standortfelds automatisch von Region A nach B durch eine Transaktion verschoben werden.

Das Sharding-System erlaubt es nun, im Gegensatz zur vorherigen Version, einen Shard-Schlüssel zu ändern. Wenn ein Shard-Schlüssel geändert wird, entspricht dies buchstäblich dem Verschieben des Dokuments auf einen anderen Shard. In dieser Version umschließt MongoDB dieses Update und wenn das Dokument von einem Shard zu einem anderen verschoben werden muss, wird das Update innerhalb einer Transaktion im Hintergrund ausgeführt.

Die Verwendung von Transaktionen ist kein empfehlenswerter Ansatz, da sie die Datenbankleistung beeinträchtigen, insbesondere wenn sie mehrmals auftreten. Während eines Transaktionszeitraums gibt es ein ausgedehntes Fenster für Vorgänge, die beim Schreiben in ein betroffenes Dokument zu Konflikten führen können. So sehr eine Transaktion wiederholt werden kann, kann es sein, dass vor diesem erneuten Versuch eine Aktualisierung am Dokument vorgenommen wird, und wann immer der erneute Versuch stattfindet, kann es sich um die alte und nicht um die neueste Dokumentversion handeln. Wiederholungsversuche verursachen offensichtlich mehr Verarbeitungskosten, abgesehen davon, dass die Ausfallzeit der Anwendung durch zunehmende Latenz erhöht wird.

Eine gute Vorgehensweise bei der Verwendung von Transaktionen ist:

  1. Vermeiden Sie die Verwendung nicht indizierter Abfragen innerhalb einer Transaktion, um sicherzustellen, dass die Operation nicht langsam wird.
  2. Ihre Transaktion sollte einige Dokumente umfassen.

Mit dem dynamischen Schemaformat und der Einbettungsfunktion von MongoDB können Sie sich dafür entscheiden, alle Felder in dieselbe Sammlung zu stellen, um zu vermeiden, dass Transaktionen als erste Maßnahme verwendet werden müssen.

Wildcard-Indizes

Wildcard-Indizes wurden in MongoDB Version 4.2 eingeführt, um Abfragen für beliebige Felder oder Felder, deren Namen nicht im Voraus bekannt sind, zu verbessern, indem das gesamte Dokument oder Teildokument indiziert wird. Sie sind nicht dazu gedacht, die Workload-basierten Indizes zu ersetzen aber geeignet für die Arbeit mit Daten mit polymorphen Mustern. Bei einem polymorphen Muster sind alle Dokumente in einer Sammlung ähnlich, haben aber keine identische Struktur. Polymorphe Datenmuster können aus Anwendungsbeteiligten, Produktkatalogen oder sozialen Daten generiert werden. Nachfolgend finden Sie ein Beispiel für polymorphe Sammlungsdaten

{

Sport: ‘Chess’,

playerName: ‘John Mah’,

Career_earning: {amount: NumberDecimal(“3000”), currency: “EUR”},

gamesPlayed:25,

career_titles:10

},

{

Sport: Tennis,

playerName: ‘Semenya Jones,

Career_earning: {amount: NumberDecimal(“34545”), currency: “USD”},

Event: {

name:”Olympics”,

career_titles:10,

career_tournaments:14

}

Indem Sie das gesamte Dokument mit Wildcard-Indizes indizieren, können Sie eine Abfrage mit einem beliebigen Feld als Index durchführen.

Um einen Wildcard-Index zu erstellen

$db.collection.createIndex({“fieldA.$**”: 1})

Wenn das ausgewählte Feld ein verschachteltes Dokument oder ein Array ist, kehrt der Wildcard-Index in das Dokument zurück und speichert den Wert für alle Felder im Dokument oder Array.

Wiederholbare Lese- und Schreibvorgänge

Normalerweise kann es bei einer Datenbank zu häufigen vorübergehenden Netzwerkausfällen kommen, die dazu führen können, dass eine Abfrage teilweise oder vollständig nicht ausgeführt wird. Diese Netzwerkfehler sind möglicherweise nicht so schwerwiegend und bieten daher die Möglichkeit, diese Abfragen erneut zu versuchen, sobald die Verbindung wiederhergestellt ist. Ab MongoDB 4.2 ist die Wiederholungskonfiguration standardmäßig aktiviert. Die MongoDB-Treiber können fehlgeschlagene Lese- und Schreibvorgänge für bestimmte Transaktionen wiederholen, wenn sie auf geringfügige Netzwerkfehler stoßen oder wenn sie keinen fehlerfreien Primärknoten im Sharded-Cluster/Replikatsatz finden können. Wenn Sie die wiederholbaren Schreibvorgänge jedoch nicht möchten, können Sie sie in Ihren Konfigurationen explizit deaktivieren, aber ich finde keinen zwingenden Grund, warum man sie deaktivieren sollte.

Diese Funktion soll sicherstellen, dass bei Änderungen der MongoDB-Infrastruktur der Anwendungscode nicht beeinträchtigt wird. In Bezug auf ein von Eliot Horowitz, dem Mitbegründer von MongoDB, erläutertes Beispiel für eine Webseite, die 20 verschiedene Datenbankoperationen durchführt, anstatt das Ganze neu zu laden oder die gesamte Webseite in eine Art Schleife zu wickeln, den Treiber unter der Decke kann einfach entscheiden, den Vorgang zu wiederholen. Immer wenn ein Schreibvorgang fehlschlägt, wird es automatisch erneut versucht und es wird ein Vertrag mit dem Server abgeschlossen, der garantiert, dass jeder Schreibvorgang nur einmal erfolgt.

Die wiederholbaren Schreibvorgänge führen nur einen einzigen Wiederholungsversuch durch, was dazu beiträgt, Replikatsatzwahlen und vorübergehende Netzwerkfehler zu beheben, jedoch nicht für dauerhafte Netzwerkfehler.

Wiederholbare Schreibvorgänge adressieren keine Instanzen, bei denen der Failover-Zeitraum den Wert von serverSelectionTimoutMs in den Parameterkonfigurationen überschreitet.

Mit dieser MongoDB-Version kann man Shard-Schlüsselwerte von Dokumenten aktualisieren (außer wenn der Shardkey das unveränderliche _id-Feld ist), indem man findAndModify/update-Operationen für einzelne Dokumente entweder in einer Transaktion oder als wiederholbaren Schreibvorgang ausführt .

MongoDB Version 4.2 kann jetzt eine Upsert-Operation für ein einzelnes Dokument wiederholen (d. h. upsert:true und multi:false), die möglicherweise aufgrund eines doppelten Schlüsselfehlers fehlgeschlagen ist, wenn die Operation die folgenden Schlüsselbedingungen erfüllt:

  1. Zielsammlung enthält einen eindeutigen Index, der den doppelten Schlüsselfehler verursacht hat.
  2. Der Aktualisierungsvorgang ändert keines der Felder im Abfrageprädikat.
  3. Die Update-Match-Bedingung ist entweder ein einzelnes Gleichheitsprädikat {field:„value“} oder ein logisches UND von Gleichheitsprädikaten {filed:„value“, field0:„value0“}
  4. Der Satz von Feldern im eindeutigen Indexschlüsselmuster stimmt mit dem Satz von Feldern im Aktualisierungsabfrageprädikat überein.

Automatische clientseitige Verschlüsselung auf Feldebene

MongoDB Version 4.2 enthält die automatische clientseitige Feldebenenverschlüsselung (CSFLE), eine Funktion, die es Entwicklern ermöglicht, einzelne Felder eines Dokuments auf der Clientseite selektiv zu verschlüsseln, bevor es an den Server gesendet wird. Die verschlüsselten Daten werden somit vor den Anbietern, die die Datenbank hosten, und allen Benutzern, die möglicherweise direkten Zugriff auf die Datenbank haben, privat gehalten.

Nur Anwendungen mit Zugriff auf die richtigen Verschlüsselungsschlüssel können die geschützten Daten entschlüsseln und lesen. Falls der Verschlüsselungsschlüssel gelöscht wird, werden alle verschlüsselten Daten unlesbar gemacht.

Hinweis:Diese Funktion ist nur mit MongoDB Enterprise verfügbar.

Verbesserte Abfragesprache für aussagekräftige Aktualisierungen

MongoDB Version 4.2 bietet eine reichhaltigere Abfragesprache als ihre Vorgänger. Es unterstützt jetzt Aggregationen und moderne Use-Case-Operationen entlang der Linien von geobasierter Suche, Graphsuche und Textsuche. Es hat eine Suchmaschine eines Drittanbieters integriert, die die Suche beschleunigt, wenn man bedenkt, dass die Suchmaschine auf einem anderen Prozess/Server läuft. Dies verbessert im Allgemeinen die Datenbankleistung im Gegensatz dazu, wenn alle Suchen im Mongod-Prozess durchgeführt würden, wodurch die Latenz der Datenbankoperation eher flüchtig werden würde, wenn die Suchmaschine neu indiziert.

Mit dieser Version können Sie jetzt Arrays handhaben, Summen und andere mathematische Operationen direkt über eine Update-Anweisung ausführen.

Materialisierte On-Demand-Ansichten

Das Datenaggregations-Pipeline-Framework in MongoDB ist ein großartiges Feature mit verschiedenen Stadien der Umwandlung eines Dokuments in einen gewünschten Zustand. Die MongoDB-Version 4.2 führt eine neue Stufe $merge ein, die mir meiner Meinung nach einige Zeit gespart hat, wenn ich mit der endgültigen Ausgabe gearbeitet habe, die in einer Sammlung gespeichert werden musste. Anfänglich ermöglicht die $out-Phase das Erstellen einer neuen Sammlung basierend auf der Aggregation und füllt die Sammlung mit den erhaltenen Ergebnissen. Wenn die Sammlung bereits vorhanden ist, würde sie die Sammlung mit den neuen Ergebnissen überschreiben, im Gegensatz zur $merge-Phase, die nur die Pipeline-Ergebnisse in eine vorhandene Ausgabe einfügt, anstatt die Sammlung vollständig zu ersetzen. Das erneute Generieren einer gesamten Sammlung mit der Phase $out verbraucht viel CPU und IO, was die Datenbankleistung beeinträchtigen kann. Der Ausgabeinhalt wird daher rechtzeitig aktualisiert, sodass Benutzer bei Bedarf materialisierte Ansichten erstellen können

Moderner Wartungsbetrieb

Entwickler können jetzt eine großartige Betriebserfahrung mit MongoDB Version 4.2 mit integrierten Funktionen machen, die die Hochverfügbarkeit, die Cloud-verwaltete Backup-Strategie verbessern, die Überwachungsleistung und die Warnsysteme verbessern. MongoDB Atlas und MongoDB Ops Manager sind die Bereitstellungsplattformen für diese Funktionen. Letzteres wurde als das beste für den Betrieb von MongoDB im Unternehmen bezeichnet. Es wurde auch in den Kubernetes-Betreiber für On-Premise-Benutzer integriert, die in die Private Cloud wechseln. Diese Schnittstelle ermöglicht die direkte Steuerung von Ops Manager.

Es wurden einige interne Änderungen an MongoDB Version 4.2 vorgenommen, darunter:

  1. Offene Cursor auflisten.
  2. Entfernung der MMAPv1-Speicher-Engine.
  3. Verbesserung der WiredTiger-Datendateireparatur.
  4. Diagnosefelder können jetzt queryHash haben
  5. Thread mit automatischer Aufteilung für Mongos-Knoten wurde entfernt.

Fazit

MongoDB Version 4.2 enthält einige Verbesserungen in Bezug auf Sicherheit und Datenbankleistung. Es enthält eine automatische clientseitige Verschlüsselung auf Feldebene, die sicherstellt, dass Daten aus der Client-Perspektive geschützt sind. Weitere Funktionen wie eine Suchmaschine eines Drittanbieters und die Einbeziehung der $merge-Phase in das Aggregationsframework führen zu einer gewissen Verbesserung der Datenbankleistung. Bevor Sie diese Version in Produktion nehmen, vergewissern Sie sich bitte, dass alle Ihre Anforderungen vollständig erfüllt sind.