Sdílet prostřednictvím

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

  • Článek

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 úloh, která je důležitá pro architekturu Azure. Pokud tuto řadu neznáte, doporučujeme začít tím , co je kritická úloha?

Čtyři vs. velké objemy dat

"Čtyři Vs of Big Data" poskytují architekturu pro lepší pochopení požadovaných charakteristik pro vysoce dostupnou datovou platformu a způsob použití dat k maximalizaci obchodní hodnoty. V této části se proto dozvíte, jak lze vlastnosti Objem, Rychlost, Rozmanitost a Veracity použít na koncepční úrovni, aby bylo možné navrhnout datovou platformu s využitím vhodných datových technologií.

  • Volume: kolik dat se chystá informovat kapacitu úložiště a požadavky na vrstvení – to je velikost datové sady.
  • Velocity: rychlost zpracování dat, a to buď jako dávky, nebo průběžné proudy – to je rychlost toku.
  • Variety: organizace a formát dat, zachytávání strukturovaných, částečně strukturovaných a nestrukturovaných formátů – to jsou data v různých úložištích nebo typech.
  • Veracity: zahrnuje provenience a souvržení považovaných datových sad pro zásady správného řízení a zajištění kvality dat – to je přesnost dat.

Na co dát pozor při navrhování

Objem

  • 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 integrované funkce TTL .

Rychlost

  • 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, pokud jde o úplné sémantiku transakce ACID a tradiční uzamykání chování.
      • Minimalizace latence zápisu bude mít náklady na konzistenci dat.

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

  • Repliky jen pro čtení (uvnitř oblasti a mezi oblastmi) se dají použít k minimalizaci latence odezvy a distribuci 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.

    • Kvůli optimalizaci nedávné doby platnosti dat je potřeba zvážit dobu vypršení platnosti mezipaměti a zásady.

Odrůda

  • 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 společné umístění.
    • Použití více datových technologií zvýší určitou režii správy, aby se zachovaly zahrnující technologie.

  • 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.

    • Prostředí analytického modulu runtime, jako je Apache Spark, můžou mít omezení integrace pro analýzu datových struktur polyglotu.

  • 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í.

Pravdomluvnost

  • 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 vrátit buď nejrychlejší dostupnou verzi datové položky, i když je zastaralá v porovnání s právě dokončeným zápisem (aktualizací) této datové položky v jiné replice nebo nejaktuálnější verzí datové položky, která může mít další 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é prostředí, pokud se data měla obsluhovat z repliky, která je nejblíže uživateli, který 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.

    • Je možné použít standardizované zásady řešení konfliktů, například "Poslední zápis wins", nebo vlastní strategii s vlastní logikou.

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

  • Šifrování neaktivních uložených dat je možné implementovat v aplikační vrstvě pomocí šifrování na straně klienta nebo datové vrstvy pomocí šifrování na straně serveru v případě potřeby.

  • podpora Azure 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 odpojování nebo odpojování.

  • 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

Objem

  • 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 Storage se používá pro "studená" provozní data pro analytické účely.

  • Nakonfigurujte postupy úklidu pro optimalizaci růstu dat a zajištění efektivity dat, jako je výkon dotazů a správa rozšíření 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.
    • Shromážděte telemetrická data platformy a statistiky využití, abyste týmům DevOps umožnili průběžně vyhodnocovat požadavky na udržování domu a úložiště dat se správnou velikostí.

  • V souladu s návrhem aplikace mikroslužeb zvažte použití více různých datových technologií paralelně 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í.

Rychlost

  • 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.

  • Na úrovni zatížení prostřednictvím asynchronního neblokujícího zasílání zpráv, například pomocí vzorů CQRS nebo Event Sourcing .

    • 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 udržování domu, abyste se vyhnuli růstu průběžných 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.

Odrůda

  • 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.

Pravdomluvnost

  • Přijměte návrh datové platformy pro více oblastí a distribuujte repliky napříč oblastmi, abyste dosáhli maximální spolehlivosti, dostupnosti a výkonu tím, že přesunete data blíže ke koncovým bodům aplikace.

    • 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.

    • Obchodní požadavky pro řešení konfliktů zvažte, když se stejná datová položka změní ve dvou samostatných replikách zápisu před replikací jedné ze změn a vytvořením 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 možnosti zálohování a obnovení a operace převzetí služeb při selhání prostřednictvím testování chaosu v rámci procesů průběžné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.

  • Při použití šifrování se důrazně doporučuje používat šifrovací klíče spravované službou jako způsob, jak snížit složitost správy.

    • Pokud existují specifické požadavky na zabezpečení klíčů spravovaných zákazníkem, ujistěte se, že se použijí příslušné postupy správy klíčů k zajištění dostupnosti, zálohování a obměně všech považovaných klíčů.

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 existuje pevná závislost centralizovaného provozního týmu, aby se vyřešily problémy související s datovou platformou izolovaně.

Použití centralizovaných datových služeb (což je centrální IT DBaaS) v konečném důsledku představuje provozní kritické body, které výrazně brání flexibilitě prostřednictvím z velké části nekontextualizované správy a měly by se vyhnout v klíčovém nebo obchodním kritickém kontextu.

Další odkazy

Další pokyny pro datovou platformu jsou k dispozici v průvodci architekturou Aplikace Azure lication.

Globálně distribuovaný úložiště dat pro zápis do více oblastí

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

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 do více oblastí a odsunutelnou konzistenci. 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 ukládá data v kontejnerech, která jsou indexovaná, transakční úložiště založená na řádcích, která umožňují rychlé transakční čtení a zápisy s dobou odezvy v řádu milisekund.

  • Azure Cosmos DB podporuje více různých rozhraní API s různými sadami funkcí, jako jsou SQL, Cassandra a MongoDB.

    • První strana Azure Cosmos DB for NoSQL poskytuje bohatší sadu funkcí a obvykle je rozhraní API, kde budou nové funkce k dispozici jako první.

  • Azure Cosmos DB podporuje režimy připojení brány a přímého připojení, kde direct usnadňuje připojení přes protokol TCP k back-endovým uzlům repliky služby Azure Cosmos DB pro zajištění lepšího výkonu s menším počtem segmentů směrování sítě, zatímco brána poskytuje připojení HTTPS k uzlům brány front-endu.

    • Přímý režim je k dispozici pouze při použití služby Azure Cosmos DB for NoSQL a je aktuálně podporován pouze na platformách .NET a Java SDK.

  • V oblastech s povolenou zónou dostupnosti nabízí Azure Cosmos DB podporu redundance zóny dostupnosti (AZ) pro zajištění vysoké dostupnosti a odolnosti vůči selháním zón v rámci oblasti.

  • Azure Cosmos DB udržuje čtyři repliky dat v rámci jedné oblasti a když je povolená redundance zóny dostupnosti (AZ), azure Cosmos DB zajišťuje, aby se repliky dat umístily do více zón, aby se chránily před selháním zón.

    • Pro dosažení kvora napříč replikami v rámci oblasti se použije protokol konsensu Paxos.

  • Účet služby Azure Cosmos DB je možné snadno nakonfigurovat tak, aby replikoval data do více oblastí, aby se zmírnit riziko nedostupnosti jedné oblasti.

    • Replikaci je možné nakonfigurovat pomocí zápisů do jedné oblasti nebo zápisů do více oblastí.
      • Při zápisech do jedné oblasti se primární oblast centra používá k poskytování všech zápisů a pokud tato oblast centra přestane být k dispozici, musí dojít k operaci převzetí služeb při selhání, aby bylo možné zvýšit úroveň jiné oblasti jako zapisovatelné.
      • Při zápisech do více oblastí můžou aplikace zapisovat do jakékoli nakonfigurované oblasti nasazení, která bude replikovat změny mezi všemi ostatními oblastmi. Pokud je oblast nedostupná, použijí se zbývající oblasti k poskytování provozu zápisu.

  • V konfiguraci zápisu do více oblastí může dojít ke konfliktům aktualizace (vložení, nahrazení, odstranění), kdy zapisovače současně aktualizují stejnou položku ve více oblastech.

  • Azure Cosmos DB poskytuje dvě zásady řešení konfliktů, které je možné použít k automatickému řešení konfliktů.

    • Poslední zápis wins (LWW) používá protokol hodin synchronizace času pomocí vlastnosti časového razítka _ts definované systémem jako cesta řešení konfliktů. Pokud dojde ke konfliktu položky s nejvyšší hodnotou cesty řešení konfliktů, stane se vítězem a pokud má více položek stejnou číselnou hodnotu, systém vybere vítěze, aby všechny oblasti mohly konvergovat ke stejné verzi potvrzené položky.
      • Při konfliktech odstranění vždy získá odstraněná verze konflikty vložení nebo nahrazení bez ohledu na hodnotu cesty řešení konfliktů.
      • Poslední chyba zápisu wins je výchozí zásada řešení konfliktů.
      • Při použití služby Azure Cosmos DB for NoSQL je možné pro řešení konfliktů použít vlastní číselnou vlastnost, například vlastní definici časového razítka.
    • Vlastní zásady řešení umožňují sémantiku definovanou aplikací odsouhlasit konflikty pomocí registrované uložené procedury hromadné korespondence, která se automaticky vyvolá při zjištění konfliktů.
      • Systém poskytuje přesně jednou záruku pro provádění procesu sloučení v rámci protokolu závazku.
      • Vlastní zásady řešení konfliktů jsou k dispozici pouze se službou Azure Cosmos DB for NoSQL a dají se nastavit pouze při vytváření kontejneru.

  • V konfiguraci zápisu do víceoblastích více oblastí existuje v jedné oblasti Azure Cosmos DB, která je

    • Platforma poskytuje vyrovnávací paměť zpráv pro konflikty zápisu v rámci oblasti centra za účelem načtení a zajištění redundance přechodných chyb.
      • Vyrovnávací paměť dokáže uchovávat několik minut aktualizací zápisu vyžadujících konsensus.

Strategickým směrem platformy Azure Cosmos DB je odebrat tuto závislost jedné oblasti pro řešení konfliktů v konfiguraci zápisu do více oblastí s využitím dvoufázového přístupu Paxos k dosažení kvora na globální úrovni a v rámci oblasti.

  • Primární oblast centra je určená první oblastí, ve které je služba Azure Cosmos DB nakonfigurovaná.

    • Pořadí priorit je nakonfigurováno pro další oblasti satelitního nasazení pro účely převzetí služeb při selhání.

  • Datový model a dělení mezi logické a fyzické oddíly hraje důležitou roli při dosažení optimálního výkonu a dostupnosti.

  • Při nasazení s jednou oblastí zápisu je možné službu Azure Cosmos DB nakonfigurovat pro automatické převzetí služeb při selhání na základě definované priority převzetí služeb při selhání s ohledem na všechny repliky oblasti čtení.

  • Plánovaná doba obnovení poskytovaná platformou Azure Cosmos DB je přibližně 10 až 15 minut a zachytává uplynulý čas provedení regionálního převzetí služeb při selhání služby Azure Cosmos DB v případě katastrofické havárie, která má dopad na oblast centra.

    • Tato plánovaná doba obnovení je relevantní také v kontextu zápisu do více oblastí vzhledem k závislosti na jedné oblasti centra pro řešení konfliktů.
      • Pokud se oblast centra stane nedostupnou, zápisy provedené do jiných oblastí selžou po vyplnění vyrovnávací paměti zprávy, protože řešení konfliktů nebude možné provést, dokud služba převezme služby služby při selhání a nenaváže se nová oblast centra.

Strategickým směrem platformy Azure Cosmos DB je snížit rto na ~5 minut tím, že povolíte převzetí služeb při selhání na úrovni oddílů.

  • Cíle bodu obnovení (RPO) a plánovaná doba obnovení (RTO) jsou konfigurovatelné prostřednictvím úrovní konzistence s kompromisem mezi odolností dat a propustností.

    • Azure Cosmos DB poskytuje minimální rto 0 pro uvolněnou úroveň konzistence s více oblastmi zápisů nebo cíl bodu obnovení 0 pro silnou konzistenci s oblastí s jedním zápisem.

  • Azure Cosmos DB nabízí smlouvu SLA o 99,999% dostupnosti čtení i zápisu pro databázové účty nakonfigurované s více oblastmi Azure jako zapisovatelné.

    • Smlouva SLA je reprezentována procentem měsíční doby provozu, která se vypočítá jako 100 % – průměrná míra chyb.
    • Průměrná míra chyb je definována jako součet chybových sazeb za každou hodinu v měsíci fakturace rozdělený celkovým počtem hodin v měsíci fakturace, kde chybovost je celkový počet neúspěšných požadavků vydělený celkovým počtem požadavků v daném hodinovém intervalu.

  • Azure Cosmos DB nabízí smlouvu SLA o 99,99 % pro propustnost, konzistenci, dostupnost a latenci pro databázové účty vymezené na jednu oblast Azure, když je nakonfigurovaná s některou z pěti úrovní konzistence.

    • Smlouva SLA 99,99 % platí také pro databázové účty, které pokrývají více oblastí Azure nakonfigurovaných s některou ze čtyř uvolněných úrovní konzistence.

  • Ve službě Azure Cosmos DB je možné zřídit dva typy propustnosti, standardní a automatické škálování, které se měří pomocí jednotek žádostí za sekundu (RU/s).

    • Standardní propustnost přiděluje prostředky potřebné k zajištění zadané hodnoty RU/s.
      • Úroveň Standard se účtuje po hodinách za zřízenou propustnost.
    • Automatické škálování definuje maximální hodnotu propustnosti a Azure Cosmos DB automaticky vertikálně navýšit nebo snížit kapacitu v závislosti na zatížení aplikace, mezi maximální hodnotou propustnosti a minimálně 10 % maximální hodnoty propustnosti.
      • Automatické škálování se účtuje po hodinách za maximální spotřebovanou propustnost.

  • Statická zřízená propustnost s proměnlivou úlohou může vést k chybám omezování, které ovlivní vnímanou dostupnost aplikace.

    • Automatické škálování chrání před chybami omezování tím, že službě Azure Cosmos DB umožní vertikálně navýšit kapacitu podle potřeby a současně udržovat ochranu nákladů vertikálním snížením kapacity při snížení zatížení.

  • Když se služba Azure Cosmos DB replikuje napříč několika oblastmi, účtují se zřízené jednotky žádostí (RU) na každou oblast.

  • Mezi konfigurací zápisu mezi více oblastmi a konfigurací zápisu do jedné oblasti existuje významný rozdíl nákladů, což v mnoha případech může znemožnit náklady na více hlavních datových platforem Azure Cosmos DB.

Čtení a zápis v jedné oblasti Zápis do jedné oblasti – čtení duální oblasti Čtení a zápis do duální oblasti
1 RU 2 RU 4 RU

Rozdíl mezi zápisem do jedné oblasti a zápisem do více oblastí je ve skutečnosti menší než poměr 1:2, který se odráží v tabulce výše. Konkrétně platí, že poplatky za přenos dat mezi oblastmi jsou spojené s aktualizacemi zápisu v konfiguraci s jedním zápisem, která se nezachytí v rámci nákladů na RU stejně jako u konfigurace zápisu do více oblastí.

  • Spotřebované úložiště se účtuje jako plochá sazba za celkové množství úložiště (GB) spotřebované k hostování dat a indexů za danou hodinu.

  • Session je výchozí a nejpoužívanější úroveň konzistence, protože data se přijímají ve stejném pořadí jako zápisy.

  • Azure Cosmos DB podporuje ověřování prostřednictvím identity Microsoft Entra nebo klíčů Azure Cosmos DB a tokenů prostředků, které poskytují překrývající se možnosti.

Možnosti přístupu ke službě Azure Cosmos DB

  • Operace správy prostředků je možné zakázat pomocí klíčů nebo tokenů prostředků, aby se omezily klíče a tokeny prostředků pouze na operace s daty, což umožňuje jemně odstupňované řízení přístupu k prostředkům pomocí řízení přístupu na základě role (RBAC) Microsoft Entra.

    • Omezení přístupu k rovině řízení prostřednictvím klíčů nebo tokenů prostředků zakáže operace řídicí roviny pro klienty používající sady SDK služby Azure Cosmos DB, a proto by se měly důkladně vyhodnotit a testovat.
    • Nastavení disableKeyBasedMetadataWriteAccess je možné nakonfigurovat prostřednictvím definic IaC šablon ARM nebo prostřednictvím integrované služby Azure Policy.

  • Podpora Microsoft Entra RBAC ve službě Azure Cosmos DB se vztahuje na operace správy roviny řízení účtů a prostředků.

    • Správci aplikací můžou vytvářet přiřazení rolí pro uživatele, skupiny, instanční objekty nebo spravované identity za účelem udělení nebo zamítnutí přístupu k prostředkům a operacím s prostředky Azure Cosmos DB.
    • Pro přiřazení rolí je k dispozici několik předdefinovaných rolí RBAC a vlastní role RBAC lze použít také k vytvoření konkrétních kombinací oprávnění.
      • Čtenář účtu služby Cosmos DB umožňuje přístup jen pro čtení k prostředku služby Azure Cosmos DB.
      • Přispěvatel účtů DocumentDB umožňuje správu účtů Služby Azure Cosmos DB včetně klíčů a přiřazení rolí, ale neumožňuje přístup k rovině dat.
      • Operátor služby Cosmos DB, který je podobný přispěvateli účtů DocumentDB, ale neposkytuje možnost spravovat klíče nebo přiřazení rolí.

  • Prostředky služby Azure Cosmos DB (účty, databáze a kontejnery) je možné chránit před nesprávnými úpravami nebo odstraněním pomocí zámků prostředků.

    • Zámky prostředků je možné nastavit na úrovni účtu, databáze nebo kontejneru.
    • Zámek prostředku nastavený na prostředek bude zděděný všemi podřízenými prostředky. Například zámek prostředku nastavený na účtu služby Azure Cosmos DB bude dědět všechny databáze a kontejnery v rámci účtu.
    • Zámky prostředků se vztahují pouze na operace řídicí roviny a nebrání operacím roviny dat, jako jsou vytváření, změny nebo odstraňování dat.
    • Pokud přístup k řídicí rovině není omezen disableKeyBasedMetadataWriteAccess, klienti budou moci provádět operace řídicí roviny pomocí klíčů účtu.

  • Kanál změn služby Azure Cosmos DB poskytuje časově uspořádaný kanál změn dat v kontejneru Azure Cosmos DB.

    • Kanál změn zahrnuje pouze operace vložení a aktualizace do zdrojového kontejneru Azure Cosmos DB; nezahrnuje odstranění.

  • Kanál změn lze použít k údržbě samostatného úložiště dat od primárního kontejneru používaného aplikací s průběžnými aktualizacemi cílového úložiště dat předávané kanálem změn ze zdrojového kontejneru.

    • Kanál změn lze použít k naplnění sekundárního úložiště pro další redundanci datové platformy nebo pro následné analytické scénáře.

  • Pokud operace odstranění pravidelně ovlivňují data v rámci zdrojového kontejneru, úložiště, které bude kanál změn předávat, bude nepřesné a neodkazuje na odstraněná data.

    • Vzor obnovitelného odstranění je možné implementovat tak, aby byly do kanálu změn zahrnuty datové záznamy.
      • Místo explicitního odstranění datových záznamů se datové záznamy aktualizují nastavením příznaku (např. IsDeleted) tak, aby označovaly, že položka je považována za odstraněnou.
      • Jakékoli cílové úložiště dat předávané kanálem změn bude muset detekovat a zpracovávat položky s odstraněným příznakem nastaveným na Hodnotu True; místo ukládání obnovitelně odstraněných datových záznamů bude nutné odstranit stávající verzi datového záznamu v cílovém úložišti.
    • Krátký formát TTL (Time To Live) se obvykle používá se vzorem obnovitelného odstranění, aby služba Azure Cosmos DB automaticky odstranila data s vypršenou platností, ale teprve potom, co se projeví v kanálu změn s odstraněným příznakem nastaveným na Hodnotu True.
      • Provede původní záměr odstranění a zároveň rozšíří odstranění prostřednictvím kanálu změn.

  • Azure Cosmos DB je možné nakonfigurovat jako analytické úložiště, které používá formát sloupce pro optimalizované analytické dotazy k řešení problémů složitosti a latence, ke kterým dochází u tradičních kanálů ETL.

  • Azure Cosmos DB automaticky zálohuje data v pravidelných intervalech, aniž by to mělo vliv na výkon nebo dostupnost a bez využití RU/s.

  • Službu Azure Cosmos DB je možné nakonfigurovat podle dvou různých režimů zálohování.

    • Periodický je výchozí režim zálohování pro všechny účty, kde se zálohy provádějí v pravidelných intervalech a data se obnoví vytvořením žádosti s týmem podpory.
      • Výchozí období pravidelného uchovávání záloh je osm hodin a výchozí interval zálohování je čtyři hodiny, což znamená, že ve výchozím nastavení se ukládají jenom nejnovější dvě zálohy.
      • Interval zálohování a doba uchovávání se dají konfigurovat v rámci účtu.
        • Maximální doba uchovávání se prodlužuje na měsíc s minimálním intervalem zálohování o jednu hodinu.
        • K konfiguraci redundance úložiště zálohování se vyžaduje přiřazení role k roli Čtenář účtu služby Azure Cosmos DB.
      • Dvě záložní kopie jsou bez dalších poplatků zahrnuté, ale za další zálohy se účtují další náklady.
      • Ve výchozím nastavení se pravidelné zálohy ukládají v samostatném geograficky redundantním úložišti (GRS), které nejsou přímo přístupné.
      • Provedení operace obnovení vyžaduje žádost o podporu, protože zákazníci nemůžou provést obnovení přímo.
        • Před otevřením lístku podpory by se doba uchovávání záloh měla zvýšit na nejméně sedm dnů do osmi hodin od události ztráty dat.
      • Operace obnovení vytvoří nový účet služby Azure Cosmos DB, ve kterém se obnoví data.
        • Existující účet služby Azure Cosmos DB se nedá použít k obnovení.
        • Ve výchozím nastavení se použije nový pojmenovaný <Azure_Cosmos_account_original_name>-restored<n> účet služby Azure Cosmos DB.
          • Tento název lze upravit, například opětovným použitím existujícího názvu, pokud byl původní účet odstraněn.
      • Pokud je propustnost zřízená na úrovni databáze, zálohování a obnovení proběhne na úrovni databáze.
        • Není možné vybrat podmnožinu kontejnerů k obnovení.
    • Režim průběžného zálohování umožňuje obnovení do libovolného bodu času během posledních 30 dnů.
      • Operace obnovení je možné provést, aby se vrátily k určitému bodu v čase (PITR) s jednou sekundou členitosti.
      • Dostupné okno pro operace obnovení je až 30 dnů.
        • Je také možné obnovit stav vytváření instancí prostředku.
      • Průběžné zálohování probíhá v rámci každé oblasti Azure, ve které existuje účet služby Azure Cosmos DB.
        • Průběžné zálohy se ukládají ve stejné oblasti Azure jako každá replika služby Azure Cosmos DB pomocí místně redundantního úložiště (LRS) nebo zónově redundantního úložiště (ZRS) v oblastech, které podporují Zóny dostupnosti.
      • Samoobslužné obnovení je možné provést pomocí webu Azure Portal nebo artefaktů IaC, jako jsou šablony ARM.
      • Průběžné zálohování má několik omezení .
        • Režim průběžného zálohování není v současné době k dispozici v konfiguraci zápisu do více oblastí.
        • V tuto chvíli je možné pro průběžné zálohování nakonfigurovat jenom službu Azure Cosmos DB for NoSQL a Azure Cosmos DB for MongoDB.
        • Pokud má kontejner nakonfigurovaný hodnotu TTL, obnovená data, která překročila hodnotu TTL, se můžou okamžitě odstranit.
      • Operace obnovení vytvoří nový účet služby Azure Cosmos DB pro obnovení k určitému bodu v čase.
      • Za průběžné zálohování a operace obnovení jsou k dispozici další náklady na úložiště.

  • Existující účty Služby Azure Cosmos DB je možné migrovat z periodického do průběžného provozu, ale ne z průběžného do periodického; migrace je jednosměrná a nevratná.

  • Každá záloha služby Azure Cosmos DB se skládá ze samotných dat a podrobností konfigurace pro zřízenou propustnost, zásady indexování, oblasti nasazení a nastavení hodnoty TTL kontejneru.

    • Zálohy neobsahují nastavení brány firewall, seznamy řízení přístupu k virtuální síti, nastavení privátního koncového bodu, nastavení konzistence (účet se obnoví s konzistencí relace), uložené procedury, triggery, funkce definované uživatelem nebo nastavení více oblastí.
      • Zákazníci zodpovídají za opětovné nasazení možností a nastavení konfigurace. Ty se neobnoví prostřednictvím zálohování služby Azure Cosmos DB.
    • Data analytického úložiště Azure Synapse Link také nejsou zahrnutá do záloh služby Azure Cosmos DB.

  • Pro scénáře, ve kterých nejsou vhodné pravidelné a průběžné přístupy, je možné implementovat vlastní funkci zálohování a obnovení.

    • Vlastní přístup představuje významné náklady a další administrativní režii, které by měly být srozumitelné a pečlivě posouzeny.
      • Běžné scénáře obnovení by měly být modelovány, například poškození nebo odstranění účtu, databáze, kontejneru u datové položky.
      • Měly by být implementovány postupy úklidu, aby se zabránilo rozrůstnutí záloh.
    • Azure Storage nebo alternativní datovou technologii je možné použít, například alternativní kontejner Azure Cosmos DB.
      • Azure Storage a Azure Cosmos DB poskytují nativní integrace se službami Azure, jako jsou Azure Functions a Azure Data Factory.

  • Dokumentace ke službě Azure Cosmos DB označuje dvě potenciální možnosti implementace vlastních záloh.

    • Kanál změn služby Azure Cosmos DB za účelem zápisu dat do samostatného úložného zařízení
      • Funkce Azure nebo ekvivalentní proces aplikace používá procesor kanálu změn k vytvoření vazby k kanálu změn a zpracování položek do úložiště.
    • Průběžné i pravidelné (dávkové) vlastní zálohy je možné implementovat pomocí kanálu změn.
    • Kanál změn služby Azure Cosmos DB zatím neodráží odstranění, takže je potřeba použít vzor obnovitelného odstranění pomocí logické vlastnosti a hodnoty TTL.
      • Tento model nebude potřeba, když kanál změn poskytuje aktualizace s plnou věrností.
    • Konektor Služby Azure Data Factory pro Službu Azure Cosmos DB (konektory rozhraní API služby Azure Cosmos DB for NoSQL nebo MongoDB) pro kopírování dat
      • Azure Data Factory (ADF) podporuje ruční spouštění a plánování, přeskakující okno a triggery založené na událostech.
        • Poskytuje podporu pro Službu Storage i Event Grid.
      • ADF je primárně vhodný pro pravidelné vlastní implementace zálohování kvůli jeho dávkové orchestraci.
        • Je méně vhodná pro implementace průběžného zálohování s častými událostmi kvůli režii na provádění orchestrace.
      • ADF podporuje Azure Private Link pro scénáře s vysokým zabezpečením sítě.

Azure Cosmos DB se používá v rámci návrhu mnoha služeb Azure, takže významný regionální výpadek služby Azure Cosmos DB bude mít kaskádový efekt napříč různými službami Azure v této oblasti. Přesný dopad na konkrétní službu bude silně záviset na tom, jak základní návrh služby využívá Službu Cosmos DB.

Doporučení k návrhu

Azure Cosmos DB

  • Azure Cosmos DB použijte jako primární datovou platformu, kde jsou požadavky povolené.

  • 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í, protože to nabízí vysokou úroveň spolehlivosti datové platformy (99,999% SLA pro čtení, 99,995% SLA pro operace zápisu) v přesvědčivější cenové bodě.

    • 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í centra, ve které dojde k řešení konfliktů v konfiguraci zápisu do více oblastí a všechny zápisy se budou provádět v konfiguraci zápisu do jedné oblasti.

    • 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óny 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í zón v rámci oblasti.

  • Azure Cosmos DB for NoSQL používejte, protože nabízí nejkomplexnější sadu funkcí, zejména pokud jde o ladění výkonu.

    • Alternativní rozhraní API by se měla zvážit hlavně pro scénáře migrace nebo kompatibility.
      • Pokud používáte alternativní rozhraní API, ověřte, že jsou ve vybraném jazyce a sadě SDK k dispozici požadované funkce, abyste zajistili optimální konfiguraci a výkon.

  • Režim přímého připojení slouží k optimalizaci výkonu sítě prostřednictvím přímého připojení TCP k back-endovým uzlům služby Azure Cosmos DB s menším počtem segmentů směrování sítě.

Smlouva 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 na úrovni spolehlivosti 99,999 %. Při návrhu na 99,999% SLO je proto důležité naplánovat regionální a víceregioná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í.

  • Definujte strategii dělení mezi logickými i fyzickými oddíly pro optimalizaci distribuce dat podle datového modelu.

    • Minimalizujte dotazy napříč oddíly.
    • Iterativní testování a ověření strategie dělení za účelem zajištění optimálního výkonu

  • Vyberte optimální klíč oddílu.

    • Klíč oddílu nelze po vytvoření v kolekci změnit.
    • Klíč oddílu by měl být hodnota vlastnosti, která se nemění.
    • Vyberte klíč oddílu s vysokou kardinalitou s širokou škálou možných hodnot.
    • Klíč oddílu by měl rovnoměrně rozdělit spotřebu RU a úložiště dat napříč všemi logickými oddíly, aby se zajistilo rovnoměrné využití RU a distribuce úložiště napříč fyzickými oddíly.
    • Spuštěním dotazů pro čtení v děleném sloupci snižte spotřebu RU a latenci.

  • Indexování je také zásadní pro výkon, takže zajistěte, aby se vyloučení indexů používala ke snížení požadavků na RU/s a úložiště.

    • Indexujte pouze pole potřebná k filtrování v rámci dotazů; indexy návrhu pro nejčastěji používané predikáty.

  • Využijte integrované zpracování chyb, opakování a širší možnosti spolehlivosti sady SDK služby Azure Cosmos DB.

    • Implementujte logiku opakování v rámci sady SDK na klientech.

  • Ke snížení složitosti správy používejte šifrovací klíče spravované službou.

    • Pokud existují specifické požadavky na zabezpečení klíčů spravovaných zákazníkem, ujistěte se, že se použijí příslušné postupy správy klíčů, jako je zálohování a obměně.

  • Zakažte přístup k zápisu metadat založených na klíčích služby Azure Cosmos DB pomocí integrované služby Azure Policy.

  • Povolte azure Monitoru shromažďovat klíčové metriky a diagnostické protokoly, jako je zřízená propustnost (RU/s).

    • Směrujte provozní data služby Azure Monitor do pracovního prostoru služby Log Analytics vyhrazeného pro službu Azure Cosmos DB a dalších globálních prostředků v rámci návrhu aplikace.
    • Pomocí metrik Azure Monitoru určete, jestli jsou vzorce provozu aplikací vhodné pro automatické škálování.

  • Vyhodnoťte vzory provozu aplikací a vyberte optimální možnost pro zřízené typy propustnosti.

    • Zvažte automaticky škálovanou zřízenou propustnost pro automatické vyrovnání požadavků na úlohy.

  • Vyhodnoťte tipy microsoftu pro zvýšení latence a propustnosti pro optimalizaci konfigurace na straně klienta a na straně serveru.

  • Při použití AKS jako výpočetní platformy: Pro úlohy náročné na dotazy vyberte skladovou položku uzlu AKS, která má povolené akcelerované síťové služby, aby se snížila latence a zpoždění procesoru.

  • U nasazení jedné oblasti zápisu důrazně doporučujeme nakonfigurovat službu Azure Cosmos DB pro automatické převzetí služeb při selhání.

  • Na úrovni zatížení prostřednictvím použití asynchronního neblokujícího zasílání zpráv v rámci systémových toků, které zapisují aktualizace do služby Azure Cosmos DB.

  • Nakonfigurujte účet služby Azure Cosmos DB pro průběžné zálohování, abyste získali podrobnou členitost bodů obnovení za posledních 30 dnů.

    • Zvažte použití záloh služby Azure Cosmos DB ve scénářích, ve kterých jsou uložená data nebo účet služby Azure Cosmos DB odstraněný nebo poškozený.
    • Nepoužívejte vlastní přístup k zálohování, pokud to není nezbytně nutné.

  • V rámci standardní přípravy provozu provozní kontinuity se důrazně doporučuje postupy obnovení u neprodukčních prostředků a dat.

  • Definujte artefakty IaC pro opětovné vytvoření nastavení konfigurace a možností obnovení zálohování služby Azure Cosmos DB.

  • Vyhodnoťte a použijte pokyny k řízení standardních hodnot zabezpečení Azure pro zálohování a obnovení služby Azure Cosmos DB.

  • U analytických úloh vyžadujících dostupnost ve více oblastech použijte analytické úložiště Azure Cosmos DB, které používá formát sloupce pro optimalizované analytické dotazy.

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é. Vtakovýchch technologiích je v takových případech důležité, aby byly navrženy a nakonfigurovány tak, aby podporovaly aktivní a aktivní cíle více oblastí.

Azure poskytuje mnoho spravovaných relačních datových platforem, včetně Azure SQL Database a Azure Database pro běžná relační řešení operačního systému, včetně MySQL, PostgreSQL a MariaDB. Aspekty návrhu a doporučení v této části se proto zaměří na optimální využití variant Azure SQL Database a operačního systému Azure Database za účelem maximalizace spolehlivosti a globální dostupnosti.

Aspekty návrhu

  • Zatímco relační datové technologie je možné nakonfigurovat tak, aby snadno škálovaly operace čtení, zápisy jsou obvykle omezené tak, aby procházely jednou primární instancí, což výrazně omezuje škálovatelnost a výkon.

  • Horizontální dělení je možné použít k distribuci dat a zpracování napříč několika identickými strukturovanými databázemi a horizontální dělení databází pro navigaci v omezeních platformy.

    • Horizontální dělení se například často používá na víceklientských platformách SaaS k izolaci skupin tenantů do různých konstruktorů datové platformy.

Azure SQL Database

  • Azure SQL Database poskytuje plně spravovaný databázový stroj, který je vždy spuštěný na nejnovější stabilní verzi databázového stroje SQL Serveru a základního operačního systému.

    • Poskytuje inteligentní funkce, jako je ladění výkonu, monitorování hrozeb a posouzení ohrožení zabezpečení.

  • Azure SQL Database poskytuje integrovanou regionální vysokou dostupnost a geografickou replikaci na klíč pro distribuci replik pro čtení napříč oblastmi Azure.

    • Při geografické replikaci zůstanou sekundární repliky databáze jen pro čtení, dokud se nes zahájí převzetí služeb při selhání.
    • Ve stejných nebo různých oblastech jsou podporovány až čtyři sekundy.
    • Sekundární repliky lze také použít pro přístup k dotazům jen pro čtení za účelem optimalizace výkonu čtení.
    • Převzetí služeb při selhání musí být inicializováno ručně, ale je možné ho zabalit do automatizovaných provozních postupů.

  • Azure SQL Database poskytuje skupiny automatického převzetí služeb při selhání, které replikují databáze na sekundární server a umožňují transparentní převzetí služeb při selhání v případě selhání.

    • Skupiny automatického převzetí služeb při selhání podporují geografickou replikaci všech databází ve skupině pouze na jeden sekundární server nebo instanci v jiné oblasti.
    • Skupiny automatického převzetí služeb při selhání se v současné době nepodporují ve vrstvě služby Hyperscale.
    • Sekundární databáze se dají použít k přesměrování zpracování provozu čtení.

  • Repliky databáze na úrovni služby premium nebo Pro důležité obchodní informace je možné distribuovat napříč Zóny dostupnosti bez dalších poplatků.

    • Řídicí okruh je také duplikován napříč několika zónami jako tři kruhy brány (GW).
      • Směrování na konkrétní okruh brány řídí Azure Traffic Manager.
    • Při použití úrovně Pro důležité obchodní informace je zónově redundantní konfigurace dostupná jenom v případě, že je vybraný výpočetní hardware Gen5.

  • Azure SQL Database nabízí smlouvu SLA standardních 99,99% dostupnosti napříč všemi jejími úrovněmi služeb, ale poskytuje vyšší smlouvu SLA o 99,995 % pro Pro důležité obchodní informace nebo úrovně Premium v oblastech, které podporují zóny dostupnosti.

    • Azure SQL Database Pro důležité obchodní informace nebo úrovně Premium, které nejsou nakonfigurované pro zónově redundantní nasazení, mají smlouvu SLA o dostupnosti 99,99 %.

  • Když je nakonfigurovaná geografická replikace, úroveň Pro důležité obchodní informace služby Azure SQL Database poskytuje 30sekundový cíl doby obnovení (RTO) po dobu 100 % nasazených hodin.

  • Při konfiguraci s geografickou replikací má úroveň Pro důležité obchodní informace služby Azure SQL Database cíl bodu obnovení (RPO) 5 sekund po dobu 100 % nasazených hodin.

  • Úroveň Hyperscale služby Azure SQL Database při konfiguraci s alespoň dvěma replikami má smlouvu SLA o dostupnosti 99,99 %.

  • Náklady na výpočetní prostředky spojené se službou Azure SQL Database je možné snížit pomocí slevy za rezervaci.

    • Pro databáze založené na DTU není možné použít rezervovanou kapacitu.

  • Obnovení k určitému bodu v čase lze použít k vrácení databáze a obsažených dat k dřívějšímu bodu v čase.

  • Geografické obnovení lze použít k obnovení databáze z geograficky redundantního zálohování.

Azure Database For PostgreSQL

  • Azure Database for PostgreSQL se nabízí ve třech různých možnostech nasazení:

    • Jednoúčelový server, SMLOUVA SLA 99,99 %
    • Flexibilní server, který nabízí redundanci zóny dostupnosti, SLA 99,99 %
    • Hyperscale (Citus), SLA 99,95 % při povolení režimu vysoké dostupnosti

  • Hyperscale (Citus) poskytuje dynamickou škálovatelnost prostřednictvím horizontálního dělení bez změn aplikace.

    • Distribuce řádků tabulky napříč několika servery PostgreSQL je klíčem k zajištění škálovatelných dotazů v Hyperscale (Citus).
    • Více uzlů může souhrnně obsahovat více dat než tradiční databáze a v mnoha případech může paralelně využívat pracovní procesory k optimalizaci nákladů.

  • Automatické škálování je možné nakonfigurovat prostřednictvím automatizace runbooků, aby se zajistila elasticita v reakci na měnící se vzory provozu.

  • Flexibilní server poskytuje nákladovou efektivitu pro neprodukční úlohy prostřednictvím možnosti zastavit nebo spustit server a nárazovou výpočetní úroveň, která je vhodná pro úlohy, které nevyžadují nepřetržitou výpočetní kapacitu.

  • Za úložiště zálohování se neúčtují žádné další poplatky až za 100 % celkového zřízeného úložiště serveru.

    • Další spotřeba úložiště zálohování se účtuje podle spotřebovaného GB za měsíc.

  • Náklady na výpočetní prostředky spojené se službou Azure Database for PostgreSQL je možné snížit pomocí slevy za rezervaci na jednoúčelový server nebo slevy za rezervaci Hyperscale (Citus).

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.

    • Toto doporučení je obzvláště rozšířené, když návrh aplikace považuje tři nebo více oblastí Azure, protože omezení relačních technologií mohou výrazně bránit globálně distribuovaným datovým platformám.
    • 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.

Azure SQL Database

  • Úroveň služby Pro důležité obchodní informace slouží k maximalizaci spolehlivosti a dostupnosti, včetně přístupu k důležitým možnostem odolnosti.

  • Model spotřeby založený na virtuálních jádrech vám usnadní nezávislý výběr výpočetních prostředků a prostředků úložiště přizpůsobený požadavkům na objem úloh a propustnost.

    • Ujistěte se, že se pro informace o požadavcích na výpočetní prostředky a prostředky úložiště použije definovaný model kapacity.

  • Nakonfigurujte model nasazení zónově redundantní tak, aby rozložil repliky databáze Pro důležité obchodní informace ve stejné oblasti napříč Zóny dostupnosti.

  • Pomocí aktivní geografické replikace nasaďte čitelné repliky ve všech oblastech nasazení (až čtyři).

  • Pomocí skupin automatického převzetí služeb při selhání můžete zajistit transparentní převzetí služeb při selhání sekundární oblasti s použitím geografické replikace, která zajistí replikaci do dalších oblastí nasazení pro optimalizaci čtení a redundanci databáze.

    • V případě scénářů aplikací omezených pouze na dvě oblasti nasazení by mělo být upřednostněno použití skupin automatického převzetí služeb při selhání.

  • Zvažte automatizované provozní triggery založené na upozorňování v souladu s modelem stavu aplikace a proveďte převzetí služeb při selhání geograficky replikovaným instancím v případě selhání, které má vliv na primární a sekundární v rámci skupiny automatického převzetí služeb při selhání.

Důležité

U aplikací, které zvažují více než čtyři oblasti nasazení, je třeba vzít v úvahu závažné aspekty horizontálního dělení aplikací nebo refaktoring aplikace tak, aby podporovaly technologie zápisu do více oblastí, jako je Azure Cosmos DB. Pokud to ale není možné ve scénáři úlohy aplikace, doporučujeme zvýšit úroveň oblasti v rámci jedné geografické oblasti na primární stav zahrnující geograficky replikovanou instanci na rovnoměrněji distribuovaný přístup pro čtení.

  • Nakonfigurujte aplikaci tak, aby dotazovat instance replik pro čtení dotazů za účelem optimalizace výkonu čtení.

  • Azure Monitor a Azure SQL Analytics slouží k detekci incidentů spolehlivosti téměř v reálném čase v Azure SQL DB.

  • Pomocí služby Azure Monitor vyhodnoťte využití pro všechny databáze, abyste zjistili, jestli mají správnou velikost.

    • Zajistěte, aby kanály CD zvážily zátěžové testování v reprezentativních úrovních zatížení a ověřte odpovídající chování datové platformy.

  • Vypočítejte metriku stavu pro databázové komponenty, abyste mohli sledovat stav vzhledem k obchodním požadavkům a využití prostředků, a tam, kde je to vhodné, využijte monitorování a upozornění k řízení automatizovaných provozních akcí.

    • Ujistěte se, že jsou zahrnuty klíčové metriky výkonu dotazů, aby bylo možné provést rychlou akci, když dojde ke snížení výkonu služby.

  • Optimalizujte dotazy, tabulky a databáze pomocí Query Performance Insights a běžných doporučení k výkonu poskytovaných Microsoftem.

  • Implementujte logiku opakování pomocí sady SDK ke zmírnění přechodných chyb, které mají vliv na připojení ke službě Azure SQL Database.

  • Určete prioritu použití klíčů spravovaných službou při použití transparentní šifrování dat na straně serveru pro šifrování neaktivních uložených dat.

    • Pokud se vyžadují klíče spravované zákazníkem nebo šifrování na straně klienta (AlwaysEncrypted), ujistěte se, že klíče jsou správně odolné vůči zálohám a automatizovaným obměněm.

  • Zvažte použití obnovení k určitému bodu v čase jako provozního playbooku k zotavení z závažných chyb konfigurace.

Azure Database For PostgreSQL

  • Flexibilní server se doporučuje používat pro důležité obchodní úlohy kvůli podpoře zóny dostupnosti.

  • Při použití Hyperscale (Citus) pro důležité obchodní úlohy povolte režim vysoké dostupnosti, aby získal záruku sla o 99,95 %.

  • Pomocí konfigurace serveru Hyperscale (Citus) můžete maximalizovat dostupnost napříč několika uzly.

  • Definujte pro aplikaci model kapacity, který informuje požadavky na výpočetní prostředky a prostředky úložiště v rámci datové platformy.

    • Zvažte slevu za rezervaci Hyperscale (Citus) a poskytněte potenciální optimalizaci nákladů.

Ukládání do mezipaměti pro data horké 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. Služba Azure Cache for Redis je umístěná k abstrakci a optimalizaci přístupu ke čtení datové platformy. Tato část se proto zaměří na optimální využití služby Azure Cache for Redis ve scénářích, kdy je vyžadován další výkon čtení a stálost přístupu k datům.

Na co dát pozor při navrhování

  • 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.

  • 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 Cache for Redis

  • Redis Cache je opensourcový systém úložiště NoSQL s hodnotou klíče v paměti.

  • Úrovně Enterprise a Enterprise Flash je možné nasadit v konfiguraci aktivní-aktivní napříč Zóny dostupnosti v rámci oblasti a různých oblastí Azure prostřednictvím geografické replikace.

    • Při nasazení v nejméně třech oblastech Azure a třech nebo více Zóny dostupnosti v každé oblasti s povolenou aktivní geografickou replikací pro všechny instance mezipaměti poskytuje Služba Azure Cache for Redis smlouvu SLA 99,999 % pro připojení k jednomu koncovému bodu místní mezipaměti.
    • Při nasazení napříč třemi Zóny dostupnosti v jedné oblasti Azure se poskytuje smlouva SLA o připojení 99,99 %.

  • Podniková úroveň Flash běží na kombinaci paměti RAM a nevolatilního úložiště paměti FLASH, zatímco to představuje malý výkon, který také umožňuje velmi velké velikosti mezipaměti až 13 TB s clusteringem.

  • 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.

  • Funkce Plánované aktualizace nezahrnuje aktualizace Azure ani aktualizace použité na základní operační systém virtuálního počítače.

  • Během operace škálování na více instancí se zvýší využití procesoru, zatímco se data migrují do nových instancí.

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 Cache for Redis

  • Využijte skladovou položku Premium nebo Enterprise k maximalizaci spolehlivosti a výkonu.

    • Pro scénáře s extrémně velkými objemy dat je potřeba zvážit úroveň Enterprise Flash.
    • V situacích, kdy je vyžadována pouze pasivní geografická replikace, je možné také zvážit úroveň Premium.

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

  • Ujistěte se, že se instance replik nasazují napříč Zóny dostupnosti v rámci každé oblasti Azure.

  • Azure Monitor použijte k vyhodnocení služby Azure Cache for Redis.

    • 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.

  • Optimalizujte odolnost připojení implementací logiky opakování, časových limitů a použitím jednotonové implementace multiplexeru připojení Redis.

  • Nakonfigurujte plánované aktualizace tak, aby předepisovali dny a časy, po které se aktualizace Redis Serveru použijí do 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.

Popis 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 přes 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í		 – Zdroj dat záznamu 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

Azure Synapse poskytuje podnikovou analytickou platformu, která spojuje relační a nerelační data s technologiemi Sparku s využitím integrované integrace se službami Azure, jako je Azure Cosmos DB, a usnadňuje analýzu velkých objemů dat. Aspekty návrhu a doporučení v této části se proto zaměří na optimální využití Azure Synapse a Azure Cosmos DB pro analytické scénáře.

Na co dát pozor při navrhování

  • 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) se používají k extrakci dat, budou spotřebovávat propustnost a ovlivnit výkon transakčních úloh.
    • Spouštění kanálů ETL zřídka kvůli snížení propustnosti a dopadu na výkon způsobí, že analytická data jsou 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 změněna nebo odstraněna, kanály ETL musí tyto změny v cílových datech počítat s analytickými dotazy prostřednictvím doplňkového nebo správě verzí, výpisu a opětovného načtení nebo místních změn analytických dat. 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.

  • Analytické úložiště Azure Cosmos DB poskytuje schématizované plně izolované úložiště dat orientovaných na sloupce, které umožňuje rozsáhlé analýzy dat azure Cosmos DB z Azure Synapse bez dopadu na transakční úlohy Azure Cosmos DB.

    • Pokud je kontejner Azure Cosmos DB povolený jako analytické úložiště, vytvoří se nové úložiště sloupců interně z provozních dat v kontejneru. Toto úložiště sloupců je trvalé odděleně od úložiště transakcí orientovaného na řádky pro kontejner.
    • Operace vytvoření, aktualizace a odstranění provozních dat se automaticky synchronizují s analytickým úložištěm, takže se nevyžaduje žádný kanál změn ani zpracování ETL.
    • Synchronizace dat z provozu do analytického úložiště nevyužívají jednotky žádostí o propustnost zřízené v kontejneru nebo databázi. Na transakční úlohy nemá žádný vliv na výkon. Analytické úložiště nevyžaduje přidělení dalších RU ve službě Azure Cosmos DB Database nebo kontejneru.
    • Automatická synchronizace je proces, kdy se změny provozních dat automaticky synchronizují do analytického úložiště. Latence automatické synchronizace je obvykle kratší než dvě (2) minuty.
      • Latence automatické synchronizace může být až pět (5) minut pro databázi se sdílenou propustností a velkým počtem kontejnerů.
      • Jakmile se automatická synchronizace dokončí, můžete nejnovější data dotazovat z Azure Synapse.
    • Úložiště analytického úložiště používá cenový model založený na spotřebě, který účtuje objem dat a počet operací čtení a zápisu. Ceny analytického úložiště jsou oddělené od cen transakčního úložiště.

  • Pomocí Azure Synapse Linku je možné analytické úložiště Azure Cosmos DB dotazovat přímo ze služby Azure Synapse. Díky tomu se z Synapse dají dotazovat data Azure Cosmos DB společně s dalšími analytickými úlohami z Synapse v téměř reálném čase.

  • Analytické úložiště Azure Cosmos DB není ve výchozím nastavení dělené.

    • V některých scénářích dotazů se výkon zlepší rozdělením dat analytického úložiště pomocí klíčů, které se často používají v predikátech dotazů.
    • Dělení se aktivuje úlohou ve službě Azure Synapse, která spouští poznámkový blok Sparku pomocí Synapse Linku, který načte data z analytického úložiště Azure Cosmos DB a zapíše je do úložiště děleného synapse v primárním účtu úložiště pracovního prostoru Synapse.

  • Bezserverové fondy SQL služby Azure Synapse Analytics se můžou dotazovat na analytické úložiště prostřednictvím automaticky aktualizovaných zobrazení nebo příkazů SELECT / OPENROWSET .

  • Fondy Spark služby Azure Synapse Analytics se můžou dotazovat na analytické úložiště prostřednictvím automaticky aktualizovaných tabulek Sparku spark.read nebo příkazu.

  • Data lze také zkopírovat z analytického úložiště Azure Cosmos DB do vyhrazeného fondu Synapse SQL pomocí Sparku, aby bylo možné použít zřízené prostředky fondu Azure Synapse SQL.

  • Data analytického úložiště Azure Cosmos DB je možné dotazovat pomocí Azure Synapse Sparku.

    • Poznámkové bloky Spark umožňují kombinacím datových rámců Sparku agregovat a transformovat analytická data azure Cosmos DB s jinými sadami dat a využívat další pokročilé funkce Synapse Sparku, včetně zápisu transformovaných dat do jiných úložišť nebo trénování modelů AIOps Machine Learning.

Úložiště analytických sloupců služby Azure Cosmos DB

  • 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.

Azure Synapse

  • Azure Synapse spojuje analytické funkce, včetně datových skladů SQL, velkých objemů dat Sparku a Průzkumníka dat pro analýzy protokolů a časových řad.

    • Azure Synapse používá propojené služby k definování připojení k jiným službám, jako je Azure Storage.
    • Data je možné ingestovat do Synapse Analytics prostřednictvím aktivita Copy z podporovaných zdrojů. To umožňuje analýzu dat ve službě Synapse, aniž by to mělo vliv na zdrojové úložiště dat, ale kvůli přenosu dat přidává režii na čas, náklady a latenci.
    • Data se také dají dotazovat v podporovaných externích úložištích a vyhnout se tak režijním nákladům na příjem a přesun dat. Azure Storage s Data Lake Gen2 je podporované úložiště pro Synapse a exportovaná data Log Analytics se dají dotazovat přes Synapse Spark.

  • Azure Synapse Studio spojuje ingestování a dotazování úloh.

    • Zdrojová data, včetně dat analytického úložiště Azure Cosmos DB a dat exportu služby Log Analytics, se dotazují a zpracovávají, aby podporovala business intelligence a další agregované případy použití analytického úložiště.

Azure Synapse Analytics

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.

Analýza aplikací

AIOps a provozní analýza

  • Vytvořte jeden pracovní prostor Azure Synapse s propojenými službami a sadami dat pro každý zdrojový účet Azure Storage, do kterého se odesílají provozní data z prostředků.

  • Vytvořte vyhrazený účet Azure Storage a použijte ho jako primární účet úložiště pracovního prostoru k ukládání dat a metadat katalogu pracovních prostorů Synapse. Nakonfigurujte ho pomocí hierarchického oboru názvů pro povolení Azure Data Lake Gen2.

    • Udržujte oddělení mezi zdrojovými analytickými daty a daty pracovního prostoru Synapse a metadaty.
      • Nepoužívejte jeden z regionálních nebo globálních účtů Azure Storage, ve kterých se odesílají provozní data.

Další krok

Projděte si důležité informace o sítích.

Síť a možnosti připojení