Introduktion till etablerat dataflöde i Azure Cosmos DB

GÄLLER för: SQL API API för Cassandra Gremlin API tabell-API Azure Cosmos DB API för MongoDB

Azure Cosmos DB kan du ange etablerat dataflöde på 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-databas är en hanteringsenhet för en uppsättning containrar. En databas består av en uppsättning schemaoberoende containrar. En Azure Cosmos-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 i alla Azure-regioner som är kopplade till ditt Azure Cosmos-konto.

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

  • Azure Cosmos-containrar
  • Azure Cosmos-databaser

Ange dataflöde för en container

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

Att ange etablerat dataflöde för en container är det alternativ som används oftast. 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 begäran (RU:er).

Dataflödet som etableras för en container fördelas jämnt mellan dess fysiska partitioner, och förutsatt att det finns en bra partitionsnyckel som distribuerar de logiska partitionerna jämnt mellan de fysiska partitionerna fördelas dataflödet 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 finns på en fysisk partition tillhör de fysiska partitionerna exklusivt containern och har stöd för det dataflöde som etableras i 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 blir hastighetsbegränsade. Det som kallas en heta partition inträffar när en logisk partition har oproportionerligt fler 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 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 vid 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 i 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 på en Azure Cosmos-databas delas dataflödet mellan alla containrar (kallas 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 i 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ägbar prestanda för en specifik container. Information om hur du konfigurerar etablerat dataflöde på en databas finns i Konfigurera etablerat dataflöde på en Azure Cosmos-databas. Information om hur du konfigurerar dataflöde för automatisk skalning för en databas finns i Etablera dataflöde för autoskalning.

Eftersom alla containrar i databasen delar det etablerade dataflödet Azure Cosmos DB inte några förutsägbara dataflödesgarantier för en viss container i databasen. Den del av dataflödet som en specifik container kan ta emot beror på:

  • Antalet containrar.
  • Valet av partitionsnycklar för olika containrar.
  • Distributionen av arbetsbelastningen över olika logiska partitioner av 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.

I följande exempel visas var du bör etablera dataflöde på databasnivå:

  • Att dela en databass etablerade dataflöde över en uppsättning containrar är användbart för ett program med flera olika program. Varje användare kan representeras av en distinkt Azure Cosmos-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 på din Azure Cosmos-databas som en logisk motsvarighet, men mer kostnadseffektiv och elastisk, med beräkningskapaciteten för mongoDB- eller Cassandra-klustret.

Alla containrar som skapas i en databas med etablerat dataflöde måste skapas med en partitionsnyckel. Vid en given 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 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 det dataflöde som allokeras till en specifik logisk partition är åtgärderna hastighetsbegränsade. När hastighetsbegränsningen inträffar kan du antingen öka dataflödet för hela databasen eller försöka 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 etablerat standarddataflöde (manuellt) kan du ha upp till 25 containrar med minst 400 RU/s i databasen. Med etablerat dataflöde för autoskalning kan du ha upp till 25 containrar i en databas med maximalt 4 000 RU/s autoskalning (skalar mellan 400–4 000 RU/s).

Anteckning

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

Om dina arbetsbelastningar inbegriper 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 du skapar en samling. 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 standard (manuellt) etablerat dataflöde på en Azure Cosmos-databas och en container:

  • Du kan skapa en Azure Cosmos-databas med namnet Z med det etablerade standarddataflödet (manuellt) 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 ska du aktivera alternativet Etablera dedikerat dataflöde för den här containern 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" RU:er hela tiden. Den backas upp av serviceavtal.

Anteckning

En container med etablerat dataflöde kan inte konverteras till en delad databascontainer. Omvänt går det inte att konvertera en delad databascontainer till ett dedikerat dataflöde.

Uppdatera dataflödet för en databas eller en container

När du har skapat en Azure Cosmos-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 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 minsta .

Om du ökar det etablerade dataflödet utförs åtgärden oftast omedelbart. Det finns dock fall där åtgärden kan ta längre tid på grund av systemaktiviteterna 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) (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 det etablerade dataflödet bör du komma ihåg 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 programmässigt kontrollera skalningsförloppet genom att läsa det aktuella etablerade dataflödet och använda:

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

Program för 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 fram 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 Azure Cosmos DB introducerat ett program för "hög lagring/lågt dataflöde" som minskar RU/s per GB-begränsning för berättigade konton.

Om du vill gå med i det här programmet och utvärdera ditt fullständiga berättigande behöver du bara fylla i den här undersökningen. Teamet Azure Cosmos DB sedan upp och fortsätter med onboarding-integreringen.

Jämförelse av modeller

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

Parameter Standarddataflöde (manuellt) för en databas Standardgenomflöde (manuellt) för en container Skala dataflöde automatiskt på en databas Autoskala dataflöde för en container
Startpunkt (minsta RU/s) 400 RU/s. Kan ha upp till 25 containrar utan ru/s minimum per container. 400 Autoskalning mellan 400–4 000 RU/s. Kan ha upp till 25 containrar utan ru/s minimum per container. Autoskalning mellan 400–4 000 RU/s.
Minsta RU/s per container -- 400 -- Autoskalning mellan 400–4 000 RU/s
Maximalt antal RU:er Obegränsat, i databasen. Obegränsat i containern. Obegränsat, i databasen. Obegränsat i containern.
RU:er tilldelade eller tillgängliga för en specifik container Inga garantier. RU:er som tilldelas till en viss container beror på egenskaperna. Egenskaper kan vara valet av partitionsnycklar för containrar som delar dataflödet, distributionen av arbetsbelastningen och antalet containrar. Alla RU:er som konfigurerats i containern är exklusivt reserverade för containern. Inga garantier. RU:er som tilldelas till en viss container beror på egenskaperna. Egenskaper kan vara valet av partitionsnycklar för containrar som delar dataflödet, distributionen av arbetsbelastningen och antalet containrar. Alla RU:er som konfigurerats i containern är exklusivt reserverade för containern.
Maximal lagring 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