Breizh JUG (mar 2011) - NoSQL : Des Grands du Web aux Entreprises

NoSQL

Des grands du Web aux entreprises

14/03/2011

Speaker

Michaël Figuière

@mfiguiere

blog.xebia.fr

Search Engines NoSQL

DistributedArchitectures

A propos de NoSQL

No SQL

A propos de NoSQL

No SQL

Not Only

A propos de NoSQL

No SQLRelational

Not Only

Contrairement aux idées reçues

• NoSQL n’est pas un remplaçant des SGBDR

• NoSQL reste un domaine d’innovation

• NoSQL est un écosystème riche et complexe

The right tool for the right job

Mais déjà déployé en production !

« Le diable est dans le détail »

Au commencement

• Performance

• Disponibilité (> 99.99 %)

• Résilience

• Scalabilité horizontale

Des cas d’usage différents mais des besoins similaires : - Création de Dynamo

- Dernier incident majeur en 2004- < 40 min d’indisponibilité par an

- Création de BigTable + MapReduce- Toutes les pages Web du monde- Fonctionnement online et offline

Amazon : naissance de Dynamo

Fill cart Checkout Payment Process order Prepare Send

Stockage clé-valeur suffisant,disponibilité en écriture

Besoin en requêtes complexes,indisponibilité temporaire acceptable

Comment assurer la scalabilité avec un SGBDR ?

Réplication synchrone ou asynchrone

Mise en oeuvretypique avec MySQL

Sharding avec un SGBDR


Sur serveur B

Sur serveur A


Sur serveur B

Sur serveur A

??


Sur serveur B

Sur serveur A

Dénormalisation

Dénormalisation


Sur serveur B

Sur serveur A

Dénormalisation

Dénormalisation

On perd alors beaucoup de l’intérêt du relationnel !

Sharding avec un SGBDR : les problèmes

• Pour garder de bonnes performances, les relations many-to-many et many-to-one nécessitent d’être dénormalisées

• Gestion du resharding

• Code applicatif complexifié

D’une table de hachage à une BDD clé-valeur

Ensemble des cléspartitionnées selon

leur préfixe


Ensemble des clés

Consistent hashing


Une partition parinstance

Multiples partitionspar instance

Organisation des noeuds en anneau

Noeud

Noeud

NoeudNoeud

Noeud

Noeud

ReplicaPartition 1

ReplicaPartition 2

ReplicaPartition N


Noeud

Noeud

NoeudNoeud

Noeud

Noeud

Communication de proche en prochepour diffuser les changements de

topologie

Interactions Client / Serveur

Client

Client

Client

Client

Noeud

Noeud

NoeudNoeud

Noeud

Noeud

Interactions Client / Serveur

Client

Client

Client

Client

Noeud

Noeud Noeudreplica

Noeudreplica

NoeudNoeudreplica

?


Client

Client

Client

Client

Noeud

Noeud Noeudreplica

Noeudreplica

NoeudNoeudreplica

Agit en tantque proxy

Que devient ACID ?

• Tout accès réseau est faillible

• Des concessions doivent être faites sur le modèle de données

• Des concessions doivent être faites sur la consistance

Le théorème CAP

Consistance

Disponibilité

Toléranceaux défaillances

Sur ces 3 propriétés,seules 2 sont

réalisablesà la fois

Le théorème CAP

Consistance

Disponibilité

Toléranceaux défaillances Impossible

BDD relationnellesBDD NoSQL

Consistance éventuelle

Client

Client

Client

Client

Noeud

Noeud Noeudreplica

Noeudreplica

NoeudNoeudreplica

Transfère les requêtes R/W vers tous les réplicas

Consistance selon nombre de réponses attendues

4 réplicas

A A A A

Temps

Ecriture avec attented’accusé d’un seul noeud


4 réplicas

A A A A

B A A A

Temps

Ecriture avec attented’accusé d’un seul noeud


R + W < N

Lecture avec attente de réponse de 2 noeuds

4 réplicas

A A A A

B A A A

B A A A

Temps


R + W = N

Ecriture avec attented’accusé de 2 noeuds


A A A A

B B A A

B B A A


R + W > N

Ecriture avec attented’accusé de 2 noeuds


A A A A

B B B A

B B B A

Consistance apparente pour le client

Client

Client

Client

Client

Noeud

Noeud Noeudreplica

Noeudreplica

NoeudNoeudreplica

Transfère les requêtes R/W vers tous les réplicas

1

2

2

2

3

3

3

4

Atomicité et Isolation

• Les données ne sont plus co-localisées

• Les transactions distribuées nuiraient à la disponibilité et aux performances

• Atomicité et Isolation par opération sur une clé

Localisation non prédictible dans le temps

Durabilité

• Ecriture sur un ou plusieurs disques

• Ecriture multiples en mémoire

• En mémoire avec écriture asynchrone sur disque

La réplication permet de renforcer la durabilité

La réplication apporte la durabilité

Pas de durabilité

Base de données orientées clé-valeur

= HashMap !

Exemple avec Riak

Base de données orientées document

La BDD est consciente du contenu. Les requêtes complexes sont possibles

Exemple avec MongoDB

Base de données orientées colonnes

BDD relationnelle BDD orientée colonnes

A chaque ID de ligne correspond une liste de couples clé-valeur

Exemple avec Cassandra

A propos de Cassandra

Base de données orientées graphe

Exemple avec Neo4j

L’intérêt pour l’entreprise

• Stockage polyglotte : une meilleure adéquation entre la BDD et les données

• Scalabilité linéaire : être à même de répondre aux besoins les plus gourmands

• Haute disponibilité : du multi-serveurs au multi-datacenters

• Elasticité : une intégration naturelle à la logique du Cloud Computing

• Curseur pour s’adapter : + de consistence ou + de fiabilité (R + W > N)

• Et finalement... la possibilité crée le besoin !

NoSQL en production ?

• En production chez de nombreux « Grands du Web »

• Outillage encore réduit

• Monitoring par JMX

• Backups peuvent être problématiques avec des volumes importants

Cas d’usage : BI sur la BDD de production

Application HBase Hadoop

Stockage des informations en

production

Exploitationdes résultats

Traitement batch distribué

Stockagedes résultats

Cas d’usage : stockage polyglotte

Application

Solr

MySQL

Cassandra

Redis

Recherche desproduits

Stockage de données de sessions

Stockage du catalogue produits

Stockage des comptes clients

Questions / Réponses

?

Breizh JUG (mar 2011) - NoSQL : Des Grands du Web aux Entreprises

Technology

Transcript of Breizh JUG (mar 2011) - NoSQL : Des Grands du Web aux Entreprises