Optimalizace nákladů na zřízenou propustnost ve službě Azure Cosmos DB

  • Článek

PLATÍ PRO: NoSQL MongoDB Cassandra Gremlin Tabulka

Služba Azure Cosmos DB nabízí model zřízené propustnosti a nabízí předvídatelný výkon v libovolném měřítku. Pokud si předem rezervujete nebo zřídíte propustnost, eliminujete vliv hlučného souseda na výkon. Zadáte přesnou požadovanou propustnost a služba Azure Cosmos DB zaručuje nakonfigurovanou propustnost, kterou zajišťuje smlouva SLA.

Můžete začít s minimální propustností 400 RU/s a vertikálně navyšovat kapacitu až na desítky milionů požadavků za sekundu nebo i více. Každý požadavek, který vydáte vůči kontejneru nebo databázi Služby Azure Cosmos DB, jako je žádost o čtení, žádost o zápis, žádost o dotaz nebo uložené procedury, má odpovídající náklady, které se odečtou od zřízené propustnosti. Pokud zřídíte 400 RU/s a vydáte dotaz, který stojí 40 RU, budete moct vydat 10 takových dotazů za sekundu. Jakákoli žádost nad rámec této žádosti bude omezená rychlostí a měli byste ji zkusit zopakovat. Pokud používáte klientské ovladače, podporují logiku automatického opakování.

Propustnost můžete zřídit pro databáze nebo kontejnery a v závislosti na konkrétním scénáři vám obě strategie můžou pomoct ušetřit náklady.

Optimalizace zřízením propustnosti na různých úrovních

  • Pokud pro databázi zřídíte propustnost, všechny kontejnery, například kolekce, tabulky nebo grafy v této databázi, můžou sdílet propustnost na základě zatížení. Propustnost rezervovaná na úrovni databáze se sdílí nerovnoměrně v závislosti na zatížení konkrétní sady kontejnerů.

  • Pokud pro kontejner zřídíte propustnost, je propustnost pro tento kontejner zaručená na základě smlouvy SLA. Volba klíče logického oddílu je zásadní pro rovnoměrnou distribuci zatížení napříč všemi logickými oddíly kontejneru. Další podrobnosti najdete v článcích o dělení a horizontálním škálování .

Následuje několik pokynů pro rozhodování o strategii zřízené propustnosti:

Zřízení propustnosti pro databázi Azure Cosmos DB (obsahující sadu kontejnerů) zvažte v těchto případech:

  1. Máte několik desítek kontejnerů Azure Cosmos DB a chcete sdílet propustnost mezi některými nebo všemi z nich.

  2. Migrujete z databáze s jedním tenantem navrženou tak, aby běžela na virtuálních počítačích hostovaných IaaS nebo místně, například NoSQL nebo relačních databázích do Azure Cosmos DB. A pokud máte mnoho kolekcí, tabulek a grafů a nechcete v datovém modelu provádět žádné změny. Upozorňujeme, že pokud při migraci z místní databáze neaktualizujete datový model, možná budete muset ohrozit některé výhody, které nabízí Azure Cosmos DB. Datový model doporučujeme vždy přehodnocovat, abyste získali maximum z hlediska výkonu a také optimalizovali náklady.

  3. Chcete absorbovat neplánované špičky v úlohách na základě propustnosti ve fondu na úrovni databáze, u které dochází k neočekávanému nárůstu zatížení.

  4. Místo nastavení konkrétní propustnosti pro jednotlivé kontejnery se staráte o získání agregované propustnosti napříč sadou kontejnerů v rámci databáze.

Zřízení propustnosti pro jednotlivé kontejnery zvažte v následujících případech:

  1. Máte několik kontejnerů Azure Cosmos DB. Vzhledem k tomu, že služba Azure Cosmos DB je nezávislá na schématu, může kontejner obsahovat položky, které mají heterogenní schémata a nevyžaduje, aby zákazníci vytvořili více typů kontejnerů, jeden pro každou entitu. Vždy je vhodné zvážit, jestli má smysl seskupit například 10–20 kontejnerů do jednoho kontejneru. S minimálním 400 RU pro kontejnery může být sdružování všech 10–20 kontejnerů do jednoho nákladově efektivnější.

  2. Chcete řídit propustnost konkrétního kontejneru a získat zaručenou propustnost pro daný kontejner, který je zajištěný smlouvou SLA.

Zvažte hybrid výše uvedených dvou strategií:

  1. Jak už bylo zmíněno dříve, Azure Cosmos DB umožňuje kombinovat a shodovat výše uvedené dvě strategie, takže teď můžete mít v databázi Azure Cosmos DB kontejnery, které můžou sdílet propustnost zřízenou v databázi, a také některé kontejnery v rámci stejné databáze, které můžou mít vyhrazené množství zřízené propustnosti.

  2. Pomocí výše uvedených strategií můžete vytvořit hybridní konfiguraci, kdy máte zřízenou propustnost na úrovni databáze s některými kontejnery s vyhrazenou propustností.

Jak je znázorněno v následující tabulce, v závislosti na volbě rozhraní API můžete zřizovat propustnost s různými podrobnostmi.

rozhraní API Pro sdílenou propustnost nakonfigurujte Pro vyhrazenou propustnost nakonfigurujte
Rozhraní API pro NoSQL databáze Kontejner
Rozhraní API služby Azure Cosmos DB pro MongoDB Databáze Kolekce
Rozhraní API pro Cassandra Prostor klíčů Tabulka
Rozhraní API pro Gremlin Databázový účet Graph
Rozhraní API pro tabulku Databázový účet Tabulka

Zřízením propustnosti na různých úrovních můžete optimalizovat náklady na základě charakteristik úloh. Jak už bylo zmíněno dříve, můžete prostřednictvím kódu programu kdykoli zvýšit nebo snížit zřízenou propustnost pro jednotlivé kontejnery nebo souhrnně napříč sadou kontejnerů. Elastickým škálováním propustnosti při změnách úloh platíte jenom za propustnost, kterou jste nakonfigurovali. Pokud je váš kontejner nebo sada kontejnerů distribuovaná do více oblastí, je zaručeno, že propustnost nakonfigurovaná pro kontejner nebo sadu kontejnerů bude k dispozici ve všech oblastech.

Optimalizace s využitím omezování rychlosti požadavků

U úloh, které nejsou citlivé na latenci, můžete zřídit menší propustnost a nechat aplikaci, aby zpracovávala omezení rychlosti, když skutečná propustnost překročí zřízenou propustnost. Server předběžně ukončí požadavek ( RequestRateTooLarge stavový kód HTTP 429) a vrátí hlavičku x-ms-retry-after-ms označující dobu v milisekundách, kterou musí uživatel před opakováním požadavku počkat.

HTTP Status 429, 
 Status Line: RequestRateTooLarge 
 x-ms-retry-after-ms :100

Logika opakování v sadách SDK

Nativní sady SDK (.NET/.NET Core, Java, Node.js a Python) implicitně zachytí tuto odpověď, respektují hlavičku retry-after zadanou serverem a zkusí požadavek zopakovat. Pokud k vašemu účtu přistupuje současně více klientů, bude další opakování úspěšné.

Pokud máte více klientů, kteří pracují konzistentně nad frekvencí požadavků, výchozí počet opakování, který je aktuálně nastavený na 9, nemusí být dostatečný. V takových případech klient vyhodí aplikaci stavový RequestRateTooLargeException kód 429. Výchozí počet opakování lze změnit nastavením RetryOptions hodnoty v instanci ConnectionPolicy. Ve výchozím nastavení RequestRateTooLargeException se stavový kód se stavovým kódem 429 vrátí po kumulativní čekací době 30 sekund, pokud požadavek dál funguje nad četností 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í, ať už je to výchozí hodnota 9, nebo uživatelsky definovaná hodnota.

MaxRetryAttemptsOnThrottledRequests je nastavená na hodnotu 3, takže v tomto případě, pokud je operace požadavku omezená překročením rezervované propustnosti pro kontejner, operace požadavku třikrát opakuje, než vyvolá výjimku do aplikace. MaxRetryWaitTimeInSeconds je nastavená na 60, takže v tomto případě pokud kumulativní doba čekání opakování v sekundách od prvního požadavku přesáhne 60 sekund, vyvolá se výjimka.

ConnectionPolicy connectionPolicy = new ConnectionPolicy(); 
connectionPolicy.RetryOptions.MaxRetryAttemptsOnThrottledRequests = 3; 
connectionPolicy.RetryOptions.MaxRetryWaitTimeInSeconds = 60;

Strategie dělení a náklady na zřízenou propustnost

Dobrá strategie dělení je důležitá pro optimalizaci nákladů ve službě Azure Cosmos DB. Ujistěte se, že nedochází k nerovnoměrné distribuci oddílů, které se zveřejňují prostřednictvím metrik úložiště. Ujistěte se, že u oddílu, který je vystavený metrikami propustnosti, nedochází k nerovnoměrné distribuci propustnosti. Ujistěte se, že nedochází k nerovnoměrné distribuci směrem ke konkrétním klíčům oddílů. Dominantní klíče v úložišti se zveřejňují prostřednictvím metrik, ale klíč bude záviset na vašem vzoru přístupu k aplikaci. Nejlepší je zamyslet se nad správným klíčem logického oddílu. Očekává se, že dobrý klíč oddílu bude mít následující vlastnosti:

  • Zvolte klíč oddílu, který rovnoměrně rozloží úlohy napříč všemi oddíly a rovnoměrně v průběhu času. Jinými slovy byste neměli mít některé klíče s většinou dat a některé klíče s menším nebo žádným datem.

  • Zvolte klíč oddílu, který umožňuje rovnoměrné rozložení vzorů přístupu mezi logické oddíly. Úloha je přiměřeně i napříč všemi klíči. Jinými slovy, většina úloh by neměla být zaměřená na několik konkrétních klíčů.

  • Zvolte klíč oddílu, který má širokou škálu hodnot.

Základní myšlenkou je rozložit data a aktivitu v kontejneru do sady logických oddílů, aby prostředky pro úložiště dat a propustnost bylo možné distribuovat napříč logickými oddíly. Kandidáti na klíče oddílů můžou zahrnovat vlastnosti, které se ve vašich dotazech často zobrazují jako filtr. Zahrnutím klíče oddílu do predikátu filtru můžete zajistit efektivní směrování dotazů. Díky takové strategii dělení bude optimalizace zřízené propustnosti mnohem jednodušší.

Návrh menších položek pro vyšší propustnost

Poplatek za požadavek nebo náklady na zpracování žádosti dané operace jsou přímo v korelaci s velikostí položky. Operace s velkými položkami budou dražší než operace s menšími položkami.

Vzory přístupu k datům

Vždy je vhodné data logicky rozdělit do logických kategorií na základě toho, jak často k datům přistupujete. Když je kategorizujete jako horká, střední nebo studená data, můžete doladit využité úložiště a požadovanou propustnost. V závislosti na frekvenci přístupu můžete data umístit do samostatných kontejnerů (například tabulek, grafů a kolekcí) a vyladit zřízenou propustnost v těchto kontejnerech tak, aby vyhovovala potřebám daného segmentu dat.

Pokud navíc používáte Službu Azure Cosmos DB a víte, že nebudete vyhledávat podle určitých hodnot dat nebo k nim budete přistupovat jen zřídka, měli byste uložit komprimované hodnoty těchto atributů. Touto metodou ušetříte místo v úložišti, prostor indexu a zřízenou propustnost a snížíte tak náklady.

Optimalizace změnou zásad indexování

Azure Cosmos DB ve výchozím nastavení automaticky indexuje všechny vlastnosti každého záznamu. Cílem je usnadnit vývoj a zajistit vynikající výkon v mnoha různých typech ad hoc dotazů. Pokud máte velké záznamy s tisíci vlastnostmi, nemusí být platba nákladů na propustnost za indexování každé vlastnosti užitečná, zejména pokud se dotazujete pouze na 10 nebo 20 z těchto vlastností. Jak se blížíte k získání popisovače pro konkrétní úlohu, naším doprovodným materiálem je vyladit zásady indexu. Úplné podrobnosti o zásadách indexování služby Azure Cosmos DB najdete tady.

Monitorování zřízené a spotřebované propustnosti

Můžete monitorovat celkový počet zřízených RU, počet požadavků s omezenou rychlostí a také počet jednotek RU, které jste spotřebovali v Azure Portal. Následující obrázek ukazuje příklad metriky využití:

Monitorování jednotek žádostí v Azure Portal

Můžete také nastavit upozornění, která zkontrolují, jestli počet požadavků omezených rychlostí nepřekračuje určitou prahovou hodnotu. Další podrobnosti najdete v článku Monitorování služby Azure Cosmos DB . Tato upozornění můžou odeslat e-mail správcům účtu nebo zavolat vlastní webhook HTTP nebo funkci Azure Functions, aby se automaticky zvýšila zřízená propustnost.

Elastické škálování propustnosti a na vyžádání

Vzhledem k tomu, že se vám účtuje zřízená propustnost, párování zřízené propustnosti vašim potřebám vám může pomoct vyhnout se poplatkům za nevyužitou propustnost. Zřízenou propustnost můžete podle potřeby kdykoli vertikálně navýšit nebo snížit. Pokud jsou vaše požadavky na propustnost velmi předvídatelné, můžete použít Azure Functions a trigger časovače a zvýšit nebo snížit propustnost podle plánu.

  • Monitorování spotřeby RU a poměru požadavků s omezenou rychlostí může odhalit, že nemusíte neustále zřizovat po celý den nebo v týdnu. V noci nebo o víkendu může být provoz menší. Zřízenou propustnost můžete kdykoli škálovat pomocí Azure Portal nebo nativních sad SDK nebo rozhraní REST API služby Azure Cosmos DB. Rozhraní REST API služby Azure Cosmos DB poskytuje koncové body, které prostřednictvím kódu programu aktualizují úroveň výkonu kontejnerů, což usnadňuje úpravu propustnosti kódu v závislosti na denní době nebo dni v týdnu. Operace se provádí bez výpadků a obvykle se projeví za méně než minutu.

  • Jednou z oblastí, ve které byste měli škálovat propustnost, je příjem dat do služby Azure Cosmos DB, například během migrace dat. Po dokončení migrace můžete vertikálně snížit zřízenou propustnost tak, aby zvládla stabilní stav řešení.

  • Mějte na paměti, že fakturace je v intervalu jedné hodiny, takže pokud budete měnit zřízenou propustnost častěji než jednu hodinu, neušetříte žádné peníze.

Určení propustnosti potřebné pro novou úlohu

Pokud chcete zjistit zřízenou propustnost pro novou úlohu, můžete použít následující kroky:

  1. Pomocí plánovače kapacity proveďte počáteční hrubé vyhodnocení a upravte odhady pomocí Průzkumníka služby Azure Cosmos DB v Azure Portal.

  2. Doporučujeme vytvořit kontejnery s vyšší propustností, než se čekalo, a pak podle potřeby vertikálně snížit kapacitu.

  3. Doporučuje se použít některou z nativních sad SDK služby Azure Cosmos DB, abyste mohli využít výhod automatických opakovaných pokusů při omezování rychlosti požadavků. Pokud pracujete na nepodporovaná platformě a používáte rozhraní REST API služby Azure Cosmos DB, implementujte vlastní zásady opakování pomocí hlavičky x-ms-retry-after-ms .

  4. Ujistěte se, že kód vaší aplikace řádně podporuje případ, kdy všechny pokusy o opakování selžou.

  5. Můžete nakonfigurovat upozornění z Azure Portal, abyste dostávali oznámení o omezování rychlosti. Můžete začít s konzervativními limity, jako je 10 požadavků s omezenou rychlostí za posledních 15 minut, a jakmile zjistíte, jak spotřeba skutečně spotřebováváte, můžete přejít na dychtivější pravidla. Občas jsou limity rychlosti v pořádku, ukazují, že si hrajete s limity, které jste nastavili, a přesně to chcete udělat.

  6. Monitorování vám umožní porozumět vašemu způsobu provozu, abyste mohli zvážit, jestli je potřeba dynamicky upravovat zřizování propustnosti v průběhu dne nebo týdne.

  7. Pravidelně monitorujte poměr zřízené a spotřebované propustnosti a ujistěte se, že jste nezřídili více než požadovaný počet kontejnerů a databází. Dobrou bezpečnostní kontrolou je trochu vyšší zřízená propustnost.

Osvědčené postupy pro optimalizaci zřízené propustnosti

Následující kroky vám pomůžou zajistit, aby vaše řešení byla při používání služby Azure Cosmos DB vysoce škálovatelná a nákladově efektivní.

  1. Pokud máte výrazně vyšší zřízenou propustnost napříč kontejnery a databázemi, měli byste zkontrolovat zřízené RU a spotřebované RU a vyladit úlohy.

  2. Jedním ze způsobů, jak odhadnout množství rezervované propustnosti vyžadované vaší aplikací, je zaznamenat poplatky za jednotky žádosti RU spojené se spouštěním typických operací s reprezentativním kontejnerem nebo databází Azure Cosmos DB, kterou vaše aplikace používá, a pak odhadnout počet operací, které očekáváte provádět každou sekundu. Nezapomeňte změřit a zahrnout také typické dotazy a jejich využití. Informace o tom, jak odhadnout náklady na RU dotazů prostřednictvím kódu programu nebo pomocí portálu, najdete v tématu Optimalizace nákladů na dotazy.

  3. Dalším způsobem, jak získat operace a jejich náklady v RU, je povolení protokolů Služby Azure Monitor, které vám poskytnou rozpis operací a doby trvání a poplatky za požadavek. Azure Cosmos DB poskytuje poplatky za požadavky pro každou operaci, takže každý poplatek za operaci je možné uložit zpět z odpovědi a pak je použít k analýze.

  4. Zřízenou propustnost můžete elasticky vertikálně navyšovat nebo snížit, jak potřebujete, abyste vyhověli potřebám vašich úloh.

  5. Podle potřeby můžete přidávat a odebírat oblasti přidružené k vašemu účtu služby Azure Cosmos DB a řídit náklady.

  6. Ujistěte se, že máte rovnoměrně rozdělená data a úlohy napříč logickými oddíly kontejnerů. Pokud máte nerovnoměrnou distribuci oddílů, může to způsobit zřízení vyšší propustnosti, než je potřebná hodnota. Pokud zjistíte, že máte nerovnoměrnou distribuci, doporučujeme distribuovat úlohy rovnoměrně napříč oddíly nebo rozdělit data na oddíly.

  7. Pokud máte mnoho kontejnerů a tyto kontejnery nevyžadují smlouvy SLA, můžete použít nabídku založenou na databázi v případech, kdy se smlouvy SLA o propustnosti jednotlivých kontejnerů nevztahují. Měli byste určit, které z kontejnerů Azure Cosmos DB chcete migrovat na nabídku propustnosti na úrovni databáze, a pak je migrovat pomocí řešení založeného na kanálu změn.

  8. Zvažte použití služby Azure Cosmos DB úrovně Free (zdarma po dobu jednoho roku), vyzkoušení služby Azure Cosmos DB (až do tří oblastí) nebo stažení emulátoru služby Azure Cosmos DB pro vývoj/testování. Použitím těchto možností pro testování a vývoj můžete výrazně snížit náklady.

  9. Můžete dále optimalizovat náklady specifické pro úlohy – například zvětšit velikost dávky, vyrovnává zatížení čtení mezi více oblastmi a odstranění duplicit dat (pokud je to možné).

  10. S rezervovanou kapacitou služby Azure Cosmos DB můžete na tři roky získat výrazné slevy až 65 %. Model rezervované kapacity služby Azure Cosmos DB je počáteční závazek jednotek žádostí potřebných v průběhu času. Slevy jsou odstupňované tak, že čím více jednotek žádostí využijete v delším období, tím větší bude vaše sleva. Tyto slevy jsou uplatněny okamžitě. Všechny jednotky RU použité nad vašimi zřízenými hodnotami se účtují na základě nákladů na nevyhraděnou kapacitu. Další podrobnosti najdete v tématu Rezervovaná kapacita služby Azure Cosmos DB). Zvažte nákup rezervované kapacity, abyste ještě snížili náklady na zřízenou propustnost.

Další kroky

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