MongoDB 7.0, veröffentlicht im August 2023, setzte den Trend der letzten Versionen fort: spezialisierte Features für spezifische Workloads, Performance-Optimierungen unter der Haube und Sicherheitsverbesserungen für Enterprise-Anforderungen. Die sichtbarsten Neuerungen betrafen Atlas Search – MongoDB’s Volltextsuche, die nun direkt aus der Datenbank-Shell managebar wurde. Unter der Oberfläche arbeitete ein grundlegend überarbeiteter Query Executor, der Find- und Aggregations-Performance auf ein neues Level hob. Und mit Queryable Encryption erreichte eine lang erwartete Security-Funktion General Availability.
Atlas Search existierte bereits seit mehreren Jahren als Teil von MongoDB Atlas. Es ermöglicht Lucene-basierte Volltextsuche direkt auf MongoDB-Daten, ohne externe Search Engines wie Elasticsearch. Die Konfiguration und Verwaltung von Search-Indizes erfolgte aber bisher ausschließlich über die Atlas-UI oder API. Wer Search-Indizes in Scripts oder CI/CD-Pipelines managen wollte, musste mit REST-APIs hantieren.
Version 7.0 brachte Search Index Management in die MongoDB-Shell. Neue Methoden erlauben das Erstellen, Aktualisieren, Auflisten und Löschen von Search-Indizes direkt aus mongosh:
// Search-Index für Produktnamen und Beschreibungen erstellen
db.products.createSearchIndex({
name: "product_search",
definition: {
mappings: {
dynamic: false,
fields: {
name: {
type: "string",
analyzer: "lucene.standard"
},
description: {
type: "string",
analyzer: "lucene.english"
},
tags: {
type: "string",
multi: {
keywordAnalyzer: {
type: "string",
analyzer: "lucene.keyword"
}
}
}
}
}
}
})
// Alle Search-Indizes anzeigen
db.products.getSearchIndexes()
// Index aktualisieren
db.products.updateSearchIndex("product_search", {
mappings: {
dynamic: false,
fields: {
name: { type: "string", analyzer: "lucene.standard" },
description: { type: "string", analyzer: "lucene.english" },
tags: { type: "string" },
price: { type: "number" } // Neu hinzugefügt
}
}
})
// Index löschen
db.products.dropSearchIndex("product_search")Diese Integration ist mehr als syntaktischer Zucker. Sie ermöglicht Infrastructure-as-Code für Search-Indizes. Deployment-Scripts können Datenbank-Schema und Search-Konfiguration in einem Schritt ausrollen. Testing wird einfacher – Test-Suites können temporäre Search-Indizes erstellen, Tests durchführen und aufräumen, alles programmatisch.
Die neue Aggregation-Stage $listSearchIndexes macht
Search-Indizes auch in Pipelines verfügbar. Dies erlaubt Meta-Analysen:
“Welche Collections haben Search-Indizes? Wie sind sie konfiguriert?”
Solche Fragen lassen sich nun direkt queryen, hilfreich für
automatisiertes Monitoring oder Governance.
Unter der Haube vollzog MongoDB 7.0 eine fundamentale Änderung der Query Execution. Der neue Slot-Based Query Executor (SBE) ersetzt schrittweise die klassische Execution-Architektur. Dies ist eine mehrjährige Entwicklung – Teile des SBE existieren seit MongoDB 5.x, aber 7.0 erweiterte seine Zuständigkeit erheblich.
Der klassische Executor repräsentiert Query-Pläne als Baumstrukturen von Operatoren. Jeder Operator – IndexScan, Filter, Sort – konsumiert Dokumente vom darunter liegenden Operator und produziert Resultate nach oben. Dies ist konzeptionell klar, aber nicht optimal für moderne CPUs. Die Kommunikation zwischen Operatoren erfolgt durch Objekt-Kopien und virtuelle Funktionsaufrufe, was Branch-Mispredictions und Cache-Misses erzeugt.
Der SBE verfolgt einen anderen Ansatz, inspiriert von modernen Analytics-Engines. Query-Pläne werden zu Bytecode kompiliert, der in einer Register-Maschine ausgeführt wird. “Slots” sind typisierte Register, die Werte zwischen Operationen transportieren. Der Compiler kann aggressive Optimierungen anwenden – Inline-Expansion, Loop-Unrolling, SIMD-Vektorisierung wo möglich.
Das Resultat sind messbare Performance-Verbesserungen. Benchmarks zeigen 2-5x schnellere Aggregations-Queries für analytische Workloads. Besonders Filter-heavy Pipelines mit komplexen Expressions profitieren. Ein Beispiel: Eine Pipeline, die Millionen Dokumente filtert, gruppiert und Statistiken berechnet, könnte von 10 Sekunden auf 3 Sekunden fallen – derselbe Code, derselbe Hardware, nur der Executor ist anders.
Für Entwickler ist die Umstellung transparent. Der SBE generiert identische Resultate wie der alte Executor, nur schneller. Query-Syntax ändert sich nicht, Explain-Pläne sehen ähnlich aus (mit neuen “sbe”-Markierungen). Die Umstellung passiert automatisch – MongoDB wählt intern, welchen Executor es verwendet, basierend auf Query-Charakteristiken.
Nicht alle Queries nutzen den SBE. Manche komplexe Operationen fallen noch auf den klassischen Executor zurück. MongoDB erweitert die SBE-Coverage kontinuierlich – 7.0 brachte Unterstützung für mehr Aggregations-Stages, zukünftige Versionen werden weitere folgen lassen.
Die WiredTiger Storage Engine limitiert die Anzahl gleichzeitiger Transaktionen, um Ressourcen zu schonen. Historisch war dieses Limit statisch, konfiguriert beim Start. Für Workloads mit stark schwankender Last war dies suboptimal. Nachts, bei geringer Last, waren Ressourcen ungenutzt. Tagsüber, bei Spitzenlast, konnte das Limit zum Bottleneck werden.
Version 7.0 machte dieses Limit dynamisch anpassbar zur Laufzeit. MongoDB kann nun basierend auf aktueller Last das Transaction-Limit erhöhen oder senken, ohne Neustart. Dies ist besonders wertvoll für Cloud-Deployments mit autoscaling oder für Systeme mit vorhersehbaren Lastmustern.
Die Konfiguration erfolgt über den Server-Parameter
storageEngineConcurrentTransactions:
db.adminCommand({
setParameter: 1,
storageEngineConcurrentTransactions: {
write: 256 // Erhöht Write-Transaction-Limit
}
})Die Default-Werte sind konservativ und für die meisten Workloads
ausreichend. Erhöhungen sollten basierend auf Monitoring erfolgen. Wenn
db.serverStatus() zeigt, dass Transaktionen regelmäßig auf
Tickets warten, könnte eine Erhöhung sinnvoll sein. Umgekehrt, bei
geringer Last, spart Verringerung Speicher.
Diese Dynamik ist Teil eines größeren Trends: MongoDB wird adaptiver, reagiert auf Laufzeitbedingungen statt statischer Konfiguration. Frühere Versionen erforderten oft Restarts für Performance-Tuning. Moderne Versionen erlauben mehr Tuning zur Laufzeit.
Wildcard-Indizes, eingeführt in MongoDB 4.2, indexieren alle Felder eines Dokuments oder Subdokuments automatisch. Dies ist ideal für heterogene Collections, wo Dokumente unterschiedliche Felder haben und man nicht im Voraus weiß, welche Felder abgefragt werden.
Version 7.0 erweiterte dies zu Compound Wildcard Indexes – Kombinationen aus spezifischen Feldern und Wildcard-Komponenten. Dies erlaubt präzisere Indizes für häufige Query-Muster:
// Compound Index: spezifisches Feld + Wildcard
db.products.createIndex({
category: 1,
"specs.$**": 1
})Dieser Index kombiniert das feste Feld category mit
einem Wildcard über specs. Queries, die nach Kategorie
filtern und dann auf beliebige Spec-Felder zugreifen, können den Index
effizient nutzen:
// Nutzt den Compound Wildcard Index
db.products.find({
category: "electronics",
"specs.screenSize": { $gt: 15 }
})
// Nutzt ihn ebenfalls
db.products.find({
category: "electronics",
"specs.batteryLife": { $gte: 8 }
})Ohne Compound Wildcard müsste man entweder einen reinen Wildcard-Index haben (ineffizient für Kategorie-Filter) oder separate Indizes für jede Spec-Kombination (unpraktikabel bei Hunderten möglicher Specs). Der Compound Wildcard gibt das Beste aus beiden Welten.
Die Limitation: Der Wildcard-Teil muss am Ende stehen. Ein Index
{"$**": 1, category: 1} ist ungültig. Dies folgt aus der
B-Tree-Struktur – das Wildcard muss die äußere Schicht der Hierarchie
bilden.
Change Streams haben ein fundamentales Limit: Events dürfen nicht größer als 16 MB sein (MongoDBs BSON-Dokumentlimit). Für die meisten Änderungen ist dies kein Problem. Aber manche Operationen erzeugen riesige Events – etwa ein Update, das ein großes Array modifiziert, oder ein Replace, das ein Multi-Megabyte-Dokument betrifft.
Vor Version 7.0 führte dies zu Fehlern. Change Streams warfen Exceptions bei oversized Events, was Consumers crashen ließ oder erforderte komplexe Error-Handling-Logik. Version 7.0 löste dies mit Event-Fragmentierung.
Die neue Stage $changeStreamSplitLargeEvent teilt große
Events automatisch in kleinere Fragmente, jedes unter dem
16-MB-Limit:
db.large_documents.watch([
{ $changeStreamSplitLargeEvent: {} }
])Ein 50-MB-Update-Event wird zu vier Fragmenten: drei mit jeweils 16 MB und ein letztes mit 2 MB. Jedes Fragment trägt Metadaten über Position und Gesamtzahl:
{
_id: { ... },
operationType: "update",
splitEvent: {
fragment: 1,
of: 4
},
fullDocument: { /* Teil 1 */ }
}Consumer müssen Fragmente reassemblieren, aber das ist vorhersehbare Logik. Die Alternative – Events zu verlieren oder Crashes – ist deutlich schlechter. Für Systeme, die mit großen Dokumenten arbeiten, ist dies ein kritisches Robustness-Feature.
Queryable Encryption (QE), lange in Preview, erreichte in 7.0 General Availability. QE ermöglicht Queries auf verschlüsselten Daten, ohne sie zu entschlüsseln. Dies ist fundamental anders als Encryption-at-Rest (verschlüsselte Disk) oder TLS (verschlüsseltes Netzwerk). Beide schützen Daten in Transit oder Storage, aber innerhalb der Datenbank sind Daten im Klartext.
QE verschlüsselt Felder clientseitig, bevor sie zur Datenbank geschickt werden. Der Server sieht nur Ciphertext. Trotzdem können bestimmte Queries ausgeführt werden – Equality-Matches und Range-Queries auf numerischen Feldern. Dies geschieht durch kryptographische Schemata, die bestimmte Operationen auf Ciphertext erlauben, ohne den Plaintext zu offenbaren.
Ein praktisches Szenario: Eine Healthcare-App speichert Patientendaten. Sozialversicherungsnummern müssen verschlüsselt sein, aber Queries wie “Finde Patient mit SSN X” müssen funktionieren. Traditionelle Verschlüsselung würde alle SSNs entschlüsseln müssen, um zu vergleichen – ein Security-Risiko. QE erlaubt den Vergleich auf Ciphertext-Ebene:
// Client-seitige Field-Level-Encryption-Konfiguration
const encryptedFieldsMap = {
"medical.patients": {
fields: [
{
path: "ssn",
bsonType: "string",
queries: { queryType: "equality" }
},
{
path: "birthdate",
bsonType: "date",
queries: { queryType: "range" }
}
]
}
}
// Query funktioniert auf verschlüsselten Daten
db.patients.find({ ssn: "123-45-6789" })Die Datenbank sieht nie die SSN im Klartext. Der MongoDB-Treiber verschlüsselt sie automatisch, die Datenbank vergleicht Ciphertexts, der Treiber entschlüsselt Resultate. Selbst ein Datenbankadministrator mit vollem Zugriff kann Plaintext nicht sehen.
Die Limitierungen sind spürbar. Nicht alle Queries funktionieren – Pattern Matching, Aggregationen oder Full-Text-Search auf verschlüsselten Feldern sind unmöglich oder stark eingeschränkt. Die Performance ist schlechter als auf Plaintext, weil kryptographische Operationen teuer sind. Und die Key-Management-Komplexität steigt – Encryption-Keys müssen sicher gespeichert und verwaltet werden, typischerweise in dedizierten KMS (Key Management Services).
Trotz dieser Trade-offs ist QE für compliance-intensive Branchen wertvoll. Regulierungen wie GDPR, HIPAA oder PCI-DSS fordern oft, dass sensible Daten “end-to-end” verschlüsselt sind. QE erfüllt dies, während traditionelle Datenbank-Verschlüsselung es nicht tut.
Die Analytics-Fähigkeiten wurden um statistische Operatoren
erweitert. $median und $percentile berechnen
Median und Perzentile – gängige Metriken in Datenanalyse. Vor 7.0
erforderten diese Berechnungen umständliche Workarounds oder
clientseitige Post-Processing.
// Median der Antwortzeiten
db.requests.aggregate([
{ $group: {
_id: "$endpoint",
medianLatency: { $median: { input: "$latency", method: "approximate" } }
}}
])
// 95. und 99. Perzentil
db.requests.aggregate([
{ $group: {
_id: "$endpoint",
p95: { $percentile: { input: "$latency", p: [0.95], method: "approximate" } },
p99: { $percentile: { input: "$latency", p: [0.99], method: "approximate" } }
}}
])Der method: "approximate"-Parameter ist wichtig. Exakte
Median- und Perzentil-Berechnung erfordert Sortierung aller Werte – bei
Millionen Datenpunkten teuer. Die approximativen Algorithmen verwenden
statistische Sketches (t-digest), die mit begrenztem Speicher und einer
Durchlauf-Operation auskommen. Die Approximation ist typischerweise auf
1-2% genau – mehr als ausreichend für die meisten Analysen.
Diese Operatoren sind besonders wertvoll für Performance-Monitoring. “P99 Latenz” – die Zeit, unter der 99% der Requests abgeschlossen sind – ist eine Standard-Metrik in SRE. MongoDB kann diese nun direkt berechnen, statt Rohdaten zu exportieren und extern zu analysieren.
Für Administratoren großer Sharded Clusters brachte 7.0 detailliertere Metriken über Chunk-Migrationen. Der Balancer, der Chunks zwischen Shards verschiebt, war bisher eine Black Box. Man sah, dass Migrationen passierten, aber Details – welche Chunks, warum, wie lange – waren unklar.
Die neuen Metriken in db.serverStatus().sharding
offenbaren diese Informationen. Administratoren können nun sehen, wie
viele Migrationen aktiv sind, welche erfolgreich waren, welche
fehlschlugen und warum. Dies ist essentiell für Troubleshooting bei
Balancing-Problemen oder Performance-Degradationen.
Die Erweiterungen zu db.currentOp() und der
$currentOp-Stage liefern ähnlich mehr Details über laufende
Operationen. Neue Felder zeigen Speicher-Nutzung pro Operation, Locks
gehalten, Zeit in verschiedenen Phasen. Für Debugging langsamer Queries
oder analysieren von Contention ist dies wertvoll.
Die folgende Tabelle fasst die Hauptneuerungen zusammen:
| Feature | Kategorie | Hauptvorteil | Typischer Use Case |
|---|---|---|---|
| Atlas Search Shell-Integration | Developer Experience | Scripting & Automation | CI/CD, Infrastructure-as-Code |
| Slot-Based Executor | Performance | 2-5x schnellere Analytics | Komplexe Aggregationen |
| Concurrent Transactions Tuning | Operations | Dynamisches Performance-Tuning | Variable Workloads |
| Compound Wildcard Indexes | Indexing | Präzisere flexible Indizes | Heterogene Schemas |
| Large Change Stream Events | Robustness | Keine Event-Verluste mehr | Große Dokumente |
| Queryable Encryption GA | Security | End-to-End-Verschlüsselung | Compliance-intensive Branchen |
| $median / $percentile | Analytics | Native statistische Metriken | Performance-Monitoring |
| Erweiterte Sharding-Metriken | Operations | Bessere Cluster-Transparenz | Troubleshooting |
MongoDB 7.0 war eine Konsolidierung – keine revolutionären neuen Paradigmen, sondern Verfeinerung und Robustheit. Der Slot-Based Executor ist technisch beeindruckend, aber unsichtbar für Entwickler. Queryable Encryption ist ein Meilenstein für Security, aber nur für spezifische Branchen relevant. Atlas Search Shell-Integration und statistische Operatoren sind praktische Additions, die tägliche Arbeit erleichtern. Für bestehende Nutzer brachte 7.0 vor allem Performance und operative Verbesserungen. Für neue Anwendungen im Healthcare oder Finanzbereich machte Queryable Encryption MongoDB zu einer attraktiveren Option, wo Encryption-Anforderungen bisher andere Datenbanken favorisierten.