Différence entre la mise à l'échelle horizontale et verticale pour les bases de données
J'ai rencontré de nombreuses bases de données NoSQL et SQL. Il existe différents paramètres pour mesurer la force et les faiblesses de ces bases de données, dont l’évolutivité. Quelle est la différence entre la mise à l'échelle horizontale et verticale de ces bases de données?
La mise à l'échelle horizontale signifie que vous mettez à l'échelle en ajoutant plus de machines dans votre pool de ressources, tandis que la mise à l'échelle verticale signifie que vous mettez à l'échelle ajout de plus de puissance (CPU, RAM) à une machine existante .
Une façon simple de s'en souvenir est de penser à une machine sur un rack de serveur. Nous ajoutons plus de machines dans le sens horizontal et ajoutons plus de ressources à une machine. dans le sens vertical .
Dans un monde de bases de données, la mise à l’échelle horizontale est souvent basée sur le partitionnement des données, c’est-à-dire que chaque nœud ne contient qu’une partie des données. le CPU et les RAM ressources de cette machine.
Avec la mise à l'échelle horizontale, il est souvent plus facile de mettre à l'échelle dynamique en ajoutant davantage de machines au pool existant. La mise à l'échelle verticale est souvent limitée à la capacité d'une seule machine.
Cassandra, MongoDB, Google Cloud Spanner .. et MySQL - Amazon RDS (version cloud de MySQL) constituent un bon exemple de redimensionnement horizontal. Il constitue un moyen simple d’évoluer verticalement en passant de petites machines à des machines plus grandes. Ce processus implique souvent des temps d'arrêt.
Les grilles de données en mémoire telles que GigaSpaces XAP , Coherence etc. sont souvent optimisées pour la mise à l'échelle horizontale et verticale simplement parce qu'elles ne sont pas liées au disque. Mise à l'échelle horizontale via le partitionnement et mise à l'échelle verticale grâce à la prise en charge multicœur.
Vous pouvez en lire plus à ce sujet dans mes précédents articles: Extrapage vs Extrapage et Les principes communs derrière les alternatives de NOSQL
En mots simples:
Mise à l'échelle horizontale ===> Des milliers de sbires feront le travail ensemble pour vous.
Mise à l'échelle verticale ===> Une grosse coque fera tout le travail à votre place.
Commençons par le besoin d'une mise à l'échelle qui augmente les ressources afin que votre système puisse maintenant traiter plus de demandes qu'il ne le pouvait auparavant.
Lorsque vous réalisez que votre système ralentit et est incapable de gérer le nombre actuel de demandes, vous devez redimensionner le système.
Cela vous fournit deux options. Soit vous augmentez les ressources du serveur que vous utilisez actuellement, c’est-à-dire que vous augmentez la quantité de RAM, de CPU, de GPU et d’autres ressources. Ceci est connu comme une mise à l'échelle verticale.
La mise à l'échelle verticale est généralement coûteuse. Cela ne rend pas le système tolérant aux pannes, c'est-à-dire que si vous redimensionnez une application exécutée avec un seul serveur, si ce serveur tombe en panne, votre système tombe en panne. De plus, le nombre de threads reste le même dans la mise à l'échelle verticale. La mise à l’échelle verticale peut nécessiter que votre système s’arrête un moment où le processus a lieu. L'augmentation des ressources sur un serveur nécessite un redémarrage et une panne du système.
Une autre solution à ce problème consiste à augmenter le nombre de serveurs présents dans le système. Cette solution est très utilisée dans le secteur des technologies. Cela réduira éventuellement le débit de requêtes par seconde sur chaque serveur. Si vous devez redimensionner le système, ajoutez simplement un autre serveur et vous avez terminé. Vous ne seriez pas obligé de redémarrer le système. Le nombre de threads dans chaque système diminue, entraînant un débit élevé. Pour séparer les demandes, également sur chaque serveur d'applications, vous devez ajouter un équilibreur de charge qui agirait comme un proxy inverse pour les serveurs Web. L'ensemble de ce système peut être appelé en tant que cluster unique. Votre système peut contenir un grand nombre de demandes nécessitant davantage de grappes comme celle-ci.
J'espère que vous comprendrez le concept d'introduction de la mise à l'échelle dans le système.
Il y a une architecture supplémentaire qui n'a pas été mentionnée - les services de base de données basés sur SQL qui permettent la mise à l'échelle horizontale sans la complexité du partage manuel. Ces services effectuent le partage en arrière-plan. Ils vous permettent donc d'exécuter une base de données SQL traditionnelle et de la faire évoluer comme vous le feriez avec des moteurs NoSQL tels que MongoDB ou CouchDB. Deux services que je connais bien sont EnterpriseDB pour PostgreSQL et Xeround pour MySQL . J'ai vu un article détaillé de Xeround qui explique pourquoi la mise à l'échelle sur des bases de données SQL est difficile et comment ils le font différemment - traitez cela avec un grain de sel car c'est un poste de vendeur. Consultez également l'entrée de la base de données Cloud de Wikipédia . Il existe une explication intéressante de SQL vs NoSQL et du service vs auto-hébergé, d'une liste de fournisseurs et de la mise à l'échelle. options pour chaque combinaison. ;)
Oui, la mise à l'échelle horizontale signifie l'ajout de plus de machines, mais cela implique également que les machines sont égales dans le cluster. MySQL peut évoluer horizontalement en termes de lecture de données, grâce à l'utilisation de répliques, mais une fois que celui-ci a atteint la capacité du serveur mem/disk, vous devez commencer à partager des données sur plusieurs serveurs. Cela devient de plus en plus complexe. La cohérence des données entre les répliques pose souvent un problème, car les taux de réplication sont souvent trop lents pour suivre le rythme des changements de données.
Couchbase est également une fantastique base de données NoSQL Horizontal Scaling, utilisée dans de nombreux jeux et applications commerciaux à haute disponibilité et sans doute le plus performant de la catégorie. Il partitionne automatiquement les données sur le cluster, l'ajout de nœuds est simple et vous pouvez utiliser du matériel standard, des instances vm moins chères (en utilisant des ordinateurs Large à la place de Mémoire élevée, à disque élevé chez AWS, par exemple). Il est construit à partir de la membrane (Memcached) mais ajoute de la persistance. En outre, dans le cas de Couchbase, chaque nœud peut effectuer des lectures et des écritures et est égal dans le cluster, avec uniquement une réplication avec basculement (et non une réplication complète de l'ensemble de données sur tous les serveurs, comme dans MySQL).
En termes de performances, vous pouvez voir un excellent benchmark Cisco: http://blog.couchbase.com/understanding-performance-benchmark-published-Cisco-and-solarflare-using-couchbase-server
Voici un excellent article de blog sur Couchbase Architecture: http://horicky.blogspot.com/2012/07/couchbase-architecture.html
Les bases de données relationnelles traditionnelles ont été conçues comme des systèmes de base de données client/serveur. Ils peuvent être mis à l'échelle horizontalement, mais le processus à suivre a tendance à être complexe et sujet aux erreurs. Les bases de données NewSQL telles que NuoDB sont des systèmes de base de données distribués centrés sur la mémoire, conçus pour évoluer horizontalement tout en conservant les propriétés SQL/ACID du SGBDR traditionnel.
Pour plus d'informations sur NuoDB, lisez leur livre blanc technique .
Les bases de données SQL telles qu'Oracle et db2 prennent également en charge la mise à l'échelle horizontale via un cluster de disques partagés. Par exemple, Oracle RAC, IBM DB2 purescale ou l'édition Sybase ASE Cluster. Un nouveau noeud peut être ajouté au système Oracle RAC ou au système DB2 purescale pour réaliser une mise à l'échelle horizontale.
Mais l'approche est différente de celle des bases de données noSQL (telles que mongodb, CouchDB ou IBM Cloudant), c'est-à-dire que le partage des données ne fait pas partie de la mise à l'échelle horizontale. Dans les bases de données noSQL, les données sont échangées lors de la mise à l'échelle horizontale.
Toutes les autres réponses semblent déjà assez complètes mais je ne voyais pas Google Cloud Spanner comme exemple de base de données relationnelle avec mise à l'échelle horizontale, c'est pourquoi j'ajoute ma petite contribution.
L'ajout de nombreux équilibreurs de charge crée une surcharge et une latence supplémentaires, ce qui constitue un inconvénient pour la mise à l'échelle horizontale dans les bases de données nosql. C'est comme la question pourquoi les gens disent que le RPC n'est pas recommandé car il n'est pas robuste.
Je pense que dans un système réel, nous devrions utiliser à la fois les bases de données SQL et nosql pour utiliser les capacités de calcul à la fois multicœurs et en nuage des systèmes actuels.
D'autre part, les requêtes transactionnelles complexes ont des performances élevées si des bases de données SQL telles que Oracle sont utilisées. NoSql pourrait être utilisé pour les données volumineuses et l’évolutivité horizontale par sharding.