Bild eines Teleskops

Neues über Datenbanken — Herbst 2019

Zweimal im Jahr lasse ich die Nachrichten der letzten sechs Monate Revue passieren und verpacke die interessantesten Neuigkeiten in eine kurze Geschichte. Es ist wieder so weit. Abonniere den Newsletter, um künftige Ausgaben zu erhalten.

Der SQL-Nachfolger?

In der letzten Ausgabe habe ich berichtet, wie der SQL-Standard momentan um Funktionen zur Abfrage von Graphen und später vielleicht sogar um Streamprocessing erweitert wird. Diesmal möchte ich den Blick auf einen anderen Vorstoß werfen: eine neue Sprache, die SQL vielleicht sogar ablösen könnte.

Im August 2019 verkündete Amazon, mit PartiQL (gesprochen: Partikl) „eine Abfragesprache für alle Daten“ erfunden zu haben. Bei genauerer Betrachtung ist PartiQL aber eher ein Rebranding von SQL++ als eine neue Erfindung.

Die Geschichte beginnt in 2014 mit der Veröffentlichung des Papers zu SQL++. In der ursprünglichen Version dieses Papers verglich man die Möglichkeiten verschiedener Abfragesprachen im Bereich von SQL-on-Hadoop, NoSQL und NewSQL. Als Mittel zum Zweck wurde SQL++ als hypothetische Über-Sprache erschaffen, die alle Funktionen der untersuchten Sprachen abdeckt. Der Vergleich selbst ist dann im Wesentlichen eine Diskussion, wie die SQL++-Funktionen von den untersuchten Sprachen unterstützt werden.

Erst in späteren Versionen des Papers rückt SQL++ selbst ins Zentrum. Denn einige Hersteller bekundeten ihr Interesse an der Umsetzung dieser Sprache. Einer davon war Couchbase, wo man danach strebte, die eigene Sprache N1QL an SQL++ anzugleichen. In der Zwischenzeit hat Couchbase diesen Plan mit N1QL for Analytics in die Tat umgesetzt. Das ist übrigens nicht zu verwechseln mit N1QL for Query, welches vormals nur N1QL genannt wurde, und nicht SQL++-kompatibel ist. Relevanter XKCD-Comic.

Gleichzeitig hat einer der SQL++-Autoren bei Amazon daran gearbeitet, diese Über-Sprache unter dem Namen PartiQL als Norm zu etablieren. Die Neuerungen gegenüber SQL++ betreffen dabei weniger die Sprache selbst, als das Drumherum. So gibt es für PartiQL zum Beispiel eine (unvollständige) Open-Source-Referenzimplementierung.

Die Frage, ob sich PartiQL tatsächlich als die eine Sprache für alle Daten durchsetzen wird, kann man einfach mit „daran sind schon andere gescheitert“ abtun. PartiQL ist nämlich nicht ganz so naiv wie andere Vorstöße in diese Richtung. Ein wichtiger Aspekt ist, dass PartiQL SQL-kompatibel ist. Auch wenn PartiQL aktuell nur einen kleinen Teil von SQL-92 abdeckt, sind viele gültige SQL-Abfragen gleichzeitig auch gültige PartiQL-Abfragen. Das erleichtert sowohl das Erlernen der neuen Sprache als auch die Migration bestehender Projekte. Außerdem kann PartiQL nicht ohne weiteres in den SQL-Standard integriert werden, wie es bei den eingangs genannten Beispielen angestrebt wird. Der essenzielle Unterschied zwischen PartiQL und SQL – dynamische vs. statische Typisierung – geht nämlich an die Grundfeste von SQL. Die allgemeine Umstellung von SQL auf eine dynamische Typisierung, wie sie PartiQL vorsieht, ist für mich unvorstellbar. Denkbar wären „dynamische Typen“, auf die wie SQL-Arrays und SQL-Objekte zugegriffen wird, aber eben ohne statische Typenprüfung. Eine Art begrenzte dynamische Typisierung. Das könnte das Beste aus beiden Welten sein.

Cloud Wars: Ungewöhnlicher Strafzoll auf den Umstieg in die Cloud

In einer aktuellen Analyse prognostiziert Gartner 17 % Umsatzwachstum für öffentliche Cloud-Lösungen. Kein Wunder, dass Softwarehersteller bemüht sind, ihren Kunden den Umstieg in die Cloud möglichst einfach zu machen. Da ist es durchaus überraschend, dass Microsoft kürzlich eine neue Umstiegshürde einführte.

In eigener Sache: Schulungstermin 23.-27. März in Wien

Seit SQL-92 hat sich einiges getan. Mein 5-tägiges Training ist das Update für Entwickler. Nur noch bis Weihnachten: € 500,00 Frühbucherrabatt. Alle Details und die Anmeldung gibt’s hier!

Das wichtigste vorweg: Diese neue Hürde betrifft nur ein sehr spezielles Szenario. Es geht um die Verwendung dedizierter Hardware in den Cloud-Umgebungen von Alibaba, Amazon, Google und auch Microsoft selbst. Für dieses Szenario können On-Premises-Lizenzen, die ab Oktober 2019 gekauft wurden, nicht mehr ohne Weiteres im Rahmen eines „Bring Your Own-License“-Setups in der Cloud weiterverwendet werden. Neue Lizenzen erlauben das nur, wenn auch Software Assurance mitgekauft wird, was die jährlichen Kosten um 25 % erhöht.

Technologie und Wissenschaft

Endlich unterstützt MySQL den Hash-Join-Algorithmus. Andere Produkte verwenden diesen Algorithmus, der insbesondere bei großen Datenmengen vorteilhaft sein kann, schon seit Jahrzehnten. Ich möchte an dieser Stelle aber nicht auf den Hash-Join-Algorithmus eingehen, sondern vielmehr erklären, warum er bei MySQL so spät kam.

Die Geschichte beginnt in den 1980er Jahren, lange vor der ersten MySQL-Version. Am Ende dieser Dekade wurde nämlich das sogenannte Volcano-Modell zur Ausführung von Abfragen vorgestellt (Paper). Die Schlüsselidee war, dass alle Operationen ein gemeinsames Interface haben, sodass alle Operationen beliebig kombiniert und wie Lego-Steine zu einem größeren Ganzen zusammengesetzt werden können. Das System hat sich durchgesetzt und ist vielen Datenbanknutzern als Ausführungsplan bekannt.

MySQL – und damit auch MariaDB – setzte das Volcano-Modell anfangs allerdings nicht um. Stattdessen schlichen sich Annahmen in den Code ein, wie verschiedene Operationen zusammenspielen können. Die Flexibilität war stark eingeschränkt. Weitere Details sind in Work-List Item 11785 dokumentiert. Letztendlich hat man sich bei Oracle aber entschieden, das Volcano-Modell auch für MySQL umzusetzen. Mit der Version 8.0.18 wurde die neue Implementierung im Oktober freigegeben.

Die Einführung neuer Operationen ist damit relativ einfach geworden. Der Hash-Join-Algorithmus ist lediglich ein Beispiel. Ein anderes ist das EXPLAIN ANALYZE-Kommando, dass das gemeinsame Interface aller Operationen für Performancemessungen nutzt. Dabei hat man sich die Syntax und das Ausgabeformat von PostgreSQL abgeschaut.

Eine andere, unabhängige Veröffentlichung rund um das Volcano-Modell gab es kürzlich von CockroachDB: Dort hat man das Interface zwischen den Operationen des Volcano-Modells so erweitert, dass mehrere Zeilen auf einmal weitergereicht werden können. Nachdem die Operationen angepasst wurden, um das erweiterte Interface effizient zu nutzen, wurden manche Abfragen um den Faktor vier schneller. Eine ähnliche Erweiterung gab es übrigens bei SQL Server 2019: Dort wird dieses Vorgehen Batch-Mode genannt und wurde ursprünglich für den spaltenorientierten Speicher Columnstore eingeführt. Nun steht dieser Ausführungsmodus auch beim Zugriff auf normale, zeilenorientierte Tabellen zur Verfügung.

Zuletzt möchte ich noch ein aktuelles Paper erwähnen: APOLLO: Automatic Detection and Diagnosis of Performance Regressions in Database Systems. Dabei geht es darum, Performanceverschlechterungen zwischen Datenbankversionen automatisch zu erkennen. Nachdem man den Algorithmus zwei Monate laufen ließ, hatte er insgesamt 11 Bugs in SQLite und PostgreSQL gefunden. Zwei davon sind bereits korrigiert, fünf weitere von dem jeweiligen Hersteller bestätigt.

Neue Versionen

MySQL 8.0.17 bis 8.0.18 (Juli 2010 bis Oktober 2019)

Die Umsetzung des Volcano-Modells und die damit einhergehende Einführung des Hash-Joins und EXPLAIN ANALYZE habe ich oben schon ausführlich dargestellt. Eine andere nennenswerte Erweiterung der letzten Monate ist die Einführung von InnoDB multi-valued indexes (Inverted Index) um JSON-Dokumente besser zu indizieren.

PostgreSQL 12 (Oktober 2019)

Mit PostgreSQL 12 wurden wieder zahlreiche interessante Erweiterungen eingeführt. Meine Favoriten sind SQL/JSON Path, nicht-deterministische ICU-Collations (case insensitive!) und dass die With-Klausel nicht mehr zwangsläufig eine Optimizer-Barriere ist.

SQLite 3.30.1 (Oktober 2019)

Im Oktober wurde die Filter-Klausel von SQLite auf Aggregatfunktionen ausgeweitet. Zuvor konnte diese Klausel nur für Window-Funktionen verwendet werden – also nur zusammen mit einer Over-Klausel. Gleichzeitig wurde die Nulls First- bzw. Nulls Last-Klausel für Order By eingeführt.

SQL Server 2019 (v15, November 2019)

Bei SQL Server 2019 sticht nicht unbedingt ein einzelnes neues Feature hervor. Es wurden eher zahlreiche bestehende Funktionen erweitert. Darunter fällt auch, dass SQL Server 2019 auf Linux nahezu 100 % Feature-kompatibel zur Windows-Version ist.

Eine genauere Analyse der neuen SQL-Funktionen dieser Releases erscheint in den nächsten Monaten auf modern-sql.com (Twitter, Email, RSS).

Neue Artikel, Folien und Aufzeichnungen

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

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.

Mit Markus Winand verbinden

Markus Winand auf LinkedInMarkus Winand auf XINGMarkus Winand auf Twitter