NoSQL-Databases-Software

Im Datenblatt steht viel. Was im Betrieb wirklich zählt, ist meist weniger glamourös.

Skalierung und Verteilung

Der Hauptgrund, warum Betriebe zu NoSQL greifen, ist oft die horizontale Skalierung: Statt einen Server immer größer zu kaufen, verteilst du die Last auf mehrere Maschinen. Achte darauf, wie die Software das macht. Muss sie beim Hinzufügen eines Knotens gestoppt werden? Verteilt sie die Daten automatisch oder musst du das manuell steuern? Frag konkret nach, was passiert, wenn ein Knoten ausfällt, während gerade geschrieben wird.

Konsistenzmodell

Hier liegt der größte Unterschied zu relationalen Datenbanken. Viele NoSQL-Systeme arbeiten mit "eventual consistency": Eine Änderung ist nicht sofort auf allen Knoten sichtbar, sondern erst nach kurzer Zeit. Für einen Warenkorb mag das egal sein, für einen Kontostand nicht. Kläre für deinen Fall, ob du starke Konsistenz brauchst oder ob eine kurze Verzögerung akzeptabel ist. Manche Systeme lassen dich das pro Abfrage einstellen.

Abfragesprache und Indizes

Schau dir an, wie du Daten aus dem System holst. Manche haben eine eigene Abfragesprache, manche lehnen sich an SQL an. Prüfe, ob du auf allen Feldern, die du wirklich abfragst, einen Index anlegen kannst. Ohne passenden Index wird die Abfrage bei wachsender Datenmenge langsam, und das merkst du erst, wenn es zu spät ist.

Backup und Wiederherstellung

Ein Backup zu erstellen ist die eine Sache. Es zurückzuspielen die andere. Frag in der Demo nicht "gibt es Backups", sondern lass dir zeigen, wie lange eine Wiederherstellung eines konkreten Datenbestands dauert und ob der Betrieb dabei stehen muss.

Monitoring und Betrieb

Du willst sehen, wie das System sich verhält: Speicherverbrauch, langsame Abfragen, Auslastung der Knoten. Ohne diese Sicht betreibst du eine Blackbox. Prüfe, ob das mitgeliefert wird oder ob du zusätzliche Werkzeuge brauchst.

Passt der Datentyp zu deinem Fall

Bevor du irgendein Tool anschaust, beschreibe auf einer Seite, wie deine Daten aussehen und welche fünf Abfragen du am häufigsten machst. Diese Beschreibung entscheidet mehr über die richtige Wahl als jedes Featureversprechen. Wenn du das nicht formulieren kannst, ist es zu früh für die Toolauswahl.

Selbst betreiben oder als Managed Service

Du kannst eine NoSQL-Datenbank auf eigenen Servern betreiben oder als gehosteten Dienst mieten. Der Eigenbetrieb gibt dir Kontrolle und meist niedrigere laufende Kosten, verlangt aber Wissen für Betrieb, Updates und Ausfallsicherung. Der gehostete Dienst nimmt dir diese Arbeit ab, kostet dafür laufend mehr und bindet dich an einen Anbieter. Rechne ehrlich, ob du das Betriebswissen im Haus hast oder aufbauen willst.

Wer bedient es später

Lass die Software in der Demo von der Person bedienen, die später damit arbeitet, nicht vom Vertrieb und nicht vom Chef. Wenn dein Entwickler nach zehn Minuten nicht selbst eine Abfrage schreiben und ein Ergebnis bekommen kann, ist das ein Warnsignal.

Reifegrad und Gemeinschaft

Schau, wie lange es das System schon gibt, wie aktiv daran entwickelt wird und wie gut du im Netz Antworten auf konkrete Probleme findest. Bei einem Problem um drei Uhr nachts hilft dir eine große Nutzergemeinschaft mehr als ein glänzendes Datenblatt.

Ausstieg mitdenken

Frag dich vor dem Einstieg, wie du wieder herauskommst. Kannst du deine Daten in einem gängigen Format exportieren? Je proprietärer das Datenformat, desto teurer wird ein späterer Wechsel.

Ich nenne dir hier bewusst keine Zahlen, weil sie je nach Anbieter und Datenmenge stark schwanken. Wichtiger ist, dass du verstehst, woraus sich die Kosten zusammensetzen.

Die gängigen Modelle

Bei quelloffenen Systemen ist die Software selbst oft kostenlos, du zahlst für die Infrastruktur und gegebenenfalls für einen Supportvertrag. Bei gehosteten Diensten zahlst du meist nach Ressourcen: Rechenleistung, Speicherplatz, Datenübertragung. Manche rechnen nach der Zahl der Anfragen ab. Genau dieses Modell wird gerne unterschätzt, weil die Rechnung mit der Nutzung wächst und nicht mit einer festen Nutzerzahl.

Kosten, die im Angebot nicht stehen

Die reine Lizenz oder Miete ist selten der größte Posten. Rechne mit:

• Arbeitszeit für Einrichtung und Datenmigration aus dem Altsystem
• Betriebsaufwand, wenn du selbst hostest (Updates, Überwachung, Ausfallbehebung)
• Kosten für den Datenverkehr, besonders wenn Daten zwischen Regionen bewegt werden
• Speicherplatz, der bei manchen Modellen getrennt von der Rechenleistung berechnet wird
• Aufbau von Wissen im Team, wenn die Technik neu für euch ist

Wie du realistisch rechnest

Schätze deine Datenmenge nicht für heute, sondern für in zwei Jahren. Bei nutzungsabhängigen Modellen bitte den Anbieter um eine Beispielrechnung mit deinen echten Zahlen, nicht mit einem Beispielszenario. Und lies das Kleingedruckte dazu, was passiert, wenn du ein Kontingent überschreitest: Wird gedrosselt oder einfach weiter berechnet.

NoSQL gewählt, weil es modern klingt

Der häufigste Fehler: Ein Betrieb hat sauber strukturierte Daten mit klaren Beziehungen und wählt trotzdem NoSQL, weil es zeitgemäß wirkt. Dann fehlen ihm die Werkzeuge, die eine relationale Datenbank für genau diesen Fall mitbringt, und er baut sie mühsam nach. NoSQL ist ein Werkzeug für bestimmte Probleme, kein Fortschritt an sich.

Das Datenmodell zu spät durchdacht

Bei NoSQL steckt viel Arbeit im Datenmodell, weil dir das System keine feste Struktur aufzwingt. Wer einfach drauflos speichert, hat nach einem Jahr Datensätze mit unterschiedlichen Feldern für dieselbe Sache, und keine Abfrage findet mehr alles. Überleg dir das Modell vorher, auch wenn das System es dir nicht abverlangt.

Indizes vergessen

In der Testphase mit wenig Daten läuft alles schnell. Im Produktivbetrieb mit Millionen Datensätzen kriecht dieselbe Abfrage, weil kein Index existiert. Teste immer mit einer realistischen Datenmenge, nicht mit einem Dutzend Beispieldatensätzen.

Backup nie zurückgespielt

Ein Betrieb hatte jahrelang Backups laufen. Als der Ernstfall kam, stellte sich heraus, dass die Wiederherstellung nie geprobt worden war und im entscheidenden Moment nicht funktionierte. Übe die Wiederherstellung mindestens einmal, bevor du dich darauf verlässt.

Konsistenz falsch eingeschätzt

Ein Team ging von sofort sichtbaren Änderungen aus, das System arbeitete aber mit Verzögerung. Ergebnis: Nutzer sahen kurz nach dem Speichern noch alte Daten und meldeten das als Fehler. Kläre das Konsistenzverhalten, bevor du auf falscher Annahme aufbaust.

Ich bin kein Anwalt, und was hier steht, ersetzt keine Rechtsberatung. Aber ein paar Punkte solltest du kennen, bevor du Daten in eine NoSQL-Datenbank legst.

Datenschutz und Serverstandort

Sobald du personenbezogene Daten speicherst, greift die DSGVO in Deutschland und Österreich, in der Schweiz das dortige Datenschutzgesetz. Kläre, wo die Daten physisch liegen. Bei gehosteten Diensten von Anbietern außerhalb der EU brauchst du eine Rechtsgrundlage für die Übermittlung. Frag konkret nach, in welchen Rechenzentren die Daten gespeichert und verarbeitet werden.

Auftragsverarbeitung

Nutzt du einen gehosteten Dienst, verarbeitet der Anbieter Daten in deinem Auftrag. Dafür brauchst du einen Vertrag zur Auftragsverarbeitung. Ohne diesen Vertrag fehlt dir die rechtliche Grundlage. Seriöse Anbieter stellen ihn bereit, du musst nur danach fragen und ihn prüfen.

Löschkonzept

Die DSGVO gibt Betroffenen ein Recht auf Löschung. Bei NoSQL kann das kniffliger sein als gedacht, wenn dieselben personenbezogenen Daten in mehreren Dokumenten oder über mehrere Knoten verteilt liegen. Überleg dir schon beim Datenmodell, wie du einen Datensatz vollständig und nachweisbar löschst.

Nachweisbarkeit

Du musst belegen können, wer wann auf welche Daten zugegriffen hat und wie sie gesichert sind. Prüfe, ob das System Zugriffe protokolliert und ob du Rollen und Rechte fein genug vergeben kannst, damit nicht jeder alles sieht.

Aufbewahrungsfristen

Je nach Datenart gelten steuer- und handelsrechtliche Aufbewahrungsfristen. Kläre, ob deine Datenbank Daten so lange und unverändert vorhalten kann und wie du das im Zweifel nachweist.

Schritt 1: Datenlage aufschreiben

Beschreibe auf einer Seite, wie deine Daten aussehen, wie sie wachsen und welche fünf Abfragen du am häufigsten brauchst. Das ist die Grundlage für alles Weitere.

Schritt 2: Prüfen, ob NoSQL überhaupt passt

Geh ehrlich durch: Sind deine Daten stark strukturiert mit klaren Beziehungen, ist womöglich eine relationale Datenbank die bessere Wahl. Passen deine Daten schlecht in Tabellen oder brauchst du echte horizontale Skalierung, spricht das für NoSQL. Triff diese Entscheidung, bevor du Tools ansiehst.

Schritt 3: Grundtyp festlegen

Entscheide anhand deiner Datenlage, welcher der vier Grundtypen passt. Erst danach schaust du dir konkrete Produkte in dieser Kategorie an.

Schritt 4: Betriebsmodell klären

Entscheide, ob du selbst betreiben oder einen gehosteten Dienst nutzen willst. Sei dabei ehrlich zu dir, was dein Team wirklich leisten kann.

Schritt 5: Zwei bis drei Kandidaten testen

Richte einen echten Test ein, mit einer realistischen Datenmenge und deinen fünf wichtigsten Abfragen. Lass die Person testen, die später damit arbeitet. Miss, wie lange die Abfragen dauern und wie viel Aufwand die Einrichtung war.

Schritt 6: Backup und Wiederherstellung proben

Spiel im Test einmal ein Backup zurück und miss die Dauer. Wenn das nicht sauber funktioniert, streich den Kandidaten.

Schritt 7: Kosten mit echten Zahlen rechnen

Bitte um eine Beispielrechnung mit deiner geschätzten Datenmenge für in zwei Jahren, inklusive aller Nebenkosten. Vergleich die Kandidaten auf dieser Basis, nicht auf Basis des Einstiegspreises.

Schritt 8: Compliance abhaken

Kläre Serverstandort, Vertrag zur Auftragsverarbeitung und Löschkonzept, bevor du unterschreibst. Diese Punkte lassen sich später nur schwer nachrüsten.

Wenn du diese Schritte in dieser Reihenfolge durchgehst, triffst du die Entscheidung aus deiner Datenlage heraus und nicht aus dem Datenblatt eines Anbieters. Das ist der Unterschied zwischen einer Datenbank, die in zwei Jahren noch trägt, und einer, die du dann teuer ablösen musst.