Keine Kompromisse mehr: Im Umgang mit der neuesten Version der Datenbank von Exasol bieten neue Features eine Alltagserleichterung. Im Kurzinterview mit Jens Graupmann, SVP Product & Innovation bei Exasol werden die Kundenvorteile zu Elastizität und Skalierbarkeit sowie zur Trennung von Storage und Compute kurz erläutert.
Was bietet der neue Funktionsumfang und welche Hintergründe haben Exasol dazu angetrieben?
Mit der Einführung der neue Version hat Exasol die Art und Weise revolutioniert, wie es Anforderungen an Elastizität in der Datenanalyse gerecht wird. Dies ermöglicht es den Exasol-Benutzern nun, nahtlos zusätzliche Ressourcen einer aktiven Datenbank zuzuweisen, um ihre Geschäftsanforderungen zu erfüllen.
Ein Blick auf unsere bestehende Benutzerbasis und den Markt zeigt, dass es einige sehr typische Workload-Muster gibt:
1. Konstante 24/7-Nutzung
2. Reine on-demand Nutzung
3. Permanente 24/7-Grundlast mit Lastspitzen sowohl mit regelmässig wiederkehrenden als auch nicht spontanen Situatione. Dieser Fall kann als Kombination aus 1+2 angesehen werden.
Was sind die größten Veränderungen für Kunden, die bisher eine Exasol Version ohne Multi-Cluster-Unterstützung einsetzen? Was ist besonders aufregend an der Art und Weise, wie sie nun mit Exasol arbeiten können?
Die Exasol-Datenbank ermöglicht nun die dynamische Verwaltung mehrerer Cluster, die auf dieselben Daten zugreifen können und anpassungsfähiges Skalieren entsprechend der Benutzeranforderungen bietet.
Stellen Sie sich einen internationalen Exasol-Benutzer mit zwei verschiedenen Teams vor, die separate Ressourcen benötigen:
- BI-Team – Standard-Reporting, rund um die Uhr in Betrieb
- Loading...Data Science-Team – Training & Anpassungen der ML-Modelle nur während der Geschäftszeiten aktiv
Dank des in neue Version eingeführten Multi-Cluster-Ansatzes ist es nun möglich, dedizierte Cluster oder Rechenressourcen für jedes Team mühelos zuzuweisen. Das BI-Team könnte beispielsweise rund um die Uhr einen mittelgroßen Cluster (M) nutzen, während das Data Science-Team während der Geschäftszeiten ausschließlich auf einen extra-großen Cluster (XL) zugreifen könnte. Diese unabhängigen Rechenressourcen verhindern Störungen zwischen den Teams und ermöglichen eine präzisere Planung und Budgetierung, während sie dennoch auf denselben Daten arbeiten.
Anschaulich zeigt es die folgende Abbildung:
Angenommen, man plant die Einführung von Self-Service-BI-Funktionen für Analyse und Visualisierung. Mit dem Multi-Cluster-Ansatz bieten sich zwei Alternativen, die den Unternehmen mehr Flexibilität geben:
- Die Rechenressourcen eines Clusters zu erhöhen und Self-Service-BI auf einen diesen Cluster zuweisen.
- Und zum Zweiten das Aufsetzen eines zusätzlichen Clusters für diese Arbeitslast
Wie werden die neuen Funktionen aus technischer Sicht implementiert?
Zunächst haben wir Rechenleistung von Datenspeicherung entkoppelt.
Die folgende Abbildung zeigt den architektonischen Entwurf einer Exasol-Datenbank vor der Veröffentlichung der neue Version.
In dieser Konfiguration läuft jede Datenbank auf einem einzigen Cluster, der aus mehreren Knoten besteht. Jeder dieser Knoten verfügt über lokalen Speicher (lokale Festplatten), um seinen Segment der Daten zu speichern. Dieser Ansatz wird üblicherweise als “Shared Nothing” bezeichnet.
Jetzt sieht es anders aus: Da auf den lokalen Speicher nur ein direkt angeschlossener Server zugreifen kann und moderne Cloud-Konzepte hoch skalierbare und kostengünstige Objektspeicheroptionen bieten, ist Exasol nun dazu übergegangen, Objektspeicher für die dauerhafte Datenspeicherung zu nutzen.
Zwei Vorteile bieten Objektspeicher: Zum einen sind sie kostengünstiger als lokaler Speicher und zum anderen sind Objektspeicher stark optimiert, um mit der Menge der I/O-Anfragen zu skalieren. Allerdings – und das gilt es zu beachten – geht es einher mit der Herausforderung, dass Objektspeicher im Vergleich zu lokal angeschlossenen Festplatten eine höhere Latenzzeit aufweisen.
Um dies zu lösen, nutzt Exasol leistungsstarke, lokale (ephemeral) SSD-Speicher der virtuellen Server, um Daten zu zwischenspeichern, da dies eine geringe Latenz bietet. In der Regel umfasst Daten, die von Exasol-Serverprozessen verwendet werden, aber auch die Daten selbst.
Die Trennung des Speichers gewährleistet den Betrieb der Exasol-Datenbank mit mehreren unabhängigen Clustern, die auf dieselben Daten zugreifen können. Ein Cluster übernimmt die Rolle als Hauptcluster und hostet das Exasol Transaction Management System (TMS). Das TMS wiederum stellt die ACID-Konformität sicher und ermöglicht verschiedene Operationen auf allen Clustern unter Wahrung der Datenbankkonsistenz.
Mit der Einführung eines neuen SQL-Befehls wird die mühelose Migration von inaktiven Benutzersitzungen zwischen den Sub-Clustern möglich – für die User schafft das eine ganz neue Transparenz des Setups.
Wann und wo wird dies für die Kunden verfügbar sein?
Aufgrund der unterschiedlichen Objektspeicher-Implementierungen der einzelnen Public Cloud-Anbieter treiben wir die Verfügbarkeit schrittweise voran. Derzeit ist das neue Angebot für AWS verfügbar. Plattformspezifische Speicherimplementierungen und Optimierungen für Google GCP und Microsoft Azure folgen in den kommenden Monaten.
Die ebenfalls bereits verfügbare Version für on-premise-Installationen unterstützt keine Multi-Cluster-Architektur und arbeitet nach wie vor mit lokalen Festplatten.
Welche weiteren Funktionalitäten und Verbesserungen können wir erwarten?
Es ist noch einiges zu erwarten. Highlights sind …
- Erweiterter Datentyp “Timestamp“
- Verbesserte Kompilierzeiten
- Verbesserungen für Situationen mit hoher Nebenläufigkeit
- Ein verbesserter Optimizer für komplexe Joins
- Zone Maps für verbesserte Speichereffizienz (in Verbindung mit Partitionierung)
- Ein neues Sicherungskonzept (Snapshot-Backups)
Sprechen Sie mit dem Kundenbetreuer von Exasol oder testen Sie das Accelerator-Programm für drei Monate und fünf Terabyte kostenlos.