Vývoj úložiště je dlouhá a seriózní záležitost.
Mnoho v životě projektu závisí na tom, jak dobře jsou na začátku promyšleny model objektu a základní struktura.
Obecně přijímaným přístupem byly a zůstávají různé kombinace hvězdného schématu s třetí normální formou. Zpravidla podle principu: počáteční údaje - 3NF, vitríny - hvězda. Tento přístup, prověřený časem a podložený spoustou výzkumů, je první (a někdy i jediná) věc, která zkušeného specialistu na DWH napadne, když přemýšlí o tom, jak by měl vypadat analytický repozitář.
Na druhou stranu podnikání obecně a požadavky zákazníků zvláště mají tendenci se rychle měnit, zatímco data rostou „do hloubky“ i „do šířky“. A zde se objevuje hlavní nevýhoda hvězdy - omezená flexibilita.
A pokud ve vašem klidném a pohodlném životě vývojáře DWH najednou:
- vyvstal úkol „udělat alespoň něco rychle a pak se uvidí“;
- objevil se rychle se rozvíjející projekt s připojením nových zdrojů a změnou obchodního modelu alespoň jednou týdně;
- objevil se zákazník, který netuší, jak by měl systém vypadat a jaké funkce by měl nakonec plnit, ale je připraven na experimenty a důsledné dolaďování požadovaného výsledku s důsledným přístupem k němu;
- projektový manažer se podíval s dobrou zprávou: „A teď máme agilní!“.
Nebo pokud se jen chcete dozvědět, jak jinak můžete vytvořit úložiště - vítejte u kočky!
Co znamená "flexibilita"?
Pro začátek si definujme, jaké vlastnosti musí mít systém, aby byl nazýván „flexibilním“.
Samostatně stojí za zmínku, že popsané vlastnosti by se měly konkrétně týkat Systém, ne do proces jeho vývoj. Proto, pokud jste si chtěli přečíst o Agile jako metodologii vývoje, je lepší si přečíst další články. Například právě tam, na Habré, je spousta zajímavých materiálů (např и A ).
To neznamená, že proces vývoje a struktura datového skladu spolu zcela nesouvisí. Agilní vývoj agilního úložiště by měl být obecně mnohem jednodušší. V praxi je však více možností s Agilním vývojem klasického DWH podle Kimbala a DataVaultu - podle vodopádu než šťastných náhod flexibility v jejích dvou podobách na jednom projektu.
Jaké funkce by tedy flexibilní úložiště mělo mít? Jsou zde tři body:
- Včasné dodání a rychlé dokončení - to znamená, že v ideálním případě by měl být první obchodní výsledek (například první pracovní reporty) získán co nejdříve, tedy ještě předtím, než je celý systém navržen a implementován. Každá další revize by zároveň měla zabrat co nejméně času.
- Iterativní zpřesňování - to znamená, že každá další revize by v ideálním případě neměla ovlivnit již fungující funkčnost. Právě tento moment se ve velkých projektech často stává tou největší noční můrou – jednotlivé objekty začnou dříve nebo později získávat tolik vztahů, že je jednodušší zcela zopakovat logiku v kopii vedle sebe, než přidat pole do existující tabulky. A pokud vás překvapuje, že analýza dopadu vylepšení na stávající objekty může zabrat více času než samotná revize, pravděpodobně jste nepracovali s velkými datovými sklady v bankovnictví nebo telekomunikacích.
- Neustálé přizpůsobování se měnícím se obchodním požadavkům - obecná struktura objektu by měla být navržena nejen s ohledem na možné rozšíření, ale s očekáváním, že o směru tohoto dalšího rozšíření nebylo možné ve fázi návrhu ani snít.
A ano, splnění všech těchto požadavků v jednom systému je možné (samozřejmě v určitých případech as určitými výhradami).
Níže se podívám na dvě z nejpopulárnějších metod agilního návrhu pro HD − kotevní model и Datový trezor. Mimo závorky jsou tak vynikající triky jako například EAV, 6NF (v čisté podobě) a vše, co souvisí s NoSQL řešeními - ne proto, že by byla nějak horší, a ani proto, že by v tomto případě hrozilo, že článek získá objem průměrné disertační práce. To vše se jen týká řešení trochu jiné třídy – buď technik, které můžete aplikovat v konkrétních případech bez ohledu na obecnou architekturu vašeho projektu (jako EAV), nebo globálně odlišných paradigmat ukládání informací (jako jsou grafové databáze a další možnosti).NoSQL).
Problémy „klasického“ přístupu a jejich řešení ve flexibilních metodikách
Tím „klasickým“ přístupem mám na mysli starou dobrou hvězdu (bez ohledu na konkrétní implementaci podkladových vrstev, promiňte mi přívrženci Kimballa, Inmona a CDM).
1. Pevná mohutnost spojů
Tento model je založen na jasném rozdělení dat na rozměry (rozměr) и fakta (Fakt). A to je, zatraceně, logické - vždyť analýza dat v drtivé většině případů spočívá v analýze určitých číselných ukazatelů (faktů) v určitých úsecích (dimenzích).
Zároveň jsou vazby mezi objekty položeny ve formě vazeb mezi tabulkami cizím klíčem. Vypadá to docela přirozeně, ale okamžitě to vede k prvnímu omezení flexibility − přísné vymezení mohutnosti vztahů.
To znamená, že ve fázi návrhu tabulek musíte pro každou dvojici souvisejících objektů určit, zda mohou souviset jako mnoho k mnoha nebo pouze 1 k mnoha a „jakým směrem“. Přímo záleží na tom, která z tabulek bude mít primární klíč a která cizí. Změna tohoto poměru při přijetí nových požadavků s největší pravděpodobností povede k přepracování základny.
Například při navrhování objektu „pokladní stvrzenka“ jste, spoléhajíc se na přísežné ujištění obchodního oddělení, stanovili možnost akce jedno povýšení na několik kontrolních pozic (ale ne naopak):
A po čase kolegové představili novou marketingovou strategii, ve které více propagačních akcí současně. A nyní musíte dokončit tabulky zvýrazněním vztahu v samostatném objektu.
(Nyní je také potřeba vylepšit všechny odvozené objekty, do kterých se promo kontrola připojuje).
Odkazy v Data Vault a Anchor Model
Ukázalo se, že je docela jednoduché se takové situaci vyhnout: nemusíte věřit obchodnímu oddělení, stačí všechny vztahy jsou zpočátku uloženy v samostatných tabulkách a zpracovat jako many-to-many.
Tento přístup byl navržen Dan Linstedt jako součást paradigmatu Datový trezor a plně podporovány Lars Rönnbäck в Model kotvy.
V důsledku toho získáváme první charakteristický rys flexibilních metodologií:
Vztahy mezi objekty nejsou uloženy v atributech nadřazených entit, ale jsou samostatným typem objektů.
В Datový trezor takové tabulky se nazývají OdkazA Model kotvy - Kravata. Na první pohled jsou si velmi podobné, i když jejich odlišnosti nejsou vyčerpány názvem (o kterém bude řeč níže). V obou architekturách se mohou odkazové tabulky propojovat libovolný počet subjektů (ne nutně 2).
Tato na první pohled redundance poskytuje zásadní flexibilitu při dokončení. Taková struktura se stává tolerantní nejen ke změně mohutnosti stávajících odkazů, ale také k přidávání nových - pokud má nyní šeková pozice také vazbu na pokladníka, který ji porušil, bude vzhled takového odkazu jednoduše nadstavbou. přes existující tabulky bez ovlivnění jakýchkoli existujících objektů a procesů.
2. Duplikace dat
Druhý problém řešený flexibilními architekturami je v první řadě méně zřejmý a vlastní. měření typu SCD2 (pomalu se měnící měření druhého typu), i když nejen oni.
V klasickém úložišti je dimenze obvykle tabulka, která obsahuje náhradní klíč (jako PK) a sadu obchodních klíčů a atributů v samostatných sloupcích.
Pokud dimenze podporuje verzování, do standardní sady polí se přidají časové limity verzí a v úložišti se objeví více verzí na řádek ve zdroji (jedna pro každou změnu verzovaných atributů).
Pokud dimenze obsahuje alespoň jeden verzovaný atribut, který se často mění, počet verzí takové dimenze bude působivý (i když ostatní atributy nejsou verzované nebo se nikdy nemění), a pokud existuje několik takových atributů, počet verzí mohou z jejich počtu exponenciálně růst. Taková dimenze může zabírat značné množství místa na disku, ačkoli většina dat v ní uložených jsou jednoduše duplikáty neměnných hodnot atributů z jiných řádků.
Zároveň se také často používá denormalizace - některé atributy jsou záměrně uloženy jako hodnota, a nikoli jako odkaz na referenční knihu nebo jinou dimenzi. Tento přístup urychluje přístup k datům snížením počtu spojení při přístupu k dimenzi.
Obvykle to má za následek stejné informace jsou uloženy současně na několika místech. Například informace o regionu bydliště a členství v zákaznické kategorii lze současně ukládat do dimenzí „Zákazník“ a skutečností „Nákup“, „Doručení“ a „Kontakty call centra“ a také do „Zákazník - Tabulka odkazů Customer Manager“.
Obecně platí výše uvedené pro běžná (neverzovaná) měření, ale u verzovaných mohou mít jiné měřítko: vzhled nové verze objektu (zejména při zpětném pohledu) vede nejen k aktualizaci všech souvisejících tabulek, ale ke kaskádovému vzhledu nových verzí souvisejících objektů – když se tabulka 1 použije k sestavení tabulky 2 a tabulka 2 se použije k sestavení tabulky 3 a tak dále. I když se na konstrukci tabulky 1 nepodílí ani jeden atribut tabulky 3 (a další atributy tabulky 2 získané z jiných zdrojů), verzování této konstrukce povede přinejmenším k dodatečné režii a nanejvýš k další verze v tabulce 3, která obecně „s tím nemá nic společného“ a dále v řetězci.
3. Nelineární složitost zpřesňování
Každá nová výloha, která je postavena na druhé, zároveň zvyšuje počet míst, kde se data mohou „rozcházet“, když jsou provedeny změny v ETL. To zase vede ke zvýšení složitosti (a trvání) každé následující revize.
Pokud výše uvedené platí pro systémy se zřídka modifikovanými ETL procesy, můžete žít v takovém paradigmatu - jen se ujistěte, že nová vylepšení jsou správně provedena u všech souvisejících objektů. Pokud k revizím dochází často, pravděpodobnost náhodného „vynechání“ několika odkazů se výrazně zvyšuje.
Pokud navíc vezmeme v úvahu, že „verzované“ ETL je mnohem komplikovanější než „neverzované“, je při častém zdokonalování celé této ekonomiky poměrně obtížné vyhnout se chybám.
Ukládání objektů a atributů v Data Vault a Anchor Model
Přístup navržený autory flexibilních architektur lze formulovat následovně:
Je třeba oddělit to, co se mění, od toho, co zůstává nezměněno. To znamená ukládat klíče odděleně od atributů.
Nepleťte se však bez verze atribut s beze změny: první neukládá historii jeho změn, ale může se měnit (např. při opravě vstupní chyby nebo příjmu nových dat), druhý se nikdy nemění.
Názory na to, co přesně lze považovat za nezměněné v modelu Data Vault a Anchor, se liší.
Z hlediska architektury Datový trezor, lze považovat za nezměněné celou sadu klíčů — přirozené (DIČ organizace, kód produktu ve zdrojovém systému atd.) a náhradní. Zároveň lze zbývající atributy rozdělit do skupin podle zdroje a/nebo četnosti změn a vést samostatnou tabulku pro každou skupinu s nezávislou sadou verzí.
Ve stejném paradigmatu Model kotvy považovány za nezměněné pouze náhradní klíč entity. Všechno ostatní (včetně přirozených klíčů) je jen speciální případ jeho atributů. V čem všechny atributy jsou ve výchozím nastavení na sobě nezávislé, takže pro každý atribut musí být vytvořen samostatný stůl.
В Datový trezor volají se tabulky obsahující klíče entit Hubami (Hub). Huby vždy obsahují pevnou sadu polí:
- Klíče přirozených entit
- Náhradní klíč
- Odkaz na zdroj
- Doba nahrávání
Záznamy v Hubs nikdy se nemění a nemají žádné verze. Navenek jsou rozbočovače velmi podobné tabulkám map ID, které se v některých systémech používají ke generování náhradních položek, doporučuje se však jako zástupné položky v datovém trezoru používat nikoli celočíselnou sekvenci, ale hash ze sady obchodních klíčů. Tento přístup zjednodušuje načítání odkazů a atributů ze zdrojů (není třeba se připojovat k hubu, abyste získali náhradní, stačí vypočítat hash z přirozeného klíče), ale může způsobit další problémy (například s kolizemi, velikostí písmen a netisknutelnými znaky v klíčích řetězců atd.), takže není obecně přijímán.
Všechny ostatní atributy entity jsou uloženy ve speciálních tabulkách tzv Satelity (satelit). Jeden hub může mít několik satelitů, které ukládají různé sady atributů.
Rozdělení atributů mezi satelity probíhá podle principu kloubní změna - na jednom satelitu mohou být uloženy neverzované atributy (například datum narození a SNILS pro jednotlivce), na druhém - zřídka se měnící verze (například příjmení a číslo pasu), na třetím - často se měnící (například dodací adresa, kategorie, datum poslední objednávky atd.). Verze se v tomto případě provádí na úrovni jednotlivých satelitů, nikoli entity jako celku, proto je vhodné atributy distribuovat tak, aby průnik verzí v rámci jednoho satelitu byl minimální (což snižuje celkový počet uložených verzí).
Aby se optimalizoval proces načítání dat, jsou atributy získané z různých zdrojů často umístěny do samostatných satelitů.
Satelity komunikují s Hubem prostřednictvím cizí klíč (což odpovídá mohutnosti 1 ku mnoha). To znamená, že tato „výchozí“ architektura podporuje více hodnot atributů (například více kontaktních telefonních čísel pro stejného zákazníka).
В Model kotvy se nazývají tabulky, které ukládají klíče Kotvy. A uchovávají:
- Pouze náhradní klíče
- Odkaz na zdroj
- Doba nahrávání
Jsou uvažovány přirozené klíče z pohledu Anchor Model běžné atributy. Tato možnost se může zdát obtížnější na pochopení, ale poskytuje mnohem větší prostor pro identifikaci objektu.
Například pokud data o stejné entitě mohou pocházet z různých systémů, z nichž každý používá svůj vlastní přirozený klíč. V datovém trezoru to může vést k poměrně těžkopádným konstrukcím několika hub (jeden na zdroj + sloučená hlavní verze), zatímco v modelu Anchor spadá přirozený klíč každého zdroje do vlastního atributu a lze jej použít při načítání nezávisle na všechny ostatní.
Zde ale leží jeden záludný moment: pokud jsou atributy z různých systémů kombinovány v jedné entitě, s největší pravděpodobností nějaké existují pravidla lepidla, čímž systém musí pochopit, že záznamy z různých zdrojů odpovídají jedné instanci entity.
В Datový trezor tato pravidla pravděpodobně určí formaci „náhradní centrum“ hlavní entity a žádným způsobem neovlivní rozbočovače, které uchovávají přirozené klíče zdrojů a jejich původní atributy. Pokud se v určitém okamžiku změní pravidla pro slučování (nebo atributy, které se pro slučování používají), bude stačit znovu vytvořit náhradní uzly.
В kotevní model taková entita bude pravděpodobně uložena jediná kotva. To znamená, že všechny atributy, bez ohledu na to, z jakého zdroje jsou získány, budou vázány na stejnou náhradu. Oddělování chybně sloučených záznamů a obecně sledování relevance slučování v takovém systému může být mnohem obtížnější, zvláště pokud jsou pravidla poměrně složitá a často se mění a stejný atribut lze získat z různých zdrojů (ačkoli je to rozhodně možné, protože každá verze atributu si zachovává odkaz na svůj původ).
V každém případě, pokud má váš systém implementovat funkcionalitu deduplikace, slučování záznamů a další prvky MDM, měli byste si zvláště pečlivě přečíst aspekty ukládání přirozených klíčů ve flexibilních metodologiích. Možná je nemotornější design datového trezoru najednou bezpečnější, pokud jde o chyby slučování.
kotevní model také poskytuje další typ objektu nazvaný Uzel ve skutečnosti je to speciál degenerovaný typ kotvy, který může obsahovat pouze jeden atribut. Uzly mají sloužit pro ukládání plochých adresářů (např. pohlaví, rodinný stav, kategorie zákaznických služeb atd.). Na rozdíl od Anchor, Knot nemá žádné přidružené tabulky atributů, a jeho jediný atribut (název) je vždy uložen ve stejné tabulce s klíčem. Uzly jsou připojeny k Anchors pomocí vazebných tabulek stejným způsobem, jako jsou kotvy připojeny k sobě navzájem.
Neexistuje jednoznačný názor na použití Nodes. Například, , který aktivně propaguje používání kotevního modelu v Rusku, věří (ne bezdůvodně), že u jediné referenční knihy nelze říci, že vždy bude statický a jednoúrovňový, proto je lepší použít plnohodnotnou Anchor pro všechny objekty najednou.
Dalším důležitým rozdílem mezi Data Vault a Anchor Model je přítomnost atributy pro odkazy:
В Datový trezor Odkazy jsou stejné plnohodnotné objekty jako Huby a mohou mít vlastní atributy. V kotevní model Odkazy se používají pouze pro připojení kotev a nemůže mít své vlastní atributy. Tento rozdíl vede k výrazně odlišným přístupům k modelování. fakta, o kterém bude řeč dále.
Ukládání faktů
Dosud jsme se bavili především o modelářských měřeních. Fakta jsou o něco méně jasná.
В Datový trezor typický předmět pro uchovávání faktů − Odkaz, v jehož satelitech jsou přidány reálné ukazatele.
Tento přístup se zdá být intuitivní. Poskytuje snadný přístup k analyzovaným ukazatelům a je obecně podobný tradiční tabulce faktů (pouze ukazatele nejsou uloženy v tabulce samotné, ale v „sousední tabulce“). Existují však také úskalí: jedno z typických vylepšení modelu – rozšíření klíče faktů – vyžaduje přidání nového cizího klíče k odkazu. A to zase „narušuje“ modularitu a potenciálně způsobuje potřebu vylepšení jiných objektů.
В kotevní model Odkaz nemůže mít své vlastní atributy, takže tento přístup nebude fungovat - absolutně všechny atributy a indikátory musí být spojeny s jednou konkrétní kotvou. Závěr z toho je jednoduchý - každá skutečnost potřebuje také svou vlastní kotvu. Pro některé z toho, co jsme zvyklí vnímat jako fakta, se to může zdát přirozené – například fakt, že nákup je dokonale zredukován na objekt „objednávka“ nebo „účtenka“, návštěva webu je redukována na relaci atd. Existují však i skutečnosti, pro které není tak snadné najít takový přirozený „nosný předmět“ - například zůstatek zboží ve skladech na začátku každého dne.
V souladu s tím neexistují žádné problémy s modularitou při rozšiřování klíče faktů v modelu kotvy (stačí pouze přidat nový vztah k odpovídající kotvě), ale návrh modelu pro zobrazení faktů je méně přímočarý, mohou se objevit „umělé“ kotvy které odrážejí objektový model podniku, není zřejmé.
Jak je dosaženo flexibility
Výsledná konstrukce v obou případech obsahuje výrazně více stolůnež tradiční měření. Ale dá to zabrat výrazně méně místa na disku se stejnou sadou verzovaných atributů jako tradiční rozměr. Přirozeně zde není žádná magie – vše je o normalizaci. Distribucí atributů mezi satelity (v datovém trezoru) nebo jednotlivé tabulky (model kotvy) snižujeme (nebo úplně eliminujeme) duplikování hodnot některých atributů při změně jiných.
pro Datový trezor zisk bude záviset na rozložení atributů mezi satelity a pro kotevní model — je téměř přímo úměrná průměrnému počtu verzí na objekt měření.
Zabírání místa je však důležitou, nikoli však hlavní výhodou samostatného ukládání atributů. Spolu s odděleným ukládáním odkazů tento přístup vytváří úložiště Modulární design. To znamená, že přidání jednotlivých atributů i celých nových tematických oblastí do takového modelu vypadá nadstavbou přes existující sadu objektů bez jejich změny. A právě to činí popisované metodiky flexibilní.
Podobá se to také přechodu od kusové výroby k sériové výrobě – pokud je v tradičním přístupu každý modelový stůl jedinečný a vyžaduje samostatnou pozornost, pak ve flexibilních metodikách jde již o soubor typických „detailů“. Jednak je více tabulek, procesy načítání a načítání dat by měly vypadat složitější. Na druhou stranu se stávají typický. To znamená, že může existovat automatizované a spravované pomocí metadat. Otázka „jak budeme pokládat?“, jejíž zodpovězení by mohlo zabrat značnou část práce na návrhu vylepšení, nyní prostě nestojí za to (stejně jako otázka dopadu změny modelu na pracovní procesy).
To neznamená, že analytici v takovém systému nejsou vůbec potřeba – někdo musí pořád vypracovat sadu objektů s atributy a vymyslet, kde a jak to všechno nahrát. Ale množství práce, stejně jako pravděpodobnost a cena chyby, jsou výrazně sníženy. Jak ve fázi analýzy, tak během vývoje ETL, který lze z podstatné části redukovat na editaci metadat.
Tmavá strana
Díky všemu výše uvedenému jsou oba přístupy skutečně flexibilní, vyrobitelné a vhodné pro iterativní zdokonalování. Samozřejmě nechybí ani „barel dehtu“, o kterém myslím, že už víte.
Dekompozice dat, která je základem modularity flexibilních architektur, vede ke zvýšení počtu tabulek a v souladu s tím nad hlavou pro spojení při načítání. Aby bylo možné jednoduše získat všechny atributy dimenze, stačí v klasickém úložišti jediný výběr a flexibilní architektura bude vyžadovat řadu spojení. Navíc, pokud pro reporty mohou být všechna tato spojení zapsána předem, pak analytici, kteří jsou zvyklí psát SQL ručně, budou trpět dvojnásob.
Existuje několik skutečností, které tuto situaci usnadňují:
Při práci s velkými rozměry se téměř nikdy nepoužívají současně téměř všechny jeho atributy. To znamená, že spojení může být méně, než se na první pohled na model zdá. V Data Vaultu můžete při přidělování atributů satelitům zohlednit i očekávanou frekvenci sdílení. Samotné rozbočovače nebo kotvy jsou zároveň potřeba především pro generování a mapování náhradních prvků ve fázi načítání a zřídka se používají v dotazech (to platí zejména pro kotvy).
Všechna spojení jsou na klíč. Navíc „komprimovanější“ způsob ukládání dat snižuje režii skenování tabulek tam, kde je to potřeba (například při filtrování podle hodnoty atributu). To může vést k tomu, že načítání z normalizované databáze s hromadou spojení bude ještě rychlejší než skenování jedné těžké dimenze se spoustou verzí na řádek.
Například zde v článku je podrobný srovnávací test výkonu modelu Anchor s výběrem z jedné tabulky.
Hodně záleží na motoru. Mnoho moderních platforem má interní mechanismy pro optimalizaci spojení. Například MS SQL a Oracle mohou „přeskočit“ spojení k tabulkám, pokud jejich data nejsou použita nikde kromě jiných spojení a neovlivní konečný výběr (eliminace tabulky/spojení), zatímco MPP Vertica , se ukázal jako vynikající motor pro model Anchor s určitou manuální optimalizací plánu dotazů. Na druhou stranu ukládat Anchor Model například na Click House, který má omezenou podporu joinu, se zatím nezdá jako dobrý nápad.
Navíc pro obě architektury existují speciální triky, které usnadňují přístup k datům (jak z hlediska výkonu dotazů, tak pro koncové uživatele). Například, Tabulky bodů v čase v Datovém trezoru popř speciální tabulkové funkce v modelu kotvy.
Celkem
Hlavní podstatou uvažovaných flexibilních architektur je modularita jejich „designu“.
Tato vlastnost umožňuje:
- Po počáteční přípravě související s nasazením metadat a psaním základních algoritmů ETL, rychle poskytnout zákazníkovi první výsledek ve formě několika zpráv obsahujících data pouze z několika zdrojových objektů. K tomu není nutné plně promyslet (ani na nejvyšší úrovni) celý objektový model.
- Datový model může začít fungovat (a užitečný) s pouhými 2-3 objekty a pak postupně rostou (pokud jde o model Anchor Nikolay krásné srovnání s myceliem).
- Většina vylepšení, včetně rozšíření oblasti předmětu a přidání nových zdrojů neovlivňuje stávající funkčnost a nezpůsobuje nebezpečí rozbití něčeho, co již funguje.
- Díky rozkladu na standardní prvky vypadají ETL procesy v takových systémech stejně, jejich zápis se hodí k algoritmizaci a v konečném důsledku automatizace.
Cena této flexibility je výkon. To neznamená, že na takových modelech není možné dosáhnout přijatelného výkonu. Více často než ne, jen možná budete potřebovat více úsilí a pozornosti k detailům, abyste dosáhli požadovaných metrik.
Aplikace
Typy entit Datový trezor
Více o Datovém trezoru:
Typy entit Model kotvy
Více o modelu Anchor:
Souhrnná tabulka se společnými rysy a rozdíly mezi uvažovanými přístupy:
Zdroj: www.habr.com