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