BASE DE DONNÉES ORIENTÉE DOCUMENTAIRE

Une base de données orientée document étend le concept de base de données clé-valeur
en employant des structures de données flexibles, qui ne nécessitent pas de schémas
prédéfinis. Ces bases de données stockent les enregistrements sous forme de « documents »
et prennent en charge des documents à structure imbriquée et complexe pour définir des
sous-catégories d'informations. Pour une base de données de documents, l'unité atomique
de base stockée est un document.
Il existe quelques différences majeures entre les bases de données de documents et les
bases de données clé-valeur. Premièrement, une base de données de documents organise les
documents en ensembles liés appelés collections. Ceci est similaire au concept de tables. Un
document lui-même est analogue à une ligne dans un fichier relationnel.base de données. En
comparaison, une base de données clé-valeur stocke toutes les paires <key,value> collectivement
dans un seul espace de noms. Deuxièmement, les valeurs des données dans une base de données
clé-valeur sont opaques pour le magasin, alors que les valeurs des données dans une base de
données orientée document sont transparentes pour le magasin.

7.5.1 Forces
Les bases de données documentaires peuvent offrir les avantages suivants aux utilisateurs :
1. Le prix de la mise à l’échelle avec une base de données de documents est bien inférieur
à celui d’une base de données SQL.
2. Puisque les données sont transparentes pour le magasin, ces bases de données peuvent
indexer les champs des documents, ce qui permet à l'utilisateur d'interroger non
seulement par la clé primaire mais également par le contenu d'un document.
3. Offre la possibilité de réaliser un développement d’applications extrêmement rapide.
4. Sans schéma, totalement libre de définir le contenu d'un document.

7.5.2 Limites
Outre les puissants moteurs de requête et les fonctionnalités d’indexation, il existe quelques
limitations :

1. Cette base de données ne convient pas aux applications de transactions commerciales.

2. Il n'offre pas de jointures entre les collections.

3. Il n’offre aucun support d’intégrité référentielle.

7.5.3 Cas d'utilisation

Les bases de données de documents constituent une excellente solution pour de nombreux
cas d'utilisation, notamment :
1. Lorsque les données sont fortement orientées vers les documents et ont plus de sens.

2. Lorsque les données ne sont pas structurées.

Quelques exemples bien connus de bases de données de documents sont MongoDB [86],
Couchbase [112] et CouchDB [241].
7.5.4 MongoDB
MongoDB est une base de données NoSQL non relationnelle et open source, qui s'appuie sur
le stockage de documents pour stocker les données. Cela implique que toutes les données de
MongoDB sont stockées dans des documents. MongoDB fournit quelques services de bases
de données relationnelles tels que le tri, l'indexation secondaire et les requêtes par plage.
MongoDB est une base de données évolutive qui repose sur une mise à l'échelle. Cela
signifie que davantage de nœuds informatiques peuvent être ajoutés facilement.

1. Représentation des données: Comme indiqué, MongoDB est une base de données de
style document. Le style de document est analogue au concept de ligne dans les SGBDR.
Les documents dans MongoDB sont stockés au format JavaScript Object Notation
(JSON) [140]. Dans MongoDB, une collection est un groupe de documents. Ceci est
analogue à une table dans un SGBDR.

Stockage de documents dans MongoDB

Exemple 7.7 (Stockage de documents dans MongoDB).Dans cet exemple, nous
apprendrons certains des styles valides et invalides de représentation des paires
<clé, valeur> dans les documents MongoDB.

{" Étudiant " : " John , Smith "}.

Ici, le document contient une clé « étudiant », avec une valeur « John Smith ».

Plusieurs <Clé, Valeurs> :

Plusieurs clés dans un document peuvent également être incluses mais elles
doivent être uniques. Par exemple, voici une représentation valide :
{" Étudiant " : " John , Smith ", " Ville " : "
Cleveland"}
Clés en double :
Les clés en double ne sont pas autorisées. Par exemple,
{" Étudiant " : " John , Smith ", " Étudiant " : " John
,Forgeron"}
Sensible aux majuscules et minuscules:
Les clés sont sensibles à la casse. Donc,
{" Étudiant " : " John , Smith ", " étudiant " : " John
,Forgeron"}
sont des paires <key,value> valides.

2. Indexation et partage: MongoDB prend en charge l'indexation des données pour un

traitement rapide des requêtes. Les documents sont indexés selon des mots-clés pour
un accès et une récupération plus rapides.
 FIGURE 7.6 MongoDB – réplication [139]

MongoDB intègre le partage automatique, grâce auquel un cluster MongoDB peut

diviser les données et les rééquilibrer automatiquement. La fonctionnalité de
partitionnement automatique offre les avantages suivants :250] :

(a) Équilibrage automatique des données.

(b) Évolutivité avec un temps d'arrêt minimal, c'est-à-dire que de nouveaux hôtes
peuvent être ajoutés.
(c) Réplication pour éviter un point de défaillance unique.
(d) Un mécanisme de basculement robuste pour éviter les temps d’arrêt.

Un fragment se compose d'un ou plusieurs serveurs contenant le sous-ensemble de

données dont il est responsable. Par exemple, si nous avions un cluster contenant les
données de 100 000 utilisateurs, une partition peut contenir les données de 20 000
utilisateurs. S'il y a plusieurs serveurs dans une partition, une partition peut également
contenir des données répliquées.
MongoDB utilise des clés (également appelées clé de fragmentation), qui peuvent être
n'importe quel champ ou combinaison de champs. Pour le partitionnement, une clé de
partition est spécifiée qui spécifie les champs sur lesquels les données seront
distribuées. En raison de la clé de fragmentation, les fragments peuvent être décrits
comme un triple de
<collection, keymin et keymax >.
La taille maximale d'un morceau est de 200 Mo. Une fois qu'un morceau atteint une
taille maximale de 200 Mo, il peut être divisé en nouveaux morceaux.
Nous pouvons avoir une idée de base sur l'architecture de la réplication MongoDB à partir
dechiffre
7.6. Un fragment contenant des données « ABC » est représenté sous forme de cylindre,
tandis que les données sont répliquées sur plusieurs serveurs, représentés sous forme
de boîtes cubiques.
Pour répartir uniformément les données entre les partitions, MongoDB peut transférer
 des morceaux de données d'une partition à une autre. Les données qui peuvent être
copiées dépendent de la clé de données sélectionnée.
{"ID" : K001-12 , "Nom" : "Abdul", "DoB" : 15-12-2000}
{"ID" : K002-12 , "Nom" : "Ahmed", "DoB" : 18-11-2000}
{"ID" : K003-12 , "Nom" : "Anisha", "DoB" : 15-12-2000}
{"ID" : K001-11 , "Nom" : "Bob", "DoB" : 18-11-2000}
{"ID" : K002-14 , "Nom" : "Christine", "DoB" : 15-12-2000}
{"ID" : K004-13 , "Nom" : "Jeniffer", "DoB" : 18-11-2000}
{"ID" : L001-11 , "Nom" : "Kim", "DoB" : 15-12-2000}
{"ID" : L002-10 , "Nom" : "Li Hao", "DoB" : 18-11-2000}
{"ID" : L002-11 , "Nom" : "Melissa", "DoB" : 15-12-2000}
{"ID" : P002-10 , "Nom" : "Otiquo", "DoB" : 18-11-2000}
{"ID" : P001-12 , "Nom" : "Paul", "DoB" : 15-12-2000}
{"ID" : K004-12 , "Nom" : "Ravinder", "DoB" : 18-11-2000}
{"ID" : P004-12 , "Nom" : "Salman", "DoB" : 15-12-2000}
{"ID" : P005-12 , "Nom" : "Sam", "DoB" : 18-11-2000}
{"ID": P006-12 , "Nom" : "Aile", "DoB" : 15-12-2000}
{"ID": K005-12 , "Nom" : "Xue", "DoB" : 18-11-2000}
{"ID": K006-12 , "Nom" : "Zafar", "DoB" : 18-11-2000}
{"ID": K006-12 , "Nom" : "Zuli", "DoB" : 18-11-2000}

FIGURE 7.7 Partage dans MongoDB

MongoDB équilibre automatiquement les données sur toutes les partitions. Chaque
fragment contient plusieurs plages afin de réduire la quantité de données transférées.
Nous pouvons considérer une plage comme une collection de clés telles que chaque
fragment puisse contenir plusieurs plages.
Pour comprendre l'ensemble du scénario de fractionnement des données et de partage
automatique, considéronsexemple 7.9, qui est basé sur une base de données
d'étudiants contenant leurs identifiants, leurs noms et leur date de naissance (date de
naissance).

Partage automatique dans MongoDB

Exemple 7.9 (Partage automatique dans MongoDB).En chiffres7.7, il y a 18
enregistrements. Supposons que si les données sont partagées en trois
fragments de telle sorte que les noms dans la plage [AJ] un se trouvent dans la
partition 01, [KR] dans la partition 02 et [SZ] dans la partition 03. Cette division
fournit une charge équilibrée dans chaque partition. Supposons maintenant que
si le nombre d'enregistrements augmente de telle sorte que les fragments 01 et
02 aient chacun 12 enregistrements, alors que le nombre d'enregistrements reste
inchangé dans le fragment 03. Puisque le nombre total d'enregistrements est
désormais de 30, une manière naïve consiste à déplacer deux enregistrements
de fragment 1 vers fragment 2, puis quatre enregistrements du fragment 2 vers
le fragment 3. De cette manière, six enregistrements doivent être déplacés.
Alternativement, si une autre partition doit être ajoutée, alors au total huit
enregistrements (quatre de chaque partition 1 et quatre de la partition 2)
peuvent être déplacés de telle sorte que la partition 1 et la partition 2
contiendront huit enregistrements chacune, tandis que la partition 3 et la
partition 4 le seront. ont sept enregistrements chacun.
Afin de réduire la quantité de transfert de données, une autre approche consiste à
définir
plusieurs plages en fragments. De cette manière, plusieurs plages peuvent être
 stockées dans chaque partition. Ainsi, au lieu de [AJ], le fragment 1 peut avoir
deux morceaux [AG] et [HJ]. La taille ou la portée du morceau peut être ajustée
en fonction des besoins. Dans ce cas, deux enregistrements du fragment 1
peuvent être directement déplacés vers le fragment 3. De même, les morceaux
du fragment 2 peuvent être divisés de cette manière, deux enregistrements
chacun du fragment 1 et du fragment 2 peuvent être déplacés vers le fragment
3. Ainsi, nous pouvons notez que le nombre total d’enregistrements à déplacer
peut être réduit à 4 enregistrements.
un
Ici, « [' et '] » désignent des limites inclusives

MongoDB prend en charge le partage automatique. Le cluster gère automatiquement

le fractionnement des données et le rééquilibrage. Cela supprime certains des
problèmes administratifs liés au partitionnement manuel.

7.1 BASE DE DONNÉES ORIENTÉES COLONNES

Une base de données orientée colonnes stocke son contenu par colonne plutôt que par
ligne et sérialise toutes les valeurs d'une colonne ensemble. Une base de données en colonnes
vise à récupérer ou à écrire efficacement des données à partir du stockage sur disque dur afin
d'accélérer le temps nécessaire pour renvoyer une requête.
7.6.1 Forces
La base de données orientée colonnes peut offrir les avantages suivants :
1. Étant donné que les données stockées dans les colonnes sont généralement similaires
et que les colonnes sont stockées les unes à côté des autres, les algorithmes de
compression utilisent cette similitude des données adjacentes pour une compression
élevée des données et permettent une utilisation plus efficace de la capacité de
stockage.
2. La compression des données peut grandement améliorer les performances en réduisant
les E/S du disque pour lire une grande quantité de valeurs répétitives. Cela améliore les
performances des requêtes en réduisant considérablement les E/S requises pour
exécuter les requêtes analytiques.
3. Un index Columnstore atteint des performances de requête élevées sur les requêtes
d'agrégation telles que AVG, SUM, MAX, MIN et COUNT. Cela est dû au fait que le
nombre de recherches sur le disque dur est réduit par rapport aux bases de données
basées sur les lignes.
4. Les bases de données orientées colonnes sont plus efficaces pour insérer des valeurs
de colonne unique à la fois, car cela peut être écrit efficacement sans affecter les autres
colonnes des lignes. Cela contraste avec les bases de données orientées lignes qui sont
plus efficaces pour écrire une nouvelle ligne si toutes les données des colonnes sont
fournies en même temps.
5. Les capacités rapides de recherche, d'analyse et d'agrégation du stockage de base de
données orienté colonnes sont très efficaces pour l'analyse.

7.6.2 Limites
Les bases de données orientées colonnes présentent les limitations suivantes :
1. Les bases de données orientées colonnes ne sont pas utiles pour les systèmes
nécessitant des transactions ACID. Ils sont nettement plus lents à gérer de telles
transactions.
2. Les opérations d'écriture telles que INSERT ou UPDATE sont relativement lentes par
rapport aux bases de données orientées lignes ou à stockage de lignes en raison du
nombre de recherches de disque requises pour insérer ou mettre à jour une ligne.
L'écriture sur une ligne nécessite de rechercher dans chaque colonne une insertion
ou une mise à jour multi-colonnes, contrairement à une base de données orientée
lignes dans laquelle la ligne entière peut écrire en même temps.
3. Les bases de données orientées colonnes ne sont pas utiles pour les systèmes avec des
requêtes très variables.

7.6.3 Cas d'utilisation

Les bases de données orientées colonnes sont conçues pour des cas d'utilisation tels que :
1. Les bases de données orientées colonnes sont plus adaptées aux applications
d'entreposage de données et c'est ainsi qu'elles sont actuellement utilisées dans
l'industrie.
 2. La base de données orientée colonnes peut également être utilisée pour les systèmes
de traitement analytique en ligne (OLAP).
3. La base de données orientée colonnes peut fonctionner bien mieux lorsque les écritures
sont rares et que l'utilisation implique un petit ensemble de récupération et
d'agrégation de colonnes. Ils peuvent accélérer les requêtes analytiques des données
en lisant uniquement les colonnes qui doivent être lues.
Cassandre [234], HBase [176] et Amazon SimpleDB [125] sont des exemples populaires
de bases de données de stockage en colonnes.
 TABLEAU 7.2 Notations SGBDR et Cassandra

SGBDR Cassandre
Base de Espace clé
données
Tableau Famille de colonnes
(CF)
Clé primaire Clé de ligne
Nom de Nom de colonne
colonne
Valeur de la Valeur de la
colonne colonne

7.6.4 Apache Cassandre

Dans cette section, nous étudierons Cassandra, qui est un stockage de données NoSQL
distribué basé sur des colonnes développé par Facebook.
Cassandra a été développée pour répondre aux besoins de stockage de la recherche dans
la boîte de réception de Facebook. La fonctionnalité permet aux utilisateurs de Facebook de
rechercher des messages dans leur boîte de réception. L'exigence était de faire évoluer le
système avec l'augmentation du nombre d'utilisateurs et de fournir un débit élevé avec des
milliards d'écritures par jour. Étant donné que les utilisateurs de Facebook sont dispersés dans
le monde entier, une exigence importante était de répliquer les données dans différents
centres de données afin de réduire la latence d'accès.

1. Modèle de données: Une table dans Cassandra peut être distribuée sur différents
nœuds. Le modèle de données de Cassandra se compose de clés et de valeurs. Chaque
attribut est stocké sous forme de clé, où la valeur représente la valeur réelle
correspondant à cette clé. Cassandra implémente une approche flexible dans laquelle il
peut y avoir peu de valeurs facultatives dans les données, de sorte que certaines lignes
peuvent avoir plus d'attributs que d'autres.

Tableau 7.2explique différentes notations pour Cassandra.

Cassandra partitionne les données en utilisant un hachage cohérent. Grâce à cette
méthode, chaque valeur de hachage est mappée à un nœud Cassandra distinct. Nous
devrions rappeler de nos principes fondamentaux
 concepts de hachage selon lesquels dans un hachage cohérent, les nœuds sont
organisés sous la forme d'un cercle. Pour trouver l'emplacement de mappage d'un
élément de données, sa valeur de hachage est utilisée pour trouver le premier nœud
qui mappe l'élément. L'évolutivité est obtenue en ajoutant plus de nœuds dans un
cercle. Lors de l'ajout d'un nœud, une partie des éléments de données est remappée.
Le nombre deles éléments de données qui doivent être remappés sont déterminés à l'aide
des deux nœuds voisins du nouveau nœud.
En utilisant un hachage cohérent, Cassandra atteint l'évolutivité.

Dans Cassandra, la clé primaire est utilisée pour déterminer une valeur de hachage.
Pour cette raison, la clé primaire est également appelée clé de partition. Si la clé
primaire est constituée d'entités composites, alors le premier composant est utilisé
pour déterminer la partition.
2. Réplication: Cassandra réplique les éléments de données pour atteindre une évolutivité
et une durabilité élevées. Chaque élément de données est répliqué N fois, où N est le
facteur de réplication défini dans le système. Chaque clé possède un nœud
coordinateur, qui garantit que l'élément de données est distribué aux N-1 répliques
restantes.
7.2 BASE DE DONNÉES GRAPHIQUES
Un système de base de données graphique est un système de base de données NoSQL
qui utilise un modèle de données graphique pour le stockage et le traitement des
données. Le modèle de données est un graphique avec des nœuds, des arêtes et des
propriétés. Il est conçu pour un accès ultra-rapide à des données complexes. Une base de
données graphique nous permet de modéliser notre problème d'une manière qui le rend
beaucoup plus simple et expressif par rapport à d'autres bases de données relationnelles
ou NoSQL. Les éléments d'une base de données graphique ont une référence directe à
leurs éléments adjacents, ce qui offre un avantage supplémentaire lors du parcours des
graphiques.
Comme on peut le voir dansexemple 7.13, les graphiques modélisent les relations du
monde réel beaucoup plus efficacement que les bases de données relationnelles. Les objets
ou entités formant des nœuds dans un graphique peuvent être ajoutés facilement avec des
connexions relationnelles reliant d'autres nœuds.
Il existe des implémentations de bases de données graphiques qui fournissent des
garanties ACID [272], haute disponibilité, évolutivité en lecture horizontale [326] ainsi qu’une
capacité de stockage permettant de stocker des milliards d’entités.

7.7.1 Forces
Les points forts des bases de données graphiques sont les suivants :
1. Les bases de données de graphiques ont la capacité de stocker différents types de
graphiques : graphiques non orientés, graphiques pondérés, hypergraphes, etc.
 2. Les modèles de données graphiques effectuent un bon travail lors de la création de données riches
et hautement connectées pour représenter les cas d'utilisation et les applications du monde réel.
3. Ils ont la capacité de gérer efficacement des données hautement connectées et des requêtes
complexes, quelle que soit la taille de l'ensemble de données.

4. Le modèle sous-jacent de base de données de graphiques fournit les fonctionnalités de la théorie

des graphes et peut facilement gérer des modèles de données complexes et flexibles.

5. Les bases de données de graphiques sont optimisées pour les parcours de graphiques locaux et
offrent des performances exceptionnelles pour les lectures locales en parcourant le graphique.
6. Les bases de données graphiques sont très utiles pour stocker des entités et des informations sur
les relations entre ces entités.

7.7.2 Limites
Outre les nombreux avantages, l’utilisation de bases de données graphiques présente quelques limites :
1. Les bases de données graphiques ne sont pas la meilleure solution pour les applications de très
gros volumes de données ou pour la mise à jour d’ensembles de données.

2. La force d'une base de données graphique réside dans le fait de parcourir les connexions entre les
nœuds et nécessite généralement que toutes les données tiennent sur une seule machine.
Cependant, cela devient la limitation de l’évolutivité des bases de données graphiques. En outre,
de nombreuses bases de données graphiques disponibles dans le commerce ne sont pas non plus
évolutives horizontalement. Par conséquent, les applications de graphiques ont une utilisation
limitée pour les applications à grand volume.

3. Les données étant connectées par nature, la mise à l’échelle d’un graphique devient plus difficile
par rapport aux autres bases de données NoSQL. Mettre à l’échelle les données graphiques en les
répartissant sur plusieurs machines n’est pas facile. De même, les relations qui s’étendent sur
plusieurs nœuds rendent la distribution des graphiques beaucoup plus difficile.
4. Les bases de données graphiques sont plus adaptées à la visualisation et à la compréhension des
relations qu'au stockage des transactions. Par exemple, utiliser une base de données graphique
pour stocker les transactions d’une épicerie n’est pas viable. Cependant, une base de données
graphique peut capturer et présenter efficacement les habitudes de dépenses d'un client.

5. Les grands graphiques peuvent être partitionnés pour être déployés sur un cluster distribué.
Cependant, partitionner un graphique n'est parfois pas facile en raison de facteurs tels que la
latence élevée du réseau, les modèles d'accès au graphique et l'évolution en temps réel du
graphique.

7.7.3 Cas d'utilisation

Les systèmes basés sur des graphiques sont de plus en plus utilisés pour stocker et traiter le Big Data. La
théorie des graphes s’est révélée efficace et significative dans de nombreux problèmes dans divers
domaines. Les graphiques peuvent être appliqués à de nombreuses applications du monde réel. Les
réseaux sociaux tels que Facebook, Twitter et LinkedIn peuvent être représentés sous forme de systèmes
basés sur des graphiques, dans lesquels chaque profil (ou utilisateur) désigne un sommet et leurs
relations sont les bords du graphique. De même, le World Wide Web est la plus grande représentation
d'un graphe réel, dans lequel chaque URL désigne un sommet et les liens sortants de l'URL sont les bords
du graphe.
D'autres applications telles que la relation employé-tâche, le chemin le plus court d'un endroit à un
autre et la gestion des flux pour un oléoduc sont également représentées sous forme de graphiques.
 TABLEAU 7.3 Utilisation des bases de données basées sur des
graphiques

Applications Usage
Réseaux sociaux Ces applications permettent aux organisations d'identifier
directement
et les relations indirectes entre les personnes, les
groupes et les activités.
Les bases de données graphiques sont généralement des
bases de données incontournables pour les réseaux
sociaux, car elles permettent de découvrir facilement
comment une personne est connectée à une autre
personne au sein d'un groupe ou d'une organisation. De
nombreuses grandes organisations de réseaux sociaux
prospères utilisent des bases de données de graphiques
à leur base, ce qui permet de parcourir rapidement un
graphe social et renvoyer les résultats de la requête à
grande vitesse.
Recommandation Un système de recommandation aide les utilisateurs en
Systèmes leur fournissant des suggestions, gestions de leurs
produits ou services en fonction du comportement ou des
préférences des utilisateurs. Les bases de données
graphiques sont naturellement bien adaptées à la création
de moteurs de recommandation. Ces bases de données
ont la capacité de formuler une recommandation efficace.
Bien que les bases de données relationnelles puissent être
utilisées pour représenter ce type de structure de
données, les bases de données graphiques sont en réalité
conçues pour résoudre ce type de problème et sont
largement utilisées en termes de performances et de
maintenance et de durabilité.
Autorisation et Une base de données de graphiques a la capacité de gérer
Contrôle d'accès l'accès à
contenu et gérer les relations entre les utilisateurs, les
groupes, les ressources et les collections. Il peut parcourir
des millions de relations par seconde pour exécuter des
requêtes en quelques millisecondes et accéder à des
recherches sur des structures vastes et complexes.
tures.

Certains des cas d'utilisation de bases de données graphiques les plus courants sont mentionnés
danstableau 7.3. De plus, la base de données graphique est une excellente solution pour de nombreux
autres cas d’utilisation, notamment les suivants :
1. Les performances et la réactivité des requêtes sont généralement les principales préoccupations
en ce qui concerne les plateformes de données pour de nombreuses organisations. Les
applications telles que les systèmes transactionnels en ligne ou les applications Web d'entreprise
nécessitent généralement de répondre aux requêtes des utilisateurs en quelques millisecondes.
Cependant, à mesure que la taille de l’ensemble de données augmente, l’opération de jointure
devient plus difficile et les performances des requêtes se détériorent. Apparemment, les bases de
données de graphiques ne subissent pas de telles pénalités et transforment des jointures
complexes en parcours de graphiques rapides en mettant à l'échelle les temps de requête et en
maintenant des performances en millisecondes, quelle que soit la taille globale de l'ensemble de
données. Par conséquent, si l'application présente des douleurs articulaires, c'est un autre
indicateur que les bases de données graphiques seront un meilleur choix et une meilleure solution
pour un modèle de données complexe dans une base de données relationnelle.
2. Une base de données graphique est mieux utilisée pour explorer des données structurées comme
un graphique, un arbre ou une hiérarchie et les relations entre les entités sont significatives. Les
données graphiques sont également utiles pour les domaines d'application comportant des
 données complexes et un modèle hautement connecté, par exemple les réseaux sociaux, les soins
de santé, la logistique en temps réel, etc.
3. Les bases de données graphiques sont également utiles pour les applications qui nécessitent de
nombreuses requêtes centrées sur les graphiques. Par exemple, ils fonctionnent mieux pour
analyser des requêtes telles que l'étroitesse des liens, le nombre d'étapes nécessaires pour passer
d'un point à un autre, etc.

4. Les bases de données graphiques conviennent également à la visualisation des données,

notamment à la façon dont les éléments sont connectés entre eux. L'analyse des relations entre
les personnes sur des sites de réseaux sociaux tels que Facebook, Twitter et LinkedIn sont des cas
d'utilisation typiques des bases de données graphiques.
Quelques exemples bien connus de bases de données graphiques sont Apache Giraph [305], Neo4j
[362], OrientDB [351], HyperGraphDB [204] et AllegroGraph [72].

7.7.4 Apache Giraph

Apache Giraph [138] est un système distribué pour le traitement de graphiques. L'entrée dans Giraph
peut provenir de n'importe quel fichier texte ou source telle que HDFS. L'entrée se présente sous la
forme d'un tuple composé de
<sommet, arêtes et relations>.
Les grands graphes G<V,E,R> intègrent le partitionnement des sommets, c'est-à-dire que le graphe
est partitionné par rapport aux sommets. Ceci est contraire à l'approche Edge Partitioning dans laquelle
un graphe est partitionné en fonction des arêtes.
Pour le calcul, Giraph s'appuie sur le mode de fonctionnement Bulk Synchronous Parallel (BSP). Le
modèle BSP est utilisé dans de nombreux systèmes de traitement de graphes tels que Pregel [258,374]
et GraphHP [132].
Grâce à ce modèle, le calcul à grande échelle est décomposé en une série d'itérations. Chaque
itération est qualifiée de super-étape. Chaque super-étape implique un calcul sur plusieurs nœuds de
travail. Après chaque super-étape, les nœuds de travail échangent des messages pour la synchronisation.
L'échange de messages implique de recevoir une valeur des voisins et de mettre à jour sa propre valeur
en fonction de la valeur reçue du voisin. La valeur mise à jour est également envoyée aux voisins, qui
deviennent disponibles lors de l'itération suivante. A la fin de l'échange de messages, chaque nœud
travailleur peut décider d'être actif ou d'arrêter son état.
7.3 REMARQUES CONCLUSIONS
Les systèmes NoSQL sont devenus une alternative aux systèmes SGBDR. L'objectif principal de ces
systèmes est d'atteindre les objectifs d'évolutivité et de disponibilité, tout en facilitant l'analyse des
données. Dans ce chapitre, nous avons étudié quatre types de systèmes NoSQL. Nous avons également
étudié des exemples, des points forts, des limites et des études de cas pour chacun d'eux. De nouveaux
systèmes NoSQL sont en cours de développement pour répondre aux besoins émergents des systèmes
Big Data en matière de flexibilité, d'évolutivité et d'analyse.