Pourquoi le cluster RDBM ne peut-il pas fonctionner comme NoSQL?
L'un des gros avantages du SGBD nosql est qu'il peut se regrouper plus facilement. Soi-disant avec NoSQL, vous pouvez créer des centaines de machines bon marché qui stockent différentes données et les interrogent en une seule fois.
Ma question est la suivante: pourquoi un SGBD relationnel ne peut-il pas faire cela comme mysql ou sql server? Est-ce que les fournisseurs n'ont tout simplement pas trouvé de moyen technique de le faire avec leur produit existant, ou y a-t-il un problème avec le modèle relationnel qui empêche que cela soit possible? Qu'y a-t-il de si génial dans la façon NoSQL de stocker et d'accéder aux données (clé/valeur, documents, etc.) qui facilite le clustering, si cela est vrai?
Systèmes de bases de données distribuées 101
Ou, Bases de données distribuées - que signifie réellement le FK ' échelle Web '?
Les systèmes de bases de données distribuées sont des créatures complexes et se déclinent en différentes versions. Si je fouille dans les profondeurs de mes études vaguement mémorisées à ce sujet à l'université, j'essaierai d'expliquer certains des principaux problèmes d'ingénierie liés à la construction d'un système de base de données distribué.
Tout d'abord, une terminologie
Propriétés ACID (atomicité, cohérence, isolation et durabilité): Ce sont les principaux invariants qui doivent être appliqués pour une transaction être mis en œuvre de manière fiable sans provoquer d'effets secondaires indésirables.
( Atomicité nécessite que la transaction soit terminée ou annulée complètement. Les transactions partiellement terminées ne devraient jamais être visibles, et le système doit être construit de manière à éviter que cela ne se produise.
Cohérence requiert qu'une transaction ne viole jamais les invariants (tels que l'intégrité référentielle déclarative) qui sont garantis par le schéma de la base de données. Par exemple, s'il existe une clé étrangère, il devrait être impossible d'insérer un enregistrement enfant avec un respect pour un parent inexistant.
L'isolement nécessite que les transactions ne s'interfèrent pas entre elles. Le système doit garantir les mêmes résultats si les transactions sont exécutées en parallèle ou séquentiellement. Dans la pratique, la plupart des produits SGBDR autorisent des modes qui compromis l'isolement contre les performances.
Durabilité nécessite qu'une fois validée, la transaction reste dans un stockage persistant d'une manière robuste aux pannes matérielles ou logicielles.
J'expliquerai ci-dessous certains des obstacles techniques que ces exigences présentent sur les systèmes distribués.
Architecture de disque partagé: Une architecture dans laquelle tous les nœuds de traitement d'un cluster ont accès à tout le stockage. Cela peut présenter un goulot d'étranglement central pour l'accès aux données. Un exemple de système à disque partagé est Oracle RAC ou Exadata .
Architecture de partage rien: Une architecture dans laquelle les nœuds de traitement d'un cluster ont un stockage local qui n'est pas visible pour les autres nœuds du cluster. Des exemples de systèmes à partage rien sont Teradata et Netezza .
Architecture de mémoire partagée: Une architecture dans laquelle plusieurs CPU (ou nœuds) peuvent accéder à un pool de mémoire partagé. La plupart des serveurs modernes sont de type mémoire partagée. La mémoire partagée facilite certaines opérations telles que les caches ou les primitives de synchronisation atomique qui sont beaucoup plus difficiles à faire sur les systèmes distribués.
Synchronisation: Terme générique décrivant diverses méthodes pour assurer un accès cohérent à une ressource partagée par plusieurs processus ou threads. C'est beaucoup plus difficile à faire sur des systèmes distribués que sur des systèmes à mémoire partagée, bien que certaines architectures de réseau (par exemple le BYNET de Teradata) aient des primitives de synchronisation dans le protocole réseau. La synchronisation peut également s'accompagner d'une surcharge importante.
Semi-jointure: Une primitive utilisée pour joindre des données contenues dans deux nœuds différents d'un système distribué. Elle consiste essentiellement en suffisamment d'informations sur les lignes à joindre regroupées et transmises par un nœud à l'autre afin de résoudre la jointure. Sur une requête volumineuse, cela pourrait impliquer un trafic réseau important.
Cohérence éventuelle: Un terme utilisé pour décrire la sémantique des transactions qui compromis la mise à jour immédiate (cohérence sur les lectures) sur tous les nœuds d'un système distribué pour les performances (et donc un débit de transaction plus élevé) sur les écritures. La cohérence éventuelle est un effet secondaire de l'utilisation de réplication de quorum comme optimisation des performances pour accélérer les validations de transactions dans les bases de données distribuées où plusieurs copies de données sont conservées sur des nœuds distincts.
Algorithme de Lamport: Un algorithme pour implémenter l'exclusion mutuelle (synchronisation) sur des systèmes sans mémoire partagée. Normalement, l'exclusion mutuelle dans un système nécessite une instruction atomique de lecture-comparaison-écriture ou similaire d'un type normalement pratique uniquement sur un système de mémoire partagée. Il existe d'autres algorithmes de synchronisation distribuée, mais celui de Lamport a été l'un des premiers et est le plus connu. Comme la plupart des mécanismes de synchronisation distribués, l'algorithme de Lamport dépend fortement de la synchronisation précise de la synchronisation et de l'horloge entre les nœuds de cluster.
Validation en deux phases (2PC): Une famille de protocoles qui garantissent que les mises à jour de la base de données impliquant plusieurs systèmes physiques sont validées ou annulées de manière cohérente . Que 2PC soit utilisé au sein d'un système ou sur plusieurs systèmes via un gestionnaire de transactions, il entraîne une surcharge importante.
Dans un protocole de validation en deux phases, le gestionnaire de transactions demande aux nœuds participants de conserver la transaction de manière à pouvoir garantir qu'elle sera validée, puis de signaler ce statut. Lorsque tous les nœuds ont renvoyé un statut "heureux", il signale ensuite aux nœuds de s'engager. La transaction est toujours considérée comme ouverte jusqu'à ce que tous les nœuds envoient une réponse indiquant que la validation est terminée. Si un nœud tombe en panne avant de signaler que la validation est terminée, le gestionnaire de transactions interroge à nouveau le nœud lorsqu'il revient jusqu'à ce qu'il obtienne une réponse positive indiquant que la transaction a été validée.
Contrôle de concurrence multi-version (MVCC): Gérer les conflits en écrivant de nouvelles versions des données à un emplacement différent et en autorisant d'autres transactions pour voir l'ancienne version des données jusqu'à ce que la nouvelle version soit validée. Cela réduit les conflits de base de données au détriment d'un trafic d'écriture supplémentaire pour écrire la nouvelle version, puis marquer l'ancienne version comme obsolète.
Algorithme d'élection: Les systèmes distribués impliquant plusieurs nœuds sont intrinsèquement moins fiables qu'un seul système car il y a plus de modes de défaillance. Dans de nombreux cas, un mécanisme est nécessaire pour que les systèmes en cluster gèrent la défaillance d'un nœud. Les algorithmes électoraux sont une classe d'algorithmes utilisés pour sélectionner un leader pour coordonner un calcul distribué dans des situations où le nœud "leader" n'est pas déterminé ou fiable à 100%.
Partitionnement horizontal: Une table peut être divisée en plusieurs nœuds ou volumes de stockage par sa clé. Cela permet à un grand volume de données d'être divisé en petits morceaux et répartis sur les nœuds de stockage.
Partage: Un ensemble de données peut être partitionné horizontalement sur plusieurs nœuds physiques dans une architecture de partage rien. Lorsque ce partitionnement n'est pas transparent (c'est-à-dire que le client doit être conscient du schéma de partition et déterminer quel nœud interroger explicitement), cela s'appelle le partitionnement. Certains systèmes (par exemple Teradata) divisent les données entre les nœuds mais l'emplacement est transparent pour le client; le terme n'est normalement pas utilisé en conjonction avec ce type de système.
Hachage cohérent: Un algorithme utilisé pour allouer des données aux partitions en fonction de la clé. Il se caractérise par une distribution uniforme des clés de hachage et la capacité d'élargir ou de réduire élastiquement le nombre de compartiments de manière efficace. Ces attributs le rendent utile pour partitionner des données ou charger sur un cluster de nœuds où la taille peut changer dynamiquement avec l'ajout ou la suppression de nœuds du cluster (peut-être en raison d'une défaillance).
Réplication multimaître: Une technique qui permet de répliquer les écritures sur plusieurs nœuds d'un cluster sur les autres nœuds. Cette technique facilite la mise à l'échelle en permettant à certaines tables d'être partitionnées ou partagées sur les serveurs et d'autres d'être synchronisées sur le cluster. Les écritures doivent être répliquées sur tous les nœuds par opposition à un quorum, de sorte que les validations de transactions sont plus coûteuses sur une architecture répliquée multimaître que sur un système répliqué en quorum.
Commutateur non bloquant: Commutateur réseau qui utilise le parallélisme matériel interne pour obtenir un débit proportionnel au nombre de ports avec pas de goulots d'étranglement internes. Une implémentation naïve peut utiliser un mécanisme crossbar, mais cela a une complexité O (N ^ 2) pour N ports, le limitant à des commutateurs plus petits. Les commutateurs plus grands peuvent utiliser une topologie interne plus complexe appelée commutateur à étendue minimale non bloquante pour obtenir une mise à l'échelle de débit linéaire sans avoir besoin de matériel O (N ^ 2).
Créer un SGBD distribué - quelle difficulté cela peut-il être?
Plusieurs défis techniques rendent cela assez difficile à faire dans la pratique. Outre la complexité supplémentaire de la construction d'un système distribué, l'architecte d'un SGBD distribué doit surmonter certains problèmes d'ingénierie délicats.
Atomicité sur les systèmes distribués: Si les données mises à jour par une transaction sont réparties sur plusieurs nœuds, la validation/restauration des nœuds doit être coordonnée. Cela ajoute un surcoût important sur les systèmes de partage de rien. Sur les systèmes à disque partagé, cela pose moins de problème car tout le stockage peut être vu par tous les nœuds, de sorte qu'un seul nœud peut coordonner la validation.
Cohérence sur les systèmes distribués: Pour prendre l'exemple de clé étrangère cité ci-dessus, le système doit être capable d'évaluer un état cohérent. Par exemple, si le parent et l'enfant d'une relation de clé étrangère peuvent résider sur des nœuds différents, une sorte de mécanisme de verrouillage distribué est nécessaire pour garantir que les informations obsolètes ne sont pas utilisées pour valider la transaction. Si cela n'est pas appliqué, vous pourriez avoir (par exemple) une condition de concurrence critique où le parent est supprimé après que sa présence est vérifiée avant d'autoriser l'insertion de l'enfant.
L'application retardée des contraintes (c'est-à-dire l'attente de la validation pour valider DRI) nécessite que le verrou soit maintenu pendant la durée de la transaction. Ce type de verrouillage distribué s'accompagne d'une surcharge importante.
Si plusieurs copies de données sont conservées (cela peut être nécessaire sur des systèmes sans partage pour éviter le trafic réseau inutile des semi-jointures), toutes les copies des données doivent être mises à jour.
Isolement sur les systèmes distribués: Lorsque les données affectées sur une transaction résident sur plusieurs nœuds système, les verrous et la version (si MVCC est utilisé) doivent être synchronisés sur nœuds. Garantir la serialisabilité des opérations, en particulier sur les architectures de partage de rien où des copies redondantes de données peuvent être stockées, nécessite un mécanisme de synchronisation distribué tel que l'algorithme de Lamport, qui s'accompagne également d'une surcharge importante dans le trafic réseau.
Durabilité sur les systèmes distribués: Sur un système de disque partagé, le problème de durabilité est essentiellement le même qu'un système à mémoire partagée, à l'exception des protocoles de synchronisation distribués toujours requis sur les nœuds. Le SGBD doit journaliser les écritures dans le journal et écrire les données de manière cohérente. Sur un système sans partage, il peut y avoir plusieurs copies des données ou des parties des données stockées sur différents nœuds. Un protocole de validation en deux phases est nécessaire pour garantir que la validation se déroule correctement sur les nœuds. Cela entraîne également des frais généraux importants.
Sur un système à partage rien, la perte d'un nœud peut signifier que les données ne sont pas disponibles pour le système. Pour atténuer ces données, elles peuvent être répliquées sur plusieurs nœuds. La cohérence dans cette situation signifie que les données doivent être répliquées sur tous les nœuds où elles résident normalement. Cela peut entraîner des frais généraux importants sur les écritures.
Une optimisation courante faite dans les systèmes NoSQL est l'utilisation de la réplication de quorum et de la cohérence éventuelle pour permettre la réplication paresseuse des données tout en garantissant un certain niveau de résilience des données en écrivant dans un quorum avant de signaler la transaction comme validée. Les données sont ensuite répliquées paresseusement vers les autres nœuds où résident des copies des données.
Notez que la "cohérence éventuelle" est un compromis majeur sur la cohérence qui peut ne pas être acceptable si les données doivent être consultées de manière cohérente dès que la transaction est validée. Par exemple, sur une application financière, un solde mis à jour doit être disponible immédiatement.
Systèmes à disque partagé
Un système à disque partagé est un système où tous les nœuds ont accès à tout le stockage. Ainsi, le calcul est indépendant de l'emplacement. De nombreuses plates-formes SGBD peuvent également fonctionner dans ce mode - Oracle RAC est un exemple d'une telle architecture.
Les systèmes de disques partagés peuvent évoluer considérablement car ils peuvent prendre en charge une relation M: M entre les nœuds de stockage et les nœuds de traitement. A SAN peut avoir plusieurs contrôleurs et plusieurs serveurs peuvent exécuter la base de données. Ces architectures ont un commutateur comme goulot d'étranglement central mais les commutateurs crossbar permettent à ce commutateur d'avoir beaucoup de bande passante. Certains traitements peuvent être déchargés sur les nœuds de stockage (comme dans le cas d'Exadata d'Oracle), ce qui peut réduire le trafic sur la bande passante de stockage.
Bien que le commutateur soit théoriquement un goulot d'étranglement, la bande passante disponible signifie que les architectures de disques partagés s'adapteront assez efficacement à de gros volumes de transactions. La plupart des architectures de SGBD traditionnelles adoptent cette approche car elle offre une évolutivité "suffisamment bonne" et une fiabilité élevée. Avec une architecture de stockage redondante telle que Fibre Channel, il n'y a pas de point de défaillance unique car il existe au moins deux chemins entre un nœud de traitement et un nœud de stockage.
Systèmes de partage rien
Les systèmes sans partage sont des systèmes où au moins certaines des données sont conservées localement sur un nœud et ne sont pas directement visibles par les autres nœuds. Cela supprime le goulot d'étranglement d'un commutateur central, permettant à la base de données d'évoluer (au moins en théorie) avec le nombre de nœuds. Le partitionnement horizontal permet de diviser les données entre les nœuds; cela peut être transparent pour le client ou non (voir Sharding ci-dessus).
Étant donné que les données sont intrinsèquement distribuées, une requête peut nécessiter des données provenant de plusieurs nœuds. Si une jointure a besoin de données provenant de différents nœuds, une opération de semi-jointure est utilisée pour transférer suffisamment de données pour prendre en charge la jointure d'un nœud à un autre. Cela peut entraîner une grande quantité de trafic réseau, donc l'optimisation de la distribution des données peut faire une grande différence pour les performances des requêtes.
Souvent, les données sont répliquées sur les nœuds d'un système sans partage pour réduire la nécessité de semi-jointures. Cela fonctionne assez bien sur les appliances d'entrepôt de données car les dimensions sont généralement beaucoup plus petites que les tables de faits et peuvent être facilement répliquées sur les nœuds. Ils sont également généralement chargés par lots, de sorte que la surcharge de réplication pose moins de problèmes qu'elle ne le serait sur une application transactionnelle.
Le parallélisme inhérent d'une architecture de partage de rien les rend bien adaptés au type de requêtes de balayage de table/agrégat caractéristiques d'un entrepôt de données. Ce type d'opération peut évoluer de façon presque linéaire avec le nombre de nœuds de traitement. Les jointures volumineuses entre les nœuds ont tendance à entraîner plus de frais généraux, car les opérations de semi-jointure peuvent générer beaucoup de trafic réseau.
Le déplacement de gros volumes de données est moins utile pour les applications de traitement des transactions, où la surcharge de plusieurs mises à jour rend ce type d'architecture moins attrayant qu'un disque partagé. Ainsi, ce type d'architecture a tendance à ne pas être largement utilisé dans les applications d'entrepôt de données.
Partage, réplication de quorum et cohérence éventuelle
La réplication de quorum est une installation où un SGBD réplique les données pour une haute disponibilité. Ceci est utile pour les systèmes destinés à fonctionner sur du matériel de base moins cher qui n'a pas de fonctionnalités intégrées à haute disponibilité comme un SAN. Dans ce type de système, les données sont répliquées sur plusieurs nœuds de stockage pour des performances de lecture et un stockage redondant afin de rendre le système résilient aux pannes matérielles d'un nœud.
Cependant, la réplication des écritures sur tous les nœuds est O (M x N) pour M nœuds et N écritures. Cela rend les écritures coûteuses si l'écriture doit être répliquée sur tous les nœuds avant qu'une transaction ne soit validée. La réplication de quorum est un compromis qui permet de répliquer des écritures sur un sous-ensemble de nœuds immédiatement, puis de les écrire paresseusement sur les autres nœuds par une tâche en arrière-plan. Les écritures peuvent être validées plus rapidement, tout en offrant un certain degré de redondance en garantissant qu'elles sont répliquées dans un sous-ensemble minimal (quorum) de nœuds avant que la transaction ne soit signalée comme validée pour le client.
Cela signifie que les lectures des nœuds en dehors du quorum peuvent voir des versions obsolètes des données jusqu'à ce que le processus d'arrière-plan ait terminé d'écrire des données dans le reste des nœuds. La sémantique est connue sous le nom de "cohérence éventuelle" et peut être acceptable ou non en fonction des exigences de votre application, mais signifie que les validations de transaction sont plus proches de O(1) que O(n) d'utilisation des ressources.
Le sharding nécessite que le client soit conscient du partitionnement des données dans les bases de données, en utilisant souvent un type d'algorithme appelé "hachage cohérent". Dans une base de données fragmentée, le client hache la clé pour déterminer à quel serveur du cluster envoyer la requête. Comme les demandes sont réparties sur les nœuds du cluster, il n'y a pas de goulot d'étranglement avec un nœud de coordinateur de requête unique.
Ces techniques permettent à une base de données d'évoluer à une vitesse quasi linéaire en ajoutant des nœuds au cluster. Théoriquement, la réplication de quorum n'est nécessaire que si le support de stockage sous-jacent doit être considéré comme non fiable. Ceci est utile si des serveurs de base doivent être utilisés, mais il est moins utile si le mécanisme de stockage sous-jacent a son propre schéma de haute disponibilité (par exemple, un SAN avec des contrôleurs en miroir et une connectivité à chemins multiples vers le hôtes).
Par exemple, BigTable de Google n'implémente pas la réplication de quorum par lui-même, bien qu'il repose sur GFS, un système de fichiers en cluster qui utilise la réplication de quorum. BigTable (ou tout système de partage de rien) pourrait utiliser un système de stockage fiable avec plusieurs contrôleurs et partitionner les données entre les contrôleurs. Un accès parallèle serait alors obtenu grâce au partitionnement des données.
Retour aux plateformes RDBMS
Il n'y a aucune raison inhérente que ces techniques ne puissent pas être utilisées avec un SGBDR. Cependant, la gestion des verrous et des versions serait assez complexe sur un tel système et tout marché pour un tel système est susceptible d'être assez spécialisé. Aucune des plates-formes RDBMS traditionnelles n'utilise la réplication de quorum et je ne connais pas spécifiquement de produit RDBMS (du moins pas avec une adoption significative) qui le fasse.
Les systèmes à disque partagé et sans partage peuvent évoluer jusqu'à de très grandes charges de travail. Par exemple, Oracle RAC peut prendre en charge 63 nœuds de traitement (qui peuvent être de grandes machines SMP à part entière) et un nombre arbitraire de contrôleurs de stockage sur le SAN. Un IBM Sysplex (un cluster de mainframes zSeries) peut prendre en charge plusieurs mainframes (chacun avec une puissance de traitement et une bande passante d'E/S propres) et plusieurs SAN contrôleurs. Ces architectures peuvent prendre en charge de très grandes transactions volumes avec la sémantique ACID, bien qu'ils supposent un stockage fiable. Teradata, Netezza et d'autres fournisseurs créent des plates-formes analytiques hautes performances basées sur des conceptions partagées qui s'adaptent à des volumes de données extrêmement importants.
Jusqu'à présent, le marché des plates-formes RDBMS entièrement ACID bon marché mais à très haut volume est dominé par MySQL, qui prend en charge le partage et la réplication multimaître. MySQL n'utilise pas la réplication de quorum pour optimiser le débit d'écriture, les validations de transactions sont donc plus coûteuses que sur un système NoSQL. Le partage permet des débits de lecture très élevés (par exemple, Facebook utilise beaucoup MySQL), donc ce type d'architecture s'adapte bien aux charges de travail lourdes en lecture.
Un débat intéressant
BigTable est une architecture de partage rien (essentiellement une paire clé-valeur distribuée) comme l'a souligné Michael Hausenblas ci-dessous . Mon évaluation initiale comprenait le moteur MapReduce, qui ne fait pas partie de BigTable mais qui serait normalement utilisé en conjonction avec lui dans ses implémentations les plus courantes (par exemple Hadoop/HBase et le framework MapReduce de Google).
En comparant cette architecture avec Teradata, qui a une affinité physique entre le stockage et le traitement (c'est-à-dire que les nœuds ont un stockage local plutôt qu'un SAN partagé), vous pouvez affirmer que BigTable/MapReduce est une architecture de disque partagée via le système de stockage parallèle globalement visible.
Le débit de traitement d'un système de style MapReduce tel que Hadoop est limité par la bande passante d'un commutateur réseau non bloquant.1 Non bloquant les commutateurs peuvent, cependant, gérer des agrégats de large bande passante en raison du parallélisme inhérent à la conception, ils sont donc rarement une contrainte pratique significative sur les performances. Cela signifie qu'une architecture de disque partagé (peut-être mieux appelée système de stockage partagé) peut évoluer vers de grandes charges de travail même si le commutateur réseau est théoriquement un goulot d'étranglement central.
Le point de départ était de noter que bien que ce goulot d'étranglement central existe dans les systèmes à disque partagé, un sous-système de stockage partitionné avec plusieurs nœuds de stockage (par exemple, des serveurs de tablettes BigTable ou SAN contrôleurs)) peut encore évoluer jusqu'à une taille importante. Une architecture de commutateur non bloquante peut (en théorie) gérer autant de connexions actuelles qu'elle a de ports.
1 Bien entendu, le traitement et le débit d'E/S disponibles constituent également une limite de performances, mais le commutateur réseau est un point central par lequel passe tout le trafic.
Les bases de données relationnelles peuvent se regrouper comme les solutions NoSQL. Le maintien des propriétés ACID peut rendre cela plus complexe et il faut être conscient des compromis effectués pour maintenir ces propriétés. Malheureusement, exactement ce que sont les compromis dépend de la charge de travail et bien sûr des décisions prises lors de la conception du logiciel de base de données.
Par exemple, une charge de travail principalement OLTP peut avoir une latence de requête unique supplémentaire, même si le débit du cluster évolue bien. En général, le clustering améliorera le débit et réduira la latence, mais même cette "règle" est suspecte si les requêtes d'une application se prêtent particulièrement au traitement parallèle.
Ce que propose la société pour laquelle je travaille, Clustrix , est une série de nœuds de calcul et de stockage homogènes connectés par un réseau relativement haut débit. Les données relationnelles sont des hachages répartis sur les nœuds sur une base par index en morceaux que nous appelons des "tranches". Chaque tranche aura deux répliques ou plus réparties dans le cluster pour plus de durabilité en cas de défaillance du nœud ou du disque. Les clients peuvent se connecter à n'importe quel nœud du cluster pour émettre des requêtes à l'aide du protocole de connexion MySQL.
Il est un peu naturel de penser indépendamment aux composants d'une base de données ACID, car une grande partie de celle-ci s'accorde, mais voici:
Atomicité - Clustrix utilise des validations en deux phases pour garantir l'atomicité. Les opérations UPDATE et DELETE verrouillent également les lignes via notre gestionnaire de verrouillage distribué car nous transformons en interne ces opérations en SELECT, suivies des opérations UPDATE/DELETE exactes.
L'atomicité augmente évidemment la quantité de messagerie entre les nœuds participant à une transaction et augmente la charge sur ces nœuds pour traiter le protocole de validation. Cela fait partie des frais généraux liés à un système distribué et limiterait l'évolutivité si chaque nœud participait à chaque transaction, mais les nœuds ne participent à une transaction que s'ils ont l'une des répliques en cours d'écriture.
Cohérence - Les clés étrangères sont implémentées en tant que déclencheurs, qui sont évalués au moment de la validation. Les opérations de mise à jour et de suppression à grande échelle peuvent nuire à nos performances en raison du verrouillage, mais nous ne les voyons heureusement pas si souvent. Il est beaucoup plus courant de voir une transaction mettre à jour/supprimer quelques lignes, puis valider.
L'autre partie de la cohérence consiste à maintenir un quorum via le protocole de consensus PAXOS qui garantit que seuls les clusters avec la majorité des nœuds connus sont capables de prendre des écritures. Il est bien sûr possible qu'un cluster ait le quorum mais qu'il manque toujours des données (toutes les répliques d'une tranche hors ligne), ce qui entraînera l'échec des transactions qui accèdent à l'une de ces tranches.
Isolation - Clustrix fournit une isolation MVCC au niveau du conteneur. Notre garantie d'atomicité que toutes les répliques applicables reçoivent une écriture particulière avant de signaler la transaction validée réduit principalement le problème d'isolement à ce que vous auriez dans le cas non groupé.
Durabilité - Chaque tranche de données relationnelles est stockée sur deux nœuds ou plus pour assurer la résilience en cas de défaillance d'un nœud ou d'un disque. Il convient également de noter ici que la version de l'appliance de notre produit possède une carte NVRAM où le WAL est stocké pour des raisons de performances. De nombreuses bases de données à instance unique améliorent les performances de leurs WAL en effectuant des points de contrôle à intervalles plutôt qu'à chaque validation. Cette approche est problématique dans un système distribué car elle fait "rejouer où? une question compliquée. Nous évitons cela dans l'appareil en offrant une garantie de durabilité.
La réponse fondamentale est que le modèle de cohérence est différent. J'écris ceci pour développer la réponse de ConcernedOfTunbridge qui devrait vraiment être le point de référence pour cela.
Le point fondamental du modèle de cohérence ACID est qu'il offre un ensemble de garanties fondamentales quant à l'état des données à l'échelle mondiale dans le système. Ces garanties sont soumises aux limitations du théorème CAP qui signifient, fondamentalement, que pour les faire fonctionner, vous devez avoir toutes les sources faisant autorité sur la même page avant de dire à l'application que vous avez commis une transaction. La réplication multimaître est donc très difficile à faire sans se heurter à ces contraintes. Certes, une fois que vous commencez à faire de la réplication asynchrone dans un environnement multi-maître, ces garanties disparaissent. Le modèle de cohérence ACID est un modèle de cohérence forte destiné aux informations importantes ou critiques.
Le modèle de cohérence BASE est un modèle de cohérence faible destiné aux informations non critiques. Étant donné que les garanties sont considérablement plus faibles, la capacité d'offrir de telles garanties faibles dans les systèmes multimaîtres est plus facilement réalisable car les garanties sont, bien, faibles.
les RDBMS peuvent évoluer et évoluent aussi bien que les solutions NoSQL!
Cependant, il existe des cas où les SGBDR peuvent évoluer et évoluent à un point tel que NoSQL pourrait même ne pas être en mesure de correspondre. Il le fait différemment. Je considérerai Postgres-XC comme un exemple de la façon dont la mise à l'échelle est possible sans sacrifier de solides garanties de cohérence.
La façon dont ces SGBDR particuliers le font consiste à implémenter quelque chose comme une solution de partage avec un proxy et un peu comme une architecture de disque partagée, mais beaucoup plus complexe que les deux. Celles-ci ne sont pas évolutives de la même manière que les solutions NoSQL et les compromis sont donc différents.
Je crois comprendre que le modèle Postgres-XC est inspiré de Teradata. Il se compose de nœuds dans deux rôles différents, en tant que nœuds de stockage ou coordinateurs. Les coordinateurs sont multi-maîtres (aucune réplication réelle n'est impliquée) et ils se connectent aux nœuds de stockage pour gérer le traitement réel des données. Les nœuds de stockage se répliquent dans une configuration maître-esclave. Chaque nœud de stockage contient ce qui est essentiellement un fragment de la base de données, mais les coordinateurs conservent une image cohérente des données.
Une séparation importante des responsabilités est impliquée ici. Les nœuds de stockage gèrent les données, vérifient les contraintes, les contraintes de clé étrangère applicables localement et gèrent au moins une certaine agrégation de données. Les coordinateurs gèrent les clés étrangères qui ne peuvent pas être appliquées localement, ainsi que le fenêtrage et d'autres considérations de données qui peuvent provenir de plusieurs nœuds de données. En substance, les coordinateurs rendent l'ACID possible dans les transactions distribuées dans une configuration multi-maîtres où l'utilisateur ne sait même pas que les transactions sont distribuées.
À cet égard, Postgres-XC offre quelque chose d'un peu comme les options de mise à l'échelle NoSQL, mais il y a une certaine complexité supplémentaire en raison des garanties de cohérence supplémentaires. Je comprends qu'il existe cependant des SGBDR commerciaux qui offrent ce type d'évolutivité. Teradata fait cela. De plus, les systèmes de disques partagés peuvent évoluer de manière similaire et DB2 et Oracle proposent de telles solutions. Il est donc tout à fait injuste de dire que les SGBDR ne peuvent pas faire cela. Ils peuvent. Le besoin a cependant été si faible dans le passé que les économies d'échelle n'ont pas été suffisantes pour rendre les solutions propriétaires très abordables pour la plupart des acteurs.
Enfin une note sur VoltDB. Comme les solutions NoSQL, je vois VoltDB comme un outil très spécialisé. Il est très rapide mais au détriment des transactions aller-retour et de la durabilité sur disque. Cela signifie que vous avez un ensemble de préoccupations très différent. VoltDB est ce que vous obtenez lorsque les pionniers du SGBDR construisent une solution NoSQL ;-). VoltDB est rapide en partie parce qu'il définit la concurrence et la durabilité hors de l'équation. La durabilité devient une propriété de réseau, pas une propriété intra-hôte et la concurrence est gérée en exécutant les requêtes une à la fois, parallélisées en interne, dans un ordre séquentiel. Ce n'est pas un SGBDR traditionnel (et c'est une bonne chose, car il peut aller dans des endroits que le SGBDR traditionnel ne peut pas, mais l'inverse est également très vrai).
Edit: Il est également important de considérer l'implication des jointures. Dans un système en cluster, les jointures deviennent un problème de performances très différent. Si tout se trouve sur le même nœud, ils peuvent améliorer les performances mais si vous devez effectuer un aller-retour vers un nœud différent, cela impose un coût très élevé. Les modèles de données font donc des différences et l'approche du clustering a des impacts sur les performances. Des approches telles que Postgres-XC et Postgres-XL supposent que vous pouvez passer un peu de temps à réfléchir aux choses afin que vous puissiez partager vos données de manière appropriée et conserver les données jointes ensemble. Mais cela impose des frais généraux de conception. D'un autre côté, cela évolue bien mieux que de nombreuses solutions NoSQL et peut être réglé de manière appropriée. Par exemple, nous (chez Adjust) utilisons une stratégie de clustering de type NoSQL pour nos 3,5 Po de données dans PostgreSQL qui est essentiellement une analyse de journal. Et une grande partie de notre conception est profondément inspirée par les stratégies de clustering NoSQL. Parfois, le modèle de données contraint également le modèle de clustering.
Ma réponse ne sera pas aussi bien écrite que la précédente, mais voilà.
Michael Stonebraker de la renommée d'Ingres a créé un magasin de colonnes MPP partagé-rien (Vertica) et une nouvelle base de données SQL partagée-rien MPP (VoltDB) qui distribue les données entre les différents nœuds d'un cluster et gère ACID. Vertica a depuis été achetée par HP.
Je crois que d'autres bases de données New SQL conservent également ACID, bien que je ne sois pas sûr du nombre d'entre elles répartissent leurs lignes sur un cluster, etc.
Voici un exposé donné par Stonebraker sur le nouveau SQL par rapport à NoSQL et "l'ancien SQL". http://www.youtube.com/watch?v=uhDM4fcI2aI
Le clustering MySQL peut partitionner en utilisant la réplication multi-mastering et le hachage des fragments sur le cluster.