Megosztás a következőn keresztül:

Adatmodellezés az Azure Cosmos DB-ben

  • Cikk

A KÖVETKEZŐRE VONATKOZIK: NoSQL

Bár a sémamentes adatbázisok, például az Azure Cosmos DB rendkívül egyszerűvé teszik a strukturálatlan és félig strukturált adatok tárolását és lekérdezését, érdemes némi időt szánnia az adatmodellre, hogy a lehető legtöbbet hozhassa ki a szolgáltatásból a teljesítmény, a méretezhetőség és a legalacsonyabb költség szempontjából.

Hogyan lesznek tárolva az adatok? Hogyan fogja az alkalmazás lekérni és lekérdezni az adatokat? Az alkalmazás írásvédett vagy írási nehéz?

A cikk elolvasása után a következő kérdésekre válaszolhat:

  • Mi az adatmodellezés, és miért fontos nekem?
  • Miben különbözik az Adatok modellezése az Azure Cosmos DB-ben egy relációs adatbázistól?
  • Hogyan expressz adatkapcsolatokat egy nem relációs adatbázisban?
  • Mikor ágyazhatok be adatokat, és mikor csatolhatok adatokat?

Számok a JSON-ban

Az Azure Cosmos DB JSON-ban menti a dokumentumokat. Ez azt jelenti, hogy gondosan meg kell határozni, hogy szükség van-e számok sztringekké alakítására, mielőtt jsonban tároljuk őket. Minden számot ideális esetben konvertálni kell, Stringha van rá esély, hogy az IEEE 754 bináris64 szerint a kettős pontosságú számok határain kívül vannak. A JSON-specifikáció felhívja azokat az okokat, amelyek miatt a határokon kívüli számok használata általában rossz gyakorlat a JSON-ban az együttműködési problémák miatt. Ezek az aggodalmak különösen fontosak a partíciókulcs oszlopában, mivel nem módosítható, és az adatmigrálást igényli a későbbi módosításhoz.

Adatok beágyazása

Amikor elkezdi az adatok modellezését az Azure Cosmos DB-ben, próbálja meg az entitásokat JSON-dokumentumként reprezentált önálló elemekként kezelni.

Összehasonlításként először nézzük meg, hogyan modellezhetjük az adatokat egy relációs adatbázisban. Az alábbi példa bemutatja, hogyan tárolhat egy személyt egy relációs adatbázisban.

Relációsadatbázis-modell

A relációs adatbázisok használatakor a stratégia az összes adat normalizálása. Az adatok normalizálása általában egy entitás, például egy személy átvételét és különálló összetevőkre bontását foglalja magában. A fenti példában egy személy több kapcsolattartási adatrekordot és több címrekordot is tartalmazhat. A kapcsolattartási adatok tovább bonthatók a gyakori mezők, például egy típus további kinyerésével. Ugyanez vonatkozik a címekre is, minden rekord lehet otthoni vagy vállalati típusú.

Az adatok normalizálásának alapfeltétele, hogy ne tároljon redundáns adatokat az egyes rekordokon, és ne hivatkozzon adatokra. Ebben a példában az összes kapcsolattartási adattal és címmel rendelkező személy olvasásához a JOINS használatával kell hatékonyan visszaírni (vagy denormalizálni) az adatokat futásidőben.

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

Az egyetlen személy kapcsolattartási adatainak és címeinek frissítéséhez több különböző táblán végzett írási műveletekre van szükség.

Most nézzük meg, hogyan modellezhetjük ugyanazokat az adatokat, mint egy önálló entitás az Azure Cosmos DB-ben.

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

A fenti megközelítéssel denormalizáltuk a személyrekordot úgy, hogy egyetlen JSON-dokumentumba ágyazzuk be a személyhez kapcsolódó összes információt, például a kapcsolattartási adatait és a címét. Emellett, mivel nem rögzített sémára korlátozódunk, rugalmasan hajthatunk végre olyan műveleteket, mint például a különböző alakzatok kapcsolattartási adatainak teljes egészében.

A teljes személy rekordjának beolvasása az adatbázisból mostantól egyetlen olvasási művelet egyetlen tárolón és egyetlen elemen. A személyrekordok kapcsolattartási adatainak és címeinek frissítése szintén egyetlen írási művelet egyetlen elemhez.

Az adatok denormalizálásával előfordulhat, hogy az alkalmazásnak kevesebb lekérdezést és frissítést kell kiadnia a gyakori műveletek elvégzéséhez.

Mikor kell beágyazni?

Általában beágyazott adatmodelleket használjon a következő esetekben:

  • Az entitások között tartalmazott kapcsolatok vannak.
  • Az entitások között egy-a-néhányhoz kapcsolat áll fenn.
  • Vannak olyan beágyazott adatok, amelyek ritkán változnak.
  • Vannak olyan beágyazott adatok, amelyek nem nőnek kötés nélkül.
  • Vannak beágyazott adatok, amelyeket gyakran kérdeznek le együtt.

Feljegyzés

A denormalizált adatmodellek általában jobb olvasási teljesítményt nyújtanak.

Mikor ne ágyazza be?

Bár az Azure Cosmos DB-ben a hüvelykujjszabály az, hogy mindent denormalizál, és az összes adatot egyetlen elembe ágyazza be, ez bizonyos helyzetekhez vezethet, amelyeket el kell kerülni.

Használja ezt a JSON-kódrészletet.

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

Így nézne ki egy beágyazott megjegyzéseket tartalmazó bejegyzés entitás, ha egy tipikus blogot vagy CMS-rendszert modelleznénk. Ezzel a példával az a probléma, hogy a megjegyzések tömbje kötetlen, ami azt jelenti, hogy nincs (gyakorlati) korlát arra, hogy egy bejegyzés hány megjegyzéssel rendelkezhet. Ez problémát okozhat, mivel az elem mérete végtelenül megnőhet, ezért érdemes elkerülni a tervezést.

Az elem méretének növekedésével az adatok átvitele a vezetéken keresztül, az elem olvasása és frissítése pedig nagy léptékben fog változni.

Ebben az esetben jobb lenne az alábbi adatmodellt figyelembe venni.

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

Ez a modell minden megjegyzéshez tartalmaz egy dokumentumot a bejegyzésazonosítót tartalmazó tulajdonsággal. Ez lehetővé teszi, hogy a bejegyzések tetszőleges számú megjegyzést tartalmazzanak, és hatékonyan növekedhessenek. Azok a felhasználók, amelyek a legutóbbi megjegyzéseknél többet szeretnének látni, lekérdezik ezt a tárolót, és átadják a postId azonosítót, amelynek a megjegyzéstároló partíciókulcsának kell lennie.

Egy másik eset, amikor az adatok beágyazása nem jó ötlet, ha a beágyazott adatokat gyakran használják az elemek között, és gyakran változnak.

Használja ezt a JSON-kódrészletet.

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

Ez egy személy részvényportfólióját jelentheti. Úgy döntöttünk, hogy az egyes portfóliódokumentumokba beágyazzuk a részvényinformációkat. Egy olyan környezetben, ahol a kapcsolódó adatok gyakran változnak, például egy tőzsdei kereskedési alkalmazás, a gyakran változó adatok beágyazása azt jelenti, hogy folyamatosan frissíti az egyes portfóliódokumentumokat minden alkalommal, amikor egy részvényt kereskednek.

Részvény zbzb lehet kereskedni több száz alkalommal egy nap, és több ezer felhasználó lehetett zbzb a portfolió. A fentihez hasonló adatmodellekkel naponta több ezer portfoliódokumentumot kell frissítenünk, ami egy olyan rendszerhez vezet, amely nem fog megfelelően méretezni.

Referenciaadatok

Az adatok beágyazása sok esetben jól működik, de vannak olyan esetek, amikor az adatok denormalizálása több problémát okoz, mint amennyit érdemes. Mit csinálunk most?

Nem csak a relációs adatbázisok hozhatnak létre kapcsolatokat az entitások között. Egy dokumentumadatbázisban előfordulhat, hogy egy dokumentumban olyan információk találhatók, amelyek más dokumentumok adataihoz kapcsolódnak. Nem javasoljuk olyan rendszerek létrehozását, amelyek jobban megfelelnének egy relációs adatbázisnak az Azure Cosmos DB-ben vagy bármely más dokumentumadatbázisban, de az egyszerű kapcsolatok rendben vannak, és hasznosak lehetnek.

Az alábbi JSON-ban úgy döntöttünk, hogy egy korábbi részvényportfólió példáját használjuk, de ezúttal a portfólió részvényelemére hivatkozunk beágyazás helyett. Így, ha a készletelem gyakran változik a nap folyamán, az egyetlen frissíteni kívánt dokumentum az egyetlen részvénydokumentum.

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
}

Ennek a megközelítésnek azonban az a közvetlen hátránya, hogy az alkalmazásnak meg kell jelenítenie az egyes részvényekre vonatkozó információkat, amelyek egy személy portfóliójának megjelenítésekor találhatók; ebben az esetben több utat kell elvégeznie az adatbázisba az egyes részvénydokumentumok adatainak betöltéséhez. Itt egy olyan döntést hoztunk az írási műveletek hatékonyságának javítása érdekében, amelyek gyakran előfordulnak a nap folyamán, de az olvasási műveletek biztonsága is veszélybe került, amelyek esetleg kevésbé befolyásolják az adott rendszer teljesítményét.

Feljegyzés

A normalizált adatmodellek több ciklikus utazást igényelhetnek a kiszolgálóra.

Mi a helyzet a külföldi kulcsokkal?

Mivel jelenleg nem létezik korlátozás, idegen kulcs vagy egyéb típusú korlátozás, a dokumentumok közötti kapcsolatok gyakorlatilag "gyenge kapcsolatok", és magát az adatbázist nem ellenőrzik. Ha meg szeretné győződni arról, hogy a dokumentum által hivatkozott adatok valóban léteznek, akkor ezt az alkalmazásban, vagy kiszolgálóoldali eseményindítók vagy tárolt eljárások használatával kell elvégeznie az Azure Cosmos DB-ben.

Mikor kell hivatkozni?

Általában a normalizált adatmodelleket akkor érdemes használni, ha:

  • Egy-a-többhöz kapcsolatok ábrázolása.
  • Több-a-többhöz kapcsolatok ábrázolása.
  • A kapcsolódó adatok gyakran változnak.
  • A hivatkozott adatok kötetlenek lehetnek.

Feljegyzés

A normalizálás általában jobb írási teljesítményt biztosít.

Hová tegyem a kapcsolatot?

A kapcsolat növekedése segít meghatározni, hogy melyik dokumentum tárolja a hivatkozást.

Ha megnézzük az alábbi JSON-t, amely közzétevőket és könyveket modell.

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

Ha a kiadónkénti könyvek száma kicsi, és korlátozott a növekedés, akkor hasznos lehet a könyvhivatkozás tárolása a közzétevő dokumentumában. Ha azonban a közzétevőnkénti könyvek száma kötetlen, akkor ez az adatmodell a fenti példa közzétevői dokumentumhoz hasonlóan változékony, növekvő tömbökhöz vezetne.

Ha egy kicsit áttér a dolgokra, az egy olyan modellt eredményez, amely továbbra is ugyanazokat az adatokat képviseli, de most elkerüli ezeket a nagy méretű mutable-gyűjteményeket.

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

A fenti példában elvetettük a kötetlen gyűjteményt a közzétevő dokumentumra. Ehelyett csak egy hivatkozás van a kiadóra minden könyvdokumentumon.

Hogyan több-a-többhöz típusú kapcsolatokat?

Egy relációs adatbázisban a több-a-többhöz kapcsolatok gyakran illesztőtáblákkal vannak modellezve, amelyek csak összekapcsolják más táblák rekordjait.

Táblák illesztése

Előfordulhat, hogy a rendszer arra csábítja, hogy ugyanazt a dokumentumot replikálja, és létrehoz egy olyan adatmodellt, amely az alábbiakhoz hasonlóan néz ki.

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

Ez működni fog. Ha azonban be kell töltenie egy szerzőt a könyveivel, vagy be kell töltenie egy könyvet a szerzőjével, mindig szükség lenne legalább két további lekérdezésre az adatbázison. Egy lekérdezés a csatlakozó dokumentumra, majd egy másik lekérdezés, amely lekéri a ténylegesen csatlakoztatott dokumentumot.

Ha ez az illesztés csak két adatrészt ragaszt össze, akkor miért nem dobja el teljesen? Gondolja át a következő példát.

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

Ha lenne egy szerzőm, azonnal tudom, hogy mely könyveket írták, és fordítva, ha betöltöttem volna egy könyvdokumentumot, tudnám a szerző(k) azonosítóit. Ezzel menti a közbenső lekérdezést az illesztőtáblán, csökkentve az alkalmazás által el kell végeznie a kiszolgálói körutazások számát.

Hibrid adatmodellek

Most megvizsgáltuk a beágyazást (vagy denormalizálást) és az adatok hivatkozását (vagy normalizálását). Minden megközelítésnek vannak hátrányai és kompromisszumai.

Nem kell mindig vagy- vagy, ne félj keverni a dolgokat egy kicsit.

Az alkalmazás konkrét használati mintái és számítási feladatai alapján lehetnek olyan esetek, amikor a beágyazott és a hivatkozott adatok keverése logikus, és egyszerűbb alkalmazáslogikához vezethet, kevesebb kiszolgálói körúttal, miközben továbbra is jó teljesítményt nyújt.

Vegye figyelembe a következő JSON-t.

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

Itt (többnyire) a beágyazott modellt követtük, ahol más entitásokból származó adatok vannak beágyazva a legfelső szintű dokumentumba, de más adatokra is hivatkozunk.

Ha megnézzük a könyvdokumentumot, néhány érdekes mezőt láthatunk, amikor megnézzük a szerzők tömbét. Van egy id mező, amely az a mező, amellyel vissza lehet hivatkozni egy szerzői dokumentumra, egy normalizált modell standard gyakorlatára, de akkor van name és thumbnailUrl. Elakadhattunk volna az alkalmazással id , és elhagyhattuk volna az alkalmazást, hogy a megfelelő szerzői dokumentumból további információt szerezzünk be a "hivatkozás" használatával, de mivel az alkalmazás megjeleníti a szerző nevét és egy miniatűrképet minden megjelenített könyvvel, könyvenként egy listában menthetjük a kiszolgálóra való utazást úgy, hogy denormalizálunk néhány adatot a szerzőtől.

Persze, ha a szerző neve megváltozott, vagy frissíteni akarták a fényképüket, akkor frissíteni kell minden könyvet, amelyet valaha is közzétettek, de az alkalmazásunk esetében, azon a feltételezésen alapulva, hogy a szerzők gyakran nem változtatják meg a nevüket, ez elfogadható tervezési döntés.

A példában előre számított aggregátumértékek vannak , amelyek költséges feldolgozást mentenek egy olvasási műveleten. A példában a szerzői dokumentumba beágyazott adatok egy része futtatáskor kiszámított adatok. Minden alkalommal, amikor új könyvet tesznek közzé, létrejön egy könyvdokumentum, és a CountOfBooks mező számított értékre van állítva az adott szerzőhöz tartozó könyvdokumentumok száma alapján. Ez az optimalizálás jó lenne az olvasási nehéz rendszerekben, ahol megengedhetjük magunknak, hogy számításokat végezzünk az írásokon az olvasás optimalizálása érdekében.

Az előre kiszámított mezőket tartalmazó modell létrehozása azért lehetséges, mert az Azure Cosmos DB támogatja a többdokumentumos tranzakciókat. Számos NoSQL-áruház nem tud tranzakciókat végrehajtani a dokumentumok között, ezért a korlátozás miatt a tervezési döntések, például a "mindig beágyazás mindent" mellett érvelnek. Az Azure Cosmos DB-vel kiszolgálóoldali eseményindítókat vagy tárolt eljárásokat használhat, amelyek könyveket szúrnak be és frissítik a szerzőket egy ACID-tranzakción belül. Most már nem kell mindent beágyaznia egy dokumentumba, csak hogy az adatok konzisztensek legyenek.

Különböző dokumentumtípusok megkülönböztetése

Bizonyos esetekben érdemes lehet különböző dokumentumtípusokat keverni ugyanabban a gyűjteményben; Ez általában akkor fordul elő, ha több kapcsolódó dokumentumot szeretne ugyanabba a partícióba helyezni. Tegyük fel például, hogy a könyvek és a könyvajánlások ugyanabban a gyűjteményben találhatók, és particionálhatja őket bookId. Ilyen esetben általában olyan mezővel szeretné hozzáadni a dokumentumokat, amelyek a típusukat azonosítják, hogy megkülönböztethessék őket.

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

Az Azure Cosmos DB-hez készült Azure Synapse Link egy felhőalapú hibrid tranzakciós és elemzési (HTAP) képesség, amellyel közel valós idejű elemzéseket futtathat a működési adatokon az Azure Cosmos DB-ben. Az Azure Synapse Link szoros, zökkenőmentes integrációt hoz létre az Azure Cosmos DB és az Azure Synapse Analytics között.

Ez az integráció az Azure Cosmos DB elemzési tárán keresztül történik, amely a tranzakciós adatok oszlopos ábrázolása, amely lehetővé teszi a nagy méretű elemzéseket anélkül, hogy hatással lenne a tranzakciós számítási feladatokra. Ez az elemzési tár alkalmas gyors, költséghatékony lekérdezésekre nagy operatív adatkészleteken anélkül, hogy adatokat másolna, és hatással lenne a tranzakciós számítási feladatok teljesítményére. Ha engedélyezett elemzési tárat tartalmazó tárolót hoz létre, vagy ha egy meglévő tárolóban engedélyezi az elemzési tárat, a rendszer az összes tranzakciós beszúrást, frissítést és törlést közel valós időben szinkronizálja az elemzési tárral, nincs szükség változáscsatorna- vagy ETL-feladatokra.

Az Azure Synapse Link használatával mostantól közvetlenül csatlakozhat az Azure Cosmos DB-tárolókhoz az Azure Synapse Analyticsből, és hozzáférhet az elemzési tárhoz kérelemegységek (kérelemegységek) nélkül. Az Azure Synapse Analytics jelenleg támogatja az Azure Synapse Linket a Synapse Apache Spark és a kiszolgáló nélküli SQL-készletek használatával. Ha globálisan elosztott Azure Cosmos DB-fiókkal rendelkezik, miután engedélyezte az elemzési tárat egy tárolóhoz, az a fiók minden régiójában elérhető lesz.

Elemzési tár automatikus sémakövetkeztetés

Bár az Azure Cosmos DB tranzakciós tárolója sororientált, félig strukturált adatnak számít, az elemzési tár oszlopos és strukturált formátummal rendelkezik. Ez az átalakítás automatikusan megtörténik az ügyfelek számára az elemzési tár sémakövető szabályainak használatával. Az átalakítási folyamatnak vannak korlátai: a beágyazott szintek maximális száma, a tulajdonságok maximális száma, a nem támogatott adattípusok stb.

Feljegyzés

Az elemzési tár kontextusában a következő struktúrákat tekintjük tulajdonságnak:

  • JSON "elements" vagy "string-value pairs separateed by : ".
  • JSON-objektumok, elválasztó { }és .
  • JSON-tömbök, tagolt [ és ].

Az alábbi technikákkal minimalizálhatja a sémakövető konverziók hatását, és maximalizálhatja az elemzési képességeket.

Normalizálás

A normalizálás értelmetlenné válik, mivel az Azure Synapse Link segítségével t-SQL vagy Spark SQL használatával csatlakozhat a tárolókhoz. A normalizálás várható előnyei a következők:

  • Kisebb adatlábnyom mind a tranzakciós, mind az elemzési tárolóban.
  • Kisebb tranzakciók.
  • Dokumentumonként kevesebb tulajdonság.
  • Kevesebb beágyazott szinttel rendelkező adatstruktúrák.

Vegye figyelembe, hogy ez az utolsó két tényező, a kevesebb tulajdonság és a kevesebb szint segíti az elemzési lekérdezések teljesítményét, de csökkenti annak esélyét is, hogy az adatok egy része nem jelenik meg az elemzési tárban. Az automatikus sémakövető szabályokról szóló cikkben leírtak szerint az elemzési tárban megjelenő szintek és tulajdonságok száma korlátozott.

A normalizálás másik fontos tényezője, hogy az Azure Synapse kiszolgáló nélküli SQL-készletei legfeljebb 1000 oszlopos eredményhalmazokat támogatnak, és a beágyazott oszlopok felfedése is beleszámít a korlátba. Más szóval mind az elemzési tár, mind a Synapse SQL kiszolgáló nélküli készletei 1000 tulajdonságokkal rendelkeznek.

De mi a teendő, mivel a denormalizálás az Azure Cosmos DB fontos adatmodellezési technikája? A válasz az, hogy meg kell találnia a megfelelő egyensúlyt a tranzakciós és elemzési számítási feladatokhoz.

Partíciókulcs

Az Azure Cosmos DB partíciókulcsa (PK) nem használatos az elemzési tárban. Mostantól az elemzési tár egyéni particionálásával bármilyen PK használatával másolhatja az elemzési tárat. Az elkülönítés miatt kiválaszthatja a tranzakciós adatok PK-ját az adatbetöltésre és a pontolvasásra összpontosítva, míg a partíciók közötti lekérdezések az Azure Synapse Linkkel végezhetők el. Lássunk egy példát:

Hipotetikus globális IoT-forgatókönyv esetén jó PK, device id mivel minden eszköz hasonló adatkötettel rendelkezik, és így nem lesz gyakori particionálási probléma. Ha azonban egynél több eszköz adatait szeretné elemezni, például "a tegnapi összes adatot" vagy a "városonkénti összesítést", akkor problémákat tapasztalhat, mivel ezek több partíciós lekérdezések. Ezek a lekérdezések ronthatják a tranzakciós teljesítményt, mivel a kérelemegységekben az átviteli sebesség egy részét használják a futtatáshoz. Az Azure Synapse Link használatával azonban a kérelemegységek költségei nélkül futtathatja ezeket az elemzési lekérdezéseket. Az elemzési tár oszlopos formátuma elemzési lekérdezésekhez van optimalizálva, és az Azure Synapse Link ezt a jellemzőt alkalmazza, hogy az Azure Synapse Analytics-futtatókörnyezetekkel nagy teljesítményt nyújthasson.

Adattípusok és tulajdonságok neve

Az automatikus sémakövető szabályok cikk felsorolja a támogatott adattípusokat. Bár a nem támogatott adattípus blokkolja a reprezentációt az elemzési tárban, a támogatott adattípusokat az Azure Synapse-futtatókörnyezetek eltérő módon dolgozhatják fel. Egy példa: Ha az ISO 8601 UTC szabványt követő DateTime-sztringeket használ, az Azure Synapse Spark-készletei sztringként jelenítik meg ezeket az oszlopokat, az Azure Synapse-ban pedig az SQL kiszolgáló nélküli készletei pedig varcharként (8000) jelenítik meg ezeket az oszlopokat.

Egy másik kihívás, hogy az Azure Synapse Spark nem minden karaktert fogad el. Bár a fehér szóközök elfogadottak, a kettőspont, a sírszín és a vessző nem. Tegyük fel, hogy a dokumentumnak van egy "Vezetéknév, Vezetéknév" nevű tulajdonsága. Ez a tulajdonság az elemzési tárban jelenik meg, és a Synapse SQL kiszolgáló nélküli készlete probléma nélkül tudja olvasni. Mivel azonban az elemzési tárban található, az Azure Synapse Spark nem tud adatokat olvasni az elemzési tárból, beleértve az összes többi tulajdonságot is. A nap végén nem használhatja az Azure Synapse Sparkot, ha egy tulajdonsága nem támogatott karaktereket használ a nevükben.

Adatelsimítás

Az Azure Cosmos DB-adatok gyökérszintjének minden tulajdonsága oszlopként jelenik meg az elemzési tárban, és a dokumentum adatmodelljének mélyebb szintjein lévő összes többi tulajdonság JSON-ként lesz ábrázolva, beágyazott struktúrákban is. A beágyazott struktúrák extra feldolgozást igényelnek az Azure Synapse-futtatókörnyezetektől, hogy strukturált formátumban simíthassa az adatokat, ami nagy adatforgatókönyvekben kihívást jelenthet.

Az alábbi dokumentum csak két oszlopot tartalmaz az elemzési tárban, id és contactDetailsa . Az összes többi adat, email és phoneaz SQL-függvényeken keresztüli további feldolgozást igényel, hogy külön-külön lehessen olvasni.


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

Az alábbi dokumentum három oszlopot tartalmaz az elemzési tárban, idemailés phone. Minden adat közvetlenül elérhető oszlopként.


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

Adatrétegezés

Az Azure Synapse Link a következő szempontokból teszi lehetővé a költségek csökkentését:

  • Kevesebb lekérdezés fut a tranzakciós adatbázisban.
  • Adatbetöltésre és pontolvasásra optimalizált PK, amely csökkenti az adatlábnyomot, a gyakori particionálási forgatókönyveket és a partíciók felosztását.
  • Az adatrétegezés, mivel az elemzési élettartam (attl) független a tranzakciós élettartamtól (tttl). A tranzakciós adatokat néhány napig, hetekig, hónapokig tárolhatja a tranzakciós tárban, és évekig vagy örökre megőrizheti az adatokat az elemzési tárban. Az elemzési tár oszlopos formátuma természetes adattömörítést eredményez, 50%-tól 90%-ig. A gb-onkénti költség pedig a tranzakciós tár tényleges árának ~10%-a. Az aktuális biztonsági mentési korlátozásokról további információt az elemzési tár áttekintésében talál.
  • A környezetben nem futnak ETL-feladatok, ami azt jelenti, hogy nem kell hozzájuk kérésegységeket kiépítenie.

Szabályozott redundancia

Ez nagyszerű alternatíva olyan helyzetekre, amikor egy adatmodell már létezik, és nem módosítható. A meglévő adatmodell pedig nem fér el jól az elemzési tárban az olyan automatikus sémakövető szabályok miatt, mint a beágyazott szintek korlátja vagy a tulajdonságok maximális száma. Ebben az esetben az Azure Cosmos DB változáscsatornával replikálhatja az adatokat egy másik tárolóba, és alkalmazhatja a szükséges átalakításokat egy Azure Synapse Link-barát adatmodellhez. Lássunk egy példát:

Eset

A tároló CustomersOrdersAndItems az online rendelések tárolására szolgál, beleértve az ügyfél és a tételek adatait: számlázási cím, szállítási cím, szállítási mód, szállítási állapot, cikkek ára stb. Csak az első 1000 tulajdonság jelenik meg, és a kulcsadatok nem szerepelnek az elemzési tárban, ami blokkolja az Azure Synapse Link használatát. A tároló olyan rekordokat tartalmazó PB-ekkel rendelkezik, amely nem módosítható az alkalmazáson, és nem módosíthatók újra az adatok.

A probléma másik perspektívája a big data-kötet. Az elemzési részleg folyamatosan több milliárd sort használ, ami megakadályozza, hogy tttl-t használjanak a régi adatok törléséhez. A tranzakciós adatbázisban az elemzési igények miatt a teljes adatelőzmény fenntartása arra kényszeríti őket, hogy folyamatosan növeljék a kérelemegységek kiépítését, ami hatással van a költségekre. A tranzakciós és elemzési számítási feladatok ugyanazon erőforrásokért versenyeznek egyszerre.

Mi a teendő?

Megoldás változáscsatornával

  • A mérnöki csapat úgy döntött, hogy a Változáscsatorna használatával tölt fel három új tárolót: Customers, Ordersés Items. A Változáscsatorna használatával normalizálják és összesimítják az adatokat. A rendszer eltávolítja a szükségtelen információkat az adatmodellből, és minden tároló közel 100 tulajdonsággal rendelkezik, így elkerülhető az adatvesztés az automatikus sémakövetkeztetési korlátok miatt.
  • Ezeknek az új tárolóknak engedélyezve van az elemzési tár, és az elemzési részleg most a Synapse Analytics használatával olvassa be az adatokat, csökkentve a kérelemegységek használatát, mivel az elemzési lekérdezések a Synapse Apache Sparkban és a kiszolgáló nélküli SQL-készletekben történnek.
  • A tároló CustomersOrdersAndItems tttl-halmaza mostantól csak hat hónapig tárolja az adatokat, ami lehetővé teszi a kérelemegységek használatának további csökkentését, mivel az Azure Cosmos DB-ben gb-onként legalább 1 kérelemegység van. Kevesebb adat, kevesebb kérelemegység.

Legfontosabb ismeretek

A cikk legnagyobb tanulsága annak megértése, hogy az adatmodellezés egy sémamentes világban ugyanolyan fontos, mint valaha.

Ahogyan egyetlen módon sem jelölhet egy adatrészt a képernyőn, az adatok modellezésére nincs egyetlen módszer sem. Ismernie kell az alkalmazást, és azt, hogyan fogja előállítani, felhasználni és feldolgozni az adatokat. Ezt követően az itt bemutatott irányelvek némelyikének alkalmazásával létrehozhat egy modellt, amely megfelel az alkalmazás azonnali igényeinek. Amikor az alkalmazásoknak változnia kell, a sémamentes adatbázisok rugalmasságával egyszerűen átfogalmazhatja és fejlesztheti az adatmodellt.

Következő lépések