Důležité informace o datových platformách pro klíčové úlohy v Azure

Výběr efektivní aplikační datové platformy je další zásadní rozhodovací oblast, která má dalekosáhlý dopad na jiné oblasti návrhu. Azure nakonec nabízí celou řadu relačních, nerelačních a analytických datových platforem, které se výrazně liší v možnostech. Proto je nezbytné, aby se klíčové požadavky na nefunkčnost plně zvážily spolu s dalšími rozhodovacími faktory, jako je konzistence, funkčnost, náklady a složitost. Například schopnost pracovat v konfiguraci zápisu do více oblastí bude mít zásadní vliv na vhodnosti pro globálně dostupnou platformu.

Tato oblast návrhu rozšiřuje návrh aplikace a poskytuje klíčové aspekty a doporučení k informování o výběru optimální datové platformy.

Důležité

Tento článek je součástí řady důležitých úloh Azure Well-Architected . Pokud tuto řadu neznáte, doporučujeme začít tím, co je kritická úloha?

Kritéria výběru datové platformy

Před výběrem datových technologií vyhodnoťte požadavky na data napříč kapacitou, propustností, datovým modelem, konzistencí a zásadami správného řízení.

Aspekty návrhu

Kapacita a růst

  • Existující (pokud existuje) a očekávané budoucí objemy dat založené na předpokládaných mírách růstu dat v souladu s obchodními cíli a plány.

    • Objem dat by měl zahrnovat samotná data a indexy, protokoly, telemetrii a další použitelné datové sady.
    • Velké podnikové a klíčové aplikace obvykle generují a ukládají velké objemy (GB a TB) každý den.
    • Rozšíření dat může mít významný dopad na náklady.

  • Objem dat může kolísat kvůli měnícím se obchodním okolnostem nebo postupům úklidu.

  • Objem dat může mít hluboký dopad na výkon dotazů datové platformy.

  • S dosažením limitů objemu datových platforem může dojít k hlubokému dopadu.

    • Bude to mít za následek výpadek? a pokud ano, jak dlouho?
    • Jaké jsou postupy pro zmírnění rizik? a bude omezení rizik vyžadovat změny aplikace?
    • Hrozí riziko ztráty dat?

  • Funkce, jako je TTL (Time to Live), je možné použít ke správě růstu dat automatickým odstraněním záznamů po uplynulé době pomocí vytvoření nebo úpravy záznamu.

    • Například Azure Cosmos DB poskytuje integrovanou funkci TTL.

Propustnost a latence

  • Rychlost, s jakou se data vygenerují z různých komponent aplikace, a požadavky na propustnost pro to, jak rychlá data je potřeba potvrdit a načíst, jsou nezbytné k určení optimální datové technologie pro klíčové scénáře úloh.

    • Povaha požadavků na propustnost se bude lišit podle scénáře úloh, například těch, které jsou náročné na čtení nebo zápis.
      • Analytické úlohy například obvykle potřebují zajistit velkou propustnost čtení.
    • Jaká je požadovaná propustnost? A jak se očekává růst propustnosti?
    • Jaké jsou požadavky na latenci dat v P50/P99 v referenčních úrovních zatížení?

  • Pro dosažení vysoké propustnosti jsou důležité možnosti, jako je podpora návrhu bez uzamčení, ladění indexů a zásad konzistence.

    • Optimalizace konfigurace pro vysokou propustnost způsobuje kompromisy, které by měly být plně srozumitelné.
    • K další optimalizaci propustnosti je možné použít vzorce trvalosti zatížení a zasílání zpráv, jako jsou CQRS a Event Sourcing.

  • Úrovně zatížení budou přirozeně kolísat pro mnoho scénářů aplikací, přičemž přirozené špičky vyžadují dostatečný stupeň elasticity pro zvládnutí proměnlivé poptávky při zachování propustnosti a latence.

    • Agilní škálovatelnost je klíčem k efektivní podpoře proměnlivé propustnosti a úrovní zatížení bez nadměrného zřízení úrovní kapacity.
      • Propustnost čtení i zápisu se musí škálovat podle požadavků aplikace a zatížení.
      • Operace vertikálního i horizontálního škálování je možné použít k reakci na měnící se úrovně zatížení.

  • Dopad poklesů propustnosti se může lišit v závislosti na scénáři úloh.

    • Dojde k přerušení připojení?
    • Vrátí jednotlivé operace kódy selhání, zatímco řídicí rovina pokračuje v provozu?
    • Aktivuje datová platforma omezování, a pokud ano, jak dlouho?

  • Základní doporučení návrhu aplikace k použití geografické distribuce aktivní-aktivní představuje problémy související s konzistencí dat.

    • Existuje kompromis mezi konzistencí a výkonem v souvislosti s plnou sémantikou transakcí ACID a tradičním uzamykacím chováním.
      • Minimalizace latence zápisu bude mít náklady na konzistenci dat.

  • V konfiguraci zápisu do více oblastí je třeba synchronizovat a sloučit změny mezi všemi replikami včetně řešení konfliktů tam, kde je to nutné, a to může ovlivnit úrovně výkonu a škálovatelnost.

  • Repliky pouze pro čtení (uvnitř oblasti a mezi oblastmi) se dají použít k minimalizaci latence a rozložení provozu za účelem zvýšení výkonu, propustnosti, dostupnosti a škálovatelnosti.

  • Vrstvu ukládání do mezipaměti lze použít ke zvýšení propustnosti čtení, aby se zlepšilo uživatelské prostředí a doba odezvy koncového klienta.

    • Aby bylo možné optimalizovat aktuálnost dat, je potřeba zvážit dobu vypršení platnosti mezipaměti a zásady.

Datový model a tvar dotazu

  • Datový model, datové typy, relace dat a zamýšlený dotazovací model silně ovlivní rozhodování o datových platformách.

    • Vyžaduje aplikace relační datový model, nebo může podporovat schéma proměnných nebo nerelační datový model?
    • Jak bude aplikace dotazovat data? A budou dotazy záviset na konceptech databázové vrstvy, jako jsou relační spojení? Nebo aplikace poskytuje takovou sémantiku?

  • Povaha datových sad považovaných aplikací se může lišit od nestrukturovaného obsahu, jako jsou obrázky a videa, nebo strukturovanější soubory, jako jsou CSV a Parquet.

    • Složené aplikační úlohy obvykle mají odlišné datové sady a přidružené požadavky.

  • Kromě relačních nebo nerelačních datových platforem, grafových nebo datových platforem klíč-hodnota mohou být také vhodné pro určité datové úlohy.

    • Některé technologie zajišťují datové modely s proměnným schématem, kde jsou datové položky sémanticky podobné a/nebo uložené a dotazované společně, ale liší se strukturálně.

  • V architektuře mikroslužeb je možné jednotlivé aplikační služby sestavit s různými úložišti dat optimalizovanými pro scénáře, nikoli v závislosti na jednom monolitickém úložišti dat.

    • Vzory návrhu, jako je SAGA , je možné použít ke správě konzistence a závislostí mezi různými úložišti dat.
      • Přímé dotazy mezi databázemi můžou mít omezení pro spoluumístění.
    • Použití více datových technologií zvýší režijní náklady na správu pro udržení kompatibility technologií.

  • Sady funkcí pro každou službu Azure se liší v různých jazycích, sadách SDK a rozhraních API, což může výrazně ovlivnit úroveň ladění konfigurace, kterou je možné použít.

  • Možnosti optimalizovaného sladění s datovým modelem a zahrnujícími datovými typy budou výrazně ovlivnit rozhodování o datových platformách.

    • Vrstvy dotazů, jako jsou uložené procedury a mapovače relačních objektů.
    • Funkce dotazů neutrálních pro jazyk, jako je zabezpečená vrstva rozhraní REST API.
    • Možnosti provozní kontinuity, jako je zálohování a obnovení.

  • Úložiště analytických dat obvykle podporují polyglotové úložiště pro různé typy datových struktur.

    • Analytická runtime prostředí, jako je Apache Spark, můžou mít omezení při integraci pro analýzu polyglotních datových struktur.

  • V podnikovém kontextu může použití stávajících procesů a nástrojů a kontinuity dovedností mít významný vliv na návrh datové platformy a výběr datových technologií.

Konzistence a zásady správného řízení

  • K ověření přesnosti dat v aplikaci je potřeba zvážit několik faktorů a správa těchto faktorů může mít významný vliv na návrh datové platformy.

    • Konzistence dat
    • Funkce zabezpečení platformy
    • Zásady správného řízení dat
    • Vývoj správy změn a schématu
    • Závislosti mezi datovými sadami

  • V každé distribuované aplikaci s více replikami dat existuje kompromis mezi konzistencí a latencí, jak je vyjádřeno v teorémech CAP a PACELC .

    • Pokud jsou čtenáři a zapisovači odlišně distribuováni, musí se aplikace rozhodnout, zda vrátí buď nejrychlejší dostupnou verzi datové položky, i když je zastaralá ve srovnání s právě dokončeným zápisem této datové položky v jiné replice, nebo nejaktuálnější verzi datové položky, což může zahrnovat dodatečnou latenci k určení a získání nejnovějšího stavu.
    • Konzistenci a dostupnost je možné nakonfigurovat na úrovni platformy nebo na úrovni jednotlivých požadavků na data.
    • Jaká je uživatelská zkušenost, pokud by byla data poskytována z repliky, která je nejblíže uživateli, ale neodráží nejnovější stav jiné repliky? Tj. může aplikace podporovat poskytování zastaralých dat?

  • V kontextu zápisu do více oblastí se při změně stejné datové položky ve dvou samostatných replikách zápisu před replikací obou změn vytvoří konflikt, který se musí vyřešit.

    • Mohou být použity standardizované zásady řešení konfliktů, jako například "Poslední zápis vyhrává", nebo vlastní strategie s vlastní logikou.

  • Implementace požadavků na zabezpečení může nepříznivě ovlivnit propustnost nebo výkon.

  • Šifrování dat v klidu lze implementovat v aplikační vrstvě pomocí šifrování na straně klienta a/nebo v datové vrstvě pomocí šifrování na straně serveru, pokud je to nutné.

  • Azure podporuje různé modely šifrování, včetně šifrování na straně serveru, které používá klíče spravované službou, klíče spravované zákazníkem ve službě Key Vault nebo klíče spravované zákazníkem na hardwaru řízeném zákazníkem.

    • Pomocí šifrování na straně klienta je možné klíče spravovat ve službě Key Vault nebo v jiném zabezpečeném umístění.

  • Šifrování datových propojení MACsec (IEEE 802.1AE MAC) slouží k zabezpečení veškerého provozu mezi datacentry Azure v páteřní síti Microsoftu.

    • Pakety se před odesláním zašifrují a dešifrují na zařízeních, což brání fyzickým útokům typu man-in-the-middle nebo odposlechu/zachycování komunikace.

  • Ověřování a autorizace roviny dat a řídicí roviny

    • Jak bude datová platforma ověřovat a autorizovat přístup k aplikacím a provozní přístup?

  • Pozorovatelnost prostřednictvím monitorování stavu platformy a přístupu k datům

    • Jak se použijí výstrahy pro podmínky mimo přijatelné provozní hranice?

Doporučení k návrhu

Kapacita a růst

  • Zajistěte, aby budoucí objemy dat spojené s organickým růstem nepřekročily možnosti datové platformy.

    • Prognózovat míry růstu dat v souladu s obchodními plány a používat stanovené sazby k informování průběžných požadavků na kapacitu.
    • Porovnejte agregované a datové svazky záznamů s limity datových platforem.
    • Pokud dojde k riziku dosažení limitů za výjimečných okolností, zajistěte, aby se zabránilo výpadkům a ztrátě dat.

  • Monitorujte objem dat a ověřte ho u modelu kapacity s ohledem na limity škálování a očekávané míry růstu dat.

    • Zajistěte, aby operace škálování odpovídaly požadavkům na úložiště, výkon a konzistenci.
    • Při zavedení nové jednotky škálování může být nutné replikovat podkladová data, která budou chvíli trvat a pravděpodobně zavedou snížení výkonu při replikaci. Proto zajistěte, aby se tyto operace prováděly mimo kritickou pracovní dobu, pokud je to možné.

  • Definujte datové vrstvy aplikace pro klasifikaci datových sad na základě využití a důležitosti, aby se usnadnilo odebrání nebo snižování zátěže starších dat.

    • Zvažte klasifikaci datových sad do horké, teplé a studené úrovně (archiv).
      • Například základní referenční implementace používají Azure Cosmos DB k ukládání "horkých" dat, která aplikace aktivně používá, zatímco Azure Blob Storage se používá pro "studená" provozní data pro analytické účely.

  • Nakonfigurujte postupy údržby pro optimalizaci růstu dat a zajištění efektivního využití dat, jako je výkon dotazů a správa rozšiřování dat.

    • Nakonfigurujte vypršení platnosti hodnoty TTL (Time-To-Live) pro data, která se už nevyžadují a nemají dlouhodobou analytickou hodnotu.
      • Ověřte, že stará data je možné bezpečně vrstvit do sekundárního úložiště nebo je přímo odstranit, aniž by to mělo nepříznivý dopad na aplikaci.
    • Přesměrujte nekritické data do sekundárního studeného úložiště, ale udržujte je pro analytickou hodnotu a pro splnění požadavků na audit.
    • Shromažďujte telemetrická data platformy a statistiky využití, aby týmy DevOps mohly průběžně vyhodnocovat požadavky na údržbu systému a optimalizovat kapacitu úložišť dat.

  • V souladu s návrhem aplikace mikroslužeb zvažte paralelní použití více různých datových technologií s optimalizovanými datovými řešeními pro konkrétní scénáře úloh a požadavky na objem.

    • Vyhněte se vytváření jednoho monolitického úložiště dat, ve kterém je obtížné spravovat objem dat z rozšíření.

Propustnost a latence

  • Datová platforma musí být ze své podstaty navržená a nakonfigurovaná tak, aby podporovala vysokou propustnost a úlohy oddělené do různých kontextů, aby se maximalizoval výkon s využitím řešení optimalizovaných pro scénáře.

    • Ujistěte se, že propustnost čtení a zápisu pro každý scénář dat může být škálovat podle očekávaných vzorců zatížení s dostatečnou odolností pro neočekávanou odchylku.
    • Různé datové úlohy, jako jsou transakční a analytické operace, oddělte do různých kontextů výkonu.

  • Vyrovnávejte zatížení pomocí asynchronního neblokujícího zasílání zpráv, například s využitím vzorů CQRS nebo Event Sourcing a služeb Azure Service Bus nebo Azure Event Hubs.

    • Mezi požadavky na zápis a dostupností nových dat pro čtení může docházet k latenci, což může mít vliv na uživatelské prostředí.
      • Tento dopad musí být srozumitelný a přijatelný v kontextu klíčových obchodních požadavků.

  • Zajištění agilní škálovatelnosti pro podporu proměnlivé propustnosti a úrovní zatížení

    • Pokud jsou úrovně zatížení vysoce nestálé, zvažte nadměrné zřízení úrovní kapacity, abyste zajistili zachování propustnosti a výkonu.
    • Otestujte a ověřte dopad na složené aplikační úlohy, když nejde zachovat propustnost.

  • Určete prioritu datových služeb nativních pro Azure pomocí automatizovaných operací škálování, abyste usnadnili rychlou reakci na nestálost na úrovni zatížení.

    • Nakonfigurujte automatické škálování na základě prahových hodnot interní služby a sady aplikací.
    • Škálování by se mělo zahájit a dokončit v časových rámcích v souladu s obchodními požadavky.
    • V situacích, kdy je nutná ruční interakce, vytvořte automatizované provozní playbooky, které je možné aktivovat místo provádění ručních provozních akcí.
      • Zvažte, jestli je možné automatizované triggery použít jako součást následných technických investic.

  • Monitorujte propustnost čtení a zápisu dat aplikací s požadavky na latenci P50/P99 a přirovnejte se k modelu kapacity aplikace.

  • Nadbytečná propustnost by měla být řádně zpracována datová platformou nebo aplikační vrstvou a zachycena modelem stavu pro provozní reprezentaci.

  • Implementujte ukládání do mezipaměti pro scénáře horkých dat, abyste minimalizovali dobu odezvy.

    • Použijte vhodné zásady pro vypršení platnosti mezipaměti a úklid, abyste se vyhnuli nárůstu dat.
      • Vypršení platnosti položek mezipaměti při změně zálohovajících dat
      • Pokud je vypršení platnosti mezipaměti výhradně založené na hodnotě TTL (Time-To-Live), je potřeba pochopit dopad a zkušenosti zákazníků při poskytování zastaralých dat.

Datový model a tvar dotazu

  • V souladu s principem cloudového a nativního návrhu Azure se důrazně doporučuje určit prioritu spravovaných služeb Azure, aby se snížila složitost provozu a správy a využila výhod budoucích investic do platformy Microsoftu.

  • V souladu s principem návrhu aplikací volně propojených architektur mikroslužeb umožňují jednotlivým službám používat různá úložiště dat a technologie optimalizované pro scénáře.

    • Identifikujte typy datových struktur, které bude aplikace zpracovávat pro konkrétní scénáře úloh.
    • Vyhněte se vytváření závislosti na jednom monolitickém úložišti dat.
      • Představte si vzor návrhu SAGA , ve kterém existují závislosti mezi úložišti dat.

  • Ověřte, že jsou pro vybrané datové technologie k dispozici požadované funkce.

    • Zajistěte podporu požadovaných jazyků a funkcí sady SDK. Ne všechny funkce jsou k dispozici pro každý jazyk nebo sadu SDK stejným způsobem.

Konzistence a zásady správného řízení

  • Přijměte návrh datové platformy s více oblastmi, který podporuje přístup k aktivnímu/aktivnímu nasazení úlohy. Podrobnosti najdete v tématu Globální distribuce.

    • Distribuce replik dat mezi zóny dostupnosti (AZ) v rámci oblasti (nebo použití zónově redundantních úrovní služby) k maximalizaci dostupnosti uvnitř oblasti.

  • Pokud to požadavky na konzistenci umožňují, použijte návrh datové platformy pro zápis do více oblastí, abyste maximalizovali celkovou globální dostupnost a spolehlivost.

    • Zvažte obchodní požadavky pro řešení konfliktů, když dojde ke změně stejné datové položky ve dvou samostatných replikách zápisu dříve, než může být některá ze změn replikována, čímž dojde ke vzniku konfliktu.
      • Pokud je to možné, použijte standardizované zásady řešení konfliktů, jako je například "Poslední vyhrává".
        • Pokud se vyžaduje vlastní strategie s vlastní logikou, ujistěte se, že se pro správu vlastní logiky použijí postupy CI/CD DevOps.

  • Otestujte a ověřte funkčnost zálohování a obnovení a operace převzetí služeb při chybě prostřednictvím testování chaosu v rámci procesů kontinuálního doručování.

  • Spusťte srovnávací testy výkonu, abyste zajistili, že požadavky na propustnost a výkon nebudou ovlivněny zahrnutím požadovaných možností zabezpečení, jako je šifrování.

    • Zajistěte, aby procesy průběžného doručování zvážily zátěžové testování proti známým srovnávacím testům výkonu.

  • Preferujete šifrovací klíče spravované službou, pokud nejsou potřeba klíče spravované zákazníkem. Podrobnosti najdete v tématu Ochrana integrity dat.

Poznámka:

Při integraci s širší organizační implementací je důležité, aby se při zřizování a provozu komponent datové platformy v návrhu aplikace použil přístup orientovaný na aplikaci.

Přesněji řečeno, aby se maximalizovala spolehlivost, je důležité, aby jednotlivé komponenty datové platformy správně reagovaly na stav aplikace prostřednictvím provozních akcí, které mohou zahrnovat další součásti aplikace. Například ve scénáři, ve kterém jsou potřeba další prostředky datové platformy, bude pravděpodobně potřeba škálovat datovou platformu spolu s dalšími komponentami aplikace podle modelu kapacity, a to potenciálně prostřednictvím zřízení dalších jednotek škálování. Tento přístup bude nakonec omezen, pokud by došlo k výrazné závislosti centralizovaného provozního týmu na řešení problémů souvisejících s platformou pro data odděleně.

Použití centralizovaných datových služeb (tedy centralizovaného IT DBaaS) může vytvářet provozní úzká místa a v prostředí kritickém z hlediska provozu nebo podnikání je třeba se mu vyhnout.

Další odkazy

Další doprovodné materiály k datovým platformám jsou k dispozici v průvodci architekturou aplikací Azure.

Globálně distribuované datové úložiště s možností zápisu do více regionů

Pokud chcete plně přizpůsobit globálně distribuovanou aktivní-aktivní architekturu návrhu aplikace, důrazně doporučujeme zvážit distribuovanou datovou platformu pro zápis do více regionů, kde se změny samostatných zapisovatelných kopií synchronizují a slučují mezi všemi replikami, s řešením konfliktů podle potřeby.

Důležité

Mikroslužby nemusí všechny vyžadovat distribuované úložiště dat zápisu do více oblastí, proto je potřeba vzít v úvahu kontext architektury a obchodní požadavky jednotlivých scénářů úloh.

Azure Cosmos DB poskytuje globálně distribuované a vysoce dostupné úložiště dat NoSQL, které nabízí zápisy ve více regionech a nastavitelné konzistence. Aspekty návrhu a doporučení v této části se proto zaměří na optimální využití služby Azure Cosmos DB.

Aspekty návrhu

Azure Cosmos DB

Azure Cosmos DB je doporučeným primárním úložištěm dat pro klíčové úlohy, které vyžadují globálně distribuovanou datovou platformu pro zápis do více oblastí. Poskytuje víceregionální zápisy a nastavitelnou konzistenci ihned po nasazení, SLA na 99,999% dostupnost čtení i zápisu při konfiguraci s několika zapisovatelnými oblastmi, automatické převzetí služeb při selhání a redundanci zón dostupnosti. Tyto funkce přímo podporují model aktivního/aktivního nasazení, který vyžadují klíčové úlohy. Kompletní sadu funkcí, pokyny ke konfiguraci a osvědčené postupy najdete v příručce ke službě Cosmos DB.

Klíčové důležité aspekty:

  • Konfigurace zápisu do více oblastí je spojena se značnými náklady, protože RU/s se zřizují a účtují pro každou oblast. Dvě oblasti pro zápis stojí 2x, tři stojí 3x a tak dále. Upřednostnit zápisy do více oblastí pouze pro scénáře úloh, které vyžadují maximální spolehlivost.
  • V konfiguraci zápisu do více oblastí může dojít ke konfliktům aktualizací . Azure Cosmos DB poskytuje zásady řešení konfliktů Poslední zápis má přednost (výchozí) a vlastní zásady řešení konfliktů.
  • Při dosažení optimálního výkonu a dostupnosti hraje zásadní roli datový model a strategie dělení napříč logickými a fyzickými oddíly.
  • Automaticky škálovaná propustnost chrání před chybami způsobenými omezením propustnosti tím, že se škáluje automaticky, což je důležité pro nepředvídatelné úlohy kritické pro chod systému.
  • Režim průběžného zálohování umožňuje samoobslužné obnovení k určitému bodu v čase (PITR) s jednosekundovou členitostí a uchováváním až 30 dnů, což je upřednostňované před pravidelnými zálohami pro kritické scénáře.

Doporučení k návrhu

Azure Cosmos DB

  • Azure Cosmos DB použijte jako primární datovou platformu, kde to požadavky umožňují.

  • Pro klíčové scénáře úloh nakonfigurujte službu Azure Cosmos DB s replikou zápisu v každé oblasti nasazení, abyste snížili latenci a zajistili maximální redundanci.

    • Nakonfigurujte aplikaci tak, aby upřednostňovala použití místní repliky služby Azure Cosmos DB pro zápisy a čtení, aby optimalizovala zatížení, výkon a spotřebu ru/s v jednotlivých oblastech.
    • Konfigurace zápisu do více oblastí má značné náklady a měla by být určena pouze pro scénáře úloh vyžadujících maximální spolehlivost.

  • U méně důležitých scénářů úloh upřednostňujte použití konfigurace zápisu s jednou oblastí (při použití Zóny dostupnosti) s globálně distribuovanými replikami pro čtení.

    • Nakonfigurujte aplikaci tak, aby používala místní repliku čtení služby Azure Cosmos DB k optimalizaci výkonu čtení.

  • Vyberte optimální oblast nasazení 'hubu', kde bude probíhat řešení konfliktů v konfiguraci zápisu do více regionů a všechny zápisy se budou provádět v konfiguraci zápisu do jednoho regionu.

    • Zvažte vzdálenost vzhledem k ostatním oblastem nasazení a související latenci při výběru primární oblasti a požadovaných funkcí, jako je podpora zón dostupnosti.

  • Nakonfigurujte službu Azure Cosmos DB s redundancí zóny dostupnosti (AZ) ve všech oblastech nasazení s podporou AZ, abyste zajistili odolnost proti selháním zón v rámci oblasti.

SLA služby Azure Cosmos DB se počítá průměrem neúspěšných požadavků, které nemusí přímo odpovídat rozpočtu pro chybovou rezervu u 99,999% úrovně spolehlivosti. Při návrhu na 99,999% SLO je proto důležité naplánovat regionální a multiregionální nedostupnost zápisu do služby Azure Cosmos DB a zajistit umístění náhradní technologie úložiště v případě selhání, jako je například trvalá fronta zpráv pro následné přehrání.

Technologie relačních dat

V případě scénářů s vysoce relačním datovým modelem nebo závislostmi na existujících relačních technologiích nemusí být použití služby Azure Cosmos DB v konfiguraci zápisu do více oblastí přímo použitelné. V takových případech je důležité, aby použité relační technologie byly navrženy a nakonfigurovány tak, aby podporovaly multi-regionální aktivní-aktivní cíle návrhu aplikace.

Klíčové úlohy využívají polyglotní trvalost: používejte nejlepší úložiště dat pro každý scénář úloh místo vynucení všech dat prostřednictvím jediné technologie. Azure Cosmos DB zpracovává globálně distribuované zápisy, zatímco relační databáze, jako jsou Azure SQL Database a Azure Database for PostgreSQL, obsluhují scénáře se silnými relačními modely, složitými transakcemi nebo regulačními omezeními, které vyžadují záruky ACID.

Podrobné pokyny ke konfiguraci Azure SQL Database najdete v průvodci službou SQL Database.

Podrobné pokyny ke konfiguraci Azure Database for PostgreSQL najdete v průvodci službou Database for PostgreSQL.

Aspekty návrhu

  • Technologie relačních dat mohou snadno škálovat operace čtení, ale zápisy jsou obvykle omezené na jednu primární instanci, která omezuje škálovatelnost a výkon pro globálně distribuované úlohy.

  • Sharding umožňuje distribuovat data a zpracování do více databází a obejít omezení platformy. To platí zejména v případě, že návrh aplikace bere v úvahu tři nebo více Azure oblastí.

  • Azure SQL Database poskytuje skupiny pro automatické převzetí služeb při selhání, geografickou replikaci až do čtyř oblastí, redundanci v zónách dostupnosti a SLA na úrovni 99,995 % v úrovních Business Critical. Díky těmto možnostem jsou vhodné pro klíčové scénáře, ve kterých existují relační požadavky. Kompletní možnosti najdete v průvodci službou SQL Database.

  • Azure Database for PostgreSQL Flexible Server s Elastic Clusters (Citus) poskytuje dynamickou škálovatelnost pomocí shardingu. Pro kriticky důležité úlohy, které vyžadují podporu zón dostupnosti a garanci SLA na úrovni 99,95 %, používejte Flexible Server. Kompletní možnosti najdete v průvodci službou Database for PostgreSQL.

Doporučení k návrhu

  • Zvažte horizontální dělení relačních databází na základě různých kontextů aplikací a dat, což pomáhá při navigaci v omezeních platformy, maximalizaci škálovatelnosti a dostupnosti a izolaci chyb.

    • Horizontální dělení není vhodné pro všechny scénáře aplikace, takže se vyžaduje kontextové vyhodnocení.

  • Určete prioritu použití služby Azure SQL Database, kde existují relační požadavky z důvodu vyspělosti platformy Azure a široké škály možností spolehlivosti.

  • Pomocí skupin automatického převzetí služeb při selhání můžete zajistit transparentní převzetí služeb při selhání do sekundární oblasti. Zvažte automatizované provozní spouštěče založené na upozorněních sladěných s modelem stavu aplikace, které spustí převzetí služeb při selhání, pokud výpadek ovlivní primární i sekundární instanci.

Důležité

U aplikací, které počítají s nasazením ve více než čtyřech oblastech, je třeba vážně zvážit sharding v rámci aplikace nebo refaktoring aplikace tak, aby podporovala technologie pro zápis do více oblastí, jako je Azure Cosmos DB.

Ukládání do mezipaměti pro data prioritní vrstvy

Vrstvu ukládání do mezipaměti v paměti je možné použít k vylepšení datové platformy tím, že výrazně zvyšuje propustnost čtení a zlepšuje dobu odezvy koncového klienta pro scénáře dat horké vrstvy.

Azure poskytuje několik služeb s příslušnými možnostmi pro ukládání datových struktur klíčů do mezipaměti. Tato část se zaměřuje na scénáře, ve kterých je vyžadován další výkon čtení a stálost přístupu k datům.

Aspekty návrhu

  • Vrstva ukládání do mezipaměti poskytuje další odolnost přístupu k datům, protože i v případě výpadku, který má vliv na základní datové technologie, může být snímek dat aplikace stále přístupný prostřednictvím vrstvy ukládání do mezipaměti.

  • Vrstva mezipaměti ale také představuje další bod selhání pro kritické pracovní zátěže. Vyhodnoťte, jestli výhoda výkonu čtení převáží nad přidanou provozní složitostí a plochou selhání.

  • V některých scénářích úloh je možné ukládání do mezipaměti v paměti implementovat v rámci samotné aplikační platformy.

Azure Managed Redis a Azure Cache for Redis

  • Azure Cache for Redis se vyřazuje. Pro nové návrhy použijte Azure Managed Redis.

  • S geografickou replikací se budou účtovat poplatky za přenos dat mezi oblastmi také kromě přímých nákladů spojených s instancemi mezipaměti.

Doporučení k návrhu

  • Zvažte optimalizovanou vrstvu ukládání do mezipaměti pro scénáře horkého dat, abyste zvýšili propustnost čtení a zlepšili dobu odezvy.

  • Použijte vhodné zásady pro vypršení platnosti mezipaměti a úklid, abyste se vyhnuli nárůstu dat.

    • Při změně záložních dat zvažte vypršení platnosti položek mezipaměti.

Azure Managed Redis a Azure Cache for Redis

  • Pro nová nasazení mezipaměti použijte Azure Managed Redis.

  • U existujících Azure Cache for Redis instancí postupujte podle pokynů pro vyřazení.

  • Nasaďte instance replik pomocí geografické replikace v aktivní konfiguraci napříč všemi oblastmi nasazení.

  • Zajistěte, aby se instance repliky nasazovaly napříč zónami dostupnosti v rámci každé oblasti Azure.

  • K vyhodnocení instancí mezipaměti použijte Azure Monitor.

    • Vypočítejte skóre stavu komponent místní mezipaměti, abyste mohli sledovat stav vzhledem k obchodním požadavkům a využití prostředků.
    • Sledujte klíčové metriky, jako jsou vysoké využití procesoru, vysoké využití paměti, vysoké zatížení serveru a vyřazené klíče pro přehledy o škálování mezipaměti.

Analytické scénáře

Pro klíčové aplikace je stále častější uvažovat o analytických scénářích jako o způsob, jak podpořit další hodnotu z zahrnujících toků dat. Analytické scénáře aplikací a provozu (AIOps) proto tvoří zásadní aspekt vysoce spolehlivé datové platformy.

Analytické a transakční úlohy vyžadují různé možnosti datové platformy a optimalizace pro přijatelný výkon v příslušných kontextech.

Description Analytický Transakční
Případ použití Analýza velmi velkých objemů dat ("velké objemy dat") Zpracování velmi velkých objemů jednotlivých transakcí
Optimalizováno pro Čtení dotazů a agregací v mnoha záznamech Dotazy CRUD (Create/Read/Update/Delete) téměř v reálném čase pro několik záznamů
Klíčové charakteristiky - Konsolidace ze zdrojů dat záznamu
– Úložiště založené na sloupcích
– Distribuované úložiště
-Paralelní zpracování
- Denormalizované
- Nízká souběžnost čtení a zápisů
- Optimalizace pro objem úložiště s kompresí		 – Autoritativní zdroj dat pro aplikaci
– Úložiště založené na řádcích
- Souvislé úložiště
- Symetrické zpracování
-Normalizovaný
- Vysoká souběžnost čtení a zápisů, aktualizace indexů
- Optimalizace pro rychlý přístup k datům pomocí úložiště v paměti

Aktuální pokyny pro Azure Cosmos DB doporučují pro nové analytické projekty zero-ETL místo Synapse Link řešení Azure Cosmos DB Mirroring for Microsoft Fabric.

Aspekty návrhu

  • Tradičně se rozsáhlé analytické scénáře usnadňují extrahováním dat do samostatné datové platformy optimalizované pro následné analytické dotazy.
    • Kanály extrakce, transformace a načítání (ETL) spotřebovávají propustnost a můžou mít vliv na výkon transakčních úloh.
    • Časté spouštění kanálů ETL za účelem snížení propustnosti a vlivu na výkon povede k tomu, že analytická data budou méně aktuální.
    • Při složitějších transformacích dat se zvyšuje režie při vývoji a údržbě kanálů ETL.
      • Pokud jsou například zdrojová data často měněna nebo odstraňována, kanály ETL musí tyto změny v cílových datech zohlednit pro analytické dotazy prostřednictvím doplňkového nebo verzovaného přístupu, výpisu a opětovného načtení, nebo přímých změn v analytických datech. Každý z těchto přístupů bude mít vliv na deriváty, například opětovné vytvoření nebo aktualizaci indexu.

Azure Cosmos DB

  • Analytické dotazy spouštěné na transakčních datech služby Azure Cosmos DB se obvykle agregují napříč oddíly nad velkými objemy dat a spotřebují významnou propustnost jednotky žádostí (RU), což může mít vliv na výkon okolních transakčních úloh.

  • Kanál změn služby Azure Cosmos DB je možné použít také k údržbě samostatného sekundárního úložiště dat pro analytické scénáře.

Doporučení k návrhu

  • Ujistěte se, že analytické úlohy nemají vliv na transakční aplikační úlohy, aby se zachoval transakční výkon.

  • Použijte zrcadlení Azure Cosmos DB pro Microsoft Fabric pro nové analytické projekty bez ETL.

  • Kanál změn Azure Cosmos DB používejte jenom pro jednoduché analytické scénáře.

Další krok

Projděte si úvahy o úvahách ohledně sítí.

Síť a připojení

  • Last updated on