Sdílet prostřednictvím

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

I když 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, zamyslete se nad datovým modelem za účelem optimalizace výkonu, škálovatelnosti a nákladů.

Jak se ukládají data? Jak vaše aplikace načítá a dotazuje data? Je vaše aplikace náročné na čtení nebo zápis?

Po přečtení tohoto článku můžete 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?
  • Jak vyjadřujete relace dat 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, takže je důležité určit, jestli se mají čísla před uložením ve formátu JSON převést na řetězce. Převeďte všechna čísla na hodnotu String , pokud by mohla překročit hranice čísel s dvojitou přesností, jak definuje institute of Electrical and Electronics Engineers (IEEE) 754 binary64. Specifikace JSON vysvětluje, proč je použití čísel mimo tuto hranici špatným postupem kvůli 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ž modelujete data ve službě Azure Cosmos DB, považují se entity za samostatné položky 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.

Snímek obrazovky s modelem 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 kontaktech můžete dále rozdělit extrahováním běžných polí, jako je typ. Stejný přístup platí pro adresy. Každý záznam lze klasifikovat jako home nebo business.

Hlavním místně při normalizaci dat je zabránit ukládání redundantních dat v každém záznamu a místo toho odkazovat na data. V tomto příkladu potřebujete pro získání informací o osobě se všemi kontaktními údaji a adresami použít JOINS k efektivní kompozici (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

Aktualizace kontaktních údajů a adres jedné osoby vyžaduje operace zápisu v mnoha jednotlivých tabulkách.

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 mít kontaktní údaje v různých formátech.

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

Denormalizace dat může snížit počet dotazů a aktualizace, které vaše aplikace potřebuje k dokončení běžných operací.

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 .
  • Data se mění zřídka.
  • Data se nezvětšují bez vazby.
  • Data se často dotazuje společně.

Poznámka:

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

Kdy nevkládat

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 tento přístup vést k situacím, kterým se 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?"},
    ]
}

Tento příklad může vypadat jako entita příspěvku s vloženými komentáři, pokud bychom modelovali typický blog nebo systém pro správu obsahu (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. Tento návrh může způsobit problémy, protože velikost položky může být neomezeně velká, takže se jí vyhněte.

S rostoucí velikostí položek se přenos, čtení a aktualizace dat ve velkém měřítku stává náročnější.

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á položku pro každý komentář s vlastností, která obsahuje identifikátor příspěvku. Tento model umožňuje, aby příspěvky obsahovaly libovolný počet komentářů a efektivně se zvětšují. Uživatelé, kteří chtějí zobrazit více než jen nejnovější komentáře, by dotazovali tento kontejner tak, že by předali postId, což by měl být partiční klíč pro kontejner komentářů.

Dalším případem, kdy vkládání dat není dobrý nápad, 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 }
        }
    ]
}

Tento příklad může představovat portfolio akcií osoby. Rozhodli jsme se vložit informace o akciích do každého dokumentu portfolia. V prostředí, ve kterém se související data mění často vkládající data, která se často mění, znamená, že neustále aktualizujete každé portfolio. Pomocí příkladu aplikace burzovního obchodování aktualizujete každou položku portfolia pokaždé, když se obchoduje akcie.

Akcie zbzb se dají obchodovat stovkykrát za jeden den a tisíce uživatelů můžou mít zbzb ve svých portfoliech. S datovým modelem, jako je příklad, musí systém aktualizovat tisíce dokumentů portfolia mnohokrát denně, což se dobře neškupá.

Referenční data

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

Můžete vytvářet vztahy mezi entitami v databázích dokumentů, nejen v relačních databázích. V databázi dokumentů může jedna položka obsahovat informace, které se připojují k datům v jiných dokumentech. Azure Cosmos DB není určený pro složité relace, jako jsou ty v relačních databázích, ale jednoduché propojení mezi položkami jsou možné a můžou být užitečné.

Ve formátu JSON použijeme příklad portfolia akcií z předchozího příkladu, 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, jedinou položkou, kterou je potřeba aktualizovat, je jeden 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
}

Jednou z nevýhod tohoto přístupu je, že vaše aplikace musí vytvořit několik databázových požadavků, aby získala informace o jednotlivých akciích v portfoliu dané osoby. Díky tomuto návrhu je zápis dat rychlejší, protože k aktualizacím často dochází. Ale čtení nebo dotazování dat je pomalejší, což je pro tento systém méně důležité.

Poznámka:

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

A co cizí klíče?

Vzhledem k tomu, že neexistuje žádný koncept omezení, jako je cizí klíč, databáze neověřuje žádné vztahy mezi dokumenty; tyto odkazy jsou efektivně "slabé". Pokud chcete zajistit, aby data, na která položka odkazuje, skutečně existuje, musíte tento krok provést ve vaší 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 vztah 1:N.
  • Reprezentace relací mnoho k mnoha (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, do které položky 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ý a růst je omezený, může být užitečné uložit odkaz na knihu uvnitř položky 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í struktury vede k modelu, který představuje stejná data, ale zabraňuje 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 už dokument vydavatele neobsahuje nevázanou kolekci. Místo toho každý dokument knihy obsahuje odkaz na jeho vydavatele.

Návody modelovat relace M:N?

V relační databázi se relace M:N často modelují pomocí spojování tabulek. Tyto relace pouze spojují záznamy z jiných tabulek dohromady.

Snímek obrazovky znázorňující, jak spojit tabulky

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

Tento přístup funguje, ale načítání autora s jeho knihami nebo knihou s autorem vždy vyžaduje alespoň dva další databázové dotazy. Jeden dotaz na spojování položky a další dotaz, který načte skutečnou položku připojenou.

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

S tímto modelem můžete snadno zjistit, které knihy autor napsal, když se podíváte na jeho dokument. Můžete také zjistit, kteří autoři napsali knihu, tak, že dokument knihy zkontrolujete. Nemusíte používat samostatnou tabulku spojení ani provádět další dotazy. Díky tomuto modelu bude vaše aplikace rychlejší a jednodušší získat data, která potřebuje.

Hybridní datové modely

Prozkoumáme vkládání (nebo denormalizaci) a odkazování (nebo normalizaci) dat. Každý přístup nabízí výhody a zahrnuje kompromisy.

Nemusí být vždy buď nebo. Neváhejte trochu kombinovat věci.

V závislosti na konkrétních vzorech využití a úlohách vaší aplikace může mít kombinování vložených a odkazovaných dat smysl. Tento přístup by mohl zjednodušit aplikační logiku, zkrátit dobu odezvy serveru a udržovat dobrý výkon.

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

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

Pokud se podíváte na dokument knihy, můžeme v poli autorů vidět několik zajímavých prvků. Existuje pole id, které používáme k odkazování na dokument autora, což je standardní praxe v normalizovaném modelu, ale pak máme také name a thumbnailUrl. Mohli bychom použít pouze id aplikaci a nechat aplikaci načíst všechny další informace, které potřebuje z odpovídající položky autora, pomocí "odkazu". Vzhledem k tomu, že aplikace zobrazuje jméno autora a miniaturu s každou knihou, denormalizace některých dat od autora snižuje počet odezvy serveru v seznamu.

Pokud se jméno autora změní nebo aktualizuje fotku, budete muset aktualizovat každou knihu, kterou publikoval. U této aplikace však za předpokladu, že autoři zřídka mění jejich názvy, je toto kompromis přijatelné rozhodnutí o návrhu.

V tomto příkladu jsou předem vypočtené agregované hodnoty, které během operace čtení šetří nákladné zpracování. V příkladu jsou některá data vložená do položky autora data, která se počítají za běhu. Při každém publikování nové knihy se vytvoří položka 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 vymýšlí rozhodnutí o návrhu, jako je "vždy vložit vše", protože toto omezení je. 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 jedné položky, abyste měli jistotu, že vaše data zůstanou konzistentní.

Rozlišovat mezi různými typy položek

V některých scénářích můžete chtít kombinovat různé typy položek ve stejné kolekci; tato volba návrhu je obvykle případ, kdy chcete mít více souvisejících dokumentů, které se nacházejí 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 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 vytvoří bezproblémovou integraci mezi 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 vlivu na transakční úlohy. Analytické úložiště umožňuje spouštět rychlé a cenově dostupné dotazy na velké sady dat. Nemusíte kopírovat data nebo se starat o zpomalení hlavní databáze. Když zapnete analytické úložiště pro kontejner, všechny změny provedené v datech se zkopírují do analytického úložiště téměř okamžitě. Nemusíte nastavovat kanál změn ani spouštět úlohy extrakce, transformace a načítání (ETL). Systém udržuje obě úložiště synchronizovaná za vás.

Díky Azure Synapse Link 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, aniž byste museli platit za jednotky žádostí (request units). 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 je částečně strukturovaná data zaměřená na řádky, zatímco analytické úložiště používá sloupcový a strukturovaný formát. Tento převod se automaticky provede pro zákazníky pomocí pravidel odvozování schématu pro analytickou databázi. 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:

  • "elements" nebo "string-value pairs separated by a :"
  • Objekty JSON, oddělené a {}
  • Pole JSON s oddělovači [ a ]

Pomocí následujících technik můžete minimalizovat účinek převodů odvozování schématu a maximalizovat analytické schopnosti.

Normalizace

Normalizace je méně relevantní, protože Azure Synapse Link umožňuje připojit 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í

Díky menšímu počtu vlastností a menšímu počtu úrovní v datech se analytické dotazy urychlují. Pomáhá také zajistit, aby všechny části vašich dat byly zahrnuty do analytického úložiště. 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ávnou rovnováhu pro své transakční a analytické úlohy.

Klíč oddílu

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 slouží jako dobrý klíč oddílu, device id protože všechna zařízení generují podobný objem dat, což brání problémům s horkými oddíly. 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 tyto dotazy jsou 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 podporuje 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ž moduly runtime Azure Synapse můžou zpracovávat podporované datové typy odlišně, nepodporované datové typy blokují reprezentaci v analytickém úložišti. Jedním z příkladů je: Při použití řetězců DateTime, které následují standard ISO 8601 UTC, fondy Sparku v Azure Synapse představují tyto sloupce jako string a bezserverové fondy SQL v Azure Synapse představují tyto sloupce jako varchar(8000).

Dalším problémem je, že Azure Synapse Spark nepřijímá všechny znaky. I když jsou mezery přijímané, znaky jako dvojtečka, ostrý přízvuk a čárka nejsou. Řekněme, že položka 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

Každá vlastnost na nejvyšší úrovni dat Azure Cosmos DB se stane sloupcem v analytickém úložišti. Vlastnosti uvnitř vnořených objektů nebo polí se ukládají jako JSON v analytickém úložišti, přičemž jejich struktura se udržuje. Vnořené struktury vyžadují dodatečné zpracování z runtimes Azure Synapse k vyrovnání dat ve strukturovaném formátu, což může představovat výzvu ve scénářích s velkými objemy dat.

Položka má v analytickém úložišti id pouze dva sloupce a contactDetails. Všechna ostatní data emaila phonevyžadují dodatečné zpracování prostřednictvím funkcí SQL, které se mají číst jednotlivě.


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

Položka má 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ů.
  • PK optimalizovaný pro příjem dat a čtení záznamů podle klíče, což snižuje nároky na data, scénáře přetížených oddílů a štěpení 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 přidělovat jednotky žádostí.

Řízená redundance

Tato technika je skvělou alternativou pro situace, kdy už datový model existuje a nedá se změnit. Aktuální datový model nefunguje s analytickým úložištěm dobře. Tato výhoda existuje, protože analytické úložiště obsahuje pravidla, která omezují počet úrovní, které můžete vnořit data a kolik vlastností můžete mít v každém dokumentu. Pokud jsou vaše data příliš složitá nebo obsahují příliš mnoho polí, nemusí se některé důležité informace zahrnout do analytického úložiště. Pokud se jedná o 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, který je přívětivý 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 petabajty záznamů, které není možné změnit a přemodelovat data.

Dalším aspektem problému je objem velkých objemů dat. Analytické oddělení neustále používá miliardy řádků, což jim znemožňuje použití 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 nutí neustále zvyšovat alokaci jednotek požadavků, což má vliv na náklady. Transakční a analytické úlohy současně soupeří o stejné prostředky.

Co můžete dělat?

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

  • Technický tým se rozhodl použít kanál změn k naplnění tří nových kontejnerů: Customers, Orders a Items. Díky kanálu změn se data normalizují a zploštějí. 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í ke čtení dat používá Synapse Analytics. Tím se snižuje využití jednotek požadavků, protože analytické dotazy běží v Synapse Apache Sparku a bezserverových fondech SQL.
  • Kontejner CustomersOrdersAndItems teď má nastavenou hodnotu TTL (Time to Live), která umožňuje uchovávat data pouze po dobu šesti měsíců, což umožňuje snížit 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, že modelování dat ve scénáři 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. Použitím zde uvedených pokynů můžete vytvořit model, který řeší okamžité potřeby vaší aplikace. Když se vaše aplikace změní, využijte flexibilitu databáze bez schématu k snadnému přizpůsobení a vývoji datového modelu.

Související obsah

  • Last updated on