Cet article a été publié pour la première fois dans InfoWorld . Il est reproduit avec permission. © IDG Communications, Inc., 2020. Tous droits réservés Comment MariaDB atteint une échelle mondiale avec Xpand. Xpand est désormais disponible dans MariaDB SkySQL, ajoutant du SQL distribué pour l'évolutivité et l'élasticité dans le cloud.
À mesure que les besoins en informations et en traitement ont augmenté, les problèmes tels que les performances et la résilience ont nécessité de nouvelles solutions. Les bases de données doivent maintenir la conformité et la cohérence ACID, fournir une haute disponibilité et des performances élevées, et gérer des charges de travail massives sans épuiser les ressources. Le sharding a offert une solution, mais pour de nombreuses entreprises, le sharding a atteint ses limites, en raison de sa complexité et de ses besoins en ressources. Une meilleure solution est le SQL distribué.
Dans une implémentation SQL distribuée, la base de données est distribuée sur plusieurs systèmes physiques, fournissant des transactions à un niveau évolutif à l'échelle mondiale. MariaDB Platform X5, une version majeure qui inclut des mises à niveau de tous les aspects de MariaDB Platform, fournit un SQL distribué et une évolutivité massive grâce à l'ajout d'un nouveau moteur de stockage intelligent appelé Xpand. Avec une architecture sans partage, des transactions ACID entièrement distribuées et une forte cohérence, Xpand vous permet d'évoluer jusqu'à des millions de transactions par seconde.
Moteurs intelligents enfichables optimisés
MariaDB Enterprise Server est conçu pour utiliser des moteurs de stockage enfichables (comme Xpand) afin d'optimiser des charges de travail particulières à partir d'une plate-forme unique. Il n'y a pas besoin de bases de données spécialisées pour gérer des charges de travail spécifiques. MariaDB Xpand, notre moteur intelligent pour SQL distribué, est le plus récent ajout à notre gamme. Xpand ajoute des capacités transactionnelles distribuées massivement évolutives aux options fournies par nos autres moteurs. Nos autres moteurs enfichables offrent une optimisation pour les charges de travail analytiques (en colonnes), les charges de travail lourdes en lecture et les charges de travail lourdes en écriture. Vous pouvez mélanger et faire correspondre des tables répliquées, distribuées et en colonnes pour optimiser chaque base de données en fonction de vos besoins spécifiques.
L'ajout de MariaDB Xpand permet aux entreprises clientes de bénéficier de tous les avantages du SQL distribué (vitesse, disponibilité et évolutivité) tout en conservant les avantages de MariaDB auxquels ils sont habitués.
Voyons comment MariaDB Xpand fournit du SQL distribué.
SQL distribué jusqu'aux index
Xpand fournit du SQL distribué en découpant, répliquant et distribuant les données entre les nœuds. Qu'est-ce que ça veut dire? Nous allons utiliser un exemple très simple avec une table et trois nœuds pour démontrer les concepts. Ce qui n'est pas montré dans cet exemple, c'est que toutes les tranches sont répliquées.
Dans la figure 1 ci-dessus, nous avons une table avec deux index. Le tableau contient des dates et nous avons un index sur la colonne deux et un autre sur les colonnes trois et un. Les index sont en quelque sorte des tableaux eux-mêmes. Ce sont des sous-ensembles du tableau. La clé primaire est id , le premier index de la table. C'est ce qui sera utilisé pour hacher et répartir les données de la table dans la base de données.
Ajoutons maintenant la notion de tranches . Les tranches sont essentiellement des partitions horizontales de la table. Nous avons cinq lignes dans notre tableau. Dans la figure 2, le tableau a été découpé et distribué. Le nœud #1 a deux rangées. Le nœud #2 a deux lignes et le nœud #3 a une ligne. L'objectif est que les données soient réparties aussi uniformément que possible entre les nœuds.
Les index ont également été tranchés et distribués. Il s'agit d'une différence essentielle entre Xpand et les autres solutions distribuées. En règle générale, les bases de données distribuées ont des index locaux, de sorte que chaque nœud a un index de ses propres données. Dans Xpand, les index sont distribués et stockés indépendamment de la table. Cela élimine le besoin d'envoyer une requête à tous les nœuds (scatter/gather). Dans l'exemple ci-dessus, le nœud 1 contient les lignes 2 et 4 de la table, ainsi que les index des lignes 32 et 35 et les lignes avril et mars. La table et les index sont découpés, distribués et répliqués indépendamment sur les nœuds.
Le moteur de requête utilise les index distribués pour déterminer où trouver les données. Il recherche uniquement les partitions d'index nécessaires, puis envoie des requêtes uniquement aux emplacements où résident les données nécessaires. Les requêtes sont toutes distribuées. Ils sont effectués simultanément et en parallèle. Leur destination dépend entièrement des données et de ce qui est nécessaire pour résoudre la requête.
Toutes les tranches sont répliquées au moins deux fois. Pour chaque tranche, il existe des répliques résidant sur d'autres nœuds. Par défaut, il y aura trois copies de ces données :la tranche et deux répliques. Chaque copie se trouvera sur un nœud différent, et si vous exécutiez dans plusieurs zones de disponibilité, ces copies se trouveraient également dans différentes zones de disponibilité.
Gestion de la lecture et de l'écriture
Prenons un autre exemple. Dans la figure 3, nous avons cinq instances de MariaDB Enterprise Server avec Xpand (nœuds). Il y a une table pour stocker les profils des clients. La tranche avec le profil de Shane est sur le nœud n°1 avec des copies sur le nœud n°3 et le nœud n°5. Les requêtes peuvent arriver sur n'importe quel nœud et seront traitées différemment selon qu'il s'agit de lectures ou d'écritures.
Les écritures sont effectuées sur toutes les copies de manière synchrone à l'intérieur d'une transaction distribuée. Chaque fois que je mets à jour mon profil "Shane" parce que j'ai changé d'e-mail ou d'adresse, ces écritures vont à toutes les copies en même temps dans une transaction. C'est ce qui donne une forte cohérence.
Dans la figure 3, l'instruction UPDATE est allée au nœud #2. Il n'y a rien sur le nœud 2 concernant mon profil, mais le nœud 2 sait où se trouve mon profil et envoie des mises à jour aux nœuds 1, 3 et 5, puis valide cette transaction et revient à l'application.
Les lectures sont gérées différemment. Dans le diagramme, la tranche avec mon profil dessus se trouve sur le nœud n°1 avec des copies sur le nœud n°3 et le nœud n°5. Cela fait du nœud n°1 la réplique de classement. Chaque tranche a une réplique de classement, qui pourrait être considérée comme le nœud qui « possède » les données. Par défaut, quel que soit le nœud sur lequel une lecture arrive, elle va toujours au réplica de classement, donc chaque SELECT qui me résout ira au nœud #1.
Fournir de l'élasticité
Les bases de données distribuées comme Xpand changent et évoluent en permanence en fonction des données de l'application. Le processus de rééquilibrage est chargé d'adapter la distribution des données aux besoins actuels et de maintenir la distribution optimale des tranches entre les nœuds. Il existe trois scénarios généraux qui nécessitent une redistribution :l'ajout de nœuds, la suppression de nœuds et la prévention des charges de travail inégales ou des "points chauds".
Par exemple, supposons que nous fonctionnions avec trois nœuds, mais que nous constatons que le trafic augmente et que nous devons évoluer - nous ajoutons un quatrième nœud pour gérer le trafic. Le nœud 4 est vide lorsque nous l'ajoutons, comme illustré à la figure 4. Le rééquilibreur déplace automatiquement les tranches et les répliques pour utiliser le nœud 4, comme illustré à la figure 5.
Si le nœud #4 tombe en panne, le rééquilibreur se remet automatiquement en marche ; cette fois en recréant des tranches à partir de leurs répliques. Aucune donnée n'est perdue. Les répliques sont également recréées pour remplacer celles qui résidaient sur le nœud n° 4, de sorte que toutes les tranches ont à nouveau des répliques sur d'autres nœuds pour garantir une haute disponibilité.
Figure 6. Si un nœud tombe en panne, le rééquilibreur Xpand recrée les tranches et les répliques qui résidaient sur le nœud défaillant à partir des données de réplique sur les autres nœuds.
Équilibrer la charge de travail
En plus de l'évolutivité horizontale et de la haute disponibilité, le rééquilibreur atténue la répartition inégale de la charge de travail, qu'il s'agisse de points chauds ou de sous-utilisation. Même lorsque les données sont distribuées de manière aléatoire avec un algorithme de hachage parfait, des points chauds peuvent se produire. Par exemple, il peut arriver par hasard que les 10 produits en vente ce mois-ci se trouvent sur le nœud n°1. Les données sont réparties uniformément, mais la charge de travail ne l'est pas (Figure 7). Dans ce type de scénario, le rééquilibreur redistribue les tranches pour équilibrer l'utilisation des ressources (Figure 8).
Figure 7. Xpand a réparti uniformément les données, mais la charge de travail est inégale. Le nœud 1 a une charge de travail nettement plus élevée que les trois autres nœuds.
Figure 8. Le rééquilibreur Xpand redistribue les tranches de données pour équilibrer la charge de travail entre les nœuds.
Évolutivité, rapidité, disponibilité, équilibre
Les besoins d'information et de traitement continueront de croître. C'est une donnée. MariaDB Xpand fournit une solution de mise à l'échelle cohérente et conforme à ACID pour les entreprises dont les exigences ne peuvent pas être satisfaites avec d'autres alternatives telles que la réplication et le sharding.
Le SQL distribué offre une évolutivité et MariaDB Xpand offre la flexibilité de choisir le niveau d'évolutivité dont vous avez besoin. Distribuez une table ou plusieurs tables ou même toute votre base de données, le choix vous appartient. Sur le plan opérationnel, la capacité est facilement ajustée pour répondre à l'évolution des demandes de charge de travail à tout moment. Vous ne devez jamais être sur-provisionné.
Xpand protège également de manière transparente contre l'utilisation inégale des ressources, en redistribuant dynamiquement les données pour équilibrer la charge de travail entre les nœuds et éviter les points chauds. Pour les développeurs, il n'y a pas besoin de se soucier de l'évolutivité et des performances. Xpand est élastique. Xpand offre également une redondance et une haute disponibilité. Avec des données découpées, répliquées et distribuées sur les nœuds, les données sont protégées et la redondance est maintenue en cas de panne matérielle.
Et, avec l'architecture de MariaDB, vos tables distribuées joueront bien - y compris les JOIN inter-moteurs - avec vos autres tables MariaDB. Créez la solution de base de données dont vous avez besoin en mélangeant et en faisant correspondre des tables répliquées, distribuées ou en colonnes sur une seule base de données sur la plate-forme MariaDB.
