Tours JUG (oct 2010) - NoSQL, des grands du Web aux entreprises

40
NoSQL Des grands du Web aux entreprises 20/10/2010

description

 

Transcript of Tours JUG (oct 2010) - NoSQL, des grands du Web aux entreprises

NoSQL

Des grands du Web aux entreprises

20/10/2010

Speaker

Michaël Figuière

@mfiguiere

blog.xebia.fr

JUGsNoSQL UG

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

Sharding avec un SGBDR

Sur serveur B

Sur serveur A

Sharding avec un SGBDR

Sur serveur B

Sur serveur A

??

Sharding avec un SGBDR

Sur serveur B

Sur serveur A

Dénormalisation

Dénormalisation

Sharding avec un SGBDR

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

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

Ensemble des clés

Consistent hashing

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

Une partition parinstance

Multiples partitionspar instance

La répartition en anneau

La répartition en anneau

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 partitions

UtopiqueBDD relationnelles

BDD NoSQL

Ecriture avec attented’accusé d’un seul noeud

Consistance éventuelle

R + W < N

Lecture avec attente de réponse de 2 noeuds

4 réplicas

Consistance éventuelle

R + W = N

Ecriture avec attented’accusé de 2 noeuds

Lecture avec attente de réponse de 2 noeuds

Consistance éventuelle

R + W > N

Ecriture avec attented’accusé de 2 noeuds

Lecture avec attente de réponse de 3 noeuds

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 !

Cas d’usage : batch distribué

Application HBase Hadoop

Stockage des informations en

production

Exploitationdes résultats

Traitement batch distribué

Stockagedes résultats

Cas d’usage : stockage polyglotte

Application

Lucene

MySQL

Cassandra

Neo4j

Recherche desproduits

Stockage du réseau social clients

Stockage du catalogue produits

Stockage des comptes clients

Questions / Réponses

?