Modèle colonne

▪ Principes
▪ HBase
▪ Cassandra

©Maude Manouvrier - Univ. Paris-Dauphine 340

 Base de données colonnes
▪ Proches des bases de données relationnelles
▪ Données logiquement structurées en tables, lignes et colonnes
▪ Nombre de colonnes dynamique et pouvant varier d’un
enregistrement à un autre
▪ Pas de stockage des valeurs NULL
▪ Stockage uniquement des données avec de valeurs
▪ Suit l’approche BigTable apportée par Google dont HBase est une
implémentation open source

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 341

 Colonnes et familles de colonnes
▪ Colonne
• Couple clé/valeur
• Représentation d’un champ de données
• Super Colonne : colonne contenant d’autres colonnes
▪ Famille de colonnes
• Regroupement de plusieurs colonnes ou super-colonnes
• Colonnes sont regroupées en lignes
• Identifiant unique pour chaque ligne

©Maude Manouvrier - Univ. Paris Dauphine - Adapté de de [Link]/rchiky/nosql/[Link] et de [Link] 342

 Base de données colonnes : cas d’utilisation
▪ Cas d’utilisation :
• Journalisation d’évènements ou comptage et catégorisation des visiteurs d’une page
web
• Utile pour les données éparses
• Utile pour les tâches d’analyses sur des colonnes et dans les traitements massifs (via
des opérations de MapReduce)
▪ Non applicable aux:
• Applications avec des besoins de transactions ACID
• Données interconnectés (distance, trajectoire)
• Agrégation (effectuée par l’application client)

©Maude Manouvrier - Univ. Paris Dauphine - Adapté de [Link]/rchiky/nosql/[Link] 343

 Principaux moteurs orientés colonne

©Maude Manouvrier - Univ. Paris-Dauphine - [Link] 344

 BigTable
▪ Base de données propriétaire gérée en interne chez Google
▪ Accessible au public uniquement via Google App Engine
▪ Ecrite en C++
▪ Cohérence forte (strong consistency)
▪ Stockage de données basé sur le système de fichiers distribués GFS
(Google File Systems)
▪ Site officiel : [Link]
▪ Article d’origine : [Link]
[Link]

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link]/rchiky/nosql/[Link] 345

 BigTable : concepts de base

▪ Map multi-dimensionnelle
▪ Row key : clé unique d'une entité (string de 64KB)
▪ Column family : groupe d'attributs (colonnes) reliés
▪ Column : comporte différentes versions de la donnée (ordonnées par
timestamp décroissant)
▪ Accès à une donnée : Row key → column family → column →
timestamp

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link]/rchiky/nosql/[Link] 346

 BigTable : modèle de données (clés et estampilles)

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 347

 BigTable : modèle de données (famille de colonnes et qualifier)

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 348

 HBase

▪ Implémentation libre du moteur BigTable de Google

▪ Partie du projet Hadoop de Apache
▪ Écrit en Java
▪ Architecture Maître/Esclave
▪ Utilise HDFS (Hadoop Distributed File System) et
ZooKeeper (système open-source de synchronisation et de
coordination des systèmes distribués)

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 349

 HBase : liens utiles

▪ Site officiel : [Link]

▪ Tutoriels et cours en ligne :
• [Link]
travailler-hbase
• [Link]
• [Link]
hbase?autoplay=true&u=74606242

©Maude Manouvrier - Univ. Paris Dauphine 350

 Hbase : Architecture
Stockage de chaque famille de colonnes dans un HFile

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 351

 Hbase : Modèle de données

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 352

 Hbase : Exemple de table

▪ 2 familles : Personnel (de colonnes Prénom et Age) et Contact (de colonnes Téléphone et Ville)
▪ Pour la clé 0001 : 3 versions (suite au changement d'âge et de ville du contact)
©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 353
 Hbase : Modèle de données

Stockage des
données sous forme
de HFiles, par
colonnes, dans
HDFS.

une column
family particulière
par HFile

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 354

 Hbase : gestion des données
▪ Plusieurs étapes d’écriture :
• Ecriture dans un WAL (Write-Ahead Log)
• Placement des données dans un buffer nommé memstore
▪ Memstore écrit dans un HFile sur le HDFS lorsque trop gros
▪ Suppression :
• Gérées à l’aide d’un marqueur tombstone
• Réelle au moment d’un compactage

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 355

 Hbase : HMaster et RegionServers
▪ HMaster : nœud maître
▪ RegionsServers : nœuds esclaves
▪ Stockage des données distribué sur
les RegionsServers gérés par le
Hmaster
▪ Tables HBase rendues persistantes
sur le disque sous forme de fichiers
HDFS appelés HFiles

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 356

 Hbase : partition d’une table

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 357

Hbase : que se passe-t-il lors d’une
demande de données ?

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 358

 Hbase : Les bonnes questions à se poser pour la
modélisation
▪ 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-elle historiser ?
©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 359
 Hbase : "Best practices" pour la modélisation
▪ Regrouper les colonnes utilisées selon le même schéma dans la même
famille de colonnes
▪ Limiter autant que possible à 10 ou 15 le nombre de familles de
colonnes par table
▪ Donner le nom de toutes les colonnes à la création de la table même si
les colonnes elles-mêmes n'existent pas encore
▪ Dénormaliser au maximum les tables modélisées

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 360

 Hbase : opérations CRUD (création d’une table)
Création d’une nouvelle table : commande create

©Maude Manouvrier - Univ. Paris Dauphine - - Repris de [Link] 361

 Hbase : opérations CRUD (get et put)
▪ get : équivalent à SELECT en SQL
▪ put : équivalent à INSERT en SQL

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 362

 Hbase : exemples de get et put

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 363

 Hbase : opérations CRUD (scan et delete)
▪ scan : lecture séquentielle
▪ delete : équivalent à DELETE en SQL mais création par HBase de
marqueurs sur chaque valeur à supprimer et suppression de celles-ci
massivement lorsqu'HBase effectue un compactage de la table
▪ Possibilité d’utiliser un langage d'abstraction comme HiveQL ou Pig
Latin, pour créer et manipuler les tables HBase

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 364

 HBase : avantages et inconvénients
▪ Tolérance aux pannes
▪ Gestion de gros volumes de données
▪ Ecosystème Hadoop

▪ Pas de support pour les jointures (à faire au niveau applicatif)

▪ Single-row ACID
▪ Ecosystème Hadoop

©Maude Manouvrier - Univ. Paris Dauphine 365

 HBase vs relationnel

©Maude Manouvrier - Univ. Paris Dauphine – repris de [Link] 366

 Cassandra
▪ Conçu à l’origine par Facebook
▪ Actuellement projet de la fondation Apache (2008)
▪ Distribué par la société Datastax
▪ Initialement basé sur le système BigTable de Google (stockage orienté
colonnes)
▪ Maintenant basé sur le système DynamoDB (hachage) ⇒ stockage
orienté ”clé/valeur”
▪ Un des rares systèmes NoSQL à proposer un typage fort
▪ Ecrit en Java
©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 367
 Cassandra : modèle relationnel étendu
▪ Evolution vers un modèle relationnel étendu
▪ Langage d’interrogation : Cassandra Query Language (CQL)
▪ Pas d'architecture maître/esclave – Architecture pair à pair
▪ Système scalable et distribué :
• Méthodes de passage à l’échelle inspirées du système Dynamo
(Amazon)
• Distribution par hachage (consistent hashing)
• Tolérance aux pannes par réplication en mode multi-nœuds
• Cohérence réglable (tunable consistency)
©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] et Repris de [Link] 368
 Cassandra : liens utiles
▪ Site officiel : [Link]
▪ Documentation en ligne :
[Link]

▪ Version entreprise : Datasax AstraDB (multi-cloud DBaaS based on Apache

Cassandra) [Link]
▪ Cours en ligne :
• [Link]
• [Link]
• [Link]
• [Link]
©Maude Manouvrier - Univ. Paris Dauphine 369
 Cassandra : modèle de données
▪ Bases de données : Keyspace
▪ Tables : Table ou Column Family (lignes organisées en partition)
▪ Partition : regroupement de lignes stockées sur le même nœud
▪ Lignes : Row (valeurs simples ou complexes)
▪ Relationnel étendu en rompant la première règle de normalisation (type
atomique).
▪ Ligne (row) : document structuré (imbrication) avec identifiant (row key) associé
à un ensemble de paires (clé, valeur).
▪ Lignes typées par un schéma, y compris les données imbriquées
▪ Pas d’insertion de données ne respectant pas le schéma

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] et Repris de [Link] 370
 Cassandra : nombre de colonnes flexible

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 371

 Cassandra : clé de partition

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 372

 Cassandra : répartition des données selon la clé de
partition

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 373

 Cassandra : exemple de table

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 374

 Cassandra : pas de stockage des valeurs null

Affiché null sous cqlsh

Ce qui est réellement stocké :

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 375

 Cassandra : principes
▪ Pas de jointure : duplication
▪ Dénormalisation et possibilité de gérer des vues matérialisées au dessus d’une
même table
▪ Pas d’intégrité référentielle (pas de clé étrangère)
▪ Modélisation orientée requêtes (Query-first design)
▪ Prise en compte du stockage : stockage de chaque table dans un fichier séparé –
nécessité de conserver les colonnes allant ensemble au sein d’une même table et
de minimiser le nombre de partitions
▪ Pas de requête de tri – gestion du tri par l’ordre ascendant ou descendant des clés
de regroupement (clustering columns)

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 376

 Cassandra : dénormalisation
▪ Jointures inexistante  dénormalisation du modèle
▪ Regrouper des données le plus possible dans des lignes
▪ Conception orientée sur les requêtes les plus fréquentes de
l’application
▪ Dimension la plus grande souvent favorisée (meilleure distribution)
!▪  redondance et possibilités d’incohérence

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 377

 Cassandra : exemple de dénormalisation
Jointures inexistante  dénormalisation du modèle

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 378

 Cassandra : une table par requête
Jointures inexistante  dénormalisation du modèle

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 379

 Cassandra : exemple de la documentation

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 380

 Cassandra : modèle relationnel de l’exemple de la
documentation

Modèle relationnel
orienté donnée

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 381

 Cassandra : Modèle orienté par les requêtes (1/3)

Chebotko logical diagram

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 382
 Cassandra : Modèle orienté par les requêtes (2/3)

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 383

 Cassandra : Modèle orienté par les requêtes (3/3)

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 384

 Cassandra : langage CQL (création)

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 385

 Cassandra : langage CQL (insertion)

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 386

 Cassandra : langage CQL (sélection)

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 387

 Cassandra : langage CQL (utilisation des estampilles)
▪ Toute valeur est associée à un TIMESTAMP
▪ Estampillage automatique (ms) lors de la mise à jour
▪ Possible de spécifier l’estampille dans les requêtes

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 388

 Cassandra : exemples de requêtes CQL

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 389

 Cassandra : Exemple (1/5)

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 390

 Cassandra : Exemple (2/5)
On ne souhaite pas faire des requêtes sur les utilisateurs mais on souhaite :
▪ Connaître les vidéos insérées par un utilisateur dont on connaît le login
▪ Accéder à toutes les informations d’une vidéo
▪ Connaître les commentaires par vidéo et par utilisateur

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 391

 Cassandra : Exemple (3/5)

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 392

 Cassandra : Exemple (4/5)

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 393

 Cassandra : Exemple (5/5)

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 394

 Cassandra : Clé de partition et de regroupement
Table avec une clé de partition à 1 attribut Table avec une clé de partition à 2 attributs

Table avec une clé de partition à 1 attribut Table avec une clé de partition à 2 attributs
et une clé de regroupement à 2 attributs et une clé de regroupement à 2 attributs

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 395

 Cassandra : attributs complexes
Pour un attribut peut être associé à un type complexe :
▪ SET : ensemble valeurs (non ordonnées)
▪ LIST : liste de valeurs (ordonnées)
▪ MAP : hashMap clé/valeur
▪ SubType : ligne imbriquée

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 396

 Cassandra : attribut de type SET

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 397

 Cassandra : attribut de type LIST

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 398

 Cassandra : attribut de type MAP

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 399

 Cassandra : attribut d’un type imbriqué

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 400

 Cassandra : architecture
▪ Base de donnée contenue dans un cluster ou ensemble de data-centers (ensemble
de nœuds qui sont dans un environnement géographique proche)
▪ Données réparties sur plusieurs nœuds et éventuellement répliquées sur 1 à N
nœuds
▪ Possibilité pour un utilisateur de se connecter sur n'importe quel nœud et accéder
à l'ensemble des données.

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 401

 Cassandra : memtable, commitlog et SSTable

(pour assurer Sorted String Table

de la durabilité)

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 402

 Cassandra : contenu d’un nœud

©Maude Manouvrier - Univ. Paris Dauphine - - Repris de [Link] 403

 Cassandra : nœud coordinateur

©Maude Manouvrier - Univ. Paris Dauphine - - Repris de [Link] 404

 Cassandra : cohérence
▪ Extension de la notion de cohérence éventuelle à une cohérence ajustable
▪ Choix du niveau de cohérence défini par requête : clause USING CONSISTENCY
(niveau ONE par défaut)
▪ Ecriture :
• Niveau ONE : écriture effectuée sur au moins un nœud
• Niveau ALL : écriture effectuée sur tous les N nœuds (avec N=ReplicationFactor)
• Niveau QUORUM : écriture effectuée sur M nœuds (avec M=|ReplicationFactor/ 2| + 1)
▪ Lecture :
• Niveau ONE : enregistrement retourné par le premier nœud qui répond
• Niveau ALL : Requête sur tous les nœuds et sélection de l'enregistrement avec
l’estampille (timestamp)la plus récente (Si un nœud ne répond pas, l'opération échoue)
• Niveau QUORUM :Requête sur M nœuds et sélection de l'enregistrement avec le
l’estampille (timestamp) la plus récents retournée par la majorité des nœuds

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link]/rchiky/nosql/[Link] 405

Cassandra : niveau de cohérence ONE en écriture avec
un facteur de réplication de 3

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 406

 Cassandra : niveau de cohérence QUORUM en écriture avec
un facteur de réplication de 2

M=|ReplicationFactor/ 2| + 1 = 2

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 407

 Cassandra : niveau de cohérence QUORUM
Exemple d’échec en écriture avec un facteur de rép. de 2

M=|ReplicationFactor/ 2| + 1 = 2

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 408

 Cassandra niveau de cohérence QUORUM en écriture avec
un facteur de réplication de 3

M=|ReplicationFactor/ 2| + 1 = 2

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 409

 Cassandra : niveau de cohérence QUORUM
Exemple d’échec en écriture avec un facteur de rép. de 3

M=|ReplicationFactor/ 2| + 1 = 2

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 410

 Cassandra niveau de cohérence ALL en écriture avec
un facteur de réplication de 3

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 411

 Cassandra : niveau de cohérence ALL
Exemple d’échec en écriture avec un facteur de rép. de 3

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 412

 Cassandra : niveau de cohérence ONE en lecture avec un
facteur de réplication de 3 - lecture sur n’importe quel nœud

Le client ne sait
où la donnée
sera lue.

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 413

 Cassandra : niveau de cohérence ONE en lecture
avec un facteur de réplication de 3 – possibilité de
« réparer » la lecture

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 414

 Cassandra : niveau de cohérence ONE en lecture avec
un facteur de réplication de 3 – réussite même en cas de
panne d’un ou plusieurs nœuds

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 415

 Cassandra : niveau de cohérence QUORUM en
lecture avec un facteur de réplication de 3

M=|ReplicationFactor/ 2| + 1 = 2

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 416

 Cassandra : niveau de cohérence ALL en lecture
avec un facteur de réplication de 3

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 417

 Cassandra : niveau de cohérence ALL en lecture Exemple
d’échec en écriture avec un facteur de rép. de 3

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 418

 Cassandra : Moduler le niveau de cohérence
Exemple avec un facteur de réplication de 3

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link] 419

 Cassandra : conclusion
▪ Rapidité d’écriture
▪ Haute performance, Décentralisation, Support de réplication
▪ Cohérence réglable

▪ Performances de lecture dépendant du modèles de données

▪ Pas d'intégrité référentielle
▪ Limitation des tailles des colonnes et des super-colonnes

©Maude Manouvrier - Univ. Paris Dauphine - Repris de [Link]/rchiky/nosql/[Link] et de [Link] 420

 Exemple
d’applications
polyglottes
utilisant
Cassandra et
Redis

©Maude Manouvrier - Univ. Paris Dauphine – repris de [Link] 421