LUCHS.AT - Development - SQL oder NoSQL? Datenhaltung für Hipster

Relationale Datenbanken sind das Zugpferd der Informationstechnologie. Bis vor einigen Jahren hatten sie kaum Konkurrenz und konnten unbehelligt ihren Aufgaben nachgehen. Klassisch kommuniziert man mit diesen Systemen über die Structured Query Language (SQL), und alle Daten müssen eine Struktur aufweisen (oder zumindest in ein oder mehrere Felder passen). Seit 1998 oder 2009 fasst man gerne nicht-relationale Datenbanken unter dem Begriff NoSQL zusammen. Man könnte genauso gut QL als Bezeichnung wählen, denn man darf diese Datenbanksysteme natürlich trotzdem abfragen. Zum allem Überfluß kommt man ohne Struktur bei beiden Varianten nicht aus. Was ist nun das Kriterium für die Wahl zwischen den Architekturen?

Bevor man sich populären Code herunterläd und beschließt, dass das nun die Antwort auf alle Fragen ist, sollte man sich mit dem Ziel der Datenbanksysteme beschäftigen. Relationale Datenbanken orientieren sich an dem ACID Prinzip (Atomicity, Consistency, Isolation, Durability). Man wünscht sich Transaktionen, die ganz oder gar nicht ausgeführt werden. Die Datenbank soll nach jeder Operation in einem konsistenten Zustand sein. Parallel ausgeführte Transaktionen sollen sich nicht beeinflussen. Bereits abgeschlossene Transaktionen sollen Bestand haben. All diese Bedingungen können ein Datenbanksystem in Bedrängnis bringen, wenn es um sehr viele Operationen in kurzer Zeit geht. Performance ist dann das Schlüsselwort.
Nicht-relationale Systeme verzichten auf einen Teil von ACID, um effizienter zu sein. Wie genau das umgesetzt wird, hängt stark von der verwendeten Software ab. Mangels Standards muss man die Kriterien von Applikation zu Applikation vergleichen.
Damit ist man nicht schlauer als vorher, allerdings hängt es sehr stark von den Daten ab, die man verarbeiten möchte. Man kennt üblicherweise die Struktur der Daten und kann sie erfassen oder konvertieren. Als weiteres Kriterium kommen die Anzahl und das Verhältnis von Schreib-/Lesezugriffen ins Spiel. Klassisch ist viel Schreiben und Lesen immer ein Problem. Dies gilt auch für moderne „QL“ Datenbanken. Entwickler bedienen sich gerne bei Caches, um Zugriffe vor erneuten Abfragen zu bewahren. Das kann der datenbankeigene Query Puffer oder auch eine Look-Up-Tabelle im Speicher sein. Man kann sogar nicht-relationale Systeme dafür verwenden.

Es spricht nichts gegen einen hybriden Ansatz. Daten sind nicht immer gleich, und man hat meist sehr viele davon. Speziell bei Dokumenten sind nicht-relationale Datenbanken oft besser geeignet, weil sie wissen was der Inhalt bedeutet. Verwendet man mehr als eine Tabelle in einer SQL Datenbank, so muss man ohnehin mit Identifikatoren arbeiten. Ob diese jetzt eine andere Tabelle oder ein anderes Datenbanksystem referenzieren, das ist in der vernetzten Welt eigentlich egal. Wir wissen wie das geht. Fragen Sie doch einfach mal.