Le guide définitif des bases de données NoSQL

Il ne fait aucun doute que la façon dont les applications Web traitent les données a considérablement changé au cours de la dernière décennie. Plus de données sont collectées et plus d'utilisateurs accèdent à ces données simultanément que jamais auparavant. Cela signifie que l'évolutivité et les performances sont plus difficiles que jamais pour les bases de données relationnelles basées sur des schémas et peuvent donc être plus difficiles à mettre à l'échelle.

L'évolution de NoSQL

Le problème d'évolutivité SQL a été reconnu par les entreprises Web 2.0 ayant des besoins énormes et croissants en matière de données et d'infrastructure, telles que Google, Amazon et Facebook. Ils ont trouvé leurs propres solutions au problème - des technologies comme BigTable, DynamoDB et Cassandra.

Cet intérêt croissant a abouti à un certain nombre de systèmes de gestion de base de données NoSQL (SGBD), axés sur les performances, la fiabilité et la cohérence. Un certain nombre de structures d'indexation existantes ont été réutilisées et améliorées dans le but d'améliorer les performances de recherche et de lecture.

Premièrement, il existait des types de bases de données NoSQL propriétaires (source fermée) développés par de grandes entreprises pour répondre à leurs besoins spécifiques, tels que BigTable de Google, qui serait le premier système NoSQL, et DynamoDB d'Amazon.

Le succès de ces systèmes propriétaires a initié le développement d'un certain nombre de systèmes de bases de données open source et propriétaires similaires, les plus populaires étant Hypertable, Cassandra, MongoDB, DynamoDB, HBase et Redis.

Qu'est-ce qui rend NoSQL différent ?

L'une des principales différences entre les bases de données NoSQL et les bases de données relationnelles traditionnelles réside dans le fait que NoSQL est une forme de stockage non structuré .

Cela signifie que les bases de données NoSQL n'ont pas de structure de table fixe comme celles trouvées dans les bases de données relationnelles.

Avantages et inconvénients des bases de données NoSQL

Avantages

Les bases de données NoSQL présentent de nombreux avantages par rapport aux bases de données relationnelles traditionnelles.

Une différence majeure sous-jacente est que les bases de données NoSQL ont une structure simple et flexible. Ils sont sans schéma.

Contrairement aux bases de données relationnelles, les bases de données NoSQL sont basées sur des paires clé-valeur.

Certains types de magasins de bases de données NoSQL incluent le magasin de colonnes, le magasin de documents, le magasin de valeurs clés, le magasin de graphiques, le magasin d'objets, le magasin XML et d'autres modes de magasin de données.

Habituellement, chaque valeur de la base de données a une clé. Certains magasins de bases de données NoSQL permettent également aux développeurs de stocker des objets sérialisés dans la base de données, et pas seulement de simples valeurs de chaîne.

Les bases de données NoSQL open source ne nécessitent pas de frais de licence élevés et peuvent fonctionner sur du matériel peu coûteux, ce qui rend leur déploiement rentable.

De plus, lorsque vous travaillez avec des bases de données NoSQL, qu'elles soient open source ou propriétaires, l'expansion est plus facile et moins chère que lorsque vous travaillez avec des bases de données relationnelles. En effet, cela se fait en mettant à l'échelle horizontalement et en répartissant la charge sur tous les nœuds, plutôt que le type de mise à l'échelle verticale qui est généralement effectué avec les systèmes de bases de données relationnelles, qui remplacent l'hôte principal par un plus puissant.

Désavantages

Bien sûr, les bases de données NoSQL ne sont pas parfaites et ne sont pas toujours le bon choix.

D'une part, la plupart des bases de données NoSQL ne prennent pas en charge les fonctionnalités de fiabilité qui sont nativement prises en charge par les systèmes de bases de données relationnelles. Ces caractéristiques de fiabilité peuvent se résumer en atomicité, cohérence, isolation et durabilité. Cela signifie également que les bases de données NoSQL, qui ne prennent pas en charge ces fonctionnalités, échangent la cohérence contre les performances et l'évolutivité.

Afin de prendre en charge les fonctionnalités de fiabilité et de cohérence, les développeurs doivent implémenter leur propre code propriétaire, ce qui ajoute plus de complexité au système.

Cela pourrait limiter le nombre d'applications pouvant s'appuyer sur des bases de données NoSQL pour des transactions sécurisées et fiables, comme les systèmes bancaires.

D'autres formes de complexité trouvées dans la plupart des bases de données NoSQL incluent l'incompatibilité avec les requêtes SQL. Cela signifie qu'un langage d'interrogation manuel ou propriétaire est nécessaire, ce qui ajoute encore plus de temps et de complexité.

NoSQL vs bases de données relationnelles

Ce tableau fournit une brève comparaison des fonctionnalités entre NoSQL et les bases de données relationnelles :

Il convient de noter que le tableau montre une comparaison au niveau de la base de données , et non des différents systèmes de gestion de base de données qui implémentent les deux modèles. Ces systèmes fournissent leurs propres techniques propriétaires pour surmonter certains des problèmes et des lacunes des deux systèmes et, dans certains cas, améliorer considérablement les performances et la fiabilité.

Types de magasins de données NoSQL

Magasin de valeur clé

Dans le type de magasin Key Value, une table de hachage est utilisée dans laquelle une clé unique pointe vers un élément.

Les clés peuvent être organisées en groupes logiques de clés, nécessitant uniquement que les clés soient uniques au sein de leur propre groupe. Cela permet d'avoir des clés identiques dans différents groupes logiques. Le tableau suivant montre un exemple de magasin clé-valeur, dans lequel la clé est le nom de la ville et la valeur est l'adresse de l'Université d'Ulster dans cette ville.

Certaines implémentations du magasin de valeurs clés fournissent des mécanismes de mise en cache, ce qui améliore considérablement leurs performances.

Tout ce qui est nécessaire pour traiter les éléments stockés dans la base de données est la clé. Les données sont stockées sous forme de chaîne, JSON ou BLOB (Binary Large OBject).

L'un des plus gros défauts de cette forme de base de données est le manque de cohérence au niveau de la base de données. Cela peut être ajouté par les développeurs avec leur propre code, mais comme mentionné précédemment, cela ajoute plus d'efforts, de complexité et de temps.

La base de données NoSQL la plus célèbre construite sur un magasin de valeurs clés est DynamoDB d'Amazon.

Magasin de documents

Les magasins de documents sont similaires aux magasins de valeurs clés dans la mesure où ils sont sans schéma et basés sur un modèle clé-valeur. Les deux partagent donc bon nombre des mêmes avantages et inconvénients. Les deux manquent de cohérence au niveau de la base de données, ce qui permet aux applications de fournir plus de fonctionnalités de fiabilité et de cohérence.

Il existe cependant des différences essentielles entre les deux.

Dans les magasins de documents, les valeurs (documents) fournissent l'encodage des données stockées. Ces encodages peuvent être XML, JSON ou BSON (JSON encodé en binaire).

En outre, des requêtes basées sur des données peuvent être effectuées.

L'application de base de données la plus populaire qui s'appuie sur un magasin de documents est MongoDB.

Magasin de colonnes

Dans une base de données Column Store, les données sont stockées dans des colonnes, au lieu d'être stockées dans des lignes comme c'est le cas dans la plupart des systèmes de gestion de bases de données relationnelles.

Un magasin de colonnes est composé d'une ou plusieurs familles de colonnes qui regroupent logiquement certaines colonnes dans la base de données. Une clé est utilisée pour identifier et pointer vers un certain nombre de colonnes dans la base de données, avec un attribut keyspace qui définit la portée de cette clé. Chaque colonne contient des tuples de noms et de valeurs, ordonnés et séparés par des virgules.

Les magasins de colonnes ont un accès rapide en lecture/écriture aux données stockées. Dans un magasin de colonnes, les lignes qui correspondent à une seule colonne sont stockées sous la forme d'une seule entrée de disque. Cela permet un accès plus rapide lors des opérations de lecture/écriture.

Les bases de données les plus populaires qui utilisent le magasin de colonnes incluent BigTable, HBase et Cassandra de Google.

Base de graphique

Dans une base de données NoSQL Graph Base, une structure de graphe orienté est utilisée pour représenter les données. Le graphe est composé d'arêtes et de nœuds.

Formellement, un graphe est une représentation d'un ensemble d'objets, où certaines paires d'objets sont reliées par des liens. Les objets interconnectés sont représentés par des abstractions mathématiques, appelées sommets, et les liens qui relient certaines paires de sommets sont appelés arêtes. Un ensemble de sommets et les arêtes qui les relient est dit un graphe.

Cela illustre la structure d'une base de données de base de graphes qui utilise des arêtes et des nœuds pour représenter et stocker des données. Ces nœuds sont organisés par des relations entre eux, qui sont représentées par des arêtes entre les nœuds. Les nœuds et les relations ont des propriétés définies.

Les bases de données de graphes sont le plus souvent utilisées dans les applications de réseaux sociaux. Les bases de données de graphes permettent aux développeurs de se concentrer davantage sur les relations entre les objets plutôt que sur les objets eux-mêmes. Dans ce contexte, ils permettent en effet d'avoir un environnement évolutif et simple d'utilisation.

Actuellement, InfoGrid et InfiniteGraph sont les bases de données de graphes les plus populaires.

Systèmes de gestion de base de données NoSQL

Pour une brève comparaison des bases de données, le tableau suivant fournit une brève comparaison entre les différents systèmes de gestion de base de données NoSQL.

MongoDB dispose d'un stockage de schéma flexible, ce qui signifie que les objets stockés ne doivent pas nécessairement avoir la même structure ou les mêmes champs. MongoDB dispose également de certaines fonctionnalités d'optimisation, qui répartissent les collectes de données, ce qui entraîne une amélioration globale des performances et un système plus équilibré.

D'autres systèmes de base de données NoSQL, tels qu'Apache CouchDB, sont également des bases de données de type magasin de documents et partagent de nombreuses fonctionnalités avec MongoDB, à l'exception du fait que la base de données est accessible à l'aide d'API RESTful.

REST est un style architectural composé d'un ensemble coordonné de contraintes architecturales appliquées aux composants, connecteurs et éléments de données, au sein du World Wide Web. Il s'appuie sur un protocole de communication client-serveur sans état et pouvant être mis en cache (par exemple, le protocole HTTP).

Les applications RESTful utilisent des requêtes HTTP pour publier, lire des données et supprimer des données.

Comme pour les bases de données à base de colonnes, Hypertable est une base de données NoSQL écrite en C++ et basée sur la BigTable de Google.

Hypertable prend en charge la distribution des magasins de données sur les nœuds pour maximiser l'évolutivité, tout comme MongoDB et CouchDB.

L'une des bases de données NoSQL les plus utilisées est Cassandra, développée par Facebook.

Cassandra est une base de données de magasin de colonnes qui comprend de nombreuses fonctionnalités axées sur la fiabilité et la tolérance aux pannes.

Plutôt que de fournir un examen approfondi de chaque SGBD NoSQL, Cassandra et MongoDB, deux des systèmes de gestion de base de données NoSQL les plus largement utilisés, seront explorés dans les sous-sections suivantes.

Cassandre

Cassandra est un système de gestion de base de données développé par Facebook.

L'objectif derrière Cassandra était de créer un SGBD qui n'a pas de point de défaillance unique et offre une disponibilité maximale.

Cassandra est principalement une base de données de magasin de colonnes. Certaines études ont qualifié Cassandra de système hybride, inspiré de BigTable de Google, qui est une base de données de magasin de colonnes, et de DynamoDB d'Amazon, qui est une base de données clé-valeur.

Ceci est réalisé en fournissant un système clé-valeur, mais les clés de Cassandra pointent vers un ensemble de familles de colonnes, en s'appuyant sur le système de fichiers distribué BigTable de Google et les fonctionnalités de disponibilité de Dynamo (table de hachage distribuée).

Cassandra est conçu pour stocker d'énormes quantités de données réparties sur différents nœuds. Cassandra est un SGBD conçu pour gérer des quantités massives de données, réparties sur de nombreux serveurs, tout en fournissant un service hautement disponible sans point de défaillance unique, ce qui est essentiel pour un gros service comme Facebook.

Les principales caractéristiques de Cassandra incluent :

• Pas de point de défaillance unique. Pour ce faire, Cassandra doit s'exécuter sur un cluster de nœuds, plutôt que sur une seule machine. Cela ne signifie pas que les données de chaque cluster sont les mêmes, mais le logiciel de gestion l'est. Lorsqu'une défaillance dans l'un des nœuds se produit, les données sur ce nœud seront inaccessibles. Cependant, d'autres nœuds (et données) seront toujours accessibles.
• Le hachage distribué est un schéma qui fournit une fonctionnalité de table de hachage de manière à ce que l'ajout ou la suppression d'un emplacement ne modifie pas de manière significative le mappage des clés aux emplacements. Cela permet de répartir la charge sur les serveurs ou les nœuds en fonction de leur capacité et, par conséquent, de minimiser les temps d'arrêt.
• Interface client relativement facile à utiliser . Cassandra utilise Apache Thrift pour son interface client. Apache Thrift fournit un client RPC multilingue, mais la plupart des développeurs préfèrent des alternatives open source construites sur Apple Thrift, comme Hector.
• Autres caractéristiques de disponibilité. L'une des fonctionnalités de Cassandra est la réplication des données. Fondamentalement, il met en miroir les données sur d'autres nœuds du cluster. La réplication peut être aléatoire ou spécifique pour maximiser la protection des données en plaçant un nœud dans un centre de données différent, par exemple. Une autre fonctionnalité trouvée dans Cassandra est la politique de partitionnement. La politique de partitionnement décide où sur quel nœud placer la clé. Cela peut aussi être aléatoire ou dans l'ordre. Lors de l'utilisation des deux types de politiques de partitionnement, Cassandra peut trouver un équilibre entre l'équilibrage de charge et l'optimisation des performances des requêtes.
• Cohérence. Des fonctionnalités telles que la réplication rendent la cohérence difficile. Cela est dû au fait que tous les nœuds doivent être à jour à tout moment avec les dernières valeurs, ou au moment où une opération de lecture est déclenchée. Finalement, cependant, Cassandra essaie de maintenir un équilibre entre les actions de réplication et les actions de lecture/écriture en fournissant cette possibilité de personnalisation au développeur.
• Actions de lecture/écriture. Le client envoie une requête à un seul nœud Cassandra. Le nœud, selon la politique de réplication, stocke les données dans le cluster. Chaque nœud effectue d'abord la modification des données dans le journal de validation, puis met à jour la structure de la table avec la modification, toutes deux effectuées de manière synchrone. L'opération de lecture est également très similaire, une demande de lecture est envoyée à un seul nœud, et ce nœud unique est celui qui détermine quel nœud contient les données, selon la politique de partitionnement/placement.

MongoDB

MongoDB est une base de données orientée document, sans schéma, écrite en C++. La base de données est basée sur un magasin de documents, ce qui signifie qu'elle stocke des valeurs (appelées documents) sous la forme de données codées.

Le choix du format encodé dans MongoDB est JSON. C'est puissant, car même si les données sont imbriquées dans des documents JSON, elles seront toujours interrogeables et indexables .

Les sous-sections qui suivent décrivent certaines des fonctionnalités clés disponibles dans MongoDB.

Fragments

Le sharding est le partitionnement et la distribution des données sur plusieurs machines (nœuds). Un fragment est une collection de nœuds MongoDB, contrairement à Cassandra où les nœuds sont distribués symétriquement. L'utilisation de fragments signifie également la possibilité d'évoluer horizontalement sur plusieurs nœuds. Dans le cas où une application utilise un seul serveur de base de données, elle peut être convertie en cluster fragmenté avec très peu de modifications du code d'application d'origine car la façon dont le partitionnement est effectué par MongoDB. oftware est presque complètement découplé des API publiques exposées côté client.

Langage de requête Mongo

Comme indiqué précédemment, MongoDB utilise une API RESTful. Pour récupérer certains documents d'une collection db, un document de requête est créé contenant les champs auxquels les documents souhaités doivent correspondre.

Actions

Dans MongoDB, il existe un groupe de serveurs appelés routeurs. Chacun agit comme un serveur pour un ou plusieurs clients. De même, le cluster contient un groupe de serveurs appelés serveurs de configuration. Chacun contient une copie des métadonnées indiquant quel fragment contient quelles données. Les actions de lecture ou d'écriture sont envoyées des clients à l'un des serveurs routeurs du cluster et sont automatiquement acheminées par ce serveur vers les fragments appropriés contenant les données à l'aide des serveurs de configuration.

Semblable à Cassandra, un fragment dans MongoDB a un schéma de réplication de données, qui crée un jeu de répliques de chaque fragment contenant exactement les mêmes données. Il existe deux types de schémas de répliques dans MongoDB : la réplication maître-esclave et la réplication Replica-Set. Replica-Set offre plus d'automatisation et une meilleure gestion des pannes, tandis que Master-Slave nécessite parfois l'intervention de l'administrateur. Quel que soit le schéma de réplication, à tout moment dans un jeu de répliques, un seul fragment agit en tant que fragment principal, tous les autres fragments de réplique sont des fragments secondaires. Toutes les opérations d'écriture et de lecture vont au fragment principal, puis sont réparties uniformément (si nécessaire) sur les autres fragments secondaires de l'ensemble.

Dans le graphique ci-dessous, nous voyons l'architecture MongoDB expliquée ci-dessus, montrant les serveurs de routeur en vert, les serveurs de configuration en bleu et les fragments contenant les nœuds MongoDB.

Il convient de noter que le sharding (ou le partage des données entre fragments) dans MongoDB est entièrement automatique, ce qui réduit le taux d'échec et fait de MongoDB un système de gestion de base de données hautement évolutif.

Structures d'indexation pour les bases de données NoSQL

L'indexation est le processus d'association d'une clé à l'emplacement d'un enregistrement de données correspondant dans un SGBD. Il existe de nombreuses structures de données d'indexation utilisées dans les bases de données NoSQL. Les sections suivantes aborderont brièvement certaines des méthodes les plus courantes ; à savoir l'indexation B-Tree, l'indexation T-Tree et l'indexation O2-Tree.

Indexation B-Tree

B-Tree est l'une des structures d'index les plus courantes dans les SGBD.

Dans les arbres B, les nœuds internes peuvent avoir un nombre variable de nœuds enfants dans une plage prédéfinie.

Une différence majeure par rapport aux autres structures arborescentes, telles que AVL, est que B-Tree permet aux nœuds d'avoir un nombre variable de nœuds enfants, ce qui signifie moins d'équilibrage d'arbre mais plus d'espace perdu.

Le B+-Tree est l'une des variantes les plus populaires des B-Trees. Le B+-Tree est une amélioration par rapport au B-Tree qui nécessite que toutes les clés résident dans les feuilles.

Indexation T-Tree

La structure de données des T-Trees a été conçue en combinant les fonctionnalités des AVL-Trees et des B-Trees.

Les AVL-Trees sont un type d'arbres de recherche binaires auto-équilibrés, tandis que les B-Trees sont déséquilibrés et chaque nœud peut avoir un nombre différent d'enfants.

Dans un T-Tree, la structure est très similaire à celle de l'AVL-Tree et du B-Tree.

Chaque nœud stocke plusieurs tuples {clé-valeur, pointeur}. De plus, la recherche binaire est utilisée en combinaison avec les nœuds à plusieurs tuples pour produire un meilleur stockage et de meilleures performances.

Un T-Tree a trois types de nœuds : un T-Node qui a un enfant droit et gauche, un nœud feuille sans enfant et un nœud demi-feuille avec un seul enfant.

On pense que les T-Trees ont de meilleures performances globales que les AVL-Trees.

Indexation O2-Tree

L'O2-Tree est essentiellement une amélioration par rapport aux arbres rouge-noir, une forme d'arbre de recherche binaire, dans lequel les nœuds feuilles contiennent les tuples {valeur clé, pointeur}.

O2-Tree a été proposé pour améliorer les performances des méthodes d'indexation actuelles. Un O2-Tree d'ordre m (m ≥ 2), où m est le degré minimum de l'arbre, vérifie les propriétés suivantes :

• Chaque nœud est soit rouge soit noir. La racine est noire.
• Chaque nœud feuille est coloré en noir et se compose d'un bloc ou d'une page contenant des paires "valeur clé, pointeur d'enregistrement".
• Si un nœud est rouge, alors ses deux enfants sont noirs.
• Pour chaque nœud interne, tous les chemins simples du nœud aux nœuds feuilles descendants contiennent le même nombre de nœuds noirs. Chaque nœud interne contient une seule valeur de clé.
• Les nœuds feuilles sont des blocs qui ont entre ⌈m/2⌉ et m paires "clé-valeur, pointeur d'enregistrement".
• Si un arbre a un seul nœud, alors ce doit être une feuille, qui est la racine de l'arbre, et il peut avoir entre 1 et m éléments de données clés.
• Les nœuds feuilles sont doublement liés dans les directions avant et arrière.

Ici, nous voyons une comparaison simple des performances entre O2-Tree, T-Tree, B+-Tree, AVL-Tree et Red-Black Tree :

L'ordre du T-Tree, du B+-Tree et du O2-Tree utilisé était m = 512.

Le temps est enregistré pour les opérations de recherche, d'insertion et de suppression avec des taux de mise à jour variant entre 0 % et 100 % pour un index de 50 millions d'enregistrements, les opérations entraînant l'ajout de 50 millions d'enregistrements supplémentaires à l'index.

Il est clair qu'avec un taux de mise à jour de 0 à 10 %, B-Tree et T-Tree fonctionnent mieux que O2-Tree. Cependant, avec l'augmentation du taux de mise à jour, l'index O2-Tree fonctionne nettement mieux que la plupart des autres structures de données, les structures B-Tree et Red-Black Tree souffrant le plus.

Le cas de NoSQL ?

Une introduction rapide aux bases de données NoSQL, mettant en évidence les domaines clés où les bases de données relationnelles traditionnelles sont insuffisantes, conduit au premier point :

Bien que les bases de données relationnelles offrent une cohérence, elles ne sont pas optimisées pour des performances élevées dans les applications où des données massives sont stockées et traitées fréquemment.

Les bases de données NoSQL ont gagné en popularité en raison de leurs hautes performances, de leur grande évolutivité et de leur facilité d'accès ; cependant, ils manquent toujours de fonctionnalités qui offrent cohérence et fiabilité.

Heureusement, un certain nombre de SGBD NoSQL relèvent ces défis en offrant de nouvelles fonctionnalités pour améliorer l'évolutivité et la fiabilité.

Tous les systèmes de base de données NoSQL ne fonctionnent pas mieux que les bases de données relationnelles.

MongoDB et Cassandra ont des performances similaires, et dans la plupart des cas meilleures, que les bases de données relationnelles dans les opérations d'écriture et de suppression.

Il n'y a pas de corrélation directe entre le type de magasin et les performances d'un SGBD NoSQL. Les implémentations NoSQL subissent des modifications, les performances peuvent donc varier.

Par conséquent, les mesures de performance des types de bases de données dans différentes études doivent toujours être mises à jour avec les dernières versions des logiciels de base de données afin que ces chiffres soient exacts.

Bien que je ne puisse pas offrir un verdict définitif sur les performances, voici quelques points à garder à l'esprit :

• L'indexation traditionnelle B-Tree et T-Tree est couramment utilisée dans les bases de données traditionnelles.
• Une étude a proposé des améliorations et des améliorations en combinant les caractéristiques de plusieurs structures d'indexation pour créer l'O2-Tree.
• L'O2-Tree a surpassé les autres structures dans la plupart des tests, en particulier avec d'énormes ensembles de données et des taux de mise à jour élevés.
• La structure B-Tree a fourni les pires performances de toutes les structures d'indexation abordées dans cet article.

D'autres travaux peuvent et doivent être effectués pour améliorer la cohérence des SGBD NoSQL. L'intégration des deux systèmes, NoSQL et bases de données relationnelles, est un domaine à explorer davantage.

Enfin, il est important de noter que NoSQL est un bon ajout aux normes de base de données existantes, mais avec quelques mises en garde importantes. NoSQL échange des fonctionnalités de fiabilité et de cohérence contre des performances et une évolutivité pures. Cela en fait une solution spécialisée, car le nombre d'applications pouvant s'appuyer sur des bases de données NoSQL reste limité.

Le bon côté ? La spécialisation n'offre peut-être pas beaucoup de flexibilité, mais lorsque vous souhaitez effectuer un travail spécialisé aussi rapidement et efficacement que possible, vous n'avez pas besoin d'un couteau suisse. Vous avez besoin de NoSQL.