Consistentieniveaus in Azure Cosmos DB
VAN TOEPASSING OP: 
NoSQL MongoDB Cassandra Gremlin Tafel
Gedistribueerde databases die afhankelijk zijn van replicatie voor hoge beschikbaarheid, lage latentie of beide, moeten een fundamentele afweging maken tussen de leesconsistentie, beschikbaarheid, latentie en doorvoer, zoals gedefinieerd door de PACELC-theorema. De lineariseerbaarheid van het sterke consistentiemodel is de gouden standaard van programmeerbaarheid van gegevens. Maar het voegt een steile prijs toe van hogere schrijflatenties omdat gegevens over grote afstanden moeten worden gerepliceerd en doorgevoerd. Sterke consistentie kan ook leiden tot verminderde beschikbaarheid (tijdens storingen), omdat gegevens niet in elke regio kunnen worden gerepliceerd en doorgevoerd. Uiteindelijke consistentie biedt hogere beschikbaarheid en betere prestaties, maar het is moeilijker om toepassingen te programmeren, omdat gegevens mogelijk niet consistent zijn in alle regio's.
De meeste commercieel beschikbare gedistribueerde NoSQL-databases die momenteel op de markt beschikbaar zijn, bieden alleen sterke en uiteindelijke consistentie. Azure Cosmos DB biedt vijf goed gedefinieerde niveaus. Van sterkste naar zwakste, de niveaus zijn:
Zie het standaardconsistentieniveau configureren of het standaardconsistentieniveau overschrijven voor meer informatie over het standaardconsistentieniveau.
Elk niveau biedt een compromis tussen beschikbaarheid en prestaties. In de volgende afbeelding ziet u de verschillende consistentieniveaus als spectrum.
Consistentieniveaus en Azure Cosmos DB-API's
Azure Cosmos DB biedt systeemeigen ondersteuning voor met wire-protocol compatibele API's voor populaire databases. Deze omvatten MongoDB, Apache Cassandra, Apache Gremlin en Azure Table Storage. In API voor Gremlin of Table wordt het standaardconsistentieniveau gebruikt dat is geconfigureerd in het Azure Cosmos DB-account. Zie DE API voor consistentieniveautoewijzing tussen Apache Cassandra en Azure Cosmos DB voor meer informatie over de toewijzing van consistentieniveaus tussen Apache Cassandra en Azure Cosmos DB. Zie API voor MongoDB-consistentietoewijzing voor meer informatie over toewijzing op consistentieniveau tussen MongoDB en Azure Cosmos DB.
Bereik van de leesconsistentie
Leesconsistentie is van toepassing op één leesbewerking binnen een logische partitie. Een externe client, een opgeslagen procedure of een trigger kan de leesbewerking uitgeven.
Het standaardconsistentieniveau configureren
U kunt het standaardconsistentieniveau op elk gewenst moment configureren voor uw Azure Cosmos DB-account. Het standaardconsistentieniveau dat voor uw account is geconfigureerd, is van toepassing op alle Azure Cosmos DB-databases en -containers onder dat account. Alle lees- en query's die zijn uitgegeven voor een container of een database, gebruiken standaard het opgegeven consistentieniveau. Wanneer u de consistentie op accountniveau wijzigt, moet u ervoor zorgen dat u uw toepassingen opnieuw implementeert en de benodigde codewijzigingen aanbrengt om deze wijzigingen toe te passen. Zie voor meer informatie hoe u het standaardconsistentieniveau configureert. U kunt ook het standaardconsistentieniveau voor een specifieke aanvraag overschrijven voor meer informatie. Zie het artikel over het standaardconsistentieniveau overschrijven.
Tip
Het overschrijven van het standaardconsistentieniveau is alleen van toepassing op leesbewerkingen binnen de SDK-client. Een account dat standaard is geconfigureerd voor sterke consistentie, schrijft en repliceert gegevens synchroon naar elke regio in het account. Wanneer het SDK-clientexemplaren of de aanvraag dit overschrijft met sessie of zwakkere consistentie, worden leesbewerkingen uitgevoerd met één replica. Zie Consistentieniveaus en doorvoer voor meer informatie.
Belangrijk
Het is vereist om een SDK-exemplaar opnieuw te maken nadat het standaardconsistentieniveau is gewijzigd. U kunt dit doen door de toepassing opnieuw op te starten. Dit zorgt ervoor dat de SDK gebruikmaakt van het nieuwe standaardconsistentieniveau.
Garanties die zijn gekoppeld aan consistentieniveaus
Azure Cosmos DB garandeert dat 100 procent van de leesaanvragen voldoet aan de consistentiegarantie voor het gekozen consistentieniveau. De exacte definities van de vijf consistentieniveaus in Azure Cosmos DB met behulp van de TLA+-specificatietaal worden geleverd in de GitHub-opslagplaats azure-cosmos-tla .
De semantiek van de vijf consistentieniveaus worden beschreven in de volgende secties.
Grote consistentie
Sterke consistentie biedt garantie op linearisabiliteit. Lineariseerbaarheid verwijst naar het gelijktijdig verwerken van aanvragen. De leesbewerkingen retourneren gegarandeerd de meest recente vastgelegde versie van een item. Een client ziet nooit een niet-verzonden of gedeeltelijke schrijfbewerking. Gebruikers kunnen altijd gegarandeerd de meest recente vastgelegde schrijfbewerking lezen.
In de volgende afbeelding ziet u de sterke consistentie met muzieknotities. Nadat de gegevens naar de regio VS - west 2 zijn geschreven, krijgt u de meest recente waarde wanneer u de gegevens uit andere regio's leest:
Dynamisch quorum
Onder normale omstandigheden wordt voor een account met sterke consistentie een schrijfbewerking als vastgelegd wanneer alle regio's erkennen dat de record naar deze record is gerepliceerd. Voor accounts met 3 regio's of meer (met inbegrip van de schrijfregio) kan het systeem het quorum van regio's echter 'omlaag verschuifen' naar een globale meerderheid in gevallen waarin sommige regio's niet reageren of langzaam reageren. Op dat moment worden niet-reagerende regio's uit de quorumset regio's gehaald om sterke consistentie te behouden. Ze worden alleen weer toegevoegd zodra ze consistent zijn met andere regio's en werken zoals verwacht. Het aantal regio's dat mogelijk uit de quorumset kan worden gehaald, is afhankelijk van het totale aantal regio's. In een account van 3 of 4 regio's is de meerderheid bijvoorbeeld respectievelijk 2 of 3 regio's, dus in beide gevallen kan slechts één regio worden verwijderd. Voor een account van 5 regio's is de meerderheid 3, dus maximaal 2 niet-reagerende regio's kunnen worden verwijderd. Deze mogelijkheid wordt 'dynamisch quorum' genoemd en kan zowel de beschikbaarheid van schrijfbewerkingen als de replicatielatentie voor accounts met 3 of meer regio's verbeteren.
Notitie
Wanneer regio's worden verwijderd uit de quorumset als onderdeel van een dynamisch quorum, kunnen deze regio's geen leesbewerkingen meer verwerken totdat ze opnieuw aan het quorum zijn toegevoegd.
Consistentie Gebonden veroudering
Voor schrijfaccounts met één regio met twee of meer regio's worden gegevens gerepliceerd van de primaire regio naar alle secundaire (alleen-lezen) regio's. Voor schrijfaccounts met meerdere regio's met twee of meer regio's worden gegevens gerepliceerd uit de regio waarin ze oorspronkelijk zijn geschreven naar alle andere schrijfbare regio's. In beide scenario's, hoewel dit niet gebruikelijk is, kan er af en toe een replicatievertraging optreden van de ene regio naar de andere.
In de consistentie gebonden veroudering is de vertraging van gegevens tussen twee regio's altijd kleiner dan een opgegeven hoeveelheid. De hoeveelheid kan 'K'-versies (dat wil wel 'updates') zijn van een item of met 'T'-tijdsintervallen, afhankelijk van wat het eerst wordt bereikt. Met andere woorden, wanneer u gebonden veroudering kiest, kunnen de maximum 'veroudering' van de gegevens in elke regio op twee manieren worden geconfigureerd:
- Het aantal versies (K) van het item
- De leesbewerkingen voor het tijdsinterval (T) kunnen achterblijven bij de schrijfbewerkingen
Gebonden veroudering is voornamelijk nuttig voor schrijfaccounts met één regio met twee of meer regio's. Als de gegevensvertraging in een regio (bepaald per fysieke partitie) de geconfigureerde verouderingswaarde overschrijdt, worden schrijfbewerkingen voor die partitie beperkt totdat veroudering weer binnen de geconfigureerde bovengrens valt.
Voor een account met één regio biedt Bounded Staleness dezelfde garanties voor schrijfconsistentie als sessie- en uiteindelijke consistentie. Met Gebonden veroudering worden gegevens gerepliceerd naar een lokale meerderheid (drie replica's in een vier replicaset) in één regio.
Belangrijk
Met de consistentie Gebonden veroudering worden verouderingscontroles alleen uitgevoerd tussen regio's en niet binnen een regio. Binnen een bepaalde regio worden gegevens altijd gerepliceerd naar een lokale meerderheid (drie replica's in een vier replicaset), ongeacht het consistentieniveau.
Leesbewerkingen bij het gebruik van Bounded Staleness retourneren de meest recente gegevens die beschikbaar zijn in die regio door te lezen uit twee beschikbare replica's in die regio. Omdat schrijfbewerkingen binnen een regio altijd worden gerepliceerd naar een lokale meerderheid (drie van de vier replica's), retourneren twee replica's de meest bijgewerkte gegevens die beschikbaar zijn in die regio.
Belangrijk
Met de consistentie Gebonden veroudering retourneren leesbewerkingen die zijn uitgegeven voor een niet-primaire regio mogelijk niet noodzakelijkerwijs de meest recente versie van de gegevens wereldwijd, maar worden gegarandeerd de meest recente versie van de gegevens in die regio geretourneerd, die zich binnen de maximale verouderingsgrens wereldwijd bevindt.
Gebonden veroudering werkt het beste voor wereldwijd gedistribueerde toepassingen met behulp van schrijfaccounts met één regio met twee of meer regio's, waarbij bijna sterke consistentie tussen regio's gewenst is. Voor schrijfaccounts met meerdere regio's met twee of meer regio's moeten toepassingsservers lees- en schrijfbewerkingen doorsturen naar dezelfde regio waarin de toepassingsservers worden gehost. Gebonden veroudering in een account met meerdere schrijfbewerkingen is een antipatroon. Dit niveau vereist een afhankelijkheid van replicatievertraging tussen regio's, wat niet uitmaakt of gegevens worden gelezen uit dezelfde regio waarnaar ze zijn geschreven.
In de volgende afbeelding ziet u de consistentie gebonden veroudering met muzieknotities. Nadat de gegevens naar de regio US - west 2 zijn geschreven, lezen de regio's VS - oost 2 en Australië - oost de geschreven waarde op basis van de geconfigureerde maximale vertragingstijd of de maximale bewerkingen:
Consistentie Sessie
In sessieconsistentie, binnen één clientsessie, worden leesbewerkingen gegarandeerd voldaan aan de lees-uw-schrijfbewerkingen en garanties voor write-follows-reads. Hierbij wordt ervan uitgegaan dat er één 'writer'-sessie wordt gebruikt of dat het sessietoken voor meerdere schrijvers wordt gedeeld.
Net als alle consistentieniveaus die zwakker zijn dan Sterk, worden schrijfbewerkingen gerepliceerd naar minimaal drie replica's (in een vier replicaset) in de lokale regio, met asynchrone replicatie naar alle andere regio's.
Na elke schrijfbewerking ontvangt de client een bijgewerkt sessietoken van de server. De client slaat de tokens in de cache op en verzendt deze naar de server voor leesbewerkingen in een opgegeven regio. Als de replica waarmee de leesbewerking wordt uitgegeven gegevens bevat voor het opgegeven token (of een recenter token), worden de aangevraagde gegevens geretourneerd. Als de replica geen gegevens voor die sessie bevat, probeert de client de aanvraag opnieuw uit te voeren op een andere replica in de regio. Indien nodig probeert de client de leesbewerking opnieuw uit te voeren op extra beschikbare regio's totdat de gegevens voor het opgegeven sessietoken worden opgehaald.
Belangrijk
In sessieconsistentie garandeert het gebruik van een sessietoken dat gegevens die overeenkomen met een oudere sessie nooit worden gelezen. Als de client echter een ouder sessietoken gebruikt en er recentere updates zijn aangebracht in de database, wordt de recentere versie van de gegevens geretourneerd ondanks een ouder sessietoken dat wordt gebruikt. Het sessietoken wordt gebruikt als minimale versiebarrière, maar niet als een specifieke (mogelijk historische) versie van de gegevens die moeten worden opgehaald uit de database.
Sessietokens in Azure Cosmos DB zijn partitiegebonden, wat betekent dat ze uitsluitend aan één partitie zijn gekoppeld. Gebruik het sessietoken dat voor het laatst is gegenereerd voor de relevante items om ervoor te zorgen dat u uw schrijfbewerkingen kunt lezen.
Als de client geen schrijfbewerking naar een fysieke partitie heeft gestart, bevat de client geen sessietoken in de cache en leest deze naar die fysieke partitie als leesbewerkingen met uiteindelijke consistentie. Als de client opnieuw wordt gemaakt, wordt ook de cache met sessietokens opnieuw gemaakt. Leesbewerkingen volgen hier ook hetzelfde gedrag als Uiteindelijke consistentie totdat volgende schrijfbewerkingen de cache van sessietokens van de client herbouwen.
Belangrijk
Als sessietokens van het ene clientexemplaren naar het andere worden doorgegeven, mag de inhoud van het token niet worden gewijzigd.
Sessieconsistentie is het meest gebruikte consistentieniveau voor zowel één regio als wereldwijd gedistribueerde toepassingen. Het biedt schrijflatenties, beschikbaarheid en leesdoorvoer die vergelijkbaar is met die van uiteindelijke consistentie. Sessieconsistentie biedt ook de consistentiegaranties die aansluiten bij de behoeften van toepassingen die zijn geschreven om te werken in de context van een gebruiker. In de volgende afbeelding ziet u de consistentie van de sessie met muzieknotities. De schrijver VS - west 2 en de lezer VS - oost 2 gebruiken dezelfde sessie (sessie A), zodat ze beide dezelfde gegevens tegelijk lezen. Terwijl de regio Australië - oost 'Sessie B' gebruikt, ontvangt deze later gegevens, maar in dezelfde volgorde als de schrijfbewerkingen.
Consistent Consistent voorvoegsel
Net als alle consistentieniveaus die zwakker zijn dan Sterk, worden schrijfbewerkingen gerepliceerd naar minimaal drie replica's (in een set met vier replica's) in de lokale regio, met asynchrone replicatie naar alle andere regio's.
In consistent voorvoegsel zien updates die zijn aangebracht als schrijfbewerkingen voor één document uiteindelijk consistentie.
Updates die zijn gemaakt als een batch binnen een transactie, worden consistent geretourneerd voor de transactie waarin ze zijn doorgevoerd. Schrijfbewerkingen binnen een transactie van meerdere documenten zijn altijd samen zichtbaar.
Stel dat twee schrijfbewerkingen transactioneel (alle of niets) worden uitgevoerd op document Doc1, gevolgd door document Doc2, binnen transacties T1 en T2. Wanneer de client een replica leest, ziet de gebruiker 'Doc1 v1 en Doc2 v1' of 'Doc1 v2 en Doc2 v2' of geen van beide documenten als de replica traag is, maar nooit 'Doc1 v1 en Doc2 v2' of 'Doc1 v2 en Doc2 v1' voor dezelfde lees- of querybewerking.
In de volgende afbeelding ziet u de consistentievoorvoegselconsistentie met muzieknotities. In alle regio's zien de leesbewerkingen nooit schrijfbewerkingen op volgorde voor een transactionele batch schrijfbewerkingen:
Consistentie Uiteindelijk
Net als alle consistentieniveaus die zwakker zijn dan Sterk, worden schrijfbewerkingen gerepliceerd naar minimaal drie replica's (in een vier replicaset) in de lokale regio, met asynchrone replicatie naar alle andere regio's.
In uiteindelijke consistentie geeft de client leesaanvragen op voor een van de vier replica's in de opgegeven regio. Deze replica kan achterblijven en kan verouderde of geen gegevens retourneren.
Uiteindelijke consistentie is de zwakste vorm van consistentie, omdat een client de waarden kan lezen die ouder zijn dan de waarden die in het verleden zijn gelezen. Uiteindelijke consistentie is ideaal wanneer er geen garanties hoeven te worden gerangschikt voor de toepassing. Voorbeelden hiervan zijn het aantal Retweets, Vind-ik-leuks of niet-threaded opmerkingen. In de volgende afbeelding ziet u de uiteindelijke consistentie met muzieknotities.
Consistentiegaranties in de praktijk
In de praktijk kunt u vaak sterkere consistentiegaranties krijgen. Consistentiegaranties voor een leesbewerking komen overeen met de versheid en volgorde van de databasestatus die u aanvraagt. Leesconsistentie is gekoppeld aan de volgorde en doorgifte van de schrijf-/updatebewerkingen.
Als er geen schrijfbewerkingen in de database zijn, levert een leesbewerking met uiteindelijke, sessie- of consistente consistentieniveaus voor voorvoegsels waarschijnlijk dezelfde resultaten op als een leesbewerking met een sterk consistentieniveau.
Als uw account is geconfigureerd met een ander consistentieniveau dan de sterke consistentie, kunt u achterhalen of uw clients sterke en consistente leesbewerkingen voor uw workloads kunnen krijgen. U kunt deze waarschijnlijkheid uitzoeken door de metrische pbs-meetwaarde (Probabilistically Bounded Staleness) te bekijken. Deze metrische gegevens worden weergegeven in Azure Portal voor meer informatie. Zie de metrische gegevens Monitor Probabilistically Bounded Staleness (PBS).
Probabilistisch gebonden veroudering toont hoe uiteindelijk uw uiteindelijke consistentie is. Deze metrische waarde biedt een inzicht in hoe vaak u een sterkere consistentie kunt krijgen dan het consistentieniveau dat u momenteel hebt geconfigureerd in uw Azure Cosmos DB-account. Met andere woorden, u kunt de waarschijnlijkheid (gemeten in milliseconden) zien van het verkrijgen van consistente leesbewerkingen voor een combinatie van schrijf- en leesregio's.
Consistentieniveaus en latentie
De leeslatentie voor alle consistentieniveaus is altijd gegarandeerd minder dan 10 milliseconden op het 99e percentiel. De gemiddelde leeslatentie, op het 50e percentiel, is doorgaans 4 milliseconden of minder.
De schrijflatentie voor alle consistentieniveaus is altijd gegarandeerd minder dan 10 milliseconden op het 99e percentiel. De gemiddelde schrijflatentie, op het 50e percentiel, is meestal 5 milliseconden of minder. Azure Cosmos DB-accounts die meerdere regio's omvatten en zijn geconfigureerd met sterke consistentie, vormen een uitzondering op deze garantie.
Schrijflatentie en sterke consistentie
Voor Azure Cosmos DB-accounts die zijn geconfigureerd met sterke consistentie met meer dan één regio, is de schrijflatentie gelijk aan twee keer retourtijd (RTT) tussen een van de twee meest verre regio's, plus 10 milliseconden op het 99e percentiel. Hoge netwerk-RTT tussen de regio's wordt omgezet in een hogere latentie voor Azure Cosmos DB-aanvragen, omdat sterke consistentie een bewerking alleen voltooit nadat deze is doorgevoerd in alle regio's binnen een account.
De exacte RTT-latentie is een functie van snelheid-van-lichtafstand en de Azure-netwerktopologie. Azure-netwerken bieden geen latentie-SLA's voor de RTT tussen twee Azure-regio's, maar publiceert wel latentiestatistieken van azure-netwerkrondes. Voor uw Azure Cosmos DB-account worden replicatielatenties weergegeven in Azure Portal. U kunt Azure Portal gebruiken door naar de sectie Metrische gegevens te gaan en vervolgens de optie Consistentie te selecteren. Met behulp van Azure Portal kunt u de replicatielatenties bewaken tussen verschillende regio's die zijn gekoppeld aan uw Azure Cosmos DB-account.
Belangrijk
Sterke consistentie voor accounts met regio's die meer dan 5000 mijl (8000 kilometer) omvatten, wordt standaard geblokkeerd vanwege een hoge schrijflatentie. Neem contact op met de ondersteuning om deze mogelijkheid in te schakelen.
Consistentieniveaus en doorvoer
Voor sterke en gebonden veroudering worden leesbewerkingen uitgevoerd op twee replica's in een vier replicaset (minderheidsquorum) om consistentiegaranties te bieden. Sessie, consistent voorvoegsel en uiteindelijk lezen van één replica. Het resultaat is dat voor hetzelfde aantal aanvraageenheden leesdoorvoer voor sterke en gebonden veroudering de helft van de andere consistentieniveaus is.
Voor een bepaald type schrijfbewerking, zoals invoegen, vervangen, upsert en verwijderen, is de schrijfdoorvoer voor aanvraageenheden identiek voor alle consistentieniveaus. Voor sterke consistentie moeten wijzigingen worden doorgevoerd in elke regio (globale meerderheid), terwijl voor alle andere consistentieniveaus lokale meerderheid (drie replica's in een vier replicaset) wordt gebruikt.
| Consistentieniveau | Quorumleesbewerkingen | Quorumschrijfbewerkingen |
|---|---|---|
| Sterk | Lokale minderheid | Wereldwijde meerderheid |
| Gebonden veroudering | Lokale minderheid | Lokale meerderheid |
| Sessie | Eén replica (met sessietoken) | Lokale meerderheid |
| Consistent voorvoegsel | Eén replica | Lokale meerderheid |
| Gebeurlijk | Eén replica | Lokale meerderheid |
Notitie
De kosten van ru's voor leesbewerkingen voor lokale minderheidsleesbewerkingen zijn twee keer dat van zwakkere consistentieniveaus, omdat leesbewerkingen worden gemaakt van twee replica's om consistentiegaranties te bieden voor de consistentieniveaus Strong en Bounded Staleness.
Consistentieniveaus en duurzaamheid van gegevens
Binnen een wereldwijd gedistribueerde databaseomgeving is er een directe relatie tussen het consistentieniveau en de duurzaamheid van gegevens in de aanwezigheid van een storing in de hele regio. Wanneer u uw bedrijfscontinuïteitsplan ontwikkelt, moet u weten wat de maximale periode van recente gegevensupdates is die de toepassing kan tolereren bij verlies bij het herstellen na een verstorende gebeurtenis. De periode van updates die u zich kunt veroorloven, wordt RPO (Recovery Point Objective) genoemd.
Deze tabel definieert de relatie tussen het consistentiemodel en de duurzaamheid van gegevens in aanwezigheid van een regiobrede storing.
| Regio('s) | Replicatiemodus | Consistentieniveau | RPO |
|---|---|---|---|
| 1 | Regio's voor één of meerdere schrijfbewerkingen | Elk consistentieniveau | < 240 minuten |
| >1 | Regio voor één schrijfbewerking | Sessie, consistent voorvoegsel, uiteindelijk | < 15 minuten |
| >1 | Regio voor één schrijfbewerking | Bounded Staleness | K & T |
| >1 | Regio voor één schrijfbewerking | Sterk | 0 |
| >1 | Meerdere schrijfregio's | Sessie, consistent voorvoegsel, uiteindelijk | < 15 minuten |
| >1 | Meerdere schrijfregio's | Bounded Staleness | K & T |
K = Het aantal 'K' -versies (dat wil gezegd, updates) van een item.
T = Het tijdsinterval 'T' sinds de laatste update.
Voor één regio-account is de minimale waarde van K en T 10 schrijfbewerkingen of 5 seconden. Voor accounts met meerdere regio's is de minimale waarde van K en T 100.000 schrijfbewerkingen of 300 seconden. Deze waarde definieert de minimale RPO voor gegevens bij gebruik van Gebonden veroudering.
Sterke consistentie en meerdere schrijfregio's
Azure Cosmos DB-accounts die zijn geconfigureerd met meerdere schrijfregio's, kunnen niet worden geconfigureerd voor sterke consistentie, omdat het niet mogelijk is voor een gedistribueerd systeem om een RPO van nul en een RTO van nul te bieden. Daarnaast zijn er geen voordelen van schrijflatentie voor het gebruik van sterke consistentie met meerdere schrijfregio's, omdat een schrijfbewerking naar een regio moet worden gerepliceerd en vastgelegd in alle geconfigureerde regio's binnen het account. Dit scenario resulteert in dezelfde schrijflatentie als één schrijfregioaccount.
Meer lezen
Lees de volgende artikelen voor meer informatie over consistentieconcepten:
- TLA+-specificaties op hoog niveau voor de vijf consistentieniveaus die worden aangeboden door Azure Cosmos DB
- Gerepliceerde gegevensconsistentie uitgelegd via honkbal (video) door Doug Terry
- Gerepliceerde gegevensconsistentie uitgelegd door Baseball (technisch document) door Doug Terry
- Sessiegaranties voor zwak consistente gerepliceerde gegevens
- Consistentie-compromissen in het ontwerp van moderne gedistribueerde databasesystemen: CAP maakt slechts deel uit van het verhaal
- Probabilistisch gebonden veroudering (PBS) voor praktische gedeeltelijke quorums
- Uiteindelijk consistent - opnieuw bezocht