Der Ruf des Marketing wird immer lauter: Große Datenmengen lassen sich mit relationalen Datenbanken (RDB) nicht beherrschen. Ist das Ende der RDB damit abzusehen?

Ich kann diese Einstellung absolut nachvollziehen: In einer gigantischen Datenmenge nach Antworten zu suchen ist aufwendig. Zentral gepflegte oder zumindest koordinierte Daten-Massen erzwingen geradezu Bottlenecks. Ein bischen kommen die NoSQL Datenbanken daher wie der Elektromotor gegenüber dem Verbrennungsmotor: einfach mit wenigen Einzelteilen gegen komplexe, aufwändige Technik mit Jahrzehnte langem Entwicklungsaufwand. David gegen Goliath. Und dazu: Dem Neuen haftet aus Vertriebssicht immer auch die Verheißung nach neuem Umsatz an.

Aber das sind doch eher oberflächliche Betrachtungen. Wir haben einige Projekte, in denen wir täglich mehrere Millionen Datensätze erfassen und sichern müssen. Und dort ist bereits völlig klar, was wir mit den Daten anfangen wollen und was nicht. Ein Beispiel: Es handelt sich um Zeitreihen mehrerer zehntausend Datenpunkte, die im 15 Minutentakt eine Sammlung von Informationen am Messpunkt bereit stellen. Millionen Datensätze täglich. Die Anwendung: Zu irgendeinem späteren Zeitpunkt kann eine beliebige Zeitreihe wichtig werden. Wir wissen zum Erfassungszeitpunkt nicht wann und wir wissen nicht welches Zeitfenster interessant werden wird. Wir brauchen alles. Und später dann brauchen wir es schnell.

Unsere Optionen: Eine verteilte Zeitreihen-Datenbank wie Cassandra, die auf mehreren 10 oder 100 Knoten läuft haben wir nicht genommen. Für das Auffinden und die Auswertung eines Zeitfensters einer einzelnen Zeitreihe braucht es schlicht keine Verteilung. Der Hardware-Aufwand wäre deutlich größer gegenüber einer einzelnen Appliance auf einem einzelnen, gestandenen Rechner. Stattdessen verwenden wir eine klassische relationale Datenbank mit einigen sorgfältig erstellten Indizes. So lässt sich jedes Fenster in jeder beliebigen Datenreihe schnell auffinden.

Klar ist, RDBMS ist nicht immer die beste Lösung. Andere unserer Projekte arbeiten mit Zeitreihendatenbanken, NoSQL, einige auch heterogen. Daten in verschiedenen Formen vorzuhalten ist eine gute Lösung, wenn Geschwindigkeit gefragt ist. Im praktischen Betrieb ist Normalisierung manchmal nur eine Theorie.

Und das ist genau der Punkt: think before code! Was wollen wir erreichen? Danach wählen wir die Mittel. Wir legen einen großen Wert darauf die freie Wahl zu haben und auch später noch möglichst flexibel die Mittel zum Einsatz zu bringen. Anstelle sich auf ein Lager der Fronten eines Paradigmenstreits zu werfen, schauen wir, dass wir die Anbindung in beide Welten mit einfachsten Mitteln gewährleisten können. Bei uns ist es der SCADA-Proxy, der vom Streaming über zeitreihenbasierte Datenbanken bis hin zu relationalen Datenbanken alle erdenklichen Datensenken befüllt – auch gern parallel und verteilt. Zielgerichtete Applikationen lösen wir mit expliziten Maßnahmen. Der Weg zur Nutzung von klassischen Big Data Analyse-Werkzeugen und -Techniken wie Hadoop, Spark, R, MapReduce, Datawarehouse, BusinessIntelligence und so weiter steht nichts im Wege. Analysen lassen sich so vorausschauend ermöglichen ohne den Datenfluss in produktiven Systemen zu gefährden.

Fazit: Es gibt immer dann keine einfachen Antworten, wenn die Anforderung nicht klar ist. Auch bei Big Data macht es viel Sinn sich über die Anforderungen und Ziele im Klaren zu sein.

Fun Fact am Rande: NoSQL gibt es schon ziemlich lange – wie in diesen Jahren gewohnt halt nur nicht unter diesem relativ neuen Namen. Die ersten Datenbanken waren alles andere als relational. Und der Elektromotor ist älter als der Verbrennungsmotor. Die beiden älteren Entwicklungen profitieren aktuell durch Verbesserungen in der Speichertechnik.