2. Sommaire
Ò Présentation NoSQL
Ò DynamoDB
Ò Cas d’utilisation
Ò Architecture
Ò Cas Pratique
Ò Cassandra
Ò Cas d’utilisation
Ò Architecture
Ò Cas Pratique
Ò Conclusion
2
3. Cas d’utilisation
• Technologie relative aux bases de données
Alternatives au SGBD relationnels pour gérer de gros volumes
• Émergence printemps 2009 avec le Cloud Computing et le Web
2.0
BigTable Google, Dynamo Amazon, Hbase Facebook, Cassandra
Twitter
• De nombreuses solutions Open Source
Cassandra, CouchDB, MongoDB, Riak, HBase, … Neo4J
3
5. Les bases Clé Valeur
Clé Valeur
• Implémentations très nombreuses
Clé Valeur
• Structure de données très simple Clé Valeur
• Map
• Base simple à créer
Ò DynamoDB, Redis, Voldemort, MemcacheDB …
5
6. Les bases Colonnes
• Une table est définie par des familles de colonnes
• Chaque famille peut avoir un nombre quelconque de colonnes
• Les colonnes sont représentées par des couples clés-valeur
• Optimisé pour l’accès par colonne
• Représentation plus flexible Famille
• One to many
• Grand nombre de colonnes
• Sparse data Clé Clé Valeur Clé Valeur
Clé Clé Valeur Clé Valeur
Ò HBase, Cassandra, BigTable Clé Clé Valeur Clé Valeur
Colonne
6
7. Les bases Document
• La clé correspond à un document soit Clé
XML soit JSON
Clé Valeur
• Retrouver avec une seule clé un Clé Valeur
ensemble d’informations structurées de
manière hiérarchique Clé Valeur
• L’utilisateur, ses statuts, ses Clé Valeur
amis Clé Valeur
• L’équivalent en relationnel impliquerait Clé Valeur
beaucoup de jointures Clé Valeur
Ò MongoDB, CouchDB Clé Valeur
7
8. Les bases Graphe
• Reposent sur la notion
de nœuds
et de relations
et de propriétés
• Traitement des données de réseaux sociaux
• l’utilisateur, ses amis, les amis de ses amis
• En phase avec les outils du web sémantique (RDF, SparQL)
Ò Neo4J
8
11. SOMMAIRE
Ò PRESENTATION
Ò PRINCIPALES FONCTIONNALITES
Ò DYNAMODB vs. AUTRES SERVICES
Ò ARCHITECTURE
Ò PROVISIONNED THROUGHPUT / CONSISTANCE
Ò API
Ò ELASTIC MAP REDUCE
Ò SECURITE
Ò CAS D’UTILISATION
Ò FACTURE
Ò CONCLUSION
12. PRESENTATION
Ò DynamoDB est la base NoSQL utilisée en interne par
Amazon depuis 2007 et rendue publique le 18 janvier
2012.
Ò DynamoDB est une base orientée clé-valeur.
Ò DynamoDB est une implémentation de Dynamo storage
system et donc peut être comparée à Riak, Redis et
Voldemort.
Ò DynamoDB fait partie des services cloud d’Amazon et est
disponible uniquement en SaaS.
13. PRINCIPALES FONCTIONNALITES
Ò Base de données orientée clé-valeur.
Ò Indexation sur un attribut ou un attribut et un range.
Ò Réplication et haute disponibilité.
Ò Réactivité : < 5ms en lecture, < 10 ms en écriture (disque
SSD)
Ò Map/Reduce.
Ò CloudWatch pour monitorer et affiner les réglages.
Ò Prix en fonction de la consistance des données.
Ò Web Services HTTP et HTTPS + API.
14. DynamoDB vs autres services Amazon
Amazon Relational Database Service (RDS):
Ò AMI de base de données relationnelle Amazon EC2 (MySQL ou
Oracle)
Ò Amazon RDS traite les longues tâches de gestion de base de
données, comme la gestion des corrections, les sauvegardes et
la réplication
15. DynamoDB vs autres services Amazon
Amazon SimpleDB:
Les deux sont des bases non relationnelles sans besoin
d’administration.
Ò SimpleDB est vraiment simplifiée au maximum, l’utilisateur
a très peu de contrôle, limite de stockage de 10Go, toutes les
colonnes sont indexées et une limite dans la capacité de
requêtes pouvant être exécutées.
Ò DynamoDB peut être configurée plus finement, seules les
clés primaires sont indexées et le modèle de prix est plus
clair (nombre de lecture/écriture contre « heure machine »)
16. DynamoDB vs autres services Amazon
Amazon S3 (Simple Storage Service):
Ò A m a z o n D y n a m o D B s t o c k e d e s d o n n é e s
structurées, indexées par clé primaire, et permet une faible
latence pour lire et écrire des items allant de 1 octet à 64Ko.
Ò Amazon S3 stocke des blobs non structurés et est donc
adapté pour stocker des objets de grande taille jusqu'à 5 TB.
17. ARCHITECTURE
Base clé-valeur vs base orientée document :
Ò Une base clé valeur est le modèle le plus simple: une valeur
indexée par une clé.
• limité à la requête par clé et les valeurs sont opaques, le magasin ne
sait rien à leur sujet. Cela permet de très rapide lectures et
écritures (un accès au disque simple)
• c e m o d è l e p e u t ê t r e v u c o m m e u n e s o r t e d e
cache non volatile (c'est à dire bien adapté si vous avez
besoin d’accès rapides par clé aux données).
Ò Une base de données orientée document étend le
modèle précédent et les valeurs sont stockées dans un format
structuré (un document, d'où le nom) que la base de données
peut comprendre. Les requêtes peuvent donc aller plus loin
que la simple clé.
18. ARCHITECTURE
Ò Le modèle de données DynamoDB repose sur des tables,
des items et des attributs.
Ò Une table contient un ensemble d’items composés
d’attributs sous la forme « clé/valeur »
19. ARCHITECTURE
Ò Pas de schema à part la déclaration de clé primaire.
Ò Clé primaire de type hash ou hash et range.
Ò Types de valeur: nombres / chaines de caractères /
ensemble de nombres ou de chaînes.
Ò Un item d’une table a un nombre illimité d’attributs,
mais il y a une limite de taille à 64 KB (somme des tailles
des noms et des valeurs de tous les attributs)
21. PROVISIONNED THROUGHPUT
Ò Sur chaque table il faut définit le «provisionned
throughput» pour permettre à Amazon d’allouer des
ressources matérielles suffisantes.
Ò U n e u n i t é d e W r i t e C a p a c i t y p e r m e t
d'effectuer une écriture par seconde pour des envois
de jusqu'à 1KB.
Ò Une unité de Read Capacity permet d'effectuer une
lecture fortement consistante par seconde (ou deux
finalement cohérentes par seconde) d'articles jusqu'à 1KB.
Expected Item Consistency Desired Reads Provisioned
Size Per Second Throughput
Required
1KB Consistent 50 50
2KB Consistent 50 100
1KB Eventually 50 25
Consistent
2KB Eventually 50 50
Consistent
22. CONSISTANCE
Ò Dépend du provisionned throughput
Ò Ecriture conditionnelle:
Ò Permet de définir des règles de priorités en cas d’accès
concurrents
Ò Overwrite ou mise à jour avant d’écrire
Ò Compteur atomique
23. API
Ò Amazon DynamoDB est un Web Service qui utilise le
protocole HTTP et HTTPS comme transport, et
JSON comme format de sérialisation message.
Ò Accès direct à l’API DynamoDB dans une application. Il
faut alors écrire le code nécessaire pour signer et
authentifier vos demandes.
Ò AWS SDK pour Java, Microsoft. NET, PHP, Android, iOS, et
Ruby.
Ò Les SDKs pour Java and .NET fournissent une API de
persistance pour mapper directement les classes de
l’application sur des tables DynamoDB.
24. API fournies par les SDKs
Ò CreateTable : permet de créer une table et de spécifier
l'index primaire utilisé pour accéder aux données.
Ò UpdateTable : permet de mettre à jour les valeurs du débit
réservé pour une table donnée.
Ò DeleteTable : permet de supprimer une table.
Ò DescribeTables : permet d'obtenir des informations
relatives à la taille, au statut et à l'index de la table.
Ò PutItem / UpdateItem / DeleteItem : opérations
classiques éventuellement conditionnelles
Ò GetItem : opération consistante à terme sinon il faut
utiliser ConsistentRead
Ò BatchGetItem : renvoie les attributs associés à plusieurs
éléments depuis plusieurs tables à l'aide des clés
primaires correspondantes
Ò Query / Scan
25. API: Query et Scan
Ò Query
Une requête ne cherche que les valeurs des clés primaires
et prend en charge un sous-ensemble des opérateurs de
comparaison. Une requête renvoie toutes les données des
items correspondants.
Ò Scan
Une opération de scan parcours l'ensemble de la table.
Il est possible de spécifier des filtres à appliquer aux
résultats pour affiner les valeurs remontées après le
scan complet.
26. ELASTIC MAP REDUCE
Ò Permet d’effectuer en parallèle des calculs sur de gros
volumes de données.
Ò Map: découper les données en sous ensembles
Ò Compute: traiter les sous ensembles séparément
Ò Reduce: Consolider les résultats des sous ensembles
27. ELASTIC MAP REDUCE
L’utilisation d’Elastic Map Reduce sur DynamoDB permet :
Ò Importer/Exporter les données vers et depuis Amazon S3.
Ò Requêter les données en live sur DynamoDB en utilisant
HiveQL (un langage SQL-like pour Hadoop)
Ò Charger des données de DynamoDB sur un Hadoop
Distributed File System
28. SECURITE
Amazon DynamoDB intègre AWS Identity et Access
Management (IAM), un service qui permet de :
Ò Créer des utilisateurs et des groupes sous votre compte
AWS
Ò A t t r i b u e r d e s i n f o r m a t i o n s d ' i d e n t i f i c a t i o n d e
sécurité propres à chaque utilisateur
Ò Gérer le contrôle d'accès aux services et ressources par
utilisateur
Ò Obtenir une seule facture pour tous les utilisateurs sous le
compte AWS
29. CAS D’UTILISATION
Ò Mise en cache de pages wiki (document JSON de toutes les
pages du wiki de DynamoDB, qui représente ~51 GB ).
Ò Quelques raisons d’utiliser une base clés/valeurs:
Ò Quand la vitesse d’écriture est la priorité (Mozilla Test Pilot pour
récupérer le feedback des utilisateurs de Firefox).
Ò Quand la lecture par clé primaire suffit.
Ò Qui utilise DynamoDB:
Ò Amazon
Le panier d'achat et le service de session du site
Ò IMDb
Le système de notation des films
35. CAS D’UTILISATION
Ò Table Tag avec une relation many-to-many:
Ò Clé primaire: name(string)
Ò Attributs: isbns(set of numbers)
Ò Table Book avec une relation many-to-many:
Ò Attributs: tags(set of string)
36. FACTURE
Ò Paiement en l’usage sur 3 critères:
Ò Capacité de débit réservé:
Débit d'écriture : $0,0113 par heure pour 10 unités de capacité d'écriture
Débit de lecture : $0,0113 par heure pour 50 unités de capacité de lecture
Ò Stockage de données indexées:
$1,13 par Go-mois
Ò Transfert de données
Premier 1 Go / mois : $0 par GB
Jusqu'à 10 To / mois : $0,12 par GB
Ò 100 Mo de stockage gratuit et capacité de débit
permanent de 5 écritures/seconde et de 10 lectures/
seconde au maximum offerte par table.
37. FACTURE
Exemple de facturation du site de critique de livres
Ò 4 tables.
Ò 2KB par item et 5000 items
Ò 10 écritures et 20 lectures consistantes par seconde
Ò Prix par table:
Ò Prix du débit par table: 10 x 2 x 0.0113/10 + 20 x 2 x 0.0113/50 =
0.032 $/h
Ò Sur un mois: 0.032 x 24 x 31 = 23.1$
Ò Prix du stockage de 10MB = 0$
Ò Total: 23.1 x 4 – Free Tier = 80.55 $ (hors taxe)
38. CONCLUSION
Ò Flexibilité et évolutivité => scalabilité
Ò Administration et utilisation simple
Ò Monitoring intégré
Ò Intégré aux autres services Amazon
40. Présentation
Ò Créé en 2008 par Facebook, il est depuis 2010 un projet Apache.
Ò Solution de stockage NO-SQL de type « colonne » basée sur un modèle
« clé-valeur » avec 2 niveaux d’imbrication.
Ò Assemblage des technologies Dynamo (Amazon) et BigTable (Google).
Ò Destiné aux applications avec de gros volumes de données fortement
liées demandant une haute disponibilité.
Ò L’architecture Cassandra est composée de nœuds (machines) regroupés
en Clusters (racks) eux même regroupés en DataCenters.
40
41. Cas d’utilisation
Ò Site de location de films, streaming - 288 instances de Cassandra sur
Amazon Web Services (Datacenter nouvelle génération)
Ò Site de microbloging – stockage de + de 50 millions de tweets/jour
Ò Hébergement, solutions de stockage, cloud computing - 3 To/jour
de logs enregistrés dans Cassandra
Ò WebEx – Outil de collaboration On-Demand – Stockage de l’activité
des utilisateurs en direct
Ò Site communautaire de votes sur des pages web intéressantes –
jointures entre tables de centaines de millions de lignes – Trop lent
avec MySQL
Ò Concurrent de Digg – Migration en 10 jours !
Ò …
41
42. Architecture - Data Model
Ò KeySpace : Namespace le plus « haut » dans
l’architecture CASSANDRA. Généralement, un KeySpace
par application
Ò Column Family : Un keyspace contient un ou plusieurs
« Column Family ». Ensemble de colonnes indexées à
l’aide d’une clé. Column Family: EMPLOYE
PRENOM NOM AGE
cdupont
Cédric DUPONT 33
Ò Column : Composé d’un nom, d’une valeur éventuelle et
un timestamp. Le nom d’une colonne peut être une clé
qui référence une valeur d’une autre colonne
42
43. Architecture - Data Model
Nom Prenom Tel Email
1 Dupond Tom d.tom@mail.com
2 Durand Max 0102030405
3 André Pierre
Organisation d’une table dans une base de données relationnelle
1
Nom Dupond Prenom Tom Email d.tom@mail.com
2
Nom Durand Prenom Max Tel 0102030405
3
Nom André Prenom Pierre
Organisation d’un column-family dans une base de données orientée
colonnes
l Pas de Schéma : Stockage de données sans schéma. Un enregistrement
d’une même column-family peut avoir un nombre de colonnes
différent.
43
44. Architecture - Data Model
Ò Super-Column :
Colonne qui Column Family: Client
référence un autre
Ligne: France Telecom
couple clé/valeur.
Une super colonne Super-Colonne: tdupond Super-Colonne: mdurant
ne contient pas de
timestamp. La valeur …
d’une super colonne
est un ensemble de
colonne.
Ligne: Airbus
Ò Super-Column-
Super-Colonne: pandre Super-Colonne: dlarue
Family : Column-
Family dont les
enregistrements sont …
un ensemble de
super-column.
44
45. Architecture - Data Model
Une valeur recherchée doit correspondre à une clé dans un
enregistrement d’un column-family ou d’un super column-
family.
Ø Création de nouveaux Column-Families pour répondre aux différentes
requêtes de l’application.
Ø Redondance de l’information
Ø Toutes les requêtes de l’application doivent être connues à l’avance.
Très optimisé pour les opérations de mise à jour.
Ø Tiré de Google BigTable à une solution de stockage de données
cohérente « log-structured ».
Ø Les mises à jour rapides peuvent être employées pour optimiser les
temps de requêtage.
45
46. Architecture - Répartition des données (Sharding)
Ò Une instance Cassandra = Ensemble de nœuds
Ò Tous les nœuds d’un même cluster sont égaux
Ò Une action de lecture ou d’écriture se fait en se connectant sur
n’importe quel nœud => coordinateur
Ò La répartition, se fait en fonction du « token » définit pour le nœud.
0
# Nœud et son token
Division 4: 76-0 Division 1: 1-25 ByteOrderedPartitioner:
RandomPartitioner:
ordonné avec la valeur de la
position sur le nœud en clé. Bon pour les requêtes
fonction du hashage de la ordonnées
ligne 75 Cluster 1 25
Division 3: 51-75 Division 2: 26-50
50
Exemple de partitionnement des données sur un cluster de 4
nœuds
46
47. Architecture - Réplication des données
Ò Pour des raisons de fiabilité et de tolérance aux erreurs, Cassandra
permet de répliquer les données sur les différents nœuds.
Ò Réplica: 1 copie de ligne
Ò Facteur de réplication = nombre de réplica pour une ligne.
Ò Pas de réplica maître.
Ò Plusieurs stratégies de réplication:
Ò SimpleStrategy
Ò NetworkTopolgyStrategy
47
48. Architecture - Réplication des données
Ò SimpleStrategy: Stratégie par défaut. L’emplacement du 1er réplica est
déterminé par le partitionner et les autres sont placés dans les nœuds
suivant le nœud en court en considérant le token des nœuds.
A1 C3 D2
Nœud
Xy Réplicat
A B
D1 B1
C2 Cluster 1 A2
B3 D3
D C
C1 B2 A3
Exemple de réplication des données sur un cluster de 4 nœuds avec un factor de
réplication à 3
52
49. Architecture - Réplication des données
Ò NetworkTopolgyStrategy:
• Cette stratégie est préférable si la répartition des nœuds dans le Data-
Center est bien connue ou si le cluster regroupe plusieurs Data-
Centers.
• Cela permet de définir le nombre de réplicas pour chaque Data-Center.
• Automatiquement NTS sépare les réplicas sur un maximum de racks
quand c’est possible. Afin d’isoler l’impacte des problèmes physiques
des machines.
1 2 9 10
Rack 1 Rack 1
3 4 11 12
# Nœud Data Center 1 Data Center 2
5 6 13 14
Rack 2 Rack 2
7 8 15 16
Exemple de répartition des nœuds dans 2 Data-Centers
49
50. Architecture - Niveau de consistance
Ò Consistency Level : Permet de contrôler le comportement en lecture et
un écriture.
Ò Se base sur le factor de réplication du schéma.
Ò Revient à définir le nombre de nœuds à bloquer pour la lecture ou pour
l’écriture.
Ò On distingue 6 niveaux principaux:
Niveau
ANY
ONE
QUORUM
LOCAL_QUORUM
EACH_QUORUM
ALL
Ò Le niveau « QUORUM » est le plus utilisé car il permet une bonne
disponibilité des données en gardant une bonne consistance.
50
51. Architecture - Niveau de consistance
Write ANY (N=3) => tolérance la plus haute
Réplica
Down
Requête Ecriture Réplica
Insert Toujours OK Nœud pilote Ecriture Down
Hint
*
Réplica
Down
Nouvelle Tentative
Perte définitive si > 60 minutes
*Seulement si Hinted Handoff 51
activé
52. Architecture - Niveau de consistance
Write ALL(N=3) => consistance la plus haute
Réplica
Requête Ecriture
Nœud pilote Ecriture
Réplica
Insert
OK OK
Réplica
52
53. Architecture - Niveau de consistance
Write QUORUM (N=3): Q = N/2 +1 = 2
Réplica
Requête Ecriture
Nœud pilote Ecriture
Réplica
Insert
OK OK
Réplica
Down
53
54. Architecture - Niveau de consistance
3 fonctionnalités pour garantir la consistance:
Ò Hinted Handoff: l’écriture est envoyée à tous les réplicas, si un ou plusieurs
sont indisponibles l’ordre est conservé (paramétrable dans le temps) par le
coordinateur le temps que le réplica soit à nouveau disponible.
Ò Read and repair: permet à un nœud
de vérifier que sa donnée est autant à
jour que les autres réplicas. Déclenché
quand le réplica n’est pas élu par une
requête. Efficace pour les données
accédées régulièrement
Ò Anti entropy node repair: Même fonctionnalité que le read repair mais sous forme
de script d’entretien pour les données accédées rarement donc rarement éligible au
read and repair
54
56. Cas pratiques – Montée en Charge (Scalabilité)
Ò Le débit en écriture et en lecture augmente linéairement au fur et à
mesure que de nouvelles machines sont ajoutées sans temps
d’interruption et sans reconfiguration des applications. Il est très simple
d’ajouter un noeud (machine)
Ò Installer Cassandra sur la machine
Ò Mettre la propriété autobootStrap à true
Ò Renseigner l’ip d’un noeud du cluster
Ò Démarrer le noeud.
Ò Cassandra peut tolérer un plantage de plusieurs nœuds du cluster sans
engendrer des pertes de performances ni d’interruptions de service. Il
utilise un outil de détection de pannes pour savoir si un nœud est « up »
ou « down ».
56
57. Cas pratiques - Client / API
Ò Cassandra-cli : Outil ligne de commande fourni par Cassandra
permettant d’interroger l’espace de stockage. Toutes les opérations de
bases sont prévues:
Ò Requetage (get, list)
Ò Création, Modification, Suppression d’objets de lignes, colonnes
et Column-Family
Ò Administration:
• Keyspace
• Niveau de consistance
Ò CQL (Cassandra Query Language) : Est apparu à partir de la V0.8 pour
harmoniser la manières d’attaquer Cassandra avec tous les langages.
Basé sur la syntaxe SQL. Hector en est l’implémentation Java
Ò Object Mapping: Hector (Java), Pycassa (Python), PhpCassa(PHP).
Ò OPSCenter: Outil de management et monitoring
57
59. Conclusion - Dangers / Critiques
Ò Consistance. Forte réflexion à mener afin de déterminer le niveau souhaité pour
chaque requête.
Ò No ACID
Ò Atomic (Tout fonctionne ou non)
L’atomicité chez Cassandra et garantie au niveau ligne, c’est tout.
Ò Consistent (état consistant après la transaction)
Dépend du Niveau de consistance choisi.
Le read & repair met à jour les nœuds en retard (qui était en erreur au moment
clé)
Ò Isolated (pas d’interaction entre les transactions)
L’accès concurrent en mise à jour sur une ligne ne pose pas de problème, le
timestamp le plus récent remporte la mise à jour.
Ò Durable (persistent dans le temps)
Dépend du niveau de consistance choisi.
59
60. Conclusion
Ò Pourquoi Cassandra?
Ò Montée en charge linéaire = Stockage de données illimité
Ò Scalabilité aisée à chaud
Ò Pas de point unique de défaillance = Très haute disponibilité
Ò La meilleure logique de distributivité
Ò OpenSource
Ò Maturité
Ò La version actuelle de Cassandra est v1.1.0. C’est une version mature
qui est déjà exploitée en production par de grands « noms »: Netflix,
Twitter, Rackspace, Cisco
Ò Communauté importante
60