NoSQL
Jean-Philippe Barbé & Mathieu Cousy Senior Consultant Valtech Toulouse
Sommaire
Ò Présentation NoSQL Ò DynamoDB
Ò Cas d’utilisation Ò Architecture Ò Cas Pratique
Ò Cassandra Ò Cas d’utilisation Ò Architecture Ò Cas Pratique
Ò Conclusion
2
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
• De nombreuses solutions Open Source Cassandra, CouchDB, MongoDB, Riak, HBase, … Neo4J
3
L’écosystème NoSQL
Clé Valeur
Document Colonne
Graphe
4
Les bases Clé Valeur
• Implémentations très nombreuses
• Structure de données très simple • Map
• Base simple à créer
Ò DynamoDB, Redis, Voldemort, MemcacheDB …
Clé Valeur Clé Valeur Clé Valeur
5
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 • One to many • Grand nombre de colonnes • Sparse data
Ò HBase, Cassandra, BigTable
Clé Valeur Clé Valeur Clé Valeur
Clé Clé Clé
Valeur Valeur Valeur
Clé Clé Clé
Famille
Colonne
6
Les bases Document
• La clé correspond à un document soit XML soit JSON
• Retrouver avec une seule clé un ensemble d’informations structurées de manière hiérarchique
• L’utilisateur, ses statuts, ses amis
• L’équivalent en relationnel impliquerait beaucoup de jointures
Ò MongoDB, CouchDB
Clé
Valeur
Valeur
Valeur
Clé
Clé
Clé
Valeur
Valeur
Valeur
Clé
Clé
Clé
Valeur Clé
Valeur Clé
7
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
Le CAP Theorem (Eric Brewer)
9
NoSQL
Amazon DynamoDB
SOMMAIRE
Ò PRESENTATION Ò PRINCIPALES FONCTIONNALITES Ò DYNAMODB vs. AUTRES SERVICES Ò ARCHITECTURE Ò PROVISIONNED THROUGHPUT / CONSISTANCE Ò API Ò ELASTIC MAP REDUCE Ò SECURITE Ò CAS D’UTILISATION Ò FACTURE Ò CONCLUSION
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.
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.
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
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 »)
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.
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é.
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 »
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)
Le CAP Theorem (Eric Brewer)
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 Size
Consistency Desired Reads Per Second
Provisioned Throughput Required
1KB Consistent 50 50
2KB Consistent 50 100
1KB Eventually Consistent
50 25
2KB Eventually Consistent
50 50
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
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.
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
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.
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
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
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
Ò Attribuer des informations d' identif ication de 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
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
CAS D’UTILISATION
Ò Exemple d’un site de critiques de livres
CAS D’UTILISATION
Ò Table Book: Ò Clé primaire: isbn(number) Ò Attributs: title(string), author(string), pages(number)
Ò Table Thread: Ò Clé primaire: subject(string) Ò Attributs: isbns(set of numbers), author(string),
content(string)
Ò Table Reply: Ò Clé primaire range: isbn + subject(string) et date (datetime) Ò Attributs: author(string), reply(string)
CAS D’UTILISATION
CAS D’UTILISATION
CAS D’UTILISATION
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)
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.
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)
CONCLUSION
Ò Flexibilité et évolutivité => scalabilité Ò Administration et utilisation simple Ò Monitoring intégré Ò Intégré aux autres services Amazon
NO-SQL
La solution grand format
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
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
Column Family: EMPLOYE
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 : 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
cdupont PRENOM
Cédric DUPONT
NOM
33
AGE
Organisation d’un column-family dans une base de données orientée colonnes
Organisation d’une table dans une base de données relationnelle
43
Nom Prenom Tel Email
1 Dupond Tom [email protected]
2 Durand Max 0102030405
3 André Pierre
1
2
3
Nom Dupond Prenom Tom Email [email protected]
Nom Durand Prenom Max Tel 0102030405
Nom André Prenom Pierre
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.
Architecture - Data Model
44
Column Family: Client
Ligne: France Telecom Super-Colonne: tdupond Super-Colonne: mdurant
…
Ligne: Airbus Super-Colonne: pandre Super-Colonne: dlarue
…
Ò Super-Column : Colonne qui référence un autre couple clé/valeur. Une super colonne ne contient pas de timestamp. La valeur d’une super colonne est un ensemble de colonne.
Ò Super-Column-
Family : Column-Family dont les enregistrements sont un ensemble de super-column.
Architecture - Data Model
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.
45
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.
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.
46
# Nœud et son token
Exemple de partitionnement des données sur un cluster de 4 nœuds
Cluster 1
0
25
50
75
Division 1: 1-25
Division 2: 26-50 Division 3: 51-75
Division 4: 76-0 RandomPartitioner:
position sur le nœud en fonction du hashage de la
ligne
ByteOrderedPartitioner: ordonné avec la valeur de la clé. Bon pour les requêtes
ordonnées
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
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.
Nœud
Exemple de réplication des données sur un cluster de 4 nœuds avec un factor de réplication à 3
Cluster 1
B
C D
A
A1
A2
A3
B1
B2
B3
C1
C2
C3
D1
D2
D3
Xy Réplicat
52
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.
49
Data Center 1
Rack 1 1 2
3 4
Rack 2 5 6
7 8
Data Center 2
Rack 1 9 10
11 12
Rack 2 13 14
15 16
# Nœud
Exemple de répartition des nœuds dans 2 Data-Centers
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:
50
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.
Architecture - Niveau de consistance
51
Write ANY (N=3) => tolérance la plus haute
Nœud pilote
Réplica Down
Réplica Down
Réplica Down
Ecriture
Nouvelle Tentative Perte définitive si > 60 minutes
Requête Insert
Ecriture
Toujours OK Hint*
*Seulement si Hinted Handoff activé
Architecture - Niveau de consistance
52
Write ALL(N=3) => consistance la plus haute
Nœud pilote
Réplica
Réplica
Réplica
Ecriture Requête Insert
Ecriture
OK OK
53
Architecture - Niveau de consistance
Write QUORUM (N=3): Q = N/2 +1 = 2
Nœud pilote
Réplica
Réplica Ecriture Requête Insert
Ecriture
OK OK
Réplica Down
Architecture - Niveau de 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.
54
3 fonctionnalités pour garantir la consistance:
Ò 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
Le CAP Theorem (Eric Brewer)
55
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
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
DataStax - OPSCENTER
58
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
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
Conclusion NO-SQL
Big Data
Architecture 2.0
62
Big Data ROI
Coût faible Gros Volume
Haute Disponibilité
63
QUESTIONS
64
Big Data
65