NoSQL : le choix difficile de la bonne base (et comment bien le faire)

Le nombre de bases NoSQL est important. Il est impératif de connaître leurs différences pour adopter la bonne technologie pour la bonne application.

Les bases de données NoSQL ont été conçues pour résoudre les problèmes de traitements de données en volume, multi-sources et multi-formats, dans des environnements Big Data. Toutefois aucun distinguo n’est fait en matière de volume ou diversité des données lorsqu’on parle de technologies NoSQL, perdant ainsi les DSI et les responsables de la donnée au milieu de nombreuses alternatives, difficiles à évaluer.

« Le marchĂ© est aujourd’hui rempli de bases de donnĂ©es NoSQL – je pense que nous sommes confrontĂ©s Ă  deux ou trois d’entre elles tous les jours Â», ironise Michael Simone, en charge de l’ingĂ©nierie de la plateforme CitiData de Citigroup, lors d’une prĂ©sentation rĂ©alisĂ©e Ă  l’occasion de la confĂ©rence MongoDB World.

En rĂ©alitĂ©, Citi a circonscrit volontairement les usages de la base MongoDB, comme alternative NoSQL aux bases relationnelles, Ă  un petit nombre d’applications, explique-t-il. Toutefois, son intervention a mis l’accent sur un point clĂ© : la difficultĂ© des entreprises Ă  cibler la technologie susceptible de rĂ©pondre au mieux aux problèmes et Ă  leur application.

Base de donnees

Remédier à cette difficulté commence par une bonne compréhension des différents types de bases de données NoSQL.

On peut classer celles-ci en quatre catĂ©gories : les bases de donnĂ©es orientĂ©es document, les bases clĂ©/valeur, les bases en colonnes et les bases orientĂ©es graphes.

Elles ont toutes un point commun : le support de modèles plus flexibles et dynamiques que ceux rĂ©alisĂ©s avec les bases de donnĂ©es relationnelles traditionnelles.

Mais, chaque type de base NoSQL correspond Ă  des usages spĂ©cifiques, prĂ©cise Nick Heudecker, analyste chez Gartner. Â« Vous devez vous demander quel type de donnĂ©es sont Ă  manipuler et comment les applications vont au final les utiliser. Â»

Les bases de donnĂ©es orientĂ©es document : une structure mixe

Les bases de données orientées document sont souvent utilisées dans les systèmes de gestion de contenus, ainsi que pour collecter et traiter des données à partir des applications mobiles ou Web à fort trafic pour les monitorer.

Comme l’indique leur nom, ces bases stockent  les donnĂ©es dans des structures identiques Ă  celles de documents,  parfois sans mĂŞme de schĂ©mas.

MongoDB, CouchDB Server, MarkLogic sont des bases orientées document.

Michael Simone explique par exemple que son utilisation de MongoDB est lié au fait que les développeurs de la société étaient à la recherche d’un moyen pour résoudre des problèmes de réplications de données, avec des structures différentes, pour une application financière en ligne. L’application a d’abord été déployée sur une base relationnelle, mais le traitement était lent et sujet à des erreurs.

« Il est ainsi devenu Ă©vident que nous ne pouvions faire face Ă  tous les formats de donnĂ©es fournis par les data scientists Â», se souvient-t-il.

Les schĂ©mas dynamiques de MongoDB se sont avĂ©rĂ©s bien adaptĂ©s Ă  cette application en Ă©volution permanente. « Nous avons dĂ©couvert que nous pouvions modĂ©liser tout ce qui nous arrivait Â», explique-t-il.  Et que cette rĂ©plication et cette modĂ©lisation pouvaient ĂŞtre rĂ©alisĂ© bien plus rapidement qu’avec l’approche relationnelle. Au final, les dĂ©veloppeurs ont conçu un modèle en prĂ©-production bâti sur MongoDB en seulement quatre mois.

Les bases clĂ©/valeur : la simplicitĂ©

Les bases de données clé/valeur, comme Aerospike, Redis et Riak, sont la forme la plus simple des bases NoSQL.

Elles associent des clés uniques à des valeurs dans des données, avec pour objectif de renforcer fortement les performances des applications reposant sur des jeux de données relativement simple.

« Les bases clĂ©/valeur sont très lĂ©gères Â», explique Joe Caserta, prĂ©sident de Caserta Concepts, une sociĂ©tĂ© de services techniques et de conseil. « Nous pouvons effectuer des recherches en quelques secondes. Â»

Autre exemple, Flywheel Software utilise Riak, une base dĂ©veloppĂ©e par l’éditeur Basho Technologies (qui vient de s'installer en France), pour motoriser une application mobile de commande de taxis sur smartphone. Cuyler Jones, qui a travaillĂ© en tant qu’architecte en chef chez Flywheel  â€“ il travaille dĂ©sormais pour une autre start-up - explique que la base peut ĂŞtre dimensionnĂ©e pour rĂ©pondre aux besoins en termes de traitement et de trafic. Ce qui, dans ce cas, est aussi important que la haute-disponibilitĂ© ainsi que le support de la cohĂ©rence des donnĂ©es de Riak, ajoute-t-il.

Les bases en colonnes

Les bases de données en colonnes conservent les données dans des tables qui disposent d’un très grand nombre de colonnes. Ce qui offre des hauts niveaux de performance et de dimensionnement lorsqu’il faut traiter (et parcourir) d’importants jeux de données.

Parmi les cas d’usages types, on retrouve la recherche sur Internet, les applications Web à grande échelle ainsi que les applications analytiques capables de traiter des péta-octets de données. Accumulo, Cassandra et HBase en sont des exemples.

Cette approche par colonnes a servi de fondation à une application portant sur l’identification des correspondances de l’ADN lancée en 2012 par Ancestry.com, explique Jeremy Pollack, responsable du développement dans la société, spécialisée dans la généalogie. Celle-ci s’est adossée à HBase et à Hadoop pour effectuer les calculs sur l’ADN qui permettent de rechercher les origines ethniques et géographiques d’un individu et d'identifier des proches jusqu’alors inconnus.

Pour obtenir le bon niveau de performance, il a fallu faire d’importants ajustements et configurer la base. Jeremy Pollack dĂ©crit cette procĂ©dure comme quelque chose de « bizarre Â». Pourquoi ? Parqu' « il y a un million de boutons Ă  tourner. Il faut vraiment aimer se salir les mains. Â»

Toutefois, cette technologie NoSQL a permis à Ancestry de comparer quelque 700.000 points de données et stocker des échantillons d’ADN pour identifier des correspondances.

Les bases orientées graphes pour suivre les relations entre données

Les bases de données en graphes, comme InfiniteGraph et Neo4j, stockent des éléments de données dans des structures "en graphes" et permettent de créer des associations entre eux pour, au final, servir de socle à des moteurs de recommandations ou des réseaux sociaux.

Base orientée Graph
Données organisées en Graph dans Neo4j

Par exemple, une technologie de graphes peut être utilisée pour identifier des relations entre différentes personnes via leurs centres d’intérêts, illustre Alex Trofymenko, en charge des questions technologiques chez HealthUnlocked, une société spécialisée dans l’information sur la santé.

Son Ă©quipe s’est adossĂ©e Ă  Neo4j, de Neo Technology, pour Ă©tablir ce type de corrĂ©lations. « Nous pouvons obtenir de nombreuses informations d’une base en graphes. Par exemple,  qu’un utilisateur est  très intĂ©ressĂ© Ă  la fois par le diabète et le sport. Â»

Des relations qui crééent de la valeur pour un site qui cherche à utiliser des millions de requêtes et mots-clés, à les associer aux bons termes sur la santé et à développer une plateforme qui permet aux utilisateurs de trouver la bonne information sur les traitements et les aides.

La fin du « dois-je aller chez Microsoft, Oracle ou IBM ? Â»

Avec ces multiples alternatives NoSQL, le processus de sĂ©lection d’une base est très diffèrent de celui de ces dernières annĂ©es. Une pĂ©riode surtout marquĂ©e, comme l’indique Joe Caserta, par la question : « dois-je aller chez Microsoft, Oracle ou IBM ? Â».

Si toutefois cette kyrielle d’options est une bonne chose pour les utilisateurs, le processus de sélection doit être appréhendé avec prudence afin d’éviter de s’orienter vers la mauvaise technologie.

OĂą trouver ces bases NoSQL

 

En collaboration avec Cyrille Chausson et Philippe Ducellier

Pour approfondir sur Big Data et Data lake