Durant la première journée de Devoxx, deux sessions étaient dédiées au NoSQL : une présentation (trop) courte de 30 minutes durant la journée suivie d’un BOF sous forme de discussion d’une heure le soir. Ce sera l’unique incursion de cette technologie durant la semaine. On peut d’ailleurs regretter que ce sujet qui monte en puissance actuellement n’y ait pas été plus présent.
Au cours de cette journée plusieurs intervenants se sont exprimés sur le NoSQL.
Steven Noels (photo ci-contre) est à la tête d’OuterThought, l’éditeur du CMS Daisy. Il souhaite faire évoluer son produit vers un CMS s’appuyant sur une technologie NoSQL pour persister ses données. Steven Noels faisait donc partager ici le fruit de leurs études sur ce sujet.
Lars George, quant à lui, est intervenu en fin de journée pour faire partager son expérience en tant qu’utilisateur de HBase depuis 2 ans.
Concepts et principes du NoSQL
On regroupe derrière le NoSQL l’ensemble des technologies de persistance qui se distinguent par une absence de requête et par un relâchement des caractéristiques ACID propres aux RDBMS.
Le NoSQL est un sujet vaste, et le temps imparti étant limité à Devoxx, seuls les principes liés à HBase ont été abordés. Ainsi les bases de données orientées graphes (telles que Neo4j) ou orientées documents (telles que CouchDB) n’ont pas été présentées.
De ACID à BASE
Les propriétés ACID sont propres aux bases de données relationnelles. Elles sont :
- Atomicité : l’ensemble des opérations d’une transaction est persisté ou toutes sont abandonnées pour revenir à l’état initial ;
- Consistance : la base de données conserve un état consistant avant comme après l’exécution d’une transaction ;
- Isolation : les autres opérations ne peuvent pas voir l’état intermédiaire des données modifiées par une transaction tant que celle-ci n’est pas terminée ;
- Durabilité : assure qu’une fois que l’utilisateur a été notifié de la conclusion correcte d’une transaction, l’ensemble des modifications est persisté et ne sera pas annulé.
L’univers du NoSQL introduit l’acronyme BASE correspondant aux propriétés suivantes :
- Basically Available : essentiellement disponible ;
- Soft state : état variable dans le temps ;
- Eventually consistant : éventuellement consistant, une donnée répliquée peut, à un instant donné, ne pas avoir la même version sur les différents nœuds.
Pour aller plus loin :
- BASE: An Acid Alternative par Dan Pritchett, technical fellow chez eBay (inscription gratuite requise) ;
- Eventually Consistent – Revisited par Werner Vogels, CTO d’Amazon.
Le théorème CAP
Le théorème CAP permet de faire le lien entre ces deux notions. En effet, il spécifie qu’une base de données ne peut offrir que deux des trois propriétés suivantes :
- Consistance (les données sont toujours correctes) ;
- Disponibilité (il est toujours possible de lire ou d’écrire des données) ;
- Tolérance au partitionnement.
Les bases de données relationnelles classiques adhèrent aux deux premières propriétés, tandis que les bases de données NoSQL se concentrent sur les deux dernières.
Bases de données orientées colonnes
On oppose l’orientation en colonnes à l’orientation en ligne utilisée dans les bases de données relationnelles.
La différence se fait dans la technique de sérialisation utilisée. L’orientation en colonnes entrainera une sérialisation des colonnes les unes après les autres, alors que l’orientation en ligne écrit chaque entité les unes après les autres.
L’intérêt des bases de données orientées colonnes est alors un éventuel gain de performances lors d’opérations d’agrégation sur de nombreuses lignes et peu de colonnes. L’ajout d’une nouvelle colonne à l’ensemble des lignes est également une opération peu coûteuse grâce à la structure de données mise en place.
HBase vs Cassandra
HBase est une base de données distribuée orientée colonnes fonctionnant au dessus d’Apache Hadoop. Le contenu des colonnes de HBase peut servir d’entrée et de sortie pour pour les données utilisées et créées par une tâche MapReduce Hadoop. HBase est une implémentation Open Source du modèle BigTable publié par Google.
Cassandra est pour sa part un projet indépendant offert à la Fondation Apache par Facebook qui l’utilise en interne pour son stockage de données distribué. Il s’agit d’un hybride entre BigTable et Dynamo d’Amazon.
HBase était pénalisé par des latences légèrement plus élevées que Cassandra jusque récemment : la récente version 0.20.0 du projet a amélioré la situation. Dès lors l’équipe d’OuterThought s’est orienté vers HBase qui constituait un choix plus rassurant de par sa communauté plus active et l’utilisation du très populaire Hadoop.
Fonctionnement de HBase
Dans HBase les tables sont donc stockées en orientation par colonne tel qu’expliqué précédemment. Chaque table est constituée d’un ensemble de familles de colonnes (regroupements logiques de colonnes) devant être spécifiées à sa création. Chaque famille peut alors recevoir un nombre arbitraire de colonnes pouvant être ajoutées après la création de la table, à n’importe quel moment.
Contrairement aux RDBMS classiques, il est très facilement envisageable de mettre en œuvre des tables de plusieurs millions de colonnes et plusieurs milliards de lignes sans que cela n’ait d’impact significatif sur les performances : il est simplement nécessaire d’augmenter en conséquence le nombre d’instances.
Les lignes des tables sont partitionnées en plusieurs regions. Lors de la création d’une table, une seule region est créée, elle est ensuite automatiquement divisée en sous-parties lorsque sa taille atteint un seuil limite. Chaque region est placée sur un region server. Le contenu des region servers est indexé dans un serveur master qui aiguille les clients vers le nœud adéquat. Le transfert de données entre les clients et les region servers se fait par une connexion directe n’incluant pas le master.
Enfin, ZooKeeper est utilisé pour définir les instances Hadoop faisant partie du cluster HBase.
Le schéma suivant présente cette architecture :
HBase en production – retour d’expérience
Dans la soirée, Lars George a apporté un retour d’expérience de grande valeur. Il utilise HBase depuis 2 ans en production sur une base de données de plusieurs dizaines de Tera Octets.
Configuration matérielle utilisée
Il utilise pour cela un cluster de 20 machines, secondé par un autre de même taille utilisé en spare. On associe en général l’utilisation de HBase et de MapReduce de manière générale avec des configurations matérielles de type commodity hardware (matériel courant non spécifique aux serveurs). Lars George utilise pour sa part des machines octo cœurs, afin d’assurer une puissance de calcul importante sur ses tâches distribuées tout en conservant un nombre de machines raisonnable.
Le réseau n’est en général pas un goulot d’étranglement sauf lors des backups. Ainsi nombre de ses machines se contente encore d’adaptateurs réseau 100 Mbps.
Maintenance et administration
HBase est récent et continue de se développer. On pouvait donc craindre de réelles difficultés pour la gestion quotidienne d’une telle base de données au quotidien. Sur cette question le retour d’expérience de Lars George se montre rassurant même si la technologie reste récente et les outils dédiés peu nombreux :
- L’administration d’une base de données HBase au quotidien est plus proche de celle d’un middleware Java que de celle d’une base de données relationnelle classique. Nul besoin d’un DBA spécialisé donc.
- JMX peut être utilisé pour le monitoring de la base de données.
- Le tuning de performance se fait avant tout au niveau de la JVM, l’environnement Hadoop / HBase présentant une configuration bien plus simple que celle offerte par Oracle ou MySQL par exemple.
- Les jobs MapReduce sont un outil puissant pour exécuter des traitements batch sur l’ensemble des données de la base, quelque soit sa taille.
- Une base de données HBase est susceptible de solliciter la JVM de manière bien plus intensive qu’un serveur Tomcat à pleine charge, particulièrement lorsque des jobs MapReduce sont en cours d’exécution.
Enfin les backups sont ici effectués par copie incrémentale (rendue possible grâce aux timestamps sur les cellules HBase) d’un cluster à l’autre. Comme mentionné précédemment cette solution sature le lien réseau entre les deux clusters mais constitue un choix raisonnable lorsque les volumes de données manipulés sont trop importants pour être sauvegardés sur un support de stockage unique ou même pour une seule machine.
Performances
Les performances obtenues sur cette plate-forme sont très satisfaisantes puisqu’il est question de quelques millisecondes pour chaque lecture / écriture. Les performances restent stables avec l’augmentation du volume de données. L’ajout de machines supplémentaires permet de supporter facilement l’augmentation du volume de requêtes.
Pour profiter de telles performances, les tâches de tuning sont principalement réduites à la JVM.
Mise en œuvre
La plupart des pratiques habituelles doivent être repensées lors de la mise en oeuvre d’une telle base de données.
Ainsi le modèle de données doit être dé-normalisé afin de respecter la logique orientée colonnes de HBase. Ceci mène à la création de données dupliquées et donc à une augmentation globale du volume stocké. Ce point n’est en fait pas gênant avec ce type de bases de données puisque leurs performances ne souffrent pas d’une telle augmentation. Le coût de la dé-normalisation se résumera donc principalement à un stockage sur disque plus important ce qui s’avèrera négligeable dans le cas de l’utilisation de disques durs bon marché (SATA).
Les cellules des tables HBase sont des byte[] bruts qui recevront aussi bien des objets Java sérialisés (avec Avro par exemple) que des fichiers. HBase ne proposant pas de langage de requêtes comme SQL, les recherches complexes devront se faire par l’intermédiaire du développement spécifique d’une tâche MapReduce.
Pour les recherches multi-critères ou full-text, Lucene peut également être un compagnon idéal d’une telle base de données. Lars George utilise ainsi un index Lucene de 200 Go permettant les recherches rapides sur l’ensemble de ses données. Pour la manipulation de tels indexes, on notera l’existence des initiatives Katta et Distributed Lucene permettant de diviser l’index en plusieurs fragments répartis sur plusieurs machines.
HBase offre un client Java ainsi que des clients REST et Thrift. Le client Java doit bien entendu être préféré pour les intégrations avec des applications Java afin de bénéficier d’une sérialisation optimisée.
Enfin, on notera qu’il est très délicat de trouver des développeurs compétents sur ce type de technologie du fait de son émergence. Une stratégie d’étude initiale et de formation est donc à prévoir.
Etat de la communauté
On le disait précédemment, HBase dispose d’une communauté très active en comparaison à Cassandra. Hadoop est un projet Apache qui connaît une ascension très rapide, et qui bénéficie de l’implication de Yahoo!.
Ce constat positif doit toutefois être contrasté :
- Les communautés Hadoop et HBase sont séparées, et constituent deux domaines de compétences distincts ;
- Peu de systèmes HBase de grandes tailles sont actuellement en production, il est donc parfois difficile d’obtenir de l’aide sur des problèmes très particuliers.
Conclusion
Bien qu’encore en version 0.20.x à l’heure actuelle, on comprend que HBase a bien dépassé le stade expérimental même si l’on ne peut pour le moment pas raisonnablement parler de maturité.
Dès lors sa capacité à manipuler des volumes très importants de données et à recevoir un fort trafic tout en conservant des performances stables pourra dors et déjà séduire certains projets devant résoudre de telles problématiques.
