Aufgaben NoSQL
Letzte Lektion des Kurses – die Prüfungsvorbereitung. Wir gehen 12 typische IHK-Aufgaben zu allen Themen des NoSQL-Kurses durch: Warum NoSQL, die vier Familien, CAP-Theorem, MongoDB, Redis und die SQL-vs.-NoSQL-Entscheidung. Klick eine Aufgabe um sie zu öffnen – versuch erst selbst zu antworten, bevor du die Lösung aufklappst.
Die Aufgabentypen entsprechen denen aus echten Prüfungen: Begriff & Definition, Szenario-Analyse, Konzept-Vergleich, Code/Befehl-Erstellung, Beratung mit Begründung. Wer diese fünf Muster beherrscht, ist gut gerüstet.
1) Überblick
Aufgaben in dieser Lektion
12
Aufgaben
5
Aufgabentypen
6
Themen abgedeckt
~35
Punkte total
Punktzahlen sind Orientierungswerte – reale IHK-Aufgaben können davon abweichen. Wichtig: das Erkennen des Aufgabentyps beim Lesen der Frage. Eine reine Wissensfrage braucht andere Antworten als eine Szenario-Analyse. Bei „Erläutern Sie …" sind 2-3 Sätze pro Punkt richtig; bei „Nennen Sie …" reicht oft eine Aufzählung.
2) Aufgaben Teil A – Grundlagen & NoSQL-Typen
Aufgaben 1–4: Konzepte und Familien
NoSQL-Begriff erklären
Wofür steht die Abkürzung „NoSQL"? Nennen Sie drei Gründe, warum NoSQL-Datenbanken Mitte der 2000er entwickelt wurden.
Musterlösung
Bedeutung: „Not Only SQL" (nicht „No SQL"). Es geht nicht darum, SQL zu verdrängen, sondern um nicht-relationale Datenbanken als Ergänzung.
Drei Gründe für die Entwicklung:
- Horizontale Skalierung: Web-Riesen wie Google, Facebook, Amazon hatten Datenmengen, die nicht mehr auf einem Server passten. Klassische SQL-DBs sind schwer auf viele Server zu verteilen.
- Schema-Flexibilität: moderne Web-Daten sind oft variabel strukturiert. Feste SQL-Schemas mit ALTER TABLE für jede Änderung wurden zum Bremser.
- Angepasste Datenmodelle: für spezielle Use Cases (Caching, Graph-Analyse, Time-Series) sind spezialisierte Datenmodelle effizienter als das relationale.
Tipp: oft wird auch genannt: schwächere Konsistenz-Anforderungen ausreichend für viele Web-Use-Cases (Likes, Posts) – dadurch konnte Verfügbarkeit höher gewichtet werden (siehe CAP-Theorem).
Die vier NoSQL-Familien
Nennen Sie die vier Hauptfamilien von NoSQL-Datenbanken und geben Sie jeweils ein typisches Beispiel-Produkt sowie einen typischen Use Case an.
Musterlösung
- Key-Value-Store: Beispiel Redis. Use Case: Cache, Session-Store, Rate-Limiting.
- Dokument-Datenbank: Beispiel MongoDB. Use Case: Content-Management, Produktkataloge mit variablen Attributen, User-Profile.
- Wide-Column-Store: Beispiel Cassandra. Use Case: Time-Series-Daten, IoT-Telemetrie, Massendaten mit hoher Schreiblast.
- Graph-Datenbank: Beispiel Neo4j. Use Case: soziale Netzwerke, Empfehlungssysteme, Betrugserkennung.
Tipp: bei IHK-Fragen den Typ + Beispiel + Use Case zusammen nennen – das gibt die volle Punktzahl, selbst wenn die theoretische Erklärung knapp ist.
Datenmodell-Wahl
Ein Streaming-Dienst will Nutzern Filme empfehlen, basierend darauf welche Filme andere Nutzer mit ähnlichem Geschmack gut bewertet haben. Welche NoSQL-Familie eignet sich am besten und warum?
Musterlösung
Eine Graph-Datenbank (z.B. Neo4j) ist hier die beste Wahl.
Begründung: die Daten sind als Graph natürlich modellierbar – Knoten sind Nutzer und Filme, Kanten sind Bewertungen mit dem Score als Eigenschaft. Die Empfehlungs-Anfrage ist eine Pfad-Traversierung im Graph: „Finde Nutzer mit ähnlichem Bewertungsmuster, dann deren bevorzugte Filme."
Warum nicht SQL? In einer relationalen DB wäre das ein mehrfach verschachtelter JOIN über die Bewertungs-Tabelle – bei Millionen Nutzern extrem teuer. Graph-DBs sind für solche Traversierungen optimiert.
Tipp: Beziehungen sind oft das Erkennungszeichen für Graph-DBs. Wenn die Frage „wer kennt wen", „wer mag was wie wer" oder „kürzester Weg" ist, ist die Antwort meist Graph.
Vertikale vs. horizontale Skalierung
Erklären Sie die Begriffe vertikale Skalierung und horizontale Skalierung. Welche der beiden Strategien wird von NoSQL-Datenbanken besser unterstützt und warum?
Musterlösung
Vertikale Skalierung (Scale up): einen einzelnen Server stärker machen – mehr CPU, mehr RAM, schnellere Disks. Funktioniert bis zur Hardware-Grenze; Top-Server kosten exponentiell mehr.
Horizontale Skalierung (Scale out): mehrere günstigere Server zusammenschalten, Daten verteilen (Sharding). Theoretisch unbegrenzt erweiterbar.
NoSQL unterstützt horizontale Skalierung besser, weil:
- Daten ohne komplexe Beziehungen (kein Foreign-Key-Constraint über Server-Grenzen) leichter zu verteilen sind.
- JOINs über mehrere Server sind teuer; NoSQL vermeidet JOINs durch Embedded-Strukturen.
- NoSQL akzeptiert oft eventually consistent, was Replikation einfacher macht.
Stichwort fürs Plus: „Sharding" als Begriff einbringen – die Aufteilung von Daten über mehrere Server.
3) Aufgaben Teil B – CAP und MongoDB
Aufgaben 5–8: Theorie und MongoDB-Praxis
CAP-Theorem erklären
Wofür stehen die drei Buchstaben im CAP-Theorem? Was sagt das Theorem aus?
Musterlösung
- C – Consistency (Konsistenz): alle Knoten im System haben zu jedem Zeitpunkt dieselbe Sicht auf die Daten.
- A – Availability (Verfügbarkeit): jeder Knoten antwortet immer auf Anfragen.
- P – Partition Tolerance (Partitionstoleranz): das System funktioniert auch bei Netzwerk-Partitionen weiter.
Falle: das C in CAP ist nicht dasselbe wie das C in ACID. ACID-C meint „Constraints eingehalten", CAP-C meint „Replikate identisch".
SQL-Tabelle vs. MongoDB-Collection
Vergleichen Sie die zentralen Konzepte: SQL-Tabelle/-Zeile/-Spalte gegenüber MongoDB-Collection/-Document/-Field. Welcher fundamentale Unterschied besteht?
Musterlösung
Direkte Entsprechungen:
- SQL-Tabelle ≈ MongoDB-Collection (Container für gleichartige Daten)
- SQL-Zeile ≈ MongoDB-Document (ein einzelner Datensatz)
- SQL-Spalte ≈ MongoDB-Field (ein Attribut innerhalb des Datensatzes)
ALTER TABLE. In MongoDB ist das Schema dynamisch – jedes Document in einer Collection kann andere Felder haben, und auch verschachtelte Strukturen (Sub-Documents, Arrays) sind möglich.
Bonus-Punkte: erwähnen, dass MongoDB optional Schema-Validierung per JSON-Schema unterstützt – das ist der pragmatische Mittelweg.
MongoDB-Abfragen schreiben
Schreiben Sie MongoDB-Befehle für folgende Aufgaben in der Collection
a) Alle Kunden aus Berlin, die mindestens 18 Jahre alt sind.
b) Den Namen eines Kunden mit der Email „test@example.de" ändern.
c) Alle inaktiven Kunden (Feld
kunden:a) Alle Kunden aus Berlin, die mindestens 18 Jahre alt sind.
b) Den Namen eines Kunden mit der Email „test@example.de" ändern.
c) Alle inaktiven Kunden (Feld
aktiv: false) löschen.Musterlösung
a) Filtern:
db.kunden.find({ stadt: "Berlin", alter: { $gte: 18 } });
b) Aktualisieren:
db.kunden.updateOne(
{ email: "test@example.de" },
{ $set: { name: "Neuer Name" } }
);
c) Löschen:
{ email: "test@example.de" },
{ $set: { name: "Neuer Name" } }
);
db.kunden.deleteMany({ aktiv: false });
Häufiger Fehler: bei b) den
$set-Operator vergessen. Ohne $set ersetzt MongoDB das gesamte Dokument – nur das name-Feld bleibt übrig, alle anderen verschwinden!Embedded vs. Referenced
Erklären Sie den Unterschied zwischen Embedded und Referenced Datenmodellen in MongoDB. Wann wählen Sie welchen Ansatz?
Musterlösung
Embedded: verwandte Daten werden als Sub-Dokumente direkt in einem übergeordneten Dokument gespeichert. Beispiel: ein User-Dokument enthält ein Array seiner Adressen.
Referenced: verwandte Daten leben in einer eigenen Collection, das Eltern-Dokument verweist nur per ID darauf (ähnlich einem Foreign Key). Beispiel: User-Dokument enthält
adressen_ids, eine separate Collection hat die Adressen-Dokumente.
Wann was?
- Embedded, wenn die Daten „gehören zu", fast immer zusammen gelesen werden und sich selten unabhängig ändern. Vorteil: eine Abfrage liefert alles, atomare Updates.
- Referenced, wenn die Daten eigenständig existieren, von mehreren Eltern verwiesen werden könnten oder das Eltern-Dokument zu groß würde (16-MB-Limit).
Faustregel: „gehört zu" → embedded, „verweist auf" → referenced.
4) Aufgaben Teil C – Redis und Architektur
Aufgaben 9–12: Redis und Entscheidungen
Redis-Datentypen
Redis ist ein Key-Value-Store. Welche Datentypen für den Value unterstützt Redis? Nennen Sie mindestens vier und geben Sie für jeden einen typischen Use Case an.
Musterlösung
- String: einfacher Text/Zahl. Use Case: Cache-Einträge, atomare Counter (mit
INCR). - List: doppelt verkettete Liste. Use Case: Queues (Jobs, Notifications) mit
LPUSH/BLPOP. - Hash: Objekt mit Feldern. Use Case: User-Profile, Session-Daten als Feld-Wert-Paare.
- Set: ungeordnete Menge eindeutiger Strings. Use Case: Online-User-Liste, Tag-Sammlungen, Mengen-Operationen.
- Sorted Set: Menge mit Score, automatisch sortiert. Use Case: Leaderboards, Prioritäts-Queues.
Tipp: die exemplarischen Befehle nennen wenn es passt –
SET, LPUSH, HSET, SADD, ZADD – das zeigt Vertrautheit.Redis-Cache implementieren
Beschreiben Sie das Cache-Aside-Pattern als Pseudocode für eine Funktion
getProduct(id), die ein Produkt aus einem 5-Minuten-Cache holt oder bei Cache-Miss aus der DB lädt. Welche Redis-Befehle werden verwendet?Musterlösung
function getProduct(id):
# 1) Cache fragen
cached = redis.GET("product:" + id)
if cached:
return JSON.parse(cached) # Cache Hit
# 2) Aus DB lesen
product = db.query("SELECT ...", id)
# 3) In Cache schreiben mit TTL = 300 Sek
redis.SETEX("product:" + id, 300, JSON.stringify(product))
return product
Verwendete Redis-Befehle:
# 1) Cache fragen
cached = redis.GET("product:" + id)
if cached:
return JSON.parse(cached) # Cache Hit
# 2) Aus DB lesen
product = db.query("SELECT ...", id)
# 3) In Cache schreiben mit TTL = 300 Sek
redis.SETEX("product:" + id, 300, JSON.stringify(product))
return product
GET key– Wert aus Cache lesen, gibtnilbei Cache-Miss.SETEX key seconds valueoderSET key value EX seconds– Wert schreiben mit Time-to-Live.
Plus-Punkte: Cache-Invalidierung erwähnen – beim UPDATE des Produkts muss der Cache-Eintrag ungültig gemacht werden (
DEL product:42), sonst kommen veraltete Daten.Architektur entwerfen
Für einen Online-Shop sollen folgende Daten gespeichert werden: (a) Kundendaten und Bestellungen mit Rechnungen, (b) Produktkatalog mit unterschiedlichen Attributen pro Produkttyp, (c) User-Sessions mit Warenkorb. Schlagen Sie eine geeignete Datenbank-Architektur vor und begründen Sie jede Wahl.
Musterlösung
Empfehlung: Polyglot Persistence mit drei spezialisierten Datenspeichern.
- (a) Kunden & Bestellungen: relationale SQL-DB (z.B. PostgreSQL oder MySQL). Begründung: harte ACID-Anforderungen für Geld und Rechtsdaten, klare Struktur, komplexe Reports nötig.
- (b) Produktkatalog: Dokument-DB (z.B. MongoDB). Begründung: variable Attribute pro Produkttyp (Bücher haben Autor, Schuhe haben Größe). In SQL würde das viele NULL-Spalten oder eine Vererbungs-Hölle bedeuten.
- (c) Sessions & Warenkörbe: Redis. Begründung: häufiger Zugriff mit Sub-Millisekunden-Anforderung, automatischer Ablauf per TTL, kein langfristiger Storage nötig.
Stichwort: „Polyglot Persistence" explizit nennen – das ist der Fachbegriff für diese Architektur und wird in der IHK-Bewertung als Plus gewertet.
ACID vs. BASE
Erklären Sie die Konzepte ACID und BASE und ordnen Sie sie SQL/NoSQL zu. Welches ist „besser"?
Musterlösung
ACID (Klassische SQL-Welt): Atomicity, Consistency, Isolation, Durability. Strikte Transaktionsgarantien – Operationen entweder ganz oder gar nicht, immer konsistent, isoliert von anderen, dauerhaft gespeichert.
BASE (typisch für AP-NoSQL-Welt): Basically Available, Soft state, Eventually consistent. Schwächere Garantien – das System ist meist verfügbar, der Zustand kann sich auch ohne neue Eingaben durch Hintergrund-Replikation ändern, Konsistenz wird irgendwann erreicht aber nicht sofort.
Keines ist „besser" – sie passen zu unterschiedlichen Use Cases:
- ACID: Bank-Transaktionen, Buchhaltung, alles mit Geld-Bezug.
- BASE: Social-Media-Likes, Click-Counter, Sensor-Daten – Bereiche, wo kurze Inkonsistenz akzeptabel und hohe Verfügbarkeit wichtiger ist.
Bonus: Brücke zum CAP-Theorem schlagen – ACID-Systeme sind oft CP, BASE-Systeme oft AP. Auch erwähnen, dass moderne NoSQL-DBs (MongoDB seit 4.0) ACID-Transaktionen unterstützen, die Grenzen also fließend werden.
5) Mini-Quiz: schnelle Zuordnung
Sechs kurze Multiple-Choice-Fragen zur Wiederholung:
Schnell-Quiz
6) Cheatsheet – das musst du auswendig wissen
Vor der Prüfung am Tag vorher überfliegen. Diese Begriffe sicher in der Klausur zu nennen, ist der Unterschied zwischen Befriedigend und Gut:
Spickzettel
NoSQL = ?
„Not Only SQL". Ergänzung, nicht Ersatz.
4 NoSQL-Familien
Key-Value (Redis), Dokument (MongoDB), Wide-Column (Cassandra), Graph (Neo4j)
CAP
Consistency, Availability, Partition Tolerance – nur 2 von 3
ACID vs. BASE
Streng (SQL) vs. eventually consistent (NoSQL/AP)
MongoDB-Hierarchie
Database → Collection → Document → Field
MongoDB CRUD
insertOne, find, updateOne (immer $set!), deleteOneQuery-Operatoren
$eq, $gt/$gte, $lt/$lte, $in, $or, $regex, $existsAggregation Stages
$match, $group, $project, $sort, $limit, $lookupEmbedded vs. Ref
Embedded = „gehört zu", Referenced = „verweist auf"
Redis-Datentypen
String, List, Hash, Set, Sorted Set, Stream
Redis Use Cases
Cache, Session, Pub/Sub, Rate Limit, Queue, Leaderboard
Persistenz
RDB (Snapshots) + AOF (Append-Only File) für Redis
Skalierung
Vertikal (Scale up) vs. horizontal (Scale out / Sharding)
Polyglot Persistence
Mehrere DBs parallel, jede für ihren Use Case
Wann SQL?
Strukturierte Daten, ACID, komplexe Reports, kleine bis mittlere Datenmenge
Wann NoSQL?
Variable Daten, hohe Last, horizontale Skalierung, spezialisierte Datenmodelle
Die hier aufgelisteten Begriffe sicher in der Klausur zu nennen, ist oft der entscheidende Faktor zwischen den Notenstufen. Wer „Polyglot Persistence", „eventually consistent" und „horizontal skalieren" als selbstverständliche Begriffe einbaut, signalisiert Tiefe.
Zusammenfassung & Kurs-Abschluss
Mit dieser Lektion ist der NoSQL-Kurs abgeschlossen. Du hast eine breite Tour durch die NoSQL-Welt gemacht: warum NoSQL überhaupt entstanden ist, die vier Familien, das CAP-Theorem als theoretische Grundlage, MongoDB als Dokument-DB mit CRUD und Aggregation, Redis als Key-Value-Store mit seinen vielfältigen Use Cases, und schließlich die Entscheidungs-Strategie. Die zwölf Aufgaben hier decken alle prüfungsrelevanten Aufgabentypen ab. Wer sie sicher beantworten kann, ist auf den NoSQL-Teil der IHK-Abschlussprüfung gut vorbereitet. Wichtigste Take-Aways: NoSQL ist kein Ersatz für SQL, sondern eine Ergänzung. Wähle das Werkzeug nach dem Problem, nicht nach Hype. Polyglot Persistence ist der heutige Standard.