Introduktion till etablerat dataflöde i Azure Cosmos DB

  • Artikel

GÄLLER FÖR: Nosql Mongodb Cassandra Gremlin Tabell

Med Azure Cosmos DB kan du ange etablerat dataflöde för dina databaser och containrar. Det finns två typer av etablerat dataflöde, standard (manuell) eller autoskalning. Den här artikeln ger en översikt över hur etablerat dataflöde fungerar.

En Azure Cosmos DB-databas är en hanteringsenhet för en uppsättning containrar. En databas består av en uppsättning schemaoberoende containrar. En Azure Cosmos DB-container är skalbarhetsenheten för både dataflöde och lagring. En container partitioneras horisontellt över en uppsättning datorer i en Azure-region och distribueras över alla Azure-regioner som är associerade med ditt Azure Cosmos DB-konto.

Med Azure Cosmos DB kan du etablera dataflöde med två kornigheter:

  • Azure Cosmos DB-containrar
  • Azure Cosmos DB-databaser

Ange dataflöde för en container

Dataflödet som etableras på en Azure Cosmos DB-container är exklusivt reserverat för containern. Containern tar emot det etablerade dataflödet hela tiden. Det etablerade dataflödet på en container backas upp ekonomiskt av serviceavtal. Information om hur du konfigurerar standarddataflöde (manuellt) för en container finns i Etablera dataflöde i en Azure Cosmos DB-container. Information om hur du konfigurerar autoskalningsdataflöde för en container finns i Etablera dataflöde för automatisk skalning.

Det vanligaste alternativet är att ange etablerat dataflöde för en container. Du kan elastiskt skala dataflödet för en container genom att etablera valfri mängd dataflöde med hjälp av enheter för programbegäran (RU:er).

Dataflödet som etableras för en container är jämnt fördelat mellan dess fysiska partitioner, och förutsatt att en bra partitionsnyckel distribuerar de logiska partitionerna jämnt mellan de fysiska partitionerna, fördelas dataflödet även jämnt över alla logiska partitioner i containern. Du kan inte selektivt ange dataflödet för logiska partitioner. Eftersom en eller flera logiska partitioner av en container hanteras av en fysisk partition, tillhör de fysiska partitionerna uteslutande containern och stöder det dataflöde som etablerats på containern.

Om arbetsbelastningen som körs på en logisk partition förbrukar mer än det dataflöde som allokerades till den underliggande fysiska partitionen är det möjligt att dina åtgärder är hastighetsbegränsade. Det som kallas för en frekvent partition inträffar när en logisk partition har oproportionerligt många begäranden än andra partitionsnyckelvärden.

När hastighetsbegränsning sker kan du antingen öka det etablerade dataflödet för hela containern eller försöka utföra åtgärderna igen. Du bör också se till att du väljer en partitionsnyckel som distribuerar lagrings- och begärandevolymen jämnt. Mer information om partitionering finns i Partitionering och horisontell skalning i Azure Cosmos DB.

Vi rekommenderar att du konfigurerar dataflödet i containerns kornighet när du vill ha förutsägbara prestanda för containern.

Följande bild visar hur en fysisk partition är värd för en eller flera logiska partitioner av en container:

Physical partition that hosts one or more logical partitions of a container

Ange dataflöde för en databas

När du etablerar dataflöde i en Azure Cosmos DB-databas delas dataflödet mellan alla containrar (så kallade delade databascontainrar) i databasen. Ett undantag är om du har angett ett etablerat dataflöde för specifika containrar i databasen. Att dela det etablerade dataflödet på databasnivå mellan dess containrar är detsamma som att vara värd för en databas på ett kluster med datorer. Eftersom alla containrar i en databas delar de resurser som är tillgängliga på en dator får du naturligtvis inte förutsägbara prestanda för någon specifik container. Information om hur du konfigurerar etablerat dataflöde i en databas finns i Konfigurera etablerat dataflöde i en Azure Cosmos DB-databas. Information om hur du konfigurerar autoskalningsdataflöde för en databas finns i Etablera dataflöde för autoskalning.

Eftersom alla containrar i databasen delar det etablerade dataflödet tillhandahåller Azure Cosmos DB inga förutsägbara dataflödesgarantier för en viss container i databasen. Den del av dataflödet som en specifik container kan ta emot är beroende av:

  • Antalet containrar.
  • Valet av partitionsnycklar för olika containrar.
  • Fördelningen av arbetsbelastningen mellan olika logiska partitioner i containrarna.

Vi rekommenderar att du konfigurerar dataflödet i en databas när du vill dela dataflödet över flera containrar, men inte vill ägna dataflödet till någon viss container.

Följande exempel visar var det är föredraget att etablera dataflöde på databasnivå:

  • Att dela en databas etablerade dataflöde över en uppsättning containrar är användbart för ett program med flera klientorganisationer. Varje användare kan representeras av en distinkt Azure Cosmos DB-container.

  • Det är användbart att dela en databass etablerade dataflöde över en uppsättning containrar när du migrerar en NoSQL-databas, till exempel MongoDB eller Cassandra, som finns i ett kluster med virtuella datorer eller från lokala fysiska servrar till Azure Cosmos DB. Tänk på det etablerade dataflödet som konfigurerats i din Azure Cosmos DB-databas som en logisk motsvarighet, men mer kostnadseffektiv och elastisk, till beräkningskapaciteten för ditt MongoDB- eller Cassandra-kluster.

Alla containrar som skapas i en databas med etablerat dataflöde måste skapas med en partitionsnyckel. Vid en viss tidpunkt distribueras dataflödet som allokerats till en container i en databas över alla logiska partitioner i containern. När du har containrar som delar etablerat dataflöde som konfigurerats i en databas kan du inte selektivt tillämpa dataflödet på en specifik container eller en logisk partition.

Om arbetsbelastningen på en logisk partition förbrukar mer än det dataflöde som allokeras till en specifik logisk partition är dina åtgärder hastighetsbegränsade. När hastighetsbegränsning sker kan du antingen öka dataflödet för hela databasen eller försöka utföra åtgärderna igen. Mer information om partitionering finns i Logiska partitioner.

Containrar i en databas med delat dataflöde delar på dataflödet (RU/s) som allokerats till databasen. Med standardetablerade dataflöden (manuella) kan du ha upp till 25 containrar med minst 400 RU/s i databasen. Med autoskalningsetablerad dataflöde kan du ha upp till 25 containrar i en databas med autoskalning på minst 1 000 RU/s (skalar mellan 100 och 1 000 RU/s).

Kommentar

I februari 2020 introducerade vi en ändring som gör att du kan ha maximalt 25 containrar i en databas med delat dataflöde, vilket ger bättre en delning av dataflödet mellan containrarna. Efter de första 25 containrarna kan du bara lägga till fler containrar i databasen om de etableras med dedikerat dataflöde, som är separat från databasens delade dataflöde.
Om ditt Azure Cosmos DB-konto redan innehåller en databas för delat dataflöde med >=25 containrar undantas kontot och alla andra konton i samma Azure-prenumeration från den här ändringen. Kontakta produktsupporten om du har feedback eller frågor.

Om dina arbetsbelastningar innebär att ta bort och återskapa alla samlingar i en databas rekommenderar vi att du släpper den tomma databasen och återskapar en ny databas innan samlingen skapas. Följande bild visar hur en fysisk partition kan vara värd för en eller flera logiska partitioner som tillhör olika containrar i en databas:

Physical partition that hosts one or more logical partitions that belong to different containers

Ange dataflöde för en databas och en container

Du kan kombinera de två modellerna. Etablering av dataflöde för både databasen och containern tillåts. I följande exempel visas hur du etablerar standarddataflöde (manuell) i en Azure Cosmos DB-databas och en container:

  • Du kan skapa en Azure Cosmos DB-databas med namnet Z med standardetablerade (manuella) dataflöden för "K" -RU:er.

  • Skapa sedan fem containrar med namnet A, B, C, D och E i databasen. När du skapar container B måste du aktivera Etablera dedikerat dataflöde för det här containeralternativet och uttryckligen konfigurera "P" RU:er för etablerat dataflöde i den här containern. Du kan bara konfigurera delat och dedikerat dataflöde när du skapar databasen och containern.

    Setting the throughput at the container-level

  • Dataflödet "K" RU/s delas mellan de fyra containrarna A, C, D och E. Den exakta mängden dataflöde som är tillgängligt för A, C, D eller E varierar. Det finns inga serviceavtal för varje enskild containers dataflöde.

  • Containern med namnet B får garanterat "P" RU/s-dataflödet hela tiden. Den backas upp av serviceavtal.

Kommentar

Det går inte att konvertera en container med etablerat dataflöde till en delad databascontainer. Omvänt kan inte en delad databascontainer konverteras till ett dedikerat dataflöde. Du måste flytta data till en container med önskad dataflödesinställning. (Containerkopieringsjobb för NoSQL-, MongoDB- och Cassandra-API:er hjälper till med den här processen.)

Uppdatera dataflödet i en databas eller en container

När du har skapat en Azure Cosmos DB-container eller en databas kan du uppdatera det etablerade dataflödet. Det finns ingen gräns för det maximala etablerade dataflödet som du kan konfigurera i databasen eller containern.

Aktuellt etablerat dataflöde

Du kan hämta det etablerade dataflödet för en container eller en databas i Azure-portalen eller med hjälp av SDK:erna:

Svaret från dessa metoder innehåller också det minsta etablerade dataflödet för containern eller databasen:

Den faktiska lägsta RU/s kan variera beroende på din kontokonfiguration. Mer information finns i vanliga frågor och svar om autoskalning.

Ändra det etablerade dataflödet

Du kan skala det etablerade dataflödet för en container eller en databas via Azure-portalen eller med hjälp av SDK:erna:

Om du minskar det etablerade dataflödet kan du göra det till ett minimum.

Om du ökar det etablerade dataflödet är åtgärden för det mesta omedelbar. Det finns dock fall där åtgärden kan ta längre tid på grund av systemuppgifterna för att etablera nödvändiga resurser. I det här fallet ger ett försök att ändra det etablerade dataflödet medan den här åtgärden pågår ett HTTP 423-svar med ett felmeddelande som förklarar att en annan skalningsåtgärd pågår.

Läs mer i artikeln Best practices for scaling provisioned throughput (RU/s).

Kommentar

Om du planerar för en mycket stor inmatningsarbetsbelastning som kräver en stor ökning av etablerat dataflöde bör du tänka på att skalningsåtgärden inte har något serviceavtal och, som nämndes i föregående stycke, kan det ta lång tid när ökningen är stor. Du kanske vill planera i förväg och starta skalningen innan arbetsbelastningen startar och använda metoderna nedan för att kontrollera förloppet.

Du kan programmatiskt kontrollera skalningsstatusen genom att läsa det aktuella etablerade dataflödet och använda:

Du kan använda Azure Monitor-mått för att visa historiken för etablerat dataflöde (RU/s) och lagring på en resurs.

Jämförelse av modeller

Den här tabellen visar en jämförelse mellan etablering av standarddataflöde (manuellt) för en databas jämfört med en container.

Parameter Standarddataflöde (manuellt) i en databas Standarddataflöde (manuellt) för en container Autoskalning av dataflöde i en databas Autoskalning av dataflöde i en container
Startpunkt (minsta RU/s) 400 RU/s. Kan ha upp till 25 containrar utan MINSTA RU/s per container. 400 Autoskalning mellan 100 och 1 000 RU/s. Kan ha upp till 25 containrar utan MINSTA RU/s per container. Autoskalning mellan 100 och 1 000 RU/s.
Minsta RU/s per container -- 400 -- Autoskalning mellan 100 och 1 000 RU/s
Maximalt antal RU:er Obegränsad i databasen. Obegränsat, på containern. Obegränsad i databasen. Obegränsat, på containern.
Ru:er som tilldelats eller är tillgängliga för en specifik container Inga garantier. RU:er som tilldelats en viss container beror på egenskaperna. Egenskaper kan vara valet av partitionsnycklar för containrar som delar dataflödet, fördelningen av arbetsbelastningen och antalet containrar. Alla RU:er som konfigurerats i containern är uteslutande reserverade för containern. Inga garantier. RU:er som tilldelats en viss container beror på egenskaperna. Egenskaper kan vara valet av partitionsnycklar för containrar som delar dataflödet, fördelningen av arbetsbelastningen och antalet containrar. Alla RU:er som konfigurerats i containern är uteslutande reserverade för containern.
Maximalt lagringsutrymme för en container Obegränsad. Obegränsat Obegränsat Obegränsat
Maximalt dataflöde per logisk partition för en container 10 000 RU/s 10 000 RU/s 10 000 RU/s 10 000 RU/s
Maximal lagring (data + index) per logisk partition i en container 20 GB 20 GB 20 GB 20 GB

Nästa steg