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

• 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 zlepšení výkonu platí pouze pro Java SDK v2 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. Přizpůsobení kapacity nahoru a dolů je stejně snadné jako jediný hovor na 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 provést k dosažení optimálního výkonu při použití sady Java SDK pro synchronizaci 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

   To, jak se klient připojuje ke službě Azure Cosmos DB, má významný vliv na výkon, zejména pokud jde o pozorovanou latenci na straně klienta. Pro konfiguraci klientské ConnectionPolicy – Režim připojení je k dispozici jedno klíčové nastavení konfigurace. K dispozici jsou dva Connection Modes:

   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, neboť využívá standardní port HTTPS a jediný koncový bod. Kompromisem ve výkonu je to, že režim Gateway zahrnuje další síťový skok 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 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 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í MaxPoolSize na každého hostitele při použití režimu Gateway

   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 uspořádána tak, že všechna nebo většina dat vrácených dotazem se soustředí do několika oddílů (v nejhorším případě do jednoho oddílu), pak by výkon dotazu mohl být omezen těmito oddíly.

   (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. Implementujte zpoždění v intervalech getRetryAfterInMilliseconds

   Během testování výkonu byste měli zvýšit zatížení, dokud se malé množství požadavků nezačne omezovat. Pokud dojde k omezení rychlosti, měla by se klientská aplikace v zadaném serverem intervalu pro opětovné pokusy zmenšit frekvenci. Respektování časové prodlevy zajišťuje, že strávíte minimální čas čekáním mezi opakovanými pokusy. Podpora mechanismu opakování je zahrnutá ve verzi 1.8.0 a vyšší v Java SDK pro synchronizaci služby Azure Cosmos DB. Další informace naleznete v tématu getRetryAfterInMilliseconds.

6. Škálujte klientskou zátěž

   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 pokračovat v rozšiřování účtu Azure Cosmos DB tím, že budete škálovat 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í. Vzhledem k tomu, že se tyto prostředky znovu vytvoří (možná se stejným názvem), jejich ukládání do mezipaměti nemusí pomoct.

8. Optimalizace velikosti stránky pro dotazy/čtení informačních kanálů kvůli lepšímu 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.

   Chcete-li 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-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 optimalizujte pro snížení využití 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 tyto 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 požadovaných jednotek nastavených pro každý kontejner. Spotřeba jednotek žádosti se vyhodnocuje jako sazba za sekundu. Aplikace, které překročí přidělenou jednotkovou sazbu požadavků pro svůj kontejner, jsou omezeny, dokud rychlost neklesne pod přidělenou ú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 uživatelem definovaných funkcí 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 uvedený v této hlavičce je zlomkem vaší vyhrazené propustnosti. Například pokud máte zřízeno 2000 RU/s a předchozí dotaz vrátí 1 000 dokumentů o velikosti 1 KB, náklady na operaci budou 1 000 RU. 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čce jednotek žádostí.

2. Řešení omezení rychlosti / příliš velká rychlost 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 SDK implicitně zachytí tuto odpověď, respektují serverem zadanou hlavičku 'retry-after' a opakují požadavek. Pokud k vašemu účtu současně nepř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ý proces 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 narazit na problémy, zejména při měření latence. Latence pozorovaná klientem se zvýší, pokud experiment narazí na omezení serveru a způsobí, že SDK klienta automaticky zopakuje pokus, aniž by si toho uživatel všiml. 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 Požadované jednotky.

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.