Dela via

Metodtips för Azure Cosmos DB Java SDK

  • Artikel

GÄLLER FÖR: NoSQL

Den här artikeln går igenom metodtipsen för att använda Azure Cosmos DB Java SDK. Genom att följa dessa metoder kan du förbättra svarstiden, tillgängligheten och öka den övergripande prestandan.

Checklista

Kontrollerad Område Information/länkar
SDK-version Använd alltid den senaste versionen av Azure Cosmos DB SDK som är tillgänglig för optimala prestanda.
Singleton-klient Använd en enda instans av CosmosClient under programmets livslängd för bättre prestanda.
Regioner Se till att köra ditt program i samma Azure-region som ditt Azure Cosmos DB-konto när det är möjligt för att minska svarstiden. Aktivera 2–4 regioner och replikera dina konton i flera regioner för bästa tillgänglighet. Aktivera tjänsthanterad redundans för produktionsarbetsbelastningar. I avsaknad av den här konfigurationen kommer kontot att uppleva förlust av skrivtillgänglighet under hela skrivningsregionens avbrott, eftersom manuell redundans inte lyckas på grund av bristande regionanslutning. Om du vill veta hur du lägger till flera regioner med hjälp av Java SDK besöker du här
Tillgänglighet och redundans Ange preferredRegions i v4 SDK. Under redundansväxlingar skickas skrivåtgärder till den aktuella skrivregionen och alla läsningar skickas till den första regionen i listan över önskade regioner. Mer information om regional redundansmekanik finns i felsökningsguiden för tillgänglighet.
Processor Du kan stöta på problem med anslutning/tillgänglighet på grund av brist på resurser på klientdatorn. Övervaka cpu-användningen på noder som kör Azure Cosmos DB-klienten och skala upp/ut om användningen är mycket hög.
Värd För de vanligaste fallen av produktionsarbetsbelastningar rekommenderar vi starkt att du använder minst 4 kärnor och virtuella datorer med 8 GB minne när det är möjligt.
Anslutningslägen Använd direktläge för bästa prestanda. Anvisningar om hur du gör detta finns i V4 SDK-dokumentationen.
Nätverk Om du använder en virtuell dator för att köra programmet aktiverar du Accelererat nätverk på den virtuella datorn för att hjälpa till med flaskhalsar på grund av hög trafik och minska svarstiden eller CPU-jitter. Du kanske också vill överväga att använda en virtuell dator med högre slutpunkt där den maximala CPU-användningen är under 70 %.
Tillfällig portöverbelastning För glesa eller sporadiska anslutningar rekommenderar vi att du anger idleEndpointTimeout ett högre värde. Egenskapen idleEndpointTimeout i DirectConnectionConfig hjälper till att styra tiden då oanvända anslutningar stängs. Detta minskar antalet oanvända anslutningar. Som standard hålls inaktiva anslutningar till en slutpunkt öppna i 1 timme. Om det inte finns några begäranden till en specifik slutpunkt för tidsgränsen för inaktiv slutpunkt stänger direktklienten alla anslutningar till slutpunkten för att spara resurser och I/O-kostnader.
Använd Lämplig Scheduler (Undvik att stjäla IO Netty-trådar i händelseloopen) Undvik att blockera anrop: .block(). Hela anropsstacken är asynkron för att dra nytta av asynkrona API-mönster och användning av lämpliga trådar och schemaläggare
Tidsgränser från slutpunkt till slutpunkt Om du vill få timeout från slutpunkt till slutpunkt implementerar du timeout-principen från slutpunkt till slutpunkt i Java SDK. Mer information om tidsgränser med Azure Cosmos DB finns här
Logik för omprövning Ett tillfälligt fel är ett fel som har en underliggande orsak som snart löser sig själv. Program som ansluts till databasen bör anpassas för att klara av dessa tillfälliga fel. För att hantera dem implementerar du logik för återförsök i koden i stället för att visa dem för användare som programfel. SDK:n har inbyggd logik för att hantera dessa tillfälliga fel vid återförsöksbara begäranden som läs- eller frågeåtgärder. SDK:t försöker inte igen vid skrivningar för tillfälliga fel eftersom skrivningar inte är idempotenter. SDK tillåter användare att konfigurera omförsökslogik för begränsningar. Mer information om vilka fel som ska försöka igen finns här
Cachelagring av databas-/samlingsnamn Hämta namnen på dina databaser och containrar från konfigurationen eller cachelagrar dem vid start. Anrop som CosmosAsyncDatabase#read() eller CosmosAsyncContainer#read() resulterar i metadataanrop till tjänsten, som förbrukar från den systemreserverade RU-gränsen. createDatabaseIfNotExists() bör också endast användas en gång för att konfigurera databasen. Sammantaget bör dessa åtgärder utföras sällan.
Parallella frågor Azure Cosmos DB SDK stöder körning av frågor parallellt för bättre svarstid och dataflöde på dina frågor. Vi rekommenderar att du anger maxDegreeOfParallelism egenskapen inom CosmosQueryRequestsOptions det antal partitioner som du har. Om du inte känner till antalet partitioner anger du det värde -1 som ger dig bästa svarstid. Ange maxBufferedItemCount också till det förväntade antalet resultat som returneras för att begränsa antalet förhämtningsresultat.
Backoffs för prestandatestning När du utför testning i ditt program bör du implementera backoffs med RetryAfter jämna mellanrum. Om du respekterar backoffen ser du till att du ägnar minimal tid åt att vänta mellan återförsöken.
Indexering Med Azure Cosmos DB-indexeringsprincipen kan du också ange vilka dokumentsökvägar som ska inkluderas eller undantas från indexering med hjälp av indexeringssökvägar IndexingPolicy#getIncludedPaths() och IndexingPolicy#getExcludedPaths(). Se till att du undantar oanvända sökvägar från indexering för snabbare skrivningar. Ett exempel på hur du skapar index med hjälp av SDK finns här
Dokumentstorlek Begärandeavgiften för en angiven åtgärd korrelerar direkt med dokumentets storlek. Vi rekommenderar att du minskar storleken på dina dokument eftersom åtgärder på stora dokument kostar mer än åtgärder på mindre dokument.
Sidstorlek Som standard returneras frågeresultat i segment på 100 objekt eller 4 MB, beroende på vilken gräns som uppnås först. Om en fråga returnerar fler än 100 objekt ökar du sidstorleken för att minska antalet tur- och returresor som krävs. Minnesförbrukningen ökar när sidstorleken ökar.
Aktivera frågemått Om du vill ha ytterligare loggning av serverdelsfrågekörningar följer du anvisningarna om hur du samlar in SQL Query Metrics med Java SDK
SDK-loggning Använd SDK-loggning för att samla in ytterligare diagnostikinformation och felsöka problem med svarstid. Logga CosmosDiagnostics i Java SDK för mer detaljerad diagnostikinformation för Azure Cosmos DB för den aktuella begäran till tjänsten. Som ett exempel på användningsfall kan du samla in diagnostik för alla undantag och vid slutförda åtgärder om CosmosDiagnostics#getDuration() värdet är större än ett angivet tröskelvärde (dvs. om du har ett serviceavtal på 10 sekunder och sedan avbildar diagnostik när getDuration()> det är 10 sekunder). Vi rekommenderar att du endast använder den här diagnostiken under prestandatestningen. Mer information finns i avbilda diagnostik på Java SDK
Undvik att använda specialtecken i identifierare Vissa tecken är begränsade och kan inte användas i vissa identifierare: '/', '\', '?', '#'. Den allmänna rekommendationen är att inte använda några specialtecken i identifierare som databasnamn, samlingsnamn, objekt-ID eller partitionsnyckel för att undvika oväntade beteenden.

Metodtips vid användning av gatewayläge

Azure Cosmos DB-begäranden görs via HTTPS/REST när du använder gatewayläge. De omfattas av standardanslutningsgränsen per värdnamn eller IP-adress. Du kan behöva justera maxConnectionPoolSize till ett annat värde (från 100 till 1 000) så att klientbiblioteket kan använda flera samtidiga anslutningar till Azure Cosmos DB. I Java v4 SDK är standardvärdet för GatewayConnectionConfig#maxConnectionPoolSize 1 000. Om du vill ändra värdet kan du ange GatewayConnectionConfig#maxConnectionPoolSize ett annat värde.

Metodtips för skrivintensiva arbetsbelastningar

För arbetsbelastningar som har tunga nyttolaster anger du CosmosClientBuilder#contentResponseOnWriteEnabled() alternativet för begäran till false. Tjänsten returnerar inte längre den skapade eller uppdaterade resursen till SDK:n. Eftersom programmet har objektet som skapas behöver det normalt inte tjänsten för att returnera det. Huvudvärdena är fortfarande tillgängliga, till exempel en begärandeavgift. Om du inaktiverar innehållssvaret kan du förbättra prestandan eftersom SDK:n inte längre behöver allokera minne eller serialisera svarets brödtext. Det minskar också användningen av nätverksbandbredd för att ytterligare hjälpa prestanda.

Nästa steg

Mer information om prestandatips för Java SDK finns i Prestandatips för Azure Cosmos DB Java SDK v4.

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.