Est-ce que NoSQL et Big Data vont tuer le DBA?

Vous souvenez-vous du bon vieux temps où les développeurs et les DBA se disputaient à propos de qui et de quoi était en train de tuer les bases de données relationnelles? « C’est ton foutu SQL », « Tu as oublié de créer un index », « Tu ne sais pas ce qu’est un index »… et ainsi de suite. Vous souvenez-vous quand le DBA parlait parfois et nous confiait humblement la manière de rendre les exécutions SQL plus rapides? Eh bien mes amis, ces jours seront bientôt derrière nous avec l’adoption des technologies NoSQL. Ou est-ce que je me trompe? Est-ce que le DBA va faire un retour fracassant?

Si vous jetez un œil sur la dernière décennie, il n’y a aucun doute que presque toutes les entreprises d’aujourd’hui sont connectées ou dirigées directement en ligne. A vrai dire, je ne me souviens pas de la dernière fois où Mme AppMan et moi-même sommes allés à la banque, avons écrit une lettre ou rendu un film emprunté. La moitié de notre vie se passe en ligne, et cela ne va pas s’arrêter de sitôt désormais car Mme AppMan a un nouveau MacBook pour effectuer ses achats. IDC et EMC ont récemment publié un rapport qui affirme que cette année le 70% de l’univers digital sera généré par des utilisateurs depuis leur domicile, leur lie de travail et ou l’entre-deux. Au total, cela nous amène à 880 millions de gigabytes de données qui seront créées cette année. Toutes ces données doivent aller quelque part, et il appartient aux applications de faire des requêtes et de rendre ces données accessibles aux utilisateurs où qu’ils soient dans le monde. La disponibilité et la performance des données n’ont jamais été aussi importantes.

Auparavant, je passais beaucoup de jours et de nuits à travailler avec des clients pour les aider à faire évoluer leurs applications à travers les grandeurs et décadences de l’Internet. Il est correct de dire que la plupart des problèmes de performance que j’ai réglés étaient liés à l’accès aux données entre le serveur de l’application et la base de données relationnelle. La verbosité et la complexité d’APIs comme JDBC prouvaient que les développeurs faisaient beaucoup d’erreurs. Pour aggraver ce problème, peu de développeurs savaient comment exploiter complètement les caractéristiques de bases de données comme Oracle. Admettre des connaissances en PL/SQL était comme si Luke Skywalker passait du côté obscur. Les développeurs et les DBAs s’entendaient rarement, largement parce que la plupart des DBAs disaient qu’ils gagnaient plus d’argent qu’une contraction de Bill Gates. Des frameworks comme Spring faisait du bon travail de maîtrise d’API en aidant les développeurs à écrire moins de code pour faire moins d’erreur. Vous aviez ensuite une série de frameworks Object Relational Mapping (ORM) qui fournissaient une base de données virtuelle pour que les développeurs puissent  tracer le chemin de leurs objets d’application vers les tables de la base de données de manière automatique et transparente. Alors que les ORMs aidaient les développeurs avec une persistance des données, les APIs trichaient souvent avec les bases de données et en retour les DBA (non pas qu’aucun développeur ne puisse se voir offrir une quelconque sympathie) quand elles étaient mal implémentées. La persistance des données et leur accès était et est toujours un facteur-clé contribuant à la performance de l’application.

Le problème aujourd’hui est que les bases de données relationnelles rendent difficiles l’évolutivité par les institutions de leurs applications afin de pouvoir faire face à une forte concurrence d’utilisateurs et aux volumes de transactions. Elles imposent le fait d’entreposer les données dans des schémas rigides de classement figé qui forcent les interactions et donc les demandes de données deviennent de plus en plus complexes, et lentes. Un autre problème est qu’il est très difficile de faire évoluer horizontalement – et si cela se passe, c’est à un très grand coût de cycle de vie en termes de licences de logiciel et de hardware. Faire évoluer vos applications avec une technologie de base de données relationnelle n’est pas un hobby bon marché dans une perspective de coût et de latence. C’est pourquoi autant de vendeurs comme Amazon, Google et Facebook ont créé leur propre technologie en open source : pour que les communautés les plus larges puissent influencer et faire évoluer les travaux qu’elles ont initiés.

C’est pourquoi autant d’institutions aujourd’hui recherchent des technologies NoSQL pour éviter le tournage en rond, le coût et les limitations d’évolutivité de la grosse base de données relationnelle. Vous avez certainement remarqué que les médias sociaux comme Twitter ou Facebook font beaucoup de publicité sur la manière dont ils gèrent le fait que plusieurs centaines de millions d’utilisateurs font des milliards des transactions chaque jour générant des pétabytes de données. Des technologies comme Hadoops, Big Tables et Cassandra’s deviennent « sexy ». La mémoire et le disque sont aussi onéreux que des chips aujourd’hui, ce qui veut dire que beaucoup de développeurs peuvent stocker, exécuter et faire plus qu’auparavant avec des données sur mémoire et disque. Et comme vous le savez, la mémoire est rapide et le disque est lent. Plus vous rapprochez les données d’une logique de business, plus une application va répondre rapidement et vous serez moins dépendant de choses comme le disque I/O et la latence – qui limitent les temps de réponse de la transaction et le débit. Le seul problème, c’est que la mémoire n’est pas permanente ou illimitée; à un certain point, vous avez besoin d’écrire les données sur le disque.

Les institutions devraient aussi prendre en compte Cloud Computing – une plateforme qui peut attribuer des ressources IT aux applications selon leurs besoins, en respectant leur timing, tout en offrant de la flexibilité. La mauvaise nouvelle est que les bases de données relationnelles ne sont pas vraiment flexibles car leurs architectures permettent difficilement -et onéreusement- d’évoluer. Elles font également grandement confiance au disque, qui dans le cloud reste un problème car il sera partagé et visualisé. Vous êtes fou si vous faites fonctionner Oracle sur un VM avec un disque bon marché. Ce serait comme demander à Usain Bolt de courir un 100 mètres sur un pied et de gagner. Pour mettre le choses en perspectives, la latence lecture/écriture d’une base de données NoSQL comme Cassandra peut être 30 fois plus rapide que celle d’une base de donnée équivalente MySQL lorsque les deux bases de données sont chargées avec plus de 50 GB de données. 30 fois plus vite constitue une différence énorme, ce qui veut dire que vous pouvez réviser 30 fois plus d’utilisateurs et des transactions.

Comment pouvez-vous faire fructifier NoSQL et rendre votre application plus flexible? Vous pouvez commencer par déplacer vos données non-critiques  d’une base de données relationnelle vers des choses comme des technologies NoSQL ou des magasins de données distribués – qui sont plus rapides, moins chers, hautement disponible, flexibles, et cependant plus faciles à faire évoluer et à gérer. Toutes les données ne doivent pas absolument se trouver dans une base de données relationnelle même s’il est pratique de toutes les garder dans un seul endroit. Vous souhaitez structurer, stocker et faire appel à vos données d’une manière qui fait sens au regard de vos objectifs. Si votre application comporte des données qui changent rarement (par exemple des catalogues de produits, du contenu de pages) et si vous voulez des temps de lecture très rapide, vous souhaitez peut-être stocker cela dans le cache distribué. Si votre application a des données qui changent beaucoup, qui n’ont pas de mission critique et qui demandent une latence faible, alors vous souhaitez peut-être lire et écrire depuis une base de données NoSQL et sauver la base de données relationnelle pour les moments où vous aurez besoin d’atomicité de transaction. Vous pouvez faire évoluer vos caches distribués et/ou vos bases de données NoSQL en passant pour qu’ils déchargent la base de données relationnelle de la plupart des chargements. Moins de voyages vous ferez vers la base de données relationnelle, plus vous améliorerez la concurrence de votre application et le débit car la plupart de vos données seront lues depuis la mémoire.

Cependant, toutes les business transactions n’ont pas la même priorité ou la même importance. Une transaction de recherche d’utilisateur peut être importante, mais si elle échoue à tout moment ce n’est pas la fin du monde. Cependant, si un paiement d’utilisateur par carte de crédit échoue, alors cela aura un impact direct sur le business. Egalement, déplacer vers des architectures d’application basées sur NoSQl n’est pas rapide et facile. Les développeurs doivent acquérir de nouvelles compétences et doivent maîtriser des prérequis non-fonctionnels pour implémenter les modèles et technologies assurant l’accessibilité aux données, ainsi que leur disponibilité et leur consistance, pour chaque business transaction effectuée par un utilisateur.

Alors, est-ce que le DBA va mourir? J’ai bien peur que non. Vous voyez, chaque nouvelle ou ancienne technologie a ses avantages et ses inconvénients. La vérité est que NoSQL prend le parti de « Pas seulement SQL » plutôt que celui de « Pas de SQL ». La base de données relationnelle ne disparaîtra pas prochainement. Les institutions ont toujours besoin d’atomicité pour leurs business transactions de mission critique. Quand un client effectue un paiement par carte de crédit ou lorsqu’un trader effectue un échange, ces business transactions doivent être effectuées en temps réel sur le disque. L’état de la transaction et de ses données a besoin d’être consistant, quel que soit le lieu où les données sont updatées et le lieu depuis lequel elles sont manipulées. Les solutions NoSQL sont si rapides, flexibles, évolutives et disponibles parce qu’elles sont à la base des magasins de données distribuées à l’intérieur de la mémoire qui fonctionne sur différents nœuds et serveurs physiques – cela veut dire que si un nœud faillit, il y en a plein d’autres pour prendre sa place. C’est pourquoi lorsqu’une transaction utilise un seul nœud, c’est incroyablement rapide mais ces données doivent être dupliquées sur tous les nœuds sur le réseau NoSQL pour que les données soient vraiment consistantes.

La consistance du Lire/Ecrire est toujours quelque chose que les solution NoSQL doivent conquérir; elles sacrifient ACID pour les performances, la flexibilité et la haute-disponibilité du lire/écrire. Même si NoSQL permet aux applications d’évoluer avec de la haute concurrence de transaction et des volumes de données, il y a toujours un besoin de travailler en parallèle sur les bases de données relationnelles pour assurer une consistance de données.

Maintenant que Java appartient à Oracle, il sera intéressant de voir comment ils vont adopter la communauté open source et les technologies NoSQL.

App Man.