Kurs
Du hast wahrscheinlich schon von relationalen Datenbanken gehört oder damit gearbeitet. Das Zeilen-Spalten-Format ist die gängigste und intuitivste Struktur, um Informationen zu speichern. Leider lassen sich nicht alle Daten, die dir begegnen, in Zeilen und Tabellen pressen. Tatsächlich erfordern viele Probleme in der Realität nicht-relationale Datenbanken. Gibt es also Alternativen?
Die Antwort ist: Ja! Es gibt vier Arten von Datenbanken, die ohne Zeilen und Tabellen auskommen. Sie werden NoSQL-Datenbanken genannt, da du sie nicht mit SQL abfragen kannst. Dazu gehören:
- Key-Value-Datenbanken
- Dokumentdatenbanken
- Spaltenfamilien-Datenbanken
- Graphdatenbanken
Dieser Artikel konzentriert sich auf Dokumentdatenbanken und die Nutzung eines Servers namens MongoDB. Bevor wir in die technischen Details einsteigen, schauen wir uns die Anwendungsfälle von Dokumentdatenbanken an. Eine separate Einführung in Graphdatenbanken findest du hier.
Wann setzt du Dokumentdatenbanken ein?
Einer der wichtigsten Gründe für Dokumentdatenbanken ist, wenn deine Daten nicht sauber in ein vordefiniertes Schema wie eine Tabelle passen. Zahlreiche Prozesse oder Anwendungen in Unternehmen speichern solche Daten. Einige Beispiele:
- Web- und Mobile-Apps: Nutzerprofile, Präferenzen, Inhalte und Interaktionen
- Content-Management-Systeme: Speicherung verschiedenster Medien wie Text, Bilder, Videos, GIFs usw.
- E-Commerce-Plattformen: Produktkataloge, Kundendaten, Bestellhistorie, Lagerbestände usw.
- Gaming: Spielerprofile, Bestenlisten
- Logging und Datenerfassung: große Mengen an Logs, Events und Metriken für Analysen usw.
Überleg kurz, wie sich diese Daten in Tabellen zwängen ließen. E-Commerce-Plattformen hätten zum Beispiel Mühe, Produktkataloge in ein fixes Schema zu pressen. Unterschiedliche Produkte haben unterschiedliche Attribute oder sogar unterschiedlich viele Attribute. Brauchst du 10 Spalten, um 10 physische Merkmale von Drohnen aus 100 Marken zu speichern, oder reichen 5–6 für Buchinformationen?
Tabellenbasierte Datenbanken helfen dir in solchen Szenarien nicht weiter. Mit Dokumentdatenbanken wie MongoDB profitierst du von folgenden Vorteilen:
- Kein initialer Entwicklungsaufwand für ein Schema
- Dokumente (Daten) können sich im Zeitverlauf ändern (inklusive Datentypen, Anzahl der Attribute usw.)
- Dokumentdatenbanken vermeiden Joins, was zu deutlich schnelleren Abfragen führt
- Intuitiv für Entwickler, da Dokumentdatenbanken meist große JSON-Dateien sind — für Pythonistas also riesige Dictionaries.
- Dokumentdatenbanken skalieren horizontal, benötigen also nicht mitwachsend immer mehr Rechenressourcen pro Server.
Schauen wir uns nun die Kernkonzepte von Dokumentdatenbanken und MongoDB an.
Lass dich für deine Traumrolle als Datenanalyst zertifizieren
Unsere Zertifizierungsprogramme helfen dir, dich von anderen abzuheben und potenziellen Arbeitgebern zu beweisen, dass deine Fähigkeiten für den Job geeignet sind.

Kernkonzepte rund um MongoDB
Ich habe bisher immer wieder von Dokumentdatenbanken gesprochen, aber was genau ist das? Hier sind die zentralen Konzepte:
- Dokumente: Daten werden in Objekten namens Dokumente gespeichert. Vereinfacht sind Dokumente JSON-ähnlichen Key-Value-Objekten sehr ähnlich. Ein einzelnes Dokument entspricht einer Tabellenzeile. Wenn du Python programmierst, kannst du dir ein Dokument wie ein Dictionary vorstellen. Wichtig: Dokumente können verschachtelte Dokumente enthalten — eines der Kernmerkmale von Dokumentdatenbanken.
- Kollektionen: Kollektionen sind wie Tabellen in relationalen Datenbanken, enthalten aber — du ahnst es — Dokumente statt Zeilen. Kollektionen sind große Datenstrukturen mit tausenden bis Millionen von Dictionaries.
- Schemalos: Hier wird es spannend. Eine Kollektion kann Dokumente unterschiedlicher Größe enthalten. Dokument 1 kann z. B. 10 Key-Value-Paare haben, während Dokument 2 15 hat (solange die Informationen thematisch zusammenpassen, etwa Produkte).
Hier ist eine gute Tabelle, die die Unterschiede zwischen relationalen und Dokumentdatenbanken zusammenfasst:
| Merkmal | Dokumentdatenbanken (z. B. MongoDB) | Relationale Datenbanken (z. B. MySQL, PostgreSQL) |
|---|---|---|
| Datenstruktur | Speichert Daten als Dokumente (z. B. JSON, BSON) und erlaubt flexible, hierarchische Strukturen. | Speichert Daten in Tabellen mit Zeilen und Spalten nach einem vordefinierten Schema. |
| Schema-Flexibilität | Schemalos: Dokumente können unterschiedliche Strukturen, Felder und Datentypen haben. | Festes Schema: Erfordert ein vordefiniertes Schema mit spezifischen Spalten und Datentypen. |
| Abfragesprache | Verwendet die MongoDB Query Language (MQL) oder ähnliche objektbasierte, flexible Sprachen. | Verwendet SQL (Structured Query Language) für strukturierte Daten. |
| Joins | Vermeidet Joins durch Einbetten zusammenhängender Daten in Dokumente (Denormalisierung). | Unterstützt komplexe Joins über Tabellen hinweg (Normalisierung). |
| Performance | Schnellere Lese- und Schreibzugriffe für unstrukturierte oder semi-strukturierte Daten. Kein Overhead durch Joins. | Hohe Leistung für strukturierte Daten, aber Joins können Abfragen verlangsamen. |
| Skalierbarkeit | Horizontal skalierbar: Verteilung von Daten über mehrere Server mittels Sharding. | Typisch vertikal skalierbar: Setzt auf stärkere Hardware, teils auch horizontal (z. B. Partitionen). |
| Transaktionen | Unterstützt ACID-Transaktionen über mehrere Dokumente (ab MongoDB 4.0), ursprünglich für nicht-transaktionale Operationen konzipiert. | Vollständige ACID-Unterstützung für starke Konsistenz und Zuverlässigkeit. |
| Anwendungsfälle | Ideal für unstrukturierte oder semi-strukturierte Daten wie Nutzerprofile, Logs, Kataloge und flexible Strukturen. | Ideal für strukturierte Daten mit klaren Beziehungen, z. B. Finanzdaten oder ERP. |
| Datenbeziehungen | Unterstützt eingebettete Daten (Denormalisierung) und erleichtert so das Abrufen verwandter Infos per Einzelabfrage. | Setzt auf Fremdschlüssel zur Beziehungspflege zwischen Tabellen (Normalisierung). |
| Indexierung | Unterstützt Indizes, jedoch meist weniger Vielfalt und Finesse als in relationalen Systemen. | Starke Indexfunktionen mit mehreren Indextypen (z. B. B-Tree, Hash) zur Performanceoptimierung. |
| Konsistenz | Bietet Eventual Consistency in verteilten Setups, aber auch starke Konsistenz bei Bedarf (via ACID-Transaktionen). | Gewährleistet in der Regel starke Konsistenz durch ACID und relationale Integrität. |
| Skalierung des Datenvolumens | Skaliert leicht durch das Hinzufügen von Servern (Sharding), um große Datenmengen aufzunehmen. | Kann vertikal skalieren; horizontale Skalierung erfordert komplexere Konfiguration (z. B. Partitionierung). |
| Datenintegrität | Integrität wird innerhalb eines Dokuments gewahrt; Beziehungen zwischen Dokumenten sind schwieriger zu verwalten. | Starke Integrität durch Primär-/Fremdschlüssel sowie Constraints wie UNIQUE und NOT NULL. |
| Entwicklerfreundlichkeit | Entwicklerfreundlich: Flexibles Datenmodell, passt gut zu modernen Anwendungen (z. B. JSON, REST-APIs). | Starres Datenmodell, dafür vertraut für Entwickler mit SQL-Background. |
Lass uns jetzt in MongoDB wirklich mit Dokumenten arbeiten!
MongoDB-Setup: Verbindung zu Datenquellen
Um Dokumentdatenbanken abzufragen, müssen wir den MongoDB-Server installieren. Hier sind plattformspezifische Anleitungen:
- Für Windows folgst du dieser Anleitung.
- Auf Unix-ähnlichen Systemen kannst du MongoDB im Terminal installieren:
$ sudo apt-get install -y mongodb
Installiere dann in einer virtuellen Umgebung die Bibliotheken pymongo und requests. pymongo ist der offizielle Python-Adapter für den MongoDB-Server. requests benötigen wir, um Daten aus einer API zu laden.
$ pip install pymongo
$ pip install requests
Starte anschließend den MongoDB-Server über das Terminal mit folgendem Befehl:
$ sudo service mongodb start
Jetzt sind wir bereit, Daten in eine Dokumentdatenbank zu laden. Dabei gibt es zwei Fälle:
- Du hast Daten lokal in passenden Formaten wie JSON, BSON, YAML oder XML.
- Du musst Daten aus externen Quellen holen, typischerweise über APIs.
Wir decken beides ab. Zuerst laden wir lokal eine Kollektion namens drone_races.json. So geht’s:
import json
from pymongo import MongoClient
# Establish connection to MongoDB
client = MongoClient("localhost", 27017)
# Create a database named "drones"
drones = client["drones"]
# Create a collection named "races"
races = drones["races"]
# Load dataset into MongoDB
with open("data/drone_races.json", "r") as file:
data = json.load(file)
races.insert_many(data)
Die zwei wichtigsten Objekte für uns sind drones (eine Datenbank) und races (eine Kollektion). Die meisten Funktionen und Methoden beziehen sich auf Kollektionen. Datenbankobjekte nutzt man vor allem, um Kollektionen zu verwalten.
Schauen wir uns nun an, wie wir dieselben Daten per API laden. Ich habe die Informationen als API über einen Dienst namens Mockaroo bereitgestellt. Hier ist der Code:
import requests
from pymongo import MongoClient
# Fetch data from the API
api_url = (
"https://my.api.mockaroo.com/drone_race_matches.json?key=6f5a6b50"
)
response = requests.get(api_url)
if response.status_code == 200:
data = response.json() # Get the JSON data from the API
# Establish a connection to MongoDB
client = MongoClient()
# Access or create a specific database
drones = client["drones"]
# Access or create a specific collection within the database
races = drones["races"]
# Insert the fetched data into the MongoDB collection
races.insert_many(data)
else:
print("Failed to fetch data from the API.")
Wir haben einige Daten in die Kollektion races der Dokumentdatenbank drones geladen — oder doch nicht? Prüfen wir es mit Abfragen!
Einfache MongoDB-Abfragen
Dokumente in MongoDB zählen
Wir müssen die Dokumente zählen, um zu sehen, ob in einer Kollektion Daten vorhanden sind. Dafür nutzen wir die Methode count_documents:
>>> races.count_documents({})
9040
Beachte das leere Dictionary, das an count_documents übergeben wird. Dieses Dictionary heißt in MongoDB Filter. Im Verlauf des Tutorials lernst du, wie du es füllst, um unterschiedliche Filter zu bauen. Aktuell haben wir keinen Filter. Der obige Code entspricht in SQL SELECT COUNT(*) FROM table_name.
Wir haben 9040 Dokumente — yay! Schauen wir uns nun einige Daten an.
Ein einzelnes Dokument in MongoDB abrufen
Um ein Dokument mit pymongo anzusehen, nutzen wir find_one:
from pprint import pprint
>>> pprint(races.find_one())
{'_id': ObjectId('659d31e9255ec0cf4bab529d'),
'laps': 3,
'league': 'F1 Drones',
'location': {'city': 'Ford',
'country': 'United Kingdom',
'date': 'error: invalid date "2024-10-25"',
'venue': 'Manhattan Seas'},
'name': 'Honorable',
'pilots': {'drone': 'DJI3-old',
'finishing_position': 66,
'name': 'Kariotta Cow',
'qualification_time': 27.39,
'team': 'Sky Crusaders',
'telemetry': {'altitude': 34.3,
'battery_voltage': 12.1,
'speed': 68.3,
'timestamp': 'error: invalid date '
'"2024-10-25T14:09:26Z"'}},
'sponsors': ['Fat Shark', 'DJI', 'Etisalat'],
'weather_conditions': 'snowy'}
Achte auf die Felder (Keys) dieses Dokuments. Es speichert Infos zu einem einzelnen Drohnenrennen, unter anderem:
- Die Anzahl der Runden
- Die Wetterbedingungen zum Zeitpunkt des Rennens
- Die Piloten (nicht alle) während des Rennens
- Sponsoren des Rennens usw.
Das Dokument hat außerdem ein Pflichtfeld _id, einen eindeutigen Hash.
Alle Dokumente in MongoDB selektieren
count_documents liefert immer eine Zahl, aber manchmal wollen wir die passenden Daten sehen. Dafür nutzen wir den großen Bruder von find_one, nämlich find:
from pprint import pprint
for race in races.find():
pprint(race)
break
{'_id': ObjectId('659d31e9255ec0cf4bab529d'),
'laps': 3,
'league': 'F1 Drones',
'location': {'city': 'Ford',
'country': 'United Kingdom',
'date': 'error: invalid date "2024-10-25"',
'venue': 'Manhattan Seas'},
'name': 'Honorable',
'pilots': {'drone': 'DJI3-old',
'finishing_position': 66,
'name': 'Kariotta Cow',
'qualification_time': 27.39,
'team': 'Sky Crusaders',
'telemetry': {'altitude': 34.3,
'battery_voltage': 12.1,
'speed': 68.3,
'timestamp': 'error: invalid date '
'"2024-10-25T14:09:26Z"'}},
'sponsors': ['Fat Shark', 'DJI', 'Etisalat'],
'weather_conditions': 'snowy'}
find ohne Argumente gibt Dokumente nacheinander zurück — das wollen wir aber nicht! Wir wollen Abfragen formulieren, um interessante Fragen zu beantworten. Hier kommen Filterdokumente ins Spiel.
Selektieren anhand einer Bedingung in MongoDB
Starten wir mit den einfachsten Filtern — wir suchen Dokumente, bei denen ein Feld gleich einem Wert ist. Das wäre in SQL:
SELECT *
FROM table_name
WHERE field = value
So sieht das in MongoDB aus:
criteria = {"sponsors": "Fat Shark"}
fat_shark_races = races.count_documents(criteria)
fat_shark_races
6194
Hier wählen wir Rennen mit "Fat Shark" als Sponsor. Die Syntax ist einfach ein Dictionary, das das Feld sponsors auf "Fat Shark" abbildet.
Eine Abfragesprache wäre keine Sprache ohne Ungleichheitsoperatoren. So nutzt du den „kleiner als“-Operator:
criteria = {"pilots.qualification_time": {"$lt": 10}}
quick_races = races.count_documents(criteria)
quick_races
3061
Die obige Abfrage führt vier neue MQL-Features ein:
- Du greifst mit Punktnotation auf Unterfelder zu.
pilots.qualification_timeholt die verschachtelte Qualifikationszeit. - Fast alle Operatoren in MQL beginnen mit einem Dollarzeichen.
- Operatoren stehen in einem verschachtelten Dokument.
$ltsteht für „less than“.
Das Ergebnis sagt uns: Es gab 3061 Rennen, in denen ein Pilot unter 10 Sekunden Qualifikationszeit hatte. Neben $lt gibt es u. a.:
$lte: kleiner oder gleich$gt: größer als$gte: größer oder gleich
Die Syntax ist jeweils identisch.
Selektieren mit logischen Operatoren in MongoDB
MQL bietet auch logische Operatoren wie $and und $or. Starten wir mit Letzterem.
Wir holen Rennen, die entweder im Vereinigten Königreich stattfanden oder Etisalat als Sponsor hatten:
criteria = {
"$or": [
{"location.country": "United Kingdom"},
{"sponsors": "Etisalat"},
]
}
>>> races.count_documents(criteria)
6223
Es gibt 6223 Dokumente, die unsere Kriterien erfüllen. Für eine OR-Logik über mehrere Werte desselben Felds nutzen wir $in.
So prüfen wir z. B. auf schlechtes Wetter:
criteria = {
"weather_conditions": {"$in": ["rainy", "snowy", "cloudy"]}
}
>>> races.count_documents(criteria)
5508
Mit $or wäre das sehr umständlich. Weiter mit $and.
Diesmal suchen wir Rennen in Australien UND mit Fat Shark als Sponsor. So geht’s mit $and:
criteria = {
"$and": [
{"location.country": "Australia"},
{"sponsors": "Fat Shark"},
]
}
>>> races.count_documents(criteria)
193
In der Praxis wirst du $and selten brauchen, denn es geht deutlich einfacher:
criteria = {
"location.country": "Australia",
"sponsors": "Fat Shark",
}
races.count_documents(criteria)
193
Füge dem Filterdokument einfach weitere Key-Value-Paare hinzu, um AND-Logik abzubilden.
Zum Schluss noch $nin für „nicht enthalten“. So geben wir alle Rennen zurück, die nicht in den USA, dem Vereinigten Königreich oder Australien stattfanden:
criteria = {
"location.country": {
"$nin": ["United States", "United Kingdom", "Australia"]
}
}
>>> races.count_documents(criteria)
126
Hier bleibt nur die United Arab Emirates übrig, daher könnten wir die Abfrage auch so schreiben:
criteria = {"location.country": "United Arab Emirates"}
>>> races.count_documents(criteria)
126
Du siehst das Prinzip.
Nach Null- oder fehlenden Werten in MongoDB suchen
Das Prüfen auf Null oder fehlende Werte ist ein Klassiker in der Datenanalyse. Dafür gibt es in MongoDB den Operator $exists. Zwei Beispiele, die prüfen, ob ein Feld existiert:
criteria = {"location.district": {"$exists": True}}
>>> races.count_documents(criteria)
0
Hmm, es stellt sich heraus: Das Feld district existiert in keinem Dokument. Das Feld laps hingegen sollte in allen Dokumenten vorhanden sein, da es für Rennen essenziell ist.
criteria = {"laps": {"$exists": True}}
races.count_documents(criteria)
9040
Wie erwartet, besitzen alle Dokumente das Feld laps. Was ist mit existierenden Feldern, die den Wert null haben? Auch das können wir prüfen:
criteria = {"pilots.finishing_position": None}
races.count_documents(criteria)
0
Mit dem eingebauten Python-Objekt None kannst du jeden Feldwert auf Missingness prüfen.
Es gibt auch fortgeschrittene Fälle für Null- oder Existenzprüfungen. Beispielsweise, wenn du prüfen willst, ob bestimmte Elemente in großen, verschachtelten Arrays existieren.
Hierfür nutzen wir die Array-Indizierungssyntax in MQL. Um etwa Rennen mit genau einem Sponsor zu finden, prüfen wir, ob das zweite Element im sponsors-Array existiert:
# Zählung beginnt wie immer bei 0
criteria = {"sponsors.1": {"$exists": False}}
races.count_documents(criteria)
2929
Das geht so einfach, indem du dem Key die Indexnummer anhängst. In unserer Kollektion wurden also knapp 3000 Rennen nur von einem Sponsor getragen.
Diese Array-Indizierung funktioniert mit vielen weiteren Operatoren, nicht nur mit $exists.
Projektionen (Felder einschränken)
Zum Schluss schauen wir uns Projektionen an. Bisher enthalten unsere Abfrageergebnisse jedes Feld eines Dokuments. Das ist unpraktisch, wenn Dokumente hunderte Felder haben — dein Output wird schnell unleserlich.
Um nur bestimmte Felder zurückzugeben, nutzen wir Projektionen. So geht’s:
criteria = {"pilots.telemetry.speed": {"$gte": 20}}
projection = {
"sponsors": 1,
"location.country": 1,
"pilots.telemetry.speed": 1,
"pilots.name": 1,
}
fast_pilots = races.find(criteria, projection)
for pilot in fast_pilots:
pprint(pilot)
break
Wir definieren wie gewohnt die Filterkriterien und geben zusätzlich ein Dokument mit vier auf 1 gesetzten Feldern an. Übergibst du dieses projection-Dokument als zweites Argument an find oder count_documents, erhältst du nur die Felder mit Wert 1.
{'_id': ObjectId('659d31e9255ec0cf4bab529d'),
'location': {'country': 'United Kingdom'},
'pilots': {'name': 'Kariotta Cow', 'telemetry': {'speed': 68.3}},
'sponsors': ['Fat Shark', 'DJI', 'Etisalat']}
Obwohl wir nur vier Felder wählten, taucht das hartnäckige Feld _id weiterhin auf. Um das zu unterdrücken, setze es in der projection auf 0:
criteria = {"pilots.telemetry.speed": {"$gte": 20}}
projection = {
"sponsors": 1,
"location.country": 1,
"pilots.telemetry.speed": 1,
"pilots.name": 1,
"_id": 0,
}
fast_pilots = races.find(criteria, projection)
for pilot in fast_pilots:
pprint(pilot)
break
{'location': {'country': 'United Kingdom'},
'pilots': {'name': 'Kariotta Cow', 'telemetry': {'speed': 68.3}},
'sponsors': ['Fat Shark', 'DJI', 'Etisalat']}
So sieht das deutlich aufgeräumter aus.
Möchtest du alle Felder bis auf wenige zurückgeben, setzt du diese wenigen auf 0:
projection = {"_id": 0, "league": 0, "pilots": 0}
# Leere Kriterien in diesem Beispiel
races.find_one({}, projection)
{'name': 'Honorable',
'location': {'venue': 'Manhattan Seas',
'city': 'Ford',
'country': 'United Kingdom',
'date': 'error: invalid date "2024-10-25"'},
'sponsors': ['Fat Shark', 'DJI', 'Etisalat'],
'laps': 3,
'weather_conditions': 'snowy'}
Wie du siehst, erhalten wir diesmal alle Felder außer _id, league und pilots.
Fazit
Dieses Tutorial kratzt nur an der Oberfläche von MongoDB als Datenbankmanagementsystem. Heute haben wir nur GET-Abfragen (Abrufen von Informationen) behandelt, doch MongoDB erlaubt auch das Einfügen, Aktualisieren und Löschen von Informationen in Dokumentdatenbanken. Ebenfalls unberührt blieb eine ganze Klasse von Abfragen — Aggregationen.
All diese Themen sprengen den Rahmen dieses Artikels und erfordern weitere Ressourcen. Schau dir zum Start gerne Folgendes an:
- Introduction to using MongoDB in data science with Python course — ein umfassender Kurs, der auch fortgeschrittene Abfragen wie Aggregationen abdeckt
- Intro to MongoDB in Python — ein weiteres MongoDB-Tutorial, das CRUD-Operationen (Create, Read, Update, Delete) mit pymongo behandelt.
- NoSQL concepts course — wenn dich NoSQL-Datenbanken interessieren, ist dieser Kurs für dich. Neben Dokumentdatenbanken deckt er weitere nicht-relationale Datenbanken ab.
Werde SQL-zertifiziert
FAQs
Worin unterscheiden sich Dokumentdatenbanken wie MongoDB von relationalen Datenbanken?
Dokumentdatenbanken wie MongoDB speichern Daten in Dokumenten (oft in JSON-ähnlichen Formaten), die verschachtelte Strukturen enthalten können. Das unterscheidet sie von relationalen Datenbanken, die Daten in Zeilen und Tabellen mit festem Schema speichern. Dokumentdatenbanken bieten mehr Flexibilität, da das Schema dynamisch ist — jedes Dokument kann unterschiedliche Felder und Datentypen haben. Dadurch eignet sich MongoDB für unstrukturierte oder semi-strukturierte Daten, während relationale Datenbanken ein vordefiniertes Schema erfordern.
Warum sollte ich MongoDB statt einer relationalen Datenbank verwenden?
MongoDB ist sinnvoll, wenn du mit Daten arbeitest, die sich nicht sauber in eine Tabellenstruktur einfügen lassen. Nutze MongoDB, wenn dein Schema flexibel sein muss, du häufige Änderungen an der Datenstruktur erwartest oder große Mengen unstrukturierter Daten verarbeiten musst. Es ist auch eine gute Wahl für Anwendungen mit hohen Lese- und Schreibraten im großen Maßstab, z. B. E-Commerce, Logging oder Content-Management-Systeme.
Welche Programmiersprachen sind mit MongoDB kompatibel?
MongoDB ist mit vielen Programmiersprachen kompatibel, darunter Python, Java, JavaScript, Node.js, Go, Ruby und C#, über offizielle Treiber und Bibliotheken. In der Datenwissenschaft wird häufig die Python-Bibliothek pymongo verwendet, um mit MongoDB zu arbeiten. MongoDB lässt sich auch gut in moderne Frameworks wie Django, Flask und Express.js integrieren.
Wie geht MongoDB mit großskaligen Daten und horizontaler Skalierung um?
MongoDB ist für horizontale Skalierung durch Sharding ausgelegt, bei dem Daten über mehrere Server verteilt werden, um große Datenmengen effizient zu verwalten. Wenn deine Daten wachsen, kann MongoDB die Last über mehrere Maschinen verteilen und so Leistung und Kapazität erhöhen. Dadurch eignet sich MongoDB ideal für Big-Data-Anwendungen oder Szenarien mit rasant wachsendem Datenvolumen.
Bewältigt MongoDB komplexe Abfragen wie SQL-Datenbanken?
Ja, MongoDB kann komplexe Abfragen verarbeiten, aber die Abfragesprache (MQL, MongoDB Query Language) unterscheidet sich deutlich von SQL. MongoDB unterstützt Filter, Projektionen, logische Operatoren und Aggregationen für anspruchsvolle Abfragen, mit denen du Daten abrufen, filtern und transformieren kannst. Anders als SQL-Datenbanken unterstützt MongoDB jedoch Joins nicht in gleicher Weise, da es auf denormalisierte, flexible Dokumentstrukturen ausgelegt ist.
Ist MongoDB für Echtzeit-Analysen geeignet?
MongoDB eignet sich für Echtzeit-Analysen, die Performance hängt jedoch stark von Datenmodell und Indizes ab. Mit der leistungsfähigen Indexierung und dem Aggregations-Framework kannst du Echtzeitanalysen effizient durchführen. Für sehr komplexe analytische Aufgaben empfiehlt sich ggf. die Integration mit Tools wie Apache Spark oder die Nutzung des Aggregations-Frameworks für große, echtzeitnahe Verarbeitungen.
Welche Sicherheitsfunktionen bietet MongoDB?
MongoDB bietet zahlreiche Sicherheitsfunktionen, darunter Authentifizierung, Autorisierung (rollenbasierte Zugriffskontrolle), Verschlüsselung (während der Übertragung und im Ruhezustand) und Auditing. Die Enterprise Edition bietet zusätzliche Features wie LDAP-Integration und Kerberos-Authentifizierung für Unternehmensanforderungen. Diese Funktionen helfen, sensible Daten zu schützen und Compliance-Vorgaben einzuhalten.
Kann MongoDB ACID-Transaktionen verarbeiten?
Ja, MongoDB unterstützt ACID-konforme Transaktionen, insbesondere seit Version 4.0. Damit sind Transaktionen über mehrere Dokumente möglich — ähnlich wie in relationalen Datenbanken — und sorgen für Atomicity, Consistency, Isolation und Durability. Das macht MongoDB auch für Szenarien geeignet, die Transaktionsgarantien erfordern.
Worin besteht der Unterschied zwischen JSON und BSON in MongoDB?
JSON ist ein menschenlesbares Format zur Datenrepräsentation, während BSON (Binary JSON) das Speicherformat von MongoDB ist. BSON ermöglicht effizientere Speicherung und schnellere Abfragen und unterstützt zusätzliche Datentypen wie Datumswerte und Binärdaten, die JSON nicht nativ abbildet. Außerdem enthält BSON Metadaten, die die Performance bei Speicherung und Abruf verbessern.
Ich bin Content-Creator im Bereich Data Science mit über zwei Jahren Erfahrung und zähle zu den größten Stimmen auf Medium. Ich schreibe gern ausführliche Artikel über KI und ML – mit einer Prise Sarkasmus, damit das Ganze nicht zu trocken wird. Bisher habe ich über 130 Artikel veröffentlicht und einen DataCamp-Kurs produziert, ein weiterer ist in Arbeit. Meine Inhalte wurden von über 5 Millionen Menschen gelesen, 20.000 davon folgen mir auf Medium und LinkedIn.
