NoSQL : en Quête de Performances Extrêmes Alors que l audience du web croît sans cesse, les applications Internet à succès ont été confrontées aux mêmes problèmes de base de données : si les serveurs web peuvent être multipliés sans trop de difficultés («scale out»), ce n est pas le cas des bases de données relationnelles. Faire face à des charges de travail croissantes sur les bases de données demande d acquérir des machines plus puissantes («scale up») ou de constituer des grappes de serveurs (cluster). Les deux solutions engendrent une augmentation des coûts et de la complexité. Dans ce contexte, les développeurs ont réalisé que les bases de données relationnelles et les langages d interrogation pourraient être les goulets d étranglements du système. Les bases de données relationnelles et les langages d interrogation sont fondamentalement conçus pour des charges de travail stables et l extraction de données complexes, ce qui n est plus si fréquent dans les applications modernes. Pour celles-ci la capacité à gérer de grands ensembles de données tout en maintenant la rapidité et l extensibilité est plus importante. De ce constat est né le mouvement NoSQL, basé sur des systèmes innovants et Open Source de bases de données non relationnelles conçues pour répondre à des besoins spécifiques et assurer une extensibilité extrême sur de très grands ensembles de données.
Construit pour s adapter Les bases de données relationnelles et les langages d interrogation sont fondamentalement conçus pour des charges de travail stables et l extraction de données complexes, ce qui n est plus si fréquent dans les applications modernes. Pour celles-ci la capacité à gérer de grands ensembles de données tout en maintenant la rapidité et l extensibilité est plus importante. De ce constat est né le mouvement NoSQL, basé sur des systèmes innovants et Open Source de bases de données non relationnelles conçues pour répondre à des besoins spécifiques et assurer une extensibilité extrême sur de très grands ensembles de données. Le NoSQL a émergé en tant que mouvement au début de l année 2009 au cours d une rencontre organisée à San Francisco et dédiée aux systèmes de gestion de bases de données Open Source ne cherchant pas la conformité avec le modèle ACID (Atomicity, Consistency, Isolation, Durability). Il existe à l heure actuelle près de 100 projets NoSQL Open Source. De nombreux projets commencent par l implémentation d une structure de données spécifique pour résoudre un problème précis que les bases de données SQL ne traitent pas. Malgré ce point de départ commun, les bases de données NoSQL sont très variées, reflétant le fait que le terme NoSQL qualifie un ensemble de bases de données atypiques plutôt qu un groupe uniforme de solutions équivalentes. Quelles sont les principales catégories de bases de données NoSQL?
Adaptabilité extrême et abordable Il existe en réalité quatre grandes familles de modèles de données NoSQL : - Les key-value stores, qui génèrent des tables de hash géantes pour le stockage des données, très utiles pour les applications à forte audience diffusant constamment des données à leurs utilisateurs : Memcached et Redis, - Les clones de Bigtable, stockant les données sur de grands schémas multidimensionnels, adaptés au stockage, à l analyse et à l extraction de grandes quantités de données : HBase et Cassandra, - Les document stores, conçus pour informations semi-structurées : CouchDB et MongoDB, - Les bases de données Graphs, probablement le type le plus expérimental, conçues pour des données de type réseau : Neo4J. Selon Bruno Michel - Lead Developer du département R&D d af83 il a pris part à tous les projets liés au NoSQL menés par af83, «Une solution comme Cassandra est conçue pour répondre à un problème spécifique, qui est la montée en charge sur de très grands ensembles de données. Une autre comme MongoDB, pour le développement d applications Web en général, avec plus de flexibilité et de performances. Il existe encore d autres solutions conçues pour des types de données bien particuliers, telles que les données des réseaux sociaux ou de la géo localisation.» Quel est l impact de cette multiplicité d approches?
Le bon outil dans le bon contexte Bruno Michel «Les bénéfices des solutions NoSQL dépendent des cas d utilisation». Quand ils envisagent une solution NoSQL, les utilisateurs doivent choisir la base de données qui conviendra le mieux à leurs applications. Un choix pertinent amène de meilleures performances... ou une diminution des coûts. Olivier Desmoulin, fondateur d un réseau social géo localisé pour les gourmets, l a bien compris : «Nous servons jusqu à 60 000 clients par jour, en n utilisant qu un seul serveur low cost, qui héberge non seulement les applications Rails, mais également l ensemble de la base de données MongoDB. La capacité de MongoDB à gérer la géo localisation a également été d une grande aide. Pour une petite start-up comme la notre, le NoSQL était décisif pour assurer l extensibilité». Les exemples de ce type sont nombreux. Bruno Michel «MongoDB est utilisé par des sites très populaires tels que bit.ly, Foursquare ou Disqus, pour sa capacité à permettre des performances plus élevées en partitionnant la base». Malgré les aspects positifs, choisir une base de données NoSQL est ardu. Ori Pekelman, CTO d af83 avec une expérience approfondie sur les technologies NoSQL, fer de lance de l usage du NoSQL dans le cadre de nombreux projets pour les clients d af83, Il y a plus d une centaine de projets NoSQL existants : beaucoup de solutions sont vraiment nouvelles sur le marché, les projets arrivés à maturité ne datent que de deux ou trois ans, et la hiérarchie est sans cesse bousculée. Il y a aujourd hui de meilleures opportunités pour le client, mais le choix reste difficile». Bruno Michel «Au cours des trois dernières années, de nombreuses solutions prometteuses sont apparues, mais certaines d entre elles se sont avérées difficiles à maintenir, du fait d un développement trop lent ou de l instabilité des projets». Quelle pourrait être la méthode pour choisir la bonne solution et tirer parti de la puissance du NoSQL?
Nos Recommandations 1. Définissez d abord vos exigences fonctionnelles Les bases de données NoSQL ont été conçues pour réaliser des tâches bien précises : MongoDB a été prévu comme moteur de base de données pour plateformes d applications en cloud, Cassandra a été conçu pour gérer les recherches dans les messages reçus sur Facebook, Memcached pour améliorer le cache sur Livejournal. Tant que vous ne prévoyez pas de créer votre propre système de gestion de bases de données, il est conseillé de définir très précisément vos exigences fonctionnelles en premier, et ensuite de trouver la solution appropriée, qu elle soit NoSQL ou non. Le NoSQL devrait être utilisé quand l extensibilité est requise, et proscrit en cas d exécution de requêtes complexes. 2. Soyez réaliste avec vos besoins d extensibilité Les bases NoSQL ne conviennent pas à toutes les applications et tous les projets. Les usages caractéristiques sont les applications à forte audience, manipulant de très grandes quantités de données : Les bases de données NoSQL typiques vont d une douzaine de gigaoctet au pétaoctet. Très peu d applications ont ces caractéristiques. Mais les projets de moindre ampleur peuvent tirer partie des besoins comparativement moins importants des bases NoSQL, tout en restant vigilants sur leur capacité à maintenir ce choix : l expertise NoSQL est plus difficile à trouver. 3. Vérifiez attentivement les performances Ori Pekelman : Nous avons testé des douzaines de solutions, avec des performances multipliées par dix d une solution à une autre. Beaucoup de benchmarks sont disponibles en ligne, mais à cause de la diversité des méthodes employées, il est difficile de trouver des retours d expérience pertinents sur des aspects précis tels que les volumes de données traités, les ratios lecture / écriture ou la distribution des requêtes». 4. Prêtez attention à la maturité des projets Open Source liés aux solutions Bruno Michel : «Les solutions NoSQL commencent seulement à être matures et prêtes à la production, mais les utilisateurs doivent être prudents : les solutions et les projets ne sont pas égaux et évoluent très rapidement. Certaines solutions ont une grande visibilité sans jamais atteindre leurs prétentions». 5. Vérifiez la disponibilité des outils et documentation dédiés Bruno Michel : «Un problème qui peut être sous-estimé est le statut des outils et documentations liés à vos solutions. En cas de défaut votre projet devient risqué, et ce quel que soit le niveau de performance de la base de données.»
Célèbres utilisateurs de NoSQL Facebook, Foursquare, Google et Yahoo sont tous des utilisateurs de NoSQL. Une recherche rapide sur Google vous donnera un large aperçu de leurs tentatives, erreurs et réussites avec le NoSQL. NoSQL n est pas toujours la solution globale Dans certains cas, NoSQL sera la solution répondant à tous vos besoins en termes de données, mais le plus souvent, NoSQL ne répondra qu à une partie de ceux-ci et vous devrez mettre en place un ensemble de solutions, y compris NoSQL. Des fonctions atypiques et innovantes Selon les implémentations, les bases NoSQL incluent bien souvent des fonctions atypiques telles que la capacité à fonctionner en mémoire vive («NoDisk»), le partitionnement ou des optimisations orientées géo localisation. Pour en savoir plus Au sujet de Dynamo, la base de données haute performance d Amazon Au sujet de BigTable, le SGBD de Google SQL Databases Don t Scale Les présentations de la rencontre NoSQL de juin 2009 à San Francisco