Quels types de systèmes doivent «évoluer» plutôt que «évoluer»?


12

Je me demande depuis longtemps s'il existe des systèmes qui doivent "évoluer" (sur un serveur plus puissant et plus cher) plutôt que "évoluer" en étant répartis sur de nombreux serveurs plus petits.

Existe-t-il de tels systèmes et, dans l'affirmative, y a-t-il quelque chose en particulier qui tend à faire évoluer les systèmes plutôt que de les étendre? (Par exemple, des transactions avec une base de données de réclamations ACID ou d'autres exigences strictes d'intégrité des données peuvent créer ce besoin.)

Étant donné que la mise à l'échelle semble entraîner des coûts matériels beaucoup plus élevés que la mise à l'échelle, cela semble être quelque chose que vous voudriez éviter, si possible, mais je ne suis pas sûr que ce soit toujours évitable ou non.

Alors, y a-t-il des systèmes qui ne peuvent pas être mis à l'échelle et doivent être mis à l'échelle à la place? Qu'est-ce qui peut provoquer cela et comment identifieriez-vous un tel système? (Ont-ils généralement en commun certaines caractéristiques qui pourraient les rendre plus facilement identifiables?)



7
La mise à l'échelle est souvent beaucoup plus facile si votre logiciel n'a pas été conçu pour évoluer. La reconception de logiciels est soit coûteuse, soit impossible si vous ne possédez pas la source ou si vous avez une influence sur les développeurs.
Zoredache

L'écriture de tels systèmes est un problème très difficile. Surtout des conceptions master / master qui peuvent aller et venir où plusieurs masters écrivent sur les mêmes enregistrements en même temps. Qui écrit gagne?
Matt

3
Vous pourriez être intéressé CAP Theorem . Fondamentalement, un service qui nécessite à la fois une cohérence et une disponibilité telles que définies dans le théorème ne tolérera pas le partitionnement. La plupart des exigences du monde réel peuvent sacrifier une certaine cohérence pour une cohérence éventuelle (gérer manuellement ou automatiquement les incohérences après coup) ou sacrifier la disponibilité en refusant de traiter une demande lorsque certains des participants ne sont pas disponibles. Par conséquent, les systèmes qui nécessitent à la fois une cohérence absolue et une disponibilité absolue sont essentiellement obligés de se développer.
Lie Ryan

1
Si par "LAN fiable" vous voulez dire "n'a jamais de panne", alors vous ne concevez pas pour le monde réel.
mfinni

Réponses:


18

Je travaille principalement avec une application qui n'a aucun potentiel de mise à l'échelle horizontale . Même s'il s'exécute sous Linux, l'application, les structures de données et les exigences d'E / S m'obligent à "évoluer" sur des systèmes de plus en plus grands afin de s'adapter à une charge de travail accrue des utilisateurs.

De nombreuses applications métiers et transactionnelles héritées ont ces types de contraintes. C'est une des raisons pour lesquelles je souligne que l'industrie se concentre sur les solutions cloud et les architectures Web basées sur DevOps ignorent un bon pourcentage du monde informatique.

Malheureusement, les systèmes de mise à l'échelle que je décris ne sont vraiment pas sexy , de sorte que l'industrie a tendance à ignorer leur valeur ou à sous-estimer les compétences nécessaires pour traiter les grands systèmes critiques (par exemple, le bétail par rapport aux animaux de compagnie ).


1
"la chose la plus simple à faire est de jeter du matériel sur le problème." S'il vous plaît, la loi de Moore, n'arrêtez pas de travailler!
cjc

2
@Demetri - Microsoft SQL Server est le produit le plus "haut de gamme" auquel je pense, c'est une "montée en puissance" typique plutôt qu'une "montée en puissance". Sa mise à l'échelle est quasiment impossible, sauf si vous remplissez un ensemble très spécifique de critères de réplication de fusion.
Mark Henderson

3
Ou si vous pouvez décomposer la solution en plusieurs problèmes. Par exemple, n'exécutez pas de rapports sur votre base de données de transactions; a frappé une réplique qui fonctionne sur un autre matériel. \
mfinni

1
-1. Je pense que vous avez raté le cœur du problème. Votre problème n'est pas forcé d'être étendu si vous pouvez réécrire le système pour un système évolutif. Cette question concerne les systèmes dont le domaine problématique est tel qu'une mise à l'échelle n'est pas possible du tout, même lorsqu'elle est conçue de A à Z.
Lie Ryan

1
@LieRyan Comprehension. Je déclare que l'application que je supporte ne peut pas être mise à l'échelle (c'est un système de type base de données) ... même si elle a été repensée, en raison de contraintes architecturales.
ewwhite

8

Du point de vue du développeur, je peux dire que presque tous les moteurs de base de données traditionnels traditionnels ne peuvent évoluer et que la mise à l'échelle est une réflexion après coup.

Ces dernières années, avec le besoin d'une plus grande évolutivité et de systèmes hautement disponibles, des efforts ont été déployés pour faire évoluer les bases de données existantes. Mais parce que les conceptions sont gênées par le code hérité, il est tout simplement boulonné plutôt que fondamental pour la conception. Vous le rencontrerez si vous essayez de faire évoluer la plupart des moteurs de base de données bien connus. L'ajout de serveurs esclaves peut être assez difficile à configurer et vous remarquerez qu'il est livré avec des limitations importantes, dont certaines peuvent nécessiter de redéfinir vos tables de base de données.

Par exemple, la plupart d'entre eux sont des conceptions maître / (multi) esclaves plutôt que multi-maîtres. En d'autres termes, il se peut que vous ayez un serveur entier juste assis là et incapable de traiter les requêtes. Certains le font, mais avec des limitations ... par exemple en lecture seule, conception multi-esclave. Vous pouvez donc avoir un serveur qui prend des écritures et tous les autres fournissent des données en lecture seule. Vous remarquerez que lorsque vous configurez ces systèmes, ce n'est pas toujours un processus simple et difficile à bien travailler. Cela se sent très bien dans de nombreux cas.

D'un autre côté, certains moteurs de base de données plus récents sont en cours de développement avec une conception simultanée et multi-maîtres depuis le début. NOSQL et NewSQL sont la nouvelle classe de conception.

Il semble donc que la meilleure façon d'obtenir de meilleures performances à partir d'un serveur SQL traditionnel soit de passer à l'échelle supérieure! Alors qu'avec NOSQL et NewSQL, il est à la fois évolutif et évolutif.

La raison pour laquelle les systèmes SGBDR traditionnels sont étroitement couplés est qu'ils ont tous besoin d'une vue cohérente des mêmes données. Lorsque vous avez plusieurs serveurs acceptant les mises à jour des mêmes données de différents clients, lequel avez-vous confiance? Toute méthode qui tente de garantir la cohérence des données via une sorte de mécanisme de verrouillage nécessite la coopération d'autres serveurs, ce qui nuit aux performances ou affecte la qualité des données dans la mesure où les données lues à partir d'un client peuvent être obsolètes. Et les serveurs doivent décider entre eux quelles données sont les plus récentes lors de l'écriture dans le même enregistrement. Comme vous pouvez le voir, c'est un problème complexe rendu plus complexe par le fait que la charge de travail est répartie entre les serveurs et pas seulement entre les processus ou les threads où l'accès aux données est encore assez rapide.


Oracle RAC ne fournissait-il pas de scale-out depuis 10g?
Dani_l

Il a. Mais avoir un RAC et un RAC fonctionnant parfaitement sont deux choses différentes - cela nécessite vraiment un soin particulier pour continuer à fonctionner. C'est un joli design cependant. Si vous en avez besoin, vous êtes probablement prêt à en payer le prix.
TomTom

Et notez le système de stockage partagé nécessaire pour Oracle RAC. Cela pourrait présenter un problème de mise à l'échelle en fonction de la façon dont il est mis en œuvre.
Matt

7

À mon avis, la démarcation de montée en puissance / extensibilité est déterminée sur la façon dont un flux de travail peut être parallèle et sur la façon dont les threads parallèles doivent se coordonner les uns avec les autres.

Thread unique
Pour une raison quelconque, ce flux de travail ne peut fonctionner que sur un seul thread.

Un fil signifie qu'un système signifie une mise à l' échelle pour l'accélérer.

Parallélisme étroitement couplé
Il s'agit d'un système multithread où les threads doivent être étroitement couplés les uns aux autres. La communication inter-processus doit peut-être être très rapide, ou tout doit être géré via un seul gestionnaire de mémoire. La plupart des systèmes RDBMS sont ce type de calcul parallèle.

Pour la plupart, ces systèmes sont ceux qui échelle jusqu'à mieux que sur bien qu'il y ait des exceptions. Par exemple, des flux de travail qui fonctionneraient sur un cluster de style d' image système unique, un espace mémoire unique mais une latence élevée entre les threads, peuvent faciliter la mise à l'échelle. Mais il est très difficile de travailler avec de tels systèmes SSI, de sorte que la plupart des ingénieurs fabriquent simplement une boîte plus grande.

Parallélisme à couplage lâche
Il s'agit d'un système multi-thread / processus où les threads sont OK avec des latences élevées entre eux. Ou pas besoin de se parler du tout. Les serveurs Web et les fermes de rendu étendus sont des exemples classiques de ce type de système. Des systèmes comme ceux-ci sont beaucoup plus faciles à rendre plus grands qu'un parallélisme étroitement couplé, c'est pourquoi il y a beaucoup d'enthousiasme à propos de ce style de système.

Ceci est le style où l' échelle sur est beaucoup plus facile.


La raison pour laquelle les SGBDR sont étroitement couplés est qu'ils sont étroitement couplés aux données. c'est-à-dire plusieurs serveurs accédant à la même ressource.
Matt
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.