Qu'est-ce qu'une base de données NoSQL et à quoi servent-elles ?

0
187

Une base de données NoSQL est tout type de base de données qui rompt avec la conception traditionnelle de SQL. Les bases de données NoSQL telles que MongoDB basée sur des documents sont devenues plus populaires ces dernières années. Pourquoi tout ce battage médiatique ?

Limitation de SQL : évolutivité

SQL existe depuis toujours— 45 ans. Il résiste étonnamment bien et les implémentations modernes de SQL sont très rapides. Mais, à mesure que le Web s'est développé, le besoin de bases de données puissantes s'agrandit pour répondre à la demande.

Le moyen le plus simple de faire évoluer une base de données SQL est de l'exécuter sur un ordinateur plus puissant. Les bases de données SQL peuvent être répliquées pour réduire la charge régionale sur une instance individuelle, mais le fractionnement d'une table (souvent appelé partitionnement) est beaucoup plus difficile pour SQL.

Les bases de données NoSQL basées sur des documents résolvent ce problème par conception. Chaque document est indépendant des autres documents de la collection, de sorte que les collections peuvent être réparties beaucoup plus facilement sur plusieurs serveurs. De nombreuses bases de données de documents incluront des outils intégrés pour partager les données sur différents serveurs.

Mais, le problème d'évolutivité n'est pas vraiment un problème tant que vous n'avez pas beaucoup de données. Vous pouvez facilement exécuter une base de données SQL avec des centaines de milliers d'utilisateurs et n'avoir aucun problème, en supposant que votre structure est solide et que vos requêtes sont rapides.

Publicité

MySQL et MongoDB feront probablement le travail pour votre application, donc le choix entre les deux dépend de la structure et de la syntaxe que vous préférez. La facilité de développement est importante, et vous constaterez peut-être que le modèle de document et la syntaxe de MongoDB, beaucoup plus récent, sont plus faciles à utiliser que SQL.

NoSQL vs .Structure SQL

Les bases de données SQL traditionnelles sont souvent appelées bases de données relationnelles en raison de leur structure. Dans une base de données SQL, vous aurez plusieurs tables, chacune contenant plusieurs lignes (appelées enregistrements), qui elles-mêmes ont plusieurs colonnes ou attributs différents. Chaque table séparée est liée à l'autre par une clé primaire, qui forme une relation.

Par exemple, imaginez que vous ayez un tableau avec chaque enregistrement représentant une publication faite par un utilisateur. La clé primaire ici est le nom d'utilisateur, qui peut être utilisé pour lier la table des publications à la table des utilisateurs. Si vous vouliez trouver l'adresse e-mail de la personne qui a publié le message, vous devez effectuer une recherche sur “Jon1996” dans le tableau des utilisateurs et sélectionnez l'option “Email” champ.

Mais cette structure de données peut ne pas fonctionner pour tout le monde. Les bases de données SQL ont un schéma défini de manière rigide, ce qui peut vous gêner si vous devez apporter des modifications ou si vous préférez simplement avoir une mise en page différente. Avec des ensembles de données complexes, les relations entre tout peuvent devenir plus compliquées que les données elles-mêmes.

Le principal type de base de données NoSQL est une base de données de documents JSON, comme MongoDB. Au lieu de stocker des lignes et des colonnes, toutes les données sont stockées dans des documents individuels. Ces documents sont stockés dans des collections (par exemple, un document “user” serait stocké dans une collection “tous les utilisateurs”) et n'ont pas besoin d'avoir la même structure que les autres documents dans la collection.

Par exemple, un “utilisateur” le document peut ressembler à ceci :

{ “username”:”Jon1996″, “email”:”jon1996@gmail.com”, “posts”: [ {“id”:1}, {“id”:2}, {“id”:3}, ] } Publicité

Les champs nom d'utilisateur et e-mail ne sont que des paires clé-valeur, similaires aux colonnes en SQL, mais les “posts” contient un tableau, ce que vous ne trouverez pas dans les bases de données SQL. Supposons maintenant que nous ayons une collection de messages avec des documents tels que :

{ “id”:1, “title”:”First Post”, “content”:”Hello, World!”, “madeby”:”Jon1996″ }

Désormais, lorsque quelqu'un visite la page de Jon, votre application peut récupérer trois publications avec les identifiants 1, 2 et 3, ce qui est généralement une requête rapide. Par rapport à SQL, où vous devrez peut-être récupérer tous les messages correspondant à l'ID utilisateur de Jon. Toujours assez rapide, mais la requête MongoDB est plus directe et a plus de sens.

À quoi servent les bases de données NoSQL ?

NoSQL est une large catégorie et comprend de nombreux types de bases de données construites avec des objectifs différents. Chaque base de données est un outil, et votre travail peut nécessiter un type d'outil spécifique, voire plusieurs outils différents.

Les bases de données SQL comme MySQL, Oracle et PostgreSQL existent depuis avant Internet. Ils sont très stables, ont beaucoup de soutien et peuvent généralement faire le travail pour la plupart des gens. Si vos données vous sont précieuses et que vous souhaitez une solution établie et cohérente, restez fidèle à SQL.

Bases de données de documents JSON, comme MongoDB et Couchbase, sont populaires pour les applications Web avec des modèles de données changeants et pour le stockage de documents complexes. Par exemple, un site comme Amazon peut souvent devoir modifier le modèle de données pour stocker les produits sur le site, donc une base de données basée sur des documents peut bien fonctionner pour eux.

Les bases de données de documents sont destinées à remplacer génériquement SQL, et c'est probablement ce à quoi vous pensez lorsque vous entendez “NoSQL.” Ils sont également plus intuitifs à apprendre que SQL, car vous n'aurez pas à gérer les relations entre les tables ou les requêtes complexes.

Publicité

RethinkDBest une base de données de documents JSON conçue pour les applications en temps réel. Dans une base de données comme MongoDB, vous devez interroger les mises à jour toutes les quelques secondes ou implémenter une API en plus pour suivre les mises à jour en temps réel, ce qui devient rapidement lourd. RethinkDB résout ce problème en diffusant automatiquement les mises à jour sur les flux de socket Web auxquels les clients peuvent se connecter.

Redisest une base de données clé-valeur extrêmement performante qui stocke les petites clés et les chaînes entièrement dans la RAM, ce qui est beaucoup plus rapide à lire et à écrire que même les SSD les plus rapides. Il est souvent utilisé avec d'autres bases de données comme cache en mémoire pour les petites données qui sont souvent écrites et lues. Par exemple, une application de messagerie peut vouloir utiliser Redis pour stocker les messages des utilisateurs (et même envoyer des mises à jour en temps réel avec leurs méthodes Pub/Sub). Le stockage de nombreux petits messages de cette manière peut entraîner des problèmes de performances avec d'autres types de bases de données.

Bases de données graphiquessont construits pour stocker les connexions entre les données. Un cas d'utilisation courant est celui des réseaux sociaux, où les utilisateurs sont connectés les uns aux autres et interagissent avec d'autres données, telles que les messages qu'ils ont publiés.

Dans cet exemple, George est ami avec deux personnes, Jon et Jane. Si un autre type de base de données voulait comprendre la connexion de George à Sarah, ils devraient interroger tous les amis de Jon et tous les amis de Jane. Mais les bases de données de graphes comprennent cette connexion intuitivement ; pour la requête des amis d'amis, la base de données de graphes populaire Neo4J est 60 % plus rapide que MySQL. Pour les amis d'amis d'amis (3 niveaux de profondeur), Neo4J est 180 fois plus rapide.

Les bases de données à larges colonnes comme Cassandra et Hbase, sont utilisées pour stocker des quantités massives de données. Ils sont conçus pour des ensembles de données si volumineux que vous avez besoin de plusieurs ordinateurs pour tout stocker, et ils sont beaucoup plus rapides que SQL et d'autres bases de données NoSQL lorsqu'ils sont répartis sur plusieurs nœuds.