NoSQL datu modeļa izstrādes iezīmes

Ievads

NoSQL datu modeļa izstrādes iezīmes "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 Amandeep Khurana rakstā ā€œIevads HB ase shēmu izstrādēā€.. Analizējot piemērus, es salÄ«dzināju vairākas vienas un tās paÅ”as problēmas risināŔanas iespējas, lai labāk nodotu auditorijai galvenās idejas.

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 O-simbolisms. ApzÄ«mēsim mÅ«su hipotētiskā sociālā tÄ«kla lielumu ar n. Tad maksimālais draugu skaits vienam lietotājam ir (n-1). Å o (-1) mēs varam neņemt vērā mÅ«su vajadzÄ«bām, jo ā€‹ā€‹O-simbolu izmantoÅ”anas ietvaros tas ir mazsvarÄ«gi.

  • 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:
      NoSQL datu modeļa izstrādes iezīmes

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 laimÄ«gā bāze, lai aprēķinātu jaucējvērtÄ«bas (MD5) 5. opcijai - hashlib

Ņ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ā.
NoSQL datu modeļa izstrādes iezīmes
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.
NoSQL datu modeļa izstrādes iezīmes
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.

NoSQL datu modeļa izstrādes iezīmes

Å 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

Pievieno komentāru