Mittwoch, 08.06.2016 In the Code: Daten banken für Analytik im Vergleich Laufzeiten von Abfragen im spezifischen Setup des Kunden, in Minuten: Wichtigste Abfragen links / bekannte Langläufer rechts. MS SQL Server 2016 (SQL 16), SAP HANA (HANA), SAP Sybase IQ 1.5.4 (SY15), SAP Sybase IQ 16 (SY16) sowie Oracle 12c (ORA) Welche Datenbank eignet sich am besten für Analytics und Reporting? Simon Hefti weiss, wie man das herausfindet und stellt fest: Microsoft SQL Server 2016 lässt die Konkurrenz in bestimmten Setups weit hinter sich. Datenbasierte Wertschöpfung ist zu einem zentralen Erfolgsfaktor in allen Industrien geworden. Gleichzeitig stellt sie auf allen Ebenen bedeutende Herausforderungen, die Kultur, Daten und Technologie betreffend. Heute bleiben wir aber auf der Technologie-Ebene und stellen die Frage: "Welche Datenbank passt am Besten zu meinem Reporting- und Analyse-Anforderungen und begleitet mich zuverlässig über die nächsten drei bis fünf Jahre"? Wie die Einschränkung auf Reporting und Analytik zeigt, steht hier die Select- oder Lese- Performance im Vordergrund. Natürlich sind Schreib-Operationen für die datenbasierte Genehmigung des Verlags.1
Wertschöpfung ebenfalls relevant. Im Gegensatz zu Anforderungen von grossen Systemen, die täglich viele hundert Millionen Transaktionen verarbeiten müssen, können für Reporting und Analytik oft Massenoperationen und bulk inserts benutzt werden. Das verringert die Anforderungen an die Schreib-Operationen verglichen mit den Lese-Operationen beträchtlich. Eine Krankenkasse mit 3 Millionen Versicherten hat sich genau diese Frage gestellt und die Produkte Oracle, SAP HANA, SAP Sybase IQ und SQL Server in ihrem spezifischen Setup verglichen. Die Erfahrung zeigt, dass Herstellerangaben und standardisierte Benchmarks nur eine grobe Einordnung der verschiedenen Produkte erlauben. Es ist wie beim Massanzug: man muss die verschiedenen Produkt-Kandidaten anziehen und am eigenen Leib testen. Das ist aber auf Grund der Datenmenge (die grösste Tabelle der Krankenkasse enthält mehrere Milliarden Zeilen) und der benötigten Hardware gar nicht so leicht zu bewerkstelligen. Wie also geht man an eine solche Frage heran? Mit Daten natürlich. Ein erfolgsversprechender Ansatz ist, Systeme in der Cloud aufzubauen und Vergleichsmessungen mit synthetischen Daten durchzuführen. Damit dies sinnvoll gelingt, muss man einige Punkte beachten. Das Datenmodell muss mit dem Datenmodell übereinstimmen, das man im Zielsystem verwenden will. Dies betrifft vorallem die Beziehungen zwischen den Entitäten, da die Verknüpfungen (Joins) bezüglich Performance die Knacknuss für alle Hersteller sind. Zweitens müssen die synthetischen Daten die gleichen statistischen Eigenschaften aufweisen wie die produktiven Daten (technisch: wenn die Verteilung zufällig wäre, könnte das getestete System mit gut ausbalancierten Bäumen und damit nahe am Optimum arbeiten). Drittens muss die Anzahl Zeilen dem produktiven Setup entsprechen, woraus wiederum vorallem eine Herausforderung bei den Verknüpfungen entsteht. Dies ist eine nicht zu unterschätzende Anforderung, da die Datenmengen gross sind. Die Breite der Tabellen ist für moderne Produkte in der Regel weniger wichtig, da sich der spaltenbasierte Ansatz breit durchgesetzt hat. Es reicht also, sich in der Simulation auf einige wenige Attribute pro Tabelle zu beschränken. Um eine gute Aussagekraft der Resultate zu erreichen, ist der Aufbau einer Leiter zwingend, die es ermöglicht, Resultate von unterschiedlichen Systemen miteinander in Beziehung zu setzen. Dies gilt insbesondere für den Vergleich von On-Premise Systemen mit Systemen in der Cloud. Der Goldfisch Übrigens - wie ist denn gute Performance zu definieren? Hier bietet sich der Goldfisch- Genehmigung des Verlags.2
Ansatz an. Der Goldfisch hat bekanntlich eine Aufmerksamkeitsspanne von 9 Sekunden und übertrifft uns Menschen damit. Braucht das System länger als 10 Sekunden für die Antwort auf eine Frage, zum Beispiel ausgedrückt durch das Ändern eines Filters in einem Bericht, so wird der Gedankenfluss des Benutzers unterbrochen. Häufige Unterbrüche führen dazu, dass die Analyse gar nicht gemacht wird. Aber zurück zu den angesprochenen Vergleichsmessungen. Die Messungen wurden mit Maschinen mit 16 Kernen und 120-240 GB RAM durchgeführt. Dabei schnitt wie gesagt im ganz spezifischen Setup der erwähnten Krankenkasse Microsoft SQL Server 2016 überraschend gut ab. In der Tabelle oben sind die Laufzeiten der verschiedenen Produkte für die wichtigsten Abfragen (Tabelle Links) und für bekannte Langläufer (Tabelle rechts) dargestellt. Weitere Erkenntnisse aus den Vergleichsmessungen: SAP HANA ist für wichtige Abfragen vergleichbar schnell, ist aber bei Queries mit vielen Verknüpfungen gefordert. Die Performance-Steigerung von SQL Server 2014 zu 2016 ist beeindruckend. Sowohl bei Oracle und bei SQL Server bringt die Einführung von Aggregate Awareness eine Steigerung der Abfrage-Performance um den Faktor 10. Funktionale Verbesserungen Für die Krankenkasse waren neben der Performance die verschiedene funktionale Verbesserungen ebenfalls wichtig: Die Möglichkeit, Aggregate Awareness einzusetzen: Das steigert erstens die Performance. Fast wichtiger aber ist zweitens, dass keine Data Marts eingeführt werden müssen. Genauer gesagt: die Data Marts sind für den Benutzer nicht sichtbar. Aggregate Awareness bedeutet ja gerade, dass das System selbst entscheidet, ob für die Beantwortung einer Abfrage voraggregierte Daten verwendet werden können, oder ob das Resultat von Grund auf berechnet werden muss. Aus Benutzersicht ist das ein Schlüsselerfolgsfaktor, da Data Marts immer ein Teilbild zeigen, hier aber der Blick auf die gesamte Organisation interessiert. Das klassische Beispiel ist die Incentivierung des Verkaufs. Wenn der Data Mart nur Abschlüsse berüchsichtigt, nicht aber den Geschäftserfolg, der mit diesen Abschlüssen erzielt wurde, so ist die Gefahr einer Fehlsteuerung vorhanden. Die Möglichkeit der Kopplung der Zugriffskontrolle mit dem bestehenden Identity und Access Management System auf Basis von Active Directory (der Row Level Security). Die Monitor &Suspend Funktionen auf Basis des Query Store, die es ermöglicht, Benutzer zu identifizieren und auszubilden, die das System über die Massen beanspruchen. Die Unterstützungsfunktionen bei der kontinuierlichen Verbesserung der Abfragen. Der um einen Faktor 7 tiefere Platzbedarf, der sich aus der starken Kompression ergibt. Sind die gerade beschriebenen funktionalen Anforderungen und die nicht-funktionalen Anforderungen (z.b. Performance) erst einmal geklärt, so stellt sich die wahrscheinlich wichtigste Frage: ist eine Migration möglich, und in welchem Zeitraum? Genehmigung des Verlags.3
Dass die Migration möglich ist, war für die erwähnte Krankenkasse schnell einmal klar - dies insbesondere, da sie eine einzelne Komponente der Datenstrecke und nicht die gesamte Datenstrecke betrifft. Während der erfolgreich in 12 Wochen durchgeführten Migration sind mir verschiedene Punkte aufgefallen: Die aus den Vergleichsmessungen erwartete Performance-Steigerung wurde realisiert. Verschiedene kleinere Bugs in den Release Candidates von SQL Server 2016 konnten identifiziert und im Rahmen des Technology Adaption Programms (TAP) in enger Zusammenarbeit mit Microsoft behoben werden. Natürlich müssen SQL Queries und T/SQL Prozeduren angepasst werden, und das Verhalten bei Transaktionen und Fehlern ist anders. Insgesamt ist der Migrationsaufwand aber überschaubar. Besonders lustig ist, dass die Funktion count() des SQL Servers auf dem Datentyp int basiert und damit mit 4 bytes auf 2 Milliarden limitiert ist. Aber die Lösung ist nicht weit: mit count_big() können auch Zeilen in Tabellen gezählt werden, die grösser sind. Erstaunlicherweise wird UTF-8 noch nicht unterstützt. Letztendlich führten die besprochenen Aspekte (Performance, funktionale Verbesserungen und Migration in kurzer Zeit) die Krankenkasse zum Entscheid, den SQL Server 2016 als Reporting- und Analyse-Datenbank produktiv einzusetzten, noch bevor der finale Release des Produkts verfügbar ist. Erfahrungen zusanmmengefasst: Was für den Anzug recht ist, muss billig sein für die zentralen Systeme, die den wertvollen Rohstoff Daten verwalten - es braucht passgenaue Systeme. Die Cloud ermöglicht es, in kurzer Zeit und auf einfache Weise Vergleichssysteme bereitzustellen, die den realitätsnahen Performancevergleich ermöglichen. Mit dem Einsatz von synthetischen Daten ist der Einsatz der Cloud mit Blick auf sensitive Daten unbedenklich. Eine allfällige Migration ist - wenn sie sorgfältig geplant ist - zügig durchführbar. Der Continuous Innovation Ansatz des Herstellers reduziert die Risiken des Wechsel auf einen 1.0er Release deutlich, da viele der Komponenten des Produkts bereits bekannt und produktiv eingesetzt werden. Über den Autor Simon Hefti ist Gründungspartner von D ONE, dem Beratungsunternehmen für datenbasierte Wertschöpfung. In seiner Dissertation hat er den Ursprung des Sonnenwindes erforscht. Als Unternehmer und Business Scientist begleitet er Kunden aus unterschiedlichsten Branchen in technischen, konzeptionellen und organisatorischen Fragen. Genehmigung des Verlags.4
Mehr zu diesem Thema: In the Code: Internet of Things? Aber sicher! In the Code: Der Kampf gegen den grossen Dreckklumpen In the code: Erfolgreiche Big-Data-Programme Genehmigung des Verlags.5