BDD NoSQL - Partie 1 : Les bases de données document

Authors : Alterway

Les bases de données NoSQL ont gagné en notoriété ces dernières années, grâce à leur efficacité dans des cas pratiques qu'une base de données relationnelle (comme Oracle ou MySQL) n'offre pas. Cet article a pour but de vous exposer de façon synthétique ce qu'offrent les bases NoSQL de type Document telle que MongoDB et en quoi elles diffèrent des bases SQL classiques.

Principes de la base NoSQL de type Document

Les principes que l'ont retrouve dans les bases Documents sont les suivants : - Un schéma de données non déterminé : Dans une même collection (table), les champs de chaque document ne sont pas prédéfinis. Vous pourrez trouver les valeurs suivantes dans la même collection :

{{< highlight json >}} {"_id" : ObjectId("551bacdec..."), "name": "John", "cat": "Miaou"} {"_id" : ObjectId("651bacdec..."), "name": "Joe", "dog": "Wouf"} {{< /highlight >}}

- Absence de jointures (elles ne sont pas recommandées) : La structure d'un document est fait de telle sorte que les joins sont le moins nécessaires possibles. Il est toute fois possible de faire des jointures, mais les bases de données en document ne sont pas faites pour ce besoin, elles seront donc plus lentes qu'une base de données relationnelle. Il existe cependant d'autres moyens de joindre des données provenant de deux collections distinctes, comme le map-reduce sur MongoDB. Afin d'éviter les jointures, il est possible de faire des documents comme suit :

{{< highlight json >}} { "_id" : ObjectId("651bacdec..."), "name": "Joe" "adresse": { "rue": "1 rue Royale", "code-postal": "92213" } } {{< /highlight >}}

L'utilisation d'une base de données Document est plus adaptée à un stockage de données non figées dans le temps. Pour des API web, leur utilisation peut être recommandée, du fait de leur simplicité d'utilisation et de déploiement.

Example d'un cas client

Lors d'un projet de centralisation de données de nos utilisateurs, le choix d'une base de données document s'est imposé à nous du fait de la flexibilité qu'elle apportait. Pour ce projet, nous devions récupérer des documents d'exports de données en csv sur différents serveurs ftp, et selon l'export, la donnée n'était pas présentée de la même façon, avec plus ou moins d'informations sur l'utilisateur. Des requêtes à des API devaient également être faites pour compléter le jeu de données. Selon la qualité des données récupérée, et leur provenance (différents domaines métier), nous stockions les données dans des collections (tables) différentes. Une fois les données insérées en base, nous faisions un aggrégat des données en liant les utilisateurs par leur nom, n'ayant pas d'identifiant commun à toutes les sources, grâce à un map-reduce. Les données "réduites" étaient alors exploitables. Il avait été décidé en début de projet de transférer les données de la base MongoDB vers une base SQL, afin qu'un data warehouse puisse s'y connecter et consommer les données. Il s'est avéré que c'était beaucoup trop coûteux pour nous de faire le transfert de la base MongoDB vers la base SQL. Nous avons modifié la façon de consommer la donnée du data warehouse afin qu'il passe par des API que nous exposions. Après cette expérience j'avais adhéré aux bases de données Document, notamment dans le cas de normalisation de données. Autres Exemples de bases de donnée document :

• Redis
• Riak
• CouchDB Dans mon prochain article sur les bases de données NoSQL, je vous exposerai les principes des bases de données en Graphe, puis un troisième et dernier article sur les bases de données en Colonne viendra clôturer ce coup d'oeil sur les bases NoSQL.