Bernard Ourghanlian @Ourghanlian CTO & CSO Microsoft France · Le théorème PACELC (Abadi,...

Bernard Ourghanlian @Ourghanlian

CTO & CSO – Microsoft France

In addition to the revenue impact of lost sales, the bigger impact is the loyal customers a brand might lose from having a non-functioning website on one of the biggest shopping days of the year.

- Mehdi Daoudi, CEO Catchpoint

https://people.eecs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf

A

Atomicity

C

Consistency

I

Isolation

D

Durability

Le théorème CAP, aussi connu sous le nom de théorème de Brewer dit qu’il est impossible sur un système distribué de garantir en même temps (c’est-à-dire de manière synchrone) les trois contraintes suivantes : • Cohérence (Consistency en anglais) : tous les nœuds du

système voient exactement les mêmes données au même moment ;

• Disponibilité (Availability en anglais) : garantie que toutes les requêtes reçoivent une réponse;

• Tolérance au partitionnement (Partition Tolerance en anglais) : aucune panne moins importante qu’une coupure totale du réseau ne doit empêcher le système de répondre correctement (ou encore : en cas de morcellement en sous-réseaux, chacun doit pouvoir fonctionner de manière autonome).

S. Gilbert and N. Lynch, “Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant

Web Services,” ACM SIGACT News, June 2002, pp. 51-59.

Master Replica

Consistency

Availability

Partition tolerance

Master Replica

http://dbmsmusings.blogspot.com/2010/04/problems-with-cap-and-yahoos-little.html

LATENCELatence = Combien de temps une demande client doit-elle attendre votre réponse ?

Imaginez avoir à répliquer les données à travers

le monde…

“A high availability requirement implies

that the system must replicate data.

But as soon as a distributed system

replicates data, a tradeoff between

consistency and latency arises.”

Abadi 2010

Le théorème PACELC (Abadi, 2010, formalisé en

2012)In a system that replicates data:

1. If a partition (P) is detected, how does the system trade off○ (A) Availability or○ (C) Consistency

2. Else (E) how does the system trade off○ (L) Latency or○ (C) Consistency

Abadi, Daniel J. “Consistency Tradeoffs in Modern Distributed Database System Design”, Yale University

http://cs-www.cs.yale.edu/homes/dna/papers/abadi-pacelc.pdf

Master Replica

In the case of network Partitioning in a distributed computer system, one

has to choose between Availability and Consistency, but Else, even when

the system is running normally in the absence of partitions, one has to

choose between Latency and Consistency.

Master Replica

Cohérence forte

Latence élevée

Cohérence éventuelle,

Latence faible

Choix pour la plupart des applications distribuées

Les bases de données sont essentiellement divisées en deux catégories Celles qui procurent les choix extrêmes – forte vs. Cohérence

éventuelle (par ex. DynamoDB)

Celles qui laissent tout à configurer aux développeurs (par ex. Cassandra) Réparation de lecture, transfert suggéré, tailles de quorum, topologies de réplication, etc.

Les développeurs ont à faire des compromis précis entre Cohérence et disponibilité (pendant les défaillances)

Cohérence et latence (à l’état normal)

Cohérence et débit (ceci est important pour des raisons de TCO)

Il est possible de mettre en œuvre 5 niveaux de cohérence bien définis pour une faible

latence et une haute disponibilité

Strong Bounded-stateless Session Consistent prefix Eventual

La plupart des applications de la vie réelle ne tombent pas dans ces deux extrêmes

01

Strong

Bounded

Staleness

Session

Consistent

Prefix

Eventual

Compromis clairs

• Latence

• Disponibilité

• Débit

https://github.com/Azure/azure-cosmos-tla

Strong Bounded-staleness Session Consistent prefix Eventual

Cinq modèles de cohérence bien définis

Annulable sur la base de chaque requête

Fournit le contrôle du compromis entre performance et cohérence,

soutenus par des SLAs complets

Un modèle de programmation intuitif offrant faible latence et haute

disponibilité pour vos applications à l’échelle de la planète

COMPROMIS CLAIRS

• Latence

• Disponibilité

• Débit

Niveau de coherence Garanties

Strong Linearizability (once operation is complete, it will be visible to all)

Bounded Staleness Consistent Prefix.

Reads lag behind writes by at most k prefixes or t interval

Similar properties to strong consistency (except within staleness window), while

preserving 99.99% availability and low latency.

Session Consistent Prefix.

Within a session: monotonic reads, monotonic writes, read-your-writes, write-

follows-reads

Predictable consistency for a session, high read throughput + low latency

Consistent Prefix Reads will never see out of order writes (no gaps).

Eventual Potential for out of order reads. Lowest cost for reads of all consistency levels.

Distribution globale à

partir de zéro

Passage à l’échelle

sans limite

Latence extrêmement

basse

Niveaux de cohérence

multiples

Modèle ARS (Atom Record

Sequence

SLAs complets

A l’échelle de la

planète

Multi-Model

Multi-API

Charges de travail

polyvalentesCharges de travail

opérationnelles

Charges de

travail

analytique

Clé-Valeur Tableau GraphDocuments

Azure Cosmos DB

Relationelle

ANSI SQL

Quelques clients qui utilisent déjà Cosmos DB aujourd’hui

Données distribuées et disponibles globalement

•

•

•

Constuire des experiences clients temps reel

•

•

•

•

Online Recommendations Service

HOT path

Offline Recommendations Engine

COLD path

Idéal pour le gaming et l’e-commerce