Bigdata, NoSQL, was ist das überhaupt? Intermezzo

Ich hab eine Frage bekommen: braucht man NoSQL aktuell in der Wirtschaft wirklich?

BigData und NoSQL sind die logischen Ergebnisse der aktuellen Entwicklung: die Datenmengen werden immer größer, weil immer mehr Prozesse technisiert werden (ELSTER, SEPA etc.), immer mehr Daten generiert werden (Megapixel, FullHD, 3D, etc.) und immer mehr Ereignisse elektronisch erfasst werden (Smart Meter, Bio-Monitoring, Web-Logging, etc.). Das Problem ist, dass die Speichertechnologie hierbei nicht mitkommt. Ein Speichermedium zeichnet sich zur 2 Eigenschaften aus:

1. Kapazität
2. IO-Leistung, aufgeteilt in
   a. Anfragen pro Sekunde
   b. Durchsatz pro Sekunde

Während 1. in den letzten 15 Jahren um den Faktor 4.000 gestiegen ist, hat sich 2. nur um den Faktor 10 verbessert. Die Erfahrung zeigt, dass Festplatten immer zu 80-90% voll sind, unabhängig von der Größe (stimmt vom meiner ersten 20MB Festplatte bis zu meinen heutigen 3 TB). Dies bedeutet, dass wir heutzutage 400 mal langsamer sind, als vor 15 Jahren, wenn wir alle unsere Daten lesen wollen. Deshalb ist es unklug zu glauben, man kann die gleiche Vorgehensweise, wie vor 15 Jahren verwenden. NoSQL sorgt dafür, dass man weniger Anfragen pro Sekunde benötigt, um die gleiche Leistung zu erzielen, während die BigData-Produkte den Durchsatz pro Sekunde durch massive Parallelisierung erhöhen.

Berechtigt ist die Frage natürlich, was das ganze der Wirtschaft bringt. Genau die gleiche Frage wurde vor 70 Jahren gestellt, als die ersten Rechenmaschinen aufkamen. Und es ist klar, "a fool with a tool is still a fool". NoSQL macht Dinge wie eBay, Facebook, Google erst möglich. BigData schafft es, zeitnah Informationen zu liefern. Ich weiß von einem Beispiel eines großen Telefonanbieters, bei dem in einer Vorstandssitzung eine Frage aufkam. Diese konnte die Technik mit klassischem SQL nach 4 Tagen beantworten. Nach der Umstellung auf BigData konnten ähnliche Fragen in 5 Minuten beantwortet werden. Bei Scooter Attack hatte ich ähnliche Erfolge erzielen können, dort aber von 2 Minuten runter auf 5 Sekunden. Und Speicherkapazität von 9 GB auf 0,5 GB. Es geht auch gar nicht so sehr um die Frage, ob NoSQL/BigData besser oder schlechter ist, als klassisches SQL. Es geht vielmehr darum, welches für was am besten geeignet ist. Früher gab es nur SQL; jetzt kann man zwischen zwei Möglichkeiten wählen, die beide ihre Stärken und Schwächen haben. Was man daraus macht, das bleibt einem immer noch selbst überlassen.

Bigdata, NoSQL, was ist das überhaupt? Teil 1: KeyValueStores

Bis vor nicht allzu langer Zeit war mit "Datenbank" meist eine relationale Datenbank gemeint, die über SQL angesprochen werden konnte, wie beispielsweise MySQL, PostgreSQL oder Microsofts SQL-Server, um nur einige zu nennen. SQL ist das "Esperanto der Datenbanken", wodurch es für Software-Entwickler leichter ist, mehrere Datenbanken zu unterstützen, da alle die gleiche Sprache sprechen. Eine SQL-Datenbank hat Tabellen, ähnlich denen einer Tabellenkalkulation: die Datensätze sind die Zeilen und die Felder der Datensätze sind die Spalten. Jeder Datensatz hat die gleichen Felder, beispielsweise "Vorname" und "Nachname" in einer Kundentabelle und jedes Feld hat einen Typ, der für alle Datensätze gleich ist. Diese Art der Datenspeicherung ist für Menschen sehr leicht verständlich, da es die natürliche Art ist, wie man auch auf einem Blatt Papier eine Liste von Personen anlegen würde.

Diese Speicherung in Tabellen mit festen Feldern hat leider einen Nachteil: wenn man ein Feld hinzufügen möchte, muss üblicherweise die Tabelle kopieren, um bei jedem Datensatz Platz für das neue Feld zu schaffen; genauso beim Ändern oder Löschen eines Feldes. Während eines solchen Kopiervorganges ist die Datenbank nicht (oder zumindest nicht voll) verfügbar. Bei wenigen Datensätzen oder eine hausinternen Datenbank, die nachts nicht genutzt wird, sind solche Ausfälle kein Problem. Ist man ein Internet-Startup mit einer guten Idee, so ärgert dieses Problem jedoch gleich mehrfach: zum einen muss man 24/7 verfügbar sein, da das Internet nicht schläft. Dazu kommt eine oftmals rapide steigende Zahl an Nutzern und damit viele Datensätze. Als Startup entwickelt man noch kräftig an der Software, so dass die Struktur sehr oft geändert werden muss. Hierzu ein Beispiel: die besten Android Apps haben mehr als 100 Millionen Downloads. Legt man für jeden dieser Nutzer ein Kundenkonto an und jedes Kundenkonto belegt 1 Kilobyte an Speicher, so benötigt man 100GB Speicherplatz. Nicht sonderlich viel in der heutigen Zeit. Das Problem ist, dass eine aktuelle Festplatte im Idealfall etwa 15 Minuten benötigt, um diese Datenmenge zu lesen oder zu schreiben. Ein RAID-System ist natürlich entsprechend schneller, aber auch da wird man kaum unter eine Minute kommen.

In der Praxis sind die Zeiten bedingt durch die Umrechnung und Neu-Indizierung eher ein gutes Stück länger. Hier kommt das erste NoSQL ins Spiel: Key-Value-Stores (KVS), auf Deutsch: Speicherung von Schlüssel-Wert-Paaren. Statt jedem Datensatz eine starre Anzahl an Feldern zuzuordnen, legt man eine variable Anzahl solcher Schlüssel-Wert-Paare ab. Also beispielsweise "Vorname = Kurt", "Nachname = Huwig" usw. Natürlich belegt dies mehr Speicherplatz, da die Feldnamen in jedem Datensatz nochmal drin stehen. Wie man oben gesehen hat, ist Speicherplatz aber nicht das Problem. Will man bei einem KVS ein neues Feld hinzufügen, braucht man an den bestehenden Daten nichts zu ändern sondern legt bei neuen Datensätzen einfach das neue Feld an. Oder fügt alten Datensätze das Feld im laufenden Betrieb hinzu und sobald man damit fertig ist, kann es genutzt werden. Ein Nachteil soll aber verschwiegen werden: bei SQL-Datenbanken ist es möglich, Datenbankfelder als notwendig zu definieren, so dass keine Datensätze angelegt werden können, in denen das Feld nicht gesetzt ist. Dies ist bei KVS nicht möglich, aber in der Praxis auch kein Problem: wurde früher vom Client direkt auf die Datenbank zugegriffen (Two-Tier) wird heute in der Regel eine Middleware eingesetzt, die alle Zugriffe des Clients bearbeitet und selbst mit der Datenbank spricht (Three-Tier oder Multi-Tier). Damit ist es leicht möglich, diese Konsistenzprüfung von der Datenbank in den Middle-Tier zu verlegen und hat damit mehr Möglichkeiten der Prüfung, als herkömmliche SQL-Datenbanken anbieten.