Caractéristiques communes de NoSQL - mannequins

Les livres et les blogs NoSQL offrent des opinions différentes sur ce qu'est une base de données NoSQL. Quatre fonctions principales de NoSQL, présentées dans la liste suivante, s'appliquent à la plupart des bases de données NoSQL. La liste compare NoSQL au SGBD relationnel traditionnel:

• Schéma agnostique: Un schéma de base de données est la description de toutes les structures de données et de données possibles dans une base de données relationnelle. Avec une base de données NoSQL, un schéma n'est pas requis, ce qui vous donne la liberté de stocker des informations sans avoir à faire de conception de schéma.

• Non relationnel: Les relations dans une base de données établissent des connexions entre des tables de données. Par exemple, une liste de détails de transaction peut être connectée à une liste distincte de détails de livraison. Avec une base de données NoSQL, ces informations sont stockées sous la forme d'un agrégat - un enregistrement unique avec tout ce qui concerne la transaction, y compris l'adresse de livraison.

• Matériel de base: Certaines bases de données sont conçues pour fonctionner au mieux (ou uniquement) avec du matériel de stockage et de traitement spécialisé. Avec une base de données NoSQL, des serveurs standard prêts à l'emploi peuvent être utilisés. Ajouter plus de ces serveurs bon marché permet aux bases de données NoSQL d'évoluer pour gérer plus de données.

• Hautement distribuable: Les bases de données distribuées peuvent stocker et traiter un ensemble d'informations sur plusieurs appareils. Avec une base de données NoSQL, un cluster de serveurs peut être utilisé pour contenir une seule grande base de données.

Schéma agnostique

Les bases de données NoSQL sont agnostiques. Vous n'êtes pas obligé de faire beaucoup de travail de conception avant de pouvoir stocker des données dans des bases de données NoSQL. Vous pouvez commencer à coder et stocker et récupérer des données sans savoir comment la base de données stocke et fonctionne en interne. (Si et quand vous avez besoin de fonctionnalités avancées, vous pouvez ajouter manuellement d'autres index ou modifier les structures de stockage de données.) L'agnosticisme de schéma peut être la différence la plus significative entre NoSQL et les bases de données relationnelles.

Le grand avantage d'une base de données agnostique de schéma est que le temps de développement est raccourci. Cet avantage augmente au fur et à mesure que vous parcourez plusieurs versions de développement et que vous devez modifier les structures de données internes dans la base de données.

Par exemple, dans un SGBDR traditionnel, vous passez par un processus de refonte du schéma. Le schéma indique à la base de données à quelles données s'attendre. Modifiez les données stockées ou les structures et vous devez réinsérer la base de données à l'aide d'un schéma modifié. Si vous deviez effectuer un changement, vous devrez passer beaucoup de temps à décider comment réorganiser les données existantes. Dans les bases de données NoSQL, vous stockez simplement une structure de données différente. Il n'est pas nécessaire de dire la base de données à l'avance.

Vous devrez peut-être modifier vos requêtes en conséquence, peut-être ajouter l'index spécifique (tel qu'un index d'intervalle entier pour autoriser moins et plus que les requêtes spécifiques au type de données), mais l'ensemble du processus beaucoup moins douloureux qu'avec un SGBDR.

Le SGBDR a décollé à cause de sa flexibilité et parce que, en utilisant SQL, il a accéléré le changement d'une requête. Les bases de données NoSQL offrent cette flexibilité pour modifier à la fois le schéma et la requête, ce qui est l'une des principales raisons pour lesquelles ils seront de plus en plus adoptés au fil du temps.

Même sur requête, vous ne devez pas trop vous inquiéter de connaître les modifications de schéma - considérez un index sur un numéro de compte de champ, où numéro de compte peut être situé n'importe où dans un document stocké dans une base de données NoSQL. Vous pouvez modifier la structure et la relocaliser où numéro de compte est stocké, et si l'élément a le même nom ailleurs dans le document, il est toujours disponible pour la requête sans modifier votre mécanisme de requête.

Notez que toutes les bases de données NoSQL ne sont pas totalement indépendantes des schémas. Certains, tels que HBase, vous obligent à arrêter la base de données pour modifier les définitions de colonne. Ils sont toujours considérés comme des bases de données NoSQL car tous les champs définis (colonnes dans ce cas) ne doivent pas être connus à l'avance pour chaque enregistrement - seulement les familles de colonnes.

Le SGBDR permet d'identifier les champs individuels des enregistrements en tant que valeurs nulles . Le problème avec un SGBDR réside dans le fait que la taille et la performance des données stockées sont négativement affectées lorsque le stockage est réservé aux valeurs nulles, au cas où l'enregistrement pourrait ultérieurement avoir une valeur dans cette colonne. Dans Cassandra, vous ne fournissez simplement pas les données de cette colonne, ce qui résout le problème.

Non relationnel

Les systèmes de gestion de bases de données relationnelles ont été le moyen dominant pour stocker les données d'application pendant plus de 20 ans. Beaucoup de travail mathématique a été fait pour prouver la théorie qui les sous-tend.

Cette sous-couche décrit la relation entre les tableaux. Une seule ligne d'ordre peut se rapporter à de nombreuses lignes d'adresse de livraison, mais chaque ligne d'adresse de livraison concerne également plusieurs lignes d'ordre. C'est une beaucoup - à - beaucoup de relations .

Les bases de données NoSQL n'ont pas ce concept de relation entre leurs enregistrements. Ils dénormalisent plutôt les données. Cela signifie que dans une base de données NoSQL aurait une structure de commande avec l'adresse de livraison intégrée. Cela signifie que l'adresse de livraison est dupliquée dans chaque ligne de commande qui l'utilise. Cette approche présente l'avantage de ne pas nécessiter de jointures de temps de requête complexes entre plusieurs structures de données (tables).

Les bases de données NoSQL ne stockent pas d'informations sur la manière dont les enregistrements individuels se rapportent à d'autres enregistrements dans la base de données, ce qui peut sembler être une limitation. Cependant, les bases de données NoSQL sont plus flexibles en termes de structures de données que vous pouvez stocker.

Considérez une commande d'un détaillant en ligne. La commande peut inclure des codes de produit, des quantités, des prix d'articles et des descriptions d'articles, ainsi que des informations sur la personne qui commande, telles que l'adresse de livraison et les informations de paiement.

Plutôt que d'insérer dix lignes dans une variété de tables dans une base de données relationnelle, vous pouvez à la place stocker une structure unique pour toutes ces informations de commande, par exemple un document JSON ou XML.

En théorie des bases de données relationnelles, l'objectif est de normaliser vos données (c'est-à-dire d'organiser les champs et les tables pour supprimer les données en double). Dans les bases de données NoSQL, en particulier les bases de données Document ou Aggregate, vous dénormaliserez souvent délibérément les données en stockant plusieurs fois plusieurs données.

Vous pouvez stocker, par exemple, "Adresse de livraison client" plusieurs fois sur de nombreuses commandes effectuées par un client au fil du temps, plutôt que de les stocker une seule fois et de s'y référer dans plusieurs commandes. Cela nécessite un espace de stockage supplémentaire et un peu de prévoyance dans la gestion de votre application. Alors pourquoi le faire?

Il y a deux avantages à stocker des données plusieurs fois:

• Stockage et récupération faciles: Sauvegardez et obtenez un seul enregistrement.

• Vitesse de requête: Dans les bases de données relationnelles, vous joignez des informations et ajoutez des contraintes entre les tables au moment de la requête. Cela peut nécessiter le moteur de base de données pour évaluer plusieurs tables. Plus vous avez de contraintes de requêtes sur différentes tables, plus vous réduisez la vitesse de votre requête. (C'est pourquoi un SGBDR a des vues précalculées.) Dans une base de données NoSQL, toutes les informations dont vous avez besoin pour évaluer votre requête se trouvent dans un seul document. Par conséquent, vous pouvez rapidement déterminer la liste des documents correspondants.

Les vues relationnelles et les dénormalisations NoSQL sont des approches différentes du problème de la propagation des données entre les enregistrements. Dans NoSQL, vous devrez peut-être gérer plusieurs dénormalisations représentant différentes vues des mêmes données. Cette approche augmente le coût de stockage mais vous donne beaucoup de temps de requête.

Compte tenu du coût toujours plus faible du stockage et de la vitesse accrue de développement et d'interrogation, les données dénormalisées ( vues matérialisées ) ne sont pas une raison majeure pour réduire les solutions NoSQL. C'est juste une façon différente d'aborder le même problème, avec ses propres avantages et inconvénients.

NoSQL est hautement distribuable et utilise du matériel de base

Dans de nombreuses bases de données NoSQL, une décision de conception clé consiste à utiliser plusieurs ordinateurs pour stocker des données pour une seule base de données plutôt que d'avoir toute la base de données sur un seul serveur.

Il est difficile de stocker des données sur plusieurs machines et de les interroger. Vous devez envoyer la requête à tous les serveurs et attendre une réponse. Heureusement, vous avez configuré les machines de façon à ce qu'elles soient assez rapides pour se parler entre elles afin de gérer les requêtes distribuées!

Le principal avantage de cette approche est dans le cas de très grands ensembles de données, car pour certains besoins de stockage, même le plus grand serveur unique disponible ne peut pas stocker ou traiter toutes les données dont vous avez besoin. Considérez tous les messages sur Twitter et Facebook. Vous avez besoin d'un mécanisme distribué pour gérer efficacement toutes ces données, même si elles concernent surtout ce que les gens avaient pour le petit-déjeuner et les jolies vidéos de chats.

Un avantage de la distribution de votre base de données est que vous pouvez utiliser des serveurs moins chers, appelés serveurs de base .Même pour les ensembles de données plus petits, il peut être moins coûteux d'acheter trois serveurs de base au lieu d'un seul serveur plus puissant.

Un autre avantage clé est que l'ajout de haute disponibilité est plus facile. vous êtes déjà à mi-chemin en distribuant vos données. Si vous répliquez vos données une ou deux fois sur d'autres serveurs du cluster, vos données seront toujours accessibles, même si l'un des serveurs tombe en panne, brûle et meurt.

Toutes les bases de données open source ne prennent pas en charge la haute disponibilité, sauf si vous achetez la version prise en charge et payante de la base de données auprès de la société qui l'a développée.

Une exception à la règle hautement distribuable est celle des bases de données graphiques. Afin de répondre efficacement à certaines requêtes graphiques en temps opportun, les données doivent être stockées sur un seul serveur. Personne n'a encore résolu ce problème particulier.

Vérifiez soigneusement si vous avez besoin d'un magasin triple ou d'un magasin de graphes. Les magasins triples sont généralement distribuables, contrairement aux magasins graphiques. Lequel vous avez besoin dépend des requêtes que vous devez soutenir.