5 Gründe, auf MariaDB umzusteigen

MariaDB ist inzwischen auf Augenhöhe mit MySQL – sieht man einmal von Ressourcengruppen ab.hollywood_DP | shutterstock.com



MariaDB nahm bekanntlich als Fork von MySQL seinen Anfang, nachdem Oracle sich Letzteres einverleibt hatte. Inzwischen hat die quelloffene Lösung jedoch zunehmend einen eigenen Weg eingeschlagen.



Speziell mit den letzten größeren Überarbeitungen wurde MariaDB um einige einzigartige Funktionen ergänzt, die dazu beitragen sollen, Oracle-SQL-Nutzer zum Umstieg zu bewegen. In diesem Artikel stellen wir Ihnen fünf der wichtigsten Neuerungen vor.



1. Opt-In-Kompatibilität



Seit Version 10.3 wurde MariaDB mit Blick auf Oracle kontinuierlich um Kompatibilitätsfunktionen erweitert. Hierdurch ist es deutlich einfacher geworden, Oracle unverändert auf MariaDB zu portieren. Diese Kompatibilität ist optional. Um sie für eine bestimmte Gruppe von SQL-Statements zu aktivieren, führen Sie lediglich den Befehl SET SQL_MODE=‘ORACLE‘ aus.



Die meisten dieser Kompatibilitätsfunktionen sind darauf ausgelegt, die Oracle-SQL-Syntax zu supporten – insbesondere dort, wo diese von ANSI SQL oder MariaDB abweicht. So können in Oracle SQL beispielsweise Stored Procedures mit ihrem Namen gecallt werden – statt mit dem CALL-Keyword.



Weitere Änderungen am Oracle-Kompatibilitätsmodus betreffen jedoch nicht nur die Syntax, sondern auch grundlegende Verhaltensweisen. Ab MariaDB 12.0 können etwa einzelne Trigger auf mehreren INSERT/UPDATE/DELETE-Events ausgeführt werden.



Das ist eine Oracle-SQL-Funktion, die sich manuell nur schwer replizieren lässt. MariaDB bietet zudem auch ein Migrations-Tool an, mit dem sich DDL-Exportdateien von Oracle SQL (nur die Datendefinition, keine tatsächlichen Daten) auf ihre „MariaDB-Tauglichkeit“ analysieren lassen.



2. KI-Funktionen



KI-Funktionen halten in fast allen datenzentrierten Softwareprodukten Einzug. Da bildet MariaDB ebenfalls keine Ausnahme. Allerdings scheinen die KI-Funktionen der Open-Source-Lösung wirklich sinnvoll. So wurde MariaDB ab Version 11.8 um einen nativen VECTOR-Datentyp ergänzt, mit dem sich Informationen über Textähnlichkeiten in eine Datenbank einbetten lassen.



Das ermöglicht, MariaDB als Engine für natürlichsprachliche Queries, Empfehlungssysteme, RAG-Lösungen oder allgemeine ML-Tasks einzusetzen. Der Großteil der dafür notwendigen Arbeiten kann dabei direkt in der Datenbank erfolgen. Umwege über externe Applikationen bleiben Ihnen erspart.



Eine weitere, neue Funktion macht MariaDB bei Bedarf außerdem zu einer Extension für existierende KI-Agenten: Eigene MCP-Server-Komponenten erleichtern es inzwischen, MariaDB-Instanzen über Large Language Models (LLMs) abzufragen.



Darüber hinaus ist es auch möglich, Embeddings (über OpenAI-, Gemini- oder offene Huggingface-Modelle) zu verwenden, um semantische Suchen in Dokumenten durchzuführen, die innerhalb einer Datenbank gespeichert sind.



3. Mehr JSON-Funktionen



NoSQL-Datenbanken gaben Entwicklern die Freiheit, offene Schemata, definiert als JSON-Dokumente, zu verwenden, um Daten zu speichern. Konventionelle SQL-Datenbanken wurden seitdem um ihre eigenen, nativen JSON-Funktionalitäten ergänzt. Diese ermöglichen die Flexibilität von NoSQL, aber ohne die formalen SQL-Schemata über Bord zu werfen.   



In MariaDB gibt es einen JSON-Spaltentyp, der Text im JSON-Format akzeptiert und automatisch validiert werden kann (mit JSON_VALID CHECK). Wenn Ihre JSON-Daten dabei strikten Datentypen folgen sollen, ist es möglich, Einschränkungen für spezifische Keys hinzuzufügen. SELECT-Queries können Daten aus JSON-Spalten anhand des Keys extrahieren:



SELECT id, name, JSON_QUERY(attr, '$.dates.release') AS release_year FROM movies



Und auch nach Werten filtern:



SELECT id, name FROM movies WHERE JSON_VALUE(attr, '$.dates.release') = 1981



Für performantere JSON-Operationen ist es auch möglich, virtuelle Spalten zu erstellen, die den Keys im Dokument zugeordnet sind. Anschließend können aus diesen virtuellen Spalten Indizes erstellt werden:



ALTER TABLE movies ADD COLUMN
release_year SMALLINT AS (JSON_VALUE(attr, '$.dates.release'));
CREATE INDEX releaseyears ON movies(release_year);



Darüber hinaus ist es auch möglich, Daten zu ändern, ohne die JSON-Datei zu extrahieren und zu bearbeiten. JSON_INSERT(), JSON_ARRAY_APPEND() und JSON_REMOVE() sorgen dafür, dass solche In-Place-Transformationen schneller und zuverlässiger ablaufen (im Vergleich zum Versuch, die Daten manuell außerhalb von MariaDB zu bearbeiten).



4. Erweiterte Optimizer-Hints



Erfahrene Datenbank-Entwickler wissen es zu schätzen, wenn sie detailliert steuern können, wie Queries ausgeführt werden. MariaDB verfügt schon seit Längerem über „Hints“, beziehungsweise „Modifikatoren“ für SELECT-Anweisungen, beispielsweise HIGH_PRIORITY und FORCE INDEX.



Mit MariaDB 12.0 kamen die sogenannten Optimizer-Hints im neuen Stil hinzu, mit denen Hinweise sowohl global als auch auf bestimmte Tabellen oder Indizes angewendet werden können. Diese sind als Inline-Kommentare mit den Begrenzungszeichen /*+ und */ formatiert.



Die erweiterten Hinweise sind nicht für den täglichen Gebrauch gedacht: Sie erzwingen die Aktivierung (oder Deaktivierung) von Verhaltensweisen, die normalerweise gut funktionieren, in bestimmten Szenarien jedoch besser, wenn sie explizit gesteuert werden. Beispielsweise teilt ein INDEX_MERGE-Hint dem Query Optimizer mit, welche spezifischen Indizes bei Index-Scans über mehrere Spalten hinweg zu verwenden sind.



Das kann Abfragen, die auf Tabellen mit vielen Indizes basieren, beschleunigen. Optimalerweise nutzen Sie eine EXPLAIN-Anweisung zusammen mit einer Abfrageoptimierung, um herauszufinden, ob das auch in der Praxis der Fall ist.



Andere neue Hints sind sowohl in Sachen Troubleshooting als auch Performance hilfreich. Der MAX_EXECUTION_TIME()-Hint kann eine spezifische Abfrage etwa nach einer bestimmten Zeit abbrechen.



Auf diese Weise lässt sich verhindern, dass „pathologische” Queries das System blockieren – oder im Rahmen des Debugging-Prozesses einer bestehenden Query, die dazu neigt, aus dem Ruder zu laufen.



5. Neuer XML-Typ



Eine weitere zukunftsweisende Verbesserung (die allerdings noch nicht viel bewirkt), ist der mit MariaDB 12.3 eingeführte, neue Spaltentyp XMLTYPE. Dieser akzeptiert aktuell lediglich Strings mit einer Größe von bis zu vier GB und ermöglicht es, XML mit der UPDATEXML-Funktion selektiv zu ersetzen.



Zwar wird XML derzeit weder validiert noch ein Schema durchgesetzt – diese Funktionen sollen jedoch folgen, um XMLTYPE funktional kompatibler mit Oracle zu machen und den Weg für künftige Erweiterungen zu ebnen. (fm)



Dieser Artikel ist im Original bei unserer Schwesterpublikation Infoworld.com erschienen.