Modelování dat ve službě Azure Cosmos DB

  • Článek

PLATÍ PRO: NoSQL

I když databáze bez schématu, jako je Azure Cosmos DB, velmi usnadňují ukládání a dotazování nestrukturovaných a částečně strukturovaných dat, měli byste se nad datovým modelem zamyslet, abyste službu získali na maximum z hlediska výkonu, škálovatelnosti a nejnižších nákladů.

Jak se budou data ukládat? Jak bude vaše aplikace načítat data a dotazovat se na data? Je vaše aplikace zatížená čtením, nebo zápisem?

Po přečtení tohoto článku budete moct odpovědět na následující otázky:

  • Co je modelování dat a proč by mě to mělo zajímat?
  • Jak se modelování dat ve službě Azure Cosmos DB liší od relační databáze?
  • Návody vyjádřit datové relace v nerelační databázi?
  • Kdy mám vložit data a kdy je propojit?

Čísla ve formátu JSON

Azure Cosmos DB ukládá dokumenty ve formátu JSON. To znamená, že je nutné pečlivě určit, jestli je nutné čísla převést na řetězce, než je uložíte do formátu JSON, nebo ne. Všechna čísla by měla být v ideálním případě převedena na String, pokud je možné, že jsou mimo hranice čísel s dvojitou přesností podle IEEE 754 binary64. Specifikace JSON zdůvodní, proč je použití čísel mimo tuto hranici obecně špatným postupem ve formátu JSON kvůli pravděpodobně problémům s interoperabilitou. Tyto aspekty jsou relevantní zejména pro sloupec s klíčem oddílu, protože je neměnný a vyžaduje migraci dat, která ho později změní.

Vložení dat

Když začnete modelovat data ve službě Azure Cosmos DB, zkuste s entitami zacházet jako s samostatnými položkami reprezentovanými jako dokumenty JSON.

Pro porovnání se nejprve podíváme, jak bychom mohli modelovat data v relační databázi. Následující příklad ukazuje, jak může být osoba uložena v relační databázi.

Model relační databáze

Strategií při práci s relačními databázemi je normalizovat všechna data. Normalizace dat obvykle zahrnuje převzetí entity, například osoby, a jejich rozdělení do samostatných komponent. Ve výše uvedeném příkladu může mít osoba více záznamů podrobností o kontaktu a několik záznamů adresy. Kontaktní údaje je možné dále rozdělit extrahováním společných polí, jako je typ. Totéž platí pro adresu, každý záznam může být typu Home nebo Business.

Hlavním předpokladem při normalizaci dat je vyhnout se ukládání redundantních dat do každého záznamu a odkazovat spíše na data. Pokud chcete v tomto příkladu přečíst osobu se všemi jejich kontaktními údaji a adresami, musíte pomocí funkce JOINS efektivně sestavit (nebo denormalizovat) data za běhu.

SELECT p.FirstName, p.LastName, a.City, cd.Detail
FROM Person p
JOIN ContactDetail cd ON cd.PersonId = p.Id
JOIN ContactDetailType cdt ON cdt.Id = cd.TypeId
JOIN Address a ON a.PersonId = p.Id

K aktualizaci kontaktních údajů a adres jednotlivých osob se vyžadují operace zápisu do mnoha jednotlivých tabulek.

Teď se podíváme na to, jak bychom modelovali stejná data jako samostatná entita ve službě Azure Cosmos DB.

{
    "id": "1",
    "firstName": "Thomas",
    "lastName": "Andersen",
    "addresses": [
        {
            "line1": "100 Some Street",
            "line2": "Unit 1",
            "city": "Seattle",
            "state": "WA",
            "zip": 98012
        }
    ],
    "contactDetails": [
        {"email": "thomas@andersen.com"},
        {"phone": "+1 555 555-5555", "extension": 5555}
    ]
}

Pomocí výše uvedeného postupu jsme denormalizovali záznam osoby tím, že jsme do jednoho dokumentu JSONvložili všechny informace související s touto osobou, například její kontaktní údaje a adresy. Kromě toho, protože nejsme omezeni na pevné schéma, máme flexibilitu dělat věci, jako je mít kontaktní údaje z různých obrazců zcela.

Načtení úplného záznamu osoby z databáze je nyní jedinou operací čtení pro jeden kontejner a pro jednu položku. Aktualizace kontaktních údajů a adres záznamu osoby je také jedinou operací zápisu do jedné položky.

Při denormalizaci dat může být nutné, aby vaše aplikace vydála méně dotazů a aktualizací, aby se dokončily běžné operace.

Kdy vložit

Obecně platí, že vložené datové modely používejte v případě, že:

  • Mezi entitami jsou obsažené vztahy.
  • Mezi entitami existují relace 1:N .
  • Vložená data se často mění.
  • Existují vložená data, která se nezvětšují bez vazby.
  • K dispozici jsou vložená data, která se často dotazuje společně.

Poznámka

Obvykle denormalizované datové modely poskytují lepší výkon při čtení .

Kdy nevkládat

I když ve službě Azure Cosmos DB platí pravidlo denormalizovat všechno a vložit všechna data do jedné položky, může to vést k některým situacím, kterým byste se měli vyhnout.

Vezměte tento fragment kódu JSON.

{
    "id": "1",
    "name": "What's new in the coolest Cloud",
    "summary": "A blog post by someone real famous",
    "comments": [
        {"id": 1, "author": "anon", "comment": "something useful, I'm sure"},
        {"id": 2, "author": "bob", "comment": "wisdom from the interwebs"},
        …
        {"id": 100001, "author": "jane", "comment": "and on we go ..."},
        …
        {"id": 1000000001, "author": "angry", "comment": "blah angry blah angry"},
        …
        {"id": ∞ + 1, "author": "bored", "comment": "oh man, will this ever end?"},
    ]
}

Takto by vypadala entita příspěvku s vloženými komentáři, pokud bychom modelovali typický systém blogu nebo CMS. Problémem v tomto příkladu je, že pole komentářů je nevázané, což znamená, že neexistuje žádné (praktické) omezení počtu komentářů, které může mít jeden příspěvek. To může být problém, protože velikost položky se může nekonečně zvětšovat, takže je návrh, kterým byste se měli vyhnout.

S tím, jak velikost položky roste, bude mít vliv na možnost přenosu dat přes drát a bude mít vliv na čtení a aktualizaci položky ve velkém měřítku.

V takovém případě by bylo lepší zvážit následující datový model.

Post item:
{
    "id": "1",
    "name": "What's new in the coolest Cloud",
    "summary": "A blog post by someone real famous",
    "recentComments": [
        {"id": 1, "author": "anon", "comment": "something useful, I'm sure"},
        {"id": 2, "author": "bob", "comment": "wisdom from the interwebs"},
        {"id": 3, "author": "jane", "comment": "....."}
    ]
}

Comment items:
[
    {"id": 4, "postId": "1", "author": "anon", "comment": "more goodness"},
    {"id": 5, "postId": "1", "author": "bob", "comment": "tails from the field"},
    ...
    {"id": 99, "postId": "1", "author": "angry", "comment": "blah angry blah angry"},
    {"id": 100, "postId": "2", "author": "anon", "comment": "yet more"},
    ...
    {"id": 199, "postId": "2", "author": "bored", "comment": "will this ever end?"}   
]

Tento model má dokument pro každý komentář s vlastností, která obsahuje identifikátor příspěvku. Díky tomu můžou příspěvky obsahovat libovolný počet komentářů a můžou se efektivně rozšiřovat. Uživatelé, kteří chtějí zobrazit více než nejnovější komentáře, se do tohoto kontejneru dotazují a předávají postId, což by měl být klíč oddílu pro kontejner komentářů.

Dalším případem, kdy vkládání dat není vhodné, je, když se vložená data často používají napříč položkami a často se mění.

Vezměte tento fragment kódu JSON.

{
    "id": "1",
    "firstName": "Thomas",
    "lastName": "Andersen",
    "holdings": [
        {
            "numberHeld": 100,
            "stock": { "symbol": "zbzb", "open": 1, "high": 2, "low": 0.5 }
        },
        {
            "numberHeld": 50,
            "stock": { "symbol": "xcxc", "open": 89, "high": 93.24, "low": 88.87 }
        }
    ]
}

To může představovat akciové portfolio osoby. Rozhodli jsme se vložit informace o akciích do každého dokumentu portfolia. V prostředí, kde se související data často mění, například aplikace pro obchodování s akciemi, vkládání dat, která se často mění, bude znamenat, že každý dokument portfolia neustále aktualizujete při každém obchodování s akciemi.

Akcie zbzb mohou být obchodovány mnoho setkrát za jeden den a tisíce uživatelů mohou mít zbzb ve svém portfoliu. S datovým modelem, jako je výše uvedený, bychom museli aktualizovat mnoho tisíc dokumentů portfolia mnohokrát denně, což vede k systému, který nebude dobře škálovat.

Referenční data

Vkládání dat funguje dobře v mnoha případech, ale existují scénáře, kdy denormalizace dat způsobí více problémů, než stojí za to. Tak co teď děláme?

Relační databáze nejsou jediným místem, kde můžete vytvářet relace mezi entitami. V databázi dokumentů můžete mít informace v jednom dokumentu, které se vztahují k datům v jiných dokumentech. Nedoporučujeme vytvářet systémy, které by byly vhodnější pro relační databázi ve službě Azure Cosmos DB nebo jakoukoli jinou databázi dokumentů, ale jednoduché relace jsou v pořádku a můžou být užitečné.

V níže uvedeném kódu JSON jsme se rozhodli použít příklad akciového portfolia z předchozích verzí, ale tentokrát místo vložení odkazujeme na položku akcií v portfoliu. Když se skladová položka v průběhu dne často mění, jediný dokument, který je potřeba aktualizovat, je jediný skladový dokument.

Person document:
{
    "id": "1",
    "firstName": "Thomas",
    "lastName": "Andersen",
    "holdings": [
        { "numberHeld":  100, "stockId": 1},
        { "numberHeld":  50, "stockId": 2}
    ]
}

Stock documents:
{
    "id": "1",
    "symbol": "zbzb",
    "open": 1,
    "high": 2,
    "low": 0.5,
    "vol": 11970000,
    "mkt-cap": 42000000,
    "pe": 5.89
},
{
    "id": "2",
    "symbol": "xcxc",
    "open": 89,
    "high": 93.24,
    "low": 88.87,
    "vol": 2970200,
    "mkt-cap": 1005000,
    "pe": 75.82
}

Okamžitým nevýhodou tohoto přístupu je však to, že je vaše aplikace povinna zobrazovat informace o každé akcii, která je držena při zobrazení portfolia osoby; v takovém případě byste museli provést několik cest do databáze, abyste načetli informace pro každý dokument. Tady jsme se rozhodli zlepšit efektivitu operací zápisu, ke kterým dochází často během dne, ale zároveň jsou ohroženy operace čtení, které mohou mít menší dopad na výkon tohoto konkrétního systému.

Poznámka

Normalizované datové modely můžou vyžadovat další doby odezvy na server.

A co cizí klíče?

Vzhledem k tomu, že v současné době neexistuje koncept omezení, cizího klíče nebo jiného, jsou všechny vztahy mezi dokumenty ve skutečnosti "slabými odkazy" a nebudou ověřeny samotnou databází. Pokud chcete zajistit, aby data, na která dokument odkazuje, skutečně existují, musíte to udělat ve své aplikaci nebo pomocí triggerů na straně serveru nebo uložených procedur ve službě Azure Cosmos DB.

Kdy odkazovat

Obecně platí, že normalizované datové modely používejte v případě, že:

  • Reprezentace relací 1:N .
  • Reprezentace relací M:N .
  • Související data se často mění.
  • Odkazovaná data můžou být nevázaná.

Poznámka

Normalizace obvykle poskytuje lepší výkon zápisu .

Kam mám vztah umístit?

Růst relace pomůže určit, do kterého dokumentu se má odkaz uložit.

Pokud se podíváme na níže uvedený kód JSON, který modeluje vydavatele a knihy.

Publisher document:
{
    "id": "mspress",
    "name": "Microsoft Press",
    "books": [ 1, 2, 3, ..., 100, ..., 1000]
}

Book documents:
{"id": "1", "name": "Azure Cosmos DB 101" }
{"id": "2", "name": "Azure Cosmos DB for RDBMS Users" }
{"id": "3", "name": "Taking over the world one JSON doc at a time" }
...
{"id": "100", "name": "Learn about Azure Cosmos DB" }
...
{"id": "1000", "name": "Deep Dive into Azure Cosmos DB" }

Pokud je počet knih na vydavatele malý s omezeným nárůstem, může být užitečné uložit odkaz na knihu do dokumentu vydavatele. Pokud je však počet knih na vydavatele nevázaný, pak by tento datový model vedl k proměnlivým a rostoucím polím, jako v ukázkovém dokumentu vydavatele výše.

Když něco změníte, vznikne model, který stále představuje stejná data, ale teď se těmto velkým proměnlivým kolekcím vyhýbá.

Publisher document:
{
    "id": "mspress",
    "name": "Microsoft Press"
}

Book documents:
{"id": "1","name": "Azure Cosmos DB 101", "pub-id": "mspress"}
{"id": "2","name": "Azure Cosmos DB for RDBMS Users", "pub-id": "mspress"}
{"id": "3","name": "Taking over the world one JSON doc at a time", "pub-id": "mspress"}
...
{"id": "100","name": "Learn about Azure Cosmos DB", "pub-id": "mspress"}
...
{"id": "1000","name": "Deep Dive into Azure Cosmos DB", "pub-id": "mspress"}

Ve výše uvedeném příkladu jsme v dokumentu vydavatele vynechali kolekci bez vazby. Místo toho máme odkaz na vydavatele v každém dokumentu knihy.

Návody modelovat relace M:N?

V relační databázi se relace M:N často modelují pomocí tabulek spojení, které jenom spojují záznamy z jiných tabulek.

Spojení tabulek

Můžete být v pokušení replikovat totéž pomocí dokumentů a vytvořit datový model podobný následujícímu.

Author documents:
{"id": "a1", "name": "Thomas Andersen" }
{"id": "a2", "name": "William Wakefield" }

Book documents:
{"id": "b1", "name": "Azure Cosmos DB 101" }
{"id": "b2", "name": "Azure Cosmos DB for RDBMS Users" }
{"id": "b3", "name": "Taking over the world one JSON doc at a time" }
{"id": "b4", "name": "Learn about Azure Cosmos DB" }
{"id": "b5", "name": "Deep Dive into Azure Cosmos DB" }

Joining documents:
{"authorId": "a1", "bookId": "b1" }
{"authorId": "a2", "bookId": "b1" }
{"authorId": "a1", "bookId": "b2" }
{"authorId": "a1", "bookId": "b3" }

To by fungovalo. Načtení buď autora s jeho knihami, nebo načtení knihy jejím autorem, by však vždy vyžadovalo alespoň dva další dotazy vůči databázi. Jeden dotaz na spojování dokumentu a pak další dotaz pro načtení skutečně připojeného dokumentu.

Pokud toto spojení spojuje pouze dva části dat, proč ho úplně neodhodit? Představte si následující příklad.

Author documents:
{"id": "a1", "name": "Thomas Andersen", "books": ["b1", "b2", "b3"]}
{"id": "a2", "name": "William Wakefield", "books": ["b1", "b4"]}

Book documents:
{"id": "b1", "name": "Azure Cosmos DB 101", "authors": ["a1", "a2"]}
{"id": "b2", "name": "Azure Cosmos DB for RDBMS Users", "authors": ["a1"]}
{"id": "b3", "name": "Learn about Azure Cosmos DB", "authors": ["a1"]}
{"id": "b4", "name": "Deep Dive into Azure Cosmos DB", "authors": ["a2"]}

Kdybych měl autora, okamžitě vím, které knihy napsali, a naopak, kdybych měl dokument knihy načtený, znal bych ID autorů. Tím se tento zprostředkující dotaz na tabulku join uloží a sníží se tak počet odezvy serveru, které vaše aplikace musí provést.

Hybridní datové modely

Teď jsme se podívali na vkládání (nebo denormalizaci) a odkazování na (neboli normalizaci) dat. Každý přístup má nevýhody a kompromisy.

Nemusí to být vždy ani -nebo, nebojte se, aby si to trochu pomíchal.

V závislosti na konkrétních vzorcích využití a úlohách vaší aplikace může být vhodné kombinovat vložená a odkazovaná data, která by mohla vést k jednodušší aplikační logice s menším počtem odezvy serveru při zachování dobré úrovně výkonu.

Podívejte se na následující kód JSON.

Author documents:
{
    "id": "a1",
    "firstName": "Thomas",
    "lastName": "Andersen",
    "countOfBooks": 3,
    "books": ["b1", "b2", "b3"],
    "images": [
        {"thumbnail": "https://....png"}
        {"profile": "https://....png"}
        {"large": "https://....png"}
    ]
},
{
    "id": "a2",
    "firstName": "William",
    "lastName": "Wakefield",
    "countOfBooks": 1,
    "books": ["b1"],
    "images": [
        {"thumbnail": "https://....png"}
    ]
}

Book documents:
{
    "id": "b1",
    "name": "Azure Cosmos DB 101",
    "authors": [
        {"id": "a1", "name": "Thomas Andersen", "thumbnailUrl": "https://....png"},
        {"id": "a2", "name": "William Wakefield", "thumbnailUrl": "https://....png"}
    ]
},
{
    "id": "b2",
    "name": "Azure Cosmos DB for RDBMS Users",
    "authors": [
        {"id": "a1", "name": "Thomas Andersen", "thumbnailUrl": "https://....png"},
    ]
}

Tady jsme (většinou) postupovali podle vloženého modelu, kdy jsou data z jiných entit vložená do dokumentu nejvyšší úrovně, ale odkazují se na jiná data.

Když se podíváte na dokument knihy, můžeme vidět několik zajímavých polí, když se podíváme na pole autorů. id Existuje pole, které používáme k odkazování na dokument autora, což je standardní postup v normalizovaném modelu, ale pak máme name také a thumbnailUrl. Mohli jsme uvíznout id a nechat aplikaci získat další potřebné informace z příslušného dokumentu autora pomocí "odkazu", ale protože naše aplikace zobrazuje jméno autora a miniaturu obrázku s každou zobrazenou knihou, můžeme uložit cestu na server podle knihy v seznamu tím, že denormalizujeme některá data od autora.

Jistě, pokud by se změnilo jméno autora nebo chtěl aktualizovat svoji fotku, museli bychom aktualizovat každou knihu, kterou kdy publikoval, ale pro naši aplikaci, na základě předpokladu, že autoři často nemění svá jména, je to přijatelné rozhodnutí o návrhu.

V tomto příkladu jsou předem vypočítané agregované hodnoty, které šetří nákladné zpracování při operaci čtení. V tomto příkladu jsou některá data vložená do dokumentu autora data, která se počítají za běhu. Při každém publikování nové knihy se vytvoří dokument knihy a pole countOfBooks se nastaví na počítanou hodnotu na základě počtu dokumentů knih, které existují pro konkrétního autora. Tato optimalizace by byla dobrá v systémech náročných na čtení, kde si za účelem optimalizace čtení můžeme dovolit provádět výpočty zápisů.

Možnost mít model s předem počítanými poli je možná, protože Azure Cosmos DB podporuje transakce s více dokumenty. Mnoho úložišť NoSQL nemůže provádět transakce napříč dokumenty, a proto kvůli tomuto omezení podporuje rozhodnutí o návrhu, jako je "vždy vkládat vše". Se službou Azure Cosmos DB můžete použít triggery na straně serveru nebo uložené procedury, které vkládají knihy a aktualizují autory, a to vše v rámci transakce ACID. Teď nemusíte vkládat všechno do jednoho dokumentu, abyste měli jistotu, že vaše data zůstanou konzistentní.

Rozlišení různých typů dokumentů

V některých scénářích můžete chtít kombinovat různé typy dokumentů ve stejné kolekci; Obvykle se jedná o případ, kdy chcete, aby bylo ve stejném oddílu více souvisejících dokumentů. Knihy i recenze knih můžete například umístit do stejné kolekce a rozdělit je podle bookId. V takovém případě obvykle chcete do dokumentů přidat pole, které identifikuje jejich typ, aby se odlišily.

Book documents:
{
    "id": "b1",
    "name": "Azure Cosmos DB 101",
    "bookId": "b1",
    "type": "book"
}

Review documents:
{
    "id": "r1",
    "content": "This book is awesome",
    "bookId": "b1",
    "type": "review"
},
{
    "id": "r2",
    "content": "Best book ever!",
    "bookId": "b1",
    "type": "review"
}

Azure Synapse Link pro Azure Cosmos DB je funkce HTAP (Hybrid Transactional and Analytical Processing) nativní pro cloud, která umožňuje spouštět analýzy téměř v reálném čase nad provozními daty ve službě Azure Cosmos DB. Azure Synapse Link vytváří úzkou bezproblémovou integraci mezi službou Azure Cosmos DB a Azure Synapse Analytics.

K této integraci dochází prostřednictvím analytického úložiště Azure Cosmos DB, což je sloupcová reprezentace transakčních dat, která umožňuje rozsáhlé analýzy bez jakéhokoli dopadu na vaše transakční úlohy. Toto analytické úložiště je vhodné pro rychlé a nákladově efektivní dotazy na velké sady provozních dat bez kopírování dat a dopadu na výkon transakčních úloh. Když vytvoříte kontejner s povoleným analytickým úložištěm nebo povolíte analytické úložiště u existujícího kontejneru, všechna vložení, aktualizace a odstranění transakcí se synchronizují s analytickým úložištěm téměř v reálném čase, nejsou potřeba žádné úlohy kanálu změn ani ETL.

S Azure Synapse Link se teď můžete přímo připojit ke kontejnerům Azure Cosmos DB z Azure Synapse Analytics a přistupovat k analytickému úložišti bez nákladů na jednotky žádostí (jednotky žádostí). Azure Synapse Analytics v současné době podporuje Azure Synapse Link se Synapse Apache Sparkem a bezserverovými fondy SQL. Pokud máte globálně distribuovaný účet služby Azure Cosmos DB, bude po povolení analytického úložiště pro kontejner dostupný ve všech oblastech pro tento účet.

Automatické odvození schématu analytického úložiště

Zatímco transakční úložiště Azure Cosmos DB se považuje za řádková částečně strukturovaná data, analytické úložiště má sloupcový a strukturovaný formát. Tento převod se automaticky provede pro zákazníky pomocí pravidel odvozování schématu pro analytické úložiště. Proces převodu má omezení: maximální počet vnořených úrovní, maximální počet vlastností, nepodporované datové typy a další.

Poznámka

V kontextu analytického úložiště považujeme za vlastnost následující struktury:

  • Páry JSON "elementy" nebo "řetězec-hodnota oddělené znakem : ".
  • Objekty JSON oddělené a {}.
  • Pole JSON oddělená a [].

Pomocí následujících technik můžete minimalizovat dopad převodů odvozování schématu a maximalizovat analytické možnosti.

Normalizace

Normalizace začíná být bezvýznamná, protože s Azure Synapse Link se můžete připojit mezi kontejnery pomocí T-SQL nebo Spark SQL. Očekávané výhody normalizace:

  • Menší nároky na data v transakčním i analytickém úložišti
  • Menší transakce.
  • Méně vlastností na dokument
  • Datové struktury s menším počtem vnořených úrovní

Všimněte si, že tyto poslední dva faktory, méně vlastností a méně úrovní, pomáhají s výkonem analytických dotazů, ale také snižují pravděpodobnost, že části vašich dat nebudou reprezentovány v analytickém úložišti. Jak je popsáno v článku o pravidlech automatického odvozování schématu, existují omezení počtu úrovní a vlastností, které jsou reprezentovány v analytickém úložišti.

Dalším důležitým faktorem normalizace je to, že bezserverové fondy SQL v Azure Synapse podporují sady výsledků až s 1000 sloupci a do tohoto limitu se také započítávají vnořené sloupce. Jinými slovy, analytické úložiště i bezserverové fondy Synapse SQL mají limit 1 000 vlastností.

Co ale dělat, protože denormalizace je důležitou technikou modelování dat ve službě Azure Cosmos DB? Odpověď je, že musíte najít správnou rovnováhu pro vaše transakční a analytické úlohy.

Partition Key (Klíč oddílu)

Klíč oddílu (PK) služby Azure Cosmos DB se nepoužívá v analytickém úložišti. Teď můžete použít vlastní dělení analytického úložiště na kopie analytického úložiště pomocí libovolného pk. Z důvodu této izolace můžete pro transakční data zvolit infrastrukturu veřejných klíčů se zaměřením na příjem dat a čtení bodů, zatímco dotazy napříč oddíly můžete provádět pomocí Azure Synapse Link. Podívejme se na příklad:

V hypotetické globální situaci device id IoT je dobrou infrastrukturou pk, protože všechna zařízení mají podobný objem dat a s tím nebudete mít problém s horkými oddíly. Pokud ale chcete analyzovat data z více než jednoho zařízení, například "všechna data ze včerejška" nebo "součty za město", můžete mít problémy, protože se jedná o dotazy napříč oddíly. Tyto dotazy můžou poškodit transakční výkon, protože ke spuštění využívají část propustnosti v jednotkách žádostí. S Azure Synapse Link ale můžete tyto analytické dotazy spouštět bez nákladů na jednotky žádostí. Sloupcový formát analytického úložiště je optimalizovaný pro analytické dotazy a Azure Synapse Link tuto charakteristiku používá k tomu, aby umožnil skvělý výkon s moduly runtime Azure Synapse Analytics.

Názvy datových typů a vlastností

Článek o pravidlech automatického odvození schématu obsahuje seznam podporovaných datových typů. I když nepodporovaný datový typ blokuje reprezentaci v analytickém úložišti, podporované datové typy můžou moduly runtime Azure Synapse zpracovávat odlišně. Jedním z příkladů je: Při použití řetězců DateTime, které dodržují standard STANDARD ISO 8601 UTC, budou fondy Sparku v Azure Synapse tyto sloupce představovat jako řetězce a bezserverové fondy SQL v Azure Synapse budou tyto sloupce představovat jako varchar(8000).

Další výzvou je, že Azure Synapse Spark nepřijímá všechny znaky. I když jsou prázdné znaky akceptované, znaky jako dvojtečka, čárka a čárka ne. Řekněme, že dokument má vlastnost s názvem "Jméno, příjmení". Tato vlastnost bude reprezentována v analytickém úložišti a bezserverový fond Synapse SQL ji může bez problémů číst. Protože je ale v analytickém úložišti, Azure Synapse Spark nemůže z analytického úložiště číst žádná data, včetně všech ostatních vlastností. Na konci dne nemůžete použít Azure Synapse Spark, pokud máte jednu vlastnost používající nepodporované znaky v jejich názvech.

Zploštělování dat

Všechny vlastnosti na kořenové úrovni dat služby Azure Cosmos DB budou v analytickém úložišti reprezentovány jako sloupec a vše ostatní, co je v hlubších úrovních datového modelu dokumentu, bude reprezentováno jako JSON, a to i ve vnořených strukturách. Vnořené struktury vyžadují dodatečné zpracování z Azure Synapse modulů runtime, aby zploštěly data ve strukturovaném formátu, což může být ve scénářích s velkými objemy dat výzvou.

Následující dokument bude obsahovat pouze dva sloupce v analytickém úložišti id a contactDetails. Všechna ostatní data email a phonebudou vyžadovat dodatečné zpracování prostřednictvím funkcí SQL, aby bylo možné je číst jednotlivě.


{
    "id": "1",
    "contactDetails": [
        {"email": "thomas@andersen.com"},
        {"phone": "+1 555 555-5555"}
    ]
}

Následující dokument bude obsahovat tři sloupce v analytickém úložišti: id, emaila phone. Všechna data jsou přímo přístupná jako sloupce.


{
    "id": "1",
    "email": "thomas@andersen.com",
    "phone": "+1 555 555-5555"
}

Vrstvení dat

Azure Synapse Link umožňuje snížit náklady z následujících hledisek:

  • Méně dotazů spuštěných v transakční databázi
  • Pk je optimalizovaná pro příjem dat a čtení bodů, snižuje nároky na data, scénáře horkých oddílů a rozdělení oddílů.
  • Vrstvení dat od analytické hodnoty time-to-live (attl) je nezávislé na hodnotě TTTL (Time to Live). Transakční data můžete v transakčním úložišti uchovávat několik dní, týdnů, měsíců a v analytickém úložišti je uchovávat roky nebo navěky. Sloupcový formát analytického úložiště přináší přirozenou kompresi dat od 50 % až po 90 %. A jeho náklady na GB jsou přibližně 10 % skutečné ceny transakčního úložiště. Další informace o aktuálních omezeních zálohování najdete v přehledu analytického úložiště.
  • Ve vašem prostředí nejsou spuštěné žádné úlohy ETL, což znamená, že pro ně nemusíte zřizovat jednotky žádostí.

Řízená redundance

Jedná se o skvělou alternativu pro situace, kdy datový model již existuje a nejde ho změnit. A stávající datový model se nehodí do analytického úložiště kvůli pravidlům automatického odvozování schématu, jako je limit vnořených úrovní nebo maximální počet vlastností. Pokud je to váš případ, můžete pomocí kanálu změn služby Azure Cosmos DB replikovat data do jiného kontejneru a použít požadované transformace pro datový model Azure Synapse Link. Podívejme se na příklad:

Scenario

Kontejner CustomersOrdersAndItems slouží k ukládání on-line objednávek, včetně podrobností o zákazníkovi a položkách: fakturační adresa, doručovací adresa, způsob doručení, stav doručení, cena položek atd. Je reprezentováno pouze prvních 1000 vlastností a do analytického úložiště nejsou zahrnuty klíčové informace, které blokují využití Azure Synapse Linku. Kontejner obsahuje DATABÁZE záznamů, není možné změnit aplikaci a přemodelovat data.

Další perspektivou problému je objem velkých objemů dat. Analytické oddělení neustále používá miliardy řádků, což jim brání v použití tttl k odstranění starých dat. Udržování celé historie dat v transakční databázi z důvodu analytických potřeb je nutí neustále zvyšovat zřizování jednotek žádostí, což má vliv na náklady. Transakční a analytické úlohy soupeří o stejné prostředky ve stejnou dobu.

Co dělat?

Řešení s kanálem změn

  • Technický tým se rozhodl použít kanál změn k naplnění tří nových kontejnerů: Customers, Ordersa Items. Kanál změn normalizuje a zploštěluje data. Z datového modelu se odeberou nepotřebné informace a každý kontejner má téměř 100 vlastností, aby se zabránilo ztrátě dat kvůli omezením automatického odvozování schématu.
  • Tyto nové kontejnery mají povolené analytické úložiště a analytické oddělení teď ke čtení dat používá Synapse Analytics, což snižuje využití jednotek žádostí, protože analytické dotazy probíhají v Synapse Apache Sparku a bezserverových fondech SQL.
  • Kontejner CustomersOrdersAndItems teď má nastavenou hodnotu tttl tak, aby se data uchovála jenom po dobu šesti měsíců, což umožňuje snížení využití dalších jednotek žádostí, protože ve službě Azure Cosmos DB je minimálně 10 jednotek žádostí na GB. Méně dat, méně jednotek žádostí.

Shrnutí

Nejdůležitějšími poznatky z tohoto článku je pochopit, že modelování dat ve světě, který neobsahuje schémata, je stejně důležité jako kdy dřív.

Stejně jako neexistuje jediný způsob, jak znázorňovat část dat na obrazovce, neexistuje jediný způsob, jak data modelovat. Potřebujete porozumět aplikaci a tomu, jak bude data vytvářet, využívat a zpracovávat. Pomocí některých zde uvedených pokynů pak můžete nastavit vytvoření modelu, který řeší okamžité potřeby vaší aplikace. Když se vaše aplikace potřebují změnit, můžete využít flexibilitu databáze bez schématu k přijetí této změny a snadnému vývoji datového modelu.

Další kroky