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


Je suis tombé sur de nombreuses bases de données et bases de données SQL NoSQL. Il existe différents paramètres pour mesurer la force et les faiblesses de ces bases de données et l'évolutivité est l'un d'entre eux. Quelle est la différence entre la mise à l'échelle horizontale et verticale de ces bases de données?


428
2017-07-29 08:40


origine


Réponses:


La mise à l'échelle horizontale signifie que vous effectuez une mise à l'échelle en ajoutant plus de machines dans votre réserve de ressources alors que La mise à l'échelle verticale signifie que vous effectuez une mise à l'échelle en ajoutant plus de puissance (CPU, RAM) à une machine existante..

Un moyen facile de se souvenir de cela est de penser à une machine sur un rack de serveur, nous ajoutons plus de machines à travers le horizontal direction et ajouter plus de ressources à une machine dans le verticale direction.

Horizontal Scaling/Vertical Scaling Visualisation

Dans un monde de base de données, la mise à l'échelle horizontale est souvent basée sur le partitionnement des données, chaque nœud ne contenant qu'une partie des données, dans une mise à l'échelle verticale les données sont stockées sur plusieurs cœurs. les ressources CPU et RAM de cette machine.

Avec la mise à l'échelle horizontale, il est souvent plus facile de procéder à une mise à l'échelle dynamique en ajoutant plus de machines au pool existant. La mise à l'échelle verticale se limite souvent à la capacité d'une seule machine.

Les bons exemples de mise à l'échelle horizontale sont Cassandra, MongoDB, Google Cloud Spanner .. et un bon exemple de dimensionnement vertical est MySQL - Amazon RDS (la version cloud de MySQL). Il offre un moyen facile d'évoluer verticalement en passant de petites machines à des machines plus grandes. Ce processus implique souvent des temps d'arrêt.

Grilles de données en mémoire telles que GigaSpaces XAP, La cohérence etc .. sont souvent optimisés pour la mise à l'échelle horizontale et verticale simplement parce qu'ils ne sont pas liés au disque. Mise à l'échelle horizontale via le partitionnement et la mise à l'échelle verticale via le support multicœur.

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


767
2018-06-01 10:53



L'extensibilité horizontale est la capacité d'augmenter la capacité en connectant plusieurs entités matérielles ou logicielles afin qu'elles fonctionnent comme une seule unité logique.

Lorsque les serveurs sont en cluster, le serveur d'origine est étendu horizontalement. Si un cluster nécessite davantage de ressources pour améliorer les performances et fournir une haute disponibilité (HA), un administrateur peut évoluer en ajoutant davantage de serveurs au cluster.

Un avantage important de l'évolutivité horizontale est qu'elle peut fournir aux administrateurs la capacité d'augmenter la capacité à la volée. Un autre avantage est qu'en théorie, l'extensibilité horizontale n'est limitée que par le nombre d'entités pouvant être connectées avec succès. Le système de stockage distribué Cassandra, par exemple, fonctionne par-dessus des centaines de noeuds de produits répartis dans différents centres de données. Comme le matériel de base est mis à l'échelle horizontalement, Cassandra est tolérant aux pannes et ne comporte pas de point de défaillance unique (SPoF).

D'autre part, l'évolutivité verticale augmente la capacité en ajoutant plus de ressources, telles que plus de mémoire ou un processeur supplémentaire, à une machine. La mise à l'échelle verticale, également appelée mise à l'échelle, nécessite généralement des temps d'arrêt lorsque de nouvelles ressources sont ajoutées et des limites définies par le matériel. Lorsque les clients Amazon RDS doivent évoluer verticalement, par exemple, ils peuvent passer d'une machine plus petite à une plus grande, mais la plus grande instance RDS d'Amazon ne dispose que de 68 Go de mémoire.

La mise à l'échelle horizontalement présente à la fois des avantages et des inconvénients. Par exemple, l'ajout d'ordinateurs de base peu coûteux à un cluster peut sembler une solution rentable à première vue, mais il est important que l'administrateur sache si les coûts de licence de ces serveurs supplémentaires, les coûts d'exploitation supplémentaires l'encombrement qu'ils occuperont dans le centre de données rendra la mise à l'échelle horizontale un meilleur choix que la mise à l'échelle verticale.


28
2017-07-08 10:33



La mise à l'échelle horizontale - également appelée «scale-out» est essentiellement l'ajout de plusieurs machines ou la mise en place d'un cluster ou d'un environnement distribué pour votre système logiciel. Cela nécessite généralement un programme d'équilibrage de charge qui est un composant de middleware dans le modèle d'architecture client-serveur standard à 3 niveaux.

Load-Balancer est chargé de répartir les demandes des utilisateurs (chargement) entre les différents systèmes / machines / nœuds principaux du cluster. Chacune de ces machines dorsales exécute une copie de votre logiciel et peut donc traiter les demandes. Ceci est juste l'une des nombreuses fonctions que l'équilibreur de charge peut effectuer. Une autre responsabilité très courante est la "vérification de l'état de santé" où l'équilibreur de charge utilise le protocole "ping-echo" ou échange des messages de pulsation avec tous les serveurs pour s'assurer qu'ils fonctionnent correctement.

L'équilibreur de charge répartit la charge en conservant l'état de chaque machine - combien de requêtes sont servies par chaque machine, quelle machine est inactive, quelle machine est surchargée de requêtes en file d'attente, etc. demande à une machine serveur appropriée. Il prend également en compte les frais généraux du réseau et peut choisir le serveur dans le centre de données le plus proche, à condition qu'il soit disponible pour répondre aux demandes.

La requête-réponse peut également être effectuée de deux manières différentes:

  1. Load Balancer agit toujours comme un programme intermédiaire pour chaque réponse - Dans ce cas, une fois que la demande a été transmise au serveur par le programme d'équilibrage de charge, toute réponse du serveur à l'utilisateur passe par l'équilibreur de charge. Ainsi, les machines serveur qui traitent la requête n'interfaceront jamais directement avec la machine utilisateur exécutant l'application cliente. La machine hébergeant le programme d'équilibrage de charge traitera toutes les demandes / réponses à destination et en provenance de l'utilisateur.

  2. Load Balancer n'agit pas en tant qu'intermédiaire pour les réponses provenant de la machine serveur. Dans ce cas, une fois que le serveur a reçu la demande de load-balancer, il ignore l'équilibreur de charge et le communique directement au client.

La configuration d'un cluster et d'un équilibreur de charge en tant qu'interface frontale avec l'application client ne complète pas vraiment notre architecture et notre conception évolutives. Il y a encore beaucoup de questions critiques à résoudre et un certain nombre de décisions de conception clés à prendre qui affecteront les propriétés globales de notre système.

Nous devons d’abord identifier nos objectifs commerciaux et les domaines dans lesquels nous souhaiterions ajouter de la valeur. Ces objectifs donneront lieu à diverses exigences. Nous devrions alors nous poser diverses questions sur les différentes propriétés systémiques.

  1. Une telle conception répondra-t-elle à nos exigences de performance?

  2. Quelles sont les caractéristiques de performance qui nous intéressent? Est-ce le débit global du système où nous sommes intéressés à servir un nombre maximum de demandes à un moment donné? Ou est-ce le temps de réponse du système où nous concevons pour renvoyer la réponse au client aussi rapidement que possible? Ces types et beaucoup d'autres types de caractéristiques de performance sont liés les uns aux autres.

  3. Une telle conception répondra-t-elle à nos exigences de disponibilité? Le système est-il tolérant aux pannes? Si oui, quel est son degré?

  4. Un tel design est-il fiable? Cela a-t-il un impact sur la rectitude? Nous ne devons pas oublier que l'exactitude à 100% est un objectif implicite de tout système.

  5. Respectons-nous vraiment nos objectifs d'évolutivité? Peut-être atteindre les objectifs à court terme ou immédiats, mais que se passera-t-il à long terme?

Tous ces types d'exigences devraient avoir des mesures quantifiables qui leur sont associés.

Nous devons ensuite prendre des décisions importantes en matière de conception en nous interrogeant, en développant des prototypes et en affinant la conception.

  1. Premièrement, l'utilisation de l'équilibreur de charge est-elle la seule approche pour répartir la charge et adapter horizontalement le système?

  2. Les différents serveurs ou noeuds principaux communiquent-ils entre eux? Si oui, alors comment le système règle-t-il la situation dans laquelle un ou plusieurs nœuds tombent - de manière permanente ou temporaire? Si oui, alors comment le système répond-il à la situation où le réseau qui connecte les nœuds est en panne, mais tous les nœuds sont opérationnels? Plus important encore, devons-nous faire la différence entre ces deux situations? Comment ?

  3. Que les nœuds dorsaux communiquent entre eux ou non, notre système doit-il maintenir des données cohérentes sur tous les nœuds? De quel niveau de cohérence nous soucions-nous? Est-ce que c'est ça À tout moment, les données de tous les nœuds doivent être cohérentes. Ou plus tard, les données sur tous les nœuds seront cohérentes. Si oui, alors quelle est cette "plus tard"? Quand et comment tous les nœuds convergent vers un état cohérent? Comment allons-nous réaliser un "ordre total" d'opérations sur tous les nœuds? Avons-nous une horloge mondiale? Si nous nous basons sur l'horloge locale de chaque nœud, comment synchronisons-nous les horloges de toutes les machines? Ils peuvent facilement sembler régresser ou une machine avec une horloge hors service pourrait rejoindre le cluster. Par conséquent, nous pouvons ignorer les dernières données et considérer les données anciennes / obsolètes comme les dernières.
  4. Quelle configuration de cluster devons-nous concevoir? Est-ce un cluster "réplica", où les données sur chaque nœud sont répliquées sur certains ou tous les autres nœuds. Dans le cas de l'ancien, quel est le facteur de réplication, et comment le décidons-nous? Ou est-ce un cluster fragmenté où le cluster est divisé en plusieurs fragments ou unités. Un fragment est un groupe de nœuds désigné. Chaque fragment prend en charge une partition de données particulière. Les données à travers les fragments ne sont pas répliquées, mais chaque fragment peut adopter une stratégie de réplication à l'intérieur de lui-même. Quel que soit le système distribué que nous concevons, il devrait idéalement pouvoir répondre aux questions ci-dessus et à bien d’autres questions similaires.

Tout ceci est ce qui rend un système distribué si intéressant et stimulant à concevoir et à mettre en œuvre.

Vertical Scaling (Échelle verticale) - également appelée "mise à l'échelle", est une tentative pour augmenter la capacité d'une seule machine: En ajoutant plus de puissance de traitement En ajoutant plus de stockage Plus de mémoire etc Résumé:

Ce qui est important ici, c'est de comprendre les différences entre ces deux approches de dimensionnement, d'identifier ce qui convient à nos besoins et de voir si l'application correspond vraiment au modèle que nous choisissons.

Comme vous l'auriez compris, la mise à l'échelle horizontale se traduit par des coûts et une complexité liés à la configuration, à la gestion et à la maintenance des clusters. La conception devient de plus en plus complexe et les changements de modèle de programmation.

Il ne suffit donc pas de lancer du nouveau matériel et d'ajouter plus de nœuds ou de machines. Tout d'abord, vérifiez si les exigences peuvent être satisfaites en augmentant la capacité ou les caractéristiques de réglage d'une seule machine. Si ce n'est pas le cas, optez pour l'approche scale-out ou une combinaison des deux.


26
2017-08-01 06:34



Oui, la mise à l'échelle horizontale signifie l'ajout de machines supplémentaires, mais cela implique également que les machines sont égales dans le cluster. MySQL peut évoluer horizontalement en termes de lecture de données, via l'utilisation de répliques, mais une fois qu'il atteint la capacité du serveur mem / disk, vous devez commencer à partager les données entre les serveurs. Cela devient de plus en plus complexe. La cohérence des données entre les répliques pose souvent problème, car les taux de réplication sont souvent trop lents pour suivre les taux de modification des données.

Couchbase est également une fantastique base de données NoSQL Horizontal Scaling, utilisée dans de nombreux jeux et applications haute disponibilité commerciaux et sans doute la plus performante de la catégorie. Il partitionne les données automatiquement à travers 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 les machines Large au lieu de High Mem, High Disk chez AWS par exemple). Il est construit sur la membrane (Memcached) mais ajoute de la persistance. De même, dans le cas de Couchbase, chaque nœud peut faire des lectures et des écritures, et est égal au cluster, avec seulement une réplication de failover (pas de réplication de jeu de données complète sur tous les serveurs comme dans mySQL).

Du point de vue des 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 sur l'architecture de Couchbase: http://horicky.blogspot.com/2012/07/couchbase-architecture.html


6
2017-09-10 09:52



Il existe une architecture supplémentaire qui n'a pas été mentionnée - les services de base de données SQL qui permettent la mise à l'échelle horizontale sans la complexité de la partition manuelle. Ces services effectuent le partitionnement en arrière-plan. Ils vous permettent donc d'exécuter une base de données SQL traditionnelle et d'évoluer comme vous le feriez avec des moteurs NoSQL tels que MongoDB ou CouchDB. Deux services que je connais sont EnterpriseDB pour PostgreSQL et Xeround pour MySQL. J'ai vu une profondeur poster par Xeround, qui explique pourquoi la mise à l'échelle sur les 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 vendeur. Consultez également Wikipedia Entrée de base de données Cloud, il y a une bonne 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. ;)


6
2018-02-13 07:41



Commençons par le besoin de mise à l'échelle qui augmente les ressources afin que votre système puisse maintenant gérer plus de demandes que ce qu'il pouvait auparavant.

Lorsque vous vous rendez compte, votre système devient lent, et est incapable de gérer le nombre actuel de demandes, vous devez mettre à l'échelle le système.

Cela vous fournit deux options, soit vous augmentez les ressources dans le serveur que vous utilisez actuellement, soit vous augmentez la quantité de RAM, CPU, GPU et autres ressources. Ceci est connu comme la 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 si vous mettez à l'échelle une application fonctionnant avec un serveur unique, si ce serveur tombe en panne, votre système va tomber. La quantité de threads reste également 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. Augmenter les ressources sur un serveur nécessite un redémarrage et met votre système en panne.

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 finira par diminuer le taux de demande par seconde dans chaque serveur. Si vous avez besoin de mettre à l'échelle 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 répartir les requêtes, de manière égale sur chacun des serveurs d'applications, vous devez ajouter un équilibreur de charge qui servirait de proxy inverse aux serveurs Web. Tout ce système peut être appelé en tant que cluster unique. Votre système peut contenir un grand nombre de requêtes nécessitant plus de clusters comme celui-ci.

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


6
2017-07-14 12:03



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 le 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 à http://goo.gl/uzLIWB.


5
2018-01-04 08:14



Les bases de données SQL telles qu'Oracle, db2, prennent également en charge la mise à l'échelle horizontale via le cluster de disque partagé. Par exemple, l'édition Oracle RAC, IBM DB2 purescale ou Sybase ASE Cluster. Un nouveau noeud 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 de celle des bases de données noSQL (comme mongodb, CouchDB ou IBM Cloudant), car le partitionnement des données ne fait pas partie de la mise à l'échelle horizontale. Dans les bases de données noSQL, les données sont shradées pendant la mise à l'échelle horizontale.


5
2018-04-04 11:03