Share via

Tips voor betere prestaties voor Azure Cosmos DB Sync Java SDK v2

  • Artikel

VAN TOEPASSING OP: NoSQL

Belangrijk

Dit is niet de nieuwste Java SDK voor Azure Cosmos DB. U moet uw project upgraden naar Azure Cosmos DB Java SDK v4 en vervolgens de handleiding met tips voor prestaties van Azure Cosmos DB Java SDK v4 lezen. Volg de instructies in de handleiding Migreren naar Azure Cosmos DB Java SDK v4 en Reactor vs RxJava-handleiding om een upgrade uit te voeren.

Deze tips voor prestaties zijn alleen geschikt voor Azure Cosmos DB Sync Java SDK v2. Bekijk de Maven-opslagplaats voor meer informatie.

Belangrijk

Op 29 februari 2024 wordt de Azure Cosmos DB Sync Java SDK v2.x buiten gebruik gesteld; de SDK en alle toepassingen die gebruikmaken van de SDK blijven functioneren; Azure Cosmos DB biedt eenvoudigweg geen onderhoud meer en ondersteuning voor deze SDK. U wordt aangeraden de bovenstaande instructies te volgen om te migreren naar Azure Cosmos DB Java SDK v4.

Azure Cosmos DB is een snelle en flexibele gedistribueerde database die naadloos wordt geschaald met gegarandeerde latentie en doorvoer. U hoeft geen belangrijke architectuurwijzigingen aan te brengen of complexe code te schrijven om uw database te schalen met Azure Cosmos DB. Omhoog en omlaag schalen is net zo eenvoudig als het maken van één API-aanroep. Zie voor meer informatie hoe u containerdoorvoer inricht of hoe u databasedoorvoer inricht. Omdat Azure Cosmos DB echter toegankelijk is via netwerkaanroepen, zijn er optimalisaties aan de clientzijde die u kunt aanbrengen om piekprestaties te bereiken wanneer u Azure Cosmos DB Sync Java SDK v2 gebruikt.

Dus als u 'Hoe kan ik de prestaties van mijn database verbeteren?' vraagt, moet u rekening houden met de volgende opties:

Netwerken

  1. Verbindingsmodus: DirectHttps gebruiken

    Hoe een client verbinding maakt met Azure Cosmos DB is belangrijk voor de prestaties, in het bijzonder wat betreft de latentie aan de clientzijde. Er is één sleutelconfiguratie-instelling beschikbaar voor het configureren van de client ConnectionPolicy : de ConnectionMode. De twee beschikbare ConnectionModes zijn:

    1. Gateway (standaard)

    2. DirectHttps

      De gatewaymodus wordt ondersteund op alle SDK-platforms en is de geconfigureerde standaardinstelling. Als uw toepassing wordt uitgevoerd binnen een bedrijfsnetwerk met strikte firewallbeperkingen, is Gateway de beste keuze omdat deze gebruikmaakt van de standaard HTTPS-poort en één eindpunt. Het nadeel van de prestaties is echter dat de gatewaymodus een extra netwerkhop omvat telkens wanneer gegevens naar Azure Cosmos DB worden gelezen of geschreven. Hierdoor biedt de DirectHttps-modus betere prestaties vanwege minder netwerkhops.

      De Azure Cosmos DB Sync Java SDK v2 maakt gebruik van HTTPS als transportprotocol. HTTPS maakt gebruik van TLS voor initiële verificatie en het versleutelen van verkeer. Wanneer u de Azure Cosmos DB Sync Java SDK v2 gebruikt, moet alleen HTTPS-poort 443 worden geopend.

      De ConnectionMode is geconfigureerd tijdens de bouw van het DocumentClient-exemplaar met de parameter ConnectionPolicy.

    Java SDK V2 synchroniseren (Maven com.microsoft.azure::azure-documentdb)

    public ConnectionPolicy getConnectionPolicy() {
  ConnectionPolicy policy = new ConnectionPolicy();
  policy.setConnectionMode(ConnectionMode.DirectHttps);
  policy.setMaxPoolSize(1000);
  return policy;
}

ConnectionPolicy connectionPolicy = new ConnectionPolicy();
DocumentClient client = new DocumentClient(HOST, MASTER_KEY, connectionPolicy, null);

    Diagram toont het verbindingsbeleid van Azure Cosmos DB.

  2. Clients in dezelfde Azure-regio plaatsen voor prestaties

    Plaats indien mogelijk toepassingen die Azure Cosmos DB aanroepen in dezelfde regio als de Azure Cosmos DB-database. Voor een geschatte vergelijking zijn aanroepen naar Azure Cosmos DB binnen dezelfde regio voltooid binnen 1-2 ms, maar de latentie tussen de west- en oostkust van de VS is >50 ms. Deze latentie kan waarschijnlijk variëren van aanvraag tot aanvraag, afhankelijk van de route die door de aanvraag wordt genomen, omdat deze wordt doorgegeven van de client naar de grens van het Azure-datacenter. De laagst mogelijke latentie wordt bereikt door ervoor te zorgen dat de aanroepende toepassing zich in dezelfde Azure-regio bevindt als het ingerichte Azure Cosmos DB-eindpunt. Zie Azure-regio's voor een lijst met beschikbare regio's.

    Diagram toont aanvragen en antwoorden in twee regio's, waarbij computers verbinding maken met een Azure Cosmos DB-account via services in de middellaag.

SDK-gebruik

  1. De meest recente SDK installeren

    De Azure Cosmos DB SDK's worden voortdurend verbeterd om de beste prestaties te bieden. Ga naar de Azure Cosmos DB SDK om de meest recente SDK-verbeteringen te bepalen.

  2. Een Singleton Azure Cosmos DB-client gebruiken voor de levensduur van uw toepassing

    Elk DocumentClient-exemplaar is thread-veilig en voert efficiënt verbindingsbeheer en adrescaching uit wanneer u in de directe modus werkt. Om efficiënt verbindingsbeheer en betere prestaties van DocumentClient mogelijk te maken, is het raadzaam om één exemplaar van DocumentClient per AppDomain te gebruiken voor de levensduur van de toepassing.

  3. MaxPoolSize per host verhogen wanneer u de gatewaymodus gebruikt

    Azure Cosmos DB-aanvragen worden uitgevoerd via HTTPS/REST wanneer u de gatewaymodus gebruikt en worden onderworpen aan de standaardverbindingslimiet per hostnaam of IP-adres. Mogelijk moet u MaxPoolSize instellen op een hogere waarde (200-1000), zodat de clientbibliotheek meerdere gelijktijdige verbindingen met Azure Cosmos DB kan gebruiken. In de Azure Cosmos DB Sync Java SDK v2 is de standaardwaarde voor ConnectionPolicy.getMaxPoolSize 100. Gebruik setMaxPoolSize om de waarde te wijzigen.

  4. Parallelle query's afstemmen voor gepartitioneerde verzamelingen

    Azure Cosmos DB Sync Java SDK versie 1.9.0 en hoger ondersteunen parallelle query's, waarmee u een query kunt uitvoeren op een gepartitioneerde verzameling parallel. Zie codevoorbeelden met betrekking tot het werken met de SDK's voor meer informatie. Parallelle query's zijn ontworpen om de querylatentie en doorvoer te verbeteren ten opzichte van hun seriële tegenhanger.

    a) SetMaxDegreeOfParallelism afstemmen: parallelle query's werken door query's uit te voeren op meerdere partities parallel. Gegevens uit een afzonderlijke gepartitioneerde verzameling worden echter serieel opgehaald met betrekking tot de query. Gebruik dus setMaxDegreeOfParallelism om het aantal partities in te stellen dat de maximale kans heeft om de meest presterende query te bereiken, mits alle andere systeemvoorwaarden hetzelfde blijven. Als u het aantal partities niet weet, kunt u setMaxDegreeOfParallelism gebruiken om een hoog getal in te stellen en kiest het systeem het minimum (aantal partities, door de gebruiker verstrekte invoer) als de maximale mate van parallelle uitvoering.

    Het is belangrijk om te weten dat parallelle query's de beste voordelen opleveren als de gegevens gelijkmatig worden verdeeld over alle partities met betrekking tot de query. Als de gepartitioneerde verzameling zodanig is gepartitioneerd dat alle of de meeste gegevens die door een query worden geretourneerd, in een paar partities zijn geconcentreerd (één partitie in het slechtste geval), worden de prestaties van de query knelpunten veroorzaakt door deze partities.

    (b) SetMaxBufferedItemCount afstemmen: Parallelle query is ontworpen om resultaten vooraf te maken terwijl de huidige batch met resultaten door de client wordt verwerkt. De prefetching helpt bij het verbeteren van de algehele latentie van een query. setMaxBufferedItemCount beperkt het aantal vooraf gemaakte resultaten. Door setMaxBufferedItemCount in te stellen op het verwachte aantal resultaten dat wordt geretourneerd (of een hoger getal), kan de query maximaal profiteren van prefetching.

    Prefetching werkt op dezelfde manier, ongeacht het MaxDegreeOfParallelisme, en er is één buffer voor de gegevens van alle partities.

  5. Uitstel implementeren bij intervallen van getRetryAfterInMilliseconds

    Tijdens het testen van de prestaties moet u de belasting verhogen totdat een klein aantal aanvragen wordt beperkt. Als de beperking is beperkt, moet de clienttoepassing uitstel uitvoeren voor de vertraging voor het door de server opgegeven interval voor opnieuw proberen. Het respecteren van de uitstel zorgt ervoor dat u minimale tijd besteedt aan het wachten tussen nieuwe pogingen. Ondersteuning voor beleid voor opnieuw proberen is opgenomen in versie 1.8.0 en hoger van de Azure Cosmos DB Sync Java SDK. Zie getRetryAfterInMilliseconds voor meer informatie.

  6. Uw clientworkload uitschalen

    Als u test op hoge doorvoerniveaus (>50.000 RU/s), kan de clienttoepassing het knelpunt worden omdat de computer het CPU- of netwerkgebruik beperkt. Als u dit punt bereikt, kunt u het Azure Cosmos DB-account verder pushen door uw clienttoepassingen uit te schalen op meerdere servers.

  7. Adressering op basis van naam gebruiken

    Gebruik adressering op basis van namen, waarbij koppelingen de indeling dbs/MyDatabaseId/colls/MyCollectionId/docs/MyDocumentIdhebben, in plaats van SelfLinks (_self), die de indeling dbs/<database_rid>/colls/<collection_rid>/docs/<document_rid> hebben om te voorkomen dat resource-id's worden opgehaald van alle resources die worden gebruikt om de koppeling te maken. Omdat deze resources opnieuw worden gemaakt (mogelijk met dezelfde naam), kan het opslaan van deze resources niet helpen.

  8. Het paginaformaat voor query's/leesfeeds afstemmen voor betere prestaties

    Wanneer u een bulksgewijs lezen van documenten uitvoert met behulp van de leesfeedfunctionaliteit (bijvoorbeeld readDocuments) of bij het uitgeven van een SQL-query, worden de resultaten op een gesegmenteerde manier geretourneerd als de resultatenset te groot is. Standaard worden resultaten geretourneerd in segmenten van 100 items of 1 MB, afhankelijk van welke limiet het eerst wordt bereikt.

    Als u het aantal netwerkrondes wilt verminderen dat nodig is om alle toepasselijke resultaten op te halen, kunt u de paginagrootte verhogen met behulp van de aanvraagheader x-ms-max-item-count tot maximaal 1000. In gevallen waarin u slechts enkele resultaten moet weergeven, bijvoorbeeld als uw gebruikersinterface of toepassings-API slechts 10 resultaten per keer retourneert, kunt u ook het paginaformaat verkleinen tot 10 om de verbruikte doorvoer voor lees- en query's te verminderen.

    U kunt ook het paginaformaat instellen met behulp van de methode SetPageSize.

Indexeringsbeleid

  1. Niet-gebruikte paden uitsluiten van indexering voor snellere schrijfbewerkingen

    Met het indexeringsbeleid van Azure Cosmos DB kunt u opgeven welke documentpaden moeten worden opgenomen of uitgesloten van indexering met behulp van indexeringspaden (setIncludedPaths en setExcludedPaths). Het gebruik van indexeringspaden kan betere schrijfprestaties en lagere indexopslag bieden voor scenario's waarin de querypatronen vooraf bekend zijn, omdat indexeringskosten rechtstreeks worden gecorreleerd aan het aantal unieke paden dat is geïndexeerd. In de volgende code ziet u bijvoorbeeld hoe u een hele sectie (substructuur) van de documenten kunt uitsluiten van indexering met behulp van het jokerteken *.

    Java SDK V2 synchroniseren (Maven com.microsoft.azure::azure-documentdb)

    Index numberIndex = Index.Range(DataType.Number);
numberIndex.set("precision", -1);
indexes.add(numberIndex);
includedPath.setIndexes(indexes);
includedPaths.add(includedPath);
indexingPolicy.setIncludedPaths(includedPaths);
collectionDefinition.setIndexingPolicy(indexingPolicy);

    Zie Het indexeringsbeleid van Azure Cosmos DB voor meer informatie.

Doorvoer

  1. Meten en afstemmen op lagere aanvraageenheden/tweede gebruik

    Azure Cosmos DB biedt een uitgebreide set databasebewerkingen, waaronder relationele en hiërarchische query's met UDF's, opgeslagen procedures en triggers, die allemaal werken op de documenten in een databaseverzameling. De kosten die gepaard gaan met elke bewerking hangen af van de CPU, de IO en het geheugen, vereist om de bewerking uit te voeren. In plaats van aan hardwareresources te denken en te beheren, kunt u een aanvraageenheid (RU) beschouwen als één meting voor de resources die nodig zijn voor het uitvoeren van verschillende databasebewerkingen en het uitvoeren van een toepassingsaanvraag.

    Doorvoer wordt ingericht op basis van het aantal aanvraageenheden dat is ingesteld voor elke container. Verbruik van aanvraageenheden wordt geëvalueerd als een tarief per seconde. Toepassingen die de ingerichte aanvraageenheidsnelheid voor hun container overschrijden, zijn beperkt totdat de snelheid lager is dan het ingerichte niveau voor de container. Als uw toepassing een hoger doorvoerniveau vereist, kunt u de doorvoer verhogen door extra aanvraageenheden in te richten.

    De complexiteit van een query heeft invloed op het aantal aanvraageenheden dat wordt verbruikt voor een bewerking. Het aantal predicaten, de aard van de predicaten, het aantal UDF's en de grootte van de brongegevensset zijn allemaal van invloed op de kosten van querybewerkingen.

    Als u de overhead van een bewerking wilt meten (maken, bijwerken of verwijderen), inspecteert u de header x-ms-request-charge (of de equivalente requestCharge-eigenschap in ResourceResponse<T> of FeedResponse<T> om het aantal aanvraageenheden te meten dat door deze bewerkingen wordt verbruikt.

    Java SDK V2 synchroniseren (Maven com.microsoft.azure::azure-documentdb)

    ResourceResponse<Document> response = client.createDocument(collectionLink, documentDefinition, null, false);

response.getRequestCharge();

    De aanvraagkosten die in deze header worden geretourneerd, zijn een fractie van uw ingerichte doorvoer. Als u bijvoorbeeld 2000 RU/s hebt ingericht en als de voorgaande query 1000 1 KB-documenten retourneert, zijn de kosten van de bewerking 1000. Daarom eert de server binnen één seconde slechts twee dergelijke aanvragen voordat de frequentie van volgende aanvragen wordt beperkt. Zie Aanvraageenheden en de rekenmachine voor aanvraageenheden voor meer informatie.

  2. Snelheidsbeperking/aanvraagsnelheid te groot verwerken

    Wanneer een client de gereserveerde doorvoer voor een account probeert te overschrijden, is er geen prestatievermindering op de server en is er geen gebruik van doorvoercapaciteit buiten het gereserveerde niveau. De server beëindigt de aanvraag met RequestRateTooLarge (HTTP-statuscode 429) en retourneert de header x-ms-retry-after-ms die de hoeveelheid tijd aangeeft, in milliseconden, dat de gebruiker moet wachten voordat de aanvraag opnieuw wordt geïmplementeerd.

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

    De SDK's vangen dit antwoord impliciet op, respecteren de server opgegeven nieuwe poging na header en probeer de aanvraag opnieuw. Tenzij uw account gelijktijdig wordt geopend door meerdere clients, slaagt de volgende nieuwe poging.

    Als u meerdere clients cumulatief boven de aanvraagsnelheid gebruikt, is het standaardaantal nieuwe pogingen dat momenteel is ingesteld op 9 intern door de client mogelijk niet voldoende; In dit geval genereert de client een DocumentClientException met statuscode 429 aan de toepassing. Het standaardaantal nieuwe pogingen kan worden gewijzigd met behulp van setRetryOptions op het ConnectionPolicy-exemplaar . De DocumentClientException met statuscode 429 wordt standaard geretourneerd na een cumulatieve wachttijd van 30 seconden als de aanvraag blijft werken boven de aanvraagsnelheid. Dit gebeurt zelfs wanneer het huidige aantal nieuwe pogingen kleiner is dan het maximumaantal nieuwe pogingen, of het nu de standaardwaarde is van 9 of een door de gebruiker gedefinieerde waarde.

    Hoewel het geautomatiseerde gedrag voor opnieuw proberen helpt om de tolerantie en bruikbaarheid voor de meeste toepassingen te verbeteren, kan het even vreemd komen bij het uitvoeren van prestatiebenchmarks, met name bij het meten van latentie. De door de client waargenomen latentie zal pieken als het experiment de server beperkt en ervoor zorgt dat de client-SDK op de achtergrond opnieuw probeert. Als u latentiepieken tijdens prestatieexperimenten wilt voorkomen, meet u de kosten die door elke bewerking worden geretourneerd en zorgt u ervoor dat aanvragen onder de gereserveerde aanvraagsnelheid worden uitgevoerd. Zie Aanvraageenheden voor meer informatie.

  3. Ontwerpen voor kleinere documenten voor hogere doorvoer

    De aanvraagkosten (de aanvraagverwerkingskosten) van een bepaalde bewerking worden rechtstreeks gecorreleerd aan de grootte van het document. Bewerkingen op grote documenten kosten meer dan bewerkingen voor kleine documenten.

Volgende stappen

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