6 Begriffe und Wording

MongoDB verwendet eine eigene Terminologie, die sich teilweise von relationalen Datenbanken unterscheidet. Diese Begriffe zu kennen ist grundlegend für die Arbeit mit der Datenbank. Viele Konzepte haben Entsprechungen in SQL-Welten, andere sind spezifisch für dokumentenorientierte oder verteilte Systeme. Ein Verständnis dieser Terminologie schafft die Basis für alles Weitere.

6.1 Datenorganisation: Von Datenbanken zu Dokumenten

Die Hierarchie der Datenorganisation in MongoDB folgt einem klaren Muster: Eine MongoDB-Instanz kann mehrere Datenbanken hosten. Jede Datenbank ist ein logischer Container, ähnlich wie in relationalen Systemen. In der Praxis wird oft pro Anwendung oder Microservice eine eigene Datenbank angelegt. Eine E-Commerce-Plattform könnte beispielsweise separate Datenbanken für Produktkatalog, Benutzer und Bestellungen verwenden.

Innerhalb einer Datenbank organisieren Collections die Daten. Eine Collection entspricht konzeptionell einer Tabelle in SQL, unterscheidet sich aber fundamental: Sie erzwingt kein Schema. Dokumente in derselben Collection können unterschiedliche Felder haben. Die Collection “products” könnte Elektronikartikel mit technischen Spezifikationen enthalten, während Kleidungsstücke Größen- und Farbinformationen haben – alles in derselben Collection, ohne dass dies ein Problem darstellt.

Das Dokument ist die atomare Einheit der Datenspeicherung. Es entspricht einer Zeile in SQL, ist aber weitaus flexibler. Ein Dokument ist ein JSON-ähnliches Objekt mit Schlüssel-Wert-Paaren. Anders als eine Tabellenzeile, die flach ist, kann ein Dokument beliebig verschachtelte Strukturen enthalten. Ein Benutzerdokument könnte direkt ein Array von Adressen oder ein eingebettetes Objekt für Präferenzen enthalten.

Die folgende Tabelle verdeutlicht die Entsprechungen zwischen SQL und MongoDB:

6.2 Datenstruktur: BSON und Felder

MongoDB speichert Dokumente nicht als reines JSON, sondern als BSON – Binary JSON. Diese binäre Repräsentation bringt mehrere Vorteile: Sie ist kompakter, schneller zu parsen und unterstützt zusätzliche Datentypen. Während JSON nur Strings, Numbers, Booleans, Arrays, Objekte und null kennt, erweitert BSON dies um Datentypen wie Date, Binary Data, ObjectId und mehr.

Die ObjectId ist dabei besonders wichtig. Jedes Dokument in MongoDB besitzt ein _id-Feld als Primärschlüssel. Wird kein expliziter Wert angegeben, generiert MongoDB automatisch eine ObjectId – eine 12-Byte-Sequenz, die global eindeutig ist und Zeitstempel, Maschinen-ID und Prozess-ID kombiniert. Diese Eindeutigkeit ohne zentrale Koordination ermöglicht verteilte Systeme ohne Engpässe.

Ein Feld ist schlicht ein Schlüssel-Wert-Paar innerhalb eines Dokuments. Der Schlüssel ist ein String, der Wert kann jeden BSON-Typ haben – von einfachen Zahlen über Arrays bis zu verschachtelten Objekten. Ein Produktdokument könnte Felder wie name, price, inStock und tags haben, wobei tags ein Array ist und price eine Zahl.

Embedded Documents sind Dokumente, die als Wert eines Feldes in einem anderen Dokument gespeichert sind. Dies ist MongoDBs primärer Mechanismus, um Beziehungen darzustellen. Statt wie in SQL mehrere Tabellen über Fremdschlüssel zu verknüpfen, bettet MongoDB zusammengehörige Daten direkt ein. Ein Benutzerdokument könnte etwa ein eingebettetes address-Objekt enthalten mit Feldern wie street, city und zipCode. Dieser Ansatz minimiert Joins und ermöglicht atomare Operationen auf zusammengehörige Daten.

6.3 Datenmanipulation: Queries, Projections und Indizes

Eine Query ist eine Abfrage zur Suche oder Filterung von Dokumenten. MongoDB verwendet dafür eine JSON-basierte Syntax. Die einfachste Query ist ein leeres Objekt {}, das alle Dokumente einer Collection zurückgibt. Komplexere Queries verwenden Operatoren: { age: { $gt: 18 } } findet alle Dokumente, deren age-Feld größer als 18 ist. Die Query-Sprache ist ausdrucksstark und unterstützt logische Verknüpfungen, reguläre Ausdrücke und Geo-Queries.

Projection ist die Technik, nur bestimmte Felder aus Query-Ergebnissen zurückzugeben. Statt ganze Dokumente zu übertragen, wenn nur wenige Felder benötigt werden, reduziert Projection die Netzwerklast. Die Syntax ist simpel: { name: 1, price: 1, _id: 0 } gibt nur name und price zurück, unterdrückt aber die _id. Projection ist besonders wichtig bei großen Dokumenten oder hohem Abfragevolumen.

Ein Index beschleunigt Suchoperationen dramatisch. Ohne Index muss MongoDB jedes Dokument einer Collection prüfen (Collection Scan). Mit Index auf einem Feld kann die Datenbank direkt zu den relevanten Dokumenten springen. MongoDB unterstützt verschiedene Index-Typen: Einzelfeld-Indizes, zusammengesetzte Indizes auf mehrere Felder, Text-Indizes für Volltextsuche und Geo-Indizes für räumliche Queries. Indizes sind essentiell für Performance, aber nicht kostenlos – sie verbrauchen Speicher und verlangsamen Schreiboperationen.

6.4 Datenreplikation und Verteilung: Replica Sets und Sharding

Replica Sets sind MongoDBs Mechanismus für Hochverfügbarkeit. Ein Replica Set besteht aus mehreren MongoDB-Instanzen, die dieselben Daten halten. Es gibt einen Primary-Knoten, der alle Schreiboperationen entgegennimmt, und mehrere Secondary-Knoten, die diese Änderungen replizieren. Clients verbinden sich mit dem Replica Set als Ganzes, nicht mit einzelnen Knoten. Fällt der Primary aus, wählen die Secondaries automatisch einen neuen Primary – ein Prozess, der als Election bezeichnet wird.

Die Replikation erfolgt über das Oplog (Operations Log), ein spezielles Capped Collection, das alle Schreiboperationen chronologisch aufzeichnet. Secondary-Knoten lesen kontinuierlich aus diesem Log und wenden die Operationen auf ihre Kopie der Daten an. Dieser asynchrone Mechanismus ist effizient, bedeutet aber auch, dass Secondaries minimal hinter dem Primary zurückliegen können.

Lesepräferenzen bestimmen, von welchen Knoten Leseoperationen ausgeführt werden. Der Standard ist Primary – alle Reads vom Primary, um aktuellste Daten zu garantieren. Alternativen wie “secondary” oder “nearest” verteilen Leselast, akzeptieren aber, dass Daten minimal veraltet sein könnten. Diese Trade-offs zwischen Konsistenz und Performance sind charakteristisch für verteilte Systeme.

Sharding verteilt Daten horizontal auf mehrere Server. Während ein Replica Set dieselben Daten auf mehrere Knoten repliziert, teilt Sharding die Daten auf verschiedene Shards auf. Jeder Shard ist selbst ein Replica Set, was Sharding und Replikation kombiniert. Die Verteilung basiert auf einem Shard Key – einem Feld oder einer Feldkombination, die bestimmt, auf welchem Shard ein Dokument landet.

Die Wahl des Shard Keys ist kritisch für Performance. Ein guter Shard Key verteilt Daten gleichmäßig, vermeidet Hotspots und ermöglicht effiziente Queries. Ein schlechter Shard Key konzentriert alle Schreiboperationen auf einen Shard oder erzwingt Broadcast-Queries über alle Shards. Die Architektur eines Sharded Clusters umfasst neben den Shards auch Config-Server zur Metadatenverwaltung und mongos-Router, die Queries an die richtigen Shards weiterleiten.

6.5 Sicherheit und Verwaltung: Authentifizierung und Rollen

Authentifizierung verifiziert die Identität eines Benutzers oder Systems, das auf MongoDB zugreifen möchte. MongoDB unterstützt verschiedene Authentifizierungsmechanismen: SCRAM (Salted Challenge Response Authentication Mechanism) als Standard, x.509-Zertifikate für Maschinen-zu-Maschinen-Kommunikation und LDAP für Integration in bestehende Directory Services. Authentifizierung beantwortet die Frage: “Wer bist du?”

Autorisierung bestimmt, was ein authentifizierter Benutzer tun darf. MongoDB verwendet ein rollenbasiertes Zugriffskontrollsystem. Ein Benutzer hat keine direkten Rechte, sondern wird Rollen zugewiesen. Eine Rolle ist ein Satz von Berechtigungen – etwa “Lesen aus Collection X” oder “Schreiben in Datenbank Y”. Autorisierung beantwortet die Frage: “Was darfst du tun?”

MongoDB bringt eingebaute Rollen mit: read für Lesezugriff, readWrite für Lese- und Schreibzugriff, dbAdmin für administrative Aufgaben auf Datenbankebene und clusterAdmin für Cluster-weite Administration. Für spezialisierte Anforderungen können auch benutzerdefinierte Rollen erstellt werden, die exakt die benötigten Rechte kombinieren.

Diese Sicherheitsmechanismen sind standardmäßig deaktiviert in MongoDB-Installationen, die nur zu Entwicklungszwecken gedacht sind. In produktiven Umgebungen ist das Aktivieren von Authentifizierung und Autorisierung nicht optional, sondern zwingend erforderlich. Die Kombination mit TLS-Verschlüsselung für Netzwerkverbindungen und Encryption-at-Rest für gespeicherte Daten bildet ein umfassendes Sicherheitskonzept.

Diese Terminologie durchzieht die gesamte MongoDB-Dokumentation und Community-Diskussionen. Die Begriffe präzise zu verwenden erleichtert nicht nur die Kommunikation, sondern auch das Verständnis der Architektur und der Design-Entscheidungen hinter MongoDB.