dire oui au NoSQL ? (1/2)

NoSQL. Not only SQL.

Peut-être êtes vous déjà tombé nez à nez avec ce terme barbare, mi-buzz word, mi déclaration guerrière qui, depuis maintenant 3 ans a fait le tour des blogs, présentations, et autres tweets. Ce mouvement, annonciateur d’un renouveau du monde de la gestion de données et du lancement de la course au Big Data, a aujourd’hui prouvé son utilité sur des projets d’ampleur au travers de produits de plus en plus matures qui viennent étoffer la boîte à outils de l’architecte logiciel.

Ce type de solutions trouve en particulier sa place dans des domaines tels que le M2M où l'hétérogénéité, la profusion et les besoins en haute disponibilité et en analyse statistique (parfois temps réel) des données récoltées font rapidement toucher aux limites des produits classiques.

Le NoSQL, demain au cœur de votre SI ?

une histoire de bases

Reposant sur des principes établis dans les années 70, les systèmes de gestion de bases de données relationnelles (SGBDR) se sont imposés comme la pierre angulaire de toute architecture logicielle d’ampleur. Ils proposent de stocker vos données sous une forme structurée en tables, dont chaque ligne représente un « enregistrement». Les relations entre enregistrements sont décrits via une utilisation de certain de leurs champs comme « clé » primaire/étrangère.

Le langage SQL (pour Structured Query Language), normalisé en 1986 est la langue commune comprise par une vaste majorité de SGBDR. L’utilisation du SQL a favorisé une convergence fonctionnelle entre ces solutions, au point qu’il est devenu relativement commun de développer des applications interrogeant des bases relationnelles sans savoir laquelle des solutions Oracle, SQL Server, PostgreSQL ou MySQL sera effectivement utilisée.

Le SQL et les bases relationnelles sont devenus au fil des ans des incontournables, à tel point que leur utilisation pour le stockage de tout type de données partagées entre plusieurs applicatifs, ou devant être persistées, allait implicitement de soi, et n’était que rarement remise en question… jusqu’à récemment.

nouveaux besoins

Par leur philosophie, les bases relationnelles répondent particulièrement bien aux besoins suivants : le stockage, la manipulation et le partage de données structurées, durables (persistées sur disque), devant offrir des garanties de cohérence fortes (via les mécanismes de transaction).

Typiquement, les bases relationnelles trouvent tout leur sens dans le secteur bancaire, où la cohérence des données (ne pas créer ou perdre de valeur lors d’une transaction bancaire par exemple) et leur durabilité sont des priorités absolues.

Avec l’essor des services Web – en particulier les réseaux sociaux – de nouveaux besoins ont émergé concernant les solutions de stockage de données :

• être capable de traiter les demandes simultanées de milliers voire millions d’utilisateurs, ce nombre pouvant croître exponentiellement en quelques semaines (la fameuse scalabilité, et oui, ça arrive)
• privilégier les performances à la cohérence (l’utilisateur attend un service réactif et tolère certaines approximations – comme par exemple de ne pas voir exactement le même contenu que son voisin)
• maintenir une haute disponibilité des données, même dans le cas de défaillances matérielles

Face à ce type de demandes, les solutions apportées par les SGBDR se trouvent limitées par le modèle relationnel lui-même. D’où l’apparition de solutions basées sur des approches radicalement différentes.

si j’avais un marteau

La « parabole du marteau » est une illustration largement diffusée dans la littérature pro NoSQL : « lorsqu’on a un marteau en main, tout ce qui dépasse a tendance à ressembler à un clou ».

Autrement dit, ce n’est pas parce qu’un outil est répandu et sait résoudre efficacement une famille de problèmes, qu’il est le meilleur dans tous les cas. Au contraire même, plus un outil se veut généraliste, et plus les chances qu’il soit la solution optimale à un problème spécifique sont faibles. Parfois, un tournevis cruciforme sera votre meilleur allié.

Le mouvement NoSQL se présente donc comme une opportunité d’étendre la gamme des solutions disponibles dans notre boîte à outils pour la gestion de nos données.

Si le terme « NoSQL » a réussi, en servant de bannière, à mettre en avant toute une gamme de nouveaux produits (ou de plus anciens : BerkeleyDB, 20 ans d’âge, serait une base NoSQL), il ne présage rien des capacités techniques et de l’approche conceptuelle choisie par ceux-ci : il existe bien des manières de ne pas faire du relationnel.

C’est ce que nous verrons prochainement dans la deuxième partie de cet article.

Charly

crédit photo : © Chepko Danil - Fotolia.com