Web et bases de données : un mariage nécessaire pour faire face aux défis des données massives

Transcription

1 Web et bases de données : un mariage nécessaire pour faire face aux défis des données massives Module 7 : Familles de bases de données NoSQL Les bases de données relationnelles mises au point dans les années 70 dominent encore le marché au niveau mondial. Ce monopole de fait les transforme en «outil à tout faire», à la fois pour représenter les données et pour les manipuler. 1

2 C est une version du dicton suivant lequel, quand on n a qu un marteau, tout ressemble à un clou. 2

3 3

4 Le mouvement récent des bases NoSQL veut répondre aux limites du modèle relationnel pour certains types de problèmes (comme les réseaux sociaux) et pour les données massives, évolutives et réparties dans le monde entier que le web crée et manipule. Ce mouvement aurait donc probablement dû s appeler plutôt No Rel(ational), non relationnel, mais l appellation NoSQL, un peu trompeuse, plus frappante, s est imposée. 4

5 Soulignons- le, il n y a pas d un côté le modèle relationnel et de l autre côté un modèle concurrent NoSQL. Il y a en fait plusieurs familles de bases de données NoSQL. Elles correspondent à des manières distinctes de répondre à différentes limites de l approche relationnelle. [D6] L exemple des recommandations de Twitter nous a permis de comprendre la motivation d une première famille, les bases de données orientées graphes. Cette famille est adaptée au traitement des réseaux massifs. Des opérateurs particuliers permettent d effectuer efficacement des calculs sur de tels réseaux : filtrer des chemins dans un graphe en fonction de leur longueur, de la direction des liens, des propriétés des liens et des nœuds, etc. Les bases de données orientées colonnes (column stores). Les bases de données relationnelles, de manière transparente pour l utilisateur, représentent souvent une table en mémoire par la mise à la queue leu leu de ses lignes. Elles sont donc «orientées lignes» (c est le cas par exemple de MySQL utilisé entre autres par WordPress). Cette représentation est adaptée quand on s intéresse simultanément à plusieurs colonnes des lignes d une table. Quand on s intéresse avant tout à des colonnes de manière indépendante les unes des autres - par exemple pour connaître l âge moyen des utilisateurs, l orientation colonnes est plus efficace. On le voit, la manière privilégiée de traiter les données conduit à changer la manière de les stocker. Les bases de données orientées clé- valeur (key- value stores). A une clé, est associé un objet unique dont la structure est laissée souvent à la charge du développeur de l application. Les opérations sont minimales : créer une association entre un objet et une clé, lire un objet à partir de sa clé, modifier un objet à partir de sa clé, détruire l objet correspondant à une clé donnée. Cette simplicité permet une grande efficacité en lecture/écriture et le changement aisé d échelle, au prix de fonctionnalités soit limitées soit à développer de manière spécifique. C est le fonctionnement pour certains systèmes de sauvegarde de type Dropbox. Ils créent un identifiant unique pour chaque utilisateur. Ils déposent et organisent sous cette 5

6 clé un «tas de données» correspondant à l utilisateur. Ils assurent les modifications de ce tas de données. La base de données orientée clé- valeur borne son rôle à assurer la création et la modification de l association entre un identifiant unique et un «tas de données». Les bases de données orientées document (document stores). Notons d abord qu il ne s agit pas de textes. Par document, il faut entendre un objet contenant des sous- boîtes qui peuvent varier en nombre et en structure. Les documents au sein d une collection n ont pas forcément la même structure. Ces bases de données permettent d accéder à un document par son identifiant, mais aussi par les noms donnés aux sous- boîtes ou par les valeurs qu elles contiennent. ebay utilise MongoDB pour gérer une partie des métadonnées sur les produits vendus. La structure de ces métadonnées varie selon les types de produits. 6

7 Dans les avantages des bases de données NoSQL, mentionnons : Le faible coût relatif (projets open- source, utilisation gratuite ou peu coûteuse, services «dans les nuages» à coût progressif, comme pour Amazon S3) Les fortes performances liées à une bonne gestion de la répartition du stockage et des traitements : temps de réponse rapide et constant ; résistance à l augmentation du nombre de requêtes La résistance au changement d échelle (taille des données) La capacité à faire évoluer la représentation des données. Les bases de données relationnelles reposent sur des tables où toutes les lignes ont la même structure. Changer la structure d une base de données relationnelle est une opération lourde et complexe. Les éléments d une collection dans une base de données NoSQL n ont pas forcément la même structure. Celle- ci peut évoluer au fil du temps. C est un avantage dans le contexte du web massif, où les données recueillies voient souvent leurs facettes changer au fil du temps et où, d un «individu» à l autre, la base ne dispose pas forcément des mêmes informations. Les services comme Facebook ou Twitter n ont pas simplement multiplié dans des proportions étonnantes leurs utilisateurs, ils ont également changé et complexifié leurs représentations de ces utilisateurs et de leurs relations. Au registre des faiblesses ou des inconvénients des bases de données NoSQL La «jeunesse» des familles NoSQL et donc leur stabilité relative. Le modèle relationnel dispose d un langage de requête normalisé, SQL. Ce n est pas le cas des bases NoSQL. Certaines offrent des langages qui leur sont propres. D autres supposent un travail de programmation spécifique pour mettre en place les traitements souhaités. Comme plusieurs familles coexistent, sans langage partagé et sans méthodologies de modélisation stabilisées, les passages d une famille ou d une 7

8 réalisation à l autre ne sont pas immédiats. La migration des données et des traitements est à réaliser au cas par cas. La cohérence et l intégrité des données sont moins faciles à garantir. Les deux listes qui précèdent sont à très gros grain. C est pour chaque problème de stockage et de traitement, à condition qu il relève effectivement des bases NoSQL, qu il faut chercher la famille de bases de données la plus appropriée, en fonction des forces et faiblesses de cette famille et des produits effectivement utilisables. 8

9 Au total, les bases de données NoSQL réfutent l idée d un «outil à tout faire» que seraient les bases de données relationnelles. Il s agit donc au contraire de choisir le bon outil en fonction des données et des traitements concernés. 9

10 Le mouvement NoSQL est une contestation de la suprématie de l approche relationnelle, pas le refus d y avoir recours quand elle est pertinente : taille «raisonnable» des données, répartition limitée des données, cohérence et intégrité fortes des données. Les tenants des approches NoSQL remplacent souvent cette négation un peu forte par une affirmation plus tempérée : Not Only SQL. Ils signifient par là que pour disposer des stockages et des traitements les plus adaptés à un contexte donné, il peut être judicieux de combiner les approches relationnelles et non relationnelles. 10

11 Crédits [Réseau avec noeuds] By Calvinius [CC BY- SA 3.0 ( sa/3.0)], via Wikimedia Commons [Marteau] "Hammer2". Licensed under CC BY- SA 3.0 via Wikimedia Commons - mmer2.jpg [Vis] "Ruuvit" by Jannev from fi. Licensed under CC BY- SA 3.0 via Wikimedia Commons - [Clous] "2 SØM EXP 223" by 2010 by Tomasz Sienicki [user: tsca, mail: tomasz.sienicki at gmail.com] - Photograph by Tomasz Sienicki (Own work). Licensed under CC BY 3.0 via Wikimedia Commons - viewer/file:2_s%c3%98m_exp_223.jpg [Tournevis] "Driver tools". Licensed under CC BY- SA 3.0 via Wikimedia Commons - Driver_tools.jpg 11