Wir erleben eine verblüffende Renaissance. Datenbanken, die lange als antiquiert verspottet wurden, sind plötzlich der Liebling der Branche. Jahre nachdem Kommentatoren Datenbanken praktisch für tot erklärt hatten, hat eine neue Generation von Start-ups die Aufmerksamkeit der Wall Street auf sich gezogen. IT-Verantwortliche tun sich jedoch nach wie vor schwer damit, ihre bestehenden Workloads effizient auf diese Systeme zu migrieren.
Der Anbieter-Lock-in bei Datenbanken ist legendär. Kein anderer Sektor übt einen derart großen Einfluss auf seine Nutzer aus. Natürlich hält der Anbieter-Lock-in die Kunden von der bestehenden Technologie abhängig. Gleichzeitig hält er aber auch den Wettbewerb und neue Anbieter fern. Der CEO von Snowflake beklagte einst öffentlich, wie schwer es ist, in diesen Markt einzudringen, als er sagte: „Teradata has [made] it bloody hard to move off their platform.“
Mit dem Aufkommen der Datenbankvirtualisierung (DBV) – nicht der Datenvirtualisierung – ist eine neue Methodik auf den Plan getreten. DBV verspricht, den Anbieter-Lock-in bei Data-Warehouse-Technologien aufzubrechen. Wie gut lässt sie sich einsetzen, und wie können IT-Verantwortliche die Technologie bewerten? Hier sind fünf Dinge, die man über DBV wissen sollte.
Siehe auch: Wie Datenbankvirtualisierung bei der Migration eines Data Warehouse in die Cloud hilft
1) Wie funktioniert DBV?
Eine DBV-Plattform sitzt zwischen Datenbank und Anwendungen. Sie ermöglicht es Anwendungen, die für eine Datenbank geschrieben wurden, nativ auf einer anderen Datenbank zu laufen. Alle Abfragen und Kommunikationsvorgänge werden in Echtzeit übersetzt. So können beispielsweise für Teradata geschriebene Anwendungen direkt auf Microsoft Azure Synapse ausgeführt werden und „wissen“ nicht einmal, dass sie nicht mehr auf Teradata laufen.
DBV arbeitet vollständig transparent; Anwendungen sollen gar keine oder nur minimale Anpassungen erfordern. Das umfasst nicht nur Standard-SQL, sondern auch proprietäre Erweiterungen. Damit die Lösung in der Praxis erfolgreich ist, müssen außerdem Loader, Treiber und Dienstprogramme unterstützt werden.
Da DBV-Systeme die Übersetzung von Abfragen und Daten übernehmen, können sie mit relativ geringem Overhead arbeiten. Die eigentliche Datenverarbeitung findet stets im Data Warehouse selbst statt und nutzt dessen Fähigkeiten zur massiv parallelen Verarbeitung (MPP).
2) Wann sollte man DBV statt einer herkömmlichen Migration einsetzen?
Bei einer herkömmlichen Migration werden der gesamte vorhandene SQL-Code sowie Treiber, Tools und Dienstprogramme durch ihre Gegenstücke im neuen Zielsystem ersetzt. Für kompakte Data-Warehouse-Systeme mit einer geringen Zahl von Anwendungen kann dies der bevorzugte Ansatz sein. Auch Data Marts mit nur einer begrenzten Zahl von Nutzern kommen dafür infrage.
Bei komplexen Enterprise Data Warehouses (EDW) kann DBV eine herkömmliche Migration jedoch deutlich übertreffen. DBV bewältigt die Migration von Workloads in einem Bruchteil der Zeit, der Kosten und des Risikos.
3) Kann DBV meinen Workload abdecken?
Manche Workloads nutzen spezialisierte Funktionen in großem Umfang. Andere wiederum verwenden Funktionen, die aus der Zeit vor den Standardisierungsbemühungen stammen. Mit anderen Worten: Kein Data-Warehouse-Workload gleicht dem anderen. Dadurch kann es schwierig sein, den Abdeckungsgrad eines DBV-Systems einzuschätzen.
Eine vollständige Dokumentation der unterstützten Funktionen scheint wünschenswert, ist aber tatsächlich nicht besonders hilfreich. Die meisten Kunden können nicht prägnant beschreiben, welche Funktionen ihre Workloads derzeit nutzen. Noch komplizierter wird die Sache dadurch, dass die ursprünglichen Autoren von Abfragen oder Funktionen häufig nicht mehr im Unternehmen sind.
Das muss der Einführung von DBV jedoch nicht im Wege stehen. Da DBV mit einem geringen Einführungsrisiko verbunden ist, eignet sich die Technologie sehr gut für Proof-of-Concept-(POC)-Implementierungen. Kunden müssen ihre Anwendungen nicht ändern, um DBV zu nutzen. Sie können ihre tatsächlichen Anwendungen direkt in einem POC testen.
Ein POC kann dann schnell alle fehlenden Abdeckungen ermitteln. Wichtig ist dabei: Eine Abdeckung von 100 % wäre zwar wünschenswert, in der Regel reichen jedoch hohe 90er-Prozentwerte aus. Die verbleibenden Probleme zu beheben, erfordert oft nur einen vernachlässigbaren Aufwand.
Siehe auch: Die besten Business-Intelligence-Softwarelösungen
4) Wie unterscheidet sich DBV von Datenvirtualisierung?
Datenvirtualisierung ist ein verwandter, aber doch deutlich anderer Ansatz. Damit Datenvirtualisierung erfolgreich sein kann, müssen zunächst alle Anwendungen neu geschrieben werden und einen abstrakten SQL-Dialekt übernehmen. Erst dann verhindert sie einen künftigen Anbieter-Lock-in. Die wichtigsten Einsatzbereiche sind „Greenfield“-Szenarien, bei denen bestehende Anwendungen nicht berücksichtigt werden müssen.
DBV bricht dagegen den bestehenden Anbieter-Lock-in auf. Die Anwendungen bleiben unverändert. Mit der Zeit kann dies zu einer vielfältigen Mischung unterschiedlicher Anwendungstechnologien führen. Das muss jedoch kein großes Problem darstellen und wird durch die Einführung neuer Datentechnologien mehr als ausgeglichen.
5) Kann DBV EDWs auf beliebige Technologien umstellen?
Alle paar Jahre stellt eine neue Technologie die Vormachtstellung von Enterprise-Data-Warehouse-Systemen infrage. Oft übertrifft der Neuling den bestehenden Stack in einer wesentlichen Hinsicht. So könnte die neue Technologie beispielsweise besser skalierbar sein. Eine andere Technologie könnte die gemeinsame Nutzung von Daten vereinfachen. Wieder eine andere spricht eher Open-Source-Entwickler an.
In der Regel können Expertenteams maßgeschneiderte Lösungen entwickeln, um Workloads vom EDW auf die meisten neuen Technologien zu verlagern. Je größer jedoch die funktionalen Unterschiede sind, desto mehr Software-Engineering ist erforderlich, um diese Systeme zu betreiben. So ist die Migration eines EDW auf ein NoSQL-System möglicherweise technisch machbar, wirtschaftlich aber nicht immer sinnvoll.
Damit DBV erfolgreich sein kann, müssen Quelle und Ziel in wesentlicher Hinsicht ähnlich sein. Eine gleichwertige Funktionalität ist jedoch nicht erforderlich. DBV kann das Fehlen der meisten fortgeschrittenen Funktionen wie Stored Procedures, Makros oder sogar nicht unterstützter Datentypen ausgleichen. Derzeit sind Cloud-native-PaaS-Lösungen im Kontext von DBV am erfolgreichsten.
Den richtigen Ansatz für Migrationen wählen
Bei der Auswahl eines neuen Zielsystems für ein bestehendes EDW müssen viele Faktoren berücksichtigt werden. Einer davon wird häufig übersehen: der Migrationsansatz. DBV ist äußerst effektiv darin, den Anbieter-Lock-in bei Legacy-Data-Warehouses aufzubrechen.
Indem IT-Verantwortliche den Migrationsansatz in ihre Wahl des Zielsystems einbeziehen, können sie eine schnelle Einführung optimieren und gleichzeitig Risiko und Kosten kontrollieren.
Siehe auch: Tech-Prognosen für 2022: Cloud, Daten, Cybersicherheit, KI und mehr
Über den Autor:
Mike Waas ist Gründer und CEO von Datometry