Nutzen Sie diese leistungsstarken MySQL- und MariaDB-Funktionen, um Ihre aktuellen Anwendungen zu verbessern. [...]
In den letzten Jahren haben sich die relationalen Open Source Datenbank-Managementsysteme MySQL und MariaDB enorm verändert: neue und verbesserte Funktionen, die Behebung langjähriger Probleme und eine bessere Leistung auf breiter Front.
Bei all dem, was sich geändert hat, ist es leicht, einige der besten Funktionen zu übersehen, die MySQL und MariaDB in dieser Zeit eingeführt haben. In diesem Artikel werden wir sieben der größten neuen Funktionen, die zu MySQL, MariaDB oder beidem hinzugefügt wurden, vorstellen – und erklären, warum Sie sie verwenden sollten.
1. JSON-Unterstützung
Als NoSQL-Datenbanken in Erscheinung traten, mit ihren Zusicherungen bezüglich Entwicklerfreundlichkeit und flexibler Skalierbarkeit, fragten sich die meisten, ob relationale Datenbanken kurz vor ihrem Ende standen. Die kurze Antwort: Überhaupt nicht. NoSQL-Systeme sind praktisch und flexibel, aber Schemata und Tabellen werden immer ihren Platz in der Welt der IT haben.
Darüber hinaus haben viele relationale Datenbanken der alten Schule, darunter MySQL und MariaDB, eine Seite aus dem NoSQL-Buch herausgegriffen und die JSON-Unterstützung als Standardfunktion hinzugefügt. Der Nettoeffekt ist NoSQL, wenn Sie es brauchen, Seite an Seite mit konventionellem SQL in der gleichen Datenbank.
Mit der JSON-Unterstützung in MySQL und MariaDB können Sie JSON-Dokumente in eine speziell dafür vorgesehene Tabellenspalte einfügen. Die eingefügten JSON-Daten können automatisch mit den gleichen Einschränkungen validiert werden, die auch für andere Datenspalten gelten. Sie können die Daten entweder als JSON-Dokumente oder einfache Skalare abrufen, und Sie können generierte oder virtuelle Spalten verwenden, um einen Effekt ähnlich wie bei JSON-Indizes zu erzeugen.
Zwei wichtige Punkte sollten hier beachtet werden. Erstens, obwohl die Mengen der JSON-Verarbeitungsfunktionen in MySQL und MariaDB ähnlich sind, sind sie keine Drop-In-Ersatzteile füreinander. Zweitens sind auch die Implementierungen von MySQL und MariaDB des nativen JSON-Spaltendatentyps unterschiedlich. Dies führt zu leichten Inkompatibilitäten, die Sie navigieren müssen, wenn Sie Daten zwischen den beiden Datenbanken migrieren oder synchronisieren wollen.
2. Ressourcengruppen (nur MySQL)
Alle Datenbank-Aufträge sind wichtig, aber einige sind dringlicher als andere. Beispielsweise können Sie Aufgaben wie die Archivierung oder eingeplante Batch-Jobs im Hintergrund ausführen und gleichzeitig sicherstellen, dass geschäftskritische Arbeiten so schnell wie möglich durchgeführt werden. Die Ressourcengruppen von MySQL machen dies möglich.
Bei Ressourcengruppen können Sie einen Typ („System“ oder „Benutzer“), eine CPU-Affinität und eine Thread-Priorität für alle dieser Gruppe zugeordneten Datenbankaufträge festlegen. Sie können eine Ressourcengruppe für eine Sitzung oder für eine einzelne Anweisung auswählen, indem Sie einen Optimiererhinweis verwenden.
Beachten Sie, dass Ressourcengruppen auf allen MySQL-Plattformen unterschiedlich implementiert werden und dass Sie Ressourcengruppen nicht in Verbindung mit dem Enterprise Thread Pool Plug-in verwenden können. Auch wenn es eine Anfrage zur Implementierung eines ähnlichen Features in MariaDB gibt, sind noch keine Pläne zur Umsetzung vorhanden.
3. OQGRAPH Speicher-Engine (nur MariaDB)
Mit Diagrammdatenbanken können Sie Beziehungen zwischen Daten viel effizienter speichern und untersuchen als mit einer relationalen Datenbank. Während sich dedizierte Diagrammdatenbanken wie Neo4j oder Amazon Neptune ausschließlich auf die Speicherung und Verarbeitung von Diagrammen konzentrieren, können Sie mit MariaDB über die OQGRAPH Speicher-Engine die Diagrammverarbeitung parallel zu herkömmlichen SQL-Abfragen durchführen.
Die meisten Diagrammdatenbanken verwenden eine eigene benutzerdefinierte Abfragesprache. Mit OQGRAPH laden Sie Daten und erstellen grafische Abfragen mit konventionellem SQL. Die Ergebnisse werden im konventionellen Abfrageformat von MariaDB zurückgegeben, so dass sie mit den Ergebnissen herkömmlicher SQL-Tabellenabfragen verknüpft oder kombiniert werden können.
4. Oracle-Kompatibilitätsmerkmale (nur MariaDB)
Die Datenbankprodukte von Oracle gehören nach wie vor zu den am weitesten verbreiteten in der gesamten IT, doch ihre Lizenzkosten und vertraglichen Beschränkungen veranlassen viele Anwender, sich für eine Exit-Strategie zu entscheiden. Darüber hinaus nutzen viele auf Oracle basierende Anwendungen intensiv die Funktionen, die ausschließlich Oracle PL/SQL und seine Syntax betreffen.
In den letzten Versionen hat MariaDB eine Reihe neuer Funktionen eingeführt, die das Verhalten von Oracle-Datenbanken, insbesondere der PL/SQL-Sprache von Oracle, nachahmen sollen. Theoretisch kann so ein Großteil des vorhandenen PL/SQL-Codes in MariaDB so oder mit nur geringen Änderungen ausgeführt werden. Das MariaDB-Team schätzt daran, dass etwa 80 Prozent der älteren Oracle PL/SQL-Systeme mit den Kompatibilitätsfunktionen wie gewohnt ausgeführt werden können.
Beachten Sie, dass der MariaDB-Befehl zur Verwendung des Oracle PL/SQL-Modus auf Client-Basis wirksam wird. Sie müssen das Verhalten von MariaDB nicht global ändern, um diese Funktion zu nutzen.
5. Systemversionierte Tabellen (MariaDB)
Die Version 2011 des SQL-Standards fügte versionierte Tabellen hinzu, die Möglichkeit für eine Datenbank, Versionen von Tabellenzeilen zu verfolgen. MariaDB hat in der Version 10.3.4 systemversionierte Tabellen als native Funktion hinzugefügt.
it den systemversionierten Tabellen von MariaDB können Sie eine Abfrage mit einem bestimmten zeitlichen Bereich durchführen, und die gelieferten Ergebnisse werden so angezeigt, wie sie in diesem Zeitraum waren.
Sie können auch Zeilen ändern oder löschen, die in einen bestimmten Datumsbereich fallen, Zeiträume hinzufügen oder entfernen, um sie zu verfolgen, und Zeiträume verwenden, die entweder auf Anwendungsebene, Systemebene oder beidem angegeben sind. Theoretisch könnte man dies mit jeder Datenbank tun, die Zeitwerte unterstützt, aber es ist schwierig, es selbst zu durchzusetzen.
Obwohl in MariaDB für jede Datenbankmaschine systemversionierte Tabellen unterstützt werden, sind einige der Funktionen – wie z.B. die transaktionsgenaue Historie, die Datensätze in der Mitte einer bestimmten Transaktion anzeigt – nur mit der InnoDB-Engine verfügbar.
6. ColumnStore Speicher-Engine / InfiniDB (MariaDB)
Die Pluggable Storage Engine Technologie in MariaDB und MySQL ermöglicht es beiden Datenbanken, ihre native Funktionalität stark zu erweitern. Eine solche Speicher-Engine, ColumnStore, verwandelt MariaDB in eine Columnar-Storage-Datenbank. (ColumnStore ist nicht für MySQL verfügbar, aber das Projekt ColumnStore wurde abgeleitet von InfiniDB, verwendet MySQL zur Ausführung von Abfragen.)
Die Spaltenspeicherung ist ideal für die schnelle Abfrage großer Datenmengen. OLAP-Systeme verwenden Spaltenspeicher, und so funktioniert ColumnStore als eine Möglichkeit, OLAP-ähnliche Funktionen innerhalb von MariaDB bereitzustellen, ohne sich auf ein externes (und typischerweise kommerzielles) Produkt wie Teradata oder Greenplum zu verlassen. ColumnStore bietet nicht die gesamte Bandbreite an sofort einsatzbereiten Analyse- oder Data-Marshaling-Funktionen, die mit diesen Produkten geliefert werden, aber es kann die Datenschicht für eine interne Analyselösung bereitstellen.
7. Die Spider Storage Engine
Je leistungsfähiger die Funktion, desto schwieriger ist der Einsatz in der Produktion. Eine dieser Funktionen ist das Datenbank-Sharding oder die Aufteilung einer Datenbank auf mehrere Server, um die Leistung zu verbessern, was in der Regel eine Menge an Änderungen und Optimierungen erfordert.
MariaDB 10.3.4 (und später) ebnet den Weg mit Spider, einer Speichermaschine mit integrierten Sharing- und Datenpartitionierungsfunktionen. Spider unterstützt mehrere verschiedene Modi: einfache Föderation, Hochverfügbarkeit, Sharding und Sharding plus hohe Verfügbarkeit.
Spider hat einige Funktionsüberschneidungen mit MaxScale, dem System von MariaDB für Lastausgleich, Proxying, Failover und hohe Verfügbarkeit. MaxScale deckt eine breitere und ehrgeizigere Palette von Anwendungsfällen ab als Spider, aber Spider ist nützlich, wenn Sie die Vorteile des Sharding in bescheideneren Umgebungen nutzen wollen.
Spider wurde ursprünglich als MySQL-Plugin entwickelt und ist in dieser Form auch heute noch für MySQL-Anwender verfügbar. Die überwiegende Mehrheit der Funktionen in beiden Versionen ist bis auf wenige Ausnahmen gleich.
*Serdar Yegulalp ist Senior-Autor bei InfoWorld und beschäftigt sich mit maschinellem Lernen, Containerisierung, Devops, dem Python-Ökosystem und regelmäßigen Reviews.
Be the first to comment