MySQL Sharding vs MySQL Cluster

13

En considérant uniquement les performances , un cluster MySQL peut-il battre une solution MySQL de partage de données personnalisé? sharding = partitionnement horizontal

Lorsque je parle de partitionnement, je considère le partitionnement effectué dans la couche application, par exemple, en répartissant les enregistrements de manière égale entre les instances MySQL indépendantes. Pour deux serveurs, cela pourrait être (mod clé 2).

mysql ndbcluster gsb
la source

Réponses:

21

Divulgation: Je suis un employé MySQL, travaillant sur MySQL Cluster.

Je dirais que MySQL Cluster pourrait atteindre un débit / hôte plus élevé que MySQL + InnoDB fragmenté à condition que:

  • Les requêtes sont simples
  • Toutes les données tiennent en mémoire

En termes de latence, MySQL Cluster devrait avoir une latence plus stable que MySQL fragmenté. La latence réelle pour les données purement en mémoire peut être similaire.

À mesure que les requêtes deviennent plus complexes et que les données sont stockées sur disque, la comparaison des performances devient plus confuse. Pour obtenir une réponse plus précise, vous devez décrire davantage votre application et les requêtes que vous effectuez, ainsi que le nombre d'hôtes et le volume de données. MySQL Cluster a récemment gagné l'exécution parallèle de requêtes localisées (AQL), ​​ce qui signifie qu'il peut être compétitif avec MySQLD autonome malgré la distribution de données sur plusieurs hôtes.

Le cluster MySQL est actuellement limité au «partage» de plus de 48 hôtes. Sharded MySQL n'a en théorie aucune limite. Cependant, pour un débit cible donné, moins d'hôtes MySQL Cluster peuvent être nécessaires que les hôtes MySQL partagés.

Les différences les plus intéressantes concernent les domaines autres que les performances:

  • MySQL Cluster prend en charge les requêtes arbitraires sur tous les fragments
  • MySQL Cluster prend en charge les transactions arbitraires sur tous les fragments
  • MySQL Cluster prend en charge la réplication synchrone des fragments avec basculement et récupération automatiques
  • MySQL Cluster prend en charge le nœud d'ajout en ligne (extension de cluster)
  • Sharded MySQL est plus «roule toi-même»

L'intégration de la partition dans votre application vous offre un potentiel de mise à l'échelle maximal, mais ajoute de la complexité et limite votre flexibilité en termes de requêtes et d'opérations entre partitions. Si votre partition est prématurée, cela peut être à l'origine de certains problèmes pour vous. MySQL Cluster vous permet d'obtenir certains des avantages du partage sans avoir à contraindre votre application à être un seul fragment.

Concernant la réponse précédente, quelques précisions:

"Bien que MySQL Cluster soit conforme à ACID, il ne fournit pas de moteur de stockage approprié pour les données avec des clés composées."

MySQL Cluster prend en charge les clés primaires et secondaires composées. Je ne sais pas ce qui ne convient pas. Peut-être que l'affiche précédente peut expliquer?

"Afin d'avoir des données avec les mêmes caractéristiques clés stockées dans un ensemble particulier de nœuds de données, vous pouvez effectuer les opérations suivantes:

  1. Mettez tous les nœuds de données hors ligne, en ne laissant que les nœuds de données dont vous souhaitez héberger les données avec les mêmes caractéristiques clés.
  2. Chargez vos données dans le cluster MySQL, qui ne remplit que vos nœuds de données sélectionnés
  3. Remettez tous les nœuds de données en ligne "

Ceci est une erreur. La distribution des données est indépendante des nœuds qui sont en ligne à tout moment. MySQL Cluster prend en charge divers schémas de distribution de données pour prendre en charge les optimisations que vous décrivez. Je décris la distribution des données dans MySQL Cluster dans un article de blog ici: Distribution des données dans MySQL Cluster

Frazer Clement
la source
Hé, Frazier. J'ai lu le lien que vous avez fourni. Juste pour la clarification, mon commentaire sur la «clé composée» était basé sur des index non uniques. La société de mon employeur a essayé MySQL Cluster vers le premier trimestre 2007 et ne l'aimait pas en raison de ses faibles performances. À mon humble avis, c'était le mauvais choix du client pour les clés (petites cardinalités) et ses requêtes. Le cluster MySQL doit avoir évolué depuis lors en fonction de votre lien. Quant à ma deuxième déclaration, c'est le nombre d'utilisateurs de MongoDB qui remplissent des fragments spécifiques. Certains clients de mon employeur l'ont fait avec leurs configurations MySQL personnalisées.
RolandoMySQLDBA
Dans votre lien, il a mentionné «un balayage d'index ordonné» qui n'a pas pu être élagué, car les lignes correspondantes ne sont pas garanties d'être stockées dans un fragment de table. C'est pourquoi je proposais d'isoler les données en fragments spécifiques (nœuds de données) pour minimiser les endroits où les données se répandraient. Puisque votre réponse fait ressortir le côté positif de MySQL Cluster, elle correspond mieux à la question publiée d'origine. Ma réponse est en faveur de la prudence, du pessimisme et de la naïveté actuelle de la puissance du cluster MySQL.
RolandoMySQLDBA
Au lieu de mes diatribes et délires, +1 pour votre réponse !!!
RolandoMySQLDBA
Salut Rolando, Merci d'avoir clarifié vos déclarations. Il est vrai que les analyses d'index ordonnées non élaguées sont «coûteuses» dans Cluster, car tous les nœuds de données sont impliqués. Il semble que ces analyses sur des indices de cardinalité faibles seraient coûteuses sur n'importe quel système, mais sur Cluster, elles sont devenues visiblement coûteuses. Votre prudence et votre pessimisme vous ont sans doute sauvé plus d'une fois :) Merci pour le +1
Frazer Clement