Co je analytické úložiště Azure Cosmos DB?

platí pro: SQL api Azure Cosmos DB api pro MongoDB

Analytické úložiště Azure Cosmos DB je plně izolované úložiště sloupců umožňující rozsáhlé analýzy provozních dat ve službě Azure Cosmos DB, aniž by to ovlivnilo vaše transakční úlohy.

Transakční úložiště Azure Cosmos DB je bez schématu a umožňuje iterovat v transakčních aplikacích, aniž byste museli řešit správu schémat nebo indexů. Na rozdíl od toho se analytické úložiště Azure Cosmos DB schematizuje, aby se optimalizoval výkon analytických dotazů. Tento článek podrobně popisuje analytické úložiště.

Problémy s rozsáhlými analýzami provozních dat

Provozní data s více modely v kontejneru Azure Cosmos DB se interně ukládají v "transakčním obchodě" založeném na indexovaných řádkovém objektu. Formát úložiště řádků je navržený tak, aby umožnil rychlé transakční čtení a zápisy v řádcích milisekund a provozních dotazech. Pokud se vaše datová sada zvětšuje, mohou být složité analytické dotazy nákladné z hlediska zřízené propustnosti dat uložených v tomto formátu. Vysoká spotřeba zřízené propustnosti zase ovlivňuje výkon transakčních úloh používaných vašimi aplikacemi a službami v reálném čase.

Při analýze velkých objemů dat se provozní data tradičně extrahují z transakčního úložiště azure Cosmos DB a ukládají se do samostatné datové vrstvy. Data se například ukládají v datovém skladu nebo datovém jezeře ve vhodném formátu. Tato data se později používají pro rozsáhlé analýzy a analyzují se pomocí výpočetního modulu, jako jsou Apache Spark clustery. Toto oddělení analytických vrstev úložiště a výpočetních vrstev od provozních dat vede k další latenci, protože kanály ETL (extrakce, transformace, načítání) běží méně často, aby se minimalizoval potenciální dopad na vaše transakční úlohy.

Kanály ETL se také stávají složitými při zpracování aktualizací provozních dat v porovnání se zpracováním pouze nově ingestovaných provozních dat.

Analytické úložiště orientované na sloupce

Analytické úložiště Azure Cosmos DB řeší problémy se složitostí a latencí, ke kterým dochází u tradičních kanálů ETL. Analytické Cosmos Azure Cosmos DB může automaticky synchronizovat provozní data do samostatného úložiště sloupců. Formát úložiště sloupců je vhodný k tomu, aby se analytické dotazy ve velkém měřítku prováděly optimalizovaným způsobem, což vede ke zlepšení latence takových dotazů.

Pomocí Azure Synapse Linku teď můžete vytvářet řešení HTAP bez ETL prostřednictvím přímého propojení s analytickým úložištěm Azure Cosmos DB z Azure Synapse Analytics. Umožňuje spouštět na provozních datech rozsáhlé analýzy v reálném čase.

Funkce analytického úložiště

Když v kontejneru Azure Cosmos DB povolíte analytické úložiště, interně se vytvoří nové úložiště sloupců na základě provozních dat v kontejneru. Toto úložiště sloupců se uchová odděleně od transakčního úložiště pro tento kontejner orientované na řádky. Vložení, aktualizace a odstranění provozních dat se automaticky synchronizují do analytického úložiště. K synchronizaci dat nepotřebujete kanál změn ani ETL.

Úložiště sloupců pro analytické úlohy s provozními daty

Analytické úlohy obvykle zahrnují agregace a sekvenční prohledávání vybraných polí. Uložením dat v pořadí podle velkého sloupce umožňuje analytické úložiště skupině hodnot pro jednotlivá pole serializovat dohromady. Tento formát snižuje počet vstupně-výstupních operací za posledních 400 let (IOPS) vyžadované k prohledávání nebo výpočtu statistik v konkrétních polích. Výrazně se tím vylepšuje doba odezvy dotazů při prohledávání velkých datových sad.

Pokud jsou například provozní tabulky v následujícím formátu:

Úložiště řádků zachová výše uvedená data v serializovaném formátu na řádek na disku. Tento formát umožňuje rychlejší transakční čtení, zápisy a provozní dotazy, jako je například "Vrácení informací o produktu Product1". S tím, jak se ale datová sada rozrůstá, a pokud chcete na datech spouštět složité analytické dotazy, může to být nákladné. Pokud například chcete získat "prodejní trendy pro produkt v kategorii s názvem "Equipment" napříč různými obchodními jednotkami a měsíci", musíte spustit složitý dotaz. Velké kontroly v této datové sadě mohou být nákladné z hlediska zřízené propustnosti a mohou také ovlivnit výkon transakčních úloh, které pohánějící vaše aplikace a služby v reálném čase.

Analytické úložiště, což je úložiště sloupců, je pro takové dotazy lepší, protože serializuje podobná pole dat dohromady a snižuje počet IOPS disku.

Následující obrázek ukazuje transakční úložiště řádků vs. analytické úložiště sloupců ve službě Azure Cosmos DB:

Oddělený výkon analytických úloh

Vzhledem k analytickým dotazům nemá žádný vliv na výkon transakčních úloh, protože analytické úložiště je oddělené od transakčního úložiště. Analytické úložiště nevyžaduje, aby byly přiděleny samostatné jednotky žádosti (RU).

Automatická synchronizace

Automatická synchronizace odkazuje na plně spravované funkce služby Azure Cosmos DB, kde se vložení, aktualizace a odstranění provozních dat automaticky synchronizují z transakčního úložiště do analytického úložiště v reálném čase. Latence automatické synchronizace je obvykle do 2 minut. V případě databáze se sdílenou propustností a velkým počtem kontejnerů může být latence automatické synchronizace jednotlivých kontejnerů vyšší a může trvat až 5 minut. Rádi bychom se dozvěděli více o tom, jak tato latence odpovídá vašim scénářům. V tom případě se obraťte na tým Azure Cosmos DB.

Na konci každého spuštění procesu automatické synchronizace budou vaše transakční data okamžitě dostupná pro Azure Synapse Analytics runtime:

• Azure Synapse Analytics Sparku mohou číst všechna data, včetně nejnovějších aktualizací, prostřednictvím tabulek Sparku, které se aktualizují automaticky nebo pomocí příkazu , které vždy čtou poslední spark.read stav dat.

• Azure Synapse Analytics SQL bez serveru mohou číst všechna data, včetně nejnovějších aktualizací, prostřednictvím zobrazení, která se aktualizují automaticky, nebo prostřednictvím příkazů , které vždy čtou nejnovější stav SELECT OPENROWSET dat.

Elasticita & škálovatelnost

Pomocí horizontálního dělení může transakční úložiště Azure Cosmos DB elasticky škálovat úložiště a propustnost bez jakýchkoli výpadků. Horizontální dělení v transakčním úložiště poskytuje & elasticitu při automatické synchronizaci, aby se data synchronizovala do analytického úložiště v reálném čase. Synchronizace dat probíhá bez ohledu na propustnost transakčního provozu, ať už se jedná o 1 000 operací za sekundu nebo 1 milion operací za sekundu, a nemá vliv na zřízenou propustnost v transakčním úložiště.

Automatické zpracování aktualizací schématu

Transakční úložiště Azure Cosmos DB je bez schématu a umožňuje iterovat v transakčních aplikacích, aniž byste museli řešit správu schémat nebo indexů. Na rozdíl od toho se analytické úložiště Azure Cosmos DB schematizuje, aby se optimalizoval výkon analytických dotazů. Díky funkci automatické synchronizace spravuje Azure Cosmos DB odvozování schématu z nejnovějších aktualizací z transakčního úložiště. Kromě toho také beze změny spravuje reprezentaci schématu v analytickém obchodě, což zahrnuje zpracování vnořených datových typů.

Jak se vaše schéma vyvíjí a postupně se přidávají nové vlastnosti, analytické úložiště automaticky prezentuje sjednocené schéma napříč všemi historickými schématy v transakčním úložiště.

Omezení schématu

Pokud povolíte analytické úložiště, které automaticky odvodí a správně reprezentuje schéma, platí pro provozní data ve službě Azure Cosmos DB následující omezení:

• Ve schématu můžete mít maximálně 1 000 vlastností na libovolné úrovni vnoření a maximální hloubku vnoření 127.

  • V analytickém úložiště se reprezentuje pouze prvních 1 000 vlastností.
  • V analytickém úložiště je znázorněno pouze prvních 127 vnořených úrovní.
  • První úrovní dokumentu JSON je jeho / kořenová úroveň.
  • Vlastnosti na první úrovni dokumentu budou reprezentovány jako sloupce.

• Ukázkové scénáře:

  • Pokud má první úroveň dokumentu 2 000 vlastností, bude reprezentováno pouze prvních 1 000.
  • Pokud mají dokumenty 5 úrovní s 200 vlastnostmi v každé z nich, budou reprezentovány všechny vlastnosti.
  • Pokud mají dokumenty 10 úrovní se 400 vlastnostmi v každé z nich, v analytickém úložiště budou plně reprezentovány pouze tyto 2 první úrovně. Bude reprezentována také polovina třetí úrovně.

• Následující hypotetický dokument obsahuje 4 vlastnosti a 3 úrovně.

  • Úrovně jsou root myArray , a vnořená struktura v rámci myArray .
  • Vlastnosti jsou id myArray , a myArray.nested1 myArray.nested2 .
  • Reprezentace analytického úložiště bude mít 2 sloupce a id myArray . Pomocí Sparku nebo T-SQL můžete také zveřejnit vnořené struktury jako sloupce.

{
  "id": "1",
  "myArray": [
    "string1",
    "string2",
    {
      "nested1": "abc",
      "nested2": "cde"
    }
  ]
}

• I když dokumenty JSON (a Cosmos/kontejnery DB) rozlišují z hlediska jedinečnosti velká a malá písmena, analytické úložiště nikoli.

  • Ve stejném dokumentu: Názvy vlastností na stejné úrovni by měly být jedinečné při porovnávání malých a velkých písmen bez rozlišení. Například následující dokument JSON má na stejné úrovni "Name" (Název) a "name" (název). I když se jedná o platný dokument JSON, nesplňuje omezení jedinečnosti, a proto nebude v analytickém úložiště plně reprezentován. V tomto příkladu jsou "Name" a "name" stejné při porovnání způsobem bez rozlišení velkých a malých písmen. V "Name": "fred" analytickém úložiště se bude reprezentovat pouze , protože se jedná o první výskyt. A "name": "john" nebude reprezentováno vůbec.

  {"id": 1, "Name": "fred", "name": "john"}
  

  • V různých dokumentech: Vlastnosti na stejné úrovni a se stejným názvem, ale v různých případech, budou reprezentovány ve stejném sloupci pomocí formátu názvu prvního výskytu. Například následující dokumenty JSON mají a "Name" "name" na stejné úrovni. Vzhledem k tomu, že první formát dokumentu je , použije se tento formát k reprezentaci "Name" názvu vlastnosti v analytickém obchodě. Jinými slovy, název sloupce v analytickém obchodě bude "Name" . Ve "fred" "john" sloupci bude reprezentováno i "Name" .

  {"id": 1, "Name": "fred"}
  {"id": 2, "name": "john"}
  

• První dokument kolekce definuje počáteční schéma analytického úložiště.

  • Dokumenty s více vlastnostmi, než má počáteční schéma, budou generovat nové sloupce v analytickém úložišti.
  • Sloupce nelze odebrat.
  • Odstranění všech dokumentů v kolekci neresetuje schéma analytického úložiště.
  • Není k dispozici Správa verzí schématu. Poslední verzí odvozenou z transakčního úložiště je to, co se zobrazí v analytickém úložišti.

• V současné době Azure synapse Spark nemůže číst vlastnosti, které obsahují některé speciální znaky, uvedené níže. Azure Synapse SQL bez serveru to nemá vliv.

  • : (Dvojtečka)
  • ' (Čárka akcent)
  • , (Čárka)
  • ; Střední
  • {}
  • ()
  • \n
  • \t
  • = (Rovnítko)
  • "(Znak uvozovek)

• Pokud máte názvy vlastností pomocí výše uvedených znaků, alternativy:

  • Změňte si datový model předem, aby nedocházelo k těmto znakům.
  • Vzhledem k tomu, že v současné době nepodporujeme obnovení schématu, můžete změnit aplikaci tak, aby přidala redundantní vlastnost s podobným názvem. tím se tyto znaky vyhne.
  • Pomocí možnosti změnit kanál můžete vytvořit materializované zobrazení kontejneru bez těchto znaků v názvech vlastností.
  • Pomocí dropColumn Možnosti Spark můžete zasažené sloupce ignorovat a načíst všechny ostatní sloupce do datového rámce. Syntaxe je:

df = spark.read\
     .format("cosmos.olap")\
     .option("spark.synapse.linkedService","<your-linked-service-name>")\
     .option("spark.synapse.container","<your-container-name>")\
     .option("spark.synapse.dropColumn","FirstName,LastName")\
     .load()  

df = spark.read\
    .format("cosmos.olap")\
    .option("spark.synapse.linkedService","<your-linked-service-name>")\
    .option("spark.synapse.container","<your-container-name>")\
    .option("spark.synapse.dropColumn","FirstName,LastName")\
    .option("spark.synapse.dropColumn","StreetName,StreetNumber")\
    .load()  

• Azure synapse Spark teď podporuje vlastnosti s prázdnými znaky v jejich názvech. V takovém případě je nutné použít allowWhiteSpaceInFieldNames možnost Spark k načtení ovlivněných sloupců do datového rámce a zachovat původní název. Syntaxe je:

df = spark.read\
     .format("cosmos.olap")\
     .option("spark.synapse.linkedService","<your-linked-service-name>")\
     .option("spark.synapse.container","<your-container-name>")\
     .option("spark.cosmos.allowWhiteSpaceInFieldNames", "true")\
    .load()

• Následující typy dat BSON nejsou podporovány a v analytickém úložišti nebudou reprezentovány:

  • Decimal128
  • Regulární výraz
  • Ukazatel DB
  • JavaScript
  • Symbol
  • MinKey / MaxKey

• Při použití řetězců DateTime, které následují Standard ISO 8601 UTC, je očekáváno následující chování:

  • Fondy Spark ve službě Azure synapse budou tyto sloupce zastupovat jako string .
  • SQL fondy bez serveru ve službě Azure Synapse budou tyto sloupce zastupovat jako varchar(8000) .

• SQL fondy bez serveru ve službě Azure Synapse podporují sady výsledků s až 1000 sloupci a vystavování vnořených sloupců také počítá s tímto limitem. Zvažte prosím tyto informace při návrhu architektury dat a modelování transakčních dat.

Reprezentace schématu

V analytickém úložišti existují dva typy reprezentace schématu. Tyto typy definují způsob reprezentace schématu pro všechny kontejnery v databázovém účtu a mají kompromisy mezi jednoduchostí možnosti dotazování a pohodlíí více zahrnutých sloupcových reprezentací pro polymorfní schémata.

• dobře definovaná reprezentace schématu, výchozí možnost pro účty rozhraní API pro SQL (jádro)
• úplná reprezentace schématu přesnosti, výchozí možnost pro Azure Cosmos DB rozhraní API pro účty MongoDB.

schéma úplných věrných pro účty rozhraní SQL API

pro SQL (Core) účty rozhraní API je možné použít schéma s úplnými kvalitou místo výchozí možnosti nastavením typu schématu při prvním povolování Synapse odkazů na účet Cosmos DB. Tady jsou informace o tom, jak změnit výchozí typ reprezentace schématu:

• Tato možnost je platná pouze pro účty, které nemají odkaz synapse již povoleny.
• Není možné obnovit typ reprezentace schématu z definice přesně na celou nebo naopak.
• aktuálně Azure Cosmos DB rozhraní API pro účty MongoDB není kompatibilní s touto možností změny reprezentace schématu. Všechny účty MongoDB budou mít vždycky plný typ reprezentace schématu.
• V tuto chvíli se tato změna nedá provést prostřednictvím Azure Portal. Všechny databázové účty, které mají odkaz synapse povolený Azure Portal, budou mít výchozí typ reprezentace schématu a dobře definované schéma.

Rozhodnutí o typu reprezentace schématu musí být provedeno současně s povoleným odkazem synapse na účtu pomocí Azure CLI nebo PowerShellu.

Pomocí Azure CLI:

az cosmosdb create --name MyCosmosDBDatabaseAccount --resource-group MyResourceGroup --subscription MySubscription --analytical-storage-schema-type "FullFidelity" --enable-analytical-storage true

S prostředím PowerShell:

 New-AzCosmosDBAccount -ResourceGroupName MyResourceGroup -Name MyCosmosDBDatabaseAccount  -EnableAnalyticalStorage true -AnalyticalStorageSchemaType "FullFidelity"

Dobře definovaná reprezentace schématu

Dobře definovaná reprezentace schématu vytvoří jednoduché tabulkové vyjádření nezávislá dat schématu v transakčním úložišti. Dobře definovaná reprezentace schématu má následující požadavky:

• První dokument definuje základní schéma a vlastnost musí mít vždy stejný typ ve všech dokumentech. Jedinou výjimkou jsou tyto:
  • Z hodnoty null na jiný datový typ. První výskyt bez hodnoty null definuje datový typ sloupce. Žádný dokument, který nenásleduje za prvním datovým typem, který není null, nebude reprezentován v analytickém úložišti.
  • Od float do integer . Všechny dokumenty budou reprezentovány v analytickém úložišti.
  • Od integer do float . Všechny dokumenty budou reprezentovány v analytickém úložišti. pokud ale chcete tato data číst pomocí SQL fondů bez serveru s využitím služby Azure Synapse, musíte k převedení sloupce na použít klauzuli with varchar . A po provedení tohoto počátečního převodu je možné ho znovu převést na číslo. Zkontrolujte prosím níže uvedený příklad, kde NUM počáteční hodnota byla celé číslo a druhá z nich byla typu float.

SELECT CAST (num as float) as num
FROM OPENROWSET(PROVIDER = 'CosmosDB',
                CONNECTION = '<your-connection',
                OBJECT = 'IntToFloat',
                SERVER_CREDENTIAL = 'your-credential'
) 
WITH (num varchar(100)) AS [IntToFloat]

• Vlastnosti, které nedodržují základní datový typ schématu, nebudou v analytickém úložišti zastoupeny. Představte si například 2 dokumenty uvedené níže a první z nich definovali základní schéma analytického úložiště. Druhý dokument, kde id je 2 , nemá dobře definované schéma, protože vlastnost "a" je řetězec a první dokument má "a" číslo. V tomto případě analytické úložiště registruje datový typ "a" jako integer životnost kontejneru. Druhý dokument bude i nadále součástí analytického úložiště, ale jeho "a" vlastnost nebude.

  • {"id": "1", "a":123}
  • {"id": "2", "a": "str"}

• Typy polí musí obsahovat jeden opakovaný typ. Například {"a": ["str",12]} není správně definované schéma, protože pole obsahuje kombinaci celočíselného a řetězcového typu.

• V dobře definovaném schématu očekává jiné chování v souvislosti s různými typy:

  • Fondy Spark ve službě Azure synapse budou tyto hodnoty zastupovat jako undefined .
  • SQL fondy bez serveru ve službě Azure Synapse budou tyto hodnoty zastupovat jako NULL .

• V souvislosti s explicitními hodnotami očekává jiné chování null :

  • Fondy Spark ve službě Azure synapse budou tyto hodnoty číst jako 0 (nula). A změní se na undefined , jakmile sloupec obsahuje hodnotu, která není null.
  • SQL fondy bez serveru ve službě Azure Synapse budou tyto hodnoty načítat jako NULL .

• V případě chybějících sloupců očekávat jiné chování:

  • Fondy Spark ve službě Azure synapse budou tyto sloupce zastupovat jako undefined .
  • SQL fondy bez serveru ve službě Azure Synapse budou tyto sloupce zastupovat jako NULL .

Reprezentace schématu s úplnou věrností

Úplná reprezentace schématu přesnosti je navržená tak, aby zpracovávala celou škálu polymorfních schémat v provozních datech nezávislá schématu. V tomto vyjádření schématu nejsou žádné položky z analytického úložiště vynechány, i když nejsou porušena dobře definovaná omezení schématu (která nemají pole se smíšeným datovým typem ani pole se smíšeným datovým typem).

Toho dosáhnete tak, že přeložíte vlastnosti listu provozních dat do analytického úložiště s odlišnými sloupci na základě datového typu hodnot ve vlastnosti. Názvy vlastností listu se rozšiřují pomocí datových typů jako přípona ve schématu analytického úložiště tak, aby mohly být dotazy bez nejednoznačnosti.

V rámci reprezentace schématu s úplnými přesnostmi bude každý datový typ každé vlastnosti generovat sloupec pro tento datový typ. Každý z nich se počítá jako jedna z maximálních vlastností 1000.

Řekněme například, že se v transakčním úložišti vezme následující ukázkový dokument:

{
name: "John Doe",
age: 32,
profession: "Doctor",
address: {
  streetNo: 15850,
  streetName: "NE 40th St.",
  zip: 98052
},
salary: 1000000
}

Vlastnost list ve vnořeném objektu bude ve schématu analytického úložiště reprezentována streetNo address jako sloupec address.object.streetNo.int32 . Datový typ se přidá jako přípona ke sloupci. Pokud se tak do transakčního úložiště přidá jiný dokument, ve kterém je hodnota vlastnosti list "123" (všimněte si, že se jedná o řetězec), schéma analytického úložiště se automaticky vyvíjí, aniž by se změnil typ dříve zapsaného streetNo sloupce. Do analytického úložiště se přidá nový sloupec, ve kterém se uloží tato hodnota address.object.streetNo.string 123.

Mapování datového typu na příponu

Tady je mapa všech datových typů vlastností a jejich reprezentace přípon v analytickém úložiště:

• Očekávejte jiné chování s ohledem na explicitní null hodnoty:

  • Fondy Sparku v Azure Synapse budou číst tyto hodnoty jako 0 (nula).
  • SQL bez serveru v Azure Synapse načte tyto hodnoty jako NULL .

• Očekávejte jiné chování s ohledem na chybějící sloupce:

  • Fondy Sparku v Azure Synapse budou tyto sloupce představovat jako undefined .
  • SQL bez serveru v Azure Synapse budou tyto sloupce představovat jako NULL .

Nákladově efektivní archivace historických dat

Vrstvení dat označuje oddělení dat mezi infrastrukturami úložiště optimalizovanými pro různé scénáře. Tím se zlepší celkový výkon a nákladová efektivita koncového datového zásobníku. S analytickým úložištěm teď Azure Cosmos DB podporuje automatické vrstvení dat z transakčního úložiště do analytického úložiště s různými rozloženími dat. Díky analytickému úložišti optimalizovanému z hlediska nákladů na úložiště v porovnání s transakčním úložištěm můžete uchovávat mnohem delší přehled provozních dat pro historické analýzy.

Po povolení analytického úložiště můžete na základě potřeb uchovávání dat transakčních úloh nakonfigurovat vlastnost Transactional Store Time to Live (Transactional TTL) tak, aby se záznamy po určitém časovém období automaticky odstranily z transakčního úložiště. Podobně "Doba TTL analytického úložiště" umožňuje spravovat životní cyklus dat uchovávaných v analytickém úložiště nezávisle na transakčním úložiště. Povolením analytického úložiště a konfigurací vlastností hodnoty TTL můžete bezproblémově vrstvovat a definovat dobu uchovávání dat pro obě úložiště.

Globální distribuce

Pokud máte globálně distribuovaný účet Azure Cosmos DB, bude po povolení analytického úložiště pro kontejner dostupný ve všech oblastech tohoto účtu. Všechny změny provozních dat se globálně replikují ve všech oblastech. Analytické dotazy můžete efektivně spouštět na nejbližší regionální kopii vašich dat v Azure Cosmos DB.

Dělení

Dělení analytického úložiště je zcela nezávislé na dělení v transakčním úložiště. Ve výchozím nastavení nejsou data v analytickém úložiště rozdělená na oddíly. Pokud vaše analytické dotazy používají filtry často, můžete na základě těchto polí rozdělit oddíly, abyste měli lepší výkon dotazů. Další informace najdete v úvodu k vlastnímu dělení a v článku o konfiguraci vlastního dělení.

Zabezpečení

• Ověřování pomocí analytického úložiště je stejné jako transakční úložiště pro danou databázi. Pro ověřování můžete použít primární, sekundární klíče nebo klíče jen pro čtení. Můžete využít propojenou službu v Synapse Studio, abyste zabránili vkládání klíčů Azure Cosmos DB do poznámkových bloků Sparku. V Azure Synapse SQL bez serveru můžete pomocí přihlašovacích údajů SQL zabránit také vkládání klíčů Azure Cosmos DB do poznámkových bloků SQL. Přístup k těmto propojeným službám nebo k těmto SQL přihlašovací údaje jsou k dispozici každému, kdo má přístup k pracovnímu prostoru.

• Izolace sítě pomocí privátních koncových bodů – Přístup k datům v transakčním a analytickém úložiště můžete řídit nezávisle. Izolace sítě se provádí pomocí samostatných spravovaných privátních koncových bodů pro každé úložiště v rámci spravovaných virtuálních sítí Azure Synapse pracovních prostorech. Další informace najdete v článku Konfigurace privátních koncových bodů pro analytické úložiště.

• Šifrování dat pomocí klíčů spravovaných zákazníkem – data v transakčních a analytických úložištěch můžete bez problémů šifrovat pomocí stejných klíčů spravovaných zákazníkem, a to automatickým a transparentním způsobem. Azure Synapse Link podporuje pouze konfiguraci klíčů spravovaných zákazníkem pomocí spravované identity účtu Azure Cosmos DB. Před povolením odkazu na Azure Key Vault musíte nakonfigurovat spravovanou identitu vašeho účtu v zásadách Azure Synapse přístupu. Další informace najdete v článku Konfigurace klíčů spravovaných zákazníkem pomocí spravovaných identit účtů Azure Cosmos DB.

Podpora více Azure Synapse Analytics runtime

Analytické úložiště je optimalizované tak, aby poskytovalo škálovatelnost, elasticitu a výkon pro analytické úlohy bez závislosti na výpočetních běhech. Technologie úložiště je samoobslužně spravovaná, aby optimalizovala analytické úlohy bez ručního úsilí.

Oddělením analytického úložného systému od analytického výpočetního systému je možné současně dotazovat data v analytickém úložišti Azure Cosmos DB z různých analytických runtime podporovaných službou Azure Synapse Analytics. V současné době podporuje Azure Synapse Analytics úložiště Apache Spark a SQL s analytickým úložištěm Azure Cosmos DB.

Ceny

Analytické úložiště se řídí cenový model založený na spotřebě, za který se vám účtují poplatky:

• Storage: objem dat uchovávaných v analytickém úložiště každý měsíc včetně historických dat definovaných analytickou TTL.

• Analytické operace zápisu: plně spravovaná synchronizace aktualizací provozních dat do analytického úložiště z transakčního úložiště (automatická synchronizace)

• Analytické operace čtení: Operace čtení prováděné s analytickým úložištěm z Azure Synapse Analytics Sparku a bez serveru SQL spuštění fondu.

Ceny analytického úložiště jsou oddělené od cenového modelu transakčního úložiště. V analytickém obchodě neexistuje žádný koncept zřovaných RU. Úplné podrobnosti o cenovém modelu pro analytické úložiště najdete na stránce s cenami služby Azure Cosmos DB.

K datům v analytickém obchodě je možné přistupovat pouze přes Azure Synapse Link, který se provádí v prostředích runtime Azure Synapse Analytics: Azure Synapse Apache Spark fondy Azure Synapse bez serveru SQL fondy. Úplné Azure Synapse Analytics cenovém modelu pro přístup k datům v analytickém obchodě najdete na stránce s cenami.

Pokud chcete získat odhad nákladů na vysoké úrovni, abyste umožnili analytické úložiště v kontejneru Azure Cosmos DB, můžete z pohledu analytického úložiště použít Plánovač kapacity služby Azure Cosmos DB a získat odhad nákladů na analytické úložiště a operace zápisu. Náklady na operace analytického čtení závisí na charakteristikách analytických úloh, ale jako základní odhad je výsledkem prohledávání 1 TB dat v analytickém obchodě obvykle 130 000 analytických operací čtení a výsledkem jsou náklady ve výši 0,065 USD.

Time-to-Live analytického analytického času (TTL)

Analytická hodnota TTL pro kontejner určuje, jak dlouho se mají uchovávat data v analytickém úložišti.

Pokud je povolené analytické úložiště, vložení, aktualizace a odstranění provozních dat se automaticky synchronizují z transakčního úložiště do analytického úložiště bez ohledu na konfiguraci transakční hodnoty TTL. Uchovávání těchto provozních dat v analytickém úložiště je možné řídit hodnotou TTL analytického úložiště na úrovni kontejneru, jak je uvedeno níže:

Analytická TTL pro kontejner se nastaví pomocí AnalyticalStoreTimeToLiveInSeconds vlastnosti :

• Pokud je hodnota nastavená na 0, chybí (nebo je nastavená na hodnotu null): Analytické úložiště je zakázané a z transakčního úložiště do analytického úložiště se nereplikují žádná data.

• Pokud existuje a hodnota je nastavená na -1: Analytické úložiště uchovává všechna historická data bez ohledu na uchovávání dat v transakčním úložiště. Toto nastavení indikuje, že analytické úložiště má nekonečné uchovávání vašich provozních dat.

• Pokud existuje a hodnota je nastavená na kladné číslo "n": platnost položek v analytickém obchodě "n" sekund po času poslední změny v transakčním obchodě vyprší. Toto nastavení můžete využít, pokud chcete uchovávat provozní data po omezenou dobu v analytickém úložiště bez ohledu na uchovávání dat v transakčním úložiště.

Některé body ke zvážení:

• Po povolení analytického úložiště s hodnotou TTL analytického úložiště ho můžete později aktualizovat na jinou platnou hodnotu.
• I když je možné hodnotu TTL transakčního úložiště nastavit na úrovni kontejneru nebo položky, hodnotu TTL analytického úložiště je možné nastavit pouze na úrovni kontejneru.
• Pokud chcete dosáhnout delšího uchovávání provozních dat v analytickém úložiště, můžete nastavením hodnoty TTL analytického úložiště >= transakční hodnota TTL na úrovni kontejneru.
• Analytické úložiště je možné vytvořit tak, aby zrcadlí transakční úložiště nastavením hodnoty TTL analytického úložiště = transakční hodnoty TTL.

Povolení analytického úložiště pro kontejner:

• V Azure Portal nastavení analytické hodnoty TTL (když je tato možnost zapnutá) na výchozí hodnotu -1. Tuto hodnotu můžete změnit na n sekund tak, že přejdete do nastavení kontejneru v části Průzkumník dat.

• Ze sady SDK pro správu Azure, sad SDK služby Azure Cosmos DB, PowerShellu nebo rozhraní příkazového řádku je možné povolit možnost analytické hodnoty TTL tak, že ji nastavíte na -1 nebo n sekund.

Další informace najdete v tématu konfigurace analytického TTL pro kontejner.

Další kroky

Další informace najdete v následujících dokumentacích:

• Azure Synapse Link pro Azure Cosmos DB

• V modulu Learn se dozvíte, jak navrhnout hybridní transakční a analytické zpracování pomocí Azure Synapse Analytics

• Začínáme s Azure Synapse Linkem pro Azure Cosmos DB

• Nejčastější dotazy k Synapse Linku pro Azure Cosmos DB

• Případy použití Azure Synapse Linku pro Azure Cosmos DB