Loading...Tout le monde a cru que l’initiative NoSQL (Not Only SQL) allait tuer les bases de données relationnelles (SGBDR/SQL). Les retours de terrain montrent qu’il n’en a rien été et que le SQL s’est même frayé un chemin dans ce monde (avec Apache Hive par exemple). Pour bien comprendre pourquoi ces systèmes différents cohabitent, il faut peler toute la couche de hype et revenir aux fondamentaux.
Le concept fondamental des bases de données est la transaction. La transaction permet de modifier les données de manière à éviter erreurs et fraudes. Deux transactions ne peuvent pas modifier une même donnée n’importe comment. Dans ce cas-là, il faut gérer un accès concurrent. Certains systèmes utilisent des verrous, d’autres recourent à un ordonnancement des transactions et à la gestion de versions multiples. Les transactions possèdent toutes les propriétés nécessaires pour obtenir des données qui soient durables, auditables et cohérentes [1].
Cependant, organiser l’accès concurrent des transactions à des données revient à gérer un état partagé (la donnée) entre plusieurs processus consommateurs (les transactions). La théorie dit alors que le passage à l’échelle par parallélisation est limité [2]. Entre d’autres termes, la donnée partagée devient le goulet d’étranglement de l’ensemble de la chaîne de traitement.
A l’inverse, il existe des systèmes où aucun état n’est partagé. Que ces états soient tout simplement absents (protocole HTTP) ou qu’ils soient répliqués (clusters de données NoSQL), il apparaît clairement que leurs performances sont supérieures à celles des systèmes basés sur les transactions [3].
Qu’on ne se méprenne pas. De tels systèmes ont un usage particulier pour lequel les propriétés permises par le modèle transactionnel ont moins d’importance que les performances globales. En revanche, pour tous les usages qui requièrent durabilité, auditabilité et cohérence, la transaction reste et restera le modèle incontournable.
Mais est-ce que les systèmes de gestion de transaction sont condamnés à être sous-performants ?
Non.
Kafka est un broker de messages distribués issu des travaux de R&D de LinkedIn et soutenu depuis 2011 par la fondation Apache. Il s’agit de l’un de ses projets phare. Que propose Apache Kafka ? De garantir un ordre immuable des messages immuables à la réception comme à l’émission. Et devinez quoi ? Pour y parvenir, Kafka se base sur un journal de transaction (log) distribué. Malgré la gestion d’un état partagé (le log), Kafka permet d’optimiser les performances en accélerant les communications entre la mémoire et le réseau par un usage subtil de la primitive Linux sendfile(). C’est un peu technique mais c’est bluffant [4].
Ceci est un exemple parmi d’autres. En revanche, ce qui reste inchangé, c’est que tous ces systèmes reposent sur un paradigme client-serveur et même si ce serveur est distribué sur plusieurs machines, même si les données sont répliquées, cela n’empêche pas une modification frauduleuse de la donnée de base si le journal de transaction est compromis. Car rien dans le modèle de transaction basé sur un journal ne permet de déterminer si une donnée a été falsifiée si l’enregistrement de transaction a disparu du serveur central.
C’est pour cette raison que des systèmes de données réellement sécurisés ont été considérés comme nécessaires pour assurer qu’une transaction réalisée et validée soit infalsifiable, que les changements d’états qu’elle a permis soient permanents mais qu’ils restent transparents pour éviter toute fraude d’un côté (serveur) comme de l’autre (client). Dans ces systèmes, une autorité de certification décide de la validité des changements apportés par les transactions. Le problème est que cette autorité reste centrale, possède un état partagé et, au final, devient un point individuel de défaillance. On a pensé résoudre le problème avec une autorité distribuée mais la distribution des traitements et des données ne changent rien au fait que, vu de l’extérieur, l’autorité de certification reste un point d’entrée unique dont l’infrastructure entière est assujettie à un propriétaire.
En réalité, une autorité de certification des transactions décentralisée et fonctionnant par consensus permettrait d’obtenir une base de données distribuée à large échelle garantissant l’auditabilité des transactions. Un rêve ? Une utopie ?
Pas vraiment puisque ce système existe et fait parler de lui pour plein d’autres raisons qui n’ont rien à voir avec la science informatique. Ce système est blockchain [5], l’algorithme qui garantit la sécurité de Bitcoin.
Blockchain est une structure de données gérée par un réseau P2P. Certains nœuds du réseau contiennent une copie du blockchain qui est certifiée par les pairs. Cette structure contient des blocs (d’où son nom) dont le contenu sont des transactions validées mais dont le détail n’est accessible qu’aux parties prenantes de la transaction. Cependant, si les détails de la transaction ne sont pas visibles pour tout le monde, l’algorithme qui permet de valider ces transactions et de les ajouter au blockchain assure qu’une fois qu’un bloc de transaction est ajouté à la chaîne, il ne peut plus être modifié. Cette propriété est rendu possible grâce à un chaînage cryptographique qui requiert des parties prenantes de la transaction de résoudre un problème ardu de factorisation pour prouver qu’elles ont le droit de prétendre à un emplacement de la blockchain.
La lecture séquentielle des adresses de chaînage des blocs dans la blockchain assure que chaque transaction est bien comptée en débit et en crédit qu’aucun BitCoin n’a été dupliqué.
Si ces propriétés sont très désirables pour une monnaie, elles le sont aussi pour des données partagées sensibles qui doivent non seulement être protégées d’une consultation non autorisée mais aussi contre toute tentative de manipulation malveillante suite à la compromission d’un nœud du réseau [6]. Simplement dit, blockchain ne permet ni de voir les données sur lesquelles a porté une transaction ni de savoir quelles furent les modifications mais assure que cette transaction est valide.
Cependant, l’adoption de blockchain comme pattern de conception pour des systèmes sécurisés et décentralisés reste faible. La technologie elle-même n’en est qu’à la phase de faisabilité même si l’étude de son implémentation dans BitCoin n’a, pour l’instant, pas laissé entrevoir de faille. En revanche, le potentiel est énorme et permettrait sans doute de résoudre les problèmes de vie privé et de droit d’auteur liés aux mégadonnées partagées.
1. GRAY, Jim, et al. The transaction concept: Virtues and limitations. In : VLDB. 1981. p. 144-154.
2. BERNSTEIN, Arthur J. Analysis of programs for parallel processing. Electronic Computers, IEEE Transactions on, 1966, no 5, p. 757-763.
3. HAN, Jing, HAIHONG, E., LE, Guan, et al. Survey on NoSQL database. In : Pervasive computing and applications (ICPCA), 2011 6th international conference on. IEEE, 2011. p. 363-366.
4. KREPS, Jay, NARKHEDE, Neha, RAO, Jun, et al. Kafka: A distributed messaging system for log processing. In : Proceedings of the NetDB. 2011. p. 1-7.
5. NAKAMOTO, Satoshi. Bitcoin: A peer-to-peer electronic cash system. Consulted, 2008, vol. 1, no 2012, p. 28.
6. KOPSTEIN, Joshua. The Mission to Decentralize the Internet. The New Yorker, 2013, lu depuis http://nyr.kr/1qVbK5m.
