Il ne fait aucun doute que la manière 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 que jamais un défi 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 de l'évolutivité SQL a été reconnu par les entreprises Web 2.0 dont les besoins en données et en infrastructure sont énormes et croissants, tels que Google, Amazon et Facebook. Ils ont proposé leurs propres solutions au problème - des technologies comme Grande table , DynamoDB , et Cassandra .

Cet intérêt croissant a abouti à un certain nombre de systèmes de gestion de bases 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 y avait des types propriétaires (source fermée) de bases de données NoSQL développées par de grandes entreprises pour répondre à leurs besoins spécifiques, comme 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 propriétaires et open source 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 est le fait que NoSQL est une forme de stockage non structuré .

Cela signifie que les bases de données NoSQL ne pas ont une 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 et 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 magasin de bases de données NoSQL incluent le magasin de colonnes, le magasin de documents, le magasin de valeurs de clé, 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, 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 par le type de mise à l'échelle verticale généralement effectuée avec les systèmes de base de données relationnelle, qui remplace l'hôte principal par un hôte 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.

comment faire croire à un site Web que vous avez payé

D'une part, la plupart des bases de données NoSQL ne prennent pas en charge caractéristiques de fiabilité qui sont nativement pris en charge par les systèmes de bases de données relationnelles. Ces caractéristiques de fiabilité peuvent être résumées par l'atomicité, la cohérence, l'isolation et la 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, développeurs doivent implémenter leur propre code propriétaire, ce qui ajoute plus de complexité au système.

Cela peut 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 de requête 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:

Fonctionnalité	Bases de données NoSQL	Bases de données relationnelles
Performance	Haute	Faible
Fiabilité	Pauvres	Bien
Disponibilité	Bien	Bien
Cohérence	Pauvres	Bien
Stockage de données	Optimisé pour les données volumineuses	De taille moyenne à grande
Évolutivité	Haute	Élevé (mais plus cher)

Il est à noter que le tableau montre une comparaison des niveau de la base de données , pas les divers Systèmes de gestion de bases de données qui implémentent les deux modèles. Ces systèmes fournissent leurs propres techniques propriétaires 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 magasin de données NoSQL

Magasin de valeurs clés

Dans le type de magasin de valeurs de clé, 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, exigeant uniquement que les clés soient uniques au sein de leur propre groupe. Cela permet 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.

Clé	Valeur
«Belfast»	{'Université d'Ulster, campus de Belfast, York Street, Belfast, BT15 1ED'}
«Coleraine»	{'Université d'Ulster, campus de Coleraine, Cromore Road, Co. Londonderry, BT52 1SA'}

Certaines implémentations du magasin de valeurs clés fournissent des mécanismes de mise en cache, qui améliorent 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 la forme d'une 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'effort, de complexité et de temps.

La base de données NoSQL la plus connue basée 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 en ce sens qu'ils sont sans schéma et basés sur un modèle clé-valeur. Les deux, par conséquent, partagent 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 clés entre les deux.

Dans les magasins de documents, les valeurs (documents) fournissent le codage des données stockées. Ces encodages peuvent être XML, JSON ou BSON (JSON codé 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 repose 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 cela se fait dans la plupart des systèmes de gestion de bases de données relationnelles.

Un magasin de colonnes comprend une ou plusieurs familles de colonnes qui regroupent logiquement certaines colonnes de 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 d'espace de clé qui définit la portée de cette clé. Chaque colonne contient des tuples de noms et de valeurs, classés et séparés par des virgules.

exprimer les meilleures pratiques de gestion des erreurs

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 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 graphique 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 considéré comme 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 certaines relations les uns avec les autres, ce qui est représenté 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 graphiques sont généralement utilisées dans les applications de réseautage social. Les bases de données graphiques permettent aux développeurs de se concentrer davantage sur les relations entre les objets que sur les objets eux-mêmes. Dans ce contexte, ils permettent en effet un environnement évolutif et facile à utiliser.

Actuellement, InfoGrid et InfiniteGraph sont les bases de données graphiques 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 bases de données NoSQL.

	Type de stockage	Méthode de requête	Interface	Langage de programmation	Open source	Réplication
Cassandra	Magasin de colonnes	API Thrift	Épargne	Java	Oui	Async
MongoDB	Magasin de documents	Requête Mongo	TCP / IP	C ++	Oui	Async
HyperTable	Magasin de colonnes	HQL	Épargne	Java	Oui	Async
CouchDB	Magasin de documents	MapReduce	DU REPOS	Erlang	Oui	Async
Grande table	Magasin de colonnes	MapReduce	TCP / IP	C ++	Non	Async
HBase	Magasin de colonnes	MapReduce	DU REPOS	Java	Oui	Async

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 distribuent les collections de données, ce qui entraîne une amélioration des performances globales et un système plus équilibré.

D'autres systèmes de base de données NoSQL, tels que 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 constitué d'un ensemble coordonné de contraintes architecturales appliquées aux composants, connecteurs et éléments de données, dans le World Wide Web. Il repose sur un protocole de communication sans état, client-serveur, 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.

comment est mesurée l'élasticité-prix de la demande

En ce qui concerne les bases de données de base de colonnes, Hypertable est une base de données NoSQL écrite en C ++ et basée sur BigTable de Google.

Hypertable prend en charge la distribution de 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 visant 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.

Cassandra

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 d'Amazon DynamoDB, qui est une base de données de valeurs-clés.

Ceci est réalisé en fournissant un système clé-valeur, mais les clés dans 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 d'énormes quantités 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 grand service comme Facebook.

Les principales caractéristiques de Cassandra comprennent:

• 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 sur chaque cluster sont identiques, mais le logiciel de gestion l'est. Lorsqu'une défaillance de l'un des nœuds se produit, les données de ce nœud seront inaccessibles. Cependant, d'autres nœuds (et données) seront toujours accessibles.
• Hashing 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 entre 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 les alternatives open-source construites sur Apple Thrift, telles que Hector.
• Autres fonctionnalités de disponibilité. L’une des fonctionnalités de Cassandra est la réplication des données. Fondamentalement, il reflète les données vers d'autres nœuds du cluster. La réplication peut être aléatoire ou spécifique pour maximiser la protection des données en les plaçant dans 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 également ê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 mis à 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 personnalisation au développeur.
• Actions de lecture / écriture. Le client envoie une requête à un seul nœud Cassandra. Le nœud, conformément à 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, conformément à la politique de partitionnement / placement.

MongoDB

MongoDB est une base de données sans schéma et orientée document é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. Ceci est puissant, car même si les données sont imbriquées dans des documents JSON, elles seront toujours interrogeable et indexable .

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

Fragments

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

Langue de requête Mongo

Comme indiqué précédemment, MongoDB utilise une API RESTful. Pour récupérer certains documents d'une collection de bases de données, 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 quelle partition contient quelles données. Les actions de lecture ou d'écriture sont envoyées des clients à l'un des serveurs de routeur 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.

modèle d'objet de page webdriver sélénium

Semblable à Cassandra, une partition dans MongoDB a un schéma de réplication de données, qui crée un jeu de répliques de chaque partition 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 de l'ensemble de répliques. Replica-Set fournit 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éplicas, une seule partition fait office de partition principale, toutes les autres partitions de réplique sont des partitions secondaires. Toutes les opérations d'écriture et de lecture vont à la partition principale, puis sont réparties uniformément (si nécessaire) vers les autres partitions secondaires de l'ensemble.

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

Il convient de noter que le partitionnement (ou le partage des données entre les fragments) dans MongoDB est complètement 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.

Indexation des structures 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 de l'arbre B

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 des arbres mais plus d'espace gaspillé.

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

Indexation T-Tree

La structure de données de 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 d'enfants différent.

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

Chaque nœud stocke plus d'un tuple {clé-valeur, pointeur}. En outre, la recherche binaire est utilisée en combinaison avec les nœuds à plusieurs tuples pour améliorer le stockage et les 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 enfants 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 de l'arbre O2

L'arbre O2 est fondamentalement 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 arbre O2 d'ordre m (m ≥ 2), où m est le degré minimum de l'arbre, satisfait les propriétés suivantes:

• Chaque nœud est rouge ou noir. La racine est noire.
• Chaque nœud feuille est de couleur noire et se compose d'un bloc ou d'une page contenant des paires «valeur clé, pointeur d'enregistrement».
• Si un nœud est rouge, 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 il 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 liés par deux 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 de l'arbre en T, de l'arbre B + et de l'arbre O2 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'indice O2-Tree fonctionne nettement mieux que la plupart des autres structures de données, les structures B-Tree et Red-Black Tree en souffrent le plus.

différence entre objectif c et swift

Le cas de NoSQL?

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

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 performances élevées, de leur grande évolutivité et de leur facilité d'accès; cependant, ils manquent 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 sur les types de bases de données dans différentes études toujours être mis à jour avec les dernières versions du logiciel de base de données afin que ces chiffres soient exacts.

Bien que je ne puisse pas offrir de 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 aboutir à 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 couvertes dans cet article.

Des travaux supplémentaires peuvent et doivent être réalisé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 commercialise des fonctionnalités de fiabilité et de cohérence pour des performances et une évolutivité optimales. 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é.

L'avantage? La spécialisation n’offre peut-être pas beaucoup de flexibilité, mais lorsque vous voulez faire un travail spécialisé aussi rapidement et efficacement que possible, vous n’avez pas besoin d’un couteau suisse. Vous avez besoin de NoSQL.

En relation: Business Intelligence Platform: didacticiel sur l'utilisation du pipeline d'agrégation MongoDB