Að þróa geymsluaðstöðu er langt og alvarlegt verkefni.
Mikið í líftíma verkefnis fer eftir því hversu vel hlutalíkanið og grunnbyggingin eru úthugsuð í upphafi.
Almennt viðurkennd nálgun hefur verið og er enn ýmis afbrigði af því að sameina stjörnukerfið við þriðja eðlilega form. Sem reglu, samkvæmt meginreglunni: upphafsgögn - 3NF, sýningarskápar - stjarna. Þessi nálgun, tímaprófuð og studd af miklu magni rannsókna, er það fyrsta (og stundum eina) sem kemur upp í huga reyndra sérfræðings í DWH þegar hann hugsar um hvernig greiningargeymsla ætti að líta út.
Á hinn bóginn hafa viðskipti almennt og kröfur viðskiptavina sérstaklega tilhneigingu til að breytast hratt og gögn hafa tilhneigingu til að vaxa bæði „í dýpt“ og „í breidd“. Og þetta er þar sem helsti ókostur stjörnu birtist - takmarkaður sveigjanleiki.
Og ef þú ert í rólegu og notalegu lífi þínu sem DWH verktaki skyndilega:
- verkefnið kom upp "að gera að minnsta kosti eitthvað fljótt, og þá sjáum við til";
- verkefni sem þróaðist hratt, með tengingu nýrra heimilda og endurvinnslu viðskiptamódelsins að minnsta kosti einu sinni í viku;
- viðskiptavinur hefur birst sem hefur ekki hugmynd um hvernig kerfið ætti að líta út og hvaða aðgerðir það ætti að framkvæma á endanum, en er tilbúinn til að gera tilraunir og stöðugt betrumbæta æskilega niðurstöðu á sama tíma og hann kemst stöðugt nær henni;
- Verkefnastjórinn kíkti við með góðu fréttirnar: „Og nú erum við með lipurð!“
Eða ef þú hefur bara áhuga á að komast að því hvernig annað er hægt að byggja upp geymslur - velkomin í klippinguna!
Hvað þýðir "sveigjanleiki"?
Í fyrsta lagi skulum við skilgreina hvaða eiginleika kerfi verður að hafa til að vera kallað „sveigjanlegt“.
Sérstaklega er rétt að nefna að lýstar eignir ættu að tengjast sérstaklega kerfi, ekki að ferli þróun þess. Þess vegna, ef þú vildir lesa um Agile sem þróunaraðferðafræði, er betra að lesa aðrar greinar. Til dæmis, þarna, á Habré, er mikið af áhugaverðu efni (eins og и Og ).
Þetta þýðir ekki að þróunarferlið og uppbygging gagnageymslunnar séu algjörlega ótengd. Á heildina litið ætti það að vera verulega auðveldara að þróa Agile geymslu fyrir lipran arkitektúr. Hins vegar, í reynd, eru oftar valkostir með Agile þróun á klassískum DWH samkvæmt Kimbal og DataVault - samkvæmt Waterfall, en ánægjulegar tilviljanir sveigjanleika í tveimur myndum í einu verkefni.
Svo, hvaða getu ætti sveigjanleg geymsla að hafa? Hér eru þrír punktar:
- Snemma afhending og fljótur afgreiðsla - þetta þýðir að helst ætti að fá fyrstu viðskiptaniðurstöðuna (til dæmis fyrstu vinnuskýrslurnar) eins fljótt og auðið er, það er jafnvel áður en allt kerfið er að fullu hannað og innleitt. Þar að auki ætti hver síðari endurskoðun einnig að taka eins stuttan tíma og mögulegt er.
- Endurtekið betrumbætur - þetta þýðir að hver síðari endurbót ætti helst ekki að hafa áhrif á virknina sem þegar er að virka. Það er þetta augnablik sem verður oft mesta martröð stórra verkefna - fyrr eða síðar byrja einstakir hlutir að ná svo mörgum tengingum að það verður auðveldara að endurtaka rökfræðina algjörlega í afriti í nágrenninu en að bæta reit við núverandi töflu. Og ef þú ert hissa á því að greina áhrif endurbóta á núverandi hluti getur tekið lengri tíma en endurbæturnar sjálfar, hefur þú líklega ekki enn unnið með stór gagnageymslur í banka eða fjarskiptum.
- Stöðugt aðlagast breyttum viðskiptakröfum - heildarbygging hlutar ætti að vera hönnuð ekki bara með hliðsjón af mögulegri stækkun, heldur með von um að ekki væri einu sinni hægt að láta sig dreyma um stefnu þessarar næstu stækkunar á hönnunarstigi.
Og já, það er mögulegt að uppfylla allar þessar kröfur í einu kerfi (auðvitað, í vissum tilvikum og með einhverjum fyrirvörum).
Hér að neðan mun ég íhuga tvær af vinsælustu lipur hönnunaraðferðum fyrir vöruhús gagna - Akkeri líkan и Data Vault. Utan við sviga eru svo frábærar aðferðir eins og til dæmis EAV, 6NF (í sinni hreinu mynd) og allt sem tengist NoSQL lausnum - ekki vegna þess að þær séu einhvern veginn verri, og ekki einu sinni vegna þess að í þessu tilfelli myndi greinin hóta að eignast rúmmál meðalritgerðar. Það er bara það að allt þetta tengist lausnum af örlítið öðrum flokki - annað hvort tækni sem þú getur notað í sérstökum tilfellum, óháð heildararkitektúr verkefnisins þíns (eins og EAV), eða öðrum gagnageymslum á heimsvísu (svo sem grafgagnagrunna og aðrir valkostir NoSQL).
Vandamál „klassísku“ nálgunarinnar og lausnir þeirra í sveigjanlegri aðferðafræði
Með „klassískri“ nálgun á ég við gömlu góðu stjörnuna (burtséð frá sértækri útfærslu undirliggjandi laganna, mega fylgjendur Kimball, Inmon og CDM fyrirgefa mér).
1. Stífur kardinalitet tenginga
Þetta líkan byggir á skýrri skiptingu gagna í Stærð и staðreyndir. Og þetta, fjandinn hafi það, er rökrétt - þegar allt kemur til alls kemur gagnagreining í yfirgnæfandi meirihluta tilfella niður á greiningu á ákveðnum tölulegum vísbendingum (staðreyndum) í ákveðnum hlutum (víddum).
Í þessu tilviki eru tengingar milli hluta komið á í formi tengsla milli taflna með því að nota erlendan lykil. Þetta lítur eðlilega út, en leiðir strax til fyrstu takmörkunar á sveigjanleika - ströng skilgreining á aðalgildi tenginga.
Þetta þýðir að á töfluhönnunarstigi verður þú að ákvarða nákvæmlega fyrir hvert par af tengdum hlutum hvort þeir geti tengst eins mörgum og mörgum, eða aðeins 1 við marga, og „í hvaða átt“. Þetta ákvarðar beint hvaða tafla mun hafa aðallykilinn og hver mun hafa erlenda lykilinn. Breyting á þessu viðhorfi þegar nýjar kröfur berast mun líklega leiða til endurvinnslu grunnsins.
Til dæmis, þegar þú hannar „reiðufékvittun“ hlutinn, reiddir þú þig á eið söludeildarinnar og lagðir fram möguleika á aðgerðum ein kynning fyrir nokkrar ávísanastöður (en ekki öfugt):
Og eftir nokkurn tíma kynntu samstarfsmenn nýja markaðsstefnu þar sem þeir geta brugðist við sömu stöðu nokkrar kynningar á sama tíma. Og nú þarftu að breyta töflunum með því að aðgreina sambandið í sérstakan hlut.
(Allir afleiddir hlutir sem kynningarávísunin er sameinuð í þarf nú einnig að bæta).
Tengsl í Data Vault og Anchor Model
Það reyndist frekar einfalt að forðast þetta ástand: þú þarft ekki að treysta söludeildinni til að gera þetta. allar tengingar eru upphaflega geymdar í aðskildum töflum og vinna það sem marga-til-marga.
Þessi leið var lögð til Dan Linstedt sem hluti af hugmyndafræðinni Data Vault og fullum stuðningi Lars Rönnbäck в Akkerislíkan.
Fyrir vikið fáum við fyrsta sérkenni sveigjanlegra aðferðafræði:
Tengsl milli hluta eru ekki geymd í eiginleikum foreldraeininga, heldur eru þau sérstök tegund hlutar.
В Data Vault slíkar tengitöflur eru kallaðar Link, og inn Akkerislíkan - Tie. Við fyrstu sýn eru þau mjög lík, þó munur þeirra endi ekki með nafninu (sem verður fjallað um hér að neðan). Í báðum arkitektúrum geta tenglatöflur tengst hvaða fjölda aðila sem er (ekki endilega 2).
Þessi offramboð, við fyrstu sýn, veitir verulegan sveigjanleika fyrir breytingar. Slík uppbygging verður ekki aðeins umburðarlynd fyrir breytingum á aðalgildi núverandi hlekkja, heldur einnig við að bæta við nýjum - ef nú ávísanastaða hefur einnig tengingu við gjaldkerann sem braut í gegnum hana, mun útlit slíks hlekks einfaldlega verða viðbót yfir núverandi töflur án þess að hafa áhrif á núverandi hluti og ferla.
2. Tvíföldun gagna
Annað vandamálið sem leyst er með sveigjanlegum arkitektúr er minna augljóst og er eðlislægt í fyrsta lagi. SCD2 gerð mælingar (hægt breytast stærðir af annarri gerðinni), þó ekki aðeins þær.
Í klassísku vöruhúsi er vídd venjulega tafla sem inniheldur staðgöngulykil (sem PK) og sett af viðskiptalykla og eiginleikum í aðskildum dálkum.
Ef vídd styður útgáfugerð, er gildismörkum útgáfu bætt við staðlaða reitahópinn og nokkrar útgáfur birtast í geymslunni fyrir eina línu í upprunanum (ein fyrir hverja breytingu á útgefnum eiginleikum).
Ef vídd inniheldur að minnsta kosti eina útgáfu sem breytist oft, mun fjöldi útgáfur af slíkri vídd vera áhrifamikill (jafnvel þó að eigindirnar sem eftir eru séu ekki útgáfur eða breytist aldrei), og ef það eru nokkrir slíkir eiginleikar getur fjöldi útgáfur vaxa veldishraða frá fjölda þeirra. Þessi vídd getur tekið umtalsvert magn af plássi, þó að mikið af gögnunum sem hún geymir séu einfaldlega afrit af óbreytanlegum eigindagildum úr öðrum röðum.
Á sama tíma er það líka mjög oft notað afeðlun — sumir eiginleikar eru viljandi geymdir sem gildi, en ekki sem tengill á uppflettibók eða aðra vídd. Þessi nálgun flýtir fyrir gagnaaðgangi og dregur úr fjölda samtenginga þegar vídd er opnuð.
Venjulega leiðir þetta til sömu upplýsingar eru geymdar samtímis á nokkrum stöðum. Til dæmis er hægt að geyma upplýsingar um búsetusvæðið og flokk viðskiptavinarins samtímis í „Viðskiptavinur“ víddunum og „Kaup“, „Afhending“ og „Símtöl í símaver“, sem og í „Viðskiptavinur - Viðskiptastjóri ” tenglatöflu.
Almennt gildir ofangreint um venjulegar (óútgáfur) víddir, en í útgáfum geta þær haft annan mælikvarða: útlit nýrrar útgáfu hlutar (sérstaklega eftir á að hyggja) leiðir ekki aðeins til uppfærslu allra tengdra töflur, en að útliti nýrra útgáfa af skyldum hlutum, þegar töflu 1 er notuð til að smíða töflu 2, og tafla 2 er notuð til að smíða töflu 3 o.s.frv. Jafnvel þó að ekki einn eiginleiki í töflu 1 komi við sögu í smíði töflu 3 (og aðrir eiginleikar töflu 2 sem fengnir eru frá öðrum aðilum koma við sögu), mun útgáfa þessarar smíði að lágmarki leiða til viðbótarkostnaðar og að hámarki til viðbótar. útgáfur í töflu 3. sem hefur ekkert með það að gera, og neðar í keðjunni.
3. Ólínulegt flókið endurvinnslu
Á sama tíma eykur hver ný verslun sem byggð er á öðrum stöðum fjölda staða þar sem gögn geta „misleitt“ þegar breytingar eru gerðar á ETL. Þetta leiðir aftur til þess að flókið (og tímalengd) hverrar síðari endurskoðunar eykst.
Ef ofangreint lýsir kerfum með sjaldan breyttum ETL ferlum geturðu lifað í slíkri hugmyndafræði - þú þarft bara að ganga úr skugga um að nýjar breytingar séu rétt gerðar á öllum tengdum hlutum. Ef endurskoðanir eiga sér stað oft, aukast líkurnar á því að „missa“ nokkrar tengingar óvart verulega.
Ef við tökum að auki með í reikninginn að „útgáfa“ ETL er umtalsvert flóknari en „óútgáfa“, þá verður það frekar erfitt að forðast mistök þegar þú uppfærir alla þessa aðstöðu oft.
Að geyma hluti og eiginleika í Data Vault og Anchor Model
Hægt er að móta nálgunina sem höfundar sveigjanlegra arkitektúra leggja til sem hér segir:
Nauðsynlegt er að aðgreina það sem breytist frá því sem er óbreytt. Það er að segja að geyma lykla aðskilda frá eiginleikum.
Hins vegar ætti maður ekki að rugla saman ekki útgáfa eiginleiki með óbreytt: sá fyrri geymir ekki sögu breytinga sinna, en getur breyst (til dæmis þegar innsláttarvilla er leiðrétt eða ný gögn eru móttekin); sá síðari breytist aldrei.
Sjónarmið eru ólík um hvað nákvæmlega geti talist óbreytanlegt í Data Vault og Anchor Model.
Frá byggingarfræðilegu sjónarmiði Data Vault, má telja óbreytt allt sett af lyklum - náttúrulegt (TIN fyrirtækis, vörukóði í frumkerfi o.s.frv.) og staðgengill. Í þessu tilviki er hægt að skipta eiginleikum sem eftir eru í hópa eftir uppruna og/eða tíðni breytinga og Halda sérstakri töflu fyrir hvern hóp með sjálfstæðum útgáfum.
Í hugmyndafræðinni Akkerislíkan talið óbreytt aðeins staðgöngulykill kjarna. Allt annað (þar á meðal náttúrulyklar) er bara sérstakt tilfelli af eiginleikum þess. Þar sem allir eiginleikar eru sjálfgefið óháðir hver öðrum, svo fyrir hverja eigind a sér borð.
В Data Vault kallaðar eru töflur sem innihalda einingalykla Hubami. Miðstöðvar innihalda alltaf fast sett af reitum:
- Natural Entity Keys
- Staðgöngulykill
- Tengill á heimild
- Skrá bæti tíma
Færslur í Hubs breytast aldrei og hafa engar útgáfur. Að utan eru miðstöðvar mjög svipaðar töflum af ID-korti sem notaðar eru í sumum kerfum til að búa til staðgöngum, hins vegar er mælt með því að nota kjötkássa úr safni viðskiptalykla sem staðgöngum í Data Vault. Þessi nálgun einfaldar hleðslusambönd og eiginleika frá heimildum (engin þörf á að tengjast miðstöðinni til að fá staðgengill, reiknaðu bara kjötkássa náttúrulykils), en getur valdið öðrum vandamálum (t.d. tengdum árekstrum, hástöfum og óprentanlegum stafi í strengjalyklum o.s.frv. .p.), því er það ekki almennt viðurkennt.
Allar aðrar einingareiginleikar eru geymdar í sérstökum töflum sem kallast Gervihnöttar. Ein miðstöð getur haft nokkur gervitungl sem geymir mismunandi sett af eiginleikum.
Dreifing eiginda á milli gervitungla fer samkvæmt meginreglunni liðskipti — í einum gervihnött er hægt að geyma óútgáfu eiginleika (til dæmis fæðingardag og SNILS fyrir einstakling), í öðrum - sjaldan breyta útgáfum (til dæmis eftirnafn og vegabréfsnúmer), í þeim þriðja - oft breytast (t.d. heimilisfang afhendingar, flokkur, dagsetning síðustu pöntunar osfrv.). Í þessu tilviki er útgáfa gerð á stigi einstakra gervihnötta, en ekki einingarinnar í heild, svo það er ráðlegt að dreifa eiginleikum þannig að skurðpunktur útgáfur innan eins gervihnött sé í lágmarki (sem dregur úr heildarfjölda geymdra útgáfur ).
Einnig, til að hámarka gagnahleðsluferlið, eru eiginleikar sem fengnir eru frá ýmsum aðilum oft innifaldir í einstökum gervihnöttum.
Gervihnöttar hafa samskipti við miðstöðina í gegnum erlendur lykill (sem samsvarar 1-til-mörgum kardinalitet). Þetta þýðir að mörg eigindagildi (til dæmis mörg tengiliðasímanúmer fyrir einn viðskiptavin) eru studd af þessum „sjálfgefna“ arkitektúr.
В Akkerislíkan töflur sem geyma lykla eru kallaðar Akkeri. Og þeir halda:
- Aðeins staðgöngulyklar
- Tengill á heimild
- Skrá bæti tíma
Náttúrulegir lyklar frá sjónarhóli Akkerislíkans eru teknir til greina venjulegir eiginleikar. Þessi valkostur kann að virðast erfiðari að skilja, en hann gefur miklu meira svigrúm til að bera kennsl á hlutinn.
Til dæmis, ef gögn um sömu aðila geta komið frá mismunandi kerfum, sem hvert um sig notar sinn náttúrulega lykil. Í Data Vault getur þetta leitt til frekar fyrirferðarmikillar uppbyggingar nokkurra miðstöðva (einn fyrir hverja uppsprettu + sameinandi aðalútgáfu), en í Anchor líkaninu fellur náttúrulegur lykill hverrar uppsprettu í eigin eiginleika og hægt er að nota hann við hleðslu óháð allir hinir.
En það er líka einn skaðlegur punktur hér: ef eiginleikar frá mismunandi kerfum eru sameinaðir í einni heild, þá eru líklega einhverjir reglur um "líma", þar sem kerfið verður að skilja að færslur frá mismunandi aðilum samsvara einu tilviki einingarinnar.
В Data Vault þessar reglur munu líklegast ráða mynduninni „staðgöngumiðstöð“ aðaleiningarinnar og hafa ekki á nokkurn hátt áhrif á Hubs sem geyma náttúrulega upprunalykla og upprunalega eiginleika þeirra. Ef samrunareglurnar breytast á einhverjum tímapunkti (eða eiginleikarnir sem það er framkvæmt með eru uppfærðir), mun það duga til að endursníða staðgöngumiðstöðina.
В Akkeri líkan slík eining verður líklega geymd í eina akkerið. Þetta þýðir að allir eiginleikar, sama hvaða uppruna þeir koma frá, verða bundnir sama staðgengil. Það getur verið mun erfiðara að aðskilja ranglega sameinaðar færslur og almennt fylgjast með mikilvægi sameiningar í slíku kerfi, sérstaklega ef reglurnar eru nokkuð flóknar og breytast oft, og sama eiginleika er hægt að fá frá mismunandi aðilum (þó það sé vissulega mögulegt, þar sem hver eigindaútgáfan heldur tengli við uppruna sinn).
Í öllum tilvikum, ef kerfið þitt á að innleiða virknina aftvíföldun, sameiningu gagna og annarra MDM þátta, það er þess virði að borga sérstaka athygli á þáttum geymslu náttúrulykla í lipri aðferðafræði. Það er líklegt að fyrirferðarmeiri Data Vault hönnunin verði skyndilega öruggari hvað varðar sameiningarvillur.
Akkeri líkan býður einnig upp á viðbótarhlutategund sem kallast Hnútur það er í rauninni sérstakt úrkynjað gerð akkeris, sem getur aðeins innihaldið einn eiginleika. Hnútarnir eiga að vera notaðir til að geyma flatar möppur (til dæmis kyn, hjúskaparstaða, þjónustuflokkur osfrv.). Ólíkt akkerinu, hnútnum hefur engar tengdar eigindatöflur, og eini eiginleiki þess (nafn) er alltaf geymdur í sömu töflu með lyklinum. Hnútar eru tengdir við akkeri með jafnteflistöflum (Tie) á sama hátt og akkeri eru tengd við hvert annað.
Það er engin skýr skoðun varðandi notkun hnúta. Til dæmis, , sem styður virkan notkun á akkerislíkaninu í Rússlandi, telur (ekki að ósekju) að fyrir ekki eina uppflettibók sé hægt að fullyrða með vissu að það alltaf verður kyrrstætt og á einu stigi, svo það er betra að nota strax fullbúið akkeri fyrir alla hluti.
Annar mikilvægur munur á Data Vault og Anchor líkaninu er framboðið eiginleika tenginga:
В Data Vault Tenglar eru sömu fullgildu hlutir og Hubs, og geta haft eigin eiginleika. Í Akkeri líkan Tenglar eru aðeins notaðir til að tengja akkeri og geta ekki haft sína eigin eiginleika. Þessi munur leiðir til marktækt mismunandi líkanaaðferða staðreyndir, sem nánar verður fjallað um.
Staðreynda geymsla
Áður en þetta ræddi við aðallega um mælingarlíkan. Staðreyndirnar eru aðeins óljósari.
В Data Vault dæmigerður hlutur til að geyma staðreyndir er Tengill, þar sem raunverulegum vísum er bætt við.
Þessi nálgun virðist leiðandi. Það veitir greiðan aðgang að greindu vísbendingunum og er almennt svipað og hefðbundin staðreyndatöflu (aðeins vísbendingar eru geymdar ekki í töflunni sjálfri heldur í „nágranna“ töflunni). En það eru líka gildrur: ein af dæmigerðum breytingum á líkaninu - stækkun staðreyndalykillsins - krefst þess að bæta nýjum erlendum lykli við Link. Og þetta aftur „brjótur“ mátinn og veldur hugsanlega þörf fyrir breytingar á öðrum hlutum.
В Akkeri líkan Tenging getur ekki haft sína eigin eiginleika, þannig að þessi nálgun mun ekki virka - algjörlega allir eiginleikar og vísbendingar verða að vera tengdir við eitt ákveðið akkeri. Niðurstaðan af þessu er einföld - Hver staðreynd þarf líka sitt akkeri. Fyrir sumt af því sem við erum vön að skynja sem staðreyndir gæti þetta litið eðlilega út - til dæmis er hægt að draga úr staðreyndum um kaup fullkomlega í hlutinn „pöntun“ eða „kvittun“, heimsókn á síðu á fundi osfrv. En það eru líka staðreyndir sem það er ekki svo auðvelt að finna svo náttúrulegan „flutningshlut“ fyrir - til dæmis leifar af vörum í vöruhúsum í upphafi hvers dags.
Í samræmi við það koma ekki upp vandamál með mát þegar stækkað er staðreyndalykill í Akkeri líkaninu (það er nóg að bæta einfaldlega nýju sambandi við samsvarandi Akkeri), en það er minna ótvírætt að hanna líkan til að sýna staðreyndir; „gervi“ akkeri geta birst sem sýna viðskiptahlutalíkanið á óljósan hátt.
Hvernig sveigjanleika er náð
Byggingin sem myndast í báðum tilvikum inniheldur verulega fleiri borðen hefðbundin mæling. En það getur tekið verulega minna diskpláss með sama sett af útfærðum eiginleikum og hefðbundin vídd. Auðvitað eru engir töfrar hér - þetta snýst allt um eðlilegt ástand. Með því að dreifa eiginleikum á gervihnöttum (í gagnahvelfingunni) eða einstökum töflum (akkerislíkan), minnkum við (eða útrýmum algjörlega) tvítekning á gildum sumra eiginleika þegar öðrum er breytt.
Fyrir Data Vault vinningarnir munu ráðast af dreifingu eiginleika meðal gervihnöttanna, og fyrir Akkeri líkan — er nánast í réttu hlutfalli við meðalfjölda útgáfur á hvern mælihlut.
Hins vegar er plásssparnaður mikilvægur kostur en ekki aðal kosturinn við að geyma eiginleika sérstaklega. Ásamt aðskildum geymslu samböndum gerir þessi nálgun verslunina mát hönnun. Þetta þýðir að það lítur út fyrir að bæta við bæði einstökum eiginleikum og heilum nýjum efnissviðum í slíku líkani yfirbygging yfir núverandi safn af hlutum án þess að breyta þeim. Og það er einmitt það sem gerir aðferðafræðina sem lýst er sveigjanleg.
Þetta líkist líka umskiptin frá stykki framleiðslu til fjöldaframleiðslu - ef í hefðbundinni nálgun er hvert borð líkansins einstakt og krefst sérstakrar athygli, þá er það í sveigjanlegri aðferðafræði þegar sett af stöðluðum "hlutum". Annars vegar eru fleiri töflur og ferlar við að hlaða og sækja gögn ættu að líta flóknari út. Á hinn bóginn verða þeir dæmigerður. Sem þýðir að það gæti verið sjálfvirk og lýsigagnadrifin. Spurningin „hvernig ætlum við að leggja það?“, sem svarið gæti tekið umtalsverðan hluta vinnunnar við að hanna umbætur, er nú einfaldlega ekki þess virði (sem og spurningin um áhrif þess að breyta líkaninu á vinnuferla ).
Þetta þýðir ekki að það sé alls ekki þörf á sérfræðingum í slíku kerfi - einhver þarf samt að vinna í gegnum safnið af hlutum með eiginleikum og finna út hvar og hvernig á að hlaða þessu öllu saman. En vinnumagnið, sem og líkur og kostnaður við villu, minnka verulega. Bæði á greiningarstigi og við þróun ETL, sem að verulegum hluta má minnka við að breyta lýsigögnum.
Myrkur hlið
Allt ofangreint gerir báðar aðferðir sannarlega sveigjanlegar, tæknilega háþróaðar og hentugar fyrir endurteknar umbætur. Auðvitað er líka „tunna í smyrslinu“ sem ég held að þú getir nú þegar giskað á.
Niðurbrot gagna, sem liggur til grundvallar máta sveigjanlegra arkitektúra, leiðir til fjölgunar taflna og í samræmi við það, yfir höfuð að sameinast við sýnatöku. Til þess að fá einfaldlega alla eiginleika víddar nægir eitt val í klassískri verslun, en sveigjanlegur arkitektúr mun krefjast heilrar röð af samskeytum. Þar að auki, ef hægt er að skrifa allar þessar sameiningar fyrir skýrslur fyrirfram, munu sérfræðingar sem eru vanir að skrifa SQL í höndunum þjást tvöfalt.
Það eru nokkrar staðreyndir sem auðvelda þetta ástand:
Þegar unnið er með stórar stærðir eru allir eiginleikar þess nánast aldrei notaðir samtímis. Þetta þýðir að tengingar gætu verið færri en það virðist við fyrstu sýn á líkanið. Data Vault getur einnig tekið tillit til væntanlegrar tíðni samnýtingar þegar eiginleikum er úthlutað til gervitungla. Á sama tíma þarf Hubs eða Akkeri sjálfir fyrst og fremst til að búa til og kortleggja staðgöngum á hleðslustigi og eru sjaldan notuð í fyrirspurnum (þetta á sérstaklega við um Akkeri).
Allar tengingar eru eftir lyklum. Að auki dregur „þjappaðari“ leið til að geyma gögn úr kostnaði við að skanna töflur þar sem þess er þörf (til dæmis þegar síað er eftir eigindargildi). Þetta getur leitt til þess að sýnatöku úr eðlilegum gagnagrunni með fullt af samskeytum verður jafnvel hraðari en að skanna eina þunga vídd með mörgum útgáfum í hverri röð.
Til dæmis, hér í Greinin inniheldur ítarlegt samanburðarpróf á frammistöðu Anchor líkansins með sýnishorni úr einni töflu.
Mikið veltur á vélinni. Margir nútímalegir pallar eru með innri hagræðingaraðferðir fyrir sameiningu. Til dæmis geta MS SQL og Oracle „sleppt“ tengingum við töflur ef gögn þeirra eru hvergi notuð nema fyrir aðrar tengingar og hafa ekki áhrif á endanlegt val (útrýming töflu/tengingar) og MPP Vertica , hefur reynst frábær vél fyrir Akkerislíkanið, enda handvirk hagræðing á fyrirspurnaráætluninni. Aftur á móti lítur það ekki út fyrir að vera mjög góð hugmynd að geyma Akkerislíkanið, til dæmis á Click House, sem hefur takmarkaðan stuðning við sameiningu.
Að auki, fyrir báða byggingarlistina eru til sérstakar hreyfingar, sem gerir gagnaaðgang auðveldari (bæði út frá frammistöðu fyrirspurna og fyrir endanotendur). Til dæmis, Tímatöflur í Data Vault eða sérstakar töfluaðgerðir í Anchor líkaninu.
Alls
Helstu kjarninn í hinum álitna sveigjanlega arkitektúr er máta „hönnun“ þeirra.
Það er þessi eign sem leyfir:
- Eftir smá undirbúning í tengslum við dreifingu lýsigagna og ritun grunn ETL reiknirit, veita viðskiptavinum fljótt fyrstu niðurstöðu í formi nokkurra skýrslna sem innihalda gögn frá örfáum upprunahlutum. Það er ekki nauðsynlegt að hugsa í gegn (jafnvel á efsta stigi) allt hlutlíkanið.
- Gagnalíkan getur byrjað að virka (og verið gagnlegt) með aðeins 2-3 hlutum og svo vaxa smám saman (Varðandi Anchor fyrirsætan Nikolai ágætur samanburður við mycelium).
- Flestar endurbætur, þar á meðal að stækka viðfangsefnið og bæta við nýjum heimildum hefur ekki áhrif á núverandi virkni og hefur ekki í för með sér hættu á að eitthvað brotni sem þegar er að virka.
- Þökk sé niðurbroti í staðlaða þætti líta ETL ferlar í slíkum kerfum eins út, skrif þeirra hentar sér til reikniritunar og að lokum, sjálfvirkni.
Verðið á þessum sveigjanleika er frammistaða. Þetta þýðir ekki að það sé ómögulegt að ná viðunandi frammistöðu á slíkum gerðum. Oftar en ekki gætirðu einfaldlega þurft meiri fyrirhöfn og athygli á smáatriðum til að ná þeim mæligildum sem þú vilt.
Apps
Tegundir eininga Data Vault
Nánari upplýsingar um Data Vault:
Tegundir eininga Akkerislíkan
Nánari upplýsingar um Anchor Model:
Yfirlitstafla með sameiginlegum eiginleikum og mismunandi aðferðum sem litið er til:
Heimild: www.habr.com