Prêt pour le big data ? Peut-être pas !
Soyons honnêtes, nous aimons tous suivre les modes. Du moins nous aimerions en être capable. Pas mal d’entre vous se font probablement casser les oreilles par le big data et ses systèmes NoSQL.
Je suis beaucoup les tendances en terme de développement. Une chose qui me semble bien depuis les deux dernières années c’est que la communauté a pris un peu de maturité sur le débat SQL vs NoSQL. Les bases de données non SQL se sont étoffées et une bonne partie des ingénieurs ont enfin compris que ces systèmes ne sont pas le remplacement ultime à la base de donnée relationnelle que nous chérissons tous.
## Une histoire d’acidité
Qu’est-ce qu’ont en relation MySQL, Sybase, Oracle, SQLServer et PostgreSQL ?
ACID ! Atomicity, Consistency, Isolation, Durability !
Avec nos bases relationnelles, la donnée est le centre de l’univers. Pas notre application. Une base de données qui implémente ACID garantie la parfaite cohésion de nos données. C’est bien, c’est rassurant, confortable. Mais est-ce qu’une base de donnée « scale » bien une explosion de votre volumétrie ?
Vous pourrez invoquer toutes les solutions implémentées par les différents vendeurs de base de données, la réponse restera toujours non. La réplication de base de données fonctionne bien pour les lectures mais aucune ne tient la charge sur de fortes volumétries d’écriture.
ACID… À la poubelle !
Le système BigTable de Google par exemple part d’une approche totalement en contradiction totale à l’implémentation ACID. Quelle est donc cette approche ? Le Query Driven Design !
On modélise tout simplement nos tables pour répondre à une seule requête précise. On élimine donc toute jointure. Ce sont ces dernières qui mettent souvent à mal nos bases de données relationnelles. Cette contrainte nous force donc à nous débarrasser de nos pantoufles et de notre peignoir si confortable. En échange, on gagne un jeu de données qui peut facilement être distribué et répliqué à travers un cluster de machine plutôt qu’un unique serveur de base de données responsable de garantir l’intégrité totale de notre base. Les requêtes adressées à la base de données NoSQL ne deviennent que de simple descripteur d’index très précis orientant le système clusterisé directement vers les adresses où résident nos données. En résumé, une hashmap un peu élaborée et distribuée.
Une table par requête ? Vraiment ?
Premier constat, duplication de données. En effet, nos données seront dupliquées pour chaque type de requêtes. Pour faire un lien avec le monde relationnel, on peut vulgariser en disant que l’on va implémenter une vue SQL pour chaque action de requêtage possible sur le système. La différence réside dans le fait qu’il sera de la responsabilité de l’application de maintenir à jour ces vues. Il s’agit d’un travail additionnel mais qui aura le bienfait de pouvoir distribuer et répliquer parfaitement chaque ligne de nos tables associées à travers les 1000 nœuds de notre cluster.
Beaucoup à digérer
Dans mon prochain billet, je présenterai Cassandra qui est une implémentation Open Source de BigTable. J’expliquerai en détail comment ce moteur gère les écritures et les lectures à travers son cluster.
N’hésitez pas d’ici là à contribuer vos remarques, suggestions, sources .. 🙂