Introduktion till etablerat dataflöde i Azure Cosmos DB

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 är horisontellt partitionerad ö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 den 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 på en Azure Cosmos DB-container. Information om hur du konfigurerar dataflöde för automatisk skalning för en container finns i Etablera dataflöde för automatisk skalning.

Att ange etablerat dataflöde för en container är det vanligaste alternativet. Du kan elastiskt skala dataflödet för en container genom att etablera hur mycket dataflöde som helst med hjälp av enheter för programbegäran (RU:er).

Dataflödet som etableras för en container fördelas jämnt 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 också 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 i en container hanteras av en fysisk partition, tillhör de fysiska partitionerna uteslutande containern och stöder dataflödet som etablerats på containern.

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

När hastighetsbegränsningen inträffar 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 på containerkornigheten när du vill ha förutsägbar 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:

Fysisk partition som är värd för en eller flera logiska partitioner i en container

Ange dataflöde för en databas

När du etablerar dataflöde för 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 för en databas finns i Konfigurera etablerat dataflöde på en Azure Cosmos DB-databas. Information om hur du konfigurerar dataflöde för automatisk skalning för en databas finns i Etablera dataflöde för automatisk skalning.

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 på en databas när du vill dela dataflödet över flera containrar, men inte vill dedikera dataflödet till en viss container.

Följande exempel visar var det är att föredra 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.

  • Att dela en databas etablerade dataflöde över en uppsättning containrar är användbart 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 för 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 allokeras till en container i en databas över alla logiska partitioner i containern. När du har containrar som delar etablerat dataflöde konfigurerat på 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 dataflödet som allokeras till en specifik logisk partition är dina åtgärder hastighetsbegränsade. När hastighetsbegränsning inträffar 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 etablerat dataflöde för automatisk skalning kan du ha upp till 25 containrar i en databas med automatisk skalning på minst 1 000 RU/s (skalar mellan 100 och 1 000 RU/s).

Anteckning

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:

Fysisk partition som är värd för en eller flera logiska partitioner som tillhör olika containrar

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 (manuellt) för en Azure Cosmos DB-databas och en container:

  • Du kan skapa en Azure Cosmos DB-databas med namnet Z med ett etablerat standarddataflöde (manuellt) för "K" -RU:er.

  • Skapa sedan fem containrar med namnen 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 för den här containern. Du kan bara konfigurera delat och dedikerat dataflöde när du skapar databasen och containern.

    Ange dataflödet på containernivå

  • Dataflödet "K" ru:er 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 dataflödet "P" för RU:er hela tiden. Den backas upp av serviceavtal.

Anteckning

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

Uppdatera dataflöde för 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-Portal 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:

Det faktiska lägsta antalet RU/s kan variera beroende på din kontokonfiguration. Vanligtvis gäller det högsta av följande värden:

  • 400 RU/s
  • Aktuell lagring i GB * 10 RU/s (den här begränsningen kan vara avslappnad i vissa fall, se vårt program för hög lagring/lågt dataflöde)
  • Högsta antal RU/s som någonsin etablerats på databasen eller containern / 100

Ändra det etablerade dataflödet

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

Om du minskar det etablerade dataflödet kan du göra det upp till det minsta möjliga.

Om du ökar det etablerade dataflödet sker åtgärden för det mesta omedelbart. 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.

Mer informasjon i artikeln Metodtips för skalning av etablerat dataflöde (RU/s).

Anteckning

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 vi nämnde 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.

Program med hög lagring/lågt dataflöde

Enligt beskrivningen i avsnittet Aktuellt etablerat dataflöde ovan beror det minsta dataflöde som du kan etablera på en container eller databas på ett antal faktorer. En av dem är mängden data som för närvarande lagras, eftersom Azure Cosmos DB tillämpar ett minsta dataflöde på 10 RU/s per GB lagringsutrymme.

Detta kan vara ett problem i situationer där du behöver lagra stora mängder data, men har låga dataflödeskrav i jämförelse. För att bättre hantera dessa scenarier har Azure Cosmos DB introducerat ett program med "hög lagring/lågt dataflöde" som minskar RU/s per GB-begränsning för berättigade konton.

För att gå med i det här programmet och bedöma din fullständiga behörighet behöver du bara fylla i den här undersökningen. Azure Cosmos DB-teamet följer sedan upp och fortsätter med din registrering.

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) för en databas Standarddataflöde (manuellt) för en container Autoskala dataflöde för en databas Autoskala dataflöde för en container
Startpunkt (minsta ANTAL 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 ANTAL RU/s per container -- 400 -- Autoskalning mellan 100 och 1 000 RU/s
Maximalt antal RU:er Obegränsat i databasen. Obegränsat, på containern. Obegränsat i databasen. Obegränsat, på containern.
RU:er tilldelade eller tillgängliga för en specifik container Inga garantier. RU:er som tilldelats till en viss container beror på egenskaperna. Egenskaper kan vara valet av partitionsnycklar för containrar som delar dataflödet, arbetsbelastningens distribution och antalet containrar. Alla RU:er som konfigurerats på containern är exklusivt reserverade för containern. Inga garantier. RU:er som tilldelats till en viss container beror på egenskaperna. Egenskaper kan vara valet av partitionsnycklar för containrar som delar dataflödet, arbetsbelastningens distribution och antalet containrar. Alla RU:er som konfigurerats på containern är exklusivt 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 för en container 20 GB 20 GB 20 GB 20 GB

Nästa steg