Ievads
"Jums jÄskrien, cik Ätri vien iespÄjams, lai paliktu vietÄ,
un, lai kaut kur tiktu, jÄskrien vismaz divreiz ÄtrÄk!ā
c) Alise BrÄ«numzemÄ
Pirms kÄda laika mani lÅ«dza nolasÄ«t lekciju analÄ«tiÄ·i mÅ«su uzÅÄmumu par datu modeļu projektÄÅ”anas tÄmu, jo, ilgstoÅ”i (dažkÄrt vairÄkus gadus) sÄžot pie projektiem, mÄs aizmirstam par to, kas notiek mums apkÄrt IT tehnoloÄ£iju pasaulÄ. MÅ«su kompÄnijÄ (tas tÄ notiek) daudzos projektos netiek izmantotas NoSQL datu bÄzes (vismaz pagaidÄm), tÄpÄc savÄ lekcijÄ tiem atseviŔķi pievÄrsu uzmanÄ«bu, izmantojot HBase piemÄru un mÄÄ£inÄju orientÄt materiÄla prezentÄciju uz tÄm. kuri tos nekad nav izmantojuÅ”i, ir strÄdÄjuÅ”i. Jo Ä«paÅ”i es ilustrÄju dažas datu modeļa dizaina iezÄ«mes, izmantojot piemÄru, ko izlasÄ«ju pirms vairÄkiem gadiem
Nesen āno neko darÄ«tā uzdevu sev jautÄjumu (tam Ä«paÅ”i labvÄlÄ«ga ir maija garÄ nedÄļas nogale karantÄ«nÄ), cik ļoti teorÄtiskie aprÄÄ·ini atbildÄ«s praksei? PatiesÄ«bÄ tÄ radÄs Ŕī raksta ideja. IzstrÄdÄtÄjs, kurÅ” ir strÄdÄjis ar NoSQL vairÄkas dienas, var neko jaunu no tÄ neiemÄcÄ«ties (un tÄpÄc var uzreiz izlaist pusi raksta). Bet priekÅ” analÄ«tiÄ·iTiem, kuri vÄl nav cieÅ”i sadarbojuÅ”ies ar NoSQL, manuprÄt, tas noderÄs, lai iegÅ«tu pamata izpratni par HBase datu modeļu projektÄÅ”anas iezÄ«mÄm.
AnalÄ«zes piemÄrs
ManuprÄt, pirms sÄkat lietot NoSQL datu bÄzes, jums rÅ«pÄ«gi jÄpÄrdomÄ un jÄizsver plusi un mÄ«nusi. Bieži vien problÄmu, visticamÄk, var atrisinÄt, izmantojot tradicionÄlÄs relÄciju DBVS. TÄpÄc labÄk neizmantot NoSQL bez bÅ«tiskiem iemesliem. Ja tomÄr nolÄmÄt izmantot NoSQL datu bÄzi, jÄÅem vÄrÄ, ka dizaina pieejas Å”eit ir nedaudz atŔķirÄ«gas. ÄŖpaÅ”i daži no tiem var bÅ«t neparasti tiem, kuri iepriekÅ” ir nodarbojuÅ”ies tikai ar relÄciju DBVS (pÄc maniem novÄrojumiem). TÄtad ārelÄcijuā pasaulÄ mÄs parasti sÄkam ar problÄmas jomas modelÄÅ”anu un tikai tad, ja nepiecieÅ”ams, modeli denormalizÄjam. NoSQL mÄs nekavÄjoties jÄÅem vÄrÄ paredzamie scenÄriji darbam ar datiem un sÄkotnÄji denormalizÄ datus. TurklÄt ir vairÄkas citas atŔķirÄ«bas, kas tiks aplÅ«kotas turpmÄk.
ApsvÄrsim Å”Ädu āsintÄtiskoā problÄmu, ar kuru mÄs turpinÄsim strÄdÄt:
Ir nepiecieÅ”ams izveidot uzglabÄÅ”anas struktÅ«ru kÄda abstrakta sociÄlÄ tÄ«kla lietotÄju draugu sarakstam. Lai vienkÄrÅ”otu, mÄs pieÅemsim, ka visi mÅ«su savienojumi ir vÄrsti (kÄ Instagram, nevis Linkedin). StruktÅ«rai jÄļauj efektÄ«vi:
- Atbildiet uz jautÄjumu, vai lietotÄjs A lasa lietotÄju B (lasÄ«Å”anas shÄma)
- Atļaut pievienot/noÅemt savienojumus, ja lietotÄjs A abonÄ/atceļ abonementu no lietotÄja B (datu maiÅas veidne)
Protams, problÄmas risinÄÅ”anai ir daudz iespÄju. ParastÄ relÄciju datu bÄzÄ mÄs, visticamÄk, vienkÄrÅ”i izveidosim attiecÄ«bu tabulu (iespÄjams, ja, piemÄram, mums ir jÄsaglabÄ lietotÄju grupa: Ä£imene, darbs utt., kurÄ ietilpst Å”is ādraugsā), un optimizÄtu piekļuves Ätrums pievienotu indeksus / sadalÄ«Å”anu. VisticamÄk, finÄla galds izskatÄ«sies apmÄram Å”Ädi:
user_id
drauga_id
Vasja
Petja
Vasja
ŠŠ»Ń
turpmÄk skaidrÄ«bas un labÄkas izpratnes labad norÄdÄ«Å”u vÄrdus, nevis ID
HBase gadÄ«jumÄ mÄs zinÄm, ka:
- ir iespÄjama efektÄ«va meklÄÅ”ana, kuras rezultÄtÄ netiek veikta pilna tabulas skenÄÅ”ana tikai ar atslÄgu
- patiesÄ«bÄ tÄpÄc daudziem pazÄ«stamu SQL vaicÄjumu rakstÄ«Å”ana Å”ÄdÄs datu bÄzÄs ir slikta ideja; tehniski, protams, no tÄs paÅ”as Impalas var nosÅ«tÄ«t SQL vaicÄjumu ar Joins un citu loÄ£iku uz HBase, bet cik tas bÅ«s efektÄ«vi...
TÄpÄc kÄ atslÄgu esam spiesti izmantot lietotÄja ID. Un mana pirmÄ doma par tÄmu "kur un kÄ uzglabÄt draugu ID?" varbÅ«t ir ideja tos glabÄt kolonnÄs. Å Ä« visredzamÄkÄ un ānaivÄkÄā opcija izskatÄ«sies apmÄram Å”Ädi (sauksim to 1. iespÄja (noklusÄjums)turpmÄkai uzziÅai):
RowKey
RunÄtÄji
Vasja
1: Petja
2: Olja
3: DaŔa
Petja
1: MaŔa
2: Vasja
Å eit katra rinda atbilst vienam tÄ«kla lietotÄjam. KolonnÄm ir nosaukumi: 1, 2, ... - atbilstoÅ”i draugu skaitam, un kolonnÄs tiek saglabÄti draugu ID. Ir svarÄ«gi Åemt vÄrÄ, ka katrÄ rindÄ bÅ«s atŔķirÄ«gs kolonnu skaits. IepriekÅ”ÄjÄ attÄla piemÄrÄ vienÄ rindÄ ir trÄ«s kolonnas (1, 2 un 3), bet otrajÄ ir tikai divas (1 un 2) - Å”eit mÄs paÅ”i izmantojÄm divus HBase rekvizÄ«tus, kuru relÄciju datu bÄzÄm nav:
- iespÄja dinamiski mainÄ«t kolonnu sastÄvu (pievienot draugu -> pievienot kolonnu, noÅemt draugu -> dzÄst kolonnu)
- dažÄdÄm rindÄm var bÅ«t atŔķirÄ«gs kolonnu sastÄvs
PÄrbaudÄ«sim, vai mÅ«su struktÅ«ra atbilst uzdevuma prasÄ«bÄm:
- Datu lasÄ«Å”ana: lai saprastu, vai Vasja ir abonÄjusi Olya, mums bÅ«s jÄatÅem visa lÄ«nija ar taustiÅu RowKey = āVasyaā un kÄrtojiet kolonnu vÄrtÄ«bas, lÄ«dz tajÄs ātiekamā Olya. Vai atkÄrtojiet visu sleju vÄrtÄ«bas, "neatbilst" Oljai un atgrieziet atbildi Nepatiesi;
- Datu rediÄ£ÄÅ”ana: drauga pievienoÅ”ana: lÄ«dzÄ«gam uzdevumam mums arÄ« jÄatÅem visa lÄ«nija izmantojot taustiÅu RowKey = āVasyaā, lai aprÄÄ·inÄtu viÅa draugu kopÄjo skaitu. Mums ir nepiecieÅ”ams Å”is kopÄjais draugu skaits, lai noteiktu kolonnas numuru, kurÄ mums ir jÄpieraksta jaunÄ drauga ID.
- Datu maiÅa: drauga dzÄÅ”ana:
- Vajag atÅemt visa lÄ«nija ar taustiÅu RowKey = āVasyaā un kÄrtojiet kolonnas, lai atrastu to, kurÄ ir ierakstÄ«ts dzÄÅ”amais draugs;
- PÄc tam, pÄc drauga dzÄÅ”anas, visi dati ir ājÄpÄrvietoā vienÄ kolonnÄ, lai to numerÄcijÄ nerastos ānepilnÄ«basā.
Tagad novÄrtÄsim, cik produktÄ«vi bÅ«s Å”ie algoritmi, kas mums bÅ«s jÄievieÅ” ānosacÄ«juma lietojumaā pusÄ, izmantojot
- Datu lasÄ«Å”ana: ir nepiecieÅ”ams atÅemt visu lÄ«niju un atkÄrtot visas tÄs kolonnas limitÄ. Tas nozÄ«mÄ, ka izmaksu augÅ”ÄjÄ aplÄse bÅ«s aptuveni O(n)
- Datu rediÄ£ÄÅ”ana: drauga pievienoÅ”ana: lai noteiktu draugu skaitu, jums ir jÄatkÄrto visas rindas kolonnas un pÄc tam jÄievieto jauna kolonna => O(n)
- Datu maiÅa: drauga dzÄÅ”ana:
- LÄ«dzÄ«gi kÄ pievienoÅ”ana ā jums jÄiet cauri visÄm ierobežojuma kolonnÄm => O(n)
- PÄc kolonnu noÅemÅ”anas mums tÄs ir ājÄpÄrvietoā. Ja jÅ«s ieviesÄ«sit Å”o "galvu", tad limitÄ jums bÅ«s nepiecieÅ”amas lÄ«dz (n-1) darbÄ«bÄm. Bet Å”eit un turpmÄk praktiskajÄ daÄ¼Ä mÄs izmantosim citu pieeju, kas ieviesÄ«s āpseido-nobÄ«diā noteiktam darbÄ«bu skaitam - tas ir, tam tiks pavadÄ«ts pastÄvÄ«gs laiks neatkarÄ«gi no n. Å o konstanto laiku (precÄ«zÄk O(2)) var neÅemt vÄrÄ, salÄ«dzinot ar O(n). Pieeja ir parÄdÄ«ta zemÄk esoÅ”ajÄ attÄlÄ: mÄs vienkÄrÅ”i kopÄjam datus no āpÄdÄjÄsā kolonnas uz to, no kuras vÄlamies dzÄst datus, un pÄc tam izdzÄÅ”am pÄdÄjo kolonnu:
KopumÄ visos scenÄrijos mÄs saÅÄmÄm asimptotisku skaitļoÅ”anas sarežģītÄ«bu O (n).
DroÅ”i vien jau esat pamanÄ«juÅ”i, ka mums gandrÄ«z vienmÄr ir jÄizlasa visa rinda no datu bÄzes un divos gadÄ«jumos no trim, lai tikai izietu visas kolonnas un aprÄÄ·inÄtu kopÄjo draugu skaitu. TÄpÄc optimizÄcijas mÄÄ£inÄjumam varat pievienot kolonnu ācountā, kurÄ tiek saglabÄts katra tÄ«kla lietotÄja kopÄjais draugu skaits. Å ajÄ gadÄ«jumÄ mÄs nevaram izlasÄ«t visu rindu, lai aprÄÄ·inÄtu kopÄjo draugu skaitu, bet lasÄ«t tikai vienu kolonnu āskaitsā. Galvenais ir neaizmirst atjauninÄt āskaituā, manipulÄjot ar datiem. Tas. mÄs uzlabojamies 2. iespÄja (skaits):
RowKey
RunÄtÄji
Vasja
1: Petja
2: Olja
3: DaŔa
skaits: 3
Petja
1: MaŔa
2: Vasja
skaits: 2
SalÄ«dzinot ar pirmo iespÄju:
- Datu lasÄ«Å”ana: lai saÅemtu atbildi uz jautÄjumu āVai Vasja lasa Olju?ā nekas nav mainÄ«jies => O(n)
- Datu rediÄ£ÄÅ”ana: drauga pievienoÅ”ana: MÄs esam vienkÄrÅ”ojuÅ”i jauna drauga ievietoÅ”anu, jo tagad mums nav jÄlasa visa rinda un jÄatkÄrto tÄs kolonnas, bet mÄs varam iegÅ«t tikai kolonnas ācountā vÄrtÄ«bu utt. nekavÄjoties nosakiet kolonnas numuru, lai ievietotu jaunu draugu. Tas noved pie skaitļoÅ”anas sarežģītÄ«bas samazinÄÅ”anÄs lÄ«dz O (1)
- Datu maiÅa: drauga dzÄÅ”ana: DzÄÅ”ot draugu, mÄs varam arÄ« izmantot Å”o kolonnu, lai samazinÄtu I/O operÄciju skaitu, kad āpÄrvietojotā datus par vienu Ŕūnu pa kreisi. Bet joprojÄm ir nepiecieÅ”ams atkÄrtot kolonnas, lai atrastu to, kas ir jÄizdzÄÅ”, tÄpÄc => āāO(n)
- No otras puses, tagad, atjaunojot datus, katru reizi ir jÄatjaunina kolonna "skaits", bet tas aizÅem nemainÄ«gu laiku, ko var neievÄrot O-simbolu ietvaros.
KopumÄ 2. variants Ŕķiet nedaudz optimÄlÄks, taÄu tas vairÄk atgÄdina āevolÅ«ciju, nevis revolÅ«cijuā. Lai veiktu ārevolÅ«cijuā, mums tas bÅ«s vajadzÄ«gs 3. iespÄja (kolonna).
ApgriezÄ«sim visu otrÄdi: pieŔķirsim kolonnas nosaukums lietotÄja ID! Tas, kas tiks ierakstÄ«ts paÅ”Ä ailÄ, mums vairs nav svarÄ«gs, lai tas ir cipars 1 (vispÄr tur var glabÄt noderÄ«gas lietas, piemÄram, grupa āÄ£imene/draugi/utt.ā). Å Äda pieeja var pÄrsteigt nesagatavotu ālajiā, kuram nav iepriekÅ”Äjas pieredzes darbÄ ar NoSQL datu bÄzÄm, taÄu tieÅ”i Ŕī pieeja ļauj daudz efektÄ«vÄk izmantot HBase potenciÄlu Å”ajÄ uzdevumÄ:
RowKey
RunÄtÄji
Vasja
Petja: 1
Ola: 1
DaŔa: 1
Petja
MaŔa: 1
Vasja: 1
Å eit mÄs iegÅ«stam vairÄkas priekÅ”rocÄ«bas vienlaikus. Lai tos saprastu, analizÄsim jauno struktÅ«ru un novÄrtÄsim skaitļoÅ”anas sarežģītÄ«bu:
- Datu lasÄ«Å”ana: lai atbildÄtu uz jautÄjumu, vai Vasja ir abonÄjusi Olya, pietiek izlasÄ«t vienu sleju "Olya": ja tÄ ir, tad atbilde ir Patiesa, ja nÄ - Nepatiesi => O(1)
- Datu rediÄ£ÄÅ”ana: drauga pievienoÅ”ana: drauga pievienoÅ”ana: vienkÄrÅ”i pievienojiet jaunu kolonnu āDrauga IDā => O(1)
- Datu maiÅa: drauga dzÄÅ”ana: vienkÄrÅ”i noÅemiet sleju Drauga ID => O(1)
KÄ redzat, Ŕī uzglabÄÅ”anas modeļa bÅ«tiska priekÅ”rocÄ«ba ir tÄ, ka visos mums nepiecieÅ”amajos scenÄrijos mÄs darbojamies tikai ar vienu kolonnu, izvairoties no datu bÄzes visas rindas nolasÄ«Å”anas un turklÄt visu Ŕīs rindas kolonnu uzskaitÄ«Å”anas. MÄs varÄtu pie tÄ apstÄties, bet...
Piekļūstot datu bÄzei, varat bÅ«t neizpratnÄ un doties nedaudz tÄlÄk pa ceļu, optimizÄjot veiktspÄju un samazinot I/O darbÄ«bas. KÄ bÅ«tu, ja mÄs saglabÄtu visu attiecÄ«bu informÄciju tieÅ”i paÅ”Ä rindas atslÄgÄ? Tas ir, padarÄ«t atslÄgu saliktu, piemÄram, userID.friendID? Å ajÄ gadÄ«jumÄ mums pat nav jÄlasa rindas kolonnas (4. iespÄja (rinda)):
RowKey
RunÄtÄji
Vasja.Petja
Petja: 1
Vasja.Olja
Ola: 1
Vasja.DaŔa
DaŔa: 1
Petja.MaŔa
MaŔa: 1
Petja.Vasja
Vasja: 1
AcÄ«mredzot visu datu manipulÄcijas scenÄriju novÄrtÄjums Å”ÄdÄ struktÅ«rÄ, tÄpat kÄ iepriekÅ”ÄjÄ versijÄ, bÅ«s O(1). AtŔķirÄ«ba no 3. iespÄjas bÅ«s tikai datu bÄzÄ veikto I/O darbÄ«bu efektivitÄtÄ.
Nu, pÄdÄjais ālociÅÅ”ā. Ir viegli redzÄt, ka 4. opcijÄ rindas taustiÅam bÅ«s mainÄ«gs garums, kas, iespÄjams, var ietekmÄt veiktspÄju (Å”eit mÄs atceramies, ka HBase saglabÄ datus kÄ baitu kopu, un rindas tabulÄs tiek sakÄrtotas pÄc atslÄgas). TurklÄt mums ir atdalÄ«tÄjs, kas dažos gadÄ«jumos var bÅ«t jÄapstrÄdÄ. Lai novÄrstu Å”o ietekmi, varat izmantot jaucÄjus no userID un friendID, un, tÄ kÄ abÄm jaukÅ”anÄm bÅ«s nemainÄ«gs garums, varat tÄs vienkÄrÅ”i savienot, neizmantojot atdalÄ«tÄju. Tad dati tabulÄ izskatÄ«sies Å”Ädi (5. iespÄja (jaukts)):
RowKey
RunÄtÄji
dc084ef00e94aef49be885f9b01f51c01918fa783851db0dc1f72f83d33a5994
Petja: 1
dc084ef00e94aef49be885f9b01f51c0f06b7714b5ba522c3cf51328b66fe28a
Ola: 1
dc084ef00e94aef49be885f9b01f51c00d2c2e5d69df6b238754f650d56c896a
DaŔa: 1
1918fa783851db0dc1f72f83d33a59949ee3309645bd2c0775899fca14f311e1
MaŔa: 1
1918fa783851db0dc1f72f83d33a5994dc084ef00e94aef49be885f9b01f51c0
Vasja: 1
AcÄ«mredzot algoritmiskÄ sarežģītÄ«ba darbam ar Å”Ädu struktÅ«ru scenÄrijos, kurus mÄs apsveram, bÅ«s tÄda pati kÄ 4. iespÄjai, tas ir, O(1).
KopumÄ apkoposim visas mÅ«su aprÄÄ·inu sarežģītÄ«bas aplÄses vienÄ tabulÄ:
Drauga pievienoŔana
PÄrbauda draugu
Drauga noÅemÅ”ana
1. iespÄja (noklusÄjums)
O (n)
O (n)
O (n)
2. iespÄja (skaitÄ«Å”ana)
O (1)
O (n)
O (n)
3. iespÄja (kolonna)
O (1)
O (1)
O (1)
4. iespÄja (rinda)
O (1)
O (1)
O (1)
5. iespÄja (jaukts)
O (1)
O (1)
O (1)
KÄ redzat, 3.-5. variants Ŕķiet vispiemÄrotÄkais un teorÄtiski nodroÅ”ina visu nepiecieÅ”amo datu manipulÄcijas scenÄriju izpildi nemainÄ«gÄ laikÄ. MÅ«su uzdevuma apstÄkļos nav skaidras prasÄ«bas iegÅ«t visu lietotÄja draugu sarakstu, taÄu reÄlÄs projekta aktivitÄtÄs mums kÄ labiem analÄ«tiÄ·iem bÅ«tu labi āparedzÄtā, ka Å”Äds uzdevums varÄtu rasties un "izklÄj salmiÅu." TÄpÄc manas simpÄtijas ir 3. varianta pusÄ. Bet diezgan iespÄjams, ka reÄlÄ projektÄ Å”o pieprasÄ«jumu jau varÄja atrisinÄt ar citiem lÄ«dzekļiem, tÄpÄc bez vispÄrÄja redzÄjuma par visu problÄmu labÄk neizdarÄ«t galÄ«gie secinÄjumi.
Eksperimenta sagatavoŔana
IepriekÅ” minÄtos teorÄtiskos argumentus vÄlos pÄrbaudÄ«t praksÄ ā tÄds bija garajÄ nedÄļas nogalÄ raduÅ”Äs idejas mÄrÄ·is. Lai to izdarÄ«tu, ir jÄnovÄrtÄ mÅ«su ānosacÄ«juma lietojumprogrammasā darbÄ«bas Ätrums visos aprakstÄ«tajos datu bÄzes izmantoÅ”anas scenÄrijos, kÄ arÄ« Ŕī laika pieaugums, palielinoties sociÄlÄ tÄ«kla izmÄram (n). MÄrÄ·a parametrs, kas mÅ«s interesÄ un ko mÄs mÄrÄ«sim eksperimenta laikÄ, ir laiks, ko ānosacÄ«juma lietojumprogrammaā pavada vienas ābiznesa operÄcijasā veikÅ”anai. Ar ābiznesa darÄ«jumuā mÄs domÄjam vienu no Å”iem:
- Viena jauna drauga pievienoŔana
- PÄrbauda, āāvai lietotÄjs A ir lietotÄja B draugs
- Viena drauga noÅemÅ”ana
TÄdÄjÄdi, Åemot vÄrÄ sÄkotnÄjÄ paziÅojumÄ izklÄstÄ«tÄs prasÄ«bas, pÄrbaudes scenÄrijs ir Å”Äds:
- Datu ierakstÄ«Å”ana. NejauÅ”i Ä£enerÄjiet sÄkotnÄjo tÄ«klu ar izmÄru n. Lai tuvinÄtu āreÄlo pasauliā, katra lietotÄja draugu skaits ir arÄ« nejauÅ”s mainÄ«gais. IzmÄriet laiku, kurÄ mÅ«su ānosacÄ«juma lietojumprogrammaā ieraksta visus Ä£enerÄtos datus HBase. PÄc tam iegÅ«to laiku sadaliet ar kopÄjo pievienoto draugu skaitu - Å”Ädi mÄs iegÅ«stam vidÄjo vienas ābiznesa operÄcijasā laiku.
- Datu lasÄ«Å”ana. Katram lietotÄjam izveidojiet "personÄ«bu" sarakstu, par kurÄm jums ir jÄsaÅem atbilde, vai lietotÄjs ir tÄs abonÄjis vai nÄ. Saraksta garums = aptuveni lietotÄja draugu skaits, un pusei no pÄrbaudÄ«tajiem draugiem jÄatbild āJÄā, bet otrai pusei ā āNÄā. PÄrbaude tiek veikta tÄdÄ secÄ«bÄ, ka atbildes āJÄā un āNÄā mijas (tas ir, katrÄ otrajÄ gadÄ«jumÄ mums bÅ«s jÄiziet visas rindas kolonnas 1. un 2. variantam). KopÄjais skrÄ«ninga laiks tiek dalÄ«ts ar pÄrbaudÄ«to draugu skaitu, lai iegÅ«tu vidÄjo skrÄ«ninga laiku vienam subjektam.
- Datu dzÄÅ”ana. NoÅemiet visus draugus no lietotÄja. TurklÄt dzÄÅ”anas secÄ«ba ir nejauÅ”a (tas ir, mÄs āsajaucamā sÄkotnÄjo sarakstu, ko izmantoja datu ierakstÄ«Å”anai). KopÄjais pÄrbaudes laiks tiek dalÄ«ts ar noÅemto draugu skaitu, lai iegÅ«tu vidÄjo pÄrbaudes laiku.
ScenÄriji ir jÄizpilda katrai no 5 datu modeļa opcijÄm un dažÄdiem sociÄlÄ tÄ«kla izmÄriem, lai redzÄtu, kÄ mainÄs laiks, tam augot. Viena n robežÄs savienojumiem tÄ«klÄ un pÄrbaudÄmo lietotÄju sarakstam, protams, jÄbÅ«t vienÄdiem visÄm 5 opcijÄm.
Lai labÄk izprastu, tÄlÄk ir sniegts Ä£enerÄto datu piemÄrs n=5. RakstÄ«tais āÄ£eneratorsā kÄ izvadi rada trÄ«s ID vÄrdnÄ«cas:
- pirmais ir paredzÄts ievietoÅ”anai
- otrais ir paredzÄts pÄrbaudei
- treÅ”ais ā par svÄ«troÅ”anu
{0: [1], 1: [4, 5, 3, 2, 1], 2: [1, 2], 3: [2, 4, 1, 5, 3], 4: [2, 1]} # Š²ŃŠµŠ³Š¾ 15 Š“ŃŃŠ·ŠµŠ¹
{0: [1, 10800], 1: [5, 10800, 2, 10801, 4, 10802], 2: [1, 10800], 3: [3, 10800, 1, 10801, 5, 10802], 4: [2, 10800]} # Š²ŃŠµŠ³Š¾ 18 ŠæŃŠ¾Š²ŠµŃŃŠµŠ¼ŃŃ
ŃŃŠ±ŃŠµŠŗŃŠ¾Š²
{0: [1], 1: [1, 3, 2, 5, 4], 2: [1, 2], 3: [4, 1, 2, 3, 5], 4: [1, 2]} # Š²ŃŠµŠ³Š¾ 15 Š“ŃŃŠ·ŠµŠ¹
KÄ redzat, visi pÄrbaudes vÄrdnÄ«cÄ norÄdÄ«tie ID, kas ir lielÄki par 10 000, ir tieÅ”i tie, kas noteikti sniegs atbildi Nepatiesi. āDrauguā ievietoÅ”ana, pÄrbaude un dzÄÅ”ana tiek veikta precÄ«zi vÄrdnÄ«cÄ norÄdÄ«tajÄ secÄ«bÄ.
Eksperiments tika veikts klÄpjdatorÄ, kurÄ darbojas operÄtÄjsistÄma Windows 10, kur vienÄ Docker konteinerÄ darbojÄs HBase, bet otrÄ darbojÄs Python ar Jupyter Notebook. Docker tika pieŔķirti 2 CPU kodoli un 2 GB RAM. Visa loÄ£ika, piemÄram, ānosacÄ«juma lietojumprogrammasā un ācauruļvaduā emulÄcija testa datu Ä£enerÄÅ”anai un laika mÄrÄ«Å”anai, tika uzrakstÄ«ta Python valodÄ. BibliotÄka tika izmantota darbam ar HBase
Å emot vÄrÄ konkrÄta klÄpjdatora skaitļoÅ”anas jaudu, eksperimentÄli tika izvÄlÄta palaiÅ”ana n = 10, 30, ā¦. 170 ā kad pilnais testÄÅ”anas cikla kopÄjais darbÄ«bas laiks (visiem scenÄrijiem visiem variantiem visiem n) bija pat vairÄk vai mazÄk saprÄtÄ«gs un ietilpa vienas tÄjas ballÄ«tes laikÄ (vidÄji 15 minÅ«tes).
Å eit ir jÄpiezÄ«mÄ, ka Å”ajÄ eksperimentÄ mÄs galvenokÄrt nenovÄrtÄjam absolÅ«tos veiktspÄjas rÄdÄ«tÄjus. Pat relatÄ«vs dažÄdu divu iespÄju salÄ«dzinÄjums var nebÅ«t pilnÄ«gi pareizs. Tagad mÅ«s interesÄ laika izmaiÅu raksturs atkarÄ«bÄ no n, jo, Åemot vÄrÄ iepriekÅ” minÄto ātesta stendaā konfigurÄciju, ir ļoti grÅ«ti iegÅ«t laika aprÄÄ·inus, kas āattÄ«rÄ«tiā no nejauÅ”u un citu faktoru ietekmes ( un Å”Äds uzdevums netika izvirzÄ«ts).
Eksperimenta rezultÄts
Pirmais tests ir, kÄ mainÄs draugu saraksta aizpildÄ«Å”anai pavadÄ«tais laiks. RezultÄts ir redzams zemÄk esoÅ”ajÄ grafikÄ.
Opcijas 3-5, kÄ paredzÄts, parÄda gandrÄ«z nemainÄ«gu ābiznesa darÄ«jumaā laiku, kas nav atkarÄ«gs no tÄ«kla lieluma pieauguma un neatŔķiramas veiktspÄjas atŔķirÄ«bas.
2. variants arÄ« parÄda nemainÄ«gu, bet nedaudz sliktÄku veiktspÄju, gandrÄ«z tieÅ”i 2 reizes salÄ«dzinÄjumÄ ar 3.ā5. Un tas nevar vien priecÄties, jo tas korelÄ ar teoriju - Å”ajÄ versijÄ I/O operÄciju skaits uz/no HBase ir tieÅ”i 2 reizes lielÄks. Tas var kalpot kÄ netieÅ”s pierÄdÄ«jums tam, ka mÅ«su testÄÅ”anas stends principÄ nodroÅ”ina labu precizitÄti.
ArÄ« 1. iespÄja, kÄ gaidÄ«ts, izrÄdÄs vislÄnÄkÄ un parÄda lineÄru laika pieaugumu, kas pavadÄ«ts, lai tÄ«kla lielumu papildinÄtu viens ar otru.
Tagad apskatÄ«sim otrÄ testa rezultÄtus.
Opcijas 3-5 atkal darbojas kÄ paredzÄts ā nemainÄ«gs laiks, neatkarÄ«gi no tÄ«kla lieluma. 1. un 2. opcija parÄda lineÄru laika pieaugumu, palielinoties tÄ«kla izmÄram un lÄ«dzÄ«gu veiktspÄju. TurklÄt 2. iespÄja izrÄdÄs nedaudz lÄnÄka - acÄ«mredzot tÄpÄc, ka ir jÄpÄrlasa un jÄapstrÄdÄ papildu kolonna āskaitsā, kas kļūst pamanÄmÄka, pieaugot n. Bet es joprojÄm atturÄÅ”os izdarÄ«t secinÄjumus, jo Ŕī salÄ«dzinÄjuma precizitÄte ir salÄ«dzinoÅ”i zema. TurklÄt Ŕīs attiecÄ«bas (kura opcija ā 1 vai 2 ir ÄtrÄka) ir mainÄ«tas no skrieÅ”anas uz skrÄjienu (saglabÄjot atkarÄ«bas raksturu un ānovÄrst pa kakluā).
Nu, pÄdÄjais grafiks ir noÅemÅ”anas pÄrbaudes rezultÄts.
Å eit atkal nav nekÄdu pÄrsteigumu. Opcijas 3-5 veic noÅemÅ”anu nemainÄ«gÄ laikÄ.
TurklÄt interesanti ir tas, ka 4. un 5. variants, atŔķirÄ«bÄ no iepriekÅ”Äjiem scenÄrijiem, uzrÄda manÄmi nedaudz sliktÄku veiktspÄju nekÄ 3. variants. AcÄ«mredzot rindas dzÄÅ”anas operÄcija ir dÄrgÄka nekÄ kolonnu dzÄÅ”anas darbÄ«ba, kas kopumÄ ir loÄ£iski.
1. un 2. variants, kÄ paredzÄts, parÄda lineÄru laika pieaugumu. TajÄ paÅ”Ä laikÄ 2. iespÄja vienmÄr ir lÄnÄka nekÄ 1. opcija, jo tiek veikta papildu I/O darbÄ«ba, lai āuzturÄtuā skaitÄ«Å”anas kolonnu.
Eksperimenta vispÄrÄ«gie secinÄjumi:
- 3.ā5. iespÄja demonstrÄ lielÄku efektivitÄti, jo tajÄs tiek izmantotas HBase priekÅ”rocÄ«bas; TurklÄt to veiktspÄja atŔķiras viena pret otru ar konstanti un nav atkarÄ«ga no tÄ«kla lieluma.
- AtŔķirÄ«ba starp 4. un 5. variantu netika reÄ£istrÄta. Bet tas nenozÄ«mÄ, ka nevajadzÄtu izmantot 5. iespÄju. VisticamÄk, ka izmantotais eksperimentÄlais scenÄrijs, Åemot vÄrÄ testa stenda veiktspÄjas raksturlielumus, neļÄva to atklÄt.
- Laika pieauguma raksturs, kas nepiecieÅ”ams ābiznesa operÄcijuā veikÅ”anai ar datiem, kopumÄ apstiprinÄja iepriekÅ” iegÅ«tos teorÄtiskos aprÄÄ·inus visÄm iespÄjÄm.
Epilogs
Aptuvenos veiktos eksperimentus nevajadzÄtu uztvert kÄ absolÅ«tu patiesÄ«bu. Ir daudzi faktori, kas netika Åemti vÄrÄ un izkropļoja rezultÄtus (Ŕīs svÄrstÄ«bas Ä«paÅ”i redzamas grafikos ar mazu tÄ«kla izmÄru). PiemÄram, taupÄ«bas Ätrums, ko izmanto happybase, apjoms un loÄ£ikas ievieÅ”anas metode, ko rakstÄ«ju Python (nevaru apgalvot, ka kods tika uzrakstÄ«ts optimÄli un efektÄ«vi izmantoja visu komponentu iespÄjas), iespÄjams, HBase keÅ”atmiÅas funkcijas, Windows 10 fona aktivitÄtes manÄ klÄpjdatorÄ utt. KopumÄ varam pieÅemt, ka visi teorÄtiskie aprÄÄ·ini ir eksperimentÄli pierÄdÄ«juÅ”i to derÄ«gumu. Nu, vai vismaz tos ar Å”Ädu āuzbraucienu ar galvuā nebija iespÄjams atspÄkot.
NoslÄgumÄ ieteikumi visiem, kas tikai sÄk veidot datu modeļus HBase: abstrakti no iepriekÅ”ÄjÄs pieredzes darbÄ ar relÄciju datu bÄzÄm un atcerieties ābauŔļusā:
- ProjektÄjot, mÄs vadÄmies no datu manipulÄcijas uzdevuma un modeļiem, nevis no domÄna modeļa
- EfektÄ«va piekļuve (bez pilnas tabulas skenÄÅ”anas) ā tikai ar atslÄgu
- DenormalizÄcija
- DažÄdÄs rindÄs var bÅ«t dažÄdas kolonnas
- SkaļruÅu dinamiskais sastÄvs
Avots: www.habr.com