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 einerOver
-Klausel. Gleichzeitig wurde dieNulls First
- bzw.Nulls Last
-Klausel fürOrder 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
Neue Aufzeichnung (45 min, YouTube): code.talks: Mehr als eine Abfragesprache: SQL im 21. Jahrhundert
Neue Aufzeichnung (62 min, ccc.de): froscon: Neues in Open-Source-SQL-Datenbanken
Neue Aufzeichnung (45 min, YouTube): Devoxx.BE: More Than a Query Language: SQL in the 21st Century
Neuer Artikel: Mein Interview in „The Art of PostgreSQL“
Neuer Artikel: Neues in Oracle-Datenbank Version 19c
Neuer Artikel im Java Magazin 1.2020: SQL im 21. Jahrhundert
Dieser Artikel erscheint demnächst auch auf modern-sql.com (Twitter, Email, RSS).
Via Twitter, in aller Kürze (folge mir auf Twitter)
@MarkusWinand: One persons microservice is another persons monolith.
@KeithWHare: “The History of Time in Data Models” is a timely blog and well worth reading.
A: I don’t have a favorite. Depending on the projects requirements, there is a best fit for each project. The requirements also include existing experience in the team and budget. However, if you don’t know the requirements yet PostgreSQL is the best default to start with.
I created 230 test cases. It took me 16 footnotes, some of them quite long, to describe all the limitations I found. Here is the result in one picture. PostgreSQL still “red” and “n/a” because this picture is based on PostgreSQL 11.
All implementations are utterly incomplete and some of them have interesting bugs and conformance issues (of which I reported some—those where I believe it makes sense). I wonder what spec they were working against.
An then there is PostgreSQL 12 (beta 3). There is only one missing feature (datetime) which is being worked on. The only conformance issue I found is also being worked on. That’s it. Everything else if fine. The most complete and correct SQL/JSON path implementation I’ve seen.
@MarkusWinand: The one and only Hello world! in SQL
VALUES('Hello world!')
@richardfoote: Oracle 19c Automatic Indexing: Methodology Introduction (After Today) https://richardfoote.wordpress.com/2019/07/24/oracle-19c-automatic-indexing-methodology-introduction-after-today/
@daniel_abadi: New post on my blog when I discuss correctness/time-travel anomalies in serializable database systems: https://dbmsmusings.blogspot.com/2019/06/correctness-anomalies-under.html
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.