L'époque de l'approche à base de données unique est révolue depuis longtemps.
Avec des exigences croissantes en matière de vitesse, de performances et d'agilité, de nombreux datastores ont émergé, destinés à résoudre un problème particulier. Nous avons des bases de données relationnelles, des magasins de documents, des bases de données de séries chronologiques, des bases de données en colonnes, des moteurs de recherche en texte intégral.
Il est assez courant de voir plusieurs magasins de données fonctionner ensemble dans le même environnement.
Alors, comment MariaDB AX s'intègre-t-il dans l'image ? Comment se compare-t-il à MariaDB TX et quel problème résout-il ?
Dans cet article de blog, nous examinerons MariaDB AX et verrons pourquoi vous voudrez peut-être l'utiliser.
Qu'est-ce que MariaDB AX ?
Tout d'abord, qu'est-ce que MariaDB AX ?
C'est un magasin de colonnes, et il stocke ses données par ... colonne ! Il est implémenté en tant que moteur séparé dans la base de données MariaDB 10.3.
Comme vous le savez peut-être, MySQL et MariaDB sont conçus pour utiliser des moteurs de stockage enfichables. Tous les moteurs de stockage, que ce soit InnoDB, Aria, MyRocks, Spider ou tout autre moteur sont des plugins.
De la même manière, MariaDB AX utilise le moteur ColumnStore :
MariaDB [(none)]> SHOW ENGINES\G
*************************** 1. row ***************************
Engine: Columnstore
Support: YES
Comment: Columnstore storage engine
Transactions: YES
XA: NO
Savepoints: NOIl en résulte une combinaison intéressante. L'analyse SQL est effectuée par MariaDB, vous pouvez donc vous attendre à travailler avec une syntaxe de requête très similaire à celle à laquelle vous êtes habitué dans MariaDB. Cela facilite également la combinaison de l'accès à MariaDB AX et MariaDB TX dans la même application. Pas besoin de connecteurs ou de bibliothèques spécifiques pour se connecter à deux datastores. Tout peut être fait en utilisant la bibliothèque cliente MySQL ou MariaDB. Vous pouvez également utiliser MaxScale pour les deux datastores, ce qui peut aider à créer une haute disponibilité pour MariaDB AX.
Pourquoi devrions-nous utiliser un magasin de données en colonnes ?
Passons en revue une brève introduction à l'idée derrière les datastores en colonnes.
Qu'est-ce qui différencie MariaDB AX de MariaDB TX ?
La principale différence réside dans la structure des données. Dans une base de données typique, les données sont stockées sous forme de lignes.
Id, Product, Price, Code, Warehouse
1, Door, 10, 12334, EU1
2, Window, 9, 9523, EU1
3, Glass, 12, 97643, EU2Comme vous pouvez le voir, nous avons trois lignes, chacune contenant toutes les données sur une entrée de produit.
Le problème est que cette façon de stocker les données n'est pas vraiment efficace lorsque vous souhaitez obtenir uniquement un sous-ensemble de ces données. Supposons que vous souhaitiez obtenir uniquement les colonnes "Produit" et "Prix". Pour ce faire, vous devez lire des lignes entières, toutes les données, puis supprimer les colonnes inutiles. Il est également délicat de trier les données. Si vous souhaitez trier l'ensemble de données du produit le plus cher au produit le moins cher, vous devez tout lire, puis effectuer le tri.
Nous savons tous que les bases de données utilisent des index pour accélérer l'accès. Un index est structuré de manière à contenir le contenu de la colonne indexée ainsi qu'un pointeur vers la ligne complète (dans InnoDB, c'est la clé primaire). Par exemple, un index sur la colonne "Produit", en supposant que "Id" est la clé primaire, peut ressembler à ceci :
Product, Id
Door, 1
Window, 2
Glass, 3Cela accélère l'accès aux données car il n'est pas nécessaire de lire une ligne complète juste pour trouver une valeur dans la colonne "Produit". Une fois que la base de données l'a trouvé, elle peut lire le reste de la ligne (si nécessaire) en suivant le pointeur.
Dans un magasin à colonnes, les choses sont différentes. Les données sont structurées non pas en lignes mais en colonnes. Dans une certaine mesure, cela ressemble à l'indice. Notre table dans le magasin de données en colonnes peut ressembler à ceci :
Id: 1, 2, 3
Product: Door, Window, Glass
Price: 10, 9, 12
Code: 12334, 9523, 97643
Warehouse: EU1, EU1, EU2Dans MariaDB AX, les colonnes sont stockées dans des fichiers séparés, chaque entrée pour une "ligne" donnée commence au même décalage.
Le principal avantage ici est que si vous souhaitez exécuter une requête qui ne fonctionnera qu'avec un sous-ensemble de données, vous n'avez qu'à lire les données des colonnes qui sont pertinentes pour la requête.
Dans notre exemple précédent, au lieu de lire l'ensemble de données complet, nous pouvons simplement charger les données des colonnes "Produit" et "Prix". Cela réduit le nombre de données à accéder sur le disque et accélère le processus.
Ce qui est également important, le stockage des données dans des colonnes les rend moins distinctes, ce qui les rend mieux compressées. Par exemple, dans notre colonne "Entrepôt", nous n'avons que deux types d'entrées. Même dans un scénario réel, il est très probable que nous nous retrouvions avec un petit nombre d'entrepôts par rapport au nombre de produits. Cela fait de la colonne "Entrepôt" une très bonne cible pour la compression.
En conséquence de tout cela, les datastores en colonnes peuvent mieux gérer de grands ensembles de données et peuvent les interroger de manière plus efficace que les bases de données "standard" axées sur OLTP.
Pourquoi devrais-je utiliser MariaDB AX ?
L'accès au disque est un goulot d'étranglement majeur dans les bases de données. Une banque de données en colonnes améliore les performances en réduisant la quantité de données devant être lues à partir du disque. Il lit uniquement les données nécessaires pour répondre à la requête.
Bien sûr, MariaDB AX n'est pas le seul magasin de données en colonnes. Il en existe bien d'autres comme, par exemple, Clickhouse ou Apache HBase.
La vérité est qu'aucune des autres options ne prend en charge la syntaxe SQL complète comme MySQL le fait. Ils nécessitent des connecteurs différents, une approche différente pour interroger les données, tandis que MariaDB AX peut être interrogée comme vous interrogeriez MariaDB "normale".
Ce qui est également important, étant donné que MariaDB AX utilise le moteur ColumnStore, il est parfaitement possible de le mélanger avec d'autres moteurs. Vous pouvez mélanger et joindre des tables InnoDB et ColumnStore dans la même requête sans aucun problème.
De plus, les outils fournis avec MariaDB TX, comme MaxScale, fonctionneront très bien avec MariaDB AX, ce qui facilitera la création d'un environnement intégré et facile à utiliser. Ainsi, lorsque vous exécutez ClusterControl avec MariaDB 10.3 et MaxScale, vous pouvez facilement ajouter MariaDB AX dans le mélange et cela fonctionnera avec d'autres parties de la configuration.
MariaDB AX est livré avec des outils destinés à faciliter le transfert de données à partir d'autres sources. Si vous utilisez Kafka ou Spark, il existe des connecteurs à utiliser lors de l'importation de données de ces sources dans MariaDB AX.
De plus, même si la réplication régulière entre MariaDB TX (InnoDB) et MariaDB AX (ColumnStore) ne fonctionne pas bien en raison des limitations de ColumnStore (il est toujours préférable de faire des insertions par lots dans des datastores en colonnes plutôt que des insertions simples, comme c'est le cas lors de la réplication), il est possible de construire un pipeline qui consisterait en MaxScale configuré comme serveur binlog et routeur Avro CDC, MaxScale CDC Data Adapter et MariaDB AX, qui recevra les données de l'adaptateur presque en temps réel.
Nous espérons que cet article de blog vous donnera un aperçu de ce qu'est MariaDB AX et de la manière dont il peut être utilisé avec l'environnement MariaDB TX déployé et géré par ClusterControl (téléchargez-le gratuitement !).
