Quand faut-il envisager d’utiliser une base de données NoSQL (plutôt qu’une base relationnelle) ?

Pour faire simple, les bases de données NoSQL conviennent mieux quand vos données ne rentrent pas bien dans les tables.

Nous travaillons avec des bases de données relationnelles SQL depuis 40 ans : elles sont idéales pour le traitement des transactions impliquant des données tabulaires stockées dans des colonnes et des lignes. Nous pouvons aussi analyser très efficacement ces données dans des bases de données multidimensionnelles.

Les données qui se prêtent bien aux tables relationnelles sont de type atomique. Cela signifie tout simplement qu’elles peuvent être subdivisées jusqu’à arriver aux plus petits composants manipulables.

Par exemple, nous stockons rarement le nom complet d’un client dans un même champ. Quand on saisit les données du client « M. Jacques Lemasson » dans une base de données relationnelles, si nous souhaitons pouvoir isoler toutes les personnes ayant pour civilité « M. » et classer les clients par ordre alphabétique selon leur nom de famille et leur prénom, nous devons stocker les données du nom dans trois colonnes différentes d’une table.

Aujourd’hui, une grande partie des données collectées ne rentrent pas dans ce modèle de table : images, données enregistrées par des capteurs, documents Word, flux Twitter et autres données souvent appelées Big Data.

Et même si on arrive parfois à placer ces données dans des tables, ce n’est pas forcément efficace.

On pourrait imaginer stocker chaque pixel d’une image dans une ligne distincte d’une table relationnelle. Mais il faut alors se poser la question suivante : quel code SQL écrire pour déterminer si l’image comprend une personne ?

Je ne veux même pas imaginer une seule seconde ce à quoi ce code pourrait ressembler.

La bonne nouvelle, c’est que nous avons désormais des moteurs de bases de données dédiés conçus pour conserver et gérer le Big Data : les bases de données NoSQL.

Les bases de données relationnelles nous imposent de recourir à des schémas de données. Imaginez que ce schéma est une façon de classer les données. Dans les bases de données relationnelles, il faut segmenter ces données en unités atomiques, puis les organiser dans des tableaux sous forme de colonnes et de lignes.

Il existe différents types de bases de données NoSQL, de sorte que toute généralisation excessive serait trompeuse. Mais globalement, ils ne nécessitent qu’un schéma très simple, voire aucun.

Par exemple, certains systèmes de bases de données NoSQL permettent d’enregistrer des fichiers image directement dans la base de données sans altérer la structure de celle-ci. On pourrait aussi stocker des fichiers audio dans la même base de données.

Il devient beaucoup plus simple de placer des données dans la base et on gagne en souplesse puisque la structure des données n’est pas figée.

En conclusion, si vos données sont difficilement stockables sous forme tabulaire ou interrogeables en langage SQL, regardez donc du côté du NoSQL.