Mae datblygu cyfleuster storio yn dasg hir a difrifol.
Mae llawer ym mywyd prosiect yn dibynnu ar ba mor dda y meddylir am y model gwrthrych a'r strwythur sylfaen ar y dechrau.
Mae'r dull a dderbynnir yn gyffredinol wedi bod ac yn parhau i fod yn amrywiol amrywiadau o gyfuno'r cynllun seren â'r drydedd ffurf arferol. Fel rheol, yn ôl yr egwyddor: data cychwynnol - 3NF, arddangosfeydd - seren. Y dull hwn, wedi'i brofi gan amser ac wedi'i gefnogi gan lawer iawn o ymchwil, yw'r peth cyntaf (ac weithiau'r unig beth) sy'n dod i feddwl arbenigwr DWH profiadol wrth feddwl am sut y dylai ystorfa ddadansoddol edrych.
Ar y llaw arall, mae busnes yn gyffredinol a gofynion cwsmeriaid yn arbennig yn tueddu i newid yn gyflym, ac mae data’n tueddu i dyfu’n “dwfn” ac “yn eang”. A dyma lle mae prif anfantais seren yn ymddangos - cyfyngedig hyblygrwydd.
Ac os yn eich bywyd tawel a chlyd fel datblygwr DWH yn sydyn:
- cododd y dasg “gwneud rhywbeth yn gyflym o leiaf, ac yna cawn weld”;
- ymddangosodd prosiect a oedd yn datblygu'n gyflym, gyda chysylltiadau ffynonellau newydd ac ailwampio'r model busnes o leiaf unwaith yr wythnos;
- mae cwsmer wedi ymddangos nad oes ganddo unrhyw syniad sut y dylai'r system edrych a pha swyddogaethau y dylai eu cyflawni yn y pen draw, ond sy'n barod i arbrofi a mireinio'r canlyniad a ddymunir yn gyson tra'n dod yn agosach ato'n gyson;
- Galwodd rheolwr y prosiect i mewn gyda’r newyddion da: “A nawr mae gennym ni ystwyth!”
Neu os oes gennych ddiddordeb mewn darganfod sut arall y gallwch adeiladu cyfleusterau storio - croeso i'r toriad!
Beth mae "hyblygrwydd" yn ei olygu?
Yn gyntaf, gadewch i ni ddiffinio pa briodweddau y mae'n rhaid i system eu cael er mwyn cael ei galw'n “hyblyg”.
Ar wahân, mae'n werth nodi y dylai'r eiddo a ddisgrifir ymwneud yn benodol â nhw system, nid i proses ei ddatblygiad. Felly, os oeddech chi eisiau darllen am Agile fel methodoleg datblygu, mae'n well darllen erthyglau eraill. Er enghraifft, yno, ar Habré, mae yna lawer o ddeunyddiau diddorol (fel и Ac ).
Nid yw hyn yn golygu bod y broses ddatblygu a strwythur y warws data yn gwbl amherthnasol. Yn gyffredinol, dylai fod yn llawer haws datblygu ystorfa Ystwyth ar gyfer pensaernïaeth ystwyth. Fodd bynnag, yn ymarferol, yn amlach mae opsiynau gyda datblygiad Agile o'r DWH clasurol yn ôl Kimbal a DataVault - yn ôl Waterfall, na chyd-ddigwyddiadau hapus o hyblygrwydd yn ei ddwy ffurf ar un prosiect.
Felly, pa alluoedd ddylai fod gan storio hyblyg? Mae tri phwynt yma:
- Cyflwyno'n gynnar a newid cyflym - mae hyn yn golygu, yn ddelfrydol, y dylid cael canlyniad busnes cyntaf (er enghraifft, yr adroddiadau gwaith cyntaf) cyn gynted â phosibl, hynny yw, hyd yn oed cyn i'r system gyfan gael ei dylunio a'i gweithredu'n llawn. At hynny, dylai pob adolygiad dilynol hefyd gymryd cyn lleied o amser â phosibl.
- Coethder iteraidd - mae hyn yn golygu na ddylai pob gwelliant dilynol yn ddelfrydol effeithio ar y swyddogaeth sydd eisoes yn gweithio. Y foment hon sy'n aml yn dod yn hunllef fwyaf ar brosiectau mawr - yn hwyr neu'n hwyrach, mae gwrthrychau unigol yn dechrau cael cymaint o gysylltiadau nes ei bod yn haws ailadrodd y rhesymeg yn llwyr mewn copi gerllaw nag ychwanegu maes at dabl sy'n bodoli eisoes. Ac os ydych chi'n synnu bod dadansoddi effaith gwelliannau ar wrthrychau presennol yn gallu cymryd mwy o amser na'r gwelliannau eu hunain, mae'n debyg nad ydych chi wedi gweithio eto gyda warysau data mawr mewn bancio neu delathrebu.
- Addasu'n gyson i ofynion busnes sy'n newid - dylai'r strwythur gwrthrych cyffredinol gael ei ddylunio nid yn unig gan gymryd i ystyriaeth ehangu posibl, ond gyda'r disgwyl na ellid hyd yn oed freuddwydio am gyfeiriad yr ehangiad nesaf hwn yn y cam dylunio.
Ac ie, mae cwrdd â'r holl ofynion hyn mewn un system yn bosibl (wrth gwrs, mewn rhai achosion a gyda rhai amheuon).
Isod byddaf yn ystyried dwy o'r methodolegau dylunio ystwyth mwyaf poblogaidd ar gyfer warysau data - Model angor и Data Vault. Mae technegau mor wych i'r chwith allan o'r cromfachau fel, er enghraifft, EAV, 6NF (yn ei ffurf pur) a phopeth sy'n ymwneud â datrysiadau NoSQL - nid oherwydd eu bod yn waeth rhywsut, ac nid hyd yn oed oherwydd yn yr achos hwn byddai'r erthygl yn bygwth caffael cyfaint y traethawd ar gyfartaledd. Dim ond bod hyn i gyd yn ymwneud â datrysiadau o ddosbarth ychydig yn wahanol - naill ai i dechnegau y gallwch eu defnyddio mewn achosion penodol, waeth beth fo pensaernïaeth gyffredinol eich prosiect (fel EAV), neu i baradeimau storio gwybodaeth eraill yn fyd-eang (fel cronfeydd data graff ac opsiynau eraill NoSQL).
Problemau'r dull “clasurol” a'u hatebion mewn methodolegau hyblyg
Wrth ddull “clasurol” rwy'n golygu'r hen seren dda (waeth beth yw gweithrediad penodol yr haenau gwaelodol, bydded i ddilynwyr Kimball, Inmon a CDM faddau i mi).
1. Cardinalality anhyblyg o gysylltiadau
Mae'r model hwn yn seiliedig ar raniad clir o ddata yn Dimensiwn и ffeithiau. Ac mae hyn, yn damn, yn rhesymegol - wedi'r cyfan, dadansoddi data yn y mwyafrif llethol o achosion yn dibynnu ar y dadansoddiad o rai dangosyddion rhifiadol (ffeithiau) mewn rhai adrannau (dimensiynau).
Yn yr achos hwn, sefydlir cysylltiadau rhwng gwrthrychau ar ffurf perthnasoedd rhwng tablau gan ddefnyddio allwedd estron. Mae hyn yn edrych yn eithaf naturiol, ond yn syth yn arwain at y cyfyngiad cyntaf ar hyblygrwydd - diffiniad llym o gardinoldeb cysylltiadau.
Mae hyn yn golygu, ar y cam dylunio tabl, bod yn rhaid i chi benderfynu'n gywir ar gyfer pob pâr o wrthrychau cysylltiedig a allant gysylltu cymaint â llawer, neu ddim ond 1-i-lawer, ac “i ba gyfeiriad”. Mae hyn yn pennu'n uniongyrchol pa dabl fydd â'r allwedd gynradd a pha un fydd â'r allwedd dramor. Bydd newid yr agwedd hon pan dderbynnir gofynion newydd yn fwyaf tebygol o arwain at ail-weithio'r ganolfan.
Er enghraifft, wrth ddylunio'r gwrthrych “derbynneb arian parod”, rydych chi, gan ddibynnu ar lwon yr adran werthu, wedi gosod y posibilrwydd o weithredu un dyrchafiad ar gyfer sawl swydd siec (ond nid i'r gwrthwyneb):
Ac ar ôl peth amser, cyflwynodd cydweithwyr strategaeth farchnata newydd lle gallant weithredu ar yr un sefyllfa sawl hyrwyddiad ar yr un pryd. Ac yn awr mae angen i chi addasu'r tablau trwy wahanu'r berthynas yn wrthrych ar wahân.
(Mae angen gwella'r holl wrthrychau deilliedig y mae'r gwiriad dyrchafiad wedi'i gysylltu ag ef nawr hefyd).
Perthnasoedd mewn Data Vault a Model Angor
Roedd osgoi'r sefyllfa hon yn eithaf syml: nid oes rhaid i chi ymddiried yn yr adran werthu i wneud hyn. caiff pob cysylltiad ei storio mewn tablau ar wahân i ddechrau a'i brosesu fel cymaint i lawer.
Cynigiwyd y dull hwn Dan Linstedt fel rhan o'r patrwm Data Vault a chefnogaeth lawn Lars Rönnbäck в Model Angor.
O ganlyniad, rydym yn cael y nodwedd nodedig gyntaf o fethodolegau hyblyg:
Nid yw perthnasoedd rhwng gwrthrychau yn cael eu storio ym mhriodweddau endidau rhiant, ond maent yn fath ar wahân o wrthrych.
В Data Vault gelwir tablau cysylltu o'r fath Cyswllt, ac yn Model Angor - Nodyn clwm. Ar yr olwg gyntaf, maent yn debyg iawn, er nad yw eu gwahaniaethau yn gorffen gyda'r enw (a drafodir isod). Yn y ddwy bensaernïaeth, gall tablau cyswllt gysylltu unrhyw nifer o endidau (nid o reidrwydd 2).
Mae'r diswyddiad hwn, ar yr olwg gyntaf, yn darparu hyblygrwydd sylweddol ar gyfer addasiadau. Mae strwythur o'r fath yn dod yn oddefgar nid yn unig i newidiadau yng nghadernid cysylltiadau presennol, ond hefyd i ychwanegu rhai newydd - os oes gan safle siec bellach gysylltiad â'r ariannwr a'i hagorodd, bydd ymddangosiad cyswllt o'r fath yn dod yn syml. ychwanegiad dros dablau presennol heb effeithio ar unrhyw wrthrychau a phrosesau presennol.
2. Dyblygu data
Mae'r ail broblem a ddatrysir gan bensaernïaeth hyblyg yn llai amlwg ac yn gynhenid yn y lle cyntaf. Mesuriadau math SCD2 (yn newid yn araf dimensiynau o'r ail fath), er nid yn unig nhw.
Mewn warws clasurol, mae dimensiwn fel arfer yn dabl sy'n cynnwys allwedd dirprwyol (fel PK) a set o allweddi a phriodoleddau busnes mewn colofnau ar wahân.
Os yw dimensiwn yn cefnogi fersiwn, ychwanegir ffiniau dilysrwydd fersiwn at y set safonol o feysydd, ac mae sawl fersiwn yn ymddangos yn y storfa ar gyfer un rhes yn y ffynhonnell (un ar gyfer pob newid mewn priodoleddau fersiwn).
Os yw dimensiwn yn cynnwys o leiaf un nodwedd fersiwn sy'n newid yn aml, bydd nifer y fersiynau o ddimensiwn o'r fath yn drawiadol (hyd yn oed os nad yw'r priodoleddau sy'n weddill yn cael eu fersiwnio neu byth yn newid), ac os oes sawl nodwedd o'r fath, gall nifer y fersiynau tyfu yn esbonyddol o'u rhif. Gall y dimensiwn hwn gymryd cryn dipyn o ofod disg, er bod llawer o'r data y mae'n ei storio yn syml yn ddyblygiadau o werthoedd priodoledd na ellir eu cyfnewid o resi eraill.
Ar yr un pryd, fe'i defnyddir yn aml iawn hefyd dadnormaleiddio — mae rhai nodweddion yn cael eu storio'n fwriadol fel gwerth, ac nid fel dolen i gyfeirlyfr neu ddimensiwn arall. Mae'r dull hwn yn cyflymu mynediad at ddata, gan leihau nifer yr uniadau wrth gyrchu dimensiwn.
Yn nodweddiadol mae hyn yn arwain at mae'r un wybodaeth yn cael ei storio ar yr un pryd mewn sawl man. Er enghraifft, gellir storio gwybodaeth am y rhanbarth preswyl a chategori'r cleient ar yr un pryd yn y dimensiynau "Cleient" a'r ffeithiau "Prynu", "Cyflwyno" a "Galwadau Canolfan Alwadau", yn ogystal ag yn y "Cleient - Rheolwr Cleient". ” tabl cyswllt.
Yn gyffredinol, mae'r hyn a ddisgrifir uchod yn berthnasol i ddimensiynau rheolaidd (di-fersiwn), ond mewn rhai fersiynau efallai y bydd ganddynt raddfa wahanol: mae ymddangosiad fersiwn newydd o wrthrych (yn enwedig wrth edrych yn ôl) yn arwain nid yn unig at ddiweddaru popeth cysylltiedig. tablau, ond i ymddangosiad rhaeadru fersiynau newydd o wrthrychau cysylltiedig - pan ddefnyddir Tabl 1 i adeiladu Tabl 2, a defnyddir Tabl 2 i adeiladu Tabl 3, ac ati. Hyd yn oed os nad oes nodwedd unigol o Dabl 1 yn rhan o adeiladu Tabl 3 (a bod nodweddion eraill Tabl 2 a gafwyd o ffynonellau eraill dan sylw), bydd fersiwn y lluniad hwn o leiaf yn arwain at orbenion ychwanegol, ac ar uchafswm at ychwanegol. fersiynau yn Nhabl 3. sydd ddim i'w wneud ag ef o gwbl, ac ymhellach i lawr y gadwyn.
3. Cymhlethdod ail-weithio aflinol
Ar yr un pryd, mae pob blaen siop newydd a adeiladwyd ar sail un arall yn cynyddu nifer y lleoedd lle gall data “wahanu” pan wneir newidiadau i'r ETL. Mae hyn, yn ei dro, yn arwain at gynnydd yng nghymhlethdod (a hyd) pob adolygiad dilynol.
Os yw'r uchod yn disgrifio systemau sydd â phrosesau ETL wedi'u haddasu'n anaml, gallwch chi fyw mewn patrwm o'r fath - does ond angen i chi sicrhau bod addasiadau newydd yn cael eu gwneud yn gywir i'r holl wrthrychau cysylltiedig. Os bydd diwygiadau'n digwydd yn aml, mae'r tebygolrwydd y bydd sawl cysylltiad “ar goll” yn ddamweiniol yn cynyddu'n sylweddol.
Os byddwn, yn ogystal, yn cymryd i ystyriaeth fod ETL “fersiwn” gryn dipyn yn fwy cymhleth nag un “heb ei fersiwn”, mae'n dod yn eithaf anodd osgoi camgymeriadau wrth ddiweddaru'r cyfleuster cyfan hwn yn aml.
Storio gwrthrychau a phriodoleddau yn Data Vault a Model Anchor
Gellir llunio'r dull a gynigir gan awduron pensaernïaeth hyblyg fel a ganlyn:
Mae angen gwahanu'r hyn sy'n newid oddi wrth yr hyn sy'n aros yr un fath. Hynny yw, storio allweddi ar wahân i briodoleddau.
Fodd bynnag, ni ddylai un ddrysu heb ei fersiwn priodoledd gyda digyfnewid: nid yw'r un cyntaf yn storio hanes ei newidiadau, ond gall newid (er enghraifft, wrth gywiro gwall mewnbwn neu dderbyn data newydd); nid yw'r ail byth yn newid.
Mae safbwyntiau'n amrywio o ran beth yn union y gellir ei ystyried yn ddigyfnewid yn y Data Vault a'r Model Anchor.
O safbwynt pensaernïol Data Vault, gellir ei ystyried yn ddigyfnewid set gyfan o allweddi - naturiol (TIN y sefydliad, cod cynnyrch yn y system ffynhonnell, ac ati) a dirprwy. Yn yr achos hwn, gellir rhannu'r priodoleddau sy'n weddill yn grwpiau yn ôl ffynhonnell a/neu amlder y newidiadau a Cadwch fwrdd ar wahân ar gyfer pob grŵp gyda set annibynnol o fersiynau.
Yn y paradigm Model Angor cael ei ystyried yn ddigyfnewid dim ond allwedd surrogate hanfod. Mae popeth arall (gan gynnwys allweddi naturiol) yn achos arbennig o'i rinweddau. lie mae pob priodoledd yn annibynol ar ei gilydd yn ddiofyn, felly am bob priodoledd a bwrdd ar wahân.
В Data Vault gelwir tablau sy'n cynnwys allweddi endid Hubami. Mae canolbwyntiau bob amser yn cynnwys set sefydlog o feysydd:
- Allweddi Endid Naturiol
- Allwedd surrogate
- Dolen i'r ffynhonnell
- Cofnodi amser ychwanegu
Postiadau mewn Hybiau byth yn newid a heb fersiynau. Yn allanol, mae canolbwyntiau yn debyg iawn i dablau math map ID a ddefnyddir mewn rhai systemau i gynhyrchu surrogates, fodd bynnag, argymhellir defnyddio hash o set o allweddi busnes fel dirprwy yn Data Vault. Mae'r dull hwn yn symleiddio perthnasoedd llwytho a phriodoleddau o ffynonellau (nid oes angen ymuno â'r canolbwynt i gael dirprwy, dim ond cyfrifo hash allwedd naturiol), ond gall achosi problemau eraill (yn gysylltiedig, er enghraifft, â gwrthdrawiadau, cas ac na ellir ei argraffu nodau mewn allweddau llinynnol, etc. .p.), felly nid yw yn cael ei dderbyn yn gyffredinol.
Mae'r holl briodoleddau endid eraill yn cael eu storio mewn tablau arbennig o'r enw Lloerennau. Gall un canolbwynt gael sawl lloeren yn storio gwahanol setiau o briodoleddau.
Mae dosbarthiad priodoleddau ymhlith lloerennau yn digwydd yn ôl yr egwyddor newid ar y cyd — mewn un lloeren gellir storio priodoleddau heb eu fersiwn (er enghraifft, dyddiad geni a SNILS ar gyfer unigolyn), mewn un arall - rhai sydd wedi'u newid yn anaml (er enghraifft, enw olaf a rhif pasbort), yn y trydydd - rhai sy'n newid yn aml (er enghraifft, cyfeiriad danfon, categori, dyddiad archeb ddiwethaf, ac ati). Yn yr achos hwn, mae fersiwn yn cael ei wneud ar lefel lloerennau unigol, ac nid yr endid yn ei gyfanrwydd, felly fe'ch cynghorir i ddosbarthu priodoleddau fel bod croestoriad fersiynau o fewn un lloeren yn fach iawn (sy'n lleihau cyfanswm nifer y fersiynau sydd wedi'u storio ).
Hefyd, i wneud y gorau o'r broses llwytho data, mae priodoleddau a geir o wahanol ffynonellau yn aml yn cael eu cynnwys mewn lloerennau unigol.
Mae lloerennau'n cyfathrebu â'r Hyb trwy allwedd tramor (sy'n cyfateb i cardinality 1-i-lawer). Mae hyn yn golygu bod gwerthoedd priodoledd lluosog (er enghraifft, rhifau ffôn cyswllt lluosog ar gyfer un cleient) yn cael eu cefnogi gan y bensaernïaeth “ddiofyn” hon.
В Model Angor gelwir tablau sy'n storio allweddi Angorau. Ac maen nhw'n cadw:
- Allweddi dirprwyol yn unig
- Dolen i'r ffynhonnell
- Cofnodi amser ychwanegu
Ystyrir allweddi naturiol o safbwynt y Model Angor priodoleddau cyffredin. Gall yr opsiwn hwn ymddangos yn anoddach i'w ddeall, ond mae'n rhoi llawer mwy o sgôp i adnabod y gwrthrych.
Er enghraifft, os gall data am yr un endid ddod o systemau gwahanol, gyda phob un ohonynt yn defnyddio ei allwedd naturiol ei hun. Yn Data Vault, gall hyn arwain at strwythurau braidd yn feichus o sawl canolbwynt (un fesul ffynhonnell + fersiwn meistr uno), tra yn y model Anchor, mae allwedd naturiol pob ffynhonnell yn disgyn i'w nodwedd ei hun a gellir ei defnyddio wrth lwytho'n annibynnol ar y lleill i gyd.
Ond mae un pwynt llechwraidd yma hefyd: os cyfunir priodoleddau o wahanol systemau mewn un endid, yn fwyaf tebygol mae rhai rheolau "gludo", lle mae'n rhaid i'r system ddeall bod cofnodion o wahanol ffynonellau yn cyfateb i un enghraifft o'r endid.
В Data Vault bydd y rheolau hyn yn fwyaf tebygol o bennu'r ffurfiant “canolbwynt dirprwyol” y prif endid a pheidio â dylanwadu mewn unrhyw ffordd ar y Canolbwyntiau sy'n storio allweddi ffynhonnell naturiol a'u priodoleddau gwreiddiol. Os bydd y rheolau uno yn newid ar ryw adeg (neu os yw'r priodoleddau ar gyfer ei berfformio'n cael eu diweddaru), bydd yn ddigon i ailfformatio'r canolfannau dirprwyol.
В Model angor mae'n debygol y bydd endid o'r fath yn cael ei storio ynddo yr unig angor. Mae hyn yn golygu y bydd yr holl briodoleddau, ni waeth o ba ffynhonnell y maent yn dod, yn rhwym i'r un dirprwy. Gall fod yn llawer anoddach gwahanu cofnodion cyfunedig anghywir ac, yn gyffredinol, monitro perthnasedd uno mewn system o'r fath, yn enwedig os yw'r rheolau'n eithaf cymhleth ac yn newid yn aml, a gellir cael yr un nodwedd o wahanol ffynonellau (er ei bod yn sicr bosibl, gan fod pob fersiwn priodoledd yn cadw dolen i'w ffynhonnell).
Mewn unrhyw achos, os yw eich system i fod i weithredu'r swyddogaeth dad-ddyblygu, uno cofnodion ac elfennau MDM eraill, mae'n werth rhoi sylw arbennig i'r agweddau ar storio allweddi naturiol mewn methodolegau ystwyth. Mae'n debygol y bydd y dyluniad Data Vault mwy swmpus yn sydyn yn fwy diogel o ran gwallau uno.
Model angor hefyd yn darparu math gwrthrych ychwanegol o'r enw Cwlwm mae'n arbennig yn ei hanfod dirywio math o angor, a all gynnwys un nodwedd yn unig. Mae'r nodau i fod i gael eu defnyddio i storio cyfeiriaduron gwastad (er enghraifft, rhyw, statws priodasol, categori gwasanaeth cwsmeriaid, ac ati). Yn wahanol i'r Angor, y Cwlwm nid oes ganddo dablau priodoleddau cysylltiedig, ac mae ei unig briodoledd (enw) bob amser yn cael ei storio yn yr un tabl gyda'r allwedd. Mae nodau wedi'u cysylltu ag Anchors gan dablau clymu (Clymu) yn yr un modd ag y mae Anchors wedi'u cysylltu â'i gilydd.
Nid oes barn glir ynghylch y defnydd o Nodau. Er enghraifft, , sy'n mynd ati i hyrwyddo'r defnydd o'r Model Angor yn Rwsia, yn credu (nid yn afresymol) y gellir datgan yn bendant am ddim un cyfeirlyfr. bob amser Bydd yn sefydlog ac yn un lefel, felly mae'n well defnyddio Angor llawn ar unwaith ar gyfer pob gwrthrych.
Gwahaniaeth pwysig arall rhwng Data Vault a'r model Anchor yw argaeledd priodoleddau cysylltiadau:
В Data Vault Mae dolenni yr un gwrthrychau llawn â Hybiau, a gallant gael priodoleddau eu hunain. Yn Model angor Defnyddir cysylltiadau yn unig i gysylltu Anchors a na allant gael eu priodoleddau eu hunain. Mae'r gwahaniaeth hwn yn arwain at ddulliau modelu sylweddol wahanol ffeithiau, a drafodir ymhellach.
Storio ffeithiau
Cyn hyn, buom yn siarad yn bennaf am fodelu mesur. Mae'r ffeithiau ychydig yn llai clir.
В Data Vault gwrthrych nodweddiadol ar gyfer storio ffeithiau yw Dolen, yn eu lloerennau dangosyddion gwirioneddol yn cael eu hychwanegu.
Mae'r dull hwn yn ymddangos yn reddfol. Mae'n darparu mynediad hawdd i'r dangosyddion a ddadansoddwyd ac yn gyffredinol mae'n debyg i dabl ffeithiau traddodiadol (dim ond y dangosyddion sy'n cael eu storio nid yn y tabl ei hun, ond yn yr un "cyfagos"). Ond mae yna beryglon hefyd: mae un o addasiadau nodweddiadol y model - ehangu'r allwedd ffaith - yn angenrheidiol ychwanegu allwedd dramor newydd i Link. Ac mae hyn, yn ei dro, yn “torri” y modiwlaredd ac o bosibl yn achosi'r angen am addasiadau i wrthrychau eraill.
В Model angor Ni all cysylltiad gael ei briodoleddau ei hun, felly ni fydd y dull hwn yn gweithio - yn hollol rhaid i bob priodoledd a dangosydd fod yn gysylltiedig ag un angor penodol. Mae'r casgliad o hyn yn syml - Mae angen ei hangor ei hun ar bob ffaith hefyd. I rai o'r hyn yr ydym wedi arfer ei ganfod fel ffeithiau, gall hyn edrych yn naturiol - er enghraifft, gellir lleihau'r ffaith pryniant yn berffaith i "archeb" neu "derbynneb" gwrthrych, ymweld â safle i sesiwn, ac ati. Ond mae yna hefyd ffeithiau nad yw mor hawdd dod o hyd i "wrthrych cludwr" mor naturiol ar eu cyfer - er enghraifft, gweddillion nwyddau mewn warysau ar ddechrau pob dydd.
Yn unol â hynny, nid yw problemau gyda modiwlaredd wrth ehangu allwedd ffaith yn y model Anchor yn codi (mae'n ddigon syml ychwanegu Perthynas newydd i'r Angor cyfatebol), ond mae dylunio model i arddangos ffeithiau yn llai diamwys; gall Angorau “artiffisial” ymddangos sy'n arddangos y model gwrthrych busnes mewn ffordd aneglur.
Sut mae hyblygrwydd yn cael ei gyflawni
Mae'r gwaith adeiladu o ganlyniad yn y ddau achos yn cynnwys llawer mwy o dablauna mesur traddodiadol. Ond efallai y bydd yn cymryd gryn dipyn yn llai o le ar y ddisg gyda'r un set o briodoleddau fersiwn â'r dimensiwn traddodiadol. Yn naturiol, nid oes hud yma - mae'n ymwneud â normaleiddio. Trwy ddosbarthu priodoleddau ar draws Lloerennau (yn y Vault Data) neu dablau unigol (Model Angor), rydym yn lleihau (neu'n dileu'n llwyr) dyblygu gwerthoedd rhai priodoleddau wrth newid rhai eraill.
I Data Vault bydd yr ennillion yn ymddibynu ar ddosraniad y priodoliaethau yn mysg y Lloerennau, ac am Model angor — bron yn uniongyrchol gymesur â nifer cyfartalog y fersiynau fesul gwrthrych mesur.
Fodd bynnag, mae arbed gofod yn fantais bwysig, ond nid y brif fantais, o storio priodoleddau ar wahân. Ynghyd â storio perthnasoedd ar wahân, mae'r dull hwn yn gwneud y storfa dylunio modiwlaidd. Mae hyn yn golygu bod ychwanegu priodoleddau unigol a meysydd pwnc newydd cyfan mewn model o'r fath yn edrych aradeiledd dros set bresennol o wrthrychau heb eu newid. A dyma'n union sy'n gwneud y methodolegau a ddisgrifir yn hyblyg.
Mae hyn hefyd yn debyg i'r newid o gynhyrchu darnau i gynhyrchu màs - os yw pob tabl o'r model yn y dull traddodiadol yn unigryw ac angen sylw arbennig, yna mewn methodolegau hyblyg mae eisoes yn set o “rannau” safonol. Ar y naill law, mae mwy o dablau, a dylai'r prosesau llwytho ac adalw data edrych yn fwy cymhleth. Ar y llaw arall, maent yn dod nodweddiadol. Sy'n golygu y gall fod awtomataidd a metadata wedi'i yrru. Nid yw’r cwestiwn “sut byddwn yn ei osod?”, y gallai’r ateb iddo fod yn rhan sylweddol o’r gwaith ar ddylunio gwelliannau, bellach yn werth chweil (yn ogystal â’r cwestiwn am effaith newid y model ar brosesau gweithio). ).
Nid yw hyn yn golygu nad oes angen dadansoddwyr mewn system o'r fath o gwbl - mae'n rhaid i rywun weithio o hyd trwy'r set o wrthrychau â phriodoleddau a darganfod ble a sut i lwytho'r cyfan. Ond mae maint y gwaith, yn ogystal â thebygolrwydd a chost gwall, yn cael eu lleihau'n sylweddol. Yn ystod y cam dadansoddi ac yn ystod datblygiad ETL, y gellir ei leihau i raddau helaeth i olygu metadata.
Ochr dywyll
Mae'r uchod i gyd yn gwneud y ddau ddull yn wirioneddol hyblyg, yn dechnolegol ddatblygedig ac yn addas ar gyfer gwelliant ailadroddol. Wrth gwrs, mae yna “gasgen yn yr eli” hefyd, yr wyf yn meddwl y gallwch chi ddyfalu amdano eisoes.
Mae dadelfennu data, sy'n sail i fodiwlaredd pensaernïaeth hyblyg, yn arwain at gynnydd yn nifer y tablau ac, yn unol â hynny, uwchben i ymuno wrth samplu. Er mwyn cael holl briodoleddau dimensiwn yn syml, mewn siop glasurol mae un dewis yn ddigon, ond bydd pensaernïaeth hyblyg yn gofyn am gyfres gyfan o uniadau. Ar ben hynny, os gellir ysgrifennu'r rhain i gyd ar gyfer adroddiadau ymlaen llaw, yna bydd dadansoddwyr sy'n gyfarwydd ag ysgrifennu SQL â llaw yn dioddef ddwywaith.
Mae yna nifer o ffeithiau sy'n gwneud y sefyllfa hon yn haws:
Wrth weithio gyda dimensiynau mawr, nid yw ei holl briodoleddau bron byth yn cael eu defnyddio ar yr un pryd. Mae hyn yn golygu y gallai fod llai o uniadau nag y mae'n ymddangos ar yr olwg gyntaf yn y model. Gall Data Vault hefyd ystyried amlder disgwyliedig rhannu wrth ddyrannu priodoleddau i loerennau. Ar yr un pryd, mae angen Hybiau neu Angorau eu hunain yn bennaf ar gyfer cynhyrchu a mapio dirprwy yn y cam llwytho ac anaml y cânt eu defnyddio mewn ymholiadau (mae hyn yn arbennig o wir ar gyfer Anchors).
Mae pob uniad trwy allwedd. Yn ogystal, mae ffordd fwy “cywasgedig” o storio data yn lleihau gorbenion tablau sganio lle mae eu hangen (er enghraifft, wrth hidlo yn ôl gwerth priodoledd). Gall hyn arwain at y ffaith y bydd samplu o gronfa ddata wedi'i normaleiddio gyda chriw o uniadau hyd yn oed yn gyflymach na sganio un dimensiwn trwm gyda llawer o fersiynau fesul rhes.
Er enghraifft, yma yn Mae'r erthygl yn cynnwys prawf cymharol manwl o berfformiad y model Anchor gyda sampl o un tabl.
Mae llawer yn dibynnu ar yr injan. Mae gan lawer o lwyfannau modern fecanweithiau optimeiddio ymuno mewnol. Er enghraifft, gall MS SQL ac Oracle “sgipio” uniadau i dablau os na ddefnyddir eu data yn unrhyw le ac eithrio ar gyfer uniadau eraill ac nad yw'n effeithio ar y dewis terfynol (dilead bwrdd / uniad), a MPP Vertica , wedi profi i fod yn beiriant ardderchog ar gyfer y Model Anchor, o ystyried rhywfaint o optimeiddio â llaw o'r cynllun ymholiad. Ar y llaw arall, nid yw storio'r Model Anchor, er enghraifft, ar Click House, sydd â chefnogaeth ymuno gyfyngedig, yn edrych fel syniad da iawn eto.
Yn ogystal, ar gyfer y ddau bensaernïaeth mae symudiadau arbennig, gwneud mynediad at ddata yn haws (o safbwynt perfformiad ymholiad ac ar gyfer defnyddwyr terfynol). Er enghraifft, Tablau Pwynt-Mewn-Amser mewn Data Vault neu swyddogaethau bwrdd arbennig yn y model Anchor.
Yn gyfan gwbl
Prif hanfod y pensaernïaeth hyblyg ystyriol yw modiwlaredd eu “dyluniad”.
Yr eiddo hwn sy'n caniatáu:
- Ar ôl peth paratoi cychwynnol yn ymwneud â defnyddio metadata ac ysgrifennu algorithmau ETL sylfaenol, darparu'r canlyniad cyntaf i'r cwsmer yn gyflym ar ffurf cwpl o adroddiadau sy'n cynnwys data o ychydig o wrthrychau ffynhonnell yn unig. Nid oes angen meddwl yn llwyr (hyd yn oed ar y lefel uchaf) y model gwrthrych cyfan.
- Gall model data ddechrau gweithio (a bod yn ddefnyddiol) gyda dim ond 2-3 gwrthrych, ac yna tyfu'n raddol (ynghylch y model Anchor Nikolai cymhariaeth braf gyda mycelium).
- Y rhan fwyaf o welliannau, gan gynnwys ehangu'r maes pwnc ac ychwanegu ffynonellau newydd nid yw'n effeithio ar ymarferoldeb presennol ac nid yw'n peri risg o dorri rhywbeth sydd eisoes yn gweithio.
- Diolch i ddadelfennu elfennau safonol, mae prosesau ETL mewn systemau o'r fath yn edrych yr un fath, mae eu hysgrifennu yn addas ar gyfer algorithmeiddio ac, yn y pen draw, awtomeiddio.
Mae pris yr hyblygrwydd hwn yn perfformiad. Nid yw hyn yn golygu ei bod yn amhosibl cyflawni perfformiad derbyniol ar fodelau o'r fath. Yn amlach na pheidio, efallai y bydd angen mwy o ymdrech a sylw i fanylion arnoch i gyflawni'r metrigau rydych chi eu heisiau.
Apps
Mathau o endidau Data Vault
Mwy o wybodaeth am Data Vault:
Mathau o endidau Model Angor
Mwy o fanylion am Fodel Anchor:
Tabl crynodeb gyda nodweddion cyffredin a gwahaniaethau yn y dulliau a ystyriwyd:
Ffynhonnell: hab.com