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

  • Článek
  • 7 min ke čtení

PLATÍ PRO: Rozhraní API Cassandra API Gremlin API Table API služby Azure Cosmos DB API pro MongoDB

Tento článek popisuje, jak se žádosti o č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 materiálech, můžete si místo toho představit a spravovat hardwarové prostředky, můžete si představit jednotku požadavku (RU) jako jednu míru pro prostředky potřebné k provádění různých databázových operací.

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 optimalizace. 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 k dosažení tohoto postupu najdete v tématu Vyhledání poplatku za jednotku požadavku ve službě Azure Cosmos DB .

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

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

  • Čtení bodů (vyhledávání klíč/hodnota u JEDNOHO ID 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í konzistencesilné nebo omezené zastaralé konzistence se náklady na RU jakékoli operace čtení (bod čtení nebo dotaz) 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. V následující tabulce jsou uvedeny náklady na počet bodů č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) 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é.

Dotazy

Jednotky žádostí pro dotazy jsou závislé na řadě faktorů. Například počet načtených nebo vrácených položek Služby Azure Cosmos, 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 využívat stejný počet jednotek žádostí i při opakovaných spuštěních. Profil dotazu s využitím metrik spouštění dotazů vám dává dobrou představu o tom, jak se jednotky žádostí tráví.

V některýchpřípadechchch jednotkách se může zobrazit posloupnost odpovědí 200 a 429 a jednotek požadavků proměnných, to znamená, že dotazy budou fungovat co nejrychleji na základě dostupných ru. Mezi serverem a klientem se může zobrazit přerušení provádění dotazů na několik stránek nebo zaokrouhlení. Například 10 000 položek může být vráceno jako více stránek, každý se účtuje na základě výpočtů provedených pro danou stránku. Při součet na těchto stránkách byste měli 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í dotazů strávené v UDF a počet 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:

  • Spolulokace 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 provádě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. Spolulokace entit v rámci stejného kontejneru může snížit počet síťových cest zaokrouhlení za účelem vyřešení relací mezi záznamy. Proto zvyšuje výkon koncového to-endu, 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é přidělit více typů entit v rámci jednoho nebo menšího 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í pro nižší jednotky požadavků/ druhé využití

    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í zřízeného modelu propustnosti. Zřízená propustnost je reprezentována z hlediska jednotek žádostí za sekundu nebo RU/s. Jednotka požadavku (RU) je logická abstrakce výpočetních prostředků, jako je procesor, paměť, vstupně-výstupní operace atd., které jsou nutné 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, garantovat nízkou latenci a vysokou dostupnost v libovolném měřítku. Jednotky žádostí představují normalizovanou měnu, která zjednodušuje odůvodnění toho, 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 1000. Server tedy během jedné sekundy respektuje pouze dva takové požadavky před omezováním rychlosti následných požadavků. Další informace najdete v článku o jednotkách žádostí a kalkulačce jednotek žádosti.

Zápis dat

Náklady na zápis položky ru závisí na těchto parametrech:

  • 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 dvakrát účtují poplatky potřebné k vložení stejné položky.

Optimalizace zápisů

Nejlepším způsobem, jak optimalizovat náklady na RU operací zápisu, je nastavení práv položek a počtu 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 dá se považovat za anti-vzor. 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 píšete do služby Azure Cosmos DB.
  • Optimalizace zásad indexování tak, aby indexovala jenom vlastnosti, na které se vaše dotazy filtrují, můžou mít velký rozdíl v rukách spotřebovaných operacemi zápisu. Při vytváření nového kontejneru indexuje výchozí zásady indexování každou a každou vlastnost, která se nachází ve vašich položkách. I když se jedná o 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 v případě, že vaše úloha začne přijímat významný provoz.

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 také použít Azure Data Factory , která je postavená 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: