La base de données relationnelle peut-elle évoluer horizontalement
Après quelques recherches sur Google, j'ai trouvé:
Note de documentation mysql :
MySQL Cluster scinde (partitionne) automatiquement les tables sur les nœuds, permettant aux bases de données d'évoluer horizontalement sur du matériel de base à faible coût pour servir des charges de travail gourmandes en lecture et en écriture, accessibles à partir de SQL et directement via les API NoSQL.
La base de données relationnelle peut-elle être mise à l'échelle horizontale? Sera-t-il basé sur la base de données NoSQL?
Quelqu'un a-t-il un exemple concret?
Comment puis-je gérer les requêtes SQL, les transactions, etc. dans une telle base de données?
Je pense que la réponse est sans équivoque oui. Vous devez garder à l'esprit que SQL est simplement un langage d'accès aux données. Il n'y a absolument aucune raison de ne pas l'étendre sur plusieurs ordinateurs et partitions réseau. Est-ce un problème difficile? Très certainement, et c'est pourquoi le logiciel qui le fait est à ses balbutiements.
Maintenant, je pense que ce que vous essayez de demander est "Est-ce que toutes les fonctionnalités que je connais et qui arrivent dans un système de gestion de base de données relationnelle de type SQL standard peuvent être développées pour fonctionner avec plusieurs serveurs de cette manière?" Bien que j'admette que je n'ai pas étudié le problème en profondeur, il existe des théorèmes qui disent "Non, cela ne peut pas". Théorème de cohérence-disponibilité-partition postule que nous ne pouvons pas avoir les trois qualités au même niveau.
Maintenant, à toutes fins pratiques, le "partage" ou le "partitionnement" ou tout ce que vous voulez appeler ne disparaîtra pas; au contraire. Cela signifie que, compte tenu du degré de validité du théorème de la PAC, nous allons devoir changer notre façon de penser les bases de données et la façon dont nous interagissons avec elles (au moins dans une certaine mesure). De nombreux développeurs ont déjà effectué le virage nécessaire pour réussir sur une plateforme No-SQL, mais beaucoup d'autres ne l'ont pas fait. En fin de compte, une maturité suffisante du modèle et des solutions de contournement suffisamment efficaces seront développées pour que les bases de données SQL traditionnelles, dans le sens que vous référez, soient plus ou moins pratiques sur plusieurs machines. Cela commence déjà à se dérouler, et je dirais de lui donner quelques années de plus et nous en serons là. Ou nous aurons collectivement déplacé la pensée au point où elle ne sera plus nécessaire, et le monde sera un meilleur endroit. :)
C'est possible mais demande beaucoup d'efforts de maintenance, Explication -
Mise à l'échelle verticale des données (synonyme de normalisation dans les bases de données SQL) est appelé fractionnement des colonnes de données en plusieurs tables afin de réduire la redondance d'espace. Exemple de table utilisateur -
Mise à l'échelle horizontale des données (synonyme de partage) est appelé fractionnement des lignes en plusieurs tables afin de réduire le temps nécessaire pour récupérer les données. Exemple de table utilisateur -
Le point clé à noter ici est car nous pouvons voir que les tables dans les bases de données SQL sont normalisées en plusieurs tables de données connexes. Afin de partager les données d'une telle table sur plusieurs machines, vous devez fractionner les données normalisées associées en conséquence, ce qui augmenterait les efforts de maintenance. Comme dans l'exemple présenté ci-dessus de la base de données SQL,
Table client qui est liée comme une relation un à plusieurs avec la table Commande
Si vous déplacez certaines lignes de données client sur une autre machine (appelée partitionnement), vous devrez également déplacer ses données de commande associées sur la même machine, ce qui serait une tâche difficile en cas de plusieurs tables liées.
C'est pratique pour les bases de données NOSQL à fragmenter car elles suivent une structure de table plate (les données sont stockées sous forme agrégée plutôt que sous forme normalisée).
Merci pour la question et la réponse. J'essayais d'expliquer cela à quelqu'un comme ça:
En termes de théorème CAP, vous ne pouvez pas avoir les trois. Ainsi, lorsqu'une partition (panne de réseau ou de serveur) se produit:
UNE
relational databasesur un seul serveur vous donneC(cohérence). Donc quand unP(partition - panne serveur/réseau) se produit, vous ne pouvez pas avoirA(disponibilité - db descend)UNE
nosql datastorevous donneA, donc quand unPse produit, vous ne pouvez pas avoirC(une ou plusieurs de vos partitions répliquées seront désynchronisées, jusqu'à ce que le n/w revient et ils se synchronisent tous). Ce ne sera donc queeventually consistent
Google Spanner est un exemple de base de données relationnelle pouvant évoluer horizontalement. Le partage et la réplication se font automatiquement, donc pas besoin de vous en soucier. Pour plus d'informations, veuillez consulter ceci papier .