Chapitre 1: Introduction aux Bases de données NoSQL PDF

# Introduction aux Big Data ## Chapitre 1: Introduction aux Bases de données NoSQL **Pr. ZAIDOUNI Dounia** - Filière: ICCN, Semestre 3, INE2 - Institut National des Postes et Télécommunications (INPT) - 22 Novembre 2024 ## Présentation du syllabus du cours - Chapitre 1: Introduction aux BD NoSQL...

# Introduction aux Big Data ## Chapitre 1: Introduction aux Bases de données NoSQL **Pr. ZAIDOUNI Dounia** - Filière: ICCN, Semestre 3, INE2 - Institut National des Postes et Télécommunications (INPT) - 22 Novembre 2024 ## Présentation du syllabus du cours - Chapitre 1: Introduction aux BD NoSQL - SGBD Relationnels transactionnels (Définition, propriétés ACID, limites, ...) - Propriété BASE et théorème du CAP (ou théorème de Brewer) - Présentation des BD NoSQL - Typologie des BD NoSQL - Chapitre 2: MongoDB - Chapitre 3: Introduction aux Big Data - Chapitre 4: Apache Hadoop et Apache Spark ## Outline 1. Contexte 2. SGBD Relationnels transactionnels 3. Propriété BASE et Théorème du CAP (ou théorème de Brewer) 4. Présentation des BD NoSQL 5. Typologie des BD NoSQL ## Plan 1. Contexte 2. SGBD Relationnels transactionnels - Définition de transaction et d'intégrité référentiel - Les propriétés ACID - Limites des SGBD Relationnels transactionnels 3. Propriété BASE et Théorème du CAP (ou théorème de Brewer) 4. Présentation des BD NoSQL 5. Typologie des BD NoSQL - BD NoSQL orientées 'agrégats' - BD NoSQL orientées 'graphes' ## Contexte - Plusieurs sources de données: - Les informations générées par les grandes plateformes et applications Web (Google, Facebook, Twitter, LinkedIn, Amazon, ...) comme: - Emails, images, vidéos, audios, transactions d'achat, logs, etc. - Les informations récupérées par des réseaux de capteurs pour gérer des Smart cities ou des Smart Building, comme: - Climat, trafic, données de géolocalisation, pression, température, etc. - Un volume considérable de données à gérer par ces applications nécessitant une distribution des données et leur traitement sur de nombreux serveurs. - Manipulation de données associées à des d'objets complexes, non structurées et hétérogènes et qui ne nécessite pas de déclarer au préalable l'ensemble des champs représentant l'objet. ## Problèmes - Limites de l'utilisation des SGBD traditionnels (relationnels et transactionnels) basés sur SQL. - Nécessité de nouvelles approches de stockage et de gestion des données permettant une meilleure scalabilité dans des contextes fortement distribués. ## Plan 1. Contexte 2. SGBD Relationnels transactionnels - Définition de transaction et d'intégrité référentiel - Les propriétés ACID - Limites des SGBD Relationnels transactionnels 3. Propriété BASE et Théorème du CAP (ou théorème de Brewer) 4. Présentation des BD NoSQL 5. Typologie des BD NoSQL - BD NoSQL orientées 'agrégats' - BD NoSQL orientées 'graphes' ## SGBD Relationnels transactionnels - Les SGBD Relationnels offrent un système de jointure entre les tables permettant de construire des requêtes complexes impliquant plusieurs entités. - Ils sont généralement transactionnels: - Ils réalisent des transactions respectant les propriétés ACID (Atomicité, Cohérence, Isolation et Durabilité). - Les SGBD Relationnels offrent aussi un système d'intégrité référentielle permettant d'assurer la cohérence du contenu de la base de données. ## Définition de transaction - **C'est une opération sur les données telle qu'une réservation, achat, paiement, transfert d'argent, etc.** - **Elle est mise en œuvre via une suite de tâches qui font passer la base de données d'un état A (antérieur à la transaction) à un état B postérieur.** - **Exemple:** Lors d'une opération informatique de transfert d'argent d'un compte bancaire sur un autre compte bancaire: - Il y a une tâche de retrait d'argent sur le compte source et une de dépôt sur le compte cible. - Le programme qui effectue cette transaction va s'assurer que les deux opérations peuvent être effectuées sans erreur, et dans ce cas, la modification deviendra alors effective sur les deux comptes. Si ce n'est pas le cas l'opération est annulée. Les deux comptes gardent leurs valeurs initiales. - **On garantit ainsi la cohérence des données entre les deux comptes.** ## Définition d'intégrité référentielle - **C'est une situation dans laquelle pour chaque information d'une table A qui fait référence à une information d'une table B, l'information référencée existe dans la table B.** - **Une clé étrangère, dans une base de données relationnelle, est une contrainte qui garantit l'intégrité référentielle entre deux tables.** - **L'intégrité référentielle est un gage de cohérence du contenu de la base de données.** - **Exemple:** On définira qu'un livre est écrit par un auteur. Une contrainte d'intégrité référentielle: - interdira l'effacement d'un auteur, tant que dans la base de données il existera au moins un livre se référant à cet auteur. - interdira également d'ajouter un livre si l'auteur n'est pas préalablement inscrit dans la base de données. ## Les propriétés ACID - **C'est un ensemble de propriétés qui garantissent qu'une transaction informatique est exécutée de façon fiable.** - Atomicité - Cohérence - Isolation - Durabilité ## Atomicité - **Il assure qu'une transaction se fait au complet ou pas du tout:** - Si une partie d'une transaction ne peut être faite, il faut effacer toute trace de la transaction et remettre les données dans l'état où elles étaient avant la transaction. - **Il n'y a jamais de transactions à moitié terminées.** - **L'atomicité doit être respectée dans toutes situations, comme une panne d'électricité, une défaillance de l'ordinateur, ou une panne d'un disque magnétique.** ## Cohérence - **Elle assure que chaque transaction amènera le système d'un état valide à un autre état valide.** - **Tout changement à la base de données doit être valide selon toutes les règles fonctionnelles définies.** - **Exemples de règles fonctionnelles:** - Contrainte d'intégrité référentiel. - Contraintes d'intégrité: - Ils sont des clauses permettant de contraindre la modification de tables afin que les données saisies dans la base soient conformes aux données attendues. Par exemple en SQL: - Le mot clé 'NOT NULL' permet de forcer la saisie d'un champ. - La clause 'UNIQUE' permet de vérifier que la valeur saisie pour un champ n'existe pas déjà dans la table. ## Isolation - **Toute transaction doit s'exécuter comme si elle était la seule sur le système. Aucune dépendance entre les transactions.** - **La propriété d'isolation assure que l'exécution simultanée de transactions produit le même état que celui qui serait obtenu par l'exécution en série des transactions. Chaque transaction doit s'exécuter en isolation totale.** - **La transaction va travailler dans un mode isolé où elle seule peut voir les données qu'elle est en train de modifier, cela en attente d'un nouveau point de synchronisation (checkpoint).** - Grâce au **Checkpoint** et au **Rollbacks-Recovery**, le système garantit la tolérance aux pannes et la visibilité sur les données antérieures. - **Un Rollback-Recovery se produit dans les systèmes de base de données quand une transaction 'T1' provoque un échec et qu'une récupération doit être effectuée.** ## Durabilité - **Lorsque la transaction est achevée, le système est dans un état stable durable:** - soit à l'issue d'une modification transactionnelle réussie, - soit à l'issue d'un échec qui se solde par le retour à l'état stable antérieur. - **La durabilité assure que lorsqu'une transaction est confirmée, elle doit être enregistrés de façon permanente même à la suite d'une panne d'électricité, d'une panne de l'ordinateur ou d'un autre problème.** ## Limites des SGBD Relationnels transactionnels - **Les SGBDR sont principalement conçus pour évoluer verticalement (ajouter plus de ressources matérielles à un seul serveur). Ils peinent à évoluer horizontalement. Dans des environnements avec de grandes quantités de données (Teraoctets et Zettaoctets) ou avec un nombre élevé de requêtes simultanées, la scalabilité verticale atteint vite ses limites.** - **Les SGBDR ne sont pas bien optimisés pour gérer des types de données comme les documents, les graphiques ou les données hiérarchiques. Par exemple, manipuler des structures JSON complexes ou traverser des graphes sociaux (comme les réseaux d'amis) peut être inefficace dans un SGBDR.** - **Les SGBDR ne sont pas conçus pour gérer efficacement des volumes massifs de données non structurées ou semi-structurées générées à grande vitesse comme les systèmes de streaming en temps réel.** - **Si on doit distribuer les traitements de données entre différents serveurs alors il est coûteux et difficile de maintenir les contraintes 'ACID' à l'échelle du système distribué entier tout en maintenant des performances correctes.** - Si le nombre de liens est important, il est de plus en plus difficile de placer les données sur des nœuds différents. - Difficulté à mettre à l'échelle les opérations d'écriture telles que les insertions et les mises à jour, elles peuvent devenir un goulot d'étranglement lorsque la taille des données augmente. - **Les SGBDR sont basés sur un schéma fixe défini à l'avance. Cela peut rendre difficile la gestion de types de données non structurées ou semi-structurées. Toute modification du schéma (ajouter ou supprimer une colonne, par ex.) peut entraîner des interruptions, des temps d'arrêt ou des efforts de migration importants, surtout avec de grandes bases.** - **La plupart des SGBD adaptés aux systèmes distribués relâchent les contraintes ACID, ou même ne proposent pas de gestion de transactions** ## Stratégies possibles des traitements sur des données - Dans un environnement distribué, il y a deux stratégies possibles pour pouvoir appliquer des traitements sur des données : - **Par distribution des traitements:** on distribue ces traitements sur un nombre de machines important afin d'absorber des charges très importantes et on envoie les données aux endroits appropriés, et on enchaîne les exécutions distantes (scénario type Workflow implémentable avec des web services). - **Par distribution des données:** on distribue les données sur un nombre important de serveurs afin de stocker de très grands volumes de données, et on pousse les programmes vers ces serveurs (plus efficace de transférer un petit programme sur le réseau plutôt qu'un grand volume de données. Ex: algorithme MapReduce). ## Plan 1. Contexte 2. SGBD Relationnels transactionnels - Définition de transaction et d'intégrité référentiel - Les propriétés ACID - Limites des SGBD Relationnels transactionnels 3. Propriété BASE et Théorème du CAP (ou théorème de Brewer) 4. Présentation des BD NoSQL 5. Typologie des BD NoSQL - BD NoSQL orientées 'agrégats' - BD NoSQL orientées 'graphes' ## Propriété BASE - **A l'opposé des propriétés 'ACID', les propriétés 'BASE' caractérisent les SGBD issus du cloud computing et des systèmes distribués.** - Ces SGBD privilégient la haute disponibilité des données distribuées, la rapidité, la simplicité au détriment de la cohérence et de l'exactitude de la réponse. - **Les propriétés 'BASE' sont:** - Basically Available, Soft state et Eventual consistency. ## Propriété BASE - **Basically Available:** Le système garantit la disponibilité des données et il y aura une réponse à toute demande. Mais cette réponse pourrait être un "échec" pour obtenir les données demandées, on peut avoir des indisponibilités sur de courtes périodes). - **Soft state:** L'état de la BD n'est pas garanti à un instant donné (les mises à jour ne sont pas immédiates). L'état du système peut changer avec le temps, des changements peuvent survenir en raison de la "cohérence éventuelle“, ainsi l'état du système est toujours "souple". - **Eventual consistency:** La cohérence des données à un instant donné n'est pas primordiale mais assurée plus tard (en utilisant différents mécanismes par exemple le 'verrouillage optimiste'). Au fur et à mesure que des données sont ajoutées au système, l'état est progressivement répliqué sur les autres nœuds. ## Propriété 'CAP' - 3 propriétés fondamentales pour les systèmes distribués: - **Consistency**: toutes les nœuds dans un systeme distribué renvoie la même valeur. - **Availability**: Chaque nœud non défaillant renvoie une réponse pour toutes les demandes de lecture et d'écriture dans un délai raisonnable. - **Partitionment tolerance**: Le système continue de fonctionner et maintient sa cohérence malgré le partitionnement dans le système distribué. ## Propriété 'CAP' - **Consistency (Consistance ou Cohérance), Availability (Disponibilité) et Partitionment tolerance (Tolérance au partitionnement).** ## Théorème du CAP (ou théorème de Brewer) - **Theorem:** Dans un système distribué, il est impossible d'obtenir ces 3 propriétés en même temps, il faut en choisir 2 parmi les 3. - **Les SGBDR sont AC (Available and Consistent).** - **Les SGBD "NoSQL" sont CP (Consistent and Partitionment tolerant) ou AP (Available and Partitionment tolerant).** ## Plan 1. Contexte 2. SGBD Relationnels transactionnels - Définition de transaction et d'intégrité référentiel - Les propriétés ACID - Limites des SGBD Relationnels transactionnels 3. Propriété BASE et Théorème du CAP (ou théorème de Brewer) 4. Présentation des BD NoSQL 5. Typologie des BD NoSQL - BD NoSQL orientées 'agrégats' - BD NoSQL orientées 'graphes' ## Définition du NoSQL (1/2) - **Ce n'est pas (comme son nom le laisse supposer) No SQL (pas de SQL) mais plutot NoSQL "Not only SQL" (pas seulement SQL ).** - **NoSQL désigne une famille de SGBD qui s'écarte du paradigme classique des bases relationnelles.** - **La raison principale de l'émergence et de l'adoption des SGBD NoSQL serait le développement des clusters de serveurs et la nécessité de posséder des SGBD adaptées à ce modèle d'infrastructure distribuées.** - **Cette architecture distribuée fonctionnant avec des agrégats répartis sur différents serveurs permettant des accès et modifications concurrentes mais imposant également de remettre en cause de nombreux fondements de l'architecture SGBD relationnelle traditionnelle, notamment les propriétés 'ACID'.** ## Définition du NoSQL (2/2) - **Le terme NoSQL a été proposé par 'Carl Strozzi' en 1998.** - **Les SGBD NoSQL ont vu le jour à la fin des années 2000 avec le développement de grandes entreprises internet (Google, Amazon, Ebay...) brassant des quantités énormes de données.** - **Les SGBD NoSQL n'interdisent pas le langage de requête structurée SQL.** - Certains systèmes NoSQL sont intégralement non relationnels, - D'autres se contentent d'éviter certaines fonctions relationnelles, telles que les schémas de tables fixes et les opérations de jointure. ## Principaux atouts des SGBD NoSQL - **Les principaux atouts des SGBD NoSQL sont:** - Évolutivité, - Disponibilité, - Tolérance aux pannes. ## Caractéristiques générales des SGBD NoSQL - **Pas forcément de schéma normalisé (schema-less) ou schéma dynamique:** - Les SGBD NoSQL peuvent ignorer cette étape de définition de shéma et stocker des données hétérogènes au fur et à mesure de leur alimentation. Cela permet une grande flexibilité dans l'application. - **Pas forcément de jointure mais multiplication des requêtes.** - **Structures de données complexes, imbriquées et hétérogènes.** - **Architecture distribué avec un partitionnement horizontal des données sur plusieurs serveurs généralement par utilisation d'algorithmes "MapReduce“.** - **Réplication des données sur plusieurs noeuds.** - **Généralement, pas de gestion de transactions.** - Mode d'utilisation : peu d'écritures, beaucoup de lectures. Par exemple: SGBD d'annuaires. - **Transactions pas forcément 'ACID' mais plutôt 'BASE'.** ## Les premiers précurseurs du modèle NoSQL - **Pour répondre aux limites des SGBDR, les entreprises ont commencé à développer leurs propres SGBD pouvant fonctionner sur des architectures matérielles distribuées et permettant de traiter des volumes de données importants.** - **Les systèmes propriétaires qui en ont résulté:** - Google (BigTable) - Amazon (Dynamo ) - LinkedIn (Project Voldemort) - Facebook (Cassandra Project puis HBase) - SourceForge.net (MongoDB) - Ubuntu One (CouchDB) ## Plan 1. Contexte 2. SGBD Relationnels transactionnels - Définition de transaction et d'intégrité référentiel - Les propriétés ACID - Limites des SGBD Relationnels transactionnels 3. Propriété BASE et Théorème du CAP (ou théorème de Brewer) 4. Présentation des BD NoSQL 5. Typologie des BD NoSQL - BD NoSQL orientées 'agrégats' - BD NoSQL orientées 'graphes' ## Typologie des BD NoSQL - **Il existe deux catégories de SGBD NoSQL :** - **Les BD NoSQL orientées 'agrégats'**: - **Type 'Clés-valeurs'**: - Exemples: DynamoDB, Redis, Riak, Voldemort, Memcached, ... - **Type 'Colonne'**: - HBase, Cassandra, Hypertable, Amazon Keyspaces, ... - **Type 'Document'**: - Exemples: MongoDB, CouchDB, Couchbase, RavenDB, ArangoDB, ... - **Les BD NoSQL orientées 'graphe'**: - Exemples: Neo4j, ArangoDB, TigerGraph, OrientDB, Amazon Neptune, ... ## BD type 'Clés-Valeurs' - **Ce modèle peut être assimilé à une table de hachage (hashmap) distribuée.** - **Les données sont simplement représentées par un couple clé-valeur.** - **La valeur:** une simple chaîne de caractères, un objet sérialisé, etc. - **Dans ce modèle clé-valeur, on stocke les entités mais pas les relations.** - **Ce modèle retourne une valeur dont elle ne connaît pas la structure.** - **Les structures de données ne sont pas contraintes par un schéma.** - Selon l'implémentation, la clé peut être attribuée ou générée aléatoirement lors de l'ajout de l'enregistrement. - **Chaque objet est identifié par une clé unique seule façon de le requêter.** ## Les opérations 'CRUD' - **L'exploitation des BD de types clés-valeurs est basée sur 4 opérations 'CRUD' :** - **Create:** créer un nouvel objet avec sa clé - create(key, value) - **Read:** lit un objet à partir de sa clé - read(key) - **Update:** met à jour la valeur d'un objet à partir de sa clé - update(key, value) - **Delete:** supprime un objet à partir de sa clé - delete(key) - **Ces BD de types clés-valeurs disposent généralement d'une simple interface de requêtage HTTP REST accessible depuis n'importe quel langage de développement.** - Elles ont des performances très élevées en lecture et en écriture et une scalabilité horizontale considérable. ## Exemples d'implémentation du modèle 'Clés-Valeurs' - **Amazon Dynamo:** - **Riak:** - **Redis (projet sponsorisé par VMWare):** - **Voldemort (développée et utilisée par LinkedIn):** - **Exemples d'utilisation :** - Dépôt de données avec besoins de requêtage très simples. - Ces BD sont adaptées aux applications nécessitant des performances élevées comme les système de stockage de cache ou d'information de sessions distribuées. - La gestions de profils et préférences d'utilisateurs des sites de E-commerce. - Les données de capteurs et des logs. ## Avantages et limites des bases orientées clé-valeur - **Avantages:** - **Performance:** Accès rapide aux données grâce à l'indexation directe par clé. - **Simplicité:** Pas de relations complexes ou de schéma fixe. - **Flexibilité:** Les valeurs peuvent être de n'importe quel type. - **Scalabilité Horizontale** - **Limitations:** - **Manque de relations:** Pas de gestion native des relations complexes entre les données. - **Requêtes limitées:** Pas de langage de requête avancé comme SQL. - **Dépendance à la clé:** Les clés doivent être bien définies pour retrouver les données. ## BD type 'Colonnes' - **Dans ce modèle, les données sont stockées par colonne, non par ligne.** - **Chaque colonne est définie par un couple clé-valeur.** - **Modèle proche d'une table dans un SGBDR mais plus flexible:** - Les colonnes d'une base de données relationnelle sont statiques et présentes pour chaque ligne. - Dans une base de données orientée colonnes, les colonnes sont dynamiques et présentes uniquement pour les lignes concernées. - Il n'y a pas de colonnes avec comme valeur Null donc le coût de stockage des valeurs Null est 0. - Il est possible d'ajouter des colonnes à une ligne à tout moment. ## Les principaux concepts associés au modèle 'colonnes' - **Une Colonne est une entité de base représentant un champ de donnée, chaque colonne est définie par un couple clé-valeur.** - Les colonnes sont stockées de manière triée sur le disque: - Cela permet d'obtenir un intervalle de colonnes avec un nombre réduit d'accès aléatoires sur le disque. Il nécessite par contre de reconstruire l'ensemble de la table de données sur le disque au fur et à mesure des modifications. - **Une supercolonne est une colonne contenant d'autres colonnes.** - L'utilisation des super-colonnes ajoute une dimension supplémentaire au modèle permettant par exemple le stockage de listes de listes. - **Une famille de colonnes permet de regrouper plusieurs colonnes (ou supercolonnes).** ## Exemples d'implémentation - **Cassandra (Initialement créé par Facebook):** - **Hbase (développé au sein de Hadoop):** - **Exemples d'utilisation :** - Traitements des données massives (via des opérations de type MapReduce). - Logging, stockage des profils des clients et l'analyse de la clientèle. - Traitement des données structurées et de Business Intelligence (BI). - gérer le vote des spectateurs. - Magasins d'analyse des données semi-structurées. - Journalisation des événements et des compteurs. ## Avantages et limites - **Avantages:** - **Optimisation des lectures:** Les colonnes nécessaires pour une requête peuvent être chargées sans lire l'ensemble de la ligne. - **Flexibilité du schéma:** Les colonnes peuvent varier d'une clé de ligne à une autre sans nécessiter de modification globale. - **Performances accrues pour l'analyse:** Idéal pour les requêtes analytiques massives où seules quelques colonnes sont nécessaires. - **Scalabilité Horizontale** - **Limitations:** - **Optimisé pour l'écriture et la lecture massive:** Moins adapté aux transactions complexes. - **Moins performant pour les requêtes complexes:** Pas aussi flexible que SQL pour les jointures ou les relations et moins intuitif que les SGBDR. ## BD type 'Documents' - **Elles stockent une collection de "documents", une collection contient plusieurs documents.** - **Elles sont basées sur le modèle 'clé-valeur' mais la valeur est un document en format semi-structuré hiérarchique de type JSON ou XML, il est possible aussi de stocker n'importe quel objet, via une sérialisation.** - **Les documents ont une structure arborescente, ils contiennent une liste de champs, un champ a une valeur qui peut être une liste de champs.** ## BD type 'Documents' - **Bien que les documents soient structurés, ces BD n'ont pas de schéma (schemaless), il n'est pas nécessaire de définir au préalable les champs utilisés dans un document:** - Les documents peuvent voir une structure hétérogène au sein de la BD. - Ces BD permettent d'effectuer des requêtes sur le contenu des documents/objets. - **Elles ont généralement une interface d'accès HTTP REST permettant d'effectuer des requêtes.** ## Exemples d'implémentation - **CouchDB (distribué sous licence Apache):** - **MongoDB (developpé par MongoDB inc):** - **Couchbase (sous licence Apache HTTP Server):** - **Exemples d'utilisation :** - Enregistrement d'événements. - Systèmes de gestion de contenu. - Web analytique ou analytique temps-réel. - Catalogue de produits (e-commerce). ## Avantages et limites des bases orientées clé-valeur - **Avantages:** - **Flexibilité du schéma:** Gestion de données hétérogènes. - **Facilité de développement:** Format proche de celui utilisé dans les applications (ex. JSON pour les API REST). - **Performances pour les lectures/écritures massives:** Les données étant regroupées dans un document, moins de jointures sont nécessaires, ce qui améliore les performances. - **Adaptées aux structures imbriquées:** Parfaites pour les applications où les données ont une structure hiérarchique ou imbriquée (ex. JSON). - **Scalabilité Horizontale** - **Limitations:** - **Moins adaptées aux relations complexes:** Non optimales pour des relations complexes nécessitant des jointures fréquentes. - **Problèmes de cohérence:** Ces BD privilégient souvent la disponibilité sur la cohérence stricte dans un environnement distribué. - **Augmentation de la redondance:** En regroupant toutes les données associées dans un seul document, on peut introduire des duplications. ## BD NoSQL orientées 'graphes' - **C'est une BD utilisant la théorie des graphes. Elle est adaptées pour les cas où les relations entre les données sont aussi importantes, voire plus, que les données elles-mêmes.** - **Elle correspond à un système de stockage de données dans un graphe, capable de fournir une adjacence entre éléments voisins : chaque voisin d'une entité est accessible grâce à un pointeur physique.** - **Les enregistrements sont des noeuds.** - **Les noeuds sont connectés entre eux par des relations orientées.** - **Les noeuds et les relations peuvent avoir des attributs qu'on appelle 'propriétés'.** - **Un 'label' est un nom qui organise des groupes de noeuds.** - **Un 'chemin' est un ou plusieurs noeuds connectés par des relations. II résulte d'une requête ou d'une traversée.** ## Exemple d'implémentation - **Neo4j (développé par Neo Technology, Inc):** - **OrientDB (Orienté graph et document):** - **ArangoDB (Orienté graph et document):** - **Exemples d'utilisation :** - **Exploitation des relations entre les données:** - Par exemple: connaissances entre des personnes, description de l'ensemble des pièces d'une machine industrielle et de la manière dont elles sont liées entre elles. - **Modélisation des données Géo-Spatial:** Carte routière et calculs d'itinéraires. - Elles sont utilisées dans la modélisation des réseaux sociaux. ## Avantages et limites des bases orientées graphe - **Avantages:** - **Représentation intuitive des données.** - **Performances pour les relations complexes:** Les graphes permettent des calculs comme la recherche de plus courts chemins ou les analyses de centralité sans les coûts de jointures massives. - **Langages de requêtes spécialisés** comme Cypher (pour Neo4j) ou Gremlin (pour des bases comme Amazon Neptune) pour exprimer des requêtes complexes. - **Limites:** - **Pas adaptées aux données tabulaires;** Nécessite une expertise spécifique pour modéliser et interroger les graphes. - **Manque de standards universels** ce qui rend les migrations et l'interopérabilité difficiles. - **Scalabilité horizontale limitée** pour des graphes massifs - **Les structures complexes des graphes rendent la maintenance plus coûteuse.** - **Moins d'outils et de documentation disponibles comparé aux bases relationnelles ou orientées documents.**