Les systèmes de gestion de bases de données relationnelles(SGBDR) utilisant le langage SQL sont utilisés depuis des décennies pour stocker les informations relatives aux applications. Servant d'épine dorsale à des industries majeures telles que la santé et la finance, le modèle relationnel d'organisation des données dans des tables avec une clé d'identification pour chaque ligne s'est avéré fiable et efficace. Les bases de données SQL modernes, y compris MySQL et PostgreSQL restent parmi les bases de données les plus utilisées aujourd'hui. Mais quand SQL ne suffit-il pas ?
L'essor des bases de données NoSQL(NotOnlySQL) à partir de la fin des années 2000 a coïncidé avec de nombreuses autres avancées. Alors que les processeurs multicœurs et la virtualisation devenaient monnaie courante, l 'informatique dématérialisée prenait son essor et des millions d'utilisateurs dans le monde entier se connectaient pour la première fois avec des smartphones. Tout devait croître, et le moyen le plus pratique d'y parvenir est de procéder à une "mise à l'échelle" horizontale. la mise à l'échelle horizontale. Nous voyons souvent SQL versus NoSQL simplifié à l'extrême en disant "SQL peut évoluer verticalement et NoSQL peut évoluer horizontalement", mais c'est incomplet et incorrect.
Mise à l'échelle horizontale
Lorsque nous parlons d'évolution horizontale, nous entendons la croissance de notre environnement par l'ajout de nœuds ou de machines supplémentaires. Alors que les bases de données SQL peuvent évoluer verticalement avec une relative facilité en ajoutant plus de RAM et de calcul à un seul nœud, la répartition de votre ensemble de données sur plusieurs nœuds est plus difficile. Cela peut se faire par le biais d'une technique appelée le sharding. Lorsque l'on travaille avec des ensembles de données volumineux et un débit élevé, le sharding permet de réduire la charge sur un seul serveur et d'augmenter la capacité en ajoutant ou en supprimant des serveurs, en fonction des besoins.
Sharding et limites de MySQL
Les bases de données SQL peuvent s'étendre horizontalement en se divisant en plusieurs parties. La méthode et les fonctionnalités prises en charge varient considérablement d'une base de données à l'autre, mais il convient de tenir compte de certaines mises en garde. Concentrons-nous sur l'un des exemples les plus courants : MySQL utilisant le moteur de stockage NDB. MySQL prend en charge les clusters NDB qui peuvent diviser une table unique et volumineuse en plusieurs tables plus petites. Le processus de division d'une table est appelé partitionnement. Lorsqu'elles sont stockées sur plusieurs serveurs, ces petites tables constituent les " shards". Les bases de données de votre cluster stockent chacune un des shards. Ensemble, les bases de données du cluster constituent votre ensemble de données complet.
L'utilisation du sharding dans les bases de données SQL peut offrir une très grande évolutivité de la taille des ensembles de données, mais elle peut également rendre la logique de votre application plus complexe. Vous devez configurer avec soin la manière dont vos données sont réparties en plusieurs fragments, car cette décision a une incidence sur les performances globales de la base de données. En plus de la complexité et du temps nécessaire, il y a des obstacles techniques à prendre en compte. Pour contrer une limitation couramment citée, MySQL peut être configuré pour effectuer des opérations de jointure entre les différents fichiers, mais au détriment des performances à plus grande échelle. Cela peut rendre les fonctions analytiques impraticables dans ces environnements.
Entrer dans le NoSQL
De nombreux types de bases de données NoSQL ont vu leur utilisation exploser depuis leur création à la fin des années 2000. Pour cet exemple, nous allons nous concentrer sur la base de données NoSQL la plus populaire, MongoDB. MongoDB (dérivé du mot "humongous") est orientée vers les documents. Les données sont stockées dans des documents similaires aux objets JSON et chaque document contient des paires de champs et de valeurs. Cette approche s'oppose à celle des bases de données SQL qui utilisent des tableaux et des lignes pour formater les données. Vous avez peut-être lu que les bases de données NoSQL telles que MongoDB sont généralement mieux adaptées à la mise à l'échelle horizontale, mais voyons pourquoi.
Notez que MongoDB utilise spécifiquement un format appelé BSON, qui est dérivé de JSON, mais cela varie avec chaque base de données.
Schémas et schémas de base (Shards)
MongoDB est sans schéma (ou sans schéma), ce qui signifie qu'il ne nécessite pas de structure organisationnelle définie au niveau de la base de données. Le schéma est plutôt intégré dans votre code au niveau de l'application, ce qui nous donne beaucoup de souplesse pour modifier la structure ultérieurement tout en préservant nos données. Bien qu'elles n'aient pas la cohérence rigide des bases de données SQL conformes à la norme ACID, MongoDB et d'autres bases de données NoSQL excellent en matière de disponibilité et de tolérance aux partitions.
Lorsque nous avons examiné la mise à l'échelle horizontale des bases de données SQL, nous avons passé en revue le processus de division d'une table en fragments. Bien que possible, cette méthode présente de nombreuses limitations en raison de la structure rigide intégrée à la base de données. MongoDB et d'autres bases de données NoSQL, en revanche, sont conçues pour s'adapter au sharding au niveau structurel. Un tesson est un sous-ensemble de données et MongoDB nous permet d'évoluer horizontalement en déployant les tessons sous forme d'ensembles de répliques. Les ensembles de répliques sont des grappes d'au moins trois nœuds avec des copies redondantes des mêmes données. Ils assurent la disponibilité et la redondance lorsqu'ils sont répartis dans de vastes environnements et ne sont pas limités par un schéma prédéterminé.
Cela nous permet de voir immédiatement les concessions que les bases de données NoSQL font pour être évolutives. Les bases de données NoSQL utilisent souvent beaucoup plus d'espace de stockage que les bases de données SQL en raison de la quantité de données redondantes nécessaires pour assurer la disponibilité dans le cadre de vastes déploiements horizontaux. Les vitesses d'écriture des bases de données NoSQL tendent à dépasser celles des bases de données SQL, mais les requêtes sont plus lentes. En l'absence d'une structure définie, les bases de données NoSQL ne sont pas conformes à la norme ACID, ce qui les rend moins pratiques pour les applications traitant de gros volumes de transactions financières. En revanche, nous pouvons configurer des clusters NoSQL distribués massifs qui maintiennent les performances, ce qui en fait des candidats idéaux pour le Big Data et l'analytique.
Quand le langage SQL ne suffit-il pas ? Comme on peut s'y attendre, la réponse n'est pas simple, mais il existe quelques lignes directrices générales dont nous pouvons tenir compte lors de la conception de nos applications. Que doit faire notre application et quelle doit être sa taille ? À partir de là, nous pouvons décider de notre priorité numéro un. Dire que "SQL évolue verticalement et NoSQL horizontalement" n'est pas vrai, mais nous pouvons dire que "la plupart des bases de données SQL ont été conçues avec la cohérence à l'esprit, tandis que la plupart des bases de données NoSQL ont été conçues pour s'adapter à l'évolutivité".
Il y aura toujours des contrepoints à cette ligne directrice générale. Vous pouvez faire évoluer MySQL horizontalement et MongoDB a commencé à prendre en charge les transactions ACID multi-documents. Plus nous comprenons comment ces bases de données sont conçues, plus nous sommes à même de choisir le meilleur outil pour le travail à accomplir.
Déploiement de bases de données sur Linode
Apprenez-en plus sur les bases de données gérées par Linode ou inscrivez-vous pour recevoir des mises à jour sur votre moteur de base de données préféré. Vous pouvez également déployer des systèmes gérés de base de données comme MongoDB depuis le Linode Marketplace ou suivre nos guides pour installer une base de données sur une variété de distros Linux, comme Installer MongoDB sur CentOS 7.
Commentaires