Kommentar von Thomas Scholz, Snowflake Computing So verändert die Cloud Datenbankarchitekturen

Neue Datenbankgenerationen machen den Unterschied zwischen Systemen, die für analytische Workloads optimiert sind und solchen, die sich am besten für transaktionale Aufgaben eignen, nicht obsolet. Daran ändert auch die Cloud nichts – sie hält aber Möglichkeiten bereit, Analytics-Lösungen noch besser zu machen.

Anbieter zum Thema

INFOMOTION GmbH

Snowflake Computing GmbH

Fivetran Germany GmbH

Fast alle Datenbankhersteller haben in den vergangenen fünf bis zehn Jahren massiv in die Modernisierung ihrer Lösungen investiert. In jüngster Zeit sorgen sie darüber hinaus dafür, dass diese Lösungen auch in der Cloud implementiert und genutzt werden können.

Auslöser für diese Entwicklung war jedoch nicht die Cloud, sondern die Zunahme der Datenmengen, die für die Unternehmen interessant sind und wahre Schätze für zusätzliche Wertschöpfung bergen. Social Media und Big Data gehören seitdem begrifflich und konzeptionell zusammen. Doch das war erst der Anfang der Datenexplosion. Das Internet der Dinge (IoT) und die in diesem Zusammenhang zu verarbeitende Informationsmenge wird alles Bisherige in den Schatten stellen. Damit stellt sich jedoch automatisch die Frage nach Performance und Speicherkapazitäten.

Die Cloud löst nicht alles

Cloud könnte jetzt fast reflexartig die Antwort auf diese Frage lauten. Und es stimmt ja. Die Cloud bietet praktisch unbegrenzte Rechen- und Speicherressourcen. Doch leider ist damit das Problem nur zum Teil gelöst. Denn die Frage, wie die Datenexplosion zu bewältigen ist, hängt nicht nur mit Ressourcen, sondern auch mit der Architektur der Lösungen zusammen, mit deren Hilfe die Informationen bearbeitet werden. Im Grunde ist dieses Problem so alt wie moderne Datenbankmanagementsysteme (DBMS) selbst.

Als die ersten kommerziellen DBMS-Lösungen auf den Markt kamen, hatten ihre Entwickler Nutzungsszenarien im Kopf, wie sie – bis heute – für das tägliche Arbeiten mit ERP-Lösungen typisch sind. Die Anwender interessieren sich bei Abfragen gegen die Datenbank für Einzeldatensätze, zum Beispiel für den Kunden X. Welche und wie viele Felder zu diesem Kunden, wie zum Beispiel Name, Adresse, Vertriebsregion, Einkäufe, Umsätze etc. gleichzeitig angezeigt werden sollen, ist eine Frage der Oberflächengestaltung. Dieses Szenario ist typisch für die bekannte zeilenorientierte Abfrage und die Menge der abzurufenden Daten bleibt dabei durch die Zahl der Felder begrenzt. Speicher- und Performanceprobleme haben die hierfür konzipierten Datenbanken bis heute sehr gut im Griff.

Je mehr jedoch die in den Datenbanken gespeicherte Gesamtmenge anwuchs, umso größer wurde das Interesse an komplexen Abfragen, die typischerweise für Entscheider relevant sind: Wie viel Umsatz wurde im vergangenen Quartal in Bayern erzielt? Wie viel in Hessen? Wie viel in unserer Niederlassung in Spanien? Für solche Abfragen müssten bei einer zeilenorientierten Speicherung erst einmal alle in Frage kommenden Datensätze aufgerufen werden, um dann in den entsprechenden Spalten Summen zu bilden. Hat ein Unternehmen viele Kunden, dann sind solche Abfragen sehr aufwendig, sowohl was die benötigte Zeit als auch die abzufragende Datenmenge betrifft.

Eine Frage der Architektur

Vor diesem Hintergrund war es nur logisch, dass neue DBMS-Systeme den Markt eroberten, die eine spaltenorientierte Speicherung erlaubten und damit für analytische Workloads geeignet waren. Auch „Zwischenlösungen“ wie das „Star Schema“ oder das davon abgeleitete und verfeinerte „Snowflake-Schema“, in denen Dimensionen wie unterschiedliche Zeiträume in der Form eines Sterns oder einer Schneeflocke um die managementrelevanten, in Spalten gespeicherten Informationen wie Umsatz angeordnet wurden, brachten hier keine dauerhafte Abhilfe. Sobald Analysen und transaktionsorientierte Abfragen gleichzeitig erfolgten, stellten sich wieder die alten Probleme hinsichtlich Geschwindigkeit und Speicherverbrauch ein.

Als ab Anfang der Nullerjahre immer mehr ehemals getrennte Funktionsbereiche wie CRM (transaktionsorientiert) und Business Intelligence (analytischer Workload) integrierter Bestandteil von ERP-Lösungen wurden, blieb deshalb eine einheitliche Datenbank ein schöner Traum. In der Regel verwendeten die Unternehmen weiterhin ein DBMS für transaktionsorientierte Aufgaben und ein weiteres für Analysen. Gerade bei so genannten Join-Operationen, also bei der Verknüpfung von Tabellen können letztere durchaus bis zu 100-mal schneller arbeiten als transaktionsorientierte Systeme mit zeilenorientierter Speicherung.

Nun gibt es seit einigen Jahren neue DBMS-Generationen, die insbesondere bei analytischen Aufgaben beeindruckende Leistungssteigerungen zeigen. Möglich wird dies einmal durch spaltenorientierte Speicherung, zum anderen aber durch den Einsatz von Rechenclustern zur parallelen Analyseberechnung. Durch SSDs und viel Hauptspeicher ist es möglich, Zugriffszeiten zu minimieren und sogar sehr große Datenmengen speicherresident vorzuhalten. Die meisten dieser Lösungen sind mittlerweile auch in der Cloud implementiert, in der Speicher im Grunde ohne Grenzen zur Verfügung steht. In Summe sind die Kosten jedoch weiterhin sehr hoch, sowohl in der aufgerüsteten On-premise-Version solcher Lösungen als auch in der Cloud-Variante.

Mehr Flexibilität

Analytische Workloads unterliegen nun aber typischerweise teils beträchtlichen Auslastungsschwankungen. Bei der Dimensionierung der entsprechenden Systeme muss daher immer von der maximalen Auslastung ausgegangen werden. Angesichts dieser Situation stellen sich Entscheider zunehmend die berechtigte Frage, warum sie einen Rolls Royce kaufen sollen, wenn es die meiste Zeit über auch der Passat täte. Es wäre dann doch sinnvoller, die Luxuskarosse nur bei Bedarf zu mieten. Auch in Zukunft werden die Unternehmen daher aus Kostengründen für unterschiedliche Workloads unterschiedliche Lösungen nutzen, und dies unabhängig von der Frage, ob diese Lösungen im eigenen Rechenzentrum implementiert sind oder als Service aus der Cloud bezogen werden.

Diese Trennung ergibt umso mehr Sinn, je mehr alle Eigenschaften der Cloud, nicht nur die aus der Sicht des einzelnen Kunden unbegrenzte Verfügbarkeit von Rechen- und Speicherressourcen von solchen analytischen Lösungen – genutzt werden. Dazu gehört insbesondere die Elastizität der Cloud. Von dieser lässt sich aber nur profitieren, wenn ein neues Designprinzip in den DBMS-Systemen Einzug hält: Die Trennung von Speicher- und Rechenkapazitäten, damit beide unabhängig voneinander bedarfsgerecht skaliert werden können.

Aus alt mach neu

Bei traditionellen DBMS-Architekturen hingegen – und das gilt auch für deren Cloud-Varianten – ist das Verhältnis zwischen Speicher- und Rechenressourcen starr. Große Datenmengen lassen sich zwar auf verschiedene Server aufteilen, die jeder für sich Teilergebnisse liefern, um daraus ein Gesamtresultat zu ermitteln. Doch das Verhältnis zwischen Speicher und Rechenleistung auf jedem dieser Server lässt sich eben nicht bedarfsgerecht steuern. Daran ändert sich auch dann nichts, wenn ein solches Data Warehouse mit traditioneller Architektur in der Cloud implementiert ist.

Das hat erhebliche Konsequenzen für das Arbeiten mit großen Datenmengen. Zum einen muss die Ressourcenausstattung immer für die maximale Last ausgelegt werden, selbst wenn es nur wenige Spitzenzeiten gibt, wie sie etwa für das saisonale Geschäft von Unternehmen typisch sind. Zum anderen lässt sich die Arbeitslast zwar parallelisieren, wie oben beschrieben, doch das Problem der sogenannten Nebenläufigkeit bleibt davon unberührt. Das bedeutet, dass die Anzahl der gleichzeitig möglichen Datenanalysen, ohne dass die Leistung merklich zurückgeht, beschränkt ist.

Die Zahl der Datenanalysen steigt jedoch in den Unternehmen. Nicht mehr die Datenspezialisten allein wollen die vorhandenen Informationen untersuchen, sondern auch immer mehr Fachanwender, ob aus dem Marketing, dem Vertrieb oder auch der Produktion, Wartung und Qualitätssicherung. In einer DBMS-Architektur, in der die Speicher- und Rechenebenen voneinander getrennt sind, lässt sich für jede dieser Abfragen ein eigenes Rechencluster implementieren. Jedes davon lässt sich vorkonfigurieren, sodass es bei Bedarf gestartet, aber auch wieder abgeschaltet werden kann. Durch detailliertes Wissen über die Daten müssen diese nicht als Ganzes aufwendig und zeitraubend kopiert werden, um ausgewertet werden zu können. Das erst erlaubt eine rein bedarfsorientierte Ressourcennutzung, die sich entsprechend abrechnen lässt. Leistung und Kosten stehen in einem Verhältnis, dass der digitalen Wirtschaft angepasst ist.

Architektur 2.0

Wollen die Unternehmen den Schatz heben, den die Digitalisierung durch die Explosion der Datenmengen bereithält, müssen sie das Problem der Nebenläufigkeit angehen. Solange die Architektur ihrer Data Warehouses jedoch nicht Cloud-nativ ist, können sie es nicht lösen. So wie der Übergang von transaktionalen zu analytischen Workloads einen Architekturwechsel nötig gemacht hat, so ist es auch beim Übergang in die Cloud. Das bedeutet nicht das Ende von DBMS-Lösungen speziell für Analysen, im Gegenteil: Mit der passenden Architektur können sie ihre Vorteile erst richtig ausspielen.

(ID:45300156)