Sdílet prostřednictvím

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

  • Článek

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

Díky nabídce modelu zřízené propustnosti nabízí Azure Cosmos DB předvídatelný výkon v libovolném měřítku. Rezervace nebo zřizování propustnosti předem eliminuje vliv "hlučného souseda" na váš výkon. Zadáte přesnou propustnost, kterou potřebujete, a 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ě navýšit kapacitu až na desítky milionů požadavků za sekundu nebo ještě více. Každá žádost, kterou vydáváte vůči kontejneru nebo databázi Azure Cosmos DB, jako je žádost o čtení, žádost o zápis, požadavek na dotaz, mají uložené procedury 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 požadavek nad rámec této rychlosti je omezený a měli byste požadavek 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 u databáze zřídíte propustnost, můžou všechny kontejnery, například kolekce, tabulky a grafy v této databázi sdílet propustnost na základě zatížení. Propustnost vyhrazená na úrovni databáze se sdílí nerovnoměrně v závislosti na úloze na konkrétní sadě kontejnerů.

  • Pokud u kontejneru zřídíte propustnost, je pro tento kontejner zaručená propustnost, která je zajištěná smlouvou SLA. Volba logického klíče oddílu je zásadní pro rovnoměrné rozdělení 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í.

Tady jsou některé pokyny pro rozhodnutí o strategii zřízené propustnosti:

Zvažte zřízení propustnosti databáze Azure Cosmos DB (obsahující sadu kontejnerů), pokud:

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

  2. Migrujete z databáze s jedním tenantem, která je navržená tak, aby běžela na virtuálních počítačích hostovaných v IaaS nebo v místním prostředí, například z NoSQL nebo relačních databází do služby Azure Cosmos DB. A pokud máte mnoho kolekcí, tabulek a grafů a nechcete provádět žádné změny datového modelu. Upozorňujeme, že pokud při migraci z místní databáze neaktualizujete datový model, budete možná muset ohrozit některé výhody, které nabízí Azure Cosmos DB. Doporučujeme vždy znovu vyhodnotit datový model, 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 vystavené neočekávanému nárůstu zatížení.

  4. Místo nastavení konkrétní propustnosti jednotlivých kontejnerů vám záleží na tom, jak získat agregovanou propustnost mezi sadou kontejnerů v databázi.

Zvažte zřízení propustnosti pro jednotlivé kontejnery, pokud:

  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 s heterogenními schématy 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 seskupování samostatných kontejnerů řekněme 10–20 do jednoho kontejneru dává smysl. S minimálním 400 RU pro kontejnery může být sdružování všech 10 až 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 hybridní použití 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 ve stejné databázi, které můžou mít vyhrazené objemy zřízené propustnosti.

  2. Výše uvedené strategie můžete použít k vytvoření hybridní konfigurace, kdy máte zřízenou propustnost na obou úrovních databáze s některými kontejnery s vyhrazenou propustností.

Jak je znázorněno v následující tabulce, v závislosti na výběru rozhraní API můžete zřídit propustnost v různých členitosti.

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íčů Table
Rozhraní API pro Gremlin Databázový účet Graf
Rozhraní API pro tabulku Databázový účet Table

Zřízením propustnosti na různých úrovních můžete optimalizovat náklady na základě charakteristik vaší úlohy. Jak už bylo zmíněno dříve, můžete programově a kdykoli zvýšit nebo snížit zřízenou propustnost pro jednotlivé kontejnery nebo souhrnně napříč sadou kontejnerů. Díky elastickému škálování propustnosti při změnách úloh platíte jenom za nakonfigurovanou propustnost. Pokud je kontejner nebo sada kontejnerů distribuovaná napříč několika oblastmi, je zaručeno, že propustnost nakonfigurovaná pro kontejner nebo sadu kontejnerů bude dostupná napříč všemi oblastmi.

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 zpracovat omezování rychlosti, když skutečná propustnost překročí zřízenou propustnost. Server předem ukončí požadavek se stavovým kódem RequestRateTooLarge HTTP 429 a vrátí x-ms-retry-after-ms hlavičku označující dobu v milisekundách, po 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ě zachytají tuto odpověď, respektují hlavičku opakování zadaného serverem a opakujte požadavek. Pokud k vašemu účtu nemá přístup souběžně 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í, který je aktuálně nastavený na 9, nemusí být dostatečný. V takových případech klient vyvolá do aplikace stavový RequestRateTooLargeException kód 429. Výchozí počet opakování lze změnit nastavením RetryOptions instance ConnectionPolicy. Ve výchozím nastavení RequestRateTooLargeException se stavový kód 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.

MaxRetryAttemptsOnThrottledRequests je nastaveno na 3, takže v tomto případě pokud je operace požadavku omezená překročením rezervované propustnosti kontejneru, operace požadavku opakuje třikrát předtím, než vyvolá výjimku 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řesahuje 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. Zajistěte, aby nedošlo k nerovnoměrné distribuci oddílů, které jsou vystavené prostřednictvím metrik úložiště. Ujistěte se, že pro oddíl neexistuje žádná nerovnoměrná distribuce propustnosti, která je vystavená metrikami propustnosti. Ujistěte se, že nedošlo k nerovnoměrné distribuci konkrétních klíčů oddílů. Dominantní klíče v úložišti se zveřejňují prostřednictvím metrik, ale klíč závisí na vzoru přístupu k vaší aplikaci. Nejlepší je uvažovat o správném logickém klíči oddílu. Očekává se, že dobrý klíč oddílu bude mít následující charakteristiky:

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

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

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

Základní myšlenkou je rozložení dat a aktivity v kontejneru do sady logických oddílů, aby se prostředky pro úložiště dat a propustnost mohly distribuovat napříč logickými oddíly. Kandidáti na klíče oddílů můžou obsahovat vlastnosti, které se v 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í je optimalizace zřízené propustnosti mnohem jednodušší.

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

Poplatek za žádost nebo náklady na zpracování žádosti dané operace přímo korelují s velikostí položky. Operace s velkými položkami stojí více než operace s menšími položkami.

Vzory přístupu k datům

Vždy je vhodné data logicky oddě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 vyladit spotřebované ú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 do tabulek, grafů a kolekcí) a doladit zřízenou propustnost tak, aby vyhovovala potřebám tohoto segmentu dat.

Navíc pokud používáte Službu Azure Cosmos DB a víte, že nebudete hledat podle určitých datových hodnot nebo k nim budete mít zřídka přístup, měli byste uložit komprimované hodnoty těchto atributů. Díky této metodě ušetříte místo na úložišti, prostor indexu a zřízenou propustnost a snížíte náklady.

Optimalizace změnou zásad indexování

Azure Cosmos DB ve výchozím nastavení automaticky indexuje každou vlastnost 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 vlastností, 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 těchto vlastností. Když se blíže seznámíte s konkrétní úlohou, naše pokyny vám pomůžou 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 jednotek žádostí, počet požadavků omezených rychlostí a počet RU, které jste spotřebovali na webu Azure Portal. Další informace najdete v tématu Analýza metrik služby Azure Cosmos DB. Následující obrázek ukazuje ukázkovou metriku využití:

Monitorování jednotek žádostí na webu Azure Portal

Můžete také nastavit upozornění, která kontrolují, jestli počet požadavků omezených rychlostí překročí určitou prahovou hodnotu. Další informace o výstrahách najdete v tématu Upozornění služby Azure Monitor.

Škálování propustnosti elasticky a na vyžádání

Vzhledem k tomu, že se vám účtuje zřízená propustnost, může vám to pomoct vyhnout se poplatkům za nevyužitou propustnost. Zřízenou propustnost můžete podle potřeby škálovat nahoru nebo dolů. Pokud jsou vaše potřeby propustnosti velmi předvídatelné, můžete použít Azure Functions a pomocí triggeru časovače zvýšit nebo snížit propustnost podle plánu.

  • Monitorování spotřeby jednotek RU a poměr požadavků omezených rychlostí může odhalit, že v průběhu dne nebo v týdnu nemusíte neustále zřizovat. V noci nebo o víkendu můžete dostávat méně provozu. Pomocí webu Azure Portal nebo nativních sad SDK služby Azure Cosmos DB nebo rozhraní REST API můžete zřízenou propustnost kdykoli škálovat. Rozhraní REST API služby Azure Cosmos DB poskytuje koncové body pro programovou aktualizaci úrovně výkonu kontejnerů, což usnadňuje úpravu propustnosti kódu v závislosti na denním nebo denním 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ých byste měli propustnost škálovat, 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, abyste zvládli stabilní stav řešení.

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

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

K určení zřízené propustnosti pro novou úlohu můžete použít následující kroky:

  1. Pomocí Plánovače kapacity proveďte počáteční přibližné vyhodnocení a upravte odhady pomocí Průzkumníka služby Azure Cosmos DB na webu Azure Portal.

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

  3. Doporučuje se použít jednu z nativních sad SDK služby Azure Cosmos DB, abyste mohli využít výhod automatických opakovaných pokusů, když požadavky získají omezenou rychlost. Pokud pracujete na platformě, která není podporovaná 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 aplikace řádně podporuje případ, když všechny opakování selžou.

  5. Upozornění můžete nakonfigurovat na webu Azure Portal, abyste dostávali oznámení o omezování rychlosti. Můžete začít s konzervativními limity, jako jsou 10 požadavků omezených rychlostí za posledních 15 minut, a přepnout na více dychtivých pravidel, jakmile zjistíte skutečnou spotřebu. Občasné limity rychlosti jsou v pořádku, ukazují, že hrajete s limity, které jste nastavili, a přesně to, co chcete udělat.

  6. Využijte monitorování, abyste porozuměli způsobu provozu, abyste mohli zvážit potřebu dynamicky upravit zřizování propustnosti za den nebo týden.

  7. Pravidelně monitorujte zřízený a spotřebovaný poměr propustnosti, abyste měli jistotu, že jste nezřídili více než požadovaný počet kontejnerů a databází. Dobrá bezpečnostní kontrola má trochu vyšší zřízenou 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 vysoce škálovatelná a nákladově efektivní při používání služby Azure Cosmos DB.

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

  2. Jednou z metod odhadu množství rezervované propustnosti vyžadované vaší aplikací je zaznamenání poplatku za jednotku žádosti spojené se spouštěním typických operací vůči reprezentativnímu kontejneru nebo databázi Azure Cosmos DB, kterou vaše aplikace používá, a pak odhadnout počet operací, které očekáváte každou sekundu. Nezapomeňte měřit a zahrnout také typické dotazy a jejich využití. Informace o tom, jak programově nebo pomocí portálu odhadnout náklady na RU dotazů, 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ím protokolů služby Azure Monitor, které vám poskytnou rozpis operací a doby trvání a poplatky za žádost. Azure Cosmos DB poskytuje poplatky za požadavky pro každou operaci, takže všechny poplatky za operace 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ě navýšit nebo snížit, protože potřebujete vyhovět potřebám vašich úloh.

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

  6. Ujistěte se, že máte rovnoměrnou distribuci dat a úloh 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ě mezi oddíly nebo znovu rozdělit data.

  7. Pokud máte mnoho kontejnerů a tyto kontejnery nevyžadují smlouvy SLA, můžete použít nabídku založenou na databázi pro případy, kdy se smlouvy SLA pro propustnost kontejnerů nevztahují. Měli byste určit, které kontejnery 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í úrovně Free služby Azure Cosmos DB (zdarma na jeden rok), vyzkoušejte službu Azure Cosmos DB (až tři oblasti) nebo si stáhněteelný emulátor služby Azure Cosmos DB pro scénáře vývoje a testování. Pomocí těchto možností pro testování-vývoj můžete podstatně snížit náklady.

  9. Optimalizaci nákladů specifických pro úlohy můžete dále provádět – například zvýšení velikosti dávky, vyrovnávání zatížení čtení napříč několika oblastmi a odstranění duplicit dat, pokud je to možné.

  10. S rezervovanou kapacitou služby Azure Cosmos DB můžete získat významné slevy až na 65 % po dobu tří let. Model rezervované kapacity služby Azure Cosmos DB je počáteční závazek jednotek požadavků potřebných v průběhu času. Slevy jsou vrstvené tak, že čím více jednotek žádostí použijete v delším období, tím větší bude vaše sleva. Tyto slevy se použijí okamžitě. Všechny ru použité nad vašimi zřízenými hodnotami se účtují na základě nákladů na neplacenou kapacitu. Další podrobnosti najdete v tématu Rezervovaná kapacita služby Azure Cosmos DB. Zvažte nákup rezervované kapacity, abyste 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: