Chapitre 6 NoSQL

Big Data
Pr .EL MENDILI
Année Universitaire: 2022/2023
Chapitre 6: Big DATA DB VS. BDR
Big Data 2
Qu'est-ce qu'Hadoop ?
Big Data 3
Bases de Données NOSQL
Définition
• Bases de données NOSQL (Not Only SQL) :
• Ce n'est pas (comme son nom le laisse supposer NoSQL (pas de SQL)
• Privilégier donc NOSQL plutôt que NoSQL
• 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
• Appelées également
• Cloud Databases
• Non-Relational Databases
• Big Data Databases
• Développées en réponse à l'augmentation exponentielle des données
générées, enregistrées et analysées par les utilisateurs modernes et
leurs applications.
Big Data 4
NOSQL VS. BDR
Big Data 5
NOSQL et BDR
Comparaison (1/3)
• Choix de NOSQL en opposition aux bases de données relationnelles conduits
par les contraintes du marché et les besoins techniques
• BigData
• Adaptation des BD NOSQL au BigData
o Volume ( Volume) : données très nombreuses
o Vitesse (Velocity) : beaucoup de données qui arrivent rapidement, à partir de plusieurs sources
o Variété ( Variety) : données structurées, semi-structurées ou non-structurées
o Complexité (Complexity ) : données stockées et gérées à plusieurs endroits et data centers.
• Disponibilité continue des données

• Le manque de disponibilité peut être fatal pour une entreprise
• BD NOSQL utilisent une architecture hautement distribuée
• Redondance des données et traitements : tolérance aux fautes
• D'où : disponibilité continue à travers les data centers. et le cloud
• Toute mise à jour ou modification est faite sans déconnecter la base
Big Data 6
NOSQL et BDR
Comparaison (2/3)
• 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
• Toute fonctionnalité d'écriture propagée à partir d'un emplacement,
pour être disponible aux utilisateurs à partir d'autres sites
• Difficile à appliquer aux BDR, surtout pour l'écriture
• Modèles de données flexibles
• Une des raisons majeures
• Dans le modèle relationnel, les relations entre les tables sont
prédéfinies, fixes et organisées dans un schéma strict et uniforme
• Problèmes d'évolutivité et de performance en gérant de grands
volumes de données
• Les BD NOSQL peuvent accepter tout type de données
(structurées, semi-structurées ou non-structurées) plus facilement
• Dans les BDR, les performances posent problème, surtout quand des
lignes « larges » sont utilisées et les actions de modification sont
nombreuses
Big Data 7
NOSQL et BDR
Comparaison (3/3)
• Business Intelligence et Analyse

• Capacité des bases NOSQL à exploiter les données collectées
pour dériver des idées
• Extraction d'informations décisionnelles à partir d'un grand
volume de données, difficile à obtenir avec des bases
relationnelles
• Bases NoSQL permettent le stocKage et la gestion des données
des applications métier, et fournissent une possibilité de
comprendre les données complexes, et de prendre des
décisions
• Capacités transactionnelles modernes

• Nouvelles définition du principe de transaction
• Utilisation des propriétés BASE au lieu des propriétés ACID
Big Data 8
NOSQL et BDR
Propriétés ACID
• Propriétés ACID : Atomicité, Consistance, Isolation et Durabilité
• Propriétés des transactions des BDR
• Atomicité : Soit toutes les instructions sont exécutées, soit aucune
• Consistance : toute transaction a mène la BD d'un état valide à un autre -
renforcée par les contraintes d'intégrité et les clefs étrangères
• Isolation : Même si plusieurs transactions peuvent être exécutées par un
ou plusieurs utilisateurs simultanément, une transaction ne devrait pas
voir les effets des autres transactions concurrentes
• Durabilité : Une fois la transaction enregistrée dans la base ( commit) ,
ces changements sont persistants.
• Toutes les BDR supportent les transactions ACID
• Mais :
• Données de plus en plus volumineuses + Besoin de systèmes évolutifs
• Besoin de bases de données distribuées sur le réseau, pour une évolutivité
horizontale.
Big Data 9
NOSQL et BDR
Théorème CAP
• Destiné à évaluer les systèmes de stockage distribués
• Théorème CAP : " Il est impossible de satisfaire les trois propriétés CAP
en même temps " .
• Propriétés CAP : Consistency, Avalability, Partition tolerance
• Consistance: Si j'écris une donnée dans un nœud et

que je la lis à partir d'un autre nœud dans un
système distribué, je retrouve ce que j'ai écris sur le
premier.
• Haute disponibdité : à tout moment, pour chaque
requête, la réponse est garantie. Même en cas de
panne, les données restent accessibles
• Tolérance au partitionnement : les données
peuvent être partitionnées sur différents supports sans
souci de localisation. Les activités continuent sans
interruption lors de la modification du système (en cas
d'ajout ou suppression de nœuds) et en cas de chute
du réseau
Big Data 10
NOSQL et BDR
Théorème CAP
• 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.
• Pour les BD NOSQL, il n'y a plus de jointures
• -> La propriété de consistance n'est plus assurée de la même manière
• Consistance dans NOSQL: consistance immédiate et éventuelle des
données à travers les nœuds de la base distribuée
Big Data 11
NOSQL et BDR
Propriétés BASE
• BASE : Basically Available,Soft- state, Eventual consistency
• Basically Available
• Le système garantit la disponibilité. comme définie dans le théorème
CAP
• Soft-State
• L'état du système peu changer dans le temps. même sans
nouvelles entrées, et ce à cause du principe de consistance
éventuelle
• Eventual Consistency
• Les modifications arriveront éventuellement à tous les serveurs. si on
leur donne suffisamment de temps
• BASE est plus flexible que ACID, accepte certaines
erreurs, dont l'occurrence est assez rare
Big Data 12
NOSQL et BDR
RécapituIatif
Big Data 13
Atouts
• Principaux atouts
• Évolutivité
• Disponibilité
• Tolérance aux fautes
• Caractéristiques
• Modèle de données sans schéma
• Architecture distribuée
• Utilisation de langages et interfaces qui ne sont pas uniquement
du SQL
Big Data 14
NOSQL et Big Data
• De point de vue métier, utiliser un environnement BigData et

NOSQL fournit un avantage compétitif certain
• Importance des données:

• « Si vos données ne croissent pas, alors votre
entreprise ne le fait pas non plus »
Big Data 15
Bases de Données NOSQL Hbase
Modèle de données¶
Le modèle se base sur six concepts, qui sont :
•Table : dans HBase les données sont organisées dans des tables. Les noms des tables sont
des chaînes de caractères.
•Row : dans chaque table, les données sont organisées dans des lignes. Une ligne est
identifiée par une clé unique (RowKey). La Rowkey n’a pas de type, elle est traitée comme un
tableau d’octets.
•Column Family : Les données au sein d’une ligne sont regroupées par column family. Chaque
ligne de la table a les mêmes column families, qui peuvent être peuplées ou pas. Les column
families sont définies à la création de la table dans HBase. Les noms des column families
sont des chaînes de caractères.
•Column qualifier : L’accès aux données au sein d’une column family se fait via le column
•
qualifier ou column. Ce dernier n’est pas spécifié à la création de la table mais plutôt à
l’insertion de la donnée. Comme les rowkeys, le column qualifier n’est pas typé, il est traité
comme un tableau d’octets.
•Cell : La combinaison du RowKey, de la Column Family ainsi que la Column qualifier identifie
d’une manière unique une cellule. Les données stockées dans une cellule sont appelées
les valeurs de cette cellule. Les valeurs n’ont pas de type, ils sont toujours considérés comme
tableaux d’octets.
•Version : Les valeurs au sein d’une cellule sont versionnés. Les versions sont identifiés par
leur timestamp (de type long). Le nombre de versions est configuré via la Column Family. Par
défaut, ce nombre est égal à trois. Big Data 16
Big Data 17
Hbase
Les données dans HBase sont stockées sous forme de HFiles, par
colonnes, dans HDFS. Chaque HFile se charge de stocker des données
correspondantes à une column family particulière.
Big Data 18
Hbase
Autres caractéristiques de HBase:
•HBase n'a pas de schéma prédéfini, sauf qu'il faut définir les familles
de colonnes à la création des tables, car elles représentent
l'organisation physique des données
•HBase est décrite comme étant un magasin de données clef/valeur, où
la clef est la combinaison (row-column family-column-timestamp)
représente la clef, et la cell représente la valeur.
Architecture¶
Physiquement, HBase est composé de trois types de serveurs de type
Master/Slave.
•Region Servers: permettent de fournir les données pour lectures et
écritures. Pour accéder aux données, les clients communiquent avec
les RegionServers directement.
•HBase HMaster : gère l'affectation des régions, les opérations de
création et suppression de tables.
•Zookeeper: permet de maintenir le cluster en état.
Big Data 19
Hbase
Le DataNode de Hadoop permet de stocker les données que le Region
Server gère. Toutes les données de HBase sont stockées dans des
fichiers HDFS.
Les RegionServers sont colocalisés avec les DataNodes.
Le NameNode permet de maintenir les métadonnées sur tous les blocs
physiques qui forment les fichiers.
Big Data 20
Hbase
Les tables HBase sont divisées horizontalement,
par row en plusieurs Regions.
Une region contient toutes les lignes de la table
comprises entre deux clefs données.
Les regions sont affectées à des noeuds dans le
cluster, appelés Region Servers, qui permettent de
servir les données pour la lecture et l'écriture.
Un region server peut servir jusqu'à 1000 régions.
Le HBase Master est responsable de coordonner
les region servers en assignant les régions au
démarrage, les réassignant en cas de récupération ou
d'équilibrage de charge, et en faisant le monitoring
des instances des region servers dans le cluster. Il
permet également de fournir une interface pour la
création, la suppression et la modification des tables.
HBase utilise Zookeeper comme service de
coordination pour maintenir l'état du serveur dans le
cluster.
Zookeeper sait quels serveurs sont actifs et
disponibles, et fournit une notification en cas d'échec
d'un serveur. Big Data 21
Hbase structure logique d’une table HBase
représentation courante de la structure logique de la table HBase
Big Data 22
ARCHITECTURE ET FONCTIONNEMENT DU HBASE
HBase est un SGBD distribué et en tant que tel, il s’installe sur un cluster d’ordinateurs. Comme
Hadoop, HBase s’installe sur un cluster en architecture Maître/Esclave.
Dans la terminologie HBase, le nœud maître s’appelle le HMaster, et les nœuds esclaves s’appellent
les RegionsServers. Le stockage des données est distribué sur les RegionsServers qui sont gérés
par le HMaster.
Le HMaster gère les métadonnées des tables HBase et coordonne l’exécution des activités des
RegionsServers, tandis que les RegionsServers effectuent les opérations de lecture/écriture de
données dans le cluster. La gestion du volume de données se fait par l’ajout des RegionsServers
supplémentaires dans le cluster. La figure ci-après illustre l’architecture d’un cluster HBase.
Big Data 23
ARCHITECTURE ET FONCTIONNEMENT DU HBASE
Dans le cas d’une base de données relationnelle, ces questions sont les suivantes : quelles sont
les tables de notre base de données ? Quelles sont les clés primaires ? Quelles sont les
associations qui existent entre les tables ? Ainsi de suite. Idem, préalablement à l’application des
« Best practices », vous devez répondre aux questions suivantes pour modéliser une table
HBase :
 Quelle est la structure des valeurs de la row key ?
 Combien de familles de colonnes la table doit-elle avoir ?
 Quelles données vont dans quelle famille de colonnes ?
 Combien de colonnes y’a t-il dans chaque famille ?
 Quel est le label ou titre de chaque colonne ?
 Quelles données seront stockées dans les cellules ?
 combien de versions de chaque cellule HBase devra t’il historiser ?.
Big Data 24
Types
 Orientées Clés-valeurs
 Orientées Colonnes
Orientées Document
 Orientées Graphes
Types
• Propriétés des BDR
• ACID : Atomicity, Consistency, isolation and Durability
• Utilisation de SQL
Types de Bases de Données NOSQL
1. Clef/Valeur ( Key/ Value Store)
• 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
• 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
• Communications se résumant surtout aux opérations PUT. GET et
DELETE et Update (API Simple)
• Objectif: fournir un accès rapide aux informations, conserver la
session d'un site web ...
• Exemple : DynamoDB (Amazon). Azure Table Storage
(ATS), Redis, BerReley DB, Vol demort (LinRed In)
1. C lef/Va leur ( Key/ Value Store)
Clés primaires Valeurs

Loto : Samedi 23 avril 2016 2, 15, 17, 22, 26 - 7
La grande question sur la vie, l'univers et le reste 42
logo cnrs
<html xmlns="http://www.w3.org/1999/xhtml"
http://prodev.cnrs.fr/doku.php?id=nosql2016 xml:lang="fr"
lang="fr" dir="ltr" class="no-js">
<head>
<meta charset="UTF-8" />
<title>nosql2016 [prodev]</title>
…
<body>
…
</body> </html>
 Cible
 Système de cache (memcache)
 Stockage de gros volume de données
 Collecte d’évènements
 Avantage
 Recherche rapide
 Table à 2 colonnes
 Inconvénient
 Aucun schéma
 Pas de requête possible sur les valeurs nativement
 Pas de garantie d’intégrité
Implémentations
 Dynamo
 Développée en 2007 et utilisée par Amazon pour gérer le panier d’achat
 Voldemort
 Développée et utilisée par LinkedIn
 Riak
 Edité par Basho Technologies
 Inspirée de Dynamo
 Base hybride orientée clé/valeur ou document
 Redis
 Hautement performant
 Redis n’est pas tolérant aux pannes
 Memcached
 Cache mémoire distribué, Eprouvé depuis de nombreuses années
En production
 The Guardian
(quotidien d’information britannique)
 GitHub
 Stack Overflow
 Craigslist
(site web américain de petites annonces et de forums de discussion)
 YouPorn
Types
Orientées Clés-valeurs
 Orientées Colonnes
2. Orientées Colonnes ( Column Store)
• Évolution de la BD clef/valeur
• Ressemble aux SGBDR, mais avec un nombre de colonnes
dynamique, différent d'un enregistrement à un autre (pas
de colonnes portant les valeurs NULL)
• Offrent de très hautes performances et une architecture
hautement évolutive
• Exemples: Hbase (Hadoop), Cassandra (Facebook,
Twitter), BigTable (Google)
ExempleCassandra : Colonne / Super Colonne / Famille de Colonnes

 Famille de colonnes
 Equivalent à une table dans une base de données relationnelle
 Structure des données par familles de colonnes
 1 clé pour accéder à un ensemble de colonnes
 Colonnes sont groupées par famille de colonne
 Données stockées par colonne
 Chaque colonne est définie par un couple clé-valeur
 Les colonnes sont regroupées par ligne
 Chaque ligne est identifiée par un identifiant unique.
 Requête sur
 Lignes
 Familles de colonnes
 Noms de colonnes
 Cible
 Répond aux problématiques
 de charge
 de volume
 de très haute disponibilité
 Timeseries
 Données stockées suivant des timestamps
 Adapter aux données issues de capteurs
 Clickstreams
 Enregistrement des actions d'un utilisateur sur une application
 Avantages
 Forte tolérance aux pannes
 Facilite l’agrégation
 Inconvénient
 API de (très) bas niveau
Implémentations
 Google BigTable
 Hbase
 Clone de BigTable développé au sein de l’écosystème Hadoop
 Très performant en lecture
 Cassandra
 Initialement créé par Facebook
 Très performant en écriture
 Pas de garantie de cohérence stricte
En production
 Google
 Netflix
Historique complet des visualisations des 36 millions d’utilisateurs
 Ebay
Données sociales (like, own, want)
 Twitter
 Cisco
 Facebook
Types
Orientées Colonnes
3. Orientée Documents (DocumentDatabase)
• Étendent le paradigme clef/valeur, avec des« documents» plus

complexes à la place des données simples, et une clef unique pour
chacun d'eux
• Documents 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
• Dans les bases relationnelles, cela impliquerait plusieurs jointures
• Exemples: Mongo DB (SourceForge), Couch DB (Apache),
RavenDB (destiné aux plateformes .Net/Windows, interrogation
via LINQ)
3. Orientée Documents ( Document Database)
 Proche du système clé-valeur
 Base de données
 Ensemble de collections
 Collection
 Ensemble de documents
 Equivalent aux tables dans les SGBDR
 Document
 Unité de base de stockage
 Equivalent aux lignes dans les SGBDR
 Ensemble de couples clé-valeur au format JSON ou XML
 Chaque document possède un identifiant unique dans une collection
 Cible
 Journalisation d’évènements
 Application CRUD
 Recherche complexe
 Avantage
 Données semi-structurées
 Gestion de la version du document
 Inconvénient
 Performances des requêtes
Implémentations
 CouchDB
 Pas de verrou lors des accès concurrents
 MongoDB
 Développé par la société 10gen
 Permet d’indexer les propriétés des documents afin d’optimiser une recherche
 Support de l’indexation géospatiale
 Riak
 Base hybride orientée clé/valeur ou document
En production
 Ebay
Métadonnées de chaque objet vendu
 Expedia
 McAfee
Référentiel central pour la plateforme de détection des menaces
 City of Chicago
Données géospatiales pour gérer toutes les urgences (situation des bus, 911, …)
 Telefonica
 Mariott
 PayPal
 Ryanair
Types
Orientées Colonnes
Orientées Graphes
4. Orienté Graphes (Graph Database)
• Basées sur les théories des graphes

• S'appuie sur les notions de nœuds, 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 inter
connectés,avec un nombre indéterminé de relations entre
elles
• Adapté aux traitements des données des réseaux sociaux
• Exemples : Neo4J et lnfin iteGraph, OrientDB
 Permet de décrire les relations entre des entités

 Modélisation des problématiques spécifiques avec forte connectivité
 Recherche de liens optimaux
 Exemple : matérialiser un réseau d’amis

4. OrientéGraphes (Graph Database)
 Exemple : matérialiser un réseau d’amis en SQL
 2 tables USER, USER_FRIENDS
ID NOM
1 Dupond
2 Durand
3 Richard
4 Ducode
5 Roche
ID FROM_USER TO_USER
1 1 2
2 1 3
3 2 5
4 5 3
5 3 4
 Exemple : matérialiser un réseau d’amis avec Neo4J
 Qui est ami avec DUPOND ?
 Premier niveau
 Second niveau
La subtilité est ici !

 Quels sont tous les amis de Dupond ? (directs et indirects)
 Quelles sont les amitiés de plus de 10 ans ?
 On ajoute des propriétés aux relations
 Quelles sont les amitiés de plus de 10 ans ?
 Et on demande
 Cible
 Représentation de relations, de réseaux, d’organisations
 Avantage
 Algorithmes de la théorie des graphes (chemin le plus court, degré de relation, …)
 Inconvénient
 Parcours complet de la base obligatoire pour avoir une réponse exhaustive
 Implémentations
 Neo4J
Implémentations
 Neo4J
 Titan
 FlockDB
 GraphBase
 InfiniteGraph
En production
 Cisco
 Ebay
Gestion des livraisons
 SFR
 TomTom
 Lufthansa
 Meetic
NOSQL et BDR
Synthèse
• Bases de données NOSQL
• Performances sur de gros volumes de données
• Performances sur des données non structurées
• Evolutivité très importante, même pour de faibles volumes
• Cependant:
• Technologie assez jeune ->Manque d'outils la supportant
• Encore en évolution, pas de standards
• Pas de langage de requêtage commun comme SQL, mais divers:
oRequêtes spécifiques au langage (Java, Python...... )
oRequêtes spéciale pour la base (Cassandra Query language)
oAPI basée sur Map Reduce, ou sur graphes d'objets
• On doit faire plus de travail au niveau du code, ce qui peut influer sur
la performance
NOSQL et BDR
Quand utiliser NOSQL?
• Si I'évolutivité est une préoccupation

• Mais attention, ce n’est pas touJours un MUST: Flicker et
Wikipedia utilisent des RDBMS
• Si l'absence de schéma est une préoccupation
• Si être IN et FASHION est une préoccupation
• Pour un nombre important de personnes, l'utilisation d'un

nouveau paradigme ou technologie est un MUST
HBase
HBase
Généralités
Rafraîchissons notre mémoire

HBase
Généralités
Quelle est la différence entre la mémoires à

accès aléatoire et le disque?
 La mémoire vive (RAM) est une forme de stockage de données qui stocke les
données et le code machine en cours d'utilisation.
 La RAM permet aux éléments de données d'être lus ou écrits au même lapse de temps,
indépendamment de l'emplacement physique des données dans la mémoire.
 En revanche, avec d'autres supports de stockage de données à accès direct, tels que les disques
durs, les CD-RW, les DVD-RW et les anciennes bandes magnétiques, le temps requis pour
lire et écrire des éléments de données varie considérablement en fonction de :
 Leur emplacement physique sur le disque .
 En raison de limitations mécaniques telles que:
• vitesses de rotation des supports
• et le mouvement des bras.
Accès direct ou aléatoire Vs Accès séquentiel
• Avec l'accès séquentiel, les éléments n ° 1, 2 et 3 doivent être traités avant que l'élément n : 4
puisse être traité .
• Avec l'accès direct, l'élément # 4 est accessible sans avoir à traiter les éléments qui le
précèdent.
HBase
Généralités
Accès direct ou aléatoire Vs Accès séquentiel
• Avec l'accès séquentiel, les éléments n ° 1, 2 et 3 doivent être traités avant que l'élément n : 4
puisse être traité .
• Avec l'accès direct, l'élément # 4 est accessible sans avoir à traiter les éléments qui le précèdent.
HBase
Généralités
Accès direct ou aléatoire
L’accès direct ou aléatoire est la capacité d'accéder à n'importe quel

élément de données aussi facilement et efficacement que tout autre, quel
que soit l’emplacement de l'élément.
Par exemple, les données peuvent être stockées dans:
• Une seule séquence, telle qu'une ligne,
• Dans deux dimensions, telles que des lignes et des colonnes sur une
surface,
• Ou dans plusieurs dimensions.
Cependant, étant donné toutes les coordonnées, un programme peut accéder à
chaque enregistrement à peu près aussi rapidement.
HBase
Généralités
Accès séquentiel
 L'accès séquentiel signifie qu’un groupe d'éléments est accédé selon

une séquence ordonnée prédéterminée.
 L’accès séquentiel est parfois le seul moyen d’accéder aux données, par exemple
si elles se trouvent sur une bande.
 Ces applications font partie des bases de données NOSQL qui stockent
d'énormes quantités de données et y accèdent de manière aléatoire
 HBase,
 Cassandra,
 Couch DB
 Dynamo,
 MongoDB
HBase
Pourquoi nous avons besoin de Hbase?
 Dans Hadoop, les données ne seront accessibles que de manière

séquentielle.
 HDFS manque de la capacité de lecture / écriture aléatoire ou directe.
 HDFS ne dispose pas d'un moteur de traitement en mémoire, ce que
ralentisse le processus d'analyse des données.
 À ce stade, une nouvelle solution est nécessaire pour accéder aux
données d’une façon rapide et aléatoire
Hbase
Quand avons-nous besoin de Hbase?
 HBase est le choix idéal pour les applications nécessitant un accès aléatoire
rapide à une grande quantité de données.
 Vous souhaitez stocker des données orientées colonne.
 Vous avez beaucoup de versions des ensembles de données et vous devez
toutes les stocker.
Hbase
Quand avons-nous besoin de Hbase?
-> Here, Hbase est la solution

HBase
C’est quoi Apache HBase?
HBase est un système de gestion de bases de données

distribué, non-relationnel et orienté colonnes,
développé au-dessus du système de fichier HDFS. Il
permet un accès aléatoire en écriture/lecture en
temps réel à un très grand ensemble de données.
HBase
HDFS vs Hbase
• Hdfs est un système de fichier

• Suit l’idéologie écrire une fois et lire plusieurs fois
• Ne supporte pas la lecture/écriture aléatoire ou direct
• HDFS fournit des opérations à latence élevée
• HDFS est accessible via les taches Map Reduce
• Hbase est une base de données NOSQL.
• Stocke les paires clé / valeur en colonnes
• Fournit un accès direct à faible latence
• Accès à de petites quantités de données à partir d'un grand ensemble de
données
• Fournit un modèle de données flexible
HBase
Bases de données orientées lignes ou colonnes
• Les bases de données orientées ligne stockent les enregistrements

de table dans une séquence de lignes.
• Les bases de données orientées colonnes stockent les enregistrements de table

dans une séquences de colonnes, c’est -à-dire que les entrées d'une colonne
sont stockées dans des emplacements contigus ou voisins sur des disques.
• Dans les bases de données orientées lignes, les données sont stockées sous
forme de lignes ou tuple de la manière suivante:
1,Paul Walker, US, 231, Gallardo,2, Vin Diesel, Brazil,520, Mustang
• Les bases de données orientées colonnes stockent ces données sous la forme de
colonne:
1,2,Paul Walker, Vin Diesel ,US, Brazil,231,520, Gallardo, Mustang
HBase
Bases de données orientées lignes ou colonnes
Le traitement transactionnel en ligne, tel que les domaines bancaires et financiers,

qui traitent des données structurées et restreintes et nécessitent des propriétés
transactionnelles, utilise une approche orientée ligne.
Traitement analytique en ligne Nous devons traiter et analyser un large ensemble
de données semi structurées ou non structurées (pétaoctets ou exaoctets) . Nous
utilisons l'approche par colonnes.
 Exploration de données,
 Entreposage de données,
 L’ applications incluant l'analyse, etc.
HBase
Modèle de données
Le modèle se base sur six concepts, qui sont :
•Table :
dans HBase les données sont organisées dans des tables. Les noms des tables sont des
chaînes de caractères.
•Row :
dans chaque table, les données sont organisées dans des lignes. Une ligne est identifiée
par une clé unique (RowKey). La Rowkey n’a pas de type, elle est traitée comme un
tableau d’octets.
•Column Family :
Les données au sein d’une ligne sont regroupées par column family. Chaque ligne de la
table a les mêmes column families, qui peuvent être peuplées ou pas. Les column
families sont définies à la création de la table dans HBase. Les noms des column
families sont des chaînes de caractères.
HBase
Modèle de données
•Column qualifier :
L’accès aux données au sein d’une column family se fait via le column
qualifier ou column. Ce dernier n’est pas spécifié à la création de la table mais plutôt à
l’insertion de la donnée. Comme les rowkeys, le column qualifier n’est pas typé, il est
traité comme un tableau d’octets.
•Cell :
La combinaison du RowKey, de la Column Family ainsi que la Column qualifier identifie
d’une manière unique une cellule. Les données stockées dans une cellule sont appelées
les valeurs de cette cellule. Les valeurs n’ont pas de type, ils sont toujours considérés
comme tableaux d’octets.
•Version :
Les valeurs au sein d’une cellule sont versionnés. Les versions sont identifiés par
leur timestamp (de type long). Le nombre de versions est configuré via la Column Family.
Par défaut, ce nombre est égal à trois.
HBase
Modèle de données
Les données dans HBase

sont stockées sous forme
de HFiles, par colonnes,
dans HDFS.
Chaque HFile se charge de
stocker des données
correspondantes à
une column
family particulière.
HBase
Modèle de données
HBase
Autres caractéristiques de HBase:
• HBase n'a pas de schéma prédéfini, sauf qu'il faut définir les familles
de colonnes à la création des tables, car elles représentent l'organisation
physique des données
• HBase est décrite comme étant un magasin de données clef/valeur, où

la clef est la combinaison (row-column family-column-timestamp)
représente la clef, et la cell représente la valeur.
HBase
Architecture de HBase:
Physiquement, HBase est composé de trois types de serveurs de type

Master/Slave.
•Region Servers: permettent de fournir les données pour lectures et

écritures. Pour accéder aux données, les clients communiquent avec les
RegionServers directement.
•HBase HMaster : gère l'affectation des régions, les opérations de création

et suppression de tables.
•Zookeeper: permet de maintenir le cluster en état.
Le DataNode de Hadoop permet de stocker les données que le Region

Server gère. Toutes les données de HBase sont stockées dans des fichiers
HDFS. Les RegionServers sont colocalisés avec les DataNodes.
Le NameNode permet de maintenir les métadonnées sur tous les blocs

physiques qui forment les fichiers.
HBase
HBase
• Les tables HBase sont divisées horizontalement, par row en

plusieurs Regions. Une region contient toutes les lignes de la table
comprises entre deux clefs données( une région a une taille par défaut de
256 Mo qui peut etre configurée en fonction des besoins) .
• Les regions sont affectées à des noeuds dans le cluster, appelés Region
Servers, qui permettent de servir les données pour la lecture et l'écriture.
• Un region server peut servir jusqu'à 1000 régions.
• Le HBase Master est responsable de coordonner les region servers en

assignant les régions au démarrage, les réassignant en cas de
récupération ou d'équilibrage de charge, et en faisant le monitoring des
instances des region servers dans le cluster. Il permet également de
fournir une interface pour la création, la suppression et la modification
des tables.
• HBase utilise Zookeeper comme service de coordination pour maintenir
l'état du serveur dans le cluster. Zookeeper sait quels serveurs sont actifs
et disponibles, et fournit une notification en cas d'échec d'un serveur.
HBase
Exercice

Chapitre 6 NoSQL

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Chapitre 6 NoSQL

Transféré par

Droits d'auteur :

Formats disponibles

Big Data

• Disponibilité continue des données

• Business Intelligence et Analyse

• Capacités transactionnelles modernes

• Consistance: Si j'écris une donnée dans un nœud et

• De point de vue métier, utiliser un environnement BigData et

• Importance des données:

représentation courante de la structure logique de la table HBase

Clés primaires Valeurs

La grande question sur la vie, l'univers et le reste 42

ExempleCassandra : Colonne / Super Colonne / Famille de Colonnes

• Étendent le paradigme clef/valeur, avec des« documents» plus

• Basées sur les théories des graphes

 Permet de décrire les relations entre des entités

 Exemple : matérialiser un réseau d’amis

La subtilité est ici !

• Si I'évolutivité est une préoccupation

• Si l'absence de schéma est une préoccupation

• Si être IN et FASHION est une préoccupation

• Pour un nombre important de personnes, l'utilisation d'un

Rafraîchissons notre mémoire

Quelle est la différence entre la mémoires à

Accès direct ou aléatoire

L’accès direct ou aléatoire est la capacité d'accéder à n'importe quel

 L'accès séquentiel signifie qu’un groupe d'éléments est accédé selon

 Dans Hadoop, les données ne seront accessibles que de manière

-> Here, Hbase est la solution

HBase est un système de gestion de bases de données

• Hdfs est un système de fichier

• Les bases de données orientées ligne stockent les enregistrements

• Les bases de données orientées colonnes stockent les enregistrements de table

Le traitement transactionnel en ligne, tel que les domaines bancaires et financiers,

Les données dans HBase

• HBase est décrite comme étant un magasin de données clef/valeur, où

Physiquement, HBase est composé de trois types de serveurs de type

•Region Servers: permettent de fournir les données pour lectures et

•HBase HMaster : gère l'affectation des régions, les opérations de création

•Zookeeper: permet de maintenir le cluster en état.

Le DataNode de Hadoop permet de stocker les données que le Region

Le NameNode permet de maintenir les métadonnées sur tous les blocs

• Les tables HBase sont divisées horizontalement, par row en

• Un region server peut servir jusqu'à 1000 régions.

• Le HBase Master est responsable de coordonner les region servers en

Vous aimerez peut-être aussi