Dans le contexte des bases de données, je suis tombé sur l'évolutivité horizontale comme l'un des avantages des bases de données NOSQL. Que signifie ce terme?
Comment se comparerait-elle à la mise à l'échelle verticale ?
Dans le contexte des bases de données, je suis tombé sur l'évolutivité horizontale comme l'un des avantages des bases de données NOSQL. Que signifie ce terme?
Comment se comparerait-elle à la mise à l'échelle verticale ?
Réponses:
Mise à l'échelle
horizontale La mise à l' échelle horizontale consiste essentiellement à construire plutôt qu'à augmenter. Vous n'allez pas acheter un plus gros serveur plus costaud et y déplacer toute votre charge, au lieu de cela, vous achetez 1+ serveurs supplémentaires et répartissez votre charge entre eux.
La mise à l'échelle horizontale est utilisée lorsque vous avez la possibilité d'exécuter simultanément plusieurs instances sur des serveurs. Typiquement, il est beaucoup plus difficile de passer de 1 serveur à 2 serveurs que de passer de 2 à 5, 10, 50, etc.
Une fois que vous avez résolu les problèmes liés à l'exécution d'instances parallèles, vous pouvez tirer pleinement parti d'environnements tels qu'Amazon EC2, le service Cloud de Rackspace, GoGrid, etc. vous n'utilisez pas simplement pour couvrir ces pics de charge.
Les bases de données relationnelles sont l'un des éléments les plus difficiles à exécuter en lecture / écriture complète en parallèle.
J'ai vu Damien Katz parler de CouchDB à StackOverflow DevDays à Austin et l'un de ses principaux objectifs pour sa création était ces instances parallèles. Comme cela a été un objectif depuis le premier jour, il serait beaucoup plus capable de tirer parti de la mise à l'échelle horizontale.
Mise à l'échelle
verticale La mise à l' échelle verticale est le contraire, s'accumuler au lieu de sortir. Allez acheter le matériel le plus solide que vous puissiez vous permettre et mettez-y votre application, votre base de données, etc.
Le monde réel
Bien sûr, ces deux éléments ont leurs avantages et leurs inconvénients. Souvent, une combinaison de ces deux est utilisée pour une solution finale.
Vous pouvez avoir votre base de données principale où tout le monde écrit et lit des données en temps réel sur un gros matériel. Ensuite, avez distribué des copies en lecture seule de la base de données pour une analyse des données et des rapports plus lourds où le fait d'être à la minute n'a pas autant d'importance. L'application Web frontale peut alors s'exécuter sur plusieurs serveurs Web derrière un équilibreur de charge.
La mise à l'échelle horizontale est idéale lorsque vous avez besoin d'une application qui doit gérer une grande quantité d'écritures et de lectures parallèles. Pensez à un site Web qui reçoit une énorme quantité de trafic et doit le consigner, ou doit consigner un grand nombre d'événements.
Je suppose que le plus grand avantage est que la mise à l'échelle horizontale peut être effectuée à l'aide de matériel de base, et il n'y a que beaucoup de choses à faire avec la mise à l'échelle verticale et en essayant d'agrandir vos boîtes existantes.
Les SGBDR traditionnels échouent ici pour diverses raisons (y compris le fait qu'ils sont ACID), et les solutions NoSQL excellent ici car elles peuvent être facilement mises à l'échelle horizontalement - mais c'est une autre histoire (RDBMS / SQL vs NoSQL.)
Certaines personnes de l'industrie utilisent une terminologie différente pour désigner la même chose: