PrezFlash :: NoSQL Jérôme Mainaud 19 juillet 2011 1 1 1

« NoSQL is like sex for teenagers: everybody is talking about it but few have actually gone for it. » Emmanuel Bernard — 2011

Il était une fois SQL

Modèle de données relationnel Panier PAN_ID CLI_ID DATE MONTANT_TOTAL TVA Client CLI_ID NOM ADRESSE CLI_ID PAN_ID Article PAN_ID CMD_ID QUANTITE PRIX_UNITAIRE

Un langage de requête plus ou moins normé SQL Un langage de requête plus ou moins normé Tout information est décrite par des listes de n-uplets Opérations puissante Sélection (where) Projection (select) Produit cartésien (join) Union Intersection Différence

Transactions ACID Pas de modification partielle Atomic (Atomique) A la fin de la transaction, les données doivent être dans un état cohérent. Assuré par les contraintes d’intégrités mais aussi et surtout par le développeur Consistant (Cohérent) Les modifications d’une transaction ne sont pas visibles par les autres tant qu’elle n’a pas été validée. Isolées Une fois validés, les données sont permanentes jusqu’à leur prochaine modification Durable

Utilisé depuis des dizaines d’années Marché mature Utilisé depuis des dizaines d’années De nombreux fournisseurs et de nombreux outils Oracle SQL Server Mysql Postgresql MariaDB (clone de Mysql) MS Access

Bases de données relationnelles Modèle Entités - relation Simple Universel Requête SQL Puissant Ad-hoc Transaction ACID Maturité Utilisé massivement Nombreux moteurs sur le marché Nombreux outils Utilisé mais pas choisi

Mise en œuvre d’un SGBD-R Base de données Serveur Applicatif HTTP JDBC

Mise en œuvre d’un SGBD-R Serveurs Applicatifs Base de données HTTP JDBC

Mise en œuvre d’un SGBD-R Base de données Serveurs Applicatifs HTTP JDBC

Mise en œuvre d’un SGBD-R Serveurs Applicatifs Base de données JDBC HTTP

Montée en charge difficile Les règles d’intégrité compliquent la montée horizontale Montée en charge verticale Coût non linéaire Atteint une limite Point unique de défaillance

Coût des transactions ACID La lecture est éparpillée Lecture d’un panier de N articles 2 requêtes 2 IO pour lire le panier N+1 IO pour les articles L’écriture est lente IO synchronisés La durée d’une requête est difficile à prévoir Select * from t where id = ? Select * from t where date < (select max(date) from ot)

Le modèle Entité Relation peu exploité Le modèle Entité-Relation est souvent peu exploité Utilisation du CRUD Utilisation de caches Memcache Ehcache Correspondance ORM C’est le modèle objet qui est privilégié

Repenser les bases de données Not oNLY SQL

Montée en charge linéaire Deux critères Volume des données Nombre de requêtes Twitter Janvier 2010 : 50 M/j Juin 2011 : 200 M/j Le coût doit augmenter linéairement

Performances — temps d’accès Mémoire 10 ns Réseau local 50 µs Disque 10 ms Il est plus rapide d’interroger une autre machine que de lire sur le disque local

Performances prédictibles La performance des opérations doit être prédictible Amazon: Perte de 1 % de chiffre d’affaire si le temps d’affichage des pages augmente de 0,1 s Plan qualité interne : Temps de réponse doit être < 300 ms pour 99,9 % des requêtes pour un pic de 500 requêtes par secondes Google pénalise les sites dont les pages s’affichent en plus de 1,5 s

Prise en compte des pannes La panne est la règle Amazon: Un datacenter de 100 000 disques entre 6 000 et 10 000 disques en panne par an (25 disques par jour) Les sources de panne sont nombreuses Matériel serveur (disque) Matériel réseau Alimentation électrique Anomalies logicielles Mises à jour des logiciels et des OS.

CAP Consistency (Cohérence) Après la modification d’une donnée, tous les clients lisent la nouvelle valeur. Avalibility (Disponibilité) Le système répond toujours aux requêtes dans un temps borné (timeout)) Partition Tolerance (Tolérance aux pannes) Le système continue à fonctionner si le réseau qui relie les nœuds est scindé en deux. La chute d’un nœud est une forme particulière de partition.

« You can have at most two of these properties for any sharded-data system. » Eric A. Brewer — 19 juillet 2000 Théorème CAP

Théorème CAP Bases distribuées Verrous distribués Oracle RAC Verrou pessimiste La partition minoritaire est indisponible Oracle RAC LDAP Commit à 2 phases Cache validation DNS Cache Web Expiration Résolution de conflit Verrou optimiste

Théorème CAP — Démonstration par l’exemple Nœud 1 Client A Version 1 Nœud 2 Client B Version 1

Théorème CAP — Démonstration par l’exemple Nœud 1 Client A Version 1 MAJ 1  2 Nœud 2 Client B Version 1

Théorème CAP — Démonstration par l’exemple Nœud 1 Client A Version 2 MAJ 1  2 Nœud 2 Client B Version 1

Théorème CAP — Démonstration par l’exemple Nœud 1 Client A Version 2 Lit version 2 Nœud 2 Client B Version 2

Théorème CAP — Démonstration par l’exemple Nœud 1 Client A Version 1 MAJ 1  2 Nœud 2 Client B Version 1

Théorème CAP — Démonstration par l’exemple Nœud 1 Client A Version 2 MAJ 1  2 Perte du message Nœud 2 Client B Version 1

Théorème CAP — Démonstration par l’exemple Perte de message détectée L’écriture échoue CP Attente et rejeu jusqu’à ce que le message soit transmis Réponse potentiellement trop tardive AP Validation de l’écriture État incohérent

Lors qu’un client clique sur le bouton « acheter » Faut-il ? Le choix d’Amazon Assurer la cohérence entre les serveurs Ajouter l’article dans le panier et assurer la vente Lors qu’un client clique sur le bouton « acheter » Faut-il ?

Cohérence à terme Continuum ACID Cohérence forte Isolation Transactions Verrous pessimistes Schéma Évolutions difficiles BASE Basicaly-Available Soft-state Eventual consistency Cohérence faible Procédure de réconciliation Favorise la disponibilité Rapide Pas de schéma Évolutions faciles Continuum

Cohérence par Quorum V2 V1 V1 Client A N réplicas V1 Client B V1 V1

N réplicas Cohérence par Quorum Le client attend E OK pour valider l’écriture V2 OK V2 Client A OK N réplicas V2 OK Client B V? V?

N réplicas Cohérence par Quorum Le client B lit L valeurs V2 V2 Client A N réplicas V2 Client B V? V? Si E + L > N la lecture est cohérente avec l’écriture

Architecture décentralisée A,B,C Client A W,X,Y,Z D,E,F GOSSIP T,U,V G,H,I J,K,L P,Q,R,S Client B M,N,O

Traiter les données Map-Reduce

Map-Reduce Technique de traitement des données de grandes tailles Acteurs réputés: Google Hadoop CouchDB MongoDB (C1V1) Map (K2V2) Input Sort (K2[V2 V2’]) Reduce (K3V3) Traitement local Traitement global

Repenser les bases de données Modèles de données

Entités-relation Panier Client PAN_ID CLI_ID CLI_ID DATE NOM CLI_ID MONTANT_TOTAL TVA Client CLI_ID NOM ADRESSE CLI_ID PAN_ID Article PAN_ID CMD_ID QUANTITE PRIX_UNITAIRE

SQL Server (Microsoft) MySQL (Oracle) IBM DB2 PostgreSQL MariaDB Entité-relation SQL NewSQL Oracle Database SQL Server (Microsoft) MySQL (Oracle) IBM DB2 PostgreSQL MariaDB Bases entièrement en mémoire et réparties sur plusieurs nœuds avec réplication. VoltDB vFabric SQLFire (Vmware) (beta)

Clef-valeur Clef Valeur Convient parfaitement à l’utilisation d’un cache Performances prédictibles Répartition facile Requêtes optimales à temps constantes Pas de triggers Pas de contraintes Toutes les jointures doivent être faites dans le code Pas de requêtes Adhoc ni filtres complexes

Infinityspan (RedHat, JBoss) Clef-valeur Berkley DB (Oracle) Cohérente Maitre/esclave Memcache MemcacheDB = Memcache + BerkeleyDB Membase (couchbase.org) Erlang Riak Cohérent Redis (Vmware) en mémoire ; écriture disque asynchrone types évolués (liste et map) et opérations évoluées associées Dynamo (Amazon) Cohérent à terme Utilisation indirecte avec les outils Amazon AWS Voldemort (LinkedIn) Gigaspace Infinityspan (RedHat, JBoss) Hibernate OGM

Bases de documents Collection de documents JSON { "_id" : ObjectId("4c220a42f3924d31102bd866"), "cli_id" : ObjectId("4c220a42f3924d31102bd867"), "date" : "2011-07-19", "montant_total” : 123, "tva” : 20.16, "articles” : [ { “art_id” : ObjectId("4c220a42f3924d31102bd85b"), “qte” : 2, "pu” : 50 }, { “art_id” : ObjectId("4c220a42f3924d31102bd869"), "qte” : 1, "pu": 23 } ] } Collection de documents JSON

Bases de documents Mise à jour partielle Permet des requêtes adhoc Limite le nombre de requêtes pour les objets composites. Répartition facile Pas de triggers Pas de contraintes Toutes les jointures doivent être faites dans le code

Bases de documents MongoDB CouchDB (Apache) OrientDB Terrastore Cohérent Bien documentée Références Foursquare Bit.ly Sourceforge The New York Times Github Grooveshark CouchDB (Apache) Cohérent à terme Erlang Complexe OrientDB Java embarquable Terrastore Lotus Notes (IBM) Cohérent à terme RavenDB .Net

Bases orientées colonnes Table clairsemée La liste des colonnes peut changer d’une ligne à l’autre Clef A B C D E F G H ID1 65 9 8 ID2 12 34

Bases orientées colonnes Gère un très grand nombre de données Ex: Cassandra Max nombre colonnes : 2 000 000 000 Max taille clef et du nom de colonne: 64 Kio Max taille valeur d’une cellule : 2 Gio Clef TS Colonne ID1 T1 A = 65 T9 D = 9 T3 H = 8 ID2 T4 B = 12 T6 E = 34

Bases orientées colonnes Mise à jour partielle Gère de très gros volumes de données Répartition facile Pas de triggers Pas de contraintes Toutes les jointures doivent être faites dans le code

Bases orientées colonnes Bigtable (Google) Cohérent Utilisable via Google App Engine Basée sur Google File System Simple DB (Amazon) Cohérent à terme Option de lecture cohérente Utilisable comme service AWS Hbase (Apache) Cohérente Base historique de Hadoop Créée par Yahoo! Open source Cassandra (Apache) Cohérent à terme Niveau de cohérence réglable Créée par Facebook Grande communauté En cours d’intégration avec la suite Hadoop

Graphe Bases qui permettent d’étudier globalement les relations entre entités. Ex: Graph social

PrezFlash Web Sémantique Octobre 2011 Graphe Neo4j GPL Très actif Bases RDF Jena (HP) Sesame (OpenRDF) Bigdata Langage de requête normé : SPARQL PrezFlash Web Sémantique Octobre 2011

Questions ? http://blog.kleegroup.com/teknics teKnics@kleegroup.com Retrouvez nous sur le blog technique de Klee http://blog.kleegroup.com/teknics teKnics@kleegroup.com @teKnics_Klee