noSQL

© Klee Group Direction technique & Spark Archives NoSQL 11

PrezFlash :: NoSQL

Jérôme Mainaud

19 juillet 2011

© Klee Group Prez Flash NoSQL Jérôme Mainaud

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

Emmanuel Bernard — 2011


SQLIl était une fois


Modèle de données relationnel

Client

CLI_IDNOMADRESSE

Panier

PAN_IDCLI_IDDATEMONTANT_TOTALTVA

Article

PAN_IDCMD_IDQUANTITEPRIX_UNITAIRE

CLI_ID

PAN_ID


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


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

•Entités - relation

•Simple

•Universel

Modèle

•SQL•Puiss

ant•Ad-

hoc

Requête

•ACID

Transaction

•Utilisé massivement

•Nombreux moteurs sur le marché

•Nombreux outils

Maturité

Utilisémais paschoisi


Mise en œuvre d’un SGBD-R

Serveur ApplicatifBase de données

HTTPJDBC



Serveurs ApplicatifsBase de données

HTTP JDBC



Serveurs ApplicatifsBase de données

HTTP JDBC



Serveurs Applicatifs

Base de données

HTTP

JDBC


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é


NOT ONLY SQLRepenser les bases de données


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

• 10 ns

Mémoire

• 50 µs

Réseaulocal

• 10 ms

Disque

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

•Après la modification d’une donnée, tous les clients lisent la nouvelle valeur.

Consistency (Cohérence)

•Le système répond toujours aux requêtes dans un temps borné (timeout))

Avalibility (Disponibilité)

•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.

Partition Tolerance (Tolérance aux

pannes)


THÉORÈME CAP

« You can have at most two of these properties for any sharded-data system. »

Eric A. Brewer — 19 juillet 2000


Théorème CAP

Cohérence

DisponibilitéTolérence à partition

CAAPCP

Oracle RACLDAPCommit à 2 phasesCache validation

Bases distribuéesVerrous distribuésVerrou pessimiste

La partition minoritaire est indisponible

DNSCache WebExpirationRésolution de conflitVerrou optimiste


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

Nœud 2

Client B Version 1

MAJ 1 2



Nœud 1

Client A Version 2

Nœud 2

Client B Version 1

MA

J 1 2



Nœud 1

Client A Version 2

Nœud 2

Client B Version 2


Lit version 2


Nœud 1

Client A Version 1

Nœud 2

Client B Version 1

MAJ 1 2



Nœud 1

Client A Version 2

Nœud 2

Client B Version 1

MA

J 1 2


Perte du message



CA•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


Le choix d’Amazon

Assurer la cohérence entre les serveursAjouter l’article dans le panier et assurer la vente

Lors qu’un client clique sur le bouton « acheter »

Faut-il ?


Cohérence à terme

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

V1

V1

V1

V1

V1

Client A

Client B

V2

N réplicas



V2

V2

V2

V?

V?

Client A

Client B

N réplicas

OK

OK

OK

Le client attend E OK pour valider l’écriture



V2

V2

V2

V?

V?

Client A

Client B

N réplicas

Le client B lit L valeurs

Si E + L > N la lecture est cohérente avec l’écriture


Architecture décentralisée

N0N1

N2

N3N4

N5

N6

N7Client A

Client B

A,B,C

D,E,F

G,H,I

J,K,L

M,N,O

P,Q,R,S

T,U,V

W,X,Y,Z

GOSSIP


MAP-REDUCETraiter les données


Map-Reduce

Technique de traitement des données de grandes tailles

Acteurs réputés:

Google

Hadoop

CouchDB

MongoDB

(C1V1) Map (K2V2)Input Sort (K2[V2 V2’]) Reduce (K3V3)

Traitement local Traitement global


MODÈLES DE DONNÉESRepenser les bases de données


Entités-relation

Client

CLI_IDNOMADRESSE

Panier

PAN_IDCLI_IDDATEMONTANT_TOTALTVA

Article

PAN_IDCMD_IDQUANTITEPRIX_UNITAIRE

CLI_ID

PAN_ID


Entité-relation

SQL

Oracle Database

SQL Server (Microsoft)

MySQL (Oracle)

IBM DB2

PostgreSQL

MariaDB

NewSQL

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

Répartition facile Requêtes optimales à temps constantes Performances prédictiblesConvient parfaitement à l’utilisation d’un cache

Pas de requêtes Adhoc ni filtres complexesToutes les jointures doivent être faites dans le codePas de contraintesPas de triggers


Clef-valeur

Berkley DB (Oracle)

Cohérente

Maitre/esclave

Memcache

MemcacheDB = Memcache + BerkeleyDB

Membase (couchbase.org)

Erlang

Riak

Cohérent

Erlang

Redis (Vmware)

Cohérent

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)

Cohérent à terme

Gigaspace

Infinityspan (RedHat, JBoss) Hibernate OGM


Bases de documents

{ "_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

Répartition facile Limite le nombre de requêtes pour les objets composites.Permet des requêtes adhocMise à jour partielle

Toutes les jointures doivent être faites dans le codePas de contraintesPas de triggers


Bases de documents

MongoDB

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



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

ID1 T9 D = 9

ID1 T3 H = 8

ID2 T4 B = 12

ID2 T6 E = 34



Répartition facile Gère de très gros volumes de donnéesMise à jour partielle

Toutes les jointures doivent être faites dans le codePas de contraintesPas de triggers



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

Open source


Graphe

Bases qui permettent d’étudier globalement les relations entre entités.

Ex: Graph social


Graphe

Neo4j

GPL

Très actif

Bases RDF

Jena (HP)

Sesame (OpenRDF)

Bigdata

Langage de requête normé : SPARQL

PrezFlashWeb Sémantique

Octobre 2011


Questions ?

Retrouvez nous sur le blog technique de Klee

http://blog.kleegroup.com/teknics

[email protected]@teKnics_Klee

http://blog.kleegroup.com/teknics

mailto:[email protected]

https://twitter.com/#!/teknics_klee

https://twitter.com/#!/teknics_klee

Technology

noSQL