Les géants du web (Google, Facebook, Twitter...) ont aidé à populariser le concept "NoSQL", une alternative aux traditionnels SGBDR ("Systèmes de Gestion de Bases de Données Relationnelles") qui leur permet de gérer les masses colossales d'informations qu'ils collectent et utilisent.
Ces exemples donnent des idées aux autres utilisateurs de masses de données volumineuses, dont les établissements financiers. Malheureusement, les mythes et légendes entourent encore les principes de NoSQL (dont le nom est un acronyme pour "Not Only SQL" et non un rejet total du langage de requête SQL), laissant croire qu'il s'agit de la solution ultime de gestion des données.
Pour remettre les choses au point, le site DZone publie une "Refcardz" sur le sujet, qui, bien que de teneur technique, décrit de manière claire et précise les potentiels et les limitations des bases NoSQL (et propose, de plus, une analyse détaillée de 3 "produits").
Le postulat de départ est que, pour gérer des volumes potentiellement infinis de données, une solution de gestion distribuée est indispensable. Or, pour un système de données distribuées, le théorème "CAP" établit qu'il est impossible de satisfaire à plus de 2 des 3 contraintes suivantes : "Consistency" (intégrité des données), "Availability" (disponibilité du système) et "Partition tolerance" (résistance aux ruptures de connectivité entre les noeuds distribués).
La distinction entre SGBDR (distribué) et base NoSQL devient alors simple à comprendre : le premier mettent l'accent sur l'intégrité et la disponibilité, alors que la seconde va toujours privilégier la "Partition tolerance" et l'une des deux autres contraintes, sacrifiant généralement l'intégrité. Un des critères de choix est donc directement dérivé des contraintes de niveau de service attendu par les utilisateurs.
Un autre critère de choix est celui de la typologie de données : les SGBDR sont particulièrement adaptés à la gestion de données très structurées et uniformes alors que les bases NoSQL sont plus à l'aise dans la gestion de documents, de paires clés-valeurs (comme Google Datastore), d'objets ou de graphes de données.
On le voit, dans un SI bancaire, NoSQL ne remplacera pas beaucoup des SGBDR existants (peut-on accepter des pertes d'intégrité sur les données de la banque ?), même s'il existe de nombreux cas d'utilisation possibles. Il ne faut pas non plus oublier, dans la panoplie des solutions de gestion des données, les approches de types "grille de données" (sur le modèle MapReduce) qui consistent à répartir les traitements de données en multiples unités totalement autonomes, distribuées sur une multitude de systèmes. Elles constituent le meilleur choix pour traiter les problématiques de modélisation financière ou de data mining, par exemple.
Aucun commentaire:
Enregistrer un commentaire
Afin de lutter contre le spam, les commentaires ne sont ouverts qu'aux personnes identifiées et sont soumis à modération (je suis sincèrement désolé pour le désagrément causé…)