Différence entre la mise à l'échelle horizontale et verticale pour les bases de données [fermé]

J'ai rencontré de nombreuses bases de données NoSQL et bases de données SQL. Il existe différents paramètres pour mesurer la force et les faiblesses de ces bases de données et l'évolutivité en fait partie. Quelle est la différence entre une 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 en ajoutant plus de puissance (CPU, RAM) à une machine existante .

Un moyen facile 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 base 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, dans la mise à l'échelle verticale, les données résident sur un seul nœud et la mise à l'échelle se fait via plusieurs cœurs, c'est-à-dire la répartition de la charge entre les ressources CPU et RAM de cette machine.

Avec la mise à l'échelle horizontale, il est souvent plus facile de faire évoluer dynamiquement en ajoutant plus de machines dans le pool existant - La mise à l'échelle verticale est souvent limitée à la capacité d'une seule machine, la mise à l'échelle au-delà de cette capacité implique souvent des temps d'arrêt et s'accompagne d'une limite supérieure.

De bons exemples de mise à l'échelle horizontale sont Cassandra, MongoDB, Google Cloud Spanner .. et un bon exemple de mise à l'échelle verticale est MySQL - Amazon RDS (la version cloud de MySQL). Il fournit un moyen facile de faire é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 une mise à l'échelle horizontale et verticale simplement parce qu'elles ne sont pas liées au disque. Mise à l'échelle horizontale par partitionnement et mise à l'échelle verticale par prise en charge multicœur.

Vous pouvez en savoir plus sur ce sujet dans mes articles précédents: Scale-out vs Scale-up et Les principes communs derrière les alternatives NOSQL

Mise à l'échelle horizontale ===> Des milliers de serviteurs feront le travail ensemble pour vous.

Mise à l'échelle verticale ===> Une grosse coque fera tout le travail pour vous.

Commençons par la nécessité d'une mise à l'échelle qui augmente les ressources afin que votre système puisse désormais gérer plus de demandes qu'auparavant.

Lorsque vous réalisez que votre système devient lent et n'est pas en mesure de gérer le nombre actuel de demandes, vous devez faire évoluer le système.

Cela vous offre deux options. Soit vous augmentez les ressources du serveur que vous utilisez actuellement, c'est-à-dire que vous augmentez la quantité de RAM, CPU, GPU et autres ressources. Ceci est connu sous le nom d'é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 faites évoluer une application fonctionnant avec un seul serveur, si ce serveur tombe en panne, votre système tombera en panne. De plus, la quantité de threads reste la même dans la mise à l'échelle verticale. La mise à l'échelle verticale peut nécessiter que votre système tombe en panne pendant un moment au cours du processus. L'augmentation des ressources sur un serveur nécessite un redémarrage et l'arrêt de votre système.

Une autre solution à ce problème consiste à augmenter la quantité de serveurs présents dans le système. Cette solution est très utilisée dans l'industrie technologique. Cela diminuera éventuellement le taux de requêtes par seconde sur chaque serveur. Si vous avez besoin de faire évoluer 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, ce qui entraîne un débit élevé. Pour séparer les demandes, également pour chacun des serveurs d'applications, vous devez ajouter un équilibreur de charge qui agirait comme proxy inverse pour les serveurs Web. L'ensemble de ce système peut être appelé comme un cluster unique. Votre système peut contenir un grand nombre de demandes qui nécessiteraient plus de clusters comme celui-ci.

J'espère que vous aurez tout le concept de l'introduction de la mise à l'échelle dans le système.

Il existe une architecture supplémentaire qui n'a pas été mentionnée - les services de base de données basés sur SQL qui permettent une mise à l'échelle horizontale sans la complexité du partage manuel. Ces services effectuent le partage en arrière-plan, de sorte qu'ils vous permettent d'exécuter une base de données SQL traditionnelle et d'évoluer comme vous le feriez avec des moteurs NoSQL comme MongoDB ou CouchDB. EnterpriseDB pour PostgreSQL et Xeround pour MySQL sont deux services que je connais . J'ai vu en profondeur après par Xeround ce qui explique pourquoi échelle sur les bases de données SQL est difficile et comment ils le font différemment - traiter cela avec un grain de sel car il est un poste de vendeur. Consultez également l' entrée de la base de données cloud de Wikipedia, il y a une belle explication de SQL vs NoSQL et du service vs auto-hébergé, une liste de fournisseurs et des options de mise à l'échelle 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 qu'il atteint la capacité du serveur mem / disque, vous devez commencer à partager les données entre les serveurs. Cela devient de plus en plus complexe. Souvent, la cohérence des données entre les répliques est un problème car les taux de réplication sont souvent trop lents pour suivre les taux de changement des données.

Couchbase est également une fantastique base de données de mise à l'échelle horizontale NoSQL, utilisée dans de nombreuses applications et jeux commerciaux à haute disponibilité et sans doute la plus performante 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 de base, des instances vm moins chères (en utilisant Large au lieu de High Mem, des machines High Disk chez AWS par exemple). Il est construit à partir de la Membase (Memcached) mais ajoute de la persistance. De plus, dans le cas de Couchbase, chaque nœud peut effectuer des lectures et des écritures et sont égaux dans le cluster, avec uniquement une réplication de basculement (pas 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 pour ce faire a tendance à être complexe et sujet aux erreurs. Les bases de données NewSQL comme 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 des SGBDR traditionnels.

Pour plus d'informations sur NuoDB, lisez leur livre blanc technique .

Les bases de données SQL comme Oracle, db2 prennent également en charge la mise à l'échelle horizontale via le cluster de disques partagés. Par exemple, Oracle RAC, IBM DB2 purescale ou Sybase ASE Cluster edition. Un nouveau nœud peut être ajouté au système Oracle RAC ou au système DB2 purescale pour obtenir une mise à l'échelle horizontale.

Mais l'approche est différente des bases de données noSQL (comme mongodb, CouchDB ou IBM Cloudant), c'est 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 transférées lors de la mise à l'échelle horizontale.

Vous avez une entreprise et il n'y a qu'un seul travailleur mais vous avez obtenu 1 nouveau projet à ce moment-là, vous embauchez un nouveau candidat - c'est une mise à l'échelle horizontale. où le nouveau candidat est de nouvelles machines et le projet est le nouveau trafic / appels vers vos API.

Où comme 1 projet avec un gars IIT / NIT traitant toutes les demandes à votre api / trafic. Si à tout moment plus de demandes à votre API, alors tirez-le et remplacez-le par un type IQ NIT / IIT élevé - c'est une mise à l'échelle verticale.

L'ajout de nombreux équilibreurs de charge crée une surcharge et une latence supplémentaires, ce qui est l'inconvénient d'une mise à l'échelle horizontale dans les bases de données nosql. C'est comme la question de savoir pourquoi les gens disent que le RPC n'est pas recommandé car il n'est pas robuste.

Je pense que dans un vrai système, nous devrions utiliser les bases de données sql et nosql pour utiliser à la fois les capacités de calcul multicœur et cloud des systèmes d'aujourd'hui.

D'un autre côté, les requêtes transactionnelles complexes ont de hautes performances si des bases de données SQL telles que Oracle sont utilisées. NoSql pourrait être utilisé pour les bigdata et l'évolutivité horizontale par partitionnement.

La réponse acceptée est la définition de base de la mise à l'échelle horizontale vs verticale. Mais contrairement à la croyance commune selon laquelle la mise à l'échelle horizontale des bases de données n'est possible qu'avec Cassandra, MongoDB, etc., je voudrais ajouter que la mise à l'échelle horizontale est également très possible avec tout RDMS traditionnel; cela aussi sans utiliser de solutions tierces.

Je connais de nombreuses entreprises, notamment des entreprises basées sur le SaaS qui le font. Cela se fait en utilisant une logique d'application simple. Vous prenez essentiellement un ensemble d'utilisateurs et les divisez sur plusieurs serveurs de base de données. Ainsi, par exemple, vous auriez généralement une base de données / table "méta" qui stockerait les clients, le serveur de base de données / les chaînes de connexion, etc. et une table qui stocke le mappage client / serveur.

Ensuite, dirigez simplement les demandes de chaque client vers le serveur de base de données auquel elles sont mappées.

Maintenant, certains diront que cela s'apparente à un partitionnement horizontal et non à une "vraie" mise à l'échelle horizontale et ils auront raison à certains égards. Mais le résultat final est que vous avez mis à l'échelle votre base de données sur plusieurs serveurs Db.

La seule différence entre les deux approches de la mise à l'échelle horizontale est qu'une approche (MongoDB, etc.) la mise à l'échelle est effectuée par le logiciel DB lui-même. En ce sens, vous "achetez" la mise à l'échelle. Dans l'autre approche (pour la mise à l'échelle horizontale du SGBDR), la mise à l'échelle est construite par le code / la logique de l'application.