bernard ourghanlian @ourghanlian cto & cso microsoft france · le théorème pacelc (abadi,...
TRANSCRIPT
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