Sdílet prostřednictvím

Optimalizace nákladů na požadavky ve službě Azure Cosmos DB

  • Článek

PLATÍ PRO: NoSQL MongoDB Cassandra Skřítek Stůl

Tento článek popisuje, jak se požadavky na čtení a zápis překládají do jednotek žádostí a jak optimalizovat náklady na tyto žádosti. Operace čtení zahrnují čtení bodů a dotazy. Operace zápisu zahrnují vložení, nahrazení, odstranění a upsert položek.

Azure Cosmos DB nabízí bohatou sadu databázových operací, které pracují s položkami v kontejneru. 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ů, můžete jednotku žádosti (RU) považovat za jedinou míru pro prostředky potřebné k provádění různých databázových operací, které budou sloužit žádosti.

Měření poplatku za RU žádosti

Je důležité měřit poplatky za RU vašich požadavků, abyste porozuměli jejich skutečným nákladům a také vyhodnotili efektivitu optimalizací. Tyto náklady můžete načíst pomocí webu Azure Portal nebo zkontrolovat odpověď odeslanou ze služby Azure Cosmos DB prostřednictvím jedné ze sad SDK. Podrobné pokyny, jak toho dosáhnout, najdete v tématu Vyhledání poplatku za jednotku žádosti ve službě Azure Cosmos DB .

Čtení dat: čtení bodů a dotazů

Operace čtení ve službě Azure Cosmos DB se obvykle řadí od nejrychlejších/nejúčinnějších po pomalejší/méně efektivní z hlediska spotřeby RU následujícím způsobem:

  • Čtení bodů (vyhledávání klíč/hodnota u ID jedné položky a klíče oddílu)
  • Dotazování pomocí klauzule filtru v rámci jednoho klíče oddílu
  • Dotaz bez klauzule filtru rovnosti nebo rozsahu u jakékoli vlastnosti
  • Dotaz bez filtrů

Role úrovně konzistence

Při použití úrovní konzistence silné nebo omezené nekonzistence se náklady na RU jakékoli operace čtení (čtení bodu nebo dotazu) zdvojnásobí.

Čtení bodů

Jediným faktorem ovlivňujícím poplatky za RU bodu čtení (kromě použité úrovně konzistence) je velikost načtené položky. Následující tabulka uvádí náklady na ru čtení bodů pro položky, které mají velikost 1 kB a 100 kB.

Velikost položky Náklady na čtení jednoho bodu
1 kB 1 RU
100 kB 10 RU

Vzhledem k tomu, že čtení bodů (vyhledávání klíč/hodnota v ID položky a klíč oddílu) je nejúčinnějším typem čtení, měli byste se ujistit, že ID položky má smysluplnou hodnotu, abyste mohli položky načíst pomocí bodu čtení (místo dotazu), pokud je to možné.

Poznámka:

V rozhraní API pro NoSQL je možné číst body pouze pomocí rozhraní REST API nebo sad SDK. Dotazy, které filtrují ID jedné položky a klíč oddílu, se nepovažují za čtený bod. Příklad použití sady .NET SDK najdete v tématu Čtení položky ve službě Azure Cosmos DB for NoSQL.

Dotazy

Jednotky žádostí pro dotazy jsou závislé na řadě faktorů. Například počet načtených/vrácených položek služby Azure Cosmos DB, počet vyhledávání v indexu, čas kompilace dotazu atd. Azure Cosmos DB zaručuje, že stejný dotaz při spuštění na stejných datech bude vždy spotřebovávat stejný počet jednotek žádostí i při opakovaných spuštěních. Profil dotazu využívající metriky spouštění dotazů vám poskytne dobrou představu o tom, jak se jednotky žádostí tráví.

V některých případech se při stránkovaném provádění dotazů může zobrazit posloupnost odpovědí 200 a 429 a proměnných jednotek žádostí, to znamená, že dotazy se budou spouštět co nejrychleji na základě dostupných RU. Mezi serverem a klientem se může zobrazit konec provádění dotazu na několik stránek/odezvy. Například 10 000 položek může být vráceno jako více stránek, přičemž každý se účtuje na základě výpočtu provedeného pro danou stránku. Když sečtete na těchto stránkách, měli byste získat stejný počet RU, kolik byste získali pro celý dotaz.

Metriky pro dotazy pro řešení potíží

Výkon a propustnost spotřebovaná dotazy (včetně uživatelem definovaných funkcí) většinou závisí na těle funkce. Nejjednodušší způsob, jak zjistit, kolik času je provádění dotazu strávené v UDF a počtu spotřebovaných RU, je povolením metrik dotazů. Pokud používáte sadu .NET SDK, tady jsou ukázkové metriky dotazů vrácené sadou SDK:

Retrieved Document Count                 :               1              
Retrieved Document Size                  :           9,963 bytes        
Output Document Count                    :               1              
Output Document Size                     :          10,012 bytes        
Index Utilization                        :          100.00 %            
Total Query Execution Time               :            0.48 milliseconds 
  Query Preparation Times 
    Query Compilation Time               :            0.07 milliseconds 
    Logical Plan Build Time              :            0.03 milliseconds 
    Physical Plan Build Time             :            0.05 milliseconds 
    Query Optimization Time              :            0.00 milliseconds 
  Index Lookup Time                      :            0.06 milliseconds 
  Document Load Time                     :            0.03 milliseconds 
  Runtime Execution Times 
    Query Engine Execution Time          :            0.03 milliseconds 
    System Function Execution Time       :            0.00 milliseconds 
    User-defined Function Execution Time :            0.00 milliseconds 
  Document Write Time                    :            0.00 milliseconds 
  Client Side Metrics 
    Retry Count                          :               1              
    Request Charge                       :            3.19 RUs  

Osvědčené postupy pro optimalizaci nákladů dotazů

Při optimalizaci dotazů na náklady zvažte následující osvědčené postupy:

  • Společné přidělení více typů entit

    Pokuste se přidělit více typů entit v rámci jednoho nebo menšího počtu kontejnerů. Tato metoda přináší výhody nejen z hlediska cen, ale také pro spouštění dotazů a transakce. Dotazy jsou vymezeny na jeden kontejner; a atomické transakce přes více záznamů prostřednictvím uložených procedur/triggerů jsou vymezeny na klíč oddílu v rámci jednoho kontejneru. Společné přidělení entit v rámci stejného kontejneru může snížit počet síťových cest zaokrouhlení pro překlad relací mezi záznamy. Zvyšuje tak komplexní výkon, umožňuje atomické transakce přes více záznamů pro větší datovou sadu a v důsledku toho snižuje náklady. Pokud je pro váš scénář obtížné společné přidělení více typů entit v jednom nebo menším počtu kontejnerů, obvykle proto, že migrujete existující aplikaci a nechcete provádět žádné změny kódu – měli byste zvážit zřízení propustnosti na úrovni databáze.

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

    Složitost dotazu má vliv na počet jednotek žádostí (RU) spotřebovaných pro operaci. Počet predikátů, povaha predikátů, počet UDF a velikost zdrojové sady dat. Všechny tyto faktory ovlivňují náklady na operace dotazů.

Azure Cosmos DB poskytuje předvídatelný výkon z hlediska propustnosti a latence pomocí modelu zřízené propustnosti. Zřízená propustnost je reprezentována z hlediska jednotek žádostí za sekundu nebo RU/s. Jednotka žádosti (RU) je logická abstrakce výpočetních prostředků, jako jsou procesor, paměť, V/V atd., které jsou potřeba k provedení požadavku. Zřízená propustnost (RU) je vyhrazená a vyhrazená pro kontejner nebo databázi, aby poskytovala předvídatelnou propustnost a latenci. Zřízená propustnost umožňuje službě Azure Cosmos DB poskytovat předvídatelný a konzistentní výkon, garantovanou nízkou latenci a vysokou dostupnost v libovolném měřítku. Jednotky žádostí představují normalizovanou měnu, která zjednodušuje odůvodnění o tom, kolik prostředků aplikace potřebuje.

Poplatek za požadavek vrácený v hlavičce požadavku označuje náklady na daný dotaz. Pokud například dotaz vrátí 1000 1 kB položek, 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 článku Jednotky žádostí a kalkulačka jednotek žádosti.

Zápis dat

Náklady na ru při psaní položky závisí na těchto jednotkách:

  • Velikost položky.
  • Počet vlastností, na které se vztahuje zásada indexování, a je potřeba je indexovat.

Vložení položky o velikosti 1 kB bez indexování nákladů kolem přibližně 5,5 RU Nahrazení nákladů na položku dvěmanásobky poplatku potřebného k vložení stejné položky.

Optimalizace zápisů

Nejlepší způsob, jak optimalizovat náklady na RU operací zápisu, je rightsize položek a počet vlastností, které se indexují.

  • Ukládání velmi velkých položek ve službě Azure Cosmos DB vede k vysokým poplatkům za RU a lze je považovat za anti-pattern. Konkrétně neukládáte binární obsah ani velké bloky textu, na které se nemusíte dotazovat. Osvědčeným postupem je umístit tento druh dat do služby Azure Blob Storage a uložit odkaz (nebo odkaz) na objekt blob v položce, kterou napíšete do služby Azure Cosmos DB.
  • Optimalizace zásad indexování tak, aby indexovala jenom vlastnosti, na které se dotazy filtrují, můžou v rukách spotřebovaných operacemi zápisu značně změnit. Při vytváření nového kontejneru indexuje výchozí zásady indexování každou a všechny vlastnosti nalezené v položkách. I když je to vhodné výchozí nastavení pro vývojové aktivity, důrazně doporučujeme znovu vyhodnotit a přizpůsobit zásady indexování při přechodu do produkčního prostředí nebo při zahájení přijímání významných přenosů úloh.

Při hromadném příjmu dat se také doporučuje použít knihovnu bulk Executor služby Azure Cosmos DB, protože je navržená tak, aby optimalizovala spotřebu RU těchto operací. Volitelně můžete použít službu Azure Data Factory , která je založená na stejné knihovně.

Další kroky

Další informace o optimalizaci nákladů ve službě Azure Cosmos DB najdete v následujících článcích: