Best practices voor Azure Cosmos DB Java SDK

  • Artikel

VAN TOEPASSING OP: NoSQL

In dit artikel worden de aanbevolen procedures beschreven voor het gebruik van de Azure Cosmos DB Java SDK. Als u deze procedures volgt, kunt u uw latentie, beschikbaarheid verbeteren en de algehele prestaties verbeteren.

Checklijst

Geselecteerd Onderwerp Details/koppelingen
SDK-versie Gebruik altijd de nieuwste versie van de Azure Cosmos DB SDK die beschikbaar is voor optimale prestaties.
Singleton-client Gebruik één exemplaar van CosmosClient de levensduur van uw toepassing voor betere prestaties.
Regio's Zorg ervoor dat u uw toepassing uitvoert in dezelfde Azure-regio als uw Azure Cosmos DB-account, indien mogelijk om de latentie te verminderen. Schakel 2-4 regio's in en repliceer uw accounts in meerdere regio's voor de beste beschikbaarheid. Voor productieworkloads schakelt u door de service beheerde failover in. Bij afwezigheid van deze configuratie ondervindt het account verlies van schrijf beschikbaarheid voor alle duur van de storing in de schrijfregio, omdat handmatige failover niet slaagt vanwege een gebrek aan regioverbinding. Als u wilt weten hoe u meerdere regio's toevoegt met behulp van de Java SDK, gaat u hier naar
Beschikbaarheid en failovers Stel de preferredRegions in de v4 SDK in. Tijdens failovers worden schrijfbewerkingen verzonden naar de huidige schrijfregio en worden alle leesbewerkingen verzonden naar de eerste regio in de lijst met voorkeursregio's. Zie de handleiding voor het oplossen van problemen met beschikbaarheid voor meer informatie over regionale failovermechanica.
CPU Mogelijk ondervindt u problemen met connectiviteit/beschikbaarheid vanwege een gebrek aan resources op uw clientcomputer. Bewaak uw CPU-gebruik op knooppunten met de Azure Cosmos DB-client en schaal omhoog/uit als het gebruik erg hoog is.
Hosting Voor de meest voorkomende gevallen van productieworkloads raden we u ten zeerste aan om waar mogelijk ten minste vier kernen en 8 GB geheugen-VM's te gebruiken.
Verbinding maken iviteitsmodi Gebruik de directe modus voor de beste prestaties. Zie de V4 SDK-documentatie voor instructies over hoe u dit doet.
Netwerken Als u een virtuele machine gebruikt om uw toepassing uit te voeren, schakelt u Versneld netwerken op uw VIRTUELE machine in om te helpen bij knelpunten vanwege hoog verkeer en om latentie of CPU-jitter te verminderen. U kunt ook overwegen een hogere virtuele machine te gebruiken waarbij het maximale CPU-gebruik lager is dan 70%.
Tijdelijke poortuitputting Voor sparse- of sporadische verbindingen raden we u aan om de idleEndpointTimeout waarde in te stellen op een hogere waarde. De idleEndpointTimeout eigenschap helpt DirectConnectionConfig bij het beheren van de tijd dat ongebruikte verbindingen worden gesloten. Dit vermindert het aantal ongebruikte verbindingen. Standaard worden niet-actieve verbindingen met een eindpunt gedurende 1 uur geopend. Als er geen aanvragen zijn voor een specifiek eindpunt voor time-outduur van een niet-actief eindpunt, sluit de directe client alle verbindingen met dat eindpunt om resources en I/O-kosten te besparen.
Geschikte Scheduler gebruiken (vermijd het stelen van Io Netty-threads voor gebeurtenislus) Voorkom het blokkeren van aanroepen: .block(). De volledige aanroepstack is asynchroon om te profiteren van asynchrone API-patronen en het gebruik van de juiste threading en schedulers
End-to-end time-outs Als u end-to-end time-outs wilt ophalen, implementeert u end-to-end time-outbeleid in de Java SDK. Bezoek hier voor meer informatie over time-outs met Azure Cosmos DB
Logica voor opnieuw proberen Een tijdelijke fout is een fout met een onderliggende oorzaak die zich snel oplost. Toepassingen die verbinding maken met uw database, moeten zo worden gebouwd dat ze deze tijdelijke fouten verwachten. Als u ze wilt afhandelen, implementeert u logica voor opnieuw proberen in uw code in plaats van ze als toepassingsfouten weer te geven aan gebruikers. De SDK heeft ingebouwde logica voor het afhandelen van deze tijdelijke fouten bij opnieuw te proberen aanvragen, zoals lees- of querybewerkingen. De SDK probeert geen schrijfbewerkingen opnieuw voor tijdelijke fouten, omdat schrijfbewerkingen niet idempotent zijn. Met de SDK kunnen gebruikers logica voor opnieuw proberen configureren voor beperkingen. Meer informatie over welke fouten u hier opnieuw kunt proberen
Namen van databases/verzamelingen opslaan in cache Haal de namen van uw databases en containers op uit de configuratie of cache ze op het begin. Aanroepen zoals CosmosAsyncDatabase#read() of CosmosAsyncContainer#read() resulteren in metagegevens aanroepen naar de service, die verbruiken van de door het systeem gereserveerde RU-limiet. createDatabaseIfNotExists() mag ook slechts eenmaal worden gebruikt voor het instellen van de database. Over het algemeen moeten deze bewerkingen onregelmatig worden uitgevoerd.
Parallelle query's De Azure Cosmos DB SDK biedt ondersteuning voor het parallel uitvoeren van query's voor betere latentie en doorvoer voor uw query's. U wordt aangeraden de maxDegreeOfParallelism eigenschap in te stellen op het CosmosQueryRequestsOptions aantal partities dat u hebt. Als u zich niet bewust bent van het aantal partities, stelt u de waarde in op -1 die waarde geeft u de beste latentie. Stel ook het maxBufferedItemCount verwachte aantal geretourneerde resultaten in om het aantal vooraf opgehaalde resultaten te beperken.
Uitstel van prestaties testen Wanneer u tests uitvoert op uw toepassing, moet u tussenpozen back-offs RetryAfter implementeren. Het respecteren van de uitstel helpt ervoor te zorgen dat u een minimale hoeveelheid tijd besteedt aan het wachten tussen nieuwe pogingen.
Indexeren Met het indexeringsbeleid van Azure Cosmos DB kunt u ook opgeven welke documentpaden moeten worden opgenomen of uitgesloten van indexering met behulp van indexeringspaden IndexingPolicy#getIncludedPaths() en IndexingPolicy#getExcludedPaths(). Zorg ervoor dat u ongebruikte paden uitsluit van indexering voor snellere schrijfbewerkingen. Voor een voorbeeld van het maken van indexen met behulp van de SDK gaat u hier naar
Documentgrootte De aanvraagkosten van een opgegeven bewerking komen rechtstreeks overeen met de grootte van het document. Het is raadzaam om de grootte van uw documenten te verkleinen als bewerkingen voor grote documenten meer kosten dan bewerkingen op kleinere documenten.
Paginagrootte Standaard worden queryresultaten geretourneerd in segmenten van 100 items of 4 MB, afhankelijk van welke limiet het eerst wordt bereikt. Als een query meer dan 100 items retourneert, verhoogt u het paginaformaat om het aantal benodigde retouren te verminderen. Het geheugenverbruik neemt toe naarmate het paginaformaat toeneemt.
Metrische querygegevens inschakelen Volg de instructies voor het vastleggen van metrische SQL-querygegevens met behulp van Java SDK voor aanvullende logboekregistratie van uw back-endquery's
SDK-logboekregistratie Gebruik SDK-logboekregistratie om aanvullende diagnostische gegevens vast te leggen en latentieproblemen op te lossen. Log de CosmosDiagnostics in Java SDK voor gedetailleerdere diagnostische gegevens van Azure Cosmos DB voor de huidige aanvraag naar de service. Als voorbeeld van een use-case legt u diagnostische gegevens vast op een uitzondering en bij voltooide bewerkingen als de CosmosDiagnostics#getDuration() drempelwaarde groter is dan een aangewezen drempelwaarde (dat wil bijvoorbeeld als u een SLA van 10 seconden hebt, legt u diagnostische gegevens vast wanneer getDuration()> 10 seconden). Het is raadzaam deze diagnostische gegevens alleen te gebruiken tijdens het testen van de prestaties. Volg diagnostische gegevens vastleggen in Java SDK voor meer informatie
Vermijd het gebruik van speciale tekens in id's Sommige tekens zijn beperkt en kunnen niet worden gebruikt in sommige id's: '/', '\', '?', '#'. De algemene aanbeveling is om geen speciale tekens te gebruiken in id's zoals databasenaam, verzamelingsnaam, item-id of partitiesleutel om onverwacht gedrag te voorkomen.

Aanbevolen procedures bij het gebruik van de gatewaymodus

Azure Cosmos DB-aanvragen worden uitgevoerd via HTTPS/REST wanneer u de gatewaymodus gebruikt. Ze zijn onderworpen aan de standaardverbindingslimiet per hostnaam of IP-adres. Mogelijk moet u max Verbinding maken ionPoolSize aanpassen aan een andere waarde (van 100 tot en met 1000), zodat de clientbibliotheek meerdere gelijktijdige verbindingen met Azure Cosmos DB kan gebruiken. In java v4 SDK is de standaardwaarde GatewayConnectionConfig#maxConnectionPoolSize voor 1000. Als u de waarde wilt wijzigen, kunt u instellen GatewayConnectionConfig#maxConnectionPoolSize op een andere waarde.

Best practices voor schrijfintensieve workloads

Voor workloads met zware nettoladingen kunt u de CosmosClientBuilder#contentResponseOnWriteEnabled() aanvraagoptie instellen op false. De service retourneert de gemaakte of bijgewerkte resource niet meer naar de SDK. Normaal gesproken heeft de toepassing het object dat wordt gemaakt, niet nodig om het te retourneren. De headerwaarden zijn nog steeds toegankelijk, zoals een aanvraagkosten. Als u het antwoord op inhoud uitschakelt, kunt u de prestaties verbeteren, omdat de SDK geen geheugen meer hoeft toe te wijzen of de hoofdtekst van het antwoord serialiseert. Het vermindert ook het netwerkbandbreedtegebruik om de prestaties verder te helpen.

Volgende stappen

Zie prestatietips voor Azure Cosmos DB Java SDK v4 voor meer informatie over prestatietips voor Java SDK.

Zie Partitioneren en schalen in Azure Cosmos DB voor meer informatie over het ontwerpen van uw toepassing voor schaalaanpassing en hoge prestaties.

Wilt u capaciteitsplanning uitvoeren voor een migratie naar Azure Cosmos DB? U kunt informatie over uw bestaande databasecluster gebruiken voor capaciteitsplanning.