Canal-U

(No SQL)

Depuis des années, SQL (Structured Query Language) est le langage standard normalisé pour interroger et mettre à jour des bases de données relationnelles. Il s’est imposé jusque dans les systèmes pour construire des sites Web, avec PHP-MySQL. Mais les exigences d’applications « extrêmes » ont conduit à remettre en question sa suprématie. On retrouve des demandes difficiles à satisfaire avec des systèmes relationnels dans deux grandes classes d’applications :

• Applications transactionnelles : on peut avoir des millions de transactions à traiter par seconde, et ce vingt-quatre heures sur vingt-quatre. C’est le cas par exemple pour des sites de E-commerce comme Amazon.
• Applications décisionnelles : on doit réaliser des calculs, notamment statistiques, sur des téraoctets de données. C’est le cas par exemple pour des sites de recommandation comme Netflix.

Enfin, certaines applications, comme le trading haute-fréquence (ou trading algorithmique) marient les contraintes du transactionnel (volume important de transactions, besoin évident de rapidité) et du décisionnel (calculs complexes à mettre en œuvre avant de prendre la décision d’acheter ou vendre).

Quand on utilise les bons vieux systèmes relationnels sur de telles applications, ça rame… Quand on essaie de comprendre pourquoi, on réalise que les systèmes relationnels paient un fort overhead pour leur universalité, c’est-à-dire le fait qu’ils sont destinés à traiter tout type d’application, avec des données très diverses dans leur représentation, dans leur structure et leur volumétrie. Les difficultés rencontrées pour les applications mentionnées ci-dessus ont conduit à considérer des systèmes de gestion de données spécialisés qui passent à l’échelle des grands systèmes transactionnels ou décisionnels, mais en abandonnant cette universalité.

Les systèmes relationnels permettent par exemple à plusieurs utilisateurs de partager des données de manière contrôlée grâce à un système de verrous ; la pose de verrou sur une donnée ou sur un morceau d’index particulier par une application garantit qu’aucune autre application ne va toucher cette information. Ce système de verrous est essentiel pour assurer des propriétés fondamentales comme la cohérence d’une base de données et de son évolution, mais il est aussi complexe et coûteux en temps. On peut améliorer les performances en le remplaçant par un protocole de partage moins sûr mais plus performant. Dans le cadre des systèmes distribués, un théorème proposé par Eric Brewer vient encourager un tel abandon. Le Théorème CAP explique qu’il est impossible de répondre aux trois exigences suivantes à la fois :

•  
  • Cohérence (consistency) : la valeur d’une donnée à un instant donné est la même pour chaque participant au système.
  • Disponibilité (availability) : une donnée doit toujours être accessible même en cas de panne.
  • Tolérance au partionnement : le système doit continuer à fonctionner même quand il est fragmenté par des problèmes de réseaux.

Dans des situations très distribuées, comme c’est le cas pour des applications qui travaillent à l’échelle duWeb, on peut choisir d’abandonner les exigences strictes en terme de cohérence (résumées par les propriétés ACID des transactions) au profit de la fluidité d’une exécution transactionnelle massive.

Une autre particularité fréquente des systèmes NoSQL est de s’appuyer sur des modèles de données plus simples que le modèle relationnel, des langages plus simples que SQL. Par exemple, plutôt que de considérer des tableaux à plusieurs colonnes, on va se limiter à associer des valeurs à des clés (comme dans un dictionnaire). On va aussi tirer un trait sur des opérations complexes comme la « jointure ». Quand on fait tout ça, on aboutit à des systèmes d’une grande pauvreté en terme de puissance de représentation et d’interrogation. C’est de là que vient le nom « No SQL » : ce n’est pas qu’on est « contre » SQL, mais plutôt qu’on n’est « même pas » SQL et qu'on en est fier ! Certains préfèrent comprendre le sigle comme « Not only SQL ». Doit-on alors comprendre qu’on est au delà de SQL ou que SQL n’est pas la solution à tout ? Dans le fourre-tout du NoSQL, on peut d'ailleurs trouver des propositions de modèles très spécialisés qui sur certains aspects sont plus riches que le modèle relationnel (par exemple pour représenter des graphes), avec des langages, eux aussi très spécialisés, qui proposent des opérations qui n’existent pas en SQL.

Mais nous nous intéressons surtout ici aux systèmes moins universels mais avec les performances extrêmes demandées. Ce n’est pas par miracle que ces systèmes arrivent à ces performances étonnantes : ils sont plus rapides parce qu'ils font moins de choses. C'est comme ça qu'on arrive à des passages à l’échelle de PétaOctets de données, de millions de transactions simultanées. C'est aussi parce qu'ils s'appuient typiquement sur des architectures massivement parallèles. La simplification des modèles trouve d’ailleurs là sa principalemotivation : simplifier pour pouvoir paralléliser et donc passer à l’échelle d’infrastructures s’appuyant sur des milliers, voire des millions de machines. Parfois, le concept même de machine devient obsolète, et ce sont des (réseaux de) cartes graphiques (processeurs intrinsèquement massivement parallèles, mais aux propriétés de calculs bien spécifiques) qui sont utilisés. Le NoSQL s’est donc imposé dans le monde du Big Data et dans celui des applications Web démesurées.

Si les systèmes NoSQL connaissent de grands succès, il faut bien être conscient de ce tout qu'on perd. Ce qu’un système de gestion de données ne fait pas, c’est à l’application de le prendre en charge. On ne dispose pas des langages de haut niveau si pratiques pour déléguer la gestion des données à des systèmes évolués. Avec un système NoSQL qui ne sait faire (certes, efficacement) que des put() et des get(), il faut écrire du code relativement bas niveau et complexe pour la moindre fonctionnalité que l’on souhaite introduire, le moindre contrôle que l’on veut garantir, la moindre mise à jour, etc. Tout cela représente potentiellement des pertes énormes de productivité, de fiabilité, et même d’efficacité (les systèmes relationnels, quoiqu’on en dise, savent faire des choix d’exécution intelligents, performants et adaptés au contexte).

L’engouement actuel pour ces systèmes mal connus, mal compris, non normalisés, dont on peut penser parfois à tort qu’ils représentent un progrès alors qu’ils ne sont que des solutions alternatives pour certaines niches, risque de conduire à des désillusions. Dans la plupart des cas, il reste préférable de recourir à un système relationnel pour ses langages normalisés, sa richesse de fonctionnalité, sa robustesse et même ses performances (mais oui). Réservons au NoSQL les applications avec tellement de données ou tellement de transactions que la solution relationnelle est exclue.

Pour aller plus loin :

•  
  •  
    • Nombreux exemples de systèmes NoSQL dans la page Wikipédia
      
    • NoSQL, W3 resource
      

Gestion de données en pair-à-pair

Dans un réseau pair-à-pair, chaque machine est à la fois un serveur et un client. On parle de P2P pour peer-to-peer en anglais (pair-à-pair ou égal-à-égal). Le but est d’utiliser la distribution, comme dans les systèmes de bases de données distribuées. Une grande différence est que toutes les machines sont traitées sur le même rang; il n’y a pas de « maitre » ou d'« esclave ». Chaque machine est appelée un nœud et l’ensemble forme un réseau en pair-à-pair.

Le grand principe du P2P est la mise en commun et le partage de ressources. Avant de nous concentrer sur le partage de données, nous allons considérer d’autres types de partage, les partages de communication et de puissance de calcul.

Communications. On peut mettre en commun l’utilisation des réseaux de communication. Les premières versions de Skype supportaient des télécommunications sur IP en s’appuyant sur du P2P. On peut aussi considérer des réseaux mobiles dits « ad hoc ». Dans de tels réseaux sans fil, une communication passe d’un nœud à l’autre (d'un téléphone mobile à l'autre) depuis la source émettrice pour arriver à destination , sans passer par des points d’accès et des infrastructures spécialisées, comme c’est le cas pour le Wifi ou le GSM.

Calcul. On peut aussi partager des puissances de calcul. L’idée de départ, c’est que la puissance de calcul des ordinateurs est souvent inutilisée. Pensez au nombre d’heures chaque jour où votre ordinateur personnel au travail ou chez vous (si vous en avez un) ne fait rien. Quand vous ne vous en servez pas, un système P2P peut confier à votre ordinateur des calculs. En utilisant des milliers de machines inactives, on peut ainsi fabriquer une formidable puissance de calcul collaboratif. Par exemple, le projet Seti@home a utilisé cette approche pour analyser le spectre magnétique de signaux de l’espace et rechercher (sans succès) des traces d'intelligence extra-terrestres.

Données et information. Les systèmes P2P sont particulièrement adaptés à la diffusion et au partage de données et de l’information. Avec la réplication, ils facilitent la disponibilité, en offrant des moyens de pallier les pannes ou les inaccessibilités de serveurs (dues par exemple à une censure). Une des applications les plus populaires est le partage de fichiers, avec des protocoles comme BitTorrent. Si ce protocole est souvent utilisé pour obtenir des films en contournant le droit d’auteur, il est également appliqué dans un cadre cette fois tout à fait légal pour la gestion des mises à jour logicielles, que ce soit de systèmes d’exploitation comme Linux, ou de jeux vidéo comme World of Warcraft.

Comment ça marche ? Un fichier (par exemple un patch de mise à jour Linux) est proposé sur un réseau. Un pair va le télécharger pour pouvoir effectuer cette mise à jour (comme client). Il va en garder une copie, et pourra donc ensuite le fournir (agissant comme serveur) quand d’autres pairs vont réclamer cette mise à jour.

Arrêtons-nous un instant sur ce qui se passe pour une mise à jour de sécurité importante, ce qui va nous permettre de dégager un avantage essentiel du parallélisme. Dans une approche classique client-serveur, ce fichier est sur un serveur. Si le serveur tombe en panne, le fichier n’est plus accessible. S’il y a trop de demandes de téléchargement, le serveur pourrait être saturé. En P2P, plus le fichier est populaire, plus il est disponible sur de nombreux pairs. Même si certains d’entre eux sont temporairement inaccessibles, il en restera toujours pour proposer ce fichier. De plus, il est probable qu’un nœud « proche » rendra la communication super efficace. Si plusieurs nœuds proches de vous disposent du fichier, vous pourrez même en télécharger une partie chez chacun. Le parallélisme en action !

Les réseaux P2P permettent d’augmenter les performances et la disponibilité des données. C’est au prix d’une plus grande complexité. Une difficulté est évidemment de coordonner le travail de machines autonomes, qui peuvent rejoindre le réseau ou le quitter de manière imprévisible, à des rythmes élevés. Une autre est de retrouver une information qui est stockée sur un des pairs du réseau. On distingue plusieurs approches :

• Le serveur d’index. On utilise un serveur qui gère un index des ressources disponibles. C’est évidemment la méthode la plus simple. Cependant, ce serveur devient un point de faiblesse. Par exemple, s’il est en panne, tout le réseau s’effondre.
• Les réseaux non-structurés. On diffuse la demande d’information massivement à des voisins, qui la transmettent à des voisins, jusqu’à tomber sur quelqu’un qui a l’information ou qui sait où la trouver. Evidemment, une difficulté est de choisir à quels voisins transmettre la demande ; une autre est d'éviter de saturer le réseau en envoyant chaque demande à tous les participants du réseau.
• Les réseaux structurés. On utilise une structure de données distribuée pour rechercher l’information. C’est par exemple une table de hachage distribuée (DHT pour distributed hash table) comme Chord ou Pastry. Une telle structure permet de retrouver à partir d’une clé (par exemple, le nom d’un fichier), le contenu correspondant (le fichier lui-même), et ce en utilisant un nombre de messages logarithmique dans le nombre de pairs actifs.

Calculer sur des données massives

in : Interstices, https://interstices.info/jcms/p_83082/calculer-sur-des-donnees-massives