Neues über Datenbanken — Herbst 2018

Bloß nicht den Überblick verlieren: Hier sind die wichtigsten Datenbank-Neuigkeiten der letzten Monate.

Das Revival der großen SQL-Ideen

Die Einführung von SQL-Konzepten in NoSQL-Systeme ist momentan ein wiederkehrendes Muster. Diesmal stechen Apache Flink mit der Einführung der Match_Recognize-Klausel, und Couchbase mit der Ankündigung, in der kommenden Version Window-Funktionen anzubieten, hervor. SQL ist jedoch mehr als nur eine leistungsfähige Abfragesprache. Constraints, Transaktionen und Transaktionsisolation sind ebenfalls integrale Bestandteile von SQL. In dieser Ausgabe möchte ich mich daher darauf konzentrieren, wie NoSQL Systeme derzeit versuchen sich den Konsistenzgarantien von SQL-Datenbanken anzunähern.

Um den Hintergrund dieses Trends zu verdeutlichen, möchte ich zwei Zitate aus Rick Negrin’s (von MemSQL) aktuellem Artikel „Thank You for Your Help NoSQL, but We Got It from Here“ bemühen:

In diesem Satz steckt eine wichtige Nachricht, die leicht zu übersehen ist: Diese Unternehmen haben maßgeschneiderte Systeme für ihre eigenen, sehr spezifischen Probleme entwickelt. Wenn man die Ressourcen dafür hat, werden diese Systeme diese speziellen Anforderungen wohl auch besser erfüllen als ein Produkt von der Stange. Und natürlich lässt man alles weg, die man nicht braucht.

Und dann haben diese Unternehmen begonnen über Ihre Lösungen zu reden…

Der Rest der Geschichte ist bekannt: NoSQL-Hersteller haben ihre Produkte als die Zukunft der Datenbanken gepriesen. Techniker sind von neuen Konzepten ohnehin immer begeistert, insbesondere wenn sie mit einem zugkräftigen Schlagwort wie NoSQL kommen.

Viele NoSQL-Nutzer haben jedoch eines übersehen: Jedes dieser NoSQL-Systeme war dazu gedacht, ein sehr konkretes Problem zu lösen – und nur dieses Problem. NoSQL-Systeme sind keine generischen Datenbanken, die eine Anforderung besser erfüllen als die Konkurrenz. Sie sind viel eher wie Zirkustiere, die jeweils nur einen Trick beherrschen – also Ein-Trick-Ponys. Diesen einen Trick beherrschen sie zwar gut, dafür kann man sonst wenig damit anfangen.

Zurück ins Jahr 2018. Heute können wir beobachten, wie NoSQL-Hersteller ihren Ponys weitere Tricks beibringen – meist Tricks, die SQL-Datenbanken schon lange beherrschen. Die Einführung von Multi-Dokument-Transkationen mit MongoDB 4.0 – wenn auch sehr eingeschränkt – ist wohl das beste Beispiel der letzten Monate. Ganz generell haben NoSQL-Systeme bezüglich der Datenkonsistenz einen langen Weg hinter sich. Der aktuelle Trend ist, dass selbst verteilte Datenbanken wieder verstärkt auf Konsistenz achten.

Google Spanner ist auch ein solches System, bei dem Datenkonsistenz wichtiger als Verfügbarkeit ist. Natürlich hat Google dann öffentlich über diesen Ansatz gesprochen und letztendlich geschah das Unvermeidliche: Open-Source-Systeme haben die Idee aufgegriffen und sind wie Pilze aus dem Boden geschossen. Die oben zitierte Geschichte wiederholt sich also.

Und was läuft diesmal falsch? Mit dieser Frage hat sich Daniel Abadi in seinem Artikel „NewSQL database systems are failing to guarantee consistency, and I blame Spanner“ beschäftigt. Der Artikel gibt eine kurze Einführung, warum strikte Konsistenz wünschenswert ist, warum NoSQL-Systeme sie ursprünglich aufgegeben haben und wie neuere Systeme wieder nach starker Konsistenz in verteilten Umgebungen streben. Das Fazit ist, dass Systeme, die versuchen Google Spanner nachzubilden, nicht dieselben Konsistenzgarantien wie Spanner geben können, weil Spanner sich dafür auf hoch präzise Zeitquellen wie Atomuhren verlässt. Wenn man das Spanner-Konzept aufgreift, ohne solche Zeitquellen zu verwenden, kann man nicht dieselbe Konsistenz und Verfügbarkeit wie Spanner garantieren. Laut Abadi machen einige Systeme genau diesen Fehler.

Einmal mehr stellt sich also die Frage: Welche Datenbank soll man nehmen? Mittlerweile hat sich zwar die Meinung durchgesetzt, dass Konsistenz wichtig ist – die meisten NoSQL-Systeme beherrschen diesen Trick aber noch nicht. Daher schlage ich vor, dem Beispiel von Amazon zu folgen: Verwende eine althergebrachte SQL-Datenbank.

Ja, Amazon verwendet noch immer Oracle-Datenbanken. Und das obwohl das Amazon-Paper über Dynamo maßgeblich zum NoSQL-Erfolg beigetragen hat. Auch nachdem Amazon weitere Datenbanken wie Redshift, Aurora, Neptune und erst jetzt im November Timestream und Quantum Ledger präsentiert hat.

Und dennoch verwendet Amazon für das eigene Geschäft immer noch Oracle-Datenbanken. Im August hat Amazon aber angekündigt, bis 2020 alle Oracle-Datenbanken abzulösen, was Larry Ellison postwendend mit „das wird schwierig“ quittiert hat. Am Prime Day hatte Amazon aufgrund der Migration dann auch mit Problemen zu kämpfen. Die Migration schreitet dennoch voran und wurde Ende November als Ziel bestätigt. Offenbar braucht man also ein gutes Jahrzehnt, um SQL-Datenbanken durch Ein-Trick-Ponys abzulösen. Am Ende wird Amazon aber weiterhin SQL verwenden – bloß nicht die Oracle-Datenbank.

Wir können daraus folgende Lehre ziehen: Am besten startet man einfach mit einer generischen Datenbank. Im Rückblick ist das genau das, was erfolgreiche Unternehmen gemacht haben. SQL-Datenbanken sind dafür besonders geeignet, weil sie sehr viele Tricks beherrschen. Vor allem, wenn sich die Anforderungen häufig ändern, sind möglichst flexible Werkzeuge ein enormer Vorteil.

Wenn man dann, falls überhaupt, das Limit dieser Datenbank erreicht, sollte man natürlich zuerst optimieren (und dabei professionelle Hilfe in Anspruch nehmen). Als Nächstes geht man daran, das größte Problem zu identifizieren. Mittlerweile stehen die Chancen gut, dass es für dieses Problem bereits ein fix und fertiges Ein-Trick-Pony gibt, das seinen Trick deutlich besser beherrscht als eine generische Datenbank. Diesen, und nur diesen Teil migriert man dann auf diese Lösung (und sucht sich dabei professionelle Hilfe). Falls nötig wiederholt man diesen Prozess. Die Flexibilität und Integrität einer SQL-Datenbank gibt man nur auf, wenn es nicht anders geht.

Die moderne, weit verbreitete und erfolgreiche Architektur besteht daher aus einer SQL-Datenbank, die manchmal von dem einen oder anderen Ein-Trick-Pony umgeben ist, um punktuell Probleme zu lösen. Den Beitrag, den die NoSQL-Bewegung zu dieser Architektur geleistet hat, ist, dass man diese Ein-Trick-Ponys nicht mehr selbst bauen muss, wie es die Internetgiganten machen mussten.

Cloud-Angebot: Tausche Hardware gegen Sicherheitsupdates

Wie in jeder Branche haben auch Cloudanbieter kreative Ideen, potenzielle Kunden von ihren Diensten zu überzeugen. Microsoft hatte in diesem Bereich eine besonders ausgefallene Idee: Da die Versionen 2008 und 2008R2 von Windows und SQL Server bald ihr Lebensende erreichen, verspricht Microsoft drei weitere Jahre kostenlose Sicherheitsupdates, wenn man diese Systeme in die Azure-Cloud migriert. Anstatt für eine neue Lizenz zu zahlen, kann man also für die Hardwarenutzung in der Azure-Cloud zahlen. Ist das nicht verlockend?

Technologie und Wissenschaft

Just in Time (JIT) Übersetzung ist bei Datenbanken momentan ein heißes Thema. Microsoft hatte diese Technologie mit SQL Server 2014 (Hekaton) als erste Mainstreamdatenbank zur Marktreife gebracht. Oracle hat aktuell eine Wette auf eine JIT-Implementierung in Java laufen (Graal). Die PostgreSQL-Datenbank wurde mit der neuen Version im Oktober zur ersten gängigen gratis Open-Source-Datenbank mit JIT Unterstützung.

In der Regel bringt JIT-Übersetzung zwar einen signifikanten Performancevorteil, dafür muss der Hersteller aber auch einen erheblichen Aufwand auf sich nehmen. Daher haben zwei niederländische Wissenschaftler versucht, Teile dieses Prozesses zu automatisieren. Konkret haben sie versucht, den Quellcode der SQLite Virtual Database Engine automatisch für eine JIT-Übersetzung zu nutzen.

Ein anderes interessantes Paper in diesem Bereich ist „Functional Pearl: A SQL to C Compiler in 500 Lines of Code“ (erschienen 2015).

Historisches Dokument

Für all jene, die sich für die Entstehung von SQL interessieren, gibt es interessanten Lesestoff: The 1995 SQL Reunion: People, Projects, and Politics. Dabei handelt es sich um das Protokoll eines eintägigen Treffens verschiedener Personen, die in den 1970ern und 1980ern mit der Entwicklung von SQL und SQL-Produkten befasst waren.

Das Protokoll deckt ein weites Themengebiet ab, wie zum Beispiel, dass man damals einen ganzen Tag lang diskutiert hat, wie das Schlüsselwort für den Null-Wert heißen soll. Meine liebste Passage ist aber diese:

Dazu muss man wissen, dass der SQL-Standard mittlerweile Fehlercodes definiert – es hält sich bloß kaum ein Hersteller daran.

Neue Hauptversionen

Im letzten Halbjahr hat sich mal wieder viel getan.

Oracle 18c (Feb., Jul., Okt.)

Ursprünglich im Februar erschienen, jedoch nur für Nutzer der Oracle-Cloud und eines Engineered Systems, wurde die Oracle Datenbank Version 18c im Juli erstmals zum Download angeboten. Eine weitere 18c-Version erschien dann noch im Oktober in Form der gratis Express Edition (XE). In der Zwischenzeit hat der geschlossene Beta-Test für die Version des nächsten Jahres begonnen (19c).

Mit Version 18c wurden unter anderem einige neue JSON-Funktionen, polymorphe Tabellenfunktionen und eine Abfragesprache für Graphen (PGQL) eingeführt. In meinem Artikel „Neues in der Oracle-Datenbank 18c“ auf modern-sql.com werfe ich einen genaueren Blick auf Version 18c. Dabei treten durchaus einige Überraschungen zutage, die der Dokumentation nicht zu entnehmen sind.

MariaDB 10.3 (Aug.)

Nur ein Jahr, nachdem MariaDB 10.2 Window-Funktionen und rekursive Abfragen eingeführt hat, folgt mit Version 10.3 die Einführung weiterer sieben (7!) moderner SQL-Funktionen. Systemversionierung ist dabei ohne Zweifel die Wichtigste. In meinem Artikel „Neues in MariaDB 10.3“ auf modern-sql.com erkläre ich alle Neuerungen im Detail.

SQLite 3.25.0 (Sep.)

SQLite hat in Version 3.25.0 Window-Funktionen eingeführt. Der Funktionsumfang braucht den Vergleich mit anderen Datenbanken nicht zu scheuen. Demnächst werde ich dazu einen Artikel auf modern-sql.com veröffentlichen (folge modern-sql.com via Twitter, Email oder RSS).

PostgreSQL 11 (Okt.)

Im Oktober wurde dann noch PostgreSQL 11 freigegeben. Unter anderen Neuerungen (z. B. JIT) wurden Window-Funktionen um frame exclusion und die Einheit groups erweitert (neben rows und range). Damit ist PostgreSQL die erste gängige Datenbank, die diese Funktionen unterstützt. Auch dazu werde ich demnächst einen Artikel auf modern-sql.com veröffentlichen (folge modern-sql.com via Twitter, Email oder RSS).

Beachte, dass MySQL neuerdings einen „agilen“ Releasezyklus verfolgt: auch kleine Versionen können neue Funktionen einführen. Zum Beispiel: Sofortiges hinzufügen von Spalten (8.0.12) und funktionsbasierte Indizes (direkt in create index; 8.0.13).

Ein öffentlicher Preview für SQL Server 2019 ist mittlerweile auch verfügbar.

Neue Aufzeichnungen und Folien

Manche Vorträge, die ich bei Konferenzen gehalten habe, wurden aufgezeichnet. Auch nächstes Jahr spreche ich wieder auf Konferenzen. Mein aktueller Terminplan ist hier.

• Standard SQL Gap Analysis: [ PgCon-Aufzeichnung | Folien ]

• Modern SQL: Evolution of a dinosaur: [ JavaZone-Aufzeichnung | Folien ]

• The Mother of all Query Languages: SQL in Modern Times: [ Folien ]

• How PostgreSQL’s SQL dialect stays ahead of its competitors [ PostgreSQL España meetup | Folien ]

• Volkskrankheit „stiefmütterliche SQL-Indizierung“ [ Aufzeichnung bei der FrOSCon ]

Via Twitter, in aller Kürze (folge mir auf Twitter)

• “What’s the largest amount of bad code you have ever seen work?” One of the answers is “Oracle Database 12.2”.

• Visualizing SQL Plan Execution Time With FlameGraphs

• PostgreSQL has learned its lessons from "vi" From the PostgreSQL 11 announcement: The inclusion of the keywords "quit" and "exit" in the PostgreSQL command-line interface to help make it easier to leave the command-line tool

• “Hidden” Efficiencies of Non-Partitioned Indexes on Partitioned Tables Part I [Oracle]

• The content of “SQL Performance Explained” is updated once or twice a year. If you bought the PDF, you can get the latest and greatest version here

• Totally forgot the 8 years anniversary of Use The Index, Luke! Happy birthday and all the best for the future, coolest squirrel on the net :)

• There is only one technology that’s adopted even more slowly than modern SQL: IPv6.

• Linux Kernel Parameters for PostgreSQL

• Cost of a Join. Contrary to popular believe, linear scalability is rather the worst case than the best case in modern databases.

SQL Renaissance Ambassador

Als SQL Renaissance Ambassador ist es meine Mission, Entwickler auf die Evolution von SQL im 21. Jahrhundert aufmerksam zu machen. Mein Buch „SQL Performance Explained“ ist in fünf Sprachen erschienen und kann online kostenlos auf use-the-index-luke.com gelesen werden. Mein nächstes Buch kann bereits während des Entstehens online gelesen werden (modern-sql.com). Allen SQL-interessierten Unternehmen und Entwicklern stehe ich als Trainer, Sprecher und Berater zur Verfügung. Mehr Infos dazu auf winand.at.