Was ist NoSQL? Unterschied zu SQL und die richtige Datenbankwahl

Was ist NoSQL?

NoSQL ist eine Familie von Datenbanken, die Daten nicht in klassischen relationalen Tabellen ablegt, sondern als Dokumente, Schlüssel und Werte, breite Spalten oder Graphen. Zunächst steht der Name meist für "not only SQL". Typisch sind also flexible Schemas, einfaches horizontales Skalieren und ein Aufbau für bestimmte Arbeitslasten.

Ein Vergleich hilft. Eine relationale Datenbank gleicht einem Aktenschrank, dessen Schubladen vorab beschriftet sind. NoSQL ist dagegen kein einzelner Schrank, sondern eine ganze Möbelfamilie: eine Garderobe mit Nummern, Ordner für beliebigen Inhalt oder eine Pinnwand, auf der Fäden Beziehungen zeigen.

Die ehrliche Antwort auf die Frage "Was ist NoSQL" lautet deshalb nicht "ein Produkt", sondern "eine Reihe von Ansätzen". Dieser Leitfaden stellt die Familie vor, vergleicht sie mit SQL und zeigt, welche Aufgabe zu welchem Typ passt.

Wir haben den Text für Einsteiger und für Entwickler geschrieben, die eine Architekturentscheidung treffen müssen. Produktnamen nennen wir außerdem nur als neutrale Beispiele.

Warum stellen so viele Menschen diese Frage? Die Wahl der Datenbank fällt in der ersten Woche eines Projekts, sie begleitet Sie aber jahrelang. Denn eine falsche Wahl kostet später Geld und Zeit. Wer die Frage "Was ist NoSQL" klärt, trifft diese Entscheidung bewusster.

Merken Sie sich beim Lesen Folgendes: Wir wollen Sie nicht zu einem Produkt lenken. Sie sollen stattdessen die richtige Frage an Ihre eigenen Daten stellen, denn eine gute Wahl hängt mehr von der Arbeitslast ab als von einer Marke.

Warum bedeutet der Name NoSQL nicht "gegen SQL"?

Der Name führt in die Irre, denn diese Datenbanken sind keine Gegner von SQL. Viele bieten Abfragesprachen, die an SQL angelehnt sind. Einige unterstützen daher sogar klassisches SQL direkt. Deshalb liest man den Namen meist als "nicht nur das relationale Modell".

Der Ursprung ist allerdings einfach. Mit dem Wachstum von Webanwendungen passten manche Datenmengen nicht mehr auf einen einzigen starken Server. Zudem passt nicht jede Art von Daten natürlich in Zeilen und Spalten. Zum Beispiel hat in einem Produktkatalog jedes Produkt andere Eigenschaften. In einem sozialen Netzwerk liegt der Wert dagegen in den Verbindungen zwischen den Datensätzen.

Ingenieure entwickelten daher Modelle, die zur Arbeitslast passen, statt alles in eine Form zu pressen. Somit ist NoSQL nicht die Aussage "SQL ist schlecht". Es ist vielmehr die Beobachtung, dass ein Werkzeug nicht für jede Aufgabe taugt.

Hinweis: Die Grenzen des Begriffs sind nicht scharf. Daher ist es manchmal strittig, ob ein Produkt als NoSQL gilt. Wir folgen hier dem üblichen Sprachgebrauch.

Außerdem unterscheiden sich NoSQL Produkte stark voneinander. Ein Key Value Speicher und eine Graphdatenbank trennen Welten, etwa wie ein Fahrrad und ein Lastwagen. Der Satz "Wir nutzen NoSQL" sagt deshalb fast nichts. Deshalb bleibt entscheidend: welches Modell, für welche Aufgabe.

Was ist NoSQL und wie funktioniert es im Inneren?

Jede NoSQL Datenbank wählt zunächst ein Modell, um Daten zu ordnen. Danach baut sie Speicherung, Indizes und Abfragen passend dazu auf. Gemeinsam ist allen, dass sie nicht von einem festen Tabellenschema oder von Joins abhängen.

Viele NoSQL Systeme verteilen Daten auf mehrere Server. Zunächst heißt diese Aufteilung Sharding. Jeder Datensatz landet anhand eines Schlüssels auf einem bestimmten Server. Dadurch verteilt sich also die Last beim Lesen und Schreiben auf mehrere Maschinen.

Zur Sicherheit liegt derselbe Datensatz auf einigen Servern als Kopie. Das nennt man dann Replikation. Fällt ein Server aus, übernimmt deshalb eine Kopie. Allerdings können zwischen den Kopien kleine Verzögerungen entstehen, und das wirft die Frage der Konsistenz auf.

Kurz gesagt folgt die Arbeitsweise drei Schritten:

• Sie beschreiben die Daten in einem Modell, das zur Arbeitslast passt.
• Sie teilen und kopieren sie nach Schlüsseln, damit sich die Last verteilt.
• Sie entwerfen Abfragen passend zur Ablage der Daten.

Allerdings geht der dritte Schritt oft unter. In der relationalen Welt ordnen Sie zuerst die Daten und denken später über Fragen nach. In der NoSQL Welt sammeln Sie dagegen oft zuerst die Fragen und legen die Daten passend dazu ab. Die Reihenfolge des Entwurfs dreht sich also um.

Was ist eine Dokumentdatenbank und wann passt sie?

Eine Dokumentdatenbank speichert jeden Datensatz als Dokument, das an JSON angelehnt ist. Ein Bestelldokument kann Kundendaten, Produktzeilen und Lieferadresse gemeinsam enthalten. Die MongoDB Dokumentation beschreibt diesen Ansatz, verwandte Daten in ein einziges Dokument einzubetten.

Mit diesem Modell lesen Sie also einen ganzen Datensatz in einem Schritt. Ein Join entfällt. Zudem darf jedes Dokument andere Felder haben. Deshalb eignet sich das Modell für Bereiche wie Produktkataloge, in denen Datensätze nicht gleich aussehen.

Ein Beispiel zeigt das konkret. Das Dokument eines Buches enthält etwa Titel, Autor, Preis und einige Rezensionen. Das Dokument eines Elektrogeräts trägt dagegen Garantiezeit und eine Liste technischer Daten. Beide liegen in derselben Sammlung, denn ihre Felder dürfen sich unterscheiden.

Andererseits kann dieselbe Information in vielen Dokumenten das Aktualisieren erschweren. Ändert eine Marke zum Beispiel ihren Namen, müssen Sie jedes Dokument anpassen, das ihn trägt.

Ein Dokumentmodell ist in diesen Fällen ein guter Kandidat:

• Die Struktur Ihrer Datensätze ändert sich oft.
• Sie lesen einen Datensatz meist als Ganzes.
• Die natürliche Form Ihrer Daten sind verschachtelte Objekte.

Was ist eine Key Value Datenbank und warum ist sie so schnell?

Eine Key Value Datenbank ist das einfachste NoSQL Modell. Sie geben einen Schlüssel an und erhalten den Wert zurück. Das funktioniert wie eine Garderobe: Sie reichen Ihre Nummer herüber und bekommen Ihren Mantel. Der Mitarbeiter schaut nie in den Mantel hinein, er gleicht nur die Nummer ab.

Diese Einfachheit bringt somit Tempo. Systeme wie Redis halten Daten meist im Arbeitsspeicher und greifen sehr schnell per Schlüssel zu. Die Redis Dokumentation stellt die Datentypen vor, etwa Zeichenketten, Listen und Mengen.

Zum Beispiel sind typische Einsatzfelder Sitzungsdaten, kurzlebige Zähler und Caching. Das Thema Caching haben wir bereits in unserem Beitrag über Caching mit Redis und Memcached behandelt, daher wiederholen wir es hier nicht.

Ein weiteres Detail ist zudem die Lebensdauer der Daten. Viele dieser Systeme lassen einen Eintrag nach einer festgelegten Zeit von selbst verfallen. Das ist zum Beispiel für eine Anmeldesitzung oder einen Einmalcode sehr praktisch. Die Einstellungen zur Dauerhaftigkeit unterscheiden sich je nach Produkt. Lesen Sie daher die offizielle Dokumentation, bevor Sie wichtige Daten anvertrauen.

Die Grenze ist ebenso klar. Allerdings ist eine Suche nach dem Inhalt des Werts schwierig. Eine Frage wie "alle Nutzer aus Berlin" ist nicht die Stärke dieses Modells.

Was ist eine Wide Column Datenbank?

Eine Wide Column Datenbank zielt auf sehr große Datenmengen auf vielen Servern. Apache Cassandra ist ein bekanntes Mitglied dieser Familie. Die Cassandra Dokumentation erklärt die verteilte Architektur und das Ziel, keinen einzelnen Ausfallpunkt zu haben.

In diesem Modell verteilen sich die Daten anhand eines Partitionsschlüssels auf die Server. Dann liegen Datensätze mit demselben Schlüssel nebeneinander. Messwerte von Sensoren, Ereignisprotokolle und Zeitreihen passen gut zu diesem Aufbau.

Allerdings gibt es einen Preis. Deshalb müssen Sie Abfragen vorab planen, passend zur späteren Leseform. Freie Joins und Ad hoc Abfragen sind nicht die Stärke dieser Systeme.

Eine weitere Eigenschaft ist die gleichmäßige Verteilung der Schreiblast. Weil das System nicht von einer einzigen Hauptmaschine abhängt, legt ein Ausfall nicht alles lahm. Dieser Vorteil verlangt dennoch sorgfältige Einstellungen zur Konsistenz, denn Kopien können kurz voneinander abweichen.

Kurz gesagt passt eine Wide Column Datenbank zu Lasten, die viel schreiben, schnell wachsen und deren Abfragen vorab bekannt sind. Für eine kleine Firmenwebsite ist sie daher zu schwer.

Was ist eine Graphdatenbank und warum zählen Beziehungen?

Eine Graphdatenbank speichert Daten als Knoten und die Beziehungen zwischen ihnen. Ein Knoten kann eine Person, ein Produkt oder eine Stadt sein. Beziehungen sind Verbindungen wie "folgt", "kaufte" oder "ist befreundet mit". Die Neo4j Dokumentation stellt diesen Ansatz für Daten vor, bei denen Verbindungen am wichtigsten sind.

Zurück zu unserem Vergleich: Dieses Modell ähnelt einer Pinnwand, die Verbindungen statt Datensätze hervorhebt. Wenn Sie den Fäden folgen, beantworten Sie schnell die Frage "Wer sind die Freunde meiner Freunde?".

In einer relationalen Datenbank braucht dieselbe Frage dagegen mehrere Joins. Außerdem gilt: Je tiefer die Kette, desto komplexer und langsamer die Abfrage. Im Graphmodell sind die Beziehungen dagegen selbst die Daten.

Empfehlungssysteme, soziale Verbindungen und die Analyse von Betrugsnetzwerken sind bekannte Einsatzfelder. Ein Beispiel: Der Vorschlag "Kunden, die dies kauften, kauften auch das" folgt den Verbindungen zwischen Kunden und Produkten. Ein Graph speichert diese Verbindungen direkt, daher bleibt die Abfrage kurz.

Eine Produktliste mit wenigen Beziehungen gewinnt dagegen nichts durch eine Graphdatenbank. Sie bringt somit nur zusätzliche Komplexität.

Was ist NoSQL im Vergleich zu SQL und wo liegt der Unterschied?

Der Unterschied zeigt sich auf fünf Achsen, nicht auf einer: Schema, Skalierung, Konsistenz, Abfragesprache und Transaktionen. Die Tabelle fasst also allgemeine Tendenzen zusammen. Es gibt viele Ausnahmen, lesen Sie sie deshalb als Landkarte, nicht als Regel.

Die Lehre aus der Tabelle ist einfach: Keine Seite ist "besser". Jede passt zu anderen Lasten.

Zudem ergänzen wir eine Sicht auf den Entwurf. Im relationalen Modell ordnen Sie die Daten zuerst ohne Wiederholung und schreiben die Fragen später. Im NoSQL Modell kennen Sie dagegen oft die Frage vorab und legen die Daten passend dazu ab. Aus "Was ist NoSQL" wird so die Frage "Welche Fragen stelle ich?".

Zudem nähern sich beide Welten an. Relationale Systeme bieten JSON Unterstützung, und viele NoSQL Produkte haben Abfragesprachen, die an SQL erinnern. Folglich verschwimmt die Grenze stärker als früher.

Was bedeuten ACID und BASE?

ACID steht für vier Eigenschaften, die die Verlässlichkeit von Transaktionen beschreiben. Erstens heißt Atomarität, dass eine Transaktion ganz oder gar nicht abläuft. Zweitens hält Konsistenz die Regeln intakt. Isolation verhindert, dass sich gleichzeitige Transaktionen vermischen. Schließlich sichert Dauerhaftigkeit, dass bestätigte Daten gespeichert bleiben.

Eine Überweisung zeigt das zum Beispiel gut. Geht Geld von einem Konto ab und kommt auf dem anderen nie an, ist das System kaputt. ACID garantiert deshalb, dass beide Schritte als ein Ganzes zählen. Die PostgreSQL Dokumentation erklärt die Isolation gleichzeitiger Transaktionen ausführlich.

BASE fasst den Ansatz zusammen, den viele verteilte NoSQL Systeme verfolgen: grundsätzlich verfügbar, weicher Zustand, letztlich konsistent. Das heißt, das System antwortet immer, aber Kopien zeigen kurz unterschiedliche Werte.

Diese beiden Begriffe tauchen oft auf, wenn man NoSQL mit SQL vergleicht. Der Unterschied ist allerdings nicht absolut. Manche NoSQL Produkte unterstützen ACID Transaktionen, und manche relationale Systeme bieten lockerere Konsistenzmodi. Prüfen Sie daher die Dokumentation des Produkts.

In der Praxis überschätzen Teams oft ihren ACID Bedarf und unterschätzen die Kosten strenger Konsistenz. Stellen Sie die Frage deshalb für jedes Datenstück einzeln. Zum Beispiel verlangt eine Rechnungszeile exakte Richtigkeit. Ein Zähler für Seitenaufrufe darf dagegen einige Sekunden nachgehen.

Was sagt das CAP Theorem in einfachen Worten?

Das CAP Theorem besagt, dass ein verteiltes System drei Eigenschaften nicht gleichzeitig vollständig bieten kann: Konsistenz, Verfügbarkeit und Toleranz gegenüber Netzwerkteilung. Eric Brewer stellte die Idee auf, später bewiesen Gilbert und Lynch sie formal.

Nehmen wir also ein einfaches Beispiel. Stellen Sie sich eine Bäckerei mit zwei Filialen vor. Fällt die Telefonleitung zwischen ihnen aus, müssen Sie sich daher entscheiden. Entweder nehmen beide Filialen eine Weile keine Bestellungen an (Konsistenz bleibt), oder jede verkauft allein und Sie gleichen die Bücher später ab (Verfügbarkeit bleibt).

Das wichtige Detail: Netzwerkstörungen sind in verteilten Systemen unvermeidbar. Die eigentliche Wahl liegt daher während einer Störung zwischen Konsistenz und Verfügbarkeit. Ohne Störung bekommen Sie dagegen beides.

Somit geben Etiketten wie "dieses Produkt ist CP, jenes AP" einen nützlichen ersten Eindruck, ändern sich aber mit der Konfiguration. Machen Sie das Etikett nicht zum einzigen Kriterium.

Das Theorem deutet außerdem auf Kosten im Normalbetrieb hin. Konkret bremst, wer Kopien sofort abgleicht, die Antwort. Wer die Antwort schnell hält, nimmt kurze Abweichungen zwischen Kopien in Kauf. Konsistenz und Tempo stehen also immer in einem Tauschgeschäft.

Ist Schemaflexibilität ein Vorteil oder ein Risiko?

Schemaflexibilität heißt, dass Sie einem Datensatz ein Feld hinzufügen können, ohne eine Tabelle zu ändern. Das ist zudem ein echter Vorteil für schnelle Prototypen, häufig wechselnde Produktmerkmale und Daten aus verschiedenen Quellen. Eine neue Funktion über Nacht auszuliefern fällt dadurch leichter.

Flexibilität hebt jedoch die Disziplin nicht auf. Prüft die Datenbank das Schema nicht, fällt also diese Pflicht an die Anwendung. Nutzt zum Beispiel ein Datensatz das Feld "telefon" und ein anderer "tel", driften die Daten schnell auseinander.

Deshalb wählen reife Teams lieber "Schema in der Anwendung" als "schemalos". Viele Dokumentdatenbanken bieten außerdem Prüfregeln für Felder.

Der praktische Rat lautet:

• Halten Sie die Kernfelder und ihre Typen schriftlich fest.
• Wenden Sie beim Schreiben eine Prüfregel an.
• Bereiten Sie einen Plan vor, um die Struktur alter Datensätze zu ändern.

Prüfregeln werden zudem zu einer gemeinsamen Sprache im Team. So bleibt Flexibilität ein Vorteil und endet nicht im Chaos.

Dennoch kommt der größte Test, wenn das Produkt wächst. In zwei Jahren weiß ein neuer Entwickler vielleicht nicht, welches Feld Pflicht ist. Ein schlichtes Datenwörterbuch ist daher eine sehr wertvolle Investition.

Wie funktioniert die Skalierung bei NoSQL: vertikal oder horizontal?

Vertikale Skalierung heißt, den bisherigen Server durch eine stärkere Maschine zu ersetzen. Dann fügen Sie mehr Speicher und Prozessoren hinzu. Horizontale Skalierung teilt dieselbe Arbeit auf viele Maschinen auf. Im Restaurant gesprochen, tauscht das Erste den Koch gegen einen schnelleren Koch, das Zweite stellt weitere Köche ein.

Viele NoSQL Systeme sind von Beginn an für horizontale Skalierung gebaut. Weil sich die Daten nach Schlüsseln teilen, verteilt ein neuer Server die Last von selbst. In der Hochsaison Server dazuzunehmen und später wieder abzugeben, fällt leichter.

Horizontale Skalierung ist aber nicht umsonst. Kommunikation zwischen Servern, Konsistenzeinstellungen und Betriebsaufwand wachsen nämlich mit. Zudem laufen viele Lasten ohnehin bequem auf einem starken Server.

Messen Sie deshalb zuerst den Bedarf. Passt Ihre heutige Last mit Luft nach oben in eine relationale Datenbank, wäre der Wechsel zu einem komplexen System "für später" womöglich eine verfrühte Optimierung.

Drei Werte helfen beim Messen: Anfragen pro Sekunde, Gesamtgröße der Daten und Ziel für die Antwortzeit. Nähert sich keiner dieser Werte der Grenze Ihres Systems, ist Skalierung allein kein starkes Argument für NoSQL.

Wann sollten Sie SQL wählen?

Sind Ihre Daten eng verknüpft und zählt Richtigkeit am meisten, ist eine relationale Datenbank die sichere Wahl. Zum Beispiel gehören Buchhaltung, Lagerbestand, Abrechnung und Abosysteme dazu. Denn eine halbfertige Transaktion bedeutet hier direkt verlorenes Geld.

Auch Berichte sind eine Stärke von SQL. Daher: Müssen Sie dieselben Daten mit ungeplanten Fragen betrachten, hilft flexibles Abfragen sehr. Die relationale Seite haben wir in unserem PostgreSQL Leitfaden ausführlich beschrieben.

Außerdem sind Alter und Verbreitung von SQL eine Art Sicherheit. Entwickler, Werkzeuge und Schulungen finden Sie viel leichter. Moderne relationale Systeme speichern zudem Dokumentdaten. Die JSON Typen von PostgreSQL erlauben es zum Beispiel, flexible Felder in einer relationalen Tabelle zu halten.

Der richtige Start ist für viele Projekte also einfach: Beginnen Sie mit einer relationalen Datenbank und nutzen Sie ein JSON Feld, wenn ein flexibler Teil nötig ist. Denken Sie an NoSQL, sobald ein echter Bedarf entsteht.

Ein wichtiger Hinweis: "Einfach starten" heißt nicht "nicht vorausdenken". Bündeln Sie den Datenzugriff in einer einzigen Schicht, dann fällt es später deutlich leichter, einen Teil in eine andere Datenbank zu verlagern.

Wann sollten Sie NoSQL wählen?

Passt Ihr Datenmodell klar nicht in relationale Tabellen oder übersteigt Ihre Last einen Server, ist NoSQL ein starker Kandidat. Die entscheidende Frage lautet: Kennen Sie Ihr Zugriffsmuster vorab? Wenn ja, ist somit ein darauf zugeschnittenes Modell oft einfacher und schneller.

Es geht also nicht darum, was modern ist, sondern was zur Last passt. Vier Beispielszenarien machen die Entscheidung greifbar:

• E-Commerce Bestellungen: Hier geht es um Geld und Bestand, daher ist meist eine relationale Datenbank sicher. Das Lesen eines Bestelldokuments klappt aber auch im Dokumentmodell gut.
• Produktkatalog: Jedes Produkt hat andere Merkmale, deshalb passt eine Dokumentdatenbank natürlich.
• Sitzungscache: Für schnelle, flüchtige Daten mit Zugriff per Schlüssel sind Key Value Systeme ideal.
• Soziale Beziehungen: Bei Fragen nach "Freunden von Freunden" glänzt eine Graphdatenbank.

Das sind allerdings nur Beispielszenarien, keine festen Regeln. Datenmenge, Erfahrung Ihres Teams und Ihre Fehlertoleranz entscheiden am Ende.

Im Katalog trägt zum Beispiel jede Kategorie andere Filter. Elektronik hat Prozessor und Display, Kleidung hat Größe und Stoff. Ein Dokumentmodell hält diese Vielfalt in einer Sammlung. Derselbe Katalog mit Tabellen braucht viele leere Spalten oder komplexe Hilfstabellen.

Was ist Polyglot Persistence und reicht eine Datenbank nicht aus?

Polyglot Persistence bedeutet, in einer Anwendung verschiedene Datenbanken für verschiedene Datenarten zu nutzen. "Polyglott" heißt vielsprachig. In der Küche nehmen Sie für jede Aufgabe ein eigenes Messer: Zwiebeln schneiden Sie nicht mit dem Brotmesser.

In einer typischen E-Commerce Plattform liegen die Bestellungen in einer relationalen Datenbank. Der Produktkatalog lebt in einer Dokumentdatenbank. Sitzungen und der Warenkorb Cache bleiben in einem Key Value System. Empfehlungen können aus einem Graphmodell kommen.

Dieser Ansatz bringt Leistung und Flexibilität. Andererseits bringt jede weitere Datenbank zusätzlichen Betriebsaufwand mit: Sie braucht Backups, Überwachung, Sicherheit und Fachwissen.

Wenden Sie den Grundsatz "für jede Aufgabe eine eigene Datenbank" daher nicht blind an. Finden Sie zuerst den Punkt, an dem eine Datenbank wirklich nicht mehr reicht. Auch eine Microservice Entscheidung verlangt ein ähnliches Abwägen, das wir im Beitrag über Microservices Architektur im Vergleich zum Monolithen behandelt haben.

Ist eine Vektordatenbank auch NoSQL?

Eine Vektordatenbank speichert Zahlendarstellungen von Inhalten wie Text, Bild oder Audio (Embeddings). Sie findet die Datensätze, die inhaltlich am nächsten liegen. Weil sie außerhalb des relationalen Modells steht, zählen die meisten Quellen sie als neueres Mitglied zur NoSQL Familie.

Die Ränder dieser Verallgemeinerung sind allerdings unscharf. Manche klassischen Datenbanken können ebenfalls ein Vektorfeld und eine Ähnlichkeitssuche ergänzen. Deshalb ist es gesünder, die Vektordatenbank als eigene Kategorie zu betrachten.

Wir vertiefen das hier nicht, denn das Thema hat einen eigenen Beitrag. Wie das Konzept arbeitet, lesen Sie in unserem Leitfaden zu Embeddings und Vektordatenbanken.

Die Kernaussage dieses Abschnitts ist einfach: Braucht eine KI Anwendung eine Ähnlichkeitssuche, kommt eine Vektordatenbank ins Gespräch. Für normale Anwendungsdaten bleiben die vier Modelle von oben die Grundoptionen.

Bedenken Sie außerdem, dass die Vektorsuche selten allein steht. Meist dient sie als Hilfsschicht, die die eigentlichen Datensätze in einer anderen Datenbank findet. Eine Vektordatenbank steht also neben dem Hauptspeicher, nicht an seiner Stelle.

Welche Irrtümer über NoSQL sind verbreitet?

Viele Entscheidungen beginnen mit einer falschen Annahme. Auch rund um die Frage "Was ist NoSQL" kursieren einige Mythen. Berichtigen wir die vier, die wir am häufigsten hören.

• "NoSQL ist immer schneller als SQL." Die Geschwindigkeit hängt von Last und Modell ab. Ein falsch genutztes NoSQL System kann langsamer laufen als ein gut abgestimmtes relationales.
• "NoSQL kennt keine Transaktionen." Manche Produkte unterstützen Transaktionen über mehrere Datensätze. Der Umfang hängt von Produkt und Konfiguration ab, prüfen Sie daher die aktuelle Dokumentation.
• "NoSQL braucht kein Schema und keinen Entwurf." In Wahrheit ist der Entwurf wichtiger, weil er dem Abfragemuster folgt.
• "NoSQL und SQL ersetzen einander." Meistens ergänzen sie sich.

Das gemeinsame Problem dieser Annahmen ist die Vorstellung vom einen richtigen Werkzeug. Jedes Modell ist ein Kompromiss. Was Sie in einer Richtung gewinnen, zahlen Sie in einer anderen. Dieses Gleichgewicht zu sehen, ist der erste Schritt zu einer guten Architekturentscheidung.

Ein weiterer Irrtum lautet: "Große Firmen nutzen NoSQL, also sollten wir es auch tun." Deren Last und Teams unterscheiden sich stark von Ihren. Wer ihre Lösung kopiert, übernimmt auch ihre Probleme.

Wie sieht eine Checkliste für SQL oder NoSQL aus?

Wenn Sie verstanden haben, was ist NoSQL, können Sie zur Entscheidung übergehen. Beantworten Sie diese Fragen der Reihe nach. Halten Sie jede Antwort schriftlich fest, dann wird auch die Diskussion im Team kürzer.

1. Welche natürliche Form haben die Daten: Tabelle, Dokument, Schlüssel und Wert oder Beziehungsnetz?
2. Welche Abfragen führen Sie am häufigsten aus, und kennen Sie sie vorab?
3. Ist ein halbfertiger Vorgang tragbar, oder brauchen Sie exakte Richtigkeit wie bei Geld und Bestand?
4. Würden einige Sekunden Inkonsistenz ein Problem verursachen?
5. Übersteigt das Datenvolumen einen Server, oder ist das nur eine Vermutung?
6. Welche Datenbank kennt Ihr Team bereits, und wer trägt den Betriebsaufwand?
7. Stehen Pläne für Backup, Sicherheit und Überwachung?
8. Wie sieht der Migrationsweg aus, falls Sie das Datenmodell später ändern müssen?

Sagen die meisten Antworten "verknüpft, konsistent, auswertbar", neigen Sie zu SQL. Lauten sie dagegen "flexibel, hohes Volumen, bekanntes Zugriffsmuster", neigen Sie zu NoSQL. Gemischte Antworten sprechen für den Polyglot Ansatz.

Wenden Sie die Liste erneut an, sobald das Projekt wächst. Die Antworten von heute können sich in einem halben Jahr ändern. Teams mit einem Entscheidungsprotokoll wissen später, warum sie so gewählt haben, und ändern die Richtung bewusst.

Wie hängen API und DevOps mit der NoSQL Entscheidung zusammen?

Die Wahl der Datenbank trifft man nie allein. Sie arbeitet unter der API Ihres Backends, daher sollte das Datenmodell zu dem passen, was die API liefert. Diese Verbindung haben wir im Beitrag Was ist eine API ausführlich behandelt.

Dazu kommt die Betriebsseite. Eine Datenbank in Produktion zu bringen, zu sichern, zu aktualisieren und zu überwachen kostet echte Arbeit. Die Kultur, diese Abläufe zu automatisieren, ist das Thema unseres Beitrags Was ist DevOps.

Verwaltete Cloud Datenbanken können diesen Aufwand verringern, haben aber weiterhin Kosten und Grenzen. Die Unterschiede der Servicemodelle finden Sie in unserem Leitfaden zu IaaS, PaaS und SaaS.

Auch Sicherheit gehört zum Ganzen. Planen Sie Zugriffsrechte, Netzwerkzugang und die Verschlüsselung der Backups von Anfang an. Die Datenbank ist der wertvollste und am häufigsten angegriffene Teil einer Anwendung. Den offiziellen Sicherheitsleitfaden zu lesen, ist am ersten Tag die beste Gewohnheit.

Kurz gesagt entsteht eine NoSQL Entscheidung gemeinsam mit Code, Infrastruktur und Teamkapazität.

Wie gehen wir bei der Datenbankwahl in einem individuellen Softwareprojekt vor?

Wir beginnen ein Projekt mit einer Frage, nicht mit einer Technikliste: Wie verhalten sich die Daten dieser Aufgabe? Zunächst erfassen wir die Abläufe, danach die Lese und Schreibmuster. Anschließend wählen wir die einfachste Lösung und ergänzen eine zweite Datenbank nur bei Bedarf.

In den meisten Projekten genügt ein relationaler Kern. Für Teile, die Flexibilität oder sehr schnellen Zugriff brauchen, fügen wir ein Hilfssystem hinzu. So vermeiden wir unnötige Komplexität.

Planen Sie eine individuelle Software, können wir diese Entscheidungen gemeinsam klären. Sehen Sie sich dazu unsere individuelle Softwareentwicklung an.

Bedenken Sie: Keine Datenbank beschleunigt ein Projekt allein. Das richtige Modell, ein guter Abfrageentwurf und regelmäßige Wartung müssen zusammenspielen.