Prestandatips för Azure Cosmos DB Python SDK

GÄLLER FÖR: NoSQL

Azure Cosmos DB är en snabb och flexibel distribuerad databas som skalas sömlöst med garanterad svarstid och dataflöde. Du behöver inte göra större arkitekturändringar eller skriva komplex kod för att skala databasen med Azure Cosmos DB. Det är lika enkelt att skala upp och ned som att göra ett enda API-anrop eller ett SDK-metodanrop. Men eftersom Azure Cosmos DB nås via nätverksanrop finns det optimeringar på klientsidan som du kan göra för att uppnå högsta prestanda när du använder Azure Cosmos DB Python SDK.

Så om du frågar "Hur kan jag förbättra mina databasprestanda?" bör du överväga följande alternativ:

Nätverk

• Samla klienter i samma Azure-region för prestanda

När det är möjligt placerar du alla program som anropar Azure Cosmos DB i samma region som Azure Cosmos DB-databasen. För en ungefärlig jämförelse slutförs anrop till Azure Cosmos DB inom samma region inom 1–2 ms, men svarstiden mellan USA:s västra och östra kust är >50 ms. Den här svarstiden kan sannolikt variera från begäran till begäran beroende på vilken väg begäran tar när den skickas från klienten till Gränsen för Azure-datacenter. Den lägsta möjliga svarstiden uppnås genom att säkerställa att det anropande programmet finns i samma Azure-region som den etablerade Azure Cosmos DB-slutpunkten. En lista över tillgängliga regioner finns i Azure-regioner.

En app som interagerar med ett Azure Cosmos DB-konto i flera regioner måste konfigurera önskade platser för att säkerställa att begäranden går till en samordnad region.

Aktivera accelererat nätverk för att minska svarstiden och CPU-jitter

Vi rekommenderar att du följer anvisningarna för att aktivera accelererat nätverk i windows (välj instruktioner) eller Linux (välj för instruktioner) virtuella Azure-datorer för att maximera prestanda (minska svarstiden och CPU-jitter).

Utan accelererat nätverk kan I/O som överförs mellan din virtuella Azure-dator och andra Azure-resurser i onödan dirigeras via en värd och en virtuell växel mellan den virtuella datorn och dess nätverkskort. Att ha värden och den virtuella växeln infogade i datasökvägen ökar inte bara latensen och jitter i kommunikationskanalen, utan stjäl även CPU-cykler från den virtuella maskinen. Med accelererat nätverk ansluter den virtuella datorn direkt till nätverkskortet utan några mellanhänder. Alla nätverkspolicyer som hanterades av värden och den virtuella växeln hanteras nu i maskinvaran på nätverkskortet. Värden och den virtuella växeln förbigås. Vanligtvis kan du förvänta dig lägre svarstid och högre dataflöde, samt mer konsekvent svarstid och minskad CPU-användning när du aktiverar accelererat nätverk.

Begränsningar: Accelererat nätverk måste stödjas på det virtuella datoroperativsystemet och kan bara aktiveras när den virtuella datorn stoppas och frigörs. Det går inte att distribuera den virtuella datorn med Azure Resource Manager. App Service har inget accelererat nätverk aktiverat.

Mer information finns i Windows- och Linux-instruktionerna.

Hög tillgänglighet

Allmän vägledning om hur du konfigurerar hög tillgänglighet i Azure Cosmos DB finns i Hög tillgänglighet i Azure Cosmos DB.

Förutom en bra grundläggande konfiguration i databasplattformen kan kretsbrytare på partitionsnivå implementeras i Python SDK, vilket kan hjälpa dig i avbrottsscenarier. Den här funktionen ger avancerade mekanismer tillgänglighetsutmaningar som går utöver de funktioner för återförsök mellan regioner som är inbyggda i SDK:et som standard. Detta kan avsevärt förbättra programmets motståndskraft och prestanda, särskilt under hög belastning eller försämrade förhållanden.

Kretsbrytare på partitionsnivå

Kretsbrytaren på partitionsnivå (PPCB) i Python SDK förbättrar tillgängligheten och motståndskraften genom att spåra hälsotillståndet för enskilda fysiska partitioner och routningsbegäranden bort från problematiska. Den här funktionen är särskilt användbar för hantering av tillfälliga problem och terminalproblem som nätverksproblem, partitionsuppgraderingar eller migreringar.

PPCB gäller i följande scenarier:

• Alla konsistensnivåer
• Åtgärder med partitionsnyckel (punktläsningar/skrivningar)
• Konton för en enda skrivregion med flera läsregioner
• Konton för flera skrivregioner

Så här fungerar det

Partitioner övergår genom fyra tillstånd – Felfri, Ej felfri preliminär, Ej felfri och Felfri preliminär – baserat på lyckade eller misslyckade begäranden:

1. Felspårning: SDK övervakar felfrekvenser (t.ex. 5xx, 408) per partition under ett fönster på en minut. Efterföljande fel per partition spåras på obestämd tid av SDK:et.
2. Märkning som otillgänglig: Om en partition överskrider konfigurerade tröskelvärden markeras den som Ej felfri preliminär och undantas från routning i 1 minut.
3. Upphöjning till Ej felfri eller Återställning: Om återställningsförsök misslyckas övergår partitionen till Inte felfri. Efter ett backoff-intervall görs en felfri preliminär avsökning med en begäran om begränsad tid för att fastställa återställningen.
4. Återinförande: Om den preliminära avsökningen lyckas återgår partitionen till Felfri. Annars förblir den Ohälsosam till nästa undersökning.

Den här redundansväxlingen hanteras internt av SDK och säkerställer att begäranden undviker kända problematiska partitioner tills de bekräftas vara felfria igen.

Konfiguration via miljövariabler

Du kan styra PPCB-beteendet med hjälp av dessa miljövariabler:

Undantagna regioner

Funktionen exkluderade regioner ger detaljerad kontroll över begärandedirigering genom att tillåta att du exkluderar specifika regioner från önskade platser per begäran. Den här funktionen är tillgänglig i Azure Cosmos DB Python SDK version 4.14.0 och senare.

Viktiga fördelar:

• Hantera hastighetsbegränsning: När du stöter på svar på 429 (för många begäranden) dirigerar du automatiskt begäranden till alternativa regioner med tillgängligt dataflöde
• Riktad routning: Se till att begäranden hanteras från specifika regioner genom att exkludera alla andra
• Kringgå önskad ordning: Åsidosätt standardlistan för prioriterade regioner för enskilda begäranden utan att skapa separata klienter

Configuration:

Undantagna regioner kan konfigureras på både klientnivå och begärandenivå:

from azure.cosmos import CosmosClient
from azure.cosmos.partition_key import PartitionKey

# Configure preferred locations and excluded locations at client level
preferred_locations = ['West US 3', 'West US', 'East US 2']
excluded_locations_on_client = ['West US 3', 'West US']

client = CosmosClient(
    url=HOST,
    credential=MASTER_KEY,
    preferred_locations=preferred_locations,
    excluded_locations=excluded_locations_on_client
)

database = client.create_database('TestDB')
container = database.create_container(
    id='TestContainer',
    partition_key=PartitionKey(path="/pk")
)

# Create an item (writes ignore excluded_locations in single-region write accounts)
test_item = {
    'id': 'Item_1',
    'pk': 'PartitionKey_1',
    'test_object': True,
    'lastName': 'Smith'
}
created_item = container.create_item(test_item)

# Read operations will use preferred_locations minus excluded_locations
# In this example: ['West US 3', 'West US', 'East US 2'] - ['West US 3', 'West US'] = ['East US 2']
item = container.read_item(
    item=created_item['id'],
    partition_key=created_item['pk']
)

Uteslutna regioner på begäransnivå:

Undantagna regioner på begäransnivå har högsta prioritet och åsidosätter inställningar på klientnivå:

# Excluded locations can be specified per request, overriding client settings
excluded_locations_on_request = ['West US 3']

# Create item with request-level excluded regions
created_item = container.create_item(
    test_item,
    excluded_locations=excluded_locations_on_request
)

# Read with request-level excluded regions
# This will use: ['West US 3', 'West US', 'East US 2'] - ['West US 3'] = ['West US', 'East US 2']
item = container.read_item(
    item=created_item['id'],
    partition_key=created_item['pk'],
    excluded_locations=excluded_locations_on_request
)

Finjustering av konsistens och tillgänglighet

Funktionen exkluderade regioner ger ytterligare en mekanism för att balansera konsekvens- och tillgänglighetsutjämningar i ditt program. Den här funktionen är särskilt värdefull i dynamiska scenarier där kraven kan ändras baserat på driftsförhållanden:

Dynamisk avbrottshantering: När en primär region upplever ett avbrott och tröskelvärden för kretsbrytare på partitionsnivå visar sig vara otillräckliga möjliggör exkluderade regioner omedelbar redundans utan kodändringar eller programomstarter. Detta ger snabbare svar på regionala problem jämfört med att vänta på automatisk aktivering av kretsbrytare.

Inställningar för villkorsstyrd konsekvens: Program kan implementera olika konsekvensstrategier baserat på drifttillstånd:

• Stabilt tillstånd: Prioritera konsekvent dataläsning genom att utesluta alla regioner utom den primära, vilket säkerställer datakonsistens även om det påverkar tillgängligheten.
• Avbrottsscenarier: Prioritera tillgänglighet framför strikt konsekvens genom att tillåta routning mellan regioner, acceptera potentiell datafördröjning i utbyte mot fortsatt tjänsttillgänglighet

Den här metoden gör det möjligt för externa mekanismer (till exempel trafikhanterare eller lastbalanserare) att samordna redundansbeslut medan programmet har kontroll över konsekvenskraven genom mönster för regionsundantag.

När alla regioner undantas dirigeras begäranden till den primära/hubbregionen. Den här funktionen fungerar med alla typer av begäranden, inklusive frågor och är särskilt användbar för att underhålla singleton-klientinstanser samtidigt som du uppnår ett flexibelt routningsbeteende.

SDK-användning

• Installera den senaste SDK:en

Azure Cosmos DB SDK:er förbättras ständigt för att ge bästa möjliga prestanda. Se release notes för Azure Cosmos DB SDK för att se den senaste SDK:n och granska förbättringar.

• Använda en Singleton Azure Cosmos DB-klient under programmets livslängd

Varje Azure Cosmos DB-klientinstans är trådsäker och utför effektiv anslutningshantering och adresscachelagring. För att möjliggöra effektiv anslutningshantering och bättre prestanda för Azure Cosmos DB-klienten rekommenderar vi att du använder en enda instans av Azure Cosmos DB-klienten under programmets livslängd.

• Justera timeout- och återförsökskonfigurationer

Tidsgränskonfigurationer och återförsöksprinciper kan anpassas baserat på programmets behov. Se dokumentet om tidsgräns och återförsök för att få en fullständig lista över konfigurationer som kan anpassas.

• Använd den lägsta konsekvensnivå som krävs för din applikation

När du skapar en CosmosClient används konsekvens på kontonivå om inget anges vid skapandet av klienten. Mer information om konsekvensnivåer finns i dokumentet om konsekvensnivåer .

• Skala ut din klientarbetsbelastning

Om du testar på höga dataflödesnivåer kan klientprogrammet bli flaskhalsen på grund av att datorn begränsar processor- eller nätverksanvändningen. Om du når den här punkten kan du fortsätta att optimera Azure Cosmos DB-kontot ytterligare genom att skala ut dina klientapplikationer över flera servrar.

En bra tumregel är att inte överskrida >50 % processoranvändning på en viss server för att hålla svarstiden låg.

• Resursgräns för öppna OS-filer

Vissa Linux-system (till exempel Red Hat) har en övre gräns för antalet öppna filer och därmed det totala antalet anslutningar. Kör följande för att visa de aktuella gränserna:

ulimit -a

Antalet öppna filer (nofile) måste vara tillräckligt stort för att ha tillräckligt med utrymme för din konfigurerade storlek på anslutningspoolen och andra öppna filer i operativsystemet. Den kan ändras för att tillåta en större storlek på anslutningspoolen.

Öppna filen limits.conf:

vim /etc/security/limits.conf

Lägg till/ändra följande rader:

* - nofile 100000

Frågeoperationer

Information om frågeåtgärder finns i prestandatipsen för frågor.

Indexeringsprincip

• Utesluta sökvägar som inte används från indexering för att få snabbare skrivning

Med Azure Cosmos DB:s indexeringsprincip kan du ange vilka dokumentsökvägar som ska inkluderas eller undantas från indexering genom att använda indexeringssökvägar (setIncludedPaths och setExcludedPaths). Användningen av indexeringssökvägar kan ge bättre skrivprestanda och lägre indexlagring för scenarier där frågemönstren är kända i förväg, eftersom indexeringskostnaderna är direkt korrelerade med antalet indexerade unika sökvägar. Följande kod visar till exempel hur du inkluderar och exkluderar hela delar av dokumenten (kallas även för ett underträd) från indexering med jokertecknet "*".

container_id = "excluded_path_container"
indexing_policy = {
        "includedPaths" : [ {'path' : "/*"} ],
        "excludedPaths" : [ {'path' : "/non_indexed_content/*"} ]
        }
db.create_container(
    id=container_id,
    indexing_policy=indexing_policy,
    partition_key=PartitionKey(path="/pk"))

Mer information finns i Azure Cosmos DB-indexeringsprinciper.

Genomflöde

• Mät och justera för lägre förbrukade förfrågningsenheter per sekund

Azure Cosmos DB erbjuder en omfattande uppsättning databasåtgärder, inklusive relationsfrågor och hierarkiska frågor med UDF:er, lagrade procedurer och utlösare – som alla körs på dokumenten i en databassamling. Den kostnad som hör till var och en av dessa operationer varierar baserat på vilken CPU, vilka IO-resurser och hur mycket minne som krävs för att slutföra operationen. I stället för att tänka på och hantera maskinvaruresurser kan du betrakta en enhet för begäran (RU) som ett enda mått för de resurser som krävs för att utföra olika databasåtgärder och hantera en programbegäran.

Genomflödet etableras baserat på antalet begärandeenheter som angetts för varje container. Begärans enhetsförbrukning utvärderas som en takt per sekund. Applikationer som överskrider den tilldelade begärandeenhetsfrekvensen för deras container begränsas tills frekvensen sjunker under den tilldelade nivån för containern. Om programmet kräver ett högre dataflöde kan du öka dataflödet genom att etablera ytterligare enheter för begäranden.

Komplexiteten i en sökfråga påverkar hur många begärandenheter som används för en åtgärd. Antalet predikat, predikatens natur, antalet UDF:er och storleken på källdatauppsättningen påverkar alla kostnaden för frågeåtgärder.

Om du vill mäta överbelastningen för en åtgärd (skapa, uppdatera eller ta bort) ska du granska x-ms-request-charge-rubriken för att mäta antalet begärandeenheter som förbrukas av dessa åtgärder.

document_definition = {
    'id': 'document',
    'key': 'value',
    'pk': 'pk'
}
document = container.create_item(
    body=document_definition,
)
print("Request charge is : ", container.client_connection.last_response_headers['x-ms-request-charge'])

Den begärandeavgift som returneras i denna header är en bråkdel av din tilldelade genomströmning. Om du till exempel har etablerat 2 000 RU/s och om föregående fråga returnerar 1 000 1 KB-dokument är kostnaden för åtgärden 1 000. Därför respekterar servern bara två sådana begäranden inom en sekund innan efterföljande begäranden begränsas. För mer information, se Begäransenheter och begäransenhetens kalkylator.

• Hantera hastighetsbegränsning/begärandefrekvens för stor

När en klient försöker överskrida det reserverade dataflödet för ett konto sker ingen prestandaförsämring på servern och ingen användning av dataflödeskapacitet utöver den reserverade nivån. Servern avslutar begäran i förebyggande syfte med RequestRateTooLarge (HTTP-statuskod 429) och returnerar rubriken x-ms-retry-after-ms som anger hur lång tid, i millisekunder, som användaren måste vänta innan begäran försöker igen.

HTTP Status 429,
Status Line: RequestRateTooLarge
x-ms-retry-after-ms :100

SDK:erna fångar implicit alla dessa svar, respekterar serverns angivna retry-after-header och försöker igen med begäran. Om inte ditt konto används samtidigt av flera klienter kommer nästa återförsök att lyckas.

Om du har fler än en klient som kumulativt fungerar konsekvent över begärandefrekvensen kanske standardantalet för återförsök som för närvarande är inställt på 9 internt av klienten kanske inte räcker. I det här fallet genererar klienten en CosmosHttpResponseError med statuskod 429 till programmet. Standardinställningen för antal gånger för återförsök kan ändras genom att skicka konfiguration retry_total till klienten. Som standard returneras CosmosHttpResponseError med statuskod 429 efter en kumulativ väntetid på 30 sekunder om begäran fortsätter att fungera över begärandefrekvensen. Detta inträffar även om det aktuella antalet återförsök är mindre än det maximala antalet återförsök, oavsett om det är standardvärdet 9 eller ett användardefinierat värde.

Även om det automatiserade återförsöksbeteendet hjälper till att förbättra återhämtning och användbarhet för de flesta program, kan det komma till odds när prestandamått utförs, särskilt när svarstiden mäts. Den klient observerade svarstiden ökar om experimentet når serverbegränsningen och gör att klient-SDK:t tyst försöker igen. För att undvika latensspikar under prestandaförsök mäter du laddningen som returneras av varje åtgärd och ser till att begäranden håller sig under den reserverade begärandefrekvensen. Mer information finns i Enheter för begäran.

• Designa för mindre dokument för högre dataflöde

Begärandeavgiften (kostnaden för bearbetning av begäran) för en viss åtgärd är direkt korrelerad till dokumentets storlek. Åtgärder på stora dokument kostar mer än åtgärder för små dokument. Vi rekommenderar att du utformar ditt program och arbetsflöden så att objektstorleken är ~1 KB eller liknande ordning eller storlek. För svarstidskänsliga program bör stora objekt undvikas – dokument med flera MB gör programmet långsammare.

Nästa steg

Mer information om hur du utformar ditt program för skalning och höga prestanda finns i Partitionering och skalning i Azure Cosmos DB.

Försöker du planera kapacitet för en migrering till Azure Cosmos DB? Du kan använda information om ditt befintliga databaskluster för kapacitetsplanering.

• Om allt du vet är antalet virtuella kärnor och servrar i ditt befintliga databaskluster, läs om att uppskatta förfrågningsenheter med virtuella kärnor eller vCPUs
• Om du känner till vanliga begärandefrekvenser för din aktuella databasarbetsbelastning kan du läsa om att uppskatta enheter för begäranden med azure Cosmos DB-kapacitetshanteraren