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

  • Článek

PLATÍ PRO: NoSQL MongoDB Cassandra Gremlin Tabulka

Tento článek popisuje, jak se žádosti o čtení a zápis překládají na jednotky žádostí a jak optimalizovat náklady na tyto požadavky. 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ě těchto prostředků, si můžete jednotku žádostí (RU) představit jako jedno měřítko pro prostředky potřebné k provádění různých databázových operací, které obsluhuje požadavek.

Měření poplatku za RU požadavku

Je důležité změřit poplatky za RU vašich požadavků, abyste porozuměli jejich skutečným nákladům a také posoudili efektivitu vašich optimalizací. Tyto náklady můžete načíst pomocí Azure Portal nebo kontrolou odpovědi odeslané zpět ze služby Azure Cosmos DB prostřednictvím některé 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 dotazy

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

  • Čtení v bodech (vyhledávání klíče/hodnoty podle ID jedné položky a klíče oddílu)
  • Dotaz s klauzulí filtru v rámci jednoho klíče oddílu.
  • Dotaz bez klauzule filtru rovnosti nebo rozsahu na libovolnou vlastnost.
  • Dotaz bez filtrů

Role úrovně konzistence

Při použití úrovně konzistencesilné nebo omezené nestaralosti se náklady na RU jakékoli operace čtení (bod čtení nebo dotaz) zdvojnásobí.

Čtení bodů

Jediným faktorem, který ovlivňuje poplatek za RU při čtení bodu (kromě použité úrovně konzistence), je velikost načtené položky. Následující tabulka ukazuje náklady na RU čtení bodů u položek o velikosti 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íči oddílu) je nejúčinnější druh čtení, měli byste se ujistit, že ID položky má smysluplnou hodnotu, abyste mohli položky načíst se čteným bodem (místo dotazu), pokud je to možné.

Poznámka

V rozhraní API pro NoSQL je možné čtení bodů provádět pouze pomocí rozhraní REST API nebo sad SDK. Dotazy, které filtrují ID jedné položky a klíč oddílu, se nepovažují za přeč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 několika faktorech. Například počet načtených/vrácených položek Služby Azure Cosmos DB, počet vyhledávání v indexu, doba kompilace dotazu atd. Podrobnosti. 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 žádosti, a to i při opakovaných spuštěních. Profil dotazu, který používá metriky spouštění dotazů, poskytuje dobrou představu o tom, jak se jednotky žádostí využívají.

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í, protože dotazy budou na základě dostupných RU běžet co nejrychleji. Může se zobrazit přerušení provádění dotazu na více stránek nebo doba odezvy mezi serverem a klientem. Například 10 000 položek může být vráceno jako více stránek, z nichž každá se účtuje na základě výpočtu provedeného pro danou stránku. Když sečtete všechny tyto stránky, měli byste získat stejný počet RU, jaký byste získali pro celý dotaz.

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

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 provádění dotazu stráví v UDF a počet spotřebovaných RU, je povolit metriky 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 dotazy pro optimalizaci nákladů

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

  • Společné umístění více typů entit

    Zkuste společně rozmístit více typů entit v jednom nebo menším počtu kontejnerů. Tato metoda přináší výhody nejen z hlediska cen, ale také z hlediska provádění dotazů a transakcí. Dotazy jsou vymezeny na jeden kontejner; atomické transakce nad více záznamy prostřednictvím uložených procedur nebo triggerů jsou vymezeny na klíč oddílu v rámci jednoho kontejneru. Společné umístění entit ve stejném kontejneru může snížit počet odezvy sítě, aby se vyřešily vztahy 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 společné umístění více typů entit do jednoho nebo menšího počtu kontejnerů pro váš scénář obtížné, 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í s nižším využitím jednotek žádostí za sekundu

    Složitost dotazu má vliv na to, kolik jednotek žádostí (RU) se pro operaci spotřebuje. 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 se reprezentuje v jednotkách žádostí za sekundu neboli RU/s. Jednotka žádosti (RU) je logická abstrakce výpočetních prostředků, jako jsou procesor, paměť, vstupně-výstupní operace atd. které jsou nutné k provedení požadavku. Zřízená propustnost (RU) je vyhrazená a vyhrazená pro váš kontejner nebo databázi, aby se zajistila předvídatelná propustnost a latence. 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 uvažová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 dotaz například vrátí 1000 položek o 1 kB, náklady na operaci jsou 1000. Proto server během jedné sekundy vyhodne jenom dvěma takovým požadavkům, než omezí rychlost následných požadavků. Další informace najdete v článku o jednotkách žádostí a v kalkulačce jednotek žádostí.

Zápis dat

Náklady na RU při zápisu položky závisí na:

Vložení 1kB položky bez indexování stojí přibližně 5,5 RU. Nahrazení položky stojí dvojnásobek poplatku za vložení stejné položky.

Optimalizace zápisů

Nejlepší způsob, 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 má za následek vysoké poplatky za RU a je možné ho považovat za anti-vzor. Zejména neukládejte binární obsah nebo velké bloky textu, na které se nemusíte dotazovat. Osvědčeným postupem je umístit tento druh dat do Azure Blob Storage a uložit odkaz (nebo odkaz) na objekt blob v položce, kterou zapisujete do služby Azure Cosmos DB.
  • Optimalizace zásad indexování tak, aby indexovaly pouze vlastnosti, které filtrují vaše dotazy, může mít velký vliv na počet RU spotřebovaných vašimi operacemi zápisu. Výchozí zásady indexování při vytváření nového kontejneru indexují každou vlastnost nalezenou ve vašich položkách. I když se jedná o vhodné výchozí nastavení pro aktivity vývoje, důrazně doporučujeme znovu vyhodnotit a přizpůsobit zásady indexování , když přejdete do produkčního prostředí nebo když vaše úloha začne přijímat velký provoz.

Při hromadném příjmu dat se také doporučuje používat knihovnu Bulk Executor služby Azure Cosmos DB , která je navržená tak, aby optimalizovala spotřebu RU při takových operacích. Volitelně můžete použít také 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: