Die Zeiten des One-Database-fits-all-Ansatzes sind lange vorbei.
Mit steigenden Anforderungen an Geschwindigkeit, Performance und Agilität sind zahlreiche Datenspeicher entstanden, die ein bestimmtes Problem lösen sollen. Wir haben relationale Datenbanken, Dokumentenspeicher, Zeitreihendatenbanken, Spaltendatenbanken, Volltextsuchmaschinen.
Es kommt häufig vor, dass mehrere Datenspeicher in derselben Umgebung zusammenarbeiten.
Wie passt MariaDB AX ins Bild? Wie schneidet es im Vergleich zu MariaDB TX ab und welches Problem löst es?
In diesem Blogbeitrag werden wir uns MariaDB AX ansehen und sehen, warum Sie es vielleicht verwenden möchten.
Was ist MariaDB AX?
Das Wichtigste zuerst, also was ist MariaDB AX?
Es ist ein Spaltenspeicher und speichert seine Daten nach ... Spalte! Es ist als separate Engine in der MariaDB 10.3-Datenbank implementiert.
Wie Sie vielleicht wissen, sind MySQL und MariaDB darauf ausgelegt, austauschbare Speicher-Engines zu verwenden. Jede Speicher-Engine, sei es InnoDB, Aria, MyRocks, Spider oder andere Engines, sind Plugins.
Auf die gleiche Weise verwendet MariaDB AX die ColumnStore-Engine:
MariaDB [(none)]> SHOW ENGINES\G
*************************** 1. row ***************************
Engine: Columnstore
Support: YES
Comment: Columnstore storage engine
Transactions: YES
XA: NO
Savepoints: NODaraus ergibt sich eine interessante Kombination. Das SQL-Parsing wird von MariaDB durchgeführt, daher können Sie damit rechnen, mit einer Abfragesyntax zu arbeiten, die der von MariaDB gewohnten sehr ähnlich ist. Dies macht es auch einfacher, den Zugriff auf MariaDB AX und MariaDB TX in derselben Anwendung zu kombinieren. Es sind keine speziellen Konnektoren oder Bibliotheken erforderlich, um eine Verbindung zu zwei Datenspeichern herzustellen. Alles kann mit der MySQL- oder MariaDB-Client-Bibliothek durchgeführt werden. Sie können MaxScale auch für beide Datenspeicher verwenden, was dazu beitragen kann, Hochverfügbarkeit für MariaDB AX aufzubauen.
Warum sollten wir einen spaltenförmigen Datenspeicher verwenden?
Sehen wir uns eine kurze Einführung in die Idee hinter spaltenorientierten Datenspeichern an.
Was unterscheidet MariaDB AX von MariaDB TX?
Der Hauptunterschied besteht darin, wie die Daten strukturiert sind. In einer typischen Datenbank werden Daten als Zeilen gespeichert.
Id, Product, Price, Code, Warehouse
1, Door, 10, 12334, EU1
2, Window, 9, 9523, EU1
3, Glass, 12, 97643, EU2Wie Sie sehen können, haben wir drei Zeilen, die jeweils alle Daten zu einem Produkteintrag enthalten.
Das Problem ist, dass diese Art der Datenspeicherung nicht wirklich effizient ist, wenn Sie nur eine Teilmenge dieser Daten erhalten möchten. Angenommen, Sie möchten nur die Spalten „Produkt“ und „Preis“ erhalten – dazu müssen Sie ganze Zeilen und alle Daten lesen und dann die nicht benötigten Spalten verwerfen. Es ist auch schwierig, die Daten zu sortieren. Wenn Sie den Datensatz vom teuersten zum billigsten Produkt sortieren möchten, müssen Sie alles lesen und dann sortieren.
Wir alle wissen, dass Datenbanken Indizes verwenden, um den Zugriff zu beschleunigen. Ein Index ist so aufgebaut, dass er den Inhalt der indizierten Spalte sowie einen Zeiger auf die vollständige Zeile (in InnoDB ist das der Primärschlüssel) enthält. Ein Index für die Spalte „Produkt“ könnte beispielsweise wie folgt aussehen, wenn „ID“ der Primärschlüssel ist:
Product, Id
Door, 1
Window, 2
Glass, 3Dies beschleunigt den Zugriff auf die Daten, da nicht die gesamte Zeile gelesen werden muss, nur um einen Wert in der Spalte „Produkt“ zu finden. Sobald die Datenbank es gefunden hat, kann sie den Rest der Zeile (falls erforderlich) lesen, indem sie dem Zeiger folgt.
In einem Kolumnengeschäft sind die Dinge anders. Daten sind nicht als Zeilen, sondern als Spalten strukturiert. Bis zu einem gewissen Grad ähnelt dies dem Index. Unsere Tabelle im spaltenorientierten Datenspeicher könnte wie folgt aussehen:
Id: 1, 2, 3
Product: Door, Window, Glass
Price: 10, 9, 12
Code: 12334, 9523, 97643
Warehouse: EU1, EU1, EU2In MariaDB AX werden Spalten in separaten Dateien gespeichert, jeder Eintrag für eine bestimmte „Zeile“ beginnt mit demselben Offset.
Der Hauptvorteil hier ist, dass Sie, wenn Sie eine Abfrage ausführen möchten, die nur mit einer Teilmenge von Daten funktioniert, nur Daten aus Spalten lesen müssen, die für die Abfrage relevant sind.
In unserem vorherigen Beispiel können wir, anstatt den gesamten Datensatz zu lesen, einfach Daten für die Spalten „Produkt“ und „Preis“ laden. Es reduziert die Datenmenge, auf die auf der Festplatte zugegriffen werden muss, und beschleunigt den Prozess.
Was auch wichtig ist, das Speichern von Daten in Spalten macht sie weniger deutlich, wodurch sie besser komprimiert werden. In unserer Spalte „Lager“ haben wir beispielsweise nur zwei Arten von Einträgen. Selbst im realen Szenario ist es sehr wahrscheinlich, dass wir im Vergleich zur Anzahl der Produkte mit einer kleinen Anzahl von Lagern enden werden. Dies macht die Spalte „Warenhaus“ zu einem sehr guten Ziel für die Komprimierung.
Als Ergebnis all dessen können spaltenorientierte Datenspeicher große Datensätze besser verarbeiten und effizienter abfragen als „standardmäßige“ OLTP-orientierte Datenbanken.
Warum sollte ich MariaDB AX verwenden?
Der Festplattenzugriff ist ein großer Engpass in Datenbanken. Ein spaltenorientierter Datenspeicher verbessert die Leistung, indem er die Datenmenge reduziert, die von der Festplatte gelesen werden muss. Es werden nur die Daten gelesen, die zur Beantwortung der Anfrage erforderlich sind.
Natürlich ist MariaDB AX nicht der einzige spaltenorientierte Datenspeicher da draußen. Es gibt viele andere wie zum Beispiel Clickhouse oder Apache HBase.
Die Wahrheit ist, dass keine der anderen Optionen die vollständige SQL-Syntax unterstützt, die MySQL tut. Sie erfordern unterschiedliche Konnektoren, unterschiedliche Ansätze zum Abfragen der Daten, während MariaDB AX genauso abgefragt werden kann, wie Sie die „normale“ MariaDB abfragen würden.
Was auch wichtig ist, da MariaDB AX die ColumnStore-Engine verwendet, ist es vollkommen in Ordnung, sie mit anderen Engines zu mischen. Sie können InnoDB- und ColumnStore-Tabellen problemlos in derselben Abfrage mischen und verknüpfen.
Darüber hinaus funktionieren Tools, die mit MariaDB TX geliefert werden, wie MaxScale, problemlos mit MariaDB AX, wodurch es einfacher wird, eine integrierte, benutzerfreundliche Umgebung zu erstellen. Wenn Sie also ClusterControl mit MariaDB 10.3 und MaxScale ausführen, können Sie ganz einfach MariaDB AX in die Mischung einfügen und es funktioniert mit anderen Teilen des Setups.
MariaDB AX wird mit Tools geliefert, die beim Übertragen der Daten aus anderen Quellen helfen sollen. Wenn Sie zufällig Kafka oder Spark verwenden, gibt es Konnektoren, die Sie verwenden können, wenn Sie Daten aus diesen Quellen in MariaDB AX importieren.
Auch wenn die reguläre Replikation zwischen MariaDB TX (InnoDB) und MariaDB AX (ColumnStore) aufgrund von ColumnStore-Einschränkungen nicht gut funktioniert (es ist immer besser, Batch-Einfügungen in spaltenbasierten Datenspeichern durchzuführen als einzelne Einfügungen, wie es bei der Replikation der Fall ist), ist dies der Fall möglich, eine Pipeline aufzubauen, die aus MaxScale als Binlog-Server und Avro CDC-Router, MaxScale CDC-Datenadapter und MariaDB AX besteht, die Daten vom Adapter fast in Echtzeit empfängt.
Wir hoffen, dass dieser Blogbeitrag Ihnen einen Einblick gibt, was MariaDB AX ist und wie es zusammen mit der von ClusterControl bereitgestellten und verwalteten MariaDB TX-Umgebung verwendet werden kann (kostenlos herunterladen!).
