Izgradnja skladišta je dug i ozbiljan pothvat.
Mnogo toga u životu projekta ovisi o tome koliko su dobro osmišljeni objektni model i osnovna struktura na početku.
Općeprihvaćeni pristup bile su i ostale različite varijante kombiniranja zvjezdane sheme s trećim normalnim oblikom. U pravilu, prema principu: početni podaci - 3NF, vitrine - zvijezda. Ovaj pristup, provjeren vremenom i potkrijepljen velikom količinom istraživanja, prva je (a ponekad i jedina) stvar koja padne na pamet iskusnom DWH stručnjaku kada razmišlja o tome kako bi analitički repozitorij trebao izgledati.
S druge strane, poslovanje općenito, a posebno zahtjevi korisnika imaju tendenciju da se brzo mijenjaju, a podaci imaju tendenciju rasta i "u dubinu" i "u širinu". I tu se pojavljuje glavni nedostatak zvijezde - ograničenost savitljivost.
A ako u vašem mirnom i ugodnom životu DWH programera odjednom:
- pojavio se zadatak "brzo napraviti barem nešto, a onda ćemo vidjeti";
- pojavio se projekt koji se brzo razvija, s povezivanjem novih izvora i preradom poslovnog modela barem jednom tjedno;
- pojavio se kupac koji nema pojma kako bi sustav trebao izgledati i koje bi funkcije u konačnici trebao obavljati, ali je spreman eksperimentirati i dosljedno usavršavati željeni rezultat dok mu se stalno približava;
- Voditelj projekta navratio je s dobrim vijestima: "I sada imamo agile!"
Ili ako vas samo zanima kako drugačije možete izgraditi skladišne prostore - dobrodošli u rez!
Što znači "fleksibilnost"?
Prvo, definirajmo koja svojstva sustav mora imati da bi se mogao nazvati “fleksibilnim”.
Zasebno je vrijedno spomenuti da se opisana svojstva trebaju posebno odnositi na sustav, ne da postupak njegov razvoj. Stoga, ako želite čitati o Agileu kao razvojnoj metodologiji, bolje je pročitati druge članke. Na primjer, upravo tamo, na Habréu, ima mnogo zanimljivih materijala (kao и I ).
To ne znači da su proces razvoja i struktura skladišta podataka potpuno nepovezani. Sve u svemu, trebalo bi biti znatno lakše razviti Agile repozitorij za agilnu arhitekturu. Međutim, u praksi češće postoje opcije s Agilnim razvojem klasičnog DWH-a prema Kimbalu i DataVaultu - prema Waterfallu, nego sretne slučajnosti fleksibilnosti u svoja dva oblika na jednom projektu.
Dakle, koje bi mogućnosti trebala imati fleksibilna pohrana? Ovdje postoje tri točke:
- Rana dostava i brz obrt - to znači da bi idealno prvi poslovni rezultat (primjerice prva radna izvješća) trebao biti dobiven što je prije moguće, odnosno čak i prije nego što je cijeli sustav u potpunosti dizajniran i implementiran. Štoviše, svaka sljedeća revizija također treba trajati što je moguće kraće.
- Iterativno usavršavanje - to znači da svako sljedeće poboljšanje idealno ne bi trebalo utjecati na funkcionalnost koja već radi. Upravo taj trenutak često postaje najveća noćna mora na velikim projektima - prije ili kasnije, pojedinačni objekti počnu stjecati toliko mnogo veza da postaje lakše potpuno ponoviti logiku u kopiji u blizini nego dodati polje postojećoj tablici. A ako ste iznenađeni da analiza utjecaja poboljšanja na postojeće objekte može potrajati više vremena nego sama poboljšanja, najvjerojatnije još niste radili s velikim skladištima podataka u bankarstvu ili telekomunikacijama.
- Konstantno prilagođavanje promjenjivim poslovnim zahtjevima - ukupnu strukturu objekta treba projektirati ne samo uzimajući u obzir moguće proširenje, već i s očekivanjem da se u fazi projektiranja ne može ni sanjati o smjeru ovog sljedećeg širenja.
I da, ispunjavanje svih ovih zahtjeva u jednom sustavu je moguće (naravno, u određenim slučajevima i uz određene rezerve).
U nastavku ću razmotriti dvije najpopularnije metodologije agilnog dizajna za skladišta podataka - Model sidra и Trezor podataka. Izostavljene su izvan zagrada takve izvrsne tehnike kao što su npr. EAV, 6NF (u svom čistom obliku) i sve vezano za NoSQL rješenja - ne zato što su nekako lošija, pa čak ni zato što bi u ovom slučaju članak prijetio stjecanjem volumen prosječnog dissera. Samo što se sve ovo odnosi na rješenja malo drugačije klase - bilo na tehnike koje možete koristiti u specifičnim slučajevima, bez obzira na ukupnu arhitekturu vašeg projekta (kao što je EAV), ili na globalno druge paradigme za pohranu informacija (kao što su graf baze podataka i druge opcije NoSQL).
Problemi “klasičnog” pristupa i njihova rješenja u fleksibilnim metodologijama
Pod “klasičnim” pristupom mislim na dobru staru zvijezdu (bez obzira na specifičnu implementaciju temeljnih slojeva, neka mi oproste sljedbenici Kimballa, Inmona i CDM-a).
1. Rigidna kardinalnost veza
Ovaj model se temelji na jasnoj podjeli podataka na Dimenzija и činjenice. I to je, dovraga, logično - uostalom, analiza podataka u velikoj većini slučajeva svodi se na analizu određenih brojčanih pokazatelja (činjenica) u određenim dijelovima (dimenzijama).
U ovom slučaju veze između objekata uspostavljaju se u obliku odnosa između tablica pomoću stranog ključa. Ovo izgleda sasvim prirodno, ali odmah dovodi do prvog ograničenja fleksibilnosti - stroga definicija kardinalnosti veza.
To znači da u fazi dizajna tablice morate točno odrediti za svaki par povezanih objekata mogu li se odnositi kao više-prema-više, ili samo 1-prema-više, i "u kojem smjeru". Ovo izravno određuje koja će tablica imati primarni, a koja strani ključ. Promjena ovog stava kada se prime novi zahtjevi najvjerojatnije će dovesti do prerade baze.
Na primjer, prilikom dizajniranja objekta "gotovinski primitak", vi ste, oslanjajući se na zakletve odjela prodaje, postavili mogućnost djelovanja jedna promocija za nekoliko čekovnih pozicija (ali ne obrnuto):
I nakon nekog vremena, kolege su predstavile novu marketinšku strategiju u kojoj mogu djelovati na istoj poziciji nekoliko promocija u isto vrijeme. A sada trebate modificirati tablice odvajanjem odnosa u zaseban objekt.
(Svi izvedeni objekti u kojima je udružena promotivna provjera sada također moraju biti poboljšani).
Odnosi u trezoru podataka i modelu sidra
Izbjegavanje ove situacije pokazalo se prilično jednostavnim: ne morate vjerovati odjelu prodaje da to učini. sve veze su inicijalno pohranjene u zasebnim tablicama i obraditi ga kao više-prema-više.
Predložen je ovaj pristup Dan Linstedt kao dio paradigme Trezor podataka i u potpunosti podržan Lars Rönnbäck в Model sidra.
Kao rezultat toga, dobivamo prvu karakterističnu značajku fleksibilnih metodologija:
Odnosi između objekata nisu pohranjeni u atributima nadređenih entiteta, već su zasebna vrsta objekta.
В Trezor podataka takve povezne tablice nazivaju se Veza, i u Model sidra - Kravata. Na prvi pogled su vrlo slični, iako njihove razlike ne završavaju s imenom (o čemu će biti riječi u nastavku). U obje arhitekture povezne tablice mogu se povezati bilo koji broj entiteta (ne nužno 2).
Ova redundancija, na prvi pogled, pruža značajnu fleksibilnost za izmjene. Takva struktura postaje tolerantna ne samo na promjene u kardinalnosti postojećih veza, već i na dodavanje novih - ako sada čekovna pozicija ima i poveznicu na blagajnika koji ju je probio, pojava takve veze jednostavno će postati dodatak postojećim tablicama bez utjecaja na postojeće objekte i procese.
2. Umnožavanje podataka
Drugi problem koji rješavaju fleksibilne arhitekture manje je očit i inherentan je na prvom mjestu. Mjerenja tipa SCD2 (polako mijenjanje dimenzija drugog tipa), iako ne samo njih.
U klasičnom skladištu, dimenzija je obično tablica koja sadrži surogat ključ (kao PK) i skup poslovnih ključeva i atributa u zasebnim stupcima.
Ako dimenzija podržava određivanje verzija, granice valjanosti verzije dodaju se standardnom skupu polja, a za jedan redak u izvoru, nekoliko verzija se pojavljuje u repozitoriju (jedna za svaku promjenu u verzioniranim atributima).
Ako dimenzija sadrži barem jedan verzionirani atribut koji se često mijenja, broj verzija takve dimenzije bit će impresivan (čak i ako preostali atributi nisu verzionirani ili se nikada ne mijenjaju), a ako postoji nekoliko takvih atributa, broj verzija može rastu eksponencijalno od njihovog broja. Ova dimenzija može zauzeti značajnu količinu prostora na disku, iako je velik dio podataka koje pohranjuje jednostavno duplikati nepromjenjivih vrijednosti atributa iz drugih redaka.
U isto vrijeme, također se vrlo često koristi denormalizacija — neki su atributi namjerno pohranjeni kao vrijednost, a ne kao poveznica na referentnu knjigu ili drugu dimenziju. Ovaj pristup ubrzava pristup podacima, smanjujući broj spajanja prilikom pristupanja dimenziji.
To obično dovodi do iste informacije pohranjuju se istovremeno na nekoliko mjesta. Na primjer, podaci o regiji prebivališta i kategoriji klijenta mogu se istovremeno pohraniti u dimenzijama „Klijent” i činjenicama „Kupnja”, „Dostava” i „Pozivi pozivnog centra”, kao i u „Klijent - Upravitelj klijenata”. ” povezna tablica.
Općenito, gore opisano se odnosi na regularne (neverzirane) dimenzije, ali u onima s verzijama one mogu imati drugačiju ljestvicu: pojavljivanje nove verzije objekta (osobito u retrospektivi) dovodi ne samo do ažuriranja svih povezanih tablicama, već kaskadnom pojavljivanju novih verzija povezanih objekata - kada se Tablica 1 koristi za izradu Tablice 2, a Tablica 2 se koristi za izgradnju Tablice 3, itd. Čak i ako niti jedan atribut tablice 1 nije uključen u konstrukciju tablice 3 (a uključeni su i drugi atributi tablice 2 dobiveni iz drugih izvora), verzija ove konstrukcije minimalno će dovesti do dodatnih troškova, a maksimalno dodatno inačice u tablici 3. što uopće nema nikakve veze s tim i dalje u lancu.
3. Nelinearna složenost prerade
U isto vrijeme, svaki novi izlog izgrađen na temelju drugog povećava broj mjesta na kojima se podaci mogu "razilaziti" kada se izvrše promjene u ETL-u. To pak dovodi do povećanja složenosti (i trajanja) svake sljedeće revizije.
Ako gore opisano opisuje sustave s rijetko modificiranim ETL procesima, možete živjeti u takvoj paradigmi - samo trebate biti sigurni da su nove izmjene ispravno napravljene na svim povezanim objektima. Ako se revizije često događaju, vjerojatnost slučajnog "nedostajanja" nekoliko veza značajno se povećava.
Ako, dodatno, uzmemo u obzir da je “versionirani” ETL znatno kompliciraniji od “neverzioniranog”, postaje prilično teško izbjeći greške prilikom čestog ažuriranja cijele ove mogućnosti.
Pohranjivanje objekata i atributa u Data Vault i Anchor Model
Pristup koji predlažu autori fleksibilnih arhitektura može se formulirati na sljedeći način:
Potrebno je odvojiti ono što se mijenja od onoga što ostaje isto. To jest, ključeve pohranite odvojeno od atributa.
Međutim, ne treba brkati nije verzirano atribut sa nepromijenjeno: prvi ne pohranjuje povijest svojih promjena, ali se može mijenjati (npr. prilikom ispravljanja greške pri unosu ili primanja novih podataka), drugi se nikada ne mijenja.
Gledišta se razlikuju oko toga što se točno može smatrati nepromjenjivim u Trezoru podataka i modelu sidra.
S arhitektonskog gledišta Trezor podataka, može se smatrati nepromijenjenim cijeli set ključeva - prirodni (OIB organizacije, šifra proizvoda u izvornom sustavu itd.) i surogat. U tom slučaju, preostali atributi mogu se podijeliti u skupine prema izvoru i/ili učestalosti promjena i Održavajte zasebnu tablicu za svaku grupu s neovisnim skupom verzija.
U paradigmi Model sidra smatrati nepromijenjenim samo surogat ključ suština. Sve ostalo (uključujući prirodne ključeve) samo je poseban slučaj njegovih atributa. pri čemu svi su atributi prema zadanim postavkama neovisni jedan o drugome, pa za svaki atribut a zaseban stol.
В Trezor podataka pozivaju se tablice koje sadrže ključeve entiteta Hubami. Čvorišta uvijek sadrže fiksni skup polja:
- Ključevi prirodnih entiteta
- Zamjenski ključ
- Link na izvor
- Zabilježite vrijeme dodavanja
Objave u čvorištima nikada se ne mijenjaju i nemaju verzije. Izvana, čvorišta su vrlo slična tablicama tipa ID-mape koje se koriste u nekim sustavima za generiranje surogata, međutim, preporučuje se koristiti hash iz skupa poslovnih ključeva kao surogata u Data Vaultu. Ovaj pristup pojednostavljuje učitavanje odnosa i atributa iz izvora (nema potrebe pridruživanja čvorištu da biste dobili surogat, samo izračunajte hash prirodnog ključa), ali može uzrokovati druge probleme (povezane, na primjer, s kolizijama, malim i velikim slovima i neispisivim znakova u ključevima nizova itd. .p.), stoga nije općeprihvaćen.
Svi ostali atributi entiteta pohranjuju se u posebne tablice tzv Sateliti. Jedno čvorište može imati nekoliko satelita koji pohranjuju različite skupove atributa.
Distribucija atributa među satelitima odvija se prema principu promjena zgloba — u jednom satelitu mogu se pohraniti neverzionirani atributi (na primjer, datum rođenja i SNILS za pojedinca), u drugom - oni koji se rijetko mijenjaju (na primjer, prezime i broj putovnice), u trećem - oni koji se često mijenjaju (na primjer, adresa dostave, kategorija, datum zadnje narudžbe itd.). U ovom slučaju, verzioniranje se provodi na razini pojedinačnih satelita, a ne entiteta kao cjeline, stoga je preporučljivo distribuirati atribute tako da presjek verzija unutar jednog satelita bude minimalan (što smanjuje ukupan broj pohranjenih verzija ).
Također, kako bi se optimizirao proces učitavanja podataka, atributi dobiveni iz različitih izvora često su uključeni u pojedinačne satelite.
Sateliti komuniciraju s Hubom putem strani kljuc (što odgovara kardinalitetu 1-prema-više). To znači da višestruke vrijednosti atributa (na primjer, više telefonskih brojeva za kontakt za jednog klijenta) podržava ova "zadana" arhitektura.
В Model sidra tablice koje pohranjuju ključeve nazivaju se Sidra. I čuvaju:
- Samo surogat ključevi
- Link na izvor
- Zabilježite vrijeme dodavanja
Razmatraju se prirodni ključevi sa stajališta modela sidra obični atributi. Ova se opcija može činiti težom za razumijevanje, ali daje puno više prostora za identifikaciju objekta.
Na primjer, ako podaci o istom entitetu mogu doći iz različitih sustava, od kojih svaki koristi svoj prirodni ključ. U Data Vaultu to može dovesti do prilično glomaznih struktura od nekoliko čvorišta (jedan po izvoru + objedinjujuća glavna verzija), dok u modelu Anchor prirodni ključ svakog izvora pada u vlastiti atribut i može se koristiti pri učitavanju neovisno o svi ostali.
Ali ovdje postoji i jedna podmukla točka: ako su atributi iz različitih sustava kombinirani u jednom entitetu, najvjerojatnije postoje neki pravila "lijepljenja", po čemu sustav mora shvatiti da zapisi iz različitih izvora odgovaraju jednoj instanci entiteta.
В Trezor podataka ta će pravila najvjerojatnije odrediti formaciju “surogat hub” glavnog entiteta i ni na koji način ne utječu na čvorišta koja pohranjuju prirodne izvorne ključeve i njihove izvorne atribute. Ako se u nekom trenutku promijene pravila spajanja (ili ažuriraju atributi po kojima se ono izvodi), bit će dovoljno preformatirati surogat čvorišta.
В Model sidra takav će entitet najvjerojatnije biti pohranjen u jedino sidro. To znači da će svi atributi, bez obzira iz kojeg izvora dolaze, biti vezani za isti surogat. Razdvajanje pogrešno spojenih zapisa i, općenito, praćenje relevantnosti spajanja u takvom sustavu može biti mnogo teže, pogotovo ako su pravila prilično složena i često se mijenjaju, a isti atribut se može dobiti iz različitih izvora (iako je svakako moguće, jer svaka verzija atributa zadržava vezu na svoj izvor).
U svakom slučaju, ako vaš sustav treba implementirati funkcionalnost deduplikacija, spajanje zapisa i drugi elementi MDM-a, vrijedi obratiti posebnu pozornost na aspekte pohranjivanja prirodnih ključeva u agilnim metodologijama. Vjerojatno će glomazniji dizajn Data Vaulta odjednom biti sigurniji u smislu grešaka spajanja.
Model sidra također pruža dodatni tip objekta tzv Čvor u biti je poseban degenerirani tip sidra, koji može sadržavati samo jedan atribut. Čvorovi bi se trebali koristiti za pohranjivanje ravnih imenika (na primjer, spol, bračni status, kategorija korisničke službe itd.). Za razliku od Sidra, Čvor nema povezane tablice atributa, a njegov jedini atribut (ime) uvijek je pohranjen u istoj tablici s ključem. Čvorovi su povezani sa Sidrima veznim tablicama (Tie) na isti način kao što su Sidra međusobno povezana.
Ne postoji jasno mišljenje o korištenju čvorova. Na primjer, , koji aktivno promiče korištenje Anchor modela u Rusiji, smatra (ne bezrazložno) da se ni za jednu referentnu knjigu ne može sa sigurnošću tvrditi da uvijek bit će statični i jednorazinski, pa je bolje odmah koristiti punopravno sidro za sve objekte.
Još jedna važna razlika između Data Vaulta i Anchor modela je dostupnost atributi veza:
В Trezor podataka Veze su isti punopravni objekti kao i čvorišta i mogu ih imati vlastite atribute. U Model sidra Veze se koriste samo za povezivanje Sidra i ne mogu imati vlastite atribute. Ova razlika rezultira značajno različitim pristupima modeliranju činjenice, o čemu će se dalje raspravljati.
Pohranjivanje činjenica
Prije ovoga, govorili smo uglavnom o modeliranju mjerenja. Činjenice su malo manje jasne.
В Trezor podataka tipičan objekt za pohranjivanje činjenica je Veza, u čijim se satelitima dodaju stvarni pokazatelji.
Ovaj pristup se čini intuitivnim. Omogućuje jednostavan pristup analiziranim pokazateljima i općenito je sličan tradicionalnoj tablici činjenica (samo što se pokazatelji ne pohranjuju u samu tablicu, već u "susjedniju"). Ali postoje i zamke: jedna od tipičnih modifikacija modela - proširenje ključa činjenica - zahtijeva dodavanje novog vanjskog ključa u vezu. A to zauzvrat “razbija” modularnost i potencijalno uzrokuje potrebu za modifikacijama drugih objekata.
В Model sidra Veza ne može imati vlastite atribute, tako da ovaj pristup neće funkcionirati - apsolutno svi atributi i indikatori moraju biti povezani s jednim određenim sidrom. Zaključak iz ovoga je jednostavan - Svaka činjenica također treba svoje sidro. Za nešto od onoga što smo navikli doživljavati kao činjenice, to može izgledati prirodno - na primjer, činjenica kupnje može se savršeno svesti na objekt "narudžba" ili "prijam", posjet web-mjestu radi sesije itd. Ali postoje i činjenice za koje nije tako lako pronaći takav prirodni "noseći objekt" - na primjer, ostaci robe u skladištima na početku svakog dana.
Sukladno tome, problemi s modularnošću prilikom proširenja ključa činjenica u modelu sidra ne nastaju (dovoljno je jednostavno dodati novi odnos odgovarajućem sidru), ali dizajniranje modela za prikaz činjenica manje je jednoznačno; mogu se pojaviti "umjetna" sidra koji prikazuju model poslovnih objekata na nejasan način.
Kako se postiže fleksibilnost
Dobivena konstrukcija u oba slučaja sadrži znatno više stolovanego tradicionalno mjerenje. Ali može potrajati značajno manje prostora na disku s istim skupom verzioniranih atributa kao tradicionalna dimenzija. Naravno, tu nema nikakve magije - sve je u normalizaciji. Distribucijom atributa po Satelitima (u Trezoru podataka) ili pojedinačnim tablicama (Anchor Model), smanjujemo (ili potpuno uklanjamo) dupliciranje vrijednosti nekih atributa pri promjeni drugih.
za Trezor podataka dobici će ovisiti o raspodjeli atributa među satelitima, i za Model sidra — gotovo je izravno proporcionalan prosječnom broju verzija po objektu mjerenja.
Međutim, ušteda prostora važna je, ali ne i glavna prednost odvojenog pohranjivanja atributa. Zajedno s odvojenim skladištenjem odnosa, ovaj pristup čini trgovinu modularni dizajn. To znači da dodavanje pojedinačnih atributa i cijelih novih predmetnih područja u takav model izgleda ovako nadgradnja nad postojećim skupom objekata bez njihovog mijenjanja. I upravo je to ono što opisane metodologije čini fleksibilnima.
Ovo također podsjeća na prijelaz s proizvodnje komada na masovnu proizvodnju - ako je u tradicionalnom pristupu svaka tablica modela jedinstvena i zahtijeva posebnu pozornost, tada je u fleksibilnim metodologijama to već skup standardnih "dijelova". S jedne strane, ima više tablica, a procesi učitavanja i dohvaćanja podataka trebali bi izgledati kompliciranije. S druge strane, postaju tipičan. Što znači da ih može biti automatizirano i vođeno metapodacima. Pitanje "kako ćemo ga postaviti?", čiji bi odgovor mogao zauzeti značajan dio rada na dizajniranju poboljšanja, sada se jednostavno ne isplati (kao ni pitanje o utjecaju promjene modela na radne procese ).
To ne znači da analitičari uopće nisu potrebni u takvom sustavu - netko ipak mora proraditi skup objekata s atributima i smisliti gdje i kako sve to učitati. Ali količina posla, kao i vjerojatnost i cijena pogreške, značajno su smanjeni. Kako u fazi analize, tako i tijekom razvoja ETL-a, koji se u značajnom dijelu može svesti na editiranje metapodataka.
Tamna strana
Sve navedeno čini oba pristupa uistinu fleksibilnima, tehnološki naprednima i prikladnima za iterativna poboljšanja. Naravno, tu je i “bačva u masti”, za koju mislim da već možete pogoditi.
Dekompozicija podataka, koja je temelj modularnosti fleksibilnih arhitektura, dovodi do povećanja broja tablica i, sukladno tome, režijski troškovi da se pridružuje prilikom uzorkovanja. Da biste jednostavno dobili sve atribute dimenzije, u klasičnoj trgovini dovoljan je jedan odabir, ali će fleksibilna arhitektura zahtijevati cijeli niz spojeva. Štoviše, ako se sva ta spajanja za izvješća mogu napisati unaprijed, tada će analitičari koji su navikli ručno pisati SQL dvostruko patiti.
Postoji nekoliko činjenica koje olakšavaju ovu situaciju:
Kada radite s velikim dimenzijama, svi njegovi atributi se gotovo nikada ne koriste istovremeno. To znači da može biti manje spojeva nego što se čini na prvi pogled na model. Data Vault također može uzeti u obzir očekivanu učestalost dijeljenja prilikom dodjele atributa satelitima. U isto vrijeme, sama čvorišta ili sidra potrebna su prvenstveno za generiranje i mapiranje surogata u fazi učitavanja i rijetko se koriste u upitima (ovo se posebno odnosi na sidra).
Sva spajanja su po ključu. Osim toga, "komprimiraniji" način pohranjivanja podataka smanjuje troškove skeniranja tablica tamo gdje je to potrebno (na primjer, kod filtriranja prema vrijednosti atributa). To može dovesti do činjenice da će uzorkovanje iz normalizirane baze podataka s hrpom spojeva biti čak brže od skeniranja jedne teške dimenzije s mnogo verzija po retku.
Na primjer, ovdje u Članak sadrži detaljan usporedni test performansi modela Anchor s uzorkom iz jedne tablice.
Puno ovisi o motoru. Mnoge moderne platforme imaju interne mehanizme optimizacije spajanja. Na primjer, MS SQL i Oracle mogu "preskočiti" spojeve na tablice ako se njihovi podaci ne koriste nigdje osim za druge spojeve i ne utječu na konačan odabir (eliminacija tablica/spojova), a MPP Vertica , pokazao se izvrsnim motorom za sidreni model, s obzirom na ručnu optimizaciju plana upita. S druge strane, pohranjivanje Anchor modela, na primjer, na Click House, koji ima ograničenu podršku pridruživanja, još uvijek ne izgleda kao dobra ideja.
Osim toga, za obje arhitekture postoje posebne poteze, olakšavajući pristup podacima (i sa stajališta izvedbe upita i za krajnje korisnike). Na primjer, Tablice točke u vremenu u Data Vault ili posebne tablične funkcije u modelu Anchor.
Ukupno
Glavna bit razmatranih fleksibilnih arhitektura je modularnost njihovog “dizajna”.
Ovo svojstvo omogućuje:
- Nakon početnih priprema vezanih uz implementaciju metapodataka i pisanje osnovnih ETL algoritama, brzo pružiti kupcu prvi rezultat u obliku nekoliko izvješća koja sadrže podatke iz samo nekoliko izvornih objekata. Nije potrebno u potpunosti promisliti (čak ni na najvišoj razini) cijeli objektni model.
- Podatkovni model može početi raditi (i biti koristan) sa samo 2-3 objekta, a zatim postupno rasti (u vezi Anchor modela Nikolaja lijepa usporedba s micelijem).
- Većina poboljšanja, uključujući proširenje predmetnog područja i dodavanje novih izvora ne utječe na postojeću funkcionalnost i ne predstavlja opasnost od kvara nečega što već radi.
- Zahvaljujući dekompoziciji na standardne elemente, ETL procesi u takvim sustavima izgledaju isto, njihovo pisanje podložno je algoritmizaciji i, u konačnici, automatizacija.
Cijena ove fleksibilnosti je izvođenje. To ne znači da je na takvim modelima nemoguće postići prihvatljive performanse. Češće nego ne, možda će vam jednostavno trebati više truda i pažnje za detalje kako biste postigli mjerne podatke koje želite.
Apps
Vrste entiteta Trezor podataka
Više informacija o trezoru podataka:
Vrste entiteta Model sidra
Više detalja o modelu sidra:
Sažeta tablica sa zajedničkim karakteristikama i razlikama razmatranih pristupa:
Izvor: www.habr.com