Skalbarhet i Azure Cosmos DB för MongoDB (virtuell kärna)

Den vCore-baserade tjänsten för Azure Cosmos DB for MongoDB ger möjlighet att skala kluster både lodrätt och vågrätt. Även om beräkningsklusternivån och lagringsdisken är funktionellt beroende av varandra, är skalbarheten och kostnaden för beräkning och lagring frikopplad.

Vertikal skalning

Vertikal skalning ger följande fördelar:

• Programteam kanske inte alltid har en tydlig sökväg för att logiskt fragmentera sina data. Dessutom definieras logisk horisontell partitionering per samling. I en datauppsättning med flera ohardade samlingar kan datamodellering för att partitionera data snabbt bli omständlig. Genom att skala upp klustret kan du kringgå behovet av logisk horisontell partitionering samtidigt som du uppfyller programmets växande lagrings- och beräkningsbehov.
• Vertikal skalning kräver inte ombalansering av data. Antalet fysiska shards förblir detsamma och endast klustrets kapacitet ökas utan att programmet påverkas.
• Skalning upp och ned sker utan driftstopp eller avbrott i tjänsten. Inga applikationsändringar behövs och stabila driftförhållanden kan fortsätta opåverkade.
• Beräkningsresurser kan också skalas ned under kända tidsfönster med låg aktivitet. Återigen undviker nedskalning behovet av att balansera om data över färre fysiska shards och är en noll nedtidsåtgärd utan avbrott i tjänsten. Även här behövs inga programändringar efter att klustret har skalats ned.
• Viktigast av allt är att beräkning och lagring kan skalas oberoende av varandra. Om det behövs fler kärnor och minne kan diskstorleken lämnas som den är och klusternivån kan skalas upp. Om det behövs mer lagringsutrymme och IOPS kan klusternivån lämnas som den är och lagringsstorleken kan skalas upp separat. Vid behov kan både beräkning och lagring skalas separat för att optimera för varje komponents krav individuellt, utan att någon av komponenternas elasticitetskrav påverkar den andra komponenten.

Horisontell skalning

Så småningom växer programmet till en punkt där skalning vertikalt inte räcker. Arbetsbelastningskraven kan öka utöver kapaciteten på den största klusternivån och så småningom behövs fler fragment. Horisontell skalning i det vCore-baserade erbjudandet för Azure Cosmos DB for MongoDB ger följande fördelar:

• Logiskt fragmenterade datauppsättningar kräver inte användarintervention för att balansera data över underliggande fysiska shards. Tjänsten mappar automatiskt logiska shards till fysiska shards. När noder läggs till eller tas bort balanseras data automatiskt om databasen under täcket.
• Begäranden dirigeras automatiskt till relevant fysisk shard som äger hash-intervallet för de data som efterfrågas.
• Geo-distribuerade kluster har en homogen konfiguration med flera noder. Därför är logiska för fysiska shardmappningar konsekventa i de primära regionerna och replikregionerna i ett kluster.

Skalning av beräkning och lagring

Beräknings- och minnesresurser påverkar läsåtgärder i den vCore-baserade tjänsten för Azure Cosmos DB för MongoDB mer än disk-IOPS.

• Läsåtgärder läser först cachen i beräkningslagret och återgår till disken när data inte kunde hämtas från cacheminnet. För arbetsbelastningar med en högre läsfrekvens per sekund leder skalning av klusternivån för att få fler PROCESSOR- och minnesresurser till högre dataflöde.
• Förutom läsdataflöde kan arbetsbelastningar med en stor mängd data per läsåtgärd också dra nytta av att skala beräkningsresurserna i klustret. Klusternivåer med mer minne underlättar till exempel större nyttolaststorlekar per dokument och ett större antal mindre dokument per svar.

Disk-IOPS påverkar skrivåtgärder i den vCore-baserade tjänsten för Azure Cosmos DB för MongoDB mer än processor- och minneskapaciteterna för beräkningsresurserna.

• Skrivåtgärder bevarar alltid data till disken (förutom att spara data i minnet för att optimera läsningar). Större diskar med mer IOPS ger högre skrivdataflöde, särskilt när de körs i stor skala.
• Tjänsten har stöd för upp till 32 TB diskar per shard, med mer IOPS per shard för att gynna skrivintensiva arbetsbelastningar, särskilt när de körs i stor skala.

Lagringsintensiva arbetsbelastningar och stora diskar

Inga minimikrav för lagring per klusternivå

Som tidigare nämnts är lagrings- och beräkningsresurser frikopplade för fakturering och tillhandahållande. Även om de fungerar som en sammanhängande enhet kan de skalas oberoende av varandra. M30-klusternivån kan ha 32 TB-diskar tilldelade. På samma sätt kan M200-klusternivån ha 32 GB diskar etablerade för att optimera för både lagrings- och beräkningskostnader.

Lägre TCO med stora diskar (32 TB och senare)

Vanligtvis begränsar NoSQL-databaser med en modell baserad på virtuell kärna lagringen per fysisk shard till 4 TB. Den vCore-baserade tjänsten för Azure Cosmos DB for MongoDB tillhandahåller upp till 8 x den kapaciteten med 32 TB diskar. För lagringsintensiva arbetsbelastningar kräver en lagringskapacitet på 4 TB per fysisk shard en enorm mängd beräkningsresurser bara för att upprätthålla lagringskraven för arbetsbelastningen. Beräkning är dyrare än lagring och överetablering av beräkning på grund av kapacitetsbegränsningar i en tjänst kan snabbt öka kostnaderna.

Nu ska vi överväga en lagringsintensiv arbetsbelastning med 200 TB data.

Minskningen av beräkningskraven minskar kraftigt med större diskar. Även om mer än det minsta antalet fysiska shards kan behövas för att upprätthålla dataflödeskraven för arbetsbelastningen, är även fördubbling eller tredubbling av antalet shards mer kostnadseffektiva än ett 50-shardkluster med mindre diskar.

Hoppa över lagringsskiktning med stora diskar

Ett omedelbart svar på beräkningskostnader i lagringsintensiva scenarier är att "nivåindela" data. Data i transaktionsdatabasen är begränsad till den mest frekvent använda "heta" data, medan den större volymen av "kalla" data frånkopplas till ett kallt arkiv. Detta orsakar driftskomplexitet. Prestanda är också oförutsägbara och beroende av den datanivå som används. Dessutom är tillgängligheten för hela systemet beroende av motståndskraften hos både de varma och kalla datalager som kombineras. Med stora diskar i tjänsten virtuell kärna behöver du inte nivåindelad lagring eftersom kostnaden för lagringsintensiva arbetsbelastningar minimeras.

Nästa steg

• Lär dig hur du skalar Azure Cosmos DB för MongoDB vCore-kluster
• Kolla in metodtips för indexering