Tipy pro zvýšení výkonu pro sadu Java SDK synchronizace služby Azure Cosmos DB v2

PLATÍ PRO: NoSQL

• Java SDK v4
• Async Java SDK v2
• Synchronizace sady Java SDK v2
• .NET SDK v3
• .NET SDK v2
• Python SDK

Důležité

Nejedná se o nejnovější sadu Java SDK pro službu Azure Cosmos DB! Projekt byste měli upgradovat na sadu Java SDK služby Azure Cosmos DB v4 a pak si přečíst průvodce tipy pro zvýšení výkonu sady Java SDK služby Azure Cosmos DB v4. Postupujte podle pokynů v průvodci migrací na sadu Java SDK služby Azure Cosmos DB verze 4 a průvodce upgradem nástroje Reactor vs RxJava .

Tyto tipy k výkonu jsou určené jenom pro sadu Java SDK služby Azure Cosmos DB v2. Další informace najdete v úložišti Maven.

Důležité

29. února 2024 bude sada Java SDK služby Azure Cosmos DB Sync v2.x vyřazena; sada SDK a všechny aplikace používající sadu SDK budou i nadále fungovat; Azure Cosmos DB jednoduše přestane poskytovat další údržbu a podporu pro tuto sadu SDK. Pokud chcete migrovat na sadu Java SDK služby Azure Cosmos DB verze 4, doporučujeme postupovat podle výše uvedených pokynů.

Azure Cosmos DB je rychlá a flexibilní distribuovaná databáze, která se bezproblémově škáluje s garantovanou latencí a propustností. Nemusíte provádět významné změny architektury ani psát složitý kód pro škálování databáze pomocí služby Azure Cosmos DB. Vertikální navýšení a snížení kapacity je stejně snadné jako vytvoření jediného volání rozhraní API. Další informace najdete v tématu zřízení propustnosti kontejneru nebo zřízení propustnosti databáze. Vzhledem k tomu, že se k Azure Cosmos DB přistupuje prostřednictvím síťových volání, existují optimalizace na straně klienta, které můžete dosáhnout maximálního výkonu při použití sady Java SDK synchronizace služby Azure Cosmos DB v2.

Pokud se tedy ptáte, jak můžu zlepšit výkon databáze? zvažte následující možnosti:

Sítě

1. Režim připojení: Použití DirectHttps

   Způsob, jakým se klient připojuje ke službě Azure Cosmos DB, má významný vliv na výkon, a to zejména z hlediska pozorované latence na straně klienta. Pro konfiguraci client ConnectionPolicy – ConnectionMode je k dispozici jedno nastavení konfigurace klíče. K dispozici jsou dva dostupné connectionmody:

   1. Brána (výchozí)

   2. DirectHttps

      Režim brány se podporuje na všech platformách sady SDK a je nakonfigurovaný jako výchozí. Pokud vaše aplikace běží v podnikové síti s přísnými omezeními brány firewall, je nejlepší volbou brána, protože používá standardní port HTTPS a jeden koncový bod. Nevýhodou výkonu je ale to, že režim brány zahrnuje další segment směrování sítě při každém čtení nebo zápisu dat do služby Azure Cosmos DB. Z tohoto důvodu nabízí režim DirectHttps lepší výkon kvůli menšímu počtu segmentů směrování sítě.

      Sada Azure Cosmos DB Sync Java SDK v2 používá protokol HTTPS jako přenosový protokol. PROTOKOL HTTPS používá protokol TLS k počátečnímu ověřování a šifrování provozu. Při použití sady Java SDK synchronizace služby Azure Cosmos DB verze 2 je potřeba otevřít jenom port HTTPS 443.

      ConnectionMode se konfiguruje během vytváření instance DocumentClient s parametrem ConnectionPolicy.

   Synchronizace sady Java SDK V2 (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);
   

   

2. Sloučit klienty ve stejné oblasti Azure pro zajištění výkonu

   Pokud je to možné, umístěte všechny aplikace, které volají službu Azure Cosmos DB, do stejné oblasti jako databáze Azure Cosmos DB. Pro přibližné porovnání se volání služby Azure Cosmos DB ve stejné oblasti dokončí do 1 až 2 ms, ale latence mezi pobřežím USA – západ a východ je >50 ms. Tato latence se může pravděpodobně lišit od požadavku na požadavek v závislosti na trase, kterou žádost vzala při průchodu z klienta do hranice datacentra Azure. Nejnižší možné latence se dosahuje tím, že se volající aplikace nachází ve stejné oblasti Azure jako zřízený koncový bod služby Azure Cosmos DB. Seznam dostupných oblastí najdete v tématu Oblasti Azure.

   

Využití sady SDK

1. Instalace nejnovější sady SDK

   Sady SDK služby Azure Cosmos DB se neustále vylepšují, aby poskytovaly nejlepší výkon. Pokud chcete zjistit nejnovější vylepšení sady SDK, navštivte sadu SDK služby Azure Cosmos DB.

2. Použití jednoúčelového klienta Azure Cosmos DB po celou dobu životnosti vaší aplikace

   Každá instance DocumentClient je bezpečná pro přístup z více vláken a provádí efektivní správu připojení a ukládání adres do mezipaměti při provozu v přímém režimu. Pokud chcete povolit efektivní správu připojení a lepší výkon documentClient, doporučujeme použít jednu instanci DocumentClient per AppDomain po celou dobu života aplikace.

3. Zvýšení maximální velikosti fondu na hostitele při použití režimu brány

   Požadavky služby Azure Cosmos DB se provádějí přes PROTOKOL HTTPS/REST při použití režimu brány a podléhají výchozímu limitu připojení na název hostitele nebo IP adresu. Možná budete muset nastavit MaxPoolSize na vyšší hodnotu (200–1000), aby klientská knihovna mohla využívat více souběžných připojení ke službě Azure Cosmos DB. V sadě Azure Cosmos DB Sync Java SDK verze 2 je výchozí hodnota ConnectionPolicy.getMaxPoolSize 100. Ke změně hodnoty použijte setMaxPoolSize .

4. Ladění paralelních dotazů pro dělené kolekce

   Sada Java SDK synchronizace služby Azure Cosmos DB verze 1.9.0 a vyšší podporuje paralelní dotazy, které umožňují paralelně dotazovat dělenou kolekci. Další informace najdete v ukázkách kódu souvisejících s prací se sadami SDK. Paralelní dotazy jsou navržené tak, aby zlepšily latenci a propustnost dotazů oproti jejich sériovému protějšku.

   (a) Ladění setMaxDegreeOfParallelism: Paralelní dotazy fungují paralelně dotazováním více oddílů. Data z jednotlivé dělené kolekce se ale načítají sériově s ohledem na dotaz. Proto pomocí setMaxDegreeOfParallelism nastavte počet oddílů, které mají maximální šanci dosáhnout nejvýkonnějšího dotazu, za předpokladu, že všechny ostatní systémové podmínky zůstanou stejné. Pokud neznáte počet oddílů, můžete použít setMaxDegreeOfParallelism k nastavení vysokého čísla a systém jako maximální stupeň paralelismu zvolí minimum (počet oddílů, zadaný vstup uživatelem).

   Je důležité si uvědomit, že paralelní dotazy přinášejí nejlepší výhody, pokud se data rovnoměrně distribuují napříč všemi oddíly s ohledem na dotaz. Pokud je dělená kolekce tak, aby se všechna nebo většina dat vrácených dotazem soustředila do několika oddílů (v nejhorším případě jeden oddíl), pak by byl výkon dotazu kritickým bodem těchto oddílů.

   (b) Ladění setMaxBufferedItemCount: Paralelní dotaz je určen k předběžnému načtení výsledků, zatímco aktuální dávka výsledků je zpracována klientem. Předběžné načítání pomáhá při celkovém zlepšení latence dotazu. setMaxBufferedItemCount omezuje počet předem načtených výsledků. Nastavením setMaxBufferedItemCount na očekávaný počet vrácených výsledků (nebo vyšší číslo), to umožňuje dotazu získat maximální výhodu z předběžného načtení.

   Předběžné načítání funguje stejně bez ohledu na MaxDegreeOfParallelism a pro data ze všech oddílů existuje jedna vyrovnávací paměť.

5. Implementace backoffu v intervalech getRetryAfterInMilliseconds

   Během testování výkonu byste měli zvýšit zatížení, dokud nedojde k omezení malé míry požadavků. Pokud dojde k omezení, měla by se klientská aplikace v intervalu opakování zadaného serveru vrátit zpět. Dodržování zpětného běhu zajišťuje, že strávíte minimální dobu čekáním mezi opakovanými pokusy. Podpora zásad opakování je zahrnutá ve verzi 1.8.0 a vyšší v sadě Java SDK synchronizace služby Azure Cosmos DB. Další informace naleznete v tématu getRetryAfterInMilliseconds.

6. Škálování úlohy klienta na více instancí

   Pokud testujete vysoké úrovně propustnosti (>50 000 RU/s), může se klientská aplikace stát kritickým bodem kvůli omezování využití procesoru nebo sítě. Pokud se k tomuto bodu dostanete, můžete účet služby Azure Cosmos DB dál nabízet horizontálním navýšením kapacity klientských aplikací na více serverů.

7. Použití adresování na základě názvů

   Použijte adresování založené na názvu, kde odkazy mají formát dbs/MyDatabaseId/colls/MyCollectionId/docs/MyDocumentId, místo SelfLinks (_self), které mají formát dbs/<database_rid>/colls/<collection_rid>/docs/<document_rid> , aby se zabránilo načtení ResourceId všech prostředků použitých k vytvoření propojení. Vzhledem k tomu, že se tyto prostředky znovu vytvoří (pravděpodobně se stejným názvem), nemusí to pomoct.

8. Vyladění velikosti stránky pro dotazy nebo informační kanály pro čtení pro zajištění lepšího výkonu

   Při provádění hromadného čtení dokumentů pomocí funkcí informačního kanálu pro čtení (například readDocuments) nebo při vydávání dotazu SQL se výsledky vrátí segmentovaným způsobem, pokud je sada výsledků příliš velká. Ve výchozím nastavení se výsledky vrátí v blocích po 100 položkách nebo 1 MB, podle toho, jaký limit se dosáhne prvního.

   Pokud chcete snížit počet síťových cest potřebných k načtení všech použitelných výsledků, můžete velikost stránky zvětšit pomocí hlavičky požadavku x-ms-ms-max-item-count až na 1 000. V případech, kdy potřebujete zobrazit jenom několik výsledků, například pokud vaše uživatelské rozhraní nebo rozhraní API aplikace vrací jenom 10 výsledků, můžete také zmenšit velikost stránky na 10, aby se snížila propustnost spotřebovaná pro čtení a dotazy.

   Velikost stránky můžete také nastavit pomocí metody setPageSize.

Zásady indexování

1. Vyloučení nepoužívaných cest z indexování za účelem zrychlení zápisu

   Zásady indexování služby Azure Cosmos DB umožňují určit, které cesty k dokumentu se mají zahrnout nebo vyloučit z indexování pomocí cest indexování (setIncludedPaths a setExcludedPaths). Použití cest indexování může nabídnout lepší výkon zápisu a nižší úložiště indexů pro scénáře, ve kterých jsou vzory dotazů známé předem, protože náklady na indexování přímo korelují s počtem indexovaných jedinečných cest. Následující kód například ukazuje, jak vyloučit celý oddíl (podstrom) dokumentů z indexování pomocí zástupného znaku "*".

   Synchronizace sady Java SDK V2 (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);
   

   Další informace najdete v tématu Zásady indexování služby Azure Cosmos DB.

Propustnost

1. Měření a ladění nižších jednotek žádostí za sekundu

   Azure Cosmos DB nabízí bohatou sadu databázových operací, včetně relačních a hierarchických dotazů s funkcemi definované uživatelem, uloženými procedurami a triggery – všechny operace s dokumenty v rámci kolekce databází. Náklady spojené s jednotlivými operacemi se liší v závislosti na procesoru, V/V a paměti, které jsou potřeba k dokončení operace. Místo toho, abyste přemýšleli o hardwarových prostředcích a správě hardwarových prostředků, si můžete představit jednotku žádostí (RU) jako jednu míru pro prostředky potřebné k provádění různých databázových operací a žádosti o aplikaci.

   Propustnost se zřizuje na základě počtu jednotek žádostí nastavených pro každý kontejner. Spotřeba jednotek žádosti se vyhodnocuje jako sazba za sekundu. Aplikace, které překročí zřízenou jednotkovou sazbu požadavku pro svůj kontejner, jsou omezené, dokud se rychlost sníží pod zřízenou úroveň kontejneru. Pokud vaše aplikace vyžaduje vyšší úroveň propustnosti, můžete zvýšit propustnost zřízením dalších jednotek žádostí.

   Složitost dotazu má vliv na počet jednotek žádostí spotřebovaných pro operaci. Počet predikátů, povaha predikátů, počet definovaných uživatelem a velikost sady zdrojových dat ovlivňují náklady na operace dotazu.

   Pokud chcete změřit režii jakékoli operace (vytvoření, aktualizace nebo odstranění), zkontrolujte hlavičku x-ms-request-charge (nebo ekvivalentní vlastnost RequestCharge v ResourceResponse<T> nebo FeedResponse<T> a změřte počet jednotek žádostí spotřebovaných těmito operacemi.

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

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

   Poplatek za požadavek vrácený v této hlavičce je zlomkem zřízené propustnosti. Pokud máte například zřízeno 2000 RU/s a pokud předchozí dotaz vrátí 1 000 1KB dokumentů, náklady na operaci jsou 1 000. V rámci jedné sekundy server respektuje pouze dva takové požadavky před omezováním rychlosti následných požadavků. Další informace najdete v tématu Jednotky žádostí a kalkulačka jednotek žádosti.

2. Zpracování omezování rychlosti nebo příliš velké frekvence požadavků

   Když se klient pokusí překročit rezervovanou propustnost pro účet, nedojde na serveru ke snížení výkonu a k žádnému využití kapacity propustnosti nad rámec rezervované úrovně. Server předem ukončí požadavek pomocí requestRateTooLarge (stavový kód HTTP 429) a vrátí hlavičku x-ms-retry-after-ms označující dobu v milisekundách, že uživatel musí před opětovným spuštěním požadavku počkat.

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

   Sady SDK všechny implicitně zachytí tuto odpověď, respektují hlavičku opakování zadanou serverem a opakují požadavek. Pokud k vašemu účtu současně přistupuje více klientů, bude další opakování úspěšné.

   Pokud máte více než jeden klient, který konzistentně pracuje nad rychlostí požadavků, výchozí počet opakování aktuálně nastavený na 9 interně klient nemusí stačit; v tomto případě klient vyvolá do aplikace výjimku DocumentClientException se stavovým kódem 429. Výchozí počet opakování lze změnit pomocí setRetryOptions v instanci ConnectionPolicy . Ve výchozím nastavení se výjimka DocumentClientException se stavovým kódem 429 vrátí po kumulativní době čekání 30 sekund, pokud požadavek nadále funguje nad rychlostí požadavků. K tomu dochází i v případě, že je aktuální počet opakování menší než maximální počet opakování, jedná se o výchozí hodnotu 9 nebo uživatelem definovanou hodnotu.

   I když automatizované chování opakování pomáhá zlepšit odolnost a použitelnost pro většinu aplikací, může při provádění srovnávacích testů výkonu přicházet k pravděpodobnosti, zejména při měření latence. Latence pozorovaná klientem se zvýší, pokud experiment dosáhne omezení serveru a způsobí tiché opakování klientské sady SDK. Abyste se vyhnuli špičkám latence během experimentů s výkonem, změřte poplatky vrácené jednotlivými operacemi a zajistěte, aby požadavky fungovaly pod rezervovanou rychlostí požadavků. Další informace najdete v tématu Jednotky žádostí.

3. Návrh menších dokumentů pro vyšší propustnost

   Poplatek za žádost (náklady na zpracování požadavku) dané operace přímo koreluje s velikostí dokumentu. Operace s velkými dokumenty stojí více než operace u malých dokumentů.

Další kroky

Další informace o návrhu aplikace pro škálování a vysoký výkon najdete v tématu Dělení a škálování ve službě Azure Cosmos DB.