Les bases des bases de données NoSQL - et pourquoi nous en avons besoin

Un guide du débutant sur le monde NoSQL

L'organisation des données est une tâche très difficile. Quand nous disons organiser, nous catégorisons en fait les choses en fonction de leur type et de leur fonction.

Une option est que le SGBDR est comme une feuille Excel - vous catégorisez les données sous forme de tableaux. Vous pouvez former des relations entre les tables.

Une requête interroge la base de données, ce qui vous donne une réponse pertinente en retour. Ce langage d'interrogation est SQL ou Structured Query Language.

Par exemple,

select * from Employee_Data;

sélectionne toutes les données d'employé de la table Employee_Data.

Les bases de données relationnelles suivent un schéma , un plan détaillé du fonctionnement de vos tables.

Vous utilisez Amazon, Facebook et tant d'applications de réseautage. Ils publient des mises à jour, ajoutent de nouvelles fonctionnalités et même des modules supplémentaires. Alors, comment changer le schéma à chaque fois? N'est-il pas long pour de si grandes entreprises de consacrer leur temps et leur travail à changer le schéma?

C'est là que SQL ne pouvait pas fonctionner .

Les inconvénients du SGBDR

Les bases de données relationnelles ne sont pas aussi mauvaises que les gens le décrivent ces jours-ci. Ils sont toujours utilisés par de nombreuses organisations. L'introduction de NoSQL dans l'image consiste à remplir les espaces où le SGBDR ne peut plus être utilisé.

Je vais vous montrer des exemples afin que vous ayez une compréhension claire.

1. Le SGBDR ne peut pas gérer la «variété de données».

La quantité de données non structurées continue d'augmenter chaque année et sa gestion est difficile. Le SGBDR ne peut pas forcer tous les types de données sous un schéma unifié de tables.

Les silos de données sont également un problème pour les développeurs.

Selon Tech Target, un silo de données est un référentiel de données qui reste sous le contrôle d'un département. Il est isolé du reste de l'organisation.

Cela signifie que lorsqu'il existe plus de silos pour les mêmes données, leur contenu est susceptible de différer. Cela crée de la confusion sur le référentiel qui représente la version la plus à jour.

L'augmentation des données de l'année 2013 à 2020 est visible dans l'image ci-dessous.

Environ 44 octets Zeta de données seront générés en 2020.

La gestion de données aussi diverses qui ne sont pas liées les unes aux autres pourrait être beaucoup plus difficile dans le SGBDR.

Exemple: Il est difficile de stocker les détails d'un patient dont les conditions corporelles varient. La catégorisation de données aussi diverses est difficile dans le SGBDR.

2. Difficile de changer les tables et les relations.

La modification des relations entre les tables ou l'ajout d'une nouvelle table pourrait affecter les relations existantes. Cela signifie changer le schéma.

Changer de schéma reviendrait à éliminer l'existant et à concevoir un nouveau schéma.

L'ajout d'une nouvelle fonctionnalité nécessiterait tous les éléments pour prendre en charge la nouvelle structure. Le changement est inévitable.

Exemple: chaque colonne supplémentaire a besoin que toutes les lignes précédentes aient des valeurs pour cette colonne. Alors que dans Cassandra (une base de données NoSQL), vous pouvez ajouter une colonne à des partitions de ligne spécifiques.

3. Le SGBDR suit les propriétés ACID de la base de données.

Les propriétés ACID d'une base de données sont l'atomicité, la cohérence, l'isolement et la durabilité. ‌

Atomicité - Une approche «tout ou rien». Si une instruction de la transaction échoue, la transaction entière est annulée.

Cohérence - La transaction doit respecter tous les protocoles définis par le système. Aucune transaction à moitié terminée.

Isolation - Aucune transaction n'a accès à une autre transaction qui est dans un état intermédiaire ou inachevé. Chaque transaction est indépendante.

Durabilité - Garantit qu'une fois qu'une transaction est validée dans la base de données, elle est préservée grâce à l'utilisation de sauvegardes et de journaux de transactions.

Les propriétés ACID ne sont pas flexibles.

Par exemple, le SGBDR suit la normalisation ou un concept de point de vérité unique . Pour chaque modification que vous apportez, vous devez vous assurer des propriétés ACID strictes. Les règles d'intégrité de l'entité et d'intégrité référentielle s'appliquent également.

Le théorème CAP

Selon Wikipedia, le théorème CAP ( théorème de Brewer) indique qu'il est impossible pour un magasin de données distribué de fournir simultanément plus de deux des trois garanties suivantes:

Cohérence: comme le C dans ACID.

Disponibilité : ‌Les ressources doivent être toujours disponibles. Il devrait y avoir une réponse sans erreur.

Tolérance de partition : aucun point (ou nœud) de défaillance unique.

Il est difficile de réaliser les trois conditions. Il faut faire un compromis entre les trois.

BASE à la rescousse!

‌NoSQL repose sur un modèle plus souple connu sous le nom de modèle BASE. BASE ( B asically A vailable, S état souvent, E cohérence ventual).

Fondamentalement disponible: garantit la disponibilité des données. Il y aura une réponse à toute demande (peut également être un échec).

État souple : l'état du système peut changer avec le temps.

Cohérence finale : Le système deviendra finalement cohérent une fois qu'il cessera de recevoir des entrées.

Les bases de données NoSQL abandonnent les exigences A, C et / ou D, et en retour, elles améliorent l'évolutivité.

NoSQL

C'est à ce moment que NoSQL est venu à la rescousse.‌ Il s'agit de bases de données « Not Only SQL» ou «Non-relationnelles».

Caractéristiques de NoSQL:

  • Sans schéma
  • Finalement cohérent (comme dans la propriété BASE)
  • Réplication des magasins de données pour éviter un point de défaillance unique.
  • Peut gérer une variété de données et d'énormes quantités de données.

Types de bases de données NoSQL

Les bases de données NoSQL se répartissent en quatre catégories principales:

Magasins de valeur clé - Riak, Voldemort et Redis

Magasins à colonnes larges - Cassandra et HBase.

Bases de données de documents - MongoDB

Bases de données Graph - Neo4J et HyperGraphDB.

Les mots sur le côté droit sont des exemples des types de types de bases de données NoSQL.

1. Magasins de valeurs clés

Un magasin de valeurs de clé utilise une table de hachage dans laquelle il existe une clé unique et un pointeur vers un élément de données particulier.

Imaginez que les magasins de valeurs clés ressemblent à un annuaire téléphonique où les noms de l'individu et leurs numéros sont mappés ensemble.

Les magasins de valeurs de clé n'ont pas de langue de requête par défaut. Vous récupérez des données à l'aide des commandes get, put et delete . C'est la raison pour laquelle il a des performances élevées.

Applications : utile pour le stockage des commentaires et des informations de session. ‌Pinterest utilise Redis pour stocker des listes d'utilisateurs, d'abonnés, de non-abonnés et de tableaux.

2. Magasins à colonnes larges

Dans une base de données de magasin de colonnes, les colonnes de chaque ligne sont contenues dans cette ligne.

Chaque famille de colonnes est un conteneur de lignes dans une table SGBDR. La clé identifie la ligne composée de plusieurs colonnes.

Les lignes n'ont pas besoin d'avoir le même nombre de colonnes. Les colonnes peuvent être ajoutées à n'importe quelle ligne à tout moment sans avoir à l'ajouter à d'autres lignes. Il s'agit d'un magasin de lignes partitionné.

Comment une base de données en colonnes stocke-t-elle les données?

Applications : Spotify utilise Cassandra pour stocker les attributs et les métadonnées du profil utilisateur.

3. Bases de données de documents

‌Les magasins de documents utilisent des documents JSON, XML ou BSON (codage binaire de JSON) pour stocker des données.

C'est comme une base de données clé-valeur, mais un magasin de documents se compose de données semi-structurées .

Un seul document consiste à stocker les enregistrements et ses données.

‌Il ne prend pas en charge les relations ou les jointures.

Si nous voulons stocker les détails des clients et leurs commandes, nous pouvons utiliser des magasins de documents pour le faire.

Applications: SEGAutilise MongoDB pour gérer 11 millions de comptes en jeu basés sur MongoDB.

4. Bases de données graphiques

‌ Les nœuds et les relations sont les composants essentiels des bases de données de graphes. Un nœud représente une entité. Une relation représente la manière dont deux nœuds sont associés.

‌Dans le SGBDR, l'ajout d'une autre relation entraîne de nombreux changements de schéma.

La base de données Graph ne nécessite le stockage des données qu'une seule fois (nœuds). Les différents types de relations (arêtes) sont spécifiés aux données stockées.

Les relations entre les nœuds sont prédéterminées, c'est-à-dire qu'elles ne sont pas déterminées au moment de la requête.

Traverser les relations persistantes est plus rapide.

Il est difficile de changer une relation entre deux nœuds. Cela entraînerait des changements régressifs dans la base de données.

Exemple : Cette image montre comment MySQL fonctionne où il doit effectuer de nombreuses opérations pour trouver un résultat correct pour Alice.

Une base de données graphique , qui prédétermine les relations.

Voici quelques-unes des informations de base dont vous aurez besoin pour commencer à explorer NoSQL. De nouvelles bases de données sont inventées pour des usages spécifiques.

Apprenez le type de données que votre application génère, puis il est facile de choisir la bonne base de données.

J'écris des histoires sur les leçons de vie, le codage et la technologie. Pour en savoir plus, suivez-moi sur Twitter et Medium.