Bernard Ourghanlian @Ourghanlian CTO & CSO - Microsoft France - Big Data Paris
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
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 C I D Atomicity Consistency Isolation 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.
Consistency Availability Partition tolerance Master Replica
Master Replica
http://dbmsmusings.blogspot.com/2010/04/problems-with-cap-and-yahoos-little.html
LATENCE Latence = 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 2010Le 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.pdfIn 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
Master Replica
Cohérence forte Cohérence éventuelle,
Latence élevée 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)La plupart des applications de la vie réelle ne tombent pas dans ces
deux extrêmes
Strong Bounded-stateless Session Consistent prefix Eventual
Il est possible de mettre en œuvre 5 niveaux de cohérence bien définis pour une faible
latence et une haute disponibilitéBounded Consistent Compromis clairs
Prefix
Staleness • Latence
• Disponibilité
Session
01 • Débit
Strong Eventualhttps://github.com/Azure/azure-cosmos-tla
COMPROMIS CLAIRS
Cinq modèles de cohérence bien définis
• Latence
Annulable sur la base de chaque requête
• Disponibilité
Fournit le contrôle du compromis entre performance et cohérence,
• Débit
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
Strong Bounded-staleness Session Consistent prefix EventualNiveau 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.Charges de travail
Charges de travail polyvalentes Charges de
opérationnelles travail
analytique
Multi-API
Azure Cosmos DB ANSI SQL
Multi-Model
Clé-Valeur Tableau Documents Graph Relationelle
A l’échelle de la
planète
Distribution globale à Passage à l’échelle Latence extrêmement Niveaux de cohérence Modèle ARS (Atom Record SLAs complets
partir de zéro sans limite basse multiples SequenceQuelques clients qui utilisent déjà Cosmos DB aujourd’hui
Données distribuées et disponibles globalement • • •
Constuire des experiences Online Recommendations Service
clients temps reel HOT path
•
•
•
•
Offline Recommendations Engine
COLD pathIdéal pour le gaming et l’e-commerce
Vous pouvez aussi lire
