Un vendredi sur deux

NoSQL

Présentation

A faire mes journées R&D, je me rends compte du retard que j’ai pris sur un nombre de sujets incroyable … Donc, on va dire que je continue la remontée et aujourd’hui, je regarde le NoSQL.

Lecture & Ecoute

Pour le coup, avant de commencer la technique, un peu / beaucoup de lecture :). Cf. les liens. Au final beaucoup de vidéos … Je sais pas si lecture était le bon terme …

Résumé / Ma Vision

Not Only SQL

La première chose que je retiens c’est que NoSQL ne veut pas forcément dire “no SQL” mais plus “Not only SQL” et surtout que cela ne vient remplacer les bases de données relationnelles mais que cela vient “compléter” cette solution là où potentiellement les bases de données relationnelles peuvent pas répondre : gros volumes de données, besoin de temps réel, pas besoin de jointure, données non structurées… Comme le dit justement une personne dans une vidéo : NoSQL & Base relationnelle sont des outils comme le marteau et la hache : lequel est le plus adapté pour un clou ou pour couper du bois ?

Différents types

Contrairement peut-être à la base de données relationnelles qui est un type en lui-même, il existe plusieurs types de bases de données “NoSQL”. Les différents articles présents dans les liens contiennent leur description mais voici un résumé :

  • Clé - Valeur (Redis) : à voir comme une grosse table hash. Pour une clé, j’ai une valeur qui peut-être un gros blob.
  • Document (MongoDB, CouchDB) : stocke des collections de documents souvent représenté en JSON,
  • Colonnes (Cassandra) : les données ne sont plus stockées en lignes mais en colonnes sachant que pour une information les colonnes peuvent être différentes
  • Graphe (neo4J)

Différences

Les deux modèles ont leur avantages / inconvénients. Typiquement s’il est nécessaire d’éviter toute redondance, d’assurer des niveaux de transactions fort, le NoSQL ne sera pas forcément la solution car il s’agit clairement des forces d’une base de données relationnelles. Par contre, si le schéma n’est pas clairement définis, que la redondance n’est pas un souci, qu’il y a un fort besoin de réactivité alors un système NoSQL peut servir …

Modélisation

Un autre point qui pose question : la modélisation … Mais là, je pense que je fais face au fait que je fais de la base de données relationnelles depuis 15 ans et que je regarde NoSQL depuis 4 heures :D. Une vidéo qui présente bien (je trouve) les choses : vidéo.

Un résumé : la règle est qu’il n’y a pas de règles. C’est un peu contraire au modèle relationnel au la 3ème forme normale est une norme. Par contre ce qui ne change pas : il faut prendre le temps de penser à son modèle en fonction de son besoin. De plus, pour un même besoin, il est possible d’avoir plusieurs solutions. Faut-il intégrer les données ? Faut-il séparer ? Quand mettre un peu de redondance ? etc …

Deux exemples issues des vidéos :

  • Hiérarchie : est-ce que le manager stocke ses équipes ? ou un équipier stocke son manager ?
  • Relation entre un film et acteur : est-ce que c’est le film qui contient les acteurs ? l’inverse ? ou alors une relation ? Dans ce cas, peut-être qu’un peu de redondance ne nuit pas …

Mon petit bilan

Bon, suite à un impondérable, je n’ai pas passé le temps que je voulais sur cette phase donc c’est pas encore tout clair. Pour être totalement honnête, je ne vois pas trop dans quels projets clients récents (à part un) ce type de système aurait vraiment représenté un plus. Mais comme indiqué dans un lien, cette solution ne s’applique pas partout …

Liens