Wereldwijde gegevensdistributie met Azure Cosmos DB - onder de motorkap

VAN TOEPASSING OP: Nosql MongoDB Cassandra Gremlin Tabel

Azure Cosmos DB is een fundamentele service in Azure, dus deze wordt geïmplementeerd in alle Azure-regio's over de hele wereld, inclusief de openbare, onafhankelijke, DoD-cloud (Department of Defense) en overheidsclouds.

Op hoog niveau worden Azure Cosmos DB-containergegevens horizontaal gepartitioneerd in veel replicasets, die schrijfbewerkingen repliceren, in elke regio. Replicasets voeren schrijfbewerkingen duurzaam door met behulp van een meerderheidsquorum.

Elke regio bevat alle gegevenspartities van een Azure Cosmos DB-container en kan leesbewerkingen en schrijfbewerkingen uitvoeren wanneer schrijfbewerkingen voor meerdere regio's zijn ingeschakeld. Als uw Azure Cosmos DB-account is verdeeld over N Azure-regio's, zijn er ten minste N x 4 kopieën van al uw gegevens.

Binnen een datacenter implementeren en beheren we de Azure Cosmos DB op enorme stempels van machines, elk met toegewezen lokale opslag. Binnen een datacentrum wordt Azure Cosmos DB geïmplementeerd in veel clusters, die mogelijk meerdere generaties hardware uitvoeren. Machines binnen een cluster zijn doorgaans verdeeld over 10-20 foutdomeinen voor hoge beschikbaarheid binnen een regio. In de volgende afbeelding ziet u de topologie van het wereldwijde distributiesysteem van Azure Cosmos DB:

Systeemtopologie

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

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

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

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

Zoals in de volgende afbeelding wordt weergegeven, worden de gegevens in een container verdeeld over twee dimensies: binnen een regio en over regio's, wereldwijd:

fysieke partities

Een fysieke partitie wordt geïmplementeerd door een groep replica's, een replicaset genoemd. Elke computer 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 gelijkmatig verdeeld over de computers in een cluster en datacenters binnen een regio.

Een replica behoort uniek tot een Azure Cosmos DB-tenant. Elke replica fungeert als host voor een exemplaar van de database-engine van Azure Cosmos DB, waarmee de resources en de bijbehorende indexen worden beheerd. De Azure Cosmos DB-database-engine werkt op een typesysteem op basis van atom-record-sequence (ARS). De engine is agnostisch ten opzichte van het concept van een schema, waardoor de grens tussen de structuur en instantiewaarden van records wordt vervaagd. Azure Cosmos DB bereikt volledig schema-agnosticisme door alles automatisch op een efficiënte manier te indexeren bij opname, waardoor gebruikers query's kunnen uitvoeren op hun wereldwijd gedistribueerde gegevens zonder dat ze te maken hebben met schema- of indexbeheer.

De Azure Cosmos DB-database-engine bestaat uit onderdelen, waaronder de implementatie van verschillende coördinatieprimitief, 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, bewaart de database-engine de gegevens en index op SSD's en repliceert deze 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 enkele thread blokkeert ooit en elke thread werkt kortdurend zonder onnodige threadswitches. Snelheidsbegrenzing en tegendruk worden over de hele stapel verdeeld, van het toegangsbeheer tot alle I/O-paden. De Azure Cosmos DB-database-engine is ontworpen om gebruik te maken van fijnmazige gelijktijdigheid en om een hoge doorvoer te leveren met een spaarzame hoeveelheid systeemresources.

De wereldwijde distributie van Azure Cosmos DB is afhankelijk van twee belangrijke abstracties: replicasets en partitiesets. Een replicaset is een modulair Lego-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 belangrijke abstracties begrijpen.

Replicasets

Een fysieke partitie wordt gerealiseerd als een zelfbeheerde groep replica's met dynamisch gelijke taakverdeling, verspreid over meerdere foutdomeinen, een replicaset genoemd. Deze set implementeert gezamenlijk het protocol van de gerepliceerde statusmachine om de gegevens in de fysieke partitie maximaal beschikbaar, duurzaam en consistent te maken. Het lidmaatschap van de replicaset N is dynamisch: het blijft fluctueren tussen NMin en NMax op basis van de fouten, beheerbewerkingen en de tijd voor mislukte replica's om opnieuw te genereren/herstellen. Op basis van de lidmaatschapswijzigingen configureert het replicatieprotocol ook de grootte van lees- en schrijfquorums opnieuw. Om de doorvoer die is toegewezen aan een bepaalde fysieke partitie uniform te verdelen, gebruiken we twee ideeën:

  • Ten eerste zijn de kosten voor het verwerken van de schrijfaanvragen op de leider hoger dan de kosten voor het toepassen van de updates op de volger. Dienovereenkomstig wordt de leider gebudgetteerd met meer systeemresources dan de volgers.

  • Ten tweede bestaat het leesquorum voor een bepaald consistentieniveau voor zover mogelijk uitsluitend uit de volgreplica's. We voorkomen dat u contact opneemt met de leider voor het leveren van leesbewerkingen, tenzij dit vereist is. We gebruiken een aantal ideeën uit het onderzoek naar de relatie tussen belasting en capaciteit in de quorumsystemen voor de vijf consistentiemodellen die Azure Cosmos DB ondersteunt.

Partitiesets

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

Partitiesets

U kunt een partitieset beschouwen als een geografisch verspreide 'superreplica-set', die bestaat uit meerdere replicasets die dezelfde set sleutels bezitten. Net als bij een replicaset is het lidmaatschap van een partitieset ook dynamisch: de partitieset fluctueert op basis van impliciete bewerkingen voor het beheer van fysieke partities om nieuwe partities toe te voegen aan of te verwijderen uit een bepaalde partitieset (bijvoorbeeld wanneer u doorvoer op een container uitschaalt, een regio aan uw Azure Cosmos DB-database toevoegt of verwijdert, of wanneer er fouten optreden). Omdat elk van de partities (van een partitieset) het lidmaatschap van de partitieset binnen een eigen replicaset beheert, is het lidmaatschap volledig gedecentraliseerd en maximaal 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 doelpartitie.

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

Conflictoplossing

Ons ontwerp voor het doorgeven van updates, conflictoplossing en causaliteitstracering is geïnspireerd op het eerdere werk aan epidemische algoritmen en het Bayou-systeem . Hoewel de kernen van de ideeën zijn bewaard gebleven en een handig referentiekader bieden voor het communiceren van het systeemontwerp van Azure Cosmos DB, hebben ze ook een belangrijke transformatie ondergaan toen we ze toepasten op het Azure Cosmos DB-systeem. Dit was nodig, omdat de vorige systemen niet zijn ontworpen met de resourcegovernance, noch met de schaal waarop Azure Cosmos DB moet werken, noch om de mogelijkheden te bieden (bijvoorbeeld consistentie gebonden veroudering) en de strenge en uitgebreide SLA's die Azure Cosmos DB aan haar klanten levert.

Een partitieset is verdeeld over meerdere regio's en volgt het replicatieprotocol van Azure Cosmos DB (schrijfbewerkingen in meerdere regio's) om de gegevens te repliceren tussen de fysieke partities die een bepaalde partitieset omvatten. Elke fysieke partitie (van een partitieset) accepteert schrijfbewerkingen en levert leesbewerkingen meestal aan de clients die lokaal in die regio zijn. Schrijfbewerkingen die door een fysieke partitie binnen een regio worden geaccepteerd, worden duurzaam doorgevoerd en maximaal beschikbaar gemaakt binnen de fysieke partitie voordat ze aan de client worden bevestigd. Dit zijn voorlopig geschreven schrijfbewerkingen en worden doorgegeven aan andere fysieke partities binnen de partitieset met behulp van een anti-entropiekanaal. Clients kunnen voorlopig of doorgevoerde schrijfbewerkingen aanvragen door een aanvraagheader door te geven. De doorgifte van anti-entropie (inclusief de frequentie van doorgifte) is dynamisch, gebaseerd op de topologie van de partitieset, de regionale nabijheid van de fysieke partities en het geconfigureerde consistentieniveau. Binnen een partitieset volgt Azure Cosmos DB een primair doorvoerschema met een dynamisch geselecteerde arbiterpartitie. De arbiterselectie is dynamisch en maakt integraal deel uit van de herconfiguratie van de partitieset op basis van de topologie van de overlay. De vastgelegde schrijfbewerkingen (inclusief updates met meerdere rijen/batches) worden gegarandeerd geordend.

We gebruiken gecodeerde vectorklokken (met regio-id en logische klokken die overeenkomen met elk niveau van consensus in respectievelijk de replicaset en partitieset) voor het bijhouden van causaliteit en versievectoren om updateconflicten te detecteren en op te lossen. De topologie en het peerselectie-algoritme zijn ontworpen om te zorgen voor vaste en minimale opslag en minimale netwerkoverhead van versievectoren. Het algoritme garandeert de eigenschap strikte convergentie.

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

  • Last-Write-Wins (LWW), die standaard gebruikmaakt van een door het systeem gedefinieerde tijdstempeleigenschap (die is gebaseerd op het tijdsynchronisatieklokprotocol). Met Azure Cosmos DB kunt u ook andere aangepaste numerieke eigenschappen opgeven die moeten worden gebruikt voor conflictoplossing.
  • Toepassingsgedefinieerde (aangepaste) conflictoplossingsbeleid (uitgedrukt via samenvoegprocedures), dat is ontworpen voor door de toepassing gedefinieerde semantische afstemming van conflicten. Deze procedures worden aangeroepen bij de detectie van schrijf-schrijfconflicten onder auspiciën van een databasetransactie aan de serverzijde. Het systeem biedt precies één keer garantie voor de uitvoering van een samenvoegingsprocedure als onderdeel van het toezeggingsprotocol. Er zijn verschillende conflictoplossingsvoorbeelden beschikbaar waarmee u kunt spelen.

Consistentiemodellen

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

De consistentie gebonden veroudering garandeert dat alle leesbewerkingen binnen K-voorvoegsels of T seconden van de laatste schrijfbewerking in een van de regio's vallen. Bovendien zijn leesbewerkingen met gebonden verouderingsconsistentie gegarandeerd monotoon en met consistente voorvoegselgaranties. Het anti-entropieprotocol werkt op een snelheidsbeperking en zorgt ervoor dat de voorvoegsels zich niet ophopen en dat de tegendruk op de schrijfbewerkingen niet hoeft te worden toegepast. Sessieconsistentie garandeert monotone lees- en monotone schrijfbewerkingen, uw eigen schrijfbewerkingen lezen, schrijven volgt lezen en consistente garanties voor voorvoegsels, wereldwijd. Voor 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 Azure Cosmos DB wordt hier beschreven en wiskundig beschreven met behulp van TLA+ -specificaties op hoog niveau.

Volgende stappen

Vervolgens leert u hoe u globale distributie configureert met behulp van de volgende artikelen: