Wereldwijde gegevensdistributie met Azure Cosmos DB - achter de wil

VAN TOEPASSING OP: SQL-API Cassandra-API Gremlin-API Table-API Azure Cosmos DB-API voor MongoDB

Azure Cosmos DB is een basisservice in Azure en wordt daarom geïmplementeerd in alle Azure-regio's wereldwijd, waaronder de openbare, onafhankelijke, Ministerie van Defensie- en overheidswolken. Binnen een datacenter implementeren en beheren we de Azure Cosmos DB op enorme stempels van machines, elk met toegewezen lokale opslag. Binnen een datacenter worden Azure Cosmos DB geïmplementeerd in veel clusters, die elk meerdere generaties hardware kunnen uitvoeren. Machines in een cluster worden doorgaans verdeeld over 10-20 foutdomeinen voor hoge beschikbaarheid binnen een regio. In de volgende afbeelding ziet u Cosmos DB de topologie van het wereldwijde distributiesysteem:

Systeemtopologie

Wereldwijde distributie in Azure Cosmos DB is turnkey: Met een paar klikken of programmatisch met één API-aanroep kunt u op elk moment de geografische regio's toevoegen of verwijderen die zijn gekoppeld aan uw Cosmos-database. Een Cosmos-database bestaat op zijn beurt uit een set Cosmos-containers. In Cosmos DB fungeren containers als de logische eenheden voor distributie en schaalbaarheid. De verzamelingen, tabellen en grafieken die u maakt, zijn (intern) alleen Cosmos-containers. Containers zijn volledig schemaagnostisch en bieden een bereik voor een query. Gegevens in een Cosmos-container worden automatisch geïndexeerd bij opname. Met automatische indexering kunnen gebruikers query's uitvoeren op de gegevens zonder de moeite van schema- of indexbeheer, met name in een wereldwijd gedistribueerde configuratie.

  • In een bepaalde regio worden gegevens binnen een container gedistribueerd met behulp van een partitiesleutel, die u levert en transparant wordt beheerd door de onderliggende fysieke partities (lokale distributie).

  • Elke fysieke partitie wordt ook gerepliceerd in geografische regio's (wereldwijde distributie).

Wanneer een app met Cosmos DB doorvoer elastisch schaalt in een Cosmos-container of meer opslag verbruikt, verwerkt Cosmos DB transparant partitiebeheerbewerkingen (splitsen, klonen, verwijderen) in alle regio's. Onafhankelijk van de schaal, distributie of storingen blijft Cosmos DB één systeemafbeelding van de gegevens in de containers bieden, die wereldwijd over een groot aantal regio's worden verdeeld.

Zoals u in de volgende afbeelding kunt zien, worden de gegevens in een container verdeeld over twee dimensies: binnen een regio en in verschillende regio's, wereldwijd:

fysieke partities

Een fysieke partitie wordt geïmplementeerd door een groep replica's, die een replicaset worden genoemd. Elke machine host honderden replica's die overeenkomen met verschillende fysieke partities binnen een vaste set processen, zoals wordt weergegeven in de bovenstaande afbeelding. Replica's die overeenkomen met de fysieke partities worden dynamisch geplaatst en verdeeld over de computers binnen een cluster en datacenters binnen een regio.

Een replica behoort op unieke manier tot een Azure Cosmos DB tenant. Elke replica host een exemplaar van Cosmos DB database-enginevan een bedrijf, die de resources en de bijbehorende indexen beheert. De Cosmos-database-engine werkt op een typesysteem op basis van atom-record-sequence (ARS). De engine is agnostisch voor het concept van een schema, waarbij de grens tussen de structuur en instantiewaarden van records vervaagt. Cosmos DB bereikt volledige schemaagnostiek door alles bij opname automatisch op een efficiënte manier te indexeren, zodat gebruikers query's kunnen uitvoeren op hun wereldwijd gedistribueerde gegevens zonder dat ze te maken krijgen met schema- of indexbeheer.

De Cosmos-database-engine bestaat uit onderdelen, waaronder de implementatie van verschillende coördinatieprimives, taalruntimes, de queryprocessor en de opslag- en indexeringssubsystemen die verantwoordelijk zijn voor respectievelijk transactionele opslag en indexering van gegevens. Om duurzaamheid en hoge beschikbaarheid te bieden, blijven de gegevens en index van de database-engine op SSD's staan en worden deze gerepliceerd tussen de database-engine-exemplaren binnen respectievelijk de replicaset(s). Grotere tenants komen overeen met een hogere schaal van doorvoer en opslag en hebben grotere of meer replica's of beide. Elk onderdeel van het systeem is volledig asynchroon: geen threadblokken en elke thread werkt van korte duur zonder onnodige threadswitches. Snelheidsbeperking en back-druk worden over de hele stack verspreid vanaf het toegangsbeheer voor alle I/O-paden. De Cosmos-database-engine is ontworpen om gebruik te maken van fijngranenseerde gelijktijdigheid en om een hoge doorvoer te leveren terwijl er binnen een beperkte hoeveelheid systeemresources wordt gebruikt.

Cosmos DB wereldwijde distributie van Cosmos DB is afhankelijk van twee sleutelabstracties: replicasets en partitiesets. Een replicaset is een modulair Blok voor coördinatie en een partitieset is een dynamische overlay van een of meer geografisch gedistribueerde fysieke partities. Om te begrijpen hoe wereldwijde distributie werkt, moeten we deze twee sleutelabstracties begrijpen.

Replicasets

Een fysieke partitie wordt ge materialiseerd als een zelf-beheerde en dynamisch gebalanceerde groep replica's die zijn verdeeld over meerdere foutdomeinen, een zogenaamde replicaset. Deze set implementeert gezamenlijk het protocol van de gerepliceerde statusmachine om de gegevens binnen de fysieke partitie uiterst beschikbaar, duurzaam en consistent te maken. Het lidmaatschap van de replicaset N is dynamisch: het blijft variëren tussen NMin en NMax op basis van fouten, beheerbewerkingen en de tijd die het voor mislukte replica's is om opnieuw te worden gegeneerd/hersteld. Op basis van de lidmaatschapswijzigingen wordt met het replicatieprotocol ook de grootte van lees- en schrijfquorums opnieuw geconfigureerd. Om de doorvoer die is toegewezen aan een bepaalde fysieke partitie gelijkmatig te distribueren, gebruiken we twee ideeën:

  • Ten eerste zijn de kosten voor het verwerken van de schrijfaanvragen voor de leider hoger dan de kosten voor het toepassen van de updates op de volger. De leider heeft daarom meer systeemresources in budgetten dan de volgers.

  • Ten tweede bestaat het leesquorum voor een bepaald consistentieniveau zo veel mogelijk uit de volgreplica's. We vermijden contact op te nemen met de leider voor het aflezen, tenzij dat nodig is. We gebruiken een aantal ideeën uit het onderzoek dat is uitgevoerd op de relatie van belasting en capaciteit in de quorumsystemen voor de vijf consistentiemodellen die Cosmos DB ondersteunt.

Partitiesets

Een groep fysieke partities, één van elk van de geconfigureerd met de Cosmos-databaseregio's, bestaat uit het beheren van dezelfde set sleutels die in alle geconfigureerde regio's worden gerepliceerd. Deze hogere coördinatieprimitief wordt een partitieset genoemd: een geografisch gedistribueerde dynamische overlay van fysieke partities die een bepaalde set sleutels beheren. Hoewel een bepaalde fysieke partitie (een replicaset) binnen het bereik van een cluster valt, kan een partitieset clusters, datacenters en geografische regio's omspannen, zoals wordt weergegeven in de onderstaande afbeelding:

Partitiesets

U kunt een partitieset zien als een geografisch verspreide 'superreplicaset', die bestaat uit meerdere replicasets die eigenaar zijn van dezelfde set sleutels. Net als bij een replicaset is het lidmaatschap van een partitieset ook dynamisch: het fluctueert op basis van impliciete fysieke partitiebeheerbewerkingen om nieuwe partities toe te voegen aan/uit een bepaalde partitieset (bijvoorbeeld wanneer u doorvoer op een container uitschaalt, een regio aan uw Cosmos-database toevoegt/verwijdert of wanneer er fouten optreden). Omdat elk van de partities (van een partitieset) het lidmaatschap van de partitieset in een eigen replicaset beheert, is het lidmaatschap volledig gedecentraliseerd en zeer beschikbaar. Tijdens de herconfiguratie van een partitieset wordt ook de topologie van de overlay tussen fysieke partities tot stand gebracht. De topologie wordt dynamisch geselecteerd op basis van het consistentieniveau, de geografische afstand en de beschikbare netwerkbandbreedte tussen de bron- en de fysieke doelpartities.

Met de service kunt u uw Cosmos-databases configureren met één schrijfregio of meerdere schrijfregio's. Afhankelijk van de keuze zijn partitiesets geconfigureerd voor het accepteren van schrijfgegevens in precies één of alle regio's. Het systeem maakt gebruik van een genest consensusprotocol op twee niveau: het ene niveau werkt binnen de replica's van een replicaset van een fysieke partitie die de schrijfingen accepteert, en het andere niveau werkt op het niveau van een partitieset om volledige volgordegaranties te bieden voor alle vastgelegde schrijf schrijfingen binnen de partitieset. Deze meerlaagse, geneste consensus is essentieel voor de implementatie van onze strenge SLA's voor hoge beschikbaarheid, evenals de implementatie van de consistentiemodellen die Cosmos DB biedt aan klanten.

Conflictoplossing

Ons ontwerp voor het doorgeven van updates, conflictoplossing en het bijhouden van causaliteit is geïnspireerd op het eerdere werk aan algoritmen voor algoritmen en het Bayou-systeem. Hoewel de kernels van de ideeën zijn blijven bestaan en een handig referentiekader bieden voor het communiceren van het systeemontwerp van de Cosmos DB, hebben ze ook een aanzienlijke transformatie ondergaan terwijl we deze op het Cosmos DB-systeem hebben toegepast. Dit was nodig, omdat de vorige systemen niet zijn ontworpen met resourcebeheer, noch met de schaal waarop Cosmos DB moet werken, noch om de mogelijkheden (bijvoorbeeld consistentie van gebonden veroudering) en de strenge en uitgebreide SLA's te bieden die Cosmos DB aan de klanten levert.

Zoals u zich herinnert, wordt een partitieset verdeeld over meerdere regio's en wordt het cosmos-replicatieprotocol (schrijf-naar-meerdere regio's) gevolgd om de gegevens te repliceren tussen de fysieke partities die bestaan uit een bepaalde partitieset. Elke fysieke partitie (van een partitieset) accepteert schrijf- en lees- en lees lezen doorgaans aan de clients die lokaal in die regio zijn. Schrijf schrijft die door een fysieke partitie binnen een regio wordt geaccepteerd, worden blijvend vastgelegd en in de fysieke partitie uiterst beschikbaar gesteld voordat ze aan de client worden bevestigd. Dit zijn tijdelijke schrijf schrijfingen en worden doorgegeven aan andere fysieke partities in de partitieset met behulp van een anti-entropiekanaal. Clients kunnen voorlopige of vastgelegde schrijf schrijven aanvragen door een aanvraagheader door te geven. De doorgeven van anti-entropie (inclusief de frequentie van doorgeven) is dynamisch, op basis van de topologie van de partitieset, regionale nabijheid van de fysieke partities en het geconfigureerde consistentieniveau. Binnen een partitieset volgt Cosmos DB een primair commit-schema met een dynamisch geselecteerde arbiterpartitie. De arbiterselectie is dynamisch en vormt een integraal onderdeel van de herconfiguratie van de partitieset op basis van de topologie van de overlay. De vastgelegde schrijf schrijven (inclusief updates met meerdere rijen of batchupdates) worden gegarandeerd geordend.

We maken gebruik van gecodeerde vector klokken (met regio-id en logische klokken die overeenkomen met elk niveau van consensus op respectievelijk de replicaset en partitieset) voor causaliteitstracking en versievectoren om updateconflicten te detecteren en op te lossen. De topologie en het peerselectiealgoritme zijn ontworpen om te zorgen voor een vaste en minimale opslag en minimale netwerkoverhead van versievectoren. Het algoritme garandeert de strikte convergentie-eigenschap.

Voor de Cosmos-databases die zijn geconfigureerd met meerdere schrijfregio's, biedt het systeem een aantal flexibele beleidsregels voor automatische conflictoplossing waar ontwikkelaars uit kunnen kiezen, waaronder:

  • Last-Write-Wins (LWW), die standaard een door het systeem gedefinieerde tijdstempel-eigenschap gebruikt (die is gebaseerd op het klokprotocol voor tijdsynchronisatie). Cosmos DB kunt u ook elke andere aangepaste numerieke eigenschap opgeven die moet worden gebruikt voor conflictoplossing.
  • Door de toepassing gedefinieerd (aangepast) conflictoplossingsbeleid (uitgedrukt via samenvoegingsprocedures), dat is ontworpen voor door de toepassing gedefinieerde semantiek voor het afstemmen van conflicten. Deze procedures worden aangeroepen bij het detecteren van schrijfconflicten onder het toezicht van een databasetransactie aan de serverzijde. Het systeem biedt exact één keer garantie voor de uitvoering van een samenvoegingsprocedure als onderdeel van het toezeggingsprotocol. Er zijn verschillende voorbeelden van conflictoplossing beschikbaar om mee te spelen.

Consistentiemodellen

Of u uw Cosmos-database nu configureert met één of meerdere schrijfregio's, u kunt kiezen uit de vijf duidelijk gedefinieerde consistentiemodellen. Met meerdere schrijfregio's zijn de volgende belangrijke aspecten van de consistentieniveaus:

De consistentie Gebonden veroudering garandeert dat alle leessels binnen K-voorvoegsels of T seconden na de laatste schrijfronde in een van de regio's komen. Leess met consistentie gebonden veroudering zijn bovendien gegarandeerd monotone en met consistente voorvoegselgaranties. Het anti-entropieprotocol werkt op een manier met een beperkte snelheid en zorgt ervoor dat de voorvoegsels niet worden verzameld en dat de backpressie op de schrijfingen niet hoeft te worden toegepast. Sessieconsistentie garandeert monotone lees-, monotone schrijf-, lees-, schrijf- en lees- en consistente voorvoegselgaranties, wereldwijd. Voor de databases die zijn geconfigureerd met sterke consistentie zijn de voordelen (lage schrijflatentie, hoge schrijfbeschikbaarheid) van meerdere schrijfregio's niet van toepassing vanwege synchrone replicatie tussen regio's.

De semantiek van de vijf consistentiemodellen in Cosmos DB worden hier beschreven enwiskundig beschreven met behulp van een TLA+-specificaties op hoog niveau.

Volgende stappen

Hierna leert u hoe u wereldwijde distributie configureert met behulp van de volgende artikelen: