Sdílet prostřednictvím

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

  • Článek

PLATÍ PRO: NoSQL

Zatímco databáze bez schématu, jako je Azure Cosmos DB, usnadňují ukládání a dotazování nestrukturovaných a částečně strukturovaných dat, měli byste trávit nějaký čas přemýšlet o datovém modelu, abyste získali většinu služby z hlediska výkonu a škálovatelnosti a nejnižších nákladů.

Jak se budou ukládat data? Jak bude vaše aplikace načítat a dotazovat data? Je vaše aplikace náročné na čtení nebo zápis?

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č je důležité?
  • 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 vložím data a kdy se připojím k datům?

Čí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é před jejich uložením do formátu JSON převést čísla na řetězce. Všechna čísla by měla být v ideálním případě převedena na String, pokud existuje šance, že jsou mimo hranice dvojitých přesností podle IEEE 754 binary64. Specifikace Json označuje důvody, proč použití čísel mimo tuto hranici obecně představuje špatný postup ve formátu JSON kvůli pravděpodobným problémům s interoperabilitou. Tyto obavy jsou zvláště důležité pro sloupec klíče oddílu, protože je neměnný a vyžaduje, aby se migrace dat později změnila.

Vložení dat

Když začnete modelovat data ve službě Azure Cosmos DB, zkuste s entitami pracovat jako s položkami, které jsou v samostatném formátu reprezentované jako dokumenty JSON.

Nejprve se podíváme, jak můžeme 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 vaše data. Normalizace dat obvykle zahrnuje převzetí entity, jako je osoba, a jejich rozdělení do samostatných komponent. V tomto příkladu může mít osoba více záznamů podrobností o kontaktu a více záznamů adres. Podrobnosti o kontaktu je možné dále rozdělit extrahováním běžných polí, jako je typ. Totéž platí pro adresu, každý záznam může být typu Home nebo Business.

Průvodcem při normalizaci dat je zabránit ukládání redundantních dat do každého záznamu a spíše odkazovat na data. V tomto příkladu potřebujete ke čtení osoby se všemi kontaktními údaji a adresami použít JOINS k efektivnímu vytváření (nebo denormalizaci) dat 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

Operace zápisu napříč mnoha jednotlivými tabulkami se vyžadují k aktualizaci kontaktních údajů a adres jedné osoby.

Teď se podíváme na to, jak bychom modeloval 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í tohoto přístupu jsme denormalizovali záznam osoby vložením všech informací souvisejících s touto osobou, jako jsou jejich kontaktní údaje a adresy, do jednoho dokumentu JSON. Vzhledem k tomu, že nejsme omezeni na pevné schéma, máme flexibilitu provádět věci, jako je třeba úplné kontaktní údaje různých obrazců.

Načtení kompletního záznamu osoby z databáze je nyní jedinou operací čtení v jednom kontejneru a pro jednu položku. Aktualizace kontaktních údajů a adres záznamu osoby je také jedna operace zápisu s jednou položkou.

Díky denormalizaci dat může vaše aplikace potřebovat vydávat méně dotazů a aktualizací, aby mohla dokončit běžné operace.

Kdy vložit

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

  • Mezi entitami jsou obsažené vztahy.
  • Mezi entitami existuje vztah 1:1 .
  • Vložená data se mění zřídka.
  • Vložená data se nezvětšují bez vazby.
  • K dispozici jsou vložená data, na která se často dotazuje.

Poznámka:

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

Kdy se neskládají

I když pravidlo palce ve službě Azure Cosmos DB je denormalizovat všechno a vkládat 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?"},
    ]
}

Může se jednat o to, jak by entita post s vloženými komentáři vypadala, kdybysme modelovali typický blog nebo systém CMS. Problém s tímto příkladem je, že pole komentářů není nevázané, což znamená, že neexistuje žádný (praktický) limit počtu komentářů, které může mít libovolný příspěvek. Může se to stát problémem, protože velikost položky může být nekonečně velká, 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 přenos dat přes drát a čtení a aktualizaci položky ve velkém měřítku.

V tomto 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 efektivně se zvětšovat. Uživatelé, kteří chtějí zobrazit více než nejnovější komentáře, by dotazoval tento kontejner a předal 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 by mohlo představovat portfolio akcií 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í, jako je například aplikace burzovního obchodování, vkládání dat, která se často mění, znamená, že neustále aktualizujete každý dokument portfolia pokaždé, když se obchoduje akcie.

Burza zbzb může být obchodována mnoho stovekkrát za jeden den a tisíce uživatelů mohou mít zbzb ve svém portfoliu. U datového modelu, jako je příklad, bychom museli každý den aktualizovat mnoho tisíc dokumentů portfolia, což vede k tomu, že systém nebude dobře škálovat.

Referenční data

Vkládání dat funguje pěkně v mnoha případech, ale existují scénáře, kdy denormalizace dat způsobuje 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 vztahy mezi entitami. V databázi dokumentů můžete mít informace v jednom dokumentu, který souvisí s daty 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 ani pro jakoukoli jinou databázi dokumentů, ale jednoduché relace jsou v pořádku a můžou být užitečné.

V kódu JSON jsme se rozhodli použít příklad portfolia akcií z dřívějších verzí, ale tentokrát místo vložení odkazujeme na skladovou položku v portfoliu. Díky tomu se skladová položka často mění v průběhu dne jediným dokumentem, 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
}

Bezprostřední nevýhodou tohoto přístupu je, že pokud je vaše aplikace nutná k zobrazení informací o jednotlivých akciích, které se uchovávají při zobrazení portfolia osoby; v takovém případě budete muset provést více cest do databáze, abyste mohli načíst informace pro každý skladový dokument. Tady jsme se rozhodli zlepšit efektivitu operací zápisu, ke kterým dochází často v průběhu dne, ale na operace čtení, které potenciálně mají menší dopad na výkon tohoto konkrétního systému, narušili.

Poznámka:

Normalizované datové modely můžou vyžadovat více odezvy na server.

A co cizí klíče?

Vzhledem k tomu, že v současné době neexistuje žádný koncept omezení, cizího klíče nebo jiného, žádné vztahy mezi dokumenty, které máte v dokumentech, jsou efektivně "slabé odkazy" a nebudou ověřeny samotnou databází. Pokud chcete zajistit, aby data, na která dokument odkazuje, skutečně existuje, 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řípadech:

  • Představuje relace 1:N .
  • Představuje relace 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 vztahu pomáhá určit, ve kterém dokumentu se má odkaz uložit.

Pokud se podíváme na 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 růstem, může být užitečné uložit odkaz na knihy v dokumentu vydavatele. Pokud je však počet knih na vydavatele nevázaný, pak by tento datový model vedl ke proměnlivosti, rostoucím polím, jako v ukázkovém dokumentu vydavatele.

Přepnutím poněkud dojde k tomu, že model, který stále představuje stejná data, ale vyhne se těmto velkým proměnlivým kolekcím.

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"}

V tomto příkladu jsme v dokumentu vydavatele vynechali nevázanou kolekci. Místo toho máme jenom odkaz na vydavatele v každém dokumentu knihy.

Návody modelovat relace M:N?

V relační databázi relací M:N se často modelují s propojenými tabulkami, které pouze spojují záznamy z jiných tabulek.

Spojení tabulek

Může být lákavé replikovat stejnou věc pomocí dokumentů a vytvořit datový model, který vypadá podobně jako v následujícím příkladu.

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í autora se svými knihami nebo načtení knihy s jeho autorem by však vždy vyžadovalo alespoň dva další dotazy vůči databázi. Jeden dotaz na spojování dokumentu a další dotaz, který načte skutečný dokument, který je připojený.

Pokud toto spojení spojuje jenom dva části dat, proč ho úplně nezahodíte? 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ý, věděl bych ID autorů. Tím se uloží zprostředkující dotaz na tabulku spojení, která snižuje počet odezv serveru, kterou musí vaše aplikace provést.

Hybridní datové modely

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

Nemusí to být vždy buď-nebo, nebudějte se, abyste si trochu směšili věci.

V závislosti na konkrétních vzorech využití a úloh vaší aplikace můžou existovat případy, kdy kombinování vložených a odkazovaných dat dává smysl a může vést k jednodušší aplikační logice s menším počtem odezvy serveru a přitom zachovat dobrou úroveň výkonu.

Podívejte se na následující 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 za vloženým modelem, kde se data z jiných entit vkládají do dokumentu nejvyšší úrovně, ale na jiná data se odkazují.

Když se podíváte na dokument knihy, uvidíme při pohledu na pole autorů několik zajímavých polí. id Pole, které používáme k odkazování na dokument autora, standardní praxe v normalizovaném modelu, je pole, které používáme name thumbnailUrlk odkazování na dokument autora. Mohli jsme aplikaci zaseknout id a nechat aplikaci, abychom získali další informace potřebné z příslušného dokumentu autora pomocí odkazu, ale protože naše aplikace zobrazuje jméno autora a miniaturu s každou zobrazenou knihou, můžeme uložit zpáteční cestu na server v seznamu tím, že některé údaje od autora denormalizujeme.

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

V tomto příkladu existují předem počítané agregační hodnoty, které šetří nákladné zpracování operace č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 knih dokumentů, které existují pro konkrétního autora. Tato optimalizace by byla dobrá v systémech náročných na čtení, kde si můžeme dovolit provádět výpočty u zápisů za účelem optimalizace čtení.

Možnost mít model s předem přepočí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 se v důsledku tohoto omezení můžete rozhodnout o návrhu, jako je například "vždy vložit vše". Pomocí služby Azure Cosmos DB můžete použít triggery na straně serveru nebo uložené procedury, které vkládají knihy a aktualizují autory v rámci transakce ACID. Teď nemusíte vkládat všechno do jednoho dokumentu, abyste měli jistotu, že vaše data zůstávají konzistentní.

Rozlišovat mezi různými typy dokumentů

V některých scénářích můžete chtít kombinovat různé typy dokumentů ve stejné kolekci; to je obvykle případ, kdy chcete mít více souvisejících dokumentů ve stejném oddílu. Můžete například vložit knihy i recenze knih do stejné kolekce a rozdělit je podle bookId. V takové situaci obvykle chcete do svých 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 přes provozní data 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žňují rozsáhlé analýzy bez jakéhokoli dopadu na transakční úlohy. Toto analytické úložiště je vhodné pro rychlé a nákladově efektivní dotazy na velké provozní datové sady 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 když povolíte analytické úložiště v existujícím kontejneru, všechny transakční vložení, aktualizace a odstranění se budou synchronizovat 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.

Díky Azure Synapse Linku se teď můžete přímo připojit ke svým 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 službou Synapse Apache Spark 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ě

Transakční úložiště Azure Cosmos DB se sice považuje za částečně strukturovaná data zaměřená na řádky, ale 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:

  • Json "elements" nebo "string-value pairs separate by a : ".
  • Objekty JSON, oddělené znakem { a }.
  • Pole JSON, oddělená znakem [ a ].

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

Normalizace

Normalizace se stává nesmyslnou, protože pomocí Azure Synapse Linku se můžete připojit mezi kontejnery pomocí T-SQL nebo Spark SQL. Očekávané výhody normalizace jsou:

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

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 dat nejsou reprezentovány v analytickém úložišti. Jak je popsáno v článku o pravidlech automatického odvozování schématu, existuje 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, že bezserverové fondy SQL ve službě Azure Synapse podporují sady výsledků s až 1 000 sloupci a zveřejnění vnořených sloupců také počítá do tohoto limitu. 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 pro Azure Cosmos DB? Odpovědí je, že musíte najít správný zůstatek pro transakční a analytické úlohy.

Klíč oddílu

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

V hypotetické globální situaci IoT je dobrá infrastruktura veřejných klíčů, device id protože všechna zařízení mají podobný objem dat a s tím, že nebudete mít problém s horkým oddílem. Pokud ale chcete analyzovat data více než jednoho zařízení, například "všechna data ze včerejška" nebo "součty na město", může dojít k problémům, protože se jedná o dotazy napříč oddíly. Tyto dotazy můžou poškodit výkon transakcí, protože ke spuštění používají část vaší propustnosti v jednotkách žádostí. Pomocí Azure Synapse Linku 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 vlastnost používá, aby umožňoval skvělý výkon s moduly runtime Azure Synapse Analytics.

Datové typy a názvy vlastností

Článek o pravidlech automatického odvozování schématu uvádí, jaké jsou podporované datové typy. I když nepodporovaný datový typ blokuje reprezentaci v analytickém úložišti, podporované datové typy můžou být zpracovány jinak moduly runtime Azure Synapse. Jedním z příkladů je: Při použití řetězců DateTime, které se řídí standardem 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, zvýraznění hrobu a čárky nejsou. Řekněme, že dokument má vlastnost s názvem Jméno, Příjmení. Tato vlastnost je reprezentována v analytickém úložišti a bezserverový fond Synapse SQL ji může číst bez problému. Protože je ale v analytickém úložišti, Azure Synapse Spark nemůže číst žádná data z analytického úložiště, včetně všech ostatních vlastností. Na konci dne nemůžete použít Azure Synapse Spark, pokud máte jednu vlastnost s použitím nepodporovaných znaků v jejich názvech.

Zploštění dat

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

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, které se budou číst jednotlivě.


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

Dokument bude obsahovat tři sloupce v analytickém úložišti, idemail, a 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 perspektiv:

  • V transakční databázi běží méně dotazů.
  • Infrastruktura veřejných klíčů optimalizovaná pro příjem dat a čtení bodů, což snižuje nároky na data, scénáře horkých oddílů a rozdělení oddílů.
  • Vrstvení dat od analytického času k živému (attl) je nezávislé na transakčním čase do živého (tttl). Transakční data můžete uchovávat v transakčním úložišti po dobu několika dnů, týdnů, měsíců a uchovávat data v analytickém úložišti po dobu let nebo kdykoli. Sloupcový formát analytického úložiště přináší přirozenou kompresi dat z 50 % až do 90 %. A její cena za GB je ~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

To je skvělá alternativa pro situace, kdy už datový model existuje a nejde ho změnit. Stávající datový model se do analytického úložiště nevejde kvůli automatickým pravidlům odvozování schématu, jako je limit vnořených úrovní nebo maximální počet vlastností. V takovém 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, který je vhodný pro Azure Synapse Link. Podívejme se na příklad:

Scénář

Kontejner CustomersOrdersAndItems se používá k ukládání online objednávek včetně podrobností o zákazníci a položkách: fakturační adresa, dodací adresa, způsob doručení, stav doručení, cena položek atd. V analytickém úložišti jsou reprezentovány pouze prvních 1 000 vlastností a nejsou zahrnuty klíčové informace, které blokují využití služby Azure Synapse Link. Kontejner obsahuje databáze záznamů, které není možné změnit a přemodelovat data.

Dalším pohledem problému je objem velkých objemů dat. Analytické oddělení neustále používá miliardy řádků, což jim brání v použití hodnoty tttl pro odstranění starých dat. Udržování celé historie dat v transakční databázi kvůli analytickým potřebám je vynutí neustálé zvýšení zřizování jednotek žádostí, což má vliv na náklady. Transakční a analytické úlohy současně soupeří o stejné prostředky.

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. S kanálem změn se normalizují a zploštějí data. Z datového modelu se odeberou nepotřebné informace a každý kontejner má téměř 100 vlastností, aby nedocházelo ke ztrátě dat kvůli automatickým omezením 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í ve synapse Apache Sparku a bezserverových fondech SQL.
  • Kontejner CustomersOrdersAndItems teď nemá nastavenou možnost uchovávat data pouze 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ě jedna jednotka žádosti za GB. Méně dat, méně jednotek žádostí

Shrnutí

Největší poznatky z tohoto článku jsou pochopit, že modelování dat ve světě, který je bez schématu, je stejně důležité jako kdykoli předtím.

Stejně jako neexistuje jediný způsob, jak znázorňovat část dat na obrazovce, neexistuje jediný způsob, jak modelovat data. Potřebujete porozumět své aplikaci a tomu, jak vytváří, spotřebovává a zpracovává data. Potom můžete použít některé z zde uvedených pokynů, které můžete nastavit o 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.

Související obsah