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 pro výkon jsou určené pouze pro sadu v2 Java SDK Sync služby Azure Cosmos DB. 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. Škálování nahoru a dolů je stejně snadné jako jediným API voláním. 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í, můžete provést optimalizace na straně klienta, abyste dosáhli špičkového výkonu při použití Azure Cosmos DB Sync Java SDK 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. Je k dispozici jedno klíčové nastavení konfigurace pro konfiguraci klienta ConnectionPolicy – ConnectionMode. K dispozici jsou dva režimy připojení:

   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, nejlepší volbou je Gateway, protože používá standardní port HTTPS a jeden koncový bod. Nevýhodou kompromisu výkonu je, že režim brány zahrnuje další síťový skok při každém čtení nebo zápisu dat do Azure Cosmos DB. Z tohoto důvodu nabízí režim DirectHttps lepší výkon díky menšímu počtu skoků v síti.

      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 práci s více vlákny a provádí efektivní správu připojení a ukládání adres do mezipaměti při používání 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í tak, že dotazují více oddílů paralelně. 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 rozdělena tak, že všechna nebo většina dat vrácených dotazem je soustředěna do několika oddílů (v nejhorším případě do jednoho oddílu), pak by výkon dotazu byl omezen těmito oddíly.

   (b) Ladění setMaxBufferedItemCount: Paralelní dotazování je určené k předběžnému načtení výsledků, zatímco je aktuální dávka výsledků zpracovává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 parametr MaxDegreeOfParallelism a pro data ze všech oddílů je k dispozici jediná vyrovnávací paměť.

5. Implementujte zpoždění v intervalech podle getRetryAfterInMilliseconds

   Během testování výkonu byste měli zvýšit zatížení, dokud nedojde k omezení malé části 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í odstupu 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 novějších sady Azure Cosmos DB Sync Java SDK. Další informace naleznete v tématu getRetryAfterInMilliseconds.

6. Škálujte zatížení klienta

   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 Azure Cosmos DB dále rozšířit tím, že škálováním horizontálně rozdělíte své klientské aplikace 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í. Protože budou tyto prostředky znovu vytvořeny (možná se stejným názvem), nemusí ukládání do mezipaměti pomoci.

8. Vyladit velikost stránky pro dotazy/čtecí kanály pro zlepšení 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ěřte a upravujte pro nižší spotřebu 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 uživatelsky definovanými funkcemi, uloženými procedurami a triggery – všechny operace s dokumenty v rámci databázové kolekce. 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čí povolenou jednotkovou sazbu požadavku pro svůj kontejner, jsou omezené, dokud sazba poklesne pod povolenou úroveň pro kontejner. 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 UDF a velikost sady zdrojových dat všechny 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 uvedený v této hlavičce je zlomkem rezervované propustnosti. Pokud máte například zřízeno 2000 RU/s a pokud předchozí dotaz vrátí 1 000 dokumentů o velikosti 1 KB, 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 naleznete v tématu jednotky žádostí a kalkulačka jednotek žádostí.

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
   

   Všechny sady SDK implicitně zachytí tuto odpověď, respektují hlavičku Retry-After zadanou serverem a znovu odešlou požadavek. Pokud k vašemu účtu současně nepřistupuje více klientů, další pokus bude ú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 být v rozporu při provádění výkonových testů, 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 zatížení vrácené každou operací a zajistěte, aby požadavky fungovaly pod rezervovanou kapacitou 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.