Introduction aux bases de données NoSQL

Transcription

1 Introduction aux bases de données NoSQL Khaled Tannir Montréal - 23 Juillet 2015

2 Qui suis-je? Khaled TANNIR Big Data Architect Lead 20 ans d expérience Auteur / Author Relecteur Technique / Technical reviewer 09 Avril 2015 Introduction aux base de données NoSQL

3 Sommaire Les besoins en gestion des données Introduction aux systèmes NoSQL Les types de base de données NoSQL NoSQL Atouts et Faiblesses

4 Les besoins en gestion de données

5 Un premier constat Le volume des données augmente considérablement Les données sont souvent de nature hétérogène Cette volumétrie nécessite une distribution des données Difficulté d intégration dans les SGDBR existant Complexité ascendante de la mise à l échelle

6 Systèmes distribués : Etat des lieux Les ordinateurs sont reliés par un réseau local (LAN) Une couche logicielle permettant la coordination de ces ensembles d ordinateurs Communiquant généralement par envoi de messages Fonctionnant sur du matériel facilement remplaçable en cas de panne

7 Systèmes distribués : Gestion des données Pour appliquer les traitements sur les grands volumes de données : La distribution des traitements Les traitements sont distribués sur un nombre important de machines puis les données sont envoyées à ces endroits puis on enchaine les exécutions distantes La distribution des données On distribue les données sur un nombre important de serveurs puis on «pousse» les traitements vers ces serveurs

8 Limites des SGDBR Le volume des données augmente considérablement Les données sont souvent de nature hétérogène Cette volumétrie nécessite une distribution des données Difficulté d intégration dans les SGDBR existant Complexité ascendante de la mise à l échelle

9 Limites dans un contexte distribué (1) Pour la plupart des SGBD relationnels, les données dʼune BD liées entre elles sont placées sur le même noeud du serveur Lorsque le nombre de liens devient important, il est alors de plus en plus difficile de placer les données sur des noeuds différents.

10 Limites dans un contexte distribué (2) Les SGBD Relationnels sont généralement transactionnels, la gestion de transactions respectant les contraintes ACID (Atomicity, Consistency, Isolation, Durability) Cette gestion a un coût considérable : La distribution des traitements de données entre différents serveurs rend difficile le maintien des contraintes ACID à l'échelle du système distribué difficultés à maintenir des performances correctes

11 Le théorème de CAP (Brewer, 2000) C : tous les nœuds du système voient exactement les mêmes données au même moment A : la perte de nœuds n'empêche pas les survivants de continuer à fonctionner correctement, les données restent accessibles P : le système étant partitionné, aucune panne moins importante qu'une coupure totale du réseau ne doit l'empêcher de répondre correctement

12 Théorème de CAP expliqué Pourquoi est-il impossible de satisfaire les 3 propriétés CAP en même temps? Soit un système distribué. On est entrain de modifier une donnée sur le nœud N1 et d essayer de la lire à partir du nœud N2 N2 peut retourner la dernière bonne valeur dont il dispose, ce qui viole la Consistance N2 attend que la nouvelle valeur lui parvienne. Comme c est un système distribué, les chances d un échec de transmission sont assez importantes, ce qui provoquera une attente infinie de N2. D où une violation de la Disponibilité Si on veut satisfaire à la fois la consistance et la disponibilité, le système de stockage ne doit pas être partitionné. D où violation de la Tolérance au partitionnement.

13 Il faut trouver une solution Un nouveau système permettant : Une meilleure mise à l échelle (scalabilité) dans des contextes fortement distribués Permettre une gestion simplifiée et meilleure de données hétérogènes Création de systèmes complémentaires aux SGDBR adressant leurs limites sans pour autant les remplacer

14 Introduction aux systèmes NoSQL

15 Le NoSQL à la rescousse Bases de données NoSQL (Not Only SQL) Bases de données non-relationnelles et largement distribuées Permet une analyse et une organisation rapides et ad-hoc des données de très grands volumes et de types de données disparates Répond à l augmentation exponentielle des données

16 Atouts et Caractéristiques Atouts Évolutivité Disponibilité Tolérance aux pannes Caractéristiques Modèle de données sans schéma Architecture distribuée Utilisation de langages qui sont autre que du SQL

17 Présentation des bases NoSQL Adoptent une représentation non relationnelle des données Ne remplacent pas les BD relationnelles mais sont une alternative Apportent une plus grande performance dans le contexte de grande volumétrie de données Utilisent une très forte distribution des données et des traitements associés Font un compromis sur le caractère «ACID» des SGBDR pour plus de scalabilité horizontale et d évolutivité

18 Caractéristiques des bases NoSQL (1) Pas de schéma pour les données ou schéma dynamique Accèptent les données de structures complexes ou imbriquées Partitionnement horizontal des données (sharding) sur plusieurs noeuds (serveurs) généralement par utilisation d'algorithmes tel que «MapReduce» Réplication des données sur plusieurs noeuds

19 Caractéristiques des bases NoSQL (2) Privilégient la Disponibilité à la Cohérence (théorème de CAP) AP (Disponible + Résistant au partitionnement) plutôt que CP (Cohérent + Résistant au partitionnement) Généralement n intègrent pas de gestion de transactions Mode d'utilisation : peu d'écritures, beaucoup de lectures

20 Les types de base de données NoSQL

21 Panorama des bases NoSQL

22 Types des BDDs NoSQL Stocker les informations de la façon la mieux adaptée à leur représentation : «Clé-valeur / Key-value» : chaque objet est identifié par une clé unique constituant la seule manière de le requêter «Colonne / Column» : permet de disposer d'un très grand nb de valeurs sur une même ligne, de stocker des relations «one-to-many», d'effectuer des requêtes par clé (adaptés au stockage de listes : messages, posts, commentaires,...) «Document» : gestion de collections de documents, composés chacun de champs et de valeurs associées, valeurs pouvant être requêtées (adaptées au stockage de profils utilisateur) «Graphe» : pour gérer des relations multiples entre les objets (adaptés au données issues de réseaux sociaux, )

23 1- Type orienté «Clé / Valeur» (1) Chaque objet est identifié par une clé. L un des types les plus simples, sorte de Hashmap distribuée Conçues pour sauvegarder les données sans définir de schéma, Toutes les données sont sous forme de clef/valeur La valeur peut être une chaîne de caractères, un objet sérialisé, blob La donnée est opaque au système: il n est pas possible d y accéder sans passer par la clef L absence de typage a un impact sur le requêtage: toute l intelligence portée avant par les requêtes devra être portée par l applicatif qui interroge la BD Opérations se résumant surtout aux PUT, GET et DELETE Fournir un accès rapide aux informations

24 1- Type orienté «Clé / Valeur» (2) Exemple : DynamoDB (Amazon), Azure Table Storage (ATS), Redis, BerkeleyDB, Voldemort (LinkedIn)

25 «Clé / Valeur» Usage principal Dépôt de données avec besoins de requêtage très simples Système de stockage de cache ou d'information de sessions distribuées Persister des données Les profils, préférences d'utilisateur Les données de panier d'achat Les données de capteur Les logs de données

26 «Clé / Valeur» Forces et Faiblesses Forces : modèle de données simple bonne mise à l'échelle horizontale pour les lectures et écritures : évolutivité (scalable) disponibilité pas de maintenances requises lors d'ajout/suppression de colonnes Faiblesses : modèle de données TROP simple : pauvre pour les données complexes interrogation seulement sur clé déporte une grande partie de la complexité de l'application sur la couche application elle-même

27 2- Type orienté «Colonne» (1) Les données sont stockées par colonne, non par ligne On peut facilement ajouter des colonnes aux tables, par contre l'insertion d'une ligne est plus coûteuse Quand les données d'une colonne se ressemblent, on peut facilement compresser la colonne Modèle proche d'une table dans un SGBDR mais ici le nombre de colonnes : est dynamique peut varier d'un enregistrement à un autre ce qui évite de retrouver des colonnes ayant des valeurs NULL

28 2- Type orienté «Colonne» (2) Exemple : Hbase (Hadoop), Cassandra (Facebook, Twitter), BigTable (Google)

29 «Colonne» Usage principal Dépôt de données avec besoins de requêtage très simples Système de stockage de cache ou d'information de sessions distribuées Persister des données Les profils, préférences d'utilisateur Les données de panier d'achat Les données de capteur Les logs de données

30 «Colonne» Forces et Faiblesses Forces : Modèle de données supportant des données semi-structurées Naturellement indexé (colonnes) Bonne mise à l'échelle à l'horizontale Utilisation de MapReduce pour le scaling horizontal, on peut voir les résultats de requêtes en temps réel Faiblesses : A éviter pour des données interconnectés (comme la distance ou calculs de la trajectoire) A éviter pour les lectures de données complexes Exige de la maintenance - lors de l'ajout / suppression de colonnes et leur regroupements

31 Dans un SGDBR, cela impliquerait plusieurs jointures 3- Type orienté «Document» (1) Étendent le paradigme clef/valeur, avec des «documents» plus complexes à la place des données simples, et une clef unique pour chacun d eux Un «Document» est de type JSON ou XML Chaque Document est un objet, contient un ou plusieurs champs, et chaque champs contient une valeur typée (string, date, binary ou array) Permettent de stocker, extraire et gérer les informations orientées documents (données semi-structurées) Avantage : pouvoir récupérer, via une seule clef, un ensemble d informations structurées de manière hiérarchique

32 3- Type orienté «Document» (2) Exemple : Mongo DB (SourceForge), Couch DB (Apache), RavenDB (.Net)

33 «Document» Usage principal Enregistrement d'événements Systèmes de gestion de contenu Web analytique ou analytique temps-réel Catalogue de produits Systèmes d'exploitation

34 «Document» Forces et Faiblesses Forces : Modèle de données simple mais puissant (expression de structures imbriquées) Bonne mise à l'échelle (surtout si le sharding est pris en charge) Pas de maintenance de la BD requise pour ajouter/supprimer des «colonnes» Forte expressivité de requêtage (requêtes assez complexes sur des structures Faiblesses : Inadaptée pour les données interconnectées Modèle de requête limitée à des clés (et indexes) Peut alors être lent pour les grandes requêtes (avec MapReduce)

35 4- Type orienté «Graphe» (1) Basées sur les théories des graphes S appuie sur les notions de noeuds, de relations et des propriétés qui leur sont rattachées Conçues pour les données dont les relations sont représentées comme graphes, et ayant des éléments interconnectés, avec un nombre indéterminé de relations entre elles Adapté aux traitements des données des réseaux sociaux Utilisent un moteur de stockage similaire à une base documentaire pour stocker les noeuds Utilisent un mécanisme de description dʼarcs (relations entre les noeuds), arcs orientés et avec propriétés (nom, date,...)

36 4- Type orienté «Graphe» (2) Exemple : Neo4J et InfiniteGraph, OrientDB

37 «Graphe» Usage principal Moteurs de recommandation Semantic Web Social computing Données géo-spatiales Généalogie Catalogue des produits Sciences de la Vie et calcul scientifique (bio-informatique, ) Données liées, données hiérarchiques Services de routage, d'expédition et de géolocalisation Services financiers : chaîne de financement, dépendances, gestion des risques, détection des fraudes,

38 «Graphe» Forces et Faiblesses Forces : Modèle de données puissant Rapide pour les données liées, bien plus rapide que SGBDR Modèles d'interrogation bien établis et performants Faiblesses : Fragmentation (sharding) : Même si elles peuvent évoluer assez bien

39 NoSQL Atouts et Faiblesses

40 NoSQL - Atouts Adapté au Big Data (grand volume, données structurées, semi-structurées ou non-structurées, données stockées et gérées à plusieurs endroits) Disponibilité continue des données Utilisent une architecture hautement distribuée Indépendance de l emplacement (Possibilité de consulter et modifier une BD sans savoir où est-ce que ces opérations ont réellement lieu) Modèles de données flexibles

41 NoSQL - Faiblesses Choix de NoSQL, en opposition aux bases de données relationnelles, conduits par les contraintes du marché et les besoins techniques Il n existe pas de langage de requêtage unifié (tel que SQL) Requêtage moins expressif que SQL Moins mature que les SGDBR (10aine d années vs 40+) Moins d outils que les SGDBR

42 SQL est de retour - NewSQL

43 Conclusion Utilisez le bon modèle de données pour le bon problème

44 Merci pour votre attention!