Konfigurace výpočetních prostředků a úložiště pro Azure DocumentDB

Výpočetní prostředky Azure DocumentDB jsou poskytovány jako virtuální jádra, které představují logický procesor základního hardwaru. Velikost úložiště pro poskytování odkazuje na kapacitu dostupnou pro shardy ve vašem clusteru.

Úložiště se používá pro databázové soubory, dočasné soubory, transakční protokoly a protokoly databázového serveru. Nastavení výpočetních prostředků a úložiště můžete vybrat nezávisle. Vybrané výpočetní a úložné hodnoty se vztahují na každý shard v clusteru.

Výpočty v Azure DocumentDB

Celkové množství paměti RAM v jediném shardu se odvíjí od vybraného počtu virtuálních jader.

Úroveň clusteru vCores Jeden fragment, GiB RAM
M10 1 (rozšiřitelné) 2
M20 2 (překročitelné) 4
M25 2 (překročitelné) 8
M30 2 8
M40 4 16
M50 8 32
M60 16 64
M80 32 128
M200 64 256

Důležité informace o výpočetních prostředcích a úložištích

Při konfiguraci clusteru Azure DocumentDB je důležité pochopit, jak volby výpočetních prostředků a úložiště ovlivňují výkon, náklady a škálovatelnost konkrétní úlohy.

Úvahy o pracovní sadě a paměti

V Azure DocumentDB pracovní sada odkazuje na část vašich dat, ke které se často přistupuje a používá vaše aplikace. Zahrnuje data i indexy, které se pravidelně čtou nebo zapisují během typických operací aplikace. Koncept pracovní sady je důležitý pro optimalizaci výkonu, protože MongoDB, jako je mnoho databází, funguje nejlépe, když pracovní sada zapadá do paměti RAM.

Pokud chcete definovat pracovní sadu databáze MongoDB a porozumět jí, zvažte následující komponenty:

  1. Často přístupná data: Tato data zahrnují dokumenty, které vaše aplikace čte nebo pravidelně aktualizuje.
  2. Indexy: Indexy používané v operacích dotazů také tvoří součást pracovní sady, protože je potřeba je načíst do paměti, aby se zajistil rychlý přístup.
  3. Vzory použití aplikací: Analýza vzorů použití vaší aplikace vám může pomoct určit, ke kterým částem dat se přistupuje nejčastěji.

Když necháte pracovní sadu v paměti RAM, můžete minimalizovat pomalejší vstupně-výstupní operace disku, čímž zlepšíte výkon databáze MongoDB. Pokud vaše pracovní sada překročí dostupnou paměť RAM, zvažte optimalizaci datového modelu, přidání další paměti RAM do clusteru nebo použití horizontálního dělení k distribuci dat mezi více uzlů.

Volba optimální konfigurace pro úlohu

Určení správné konfigurace výpočetních prostředků a úložiště pro úlohy Azure DocumentDB zahrnuje vyhodnocení několika faktorů souvisejících s požadavky a vzory použití vaší aplikace. Mezi klíčové kroky a důležité informace pro určení optimální konfigurace patří:

  1. Vysvětlení úloh

    • Objem dat: Odhad celkové velikosti dat včetně indexů.
    • Poměr čtení a zápisu: Určete poměr operací čtení s operacemi zápisu.
    • Vzory dotazů: Analyzujte typy dotazů, které vaše aplikace provádí. Například jednoduché čtení, složité agregace.
    • Souběžnost: Vyhodnoťte počet souběžných operací, které vaše databáze potřebuje zpracovat.
  2. Monitorování aktuálního výkonu

    • Zdrojové využití: Pomocí monitorovacích nástrojů můžete sledovat využití procesoru, paměti, vstupně-výstupních operací disku a sítě před migrací úloh do Azure. Po nasazení úlohy MongoDB v clusteru Azure DocumentDB pokračujte v monitorování pomocí metrik monitorování Azure.
    • Metriky výkonu: Monitorujte klíčové metriky výkonu, jako jsou latence, propustnost a poměry přístupů do mezipaměti.
    • Kritické body: Identifikujte všechny stávající kritické body výkonu, jako je vysoké využití procesoru, zatížení paměti nebo pomalé vstupně-výstupní operace disku.
  3. Odhad požadavků na prostředky

    • Paměť: Ujistěte se, že vaše pracovní sada (často přístupná data a indexy) zapadá do paměti RAM. Pokud velikost pracovní sady překročí dostupnou paměť, zvažte přidání další paměti RAM nebo optimalizaci datového modelu.
    • Cpu: Zvolte konfiguraci procesoru, která dokáže zpracovat požadavky na zatížení dotazů a souběžnost. Úlohy náročné na procesor můžou vyžadovat více jader. K zobrazení historických vzorů využití výpočetních prostředků použijte metriku Procento procesoru s agregací Max v clusteru Azure DocumentDB.
    • IOPS úložiště: Pomocí metriky IOPS s agregací Max v clusteru můžete zobrazit historické využití IOPS úložiště.
    • Síť: Zajistěte dostatečnou šířku pásma sítě pro zpracování přenosu dat mezi vaší aplikací a databází, zejména pro distribuované nastavení. Ujistěte se, že jste pro aplikaci MongoDB nakonfigurovali hostitele pro podporu akcelerovaných síťových technologií, jako je SR-IOV.
  4. Vhodné škálování

    • Vertikální škálování: Škáluje výpočetní prostředky / PAMĚŤ RAM nahoru a dolů a vertikálně navyšuje kapacitu úložiště.
      • Výpočty: Pokud vaše úloha vyžaduje dočasné zvýšení nebo překročení 70% využití procesoru po delší dobu, zvyšte počet virtuálních jader nebo paměti RAM v clusteru.
      • Ujistěte se, že máte v databázi Azure DocumentDB odpovídající uchovávání dat. Uchovávání vám umožní vyhnout se zbytečnému použití úložiště. Monitorování využití úložiště nastavením upozornění na metriky "Procento úložiště" nebo "Využité úložiště" s agregací Max. Zvažte zvýšení velikosti úložiště, protože velikost úloh překračuje 70% využití.
    • Horizontální škálování: Zvažte použití několika shardů pro váš cluster k distribuci dat mezi několik uzlů Azure DocumentDB pro zvýšení výkonu a lepší správu kapacity s rostoucí pracovní zátěží. Toto škálování je zvláště užitečné pro velké datové sady (více než 2–4 TiB) a aplikace s vysokou propustností.
  5. Testování a iterace

    • Srovnávací testy: Měření pro nejčastěji používané dotazy s různými konfiguracemi k určení vlivu na výkon. Použijte metriky procesoru a paměti RAM a IOPS a srovnávací testy na úrovni aplikace.
    • Zátěžové testování: Proveďte zátěžové testování pro simulaci produkčních úloh a ověřte výkon zvolené konfigurace.
    • Průběžné monitorování: Průběžně monitorujte nasazení Azure DocumentDB a upravte prostředky podle potřeby na základě změn úloh a vzorů využití.

Díky systematicky vyhodnocovat tyto faktory a průběžně monitorovat a upravovat konfiguraci můžete zajistit, aby nasazení MongoDB bylo dobře optimalizované pro vaši konkrétní úlohu.

Důležité informace o úložišti

Rozhodování o vhodné velikosti úložiště pro vaši úlohu zahrnuje několik aspektů, které zajistí optimální výkon a škálovatelnost. Tady jsou důležité informace o velikosti úložiště v Azure DocumentDB:

  1. Odhad velikosti dat:

    • Vypočítejte očekávanou velikost dat Azure DocumentDB. Zvažte:
      • Aktuální velikost dat: Pokud migrujete z existující databáze.
      • Tempo růstu: Odhadnout, kolik dat se bude v průběhu času přidávat.
      • Velikost a struktura dokumentu: Seznamte se se schématem dat a velikostmi dokumentů, protože ovlivňují efektivitu úložiště.
  2. Faktor v indexech:

    • Azure DocumentDB používá k efektivnímu dotazování indexy . Indexy spotřebovávají místo na disku.
    • Odhad velikosti indexů na základě:
      • Počet indexů
      • Velikost indexovaných polí
  3. Faktory ovlivňující výkon:

    • Výkon disku má vliv na databázové operace, zejména pro úlohy, které nemohou uložit svou pracovní sadu do paměti RAM. Zvažte:
      • Propustnost I/O: IOPS, neboli počet vstupně-výstupních operací za sekundu, je počet požadavků odesílaných na disková úložiště během jedné sekundy. Disky SSD úrovně Premium v2 jsou nakonfigurované s nejvyšší dosažitelnou IOPS a šířkou pásma, kterou může výpočetní úroveň nabízet. Zajistěte odpovídající propustnost pro operace čtení a zápisu. K monitorování využitých IOPS v clusteru použijte metriku IOPS s agregací Max.
      • Latence: Latence je doba, kterou aplikace potřebuje k přijetí jednoho požadavku, odeslání na disky úložiště a odeslání odpovědi klientovi. Latence je důležitou mírou výkonu aplikace kromě IOPS a propustnosti. Typ použitého úložiště a konfigurace úložiště do značné míry definuje latenci. Ve spravované službě, jako je Azure DocumentDB, se rychlé úložiště, jako jsou disky SSD úrovně Premium, používá s nastavením optimalizovaným pro snížení latence.
  4. Budoucí růst a škálovatelnost:

    • Naplánujte budoucí růst dat a potřeby škálovatelnosti.
    • Přidělte více místa na disku nad rámec aktuálních potřeb pro přizpůsobení růstu bez častých rozšíření úložiště.
  5. Příklad výpočtu:

    • Předpokládejme, že vaše počáteční velikost dat je 500 GiB.
    • S indexy může růst na 700 GiB.
    • Pokud očekáváte zdvojnásobení dat za dva roky, naplánujte 1,4 TiB (700 GiB * 2).
    • Přidejte vyrovnávací prostor pro režii, růst a provozní požadavky.
    • Možná budete chtít začít s úložištěm 1 TiB ještě dnes a po zvětšení velikosti až 800 GiB ho můžete škálovat na 2 TiB.

Rozhodování o velikosti úložiště zahrnuje kombinaci odhadu aktuálních a budoucích potřeb dat, zvažování indexování a komprese a zajištění odpovídajícího výkonu a škálovatelnosti. Pravidelné monitorování a úpravy založené na skutečném využití a trendech růstu jsou také zásadní pro zachování optimálního výkonu MongoDB.

Co je výpočetní kapacita s možností zvýšení výkonu?

Škálovatelná úroveň nabízí inteligentně přizpůsobené řešení pro malé databázové úlohy. Díky zajištění minimálního výkonu procesoru během nečinných období optimalizují tyto clustery využití prostředků. Skutečná brilantnost ale spočívá v jejich schopnosti bezproblémově vertikálně navýšit kapacitu na plný výkon procesoru v reakci na zvýšené požadavky na provoz nebo úlohy. Tato přizpůsobitelnost poskytuje špičkový výkon přesně v případě potřeby a zároveň přináší značné úspory nákladů.

Snížením počáteční cenové úrovně služby vrstva Burstable Cluster Azure DocumentDB usiluje o usnadnění onboardingu uživatelů a zkoumání Azure DocumentDB za snížené ceny. Tato demokratizace přístupu umožňuje firmám všech velikostí využívat sílu Azure DocumentDB bez narušení banky. Ať už jste startup, malá firma nebo podnik, otevře tato úroveň nové možnosti nákladově efektivní škálovatelnosti.

Zřizování vrstvy s možností nárazového škálování je stejně jednoduché jako zřizování pravidelných vrstev; v možnosti vrstvy clusteru stačí zvolit M10, M20 nebo M25. Tady je úvodní příručka, která nabízí podrobné pokyny k nastavení clusteru Azure DocumentDB.