Name: Tremplin Numérique
Price range: $$$

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. De quoi parle tout ce battage médiatique?

Sommaire

Les limites de SQL: évolutivité

SQL existe depuis toujours – 45 ans. Cela tient é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 qui évoluent pour répondre à la demande augmente également.

Le moyen le plus simple de mettre à l’échelle 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 en fractionnant une table (souvent appelée sharding) est beaucoup plus difficile pour SQL.

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

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

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 du plus récent MongoDB sont plus faciles à utiliser que SQL.

NoSQL et structure SQL

Les bases de données SQL traditionnelles sont souvent appelées bases de données relationnelles en raison de la façon dont ils sont structurés. Dans une base de données SQL, vous aurez plusieurs tables, chacune contenant plusieurs lignes (appelées records), qui ont eux-mêmes plusieurs colonnes différentes, ou les attributs. Chaque table séparée est liée à l’autre par une clé primaire, qui forme une relation.

Par exemple, imaginez que vous ayez une table 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 souhaitez trouver l’adresse e-mail de l’auteur de la publication, effectuez une recherche sur «Jon1996» dans le tableau des utilisateurs et sélectionnez le champ «E-mail».

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 disposition 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 type principal 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 «utilisateur» serait stocké dans une collection «tous les utilisateurs») et n’ont pas besoin d’avoir la même structure que les autres documents de la collection.

Par exemple, un document «utilisateur» peut ressembler à ceci:

{
  "username":"Jon1996",
  "email":"jon1996@gmail.com",
  "posts": [
   {"id":1},
   {"id":2},
   {"id":3},
  ]
}

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

{
  "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 ID 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 qui correspondent à 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 vaste 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.

Bases de données SQL comme MySQL, Oracle et PostgreSQL existent bien avant Internet. Ils sont très stables, bénéficient d’un soutien important et peuvent généralement faire le travail pour la plupart des gens. Si vos données sont précieuses pour vous et que vous souhaitez une solution établie et cohérente, respectez 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 stocker des documents complexes. Par exemple, un site comme Amazon peut souvent devoir changer le modèle de données pour stocker des produits sur le site, de sorte qu’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 le SQL de manière générique et sont 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.

RepenserDB est 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 de cela pour suivre les mises à jour en temps réel, ce qui devient vite lourd. RethinkDB résout ce problème en poussant automatiquement les mises à jour sur les flux Websocket auxquels les clients peuvent se connecter.

Redis est une base de données clé-valeur extrêmement performante qui stocke les petites clés et 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 souhaiter 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 graphiques sont conçus 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 publications qu’ils ont faites.

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 graphiques comprennent cette connexion intuitivement; pour la requête des amis d’amis, la base de données graphique 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.

Bases de données à colonnes larges comme Cassandra et Hbase, sont utilisés 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.