Vipengele vya kuunda muundo wa data kwa NoSQL

Utangulizi

"Lazima ukimbie haraka uwezavyo ili tu kukaa mahali,
na ili kufika mahali fulani, unapaswa kukimbia angalau mara mbili zaidi!”
(c) Alice huko Wonderland

Wakati fulani uliopita niliombwa nitoe mhadhara wachambuzi kampuni yetu juu ya mada ya kubuni mifano ya data, kwa sababu kukaa kwenye miradi kwa muda mrefu (wakati mwingine kwa miaka kadhaa) tunapoteza kuona kile kinachotokea karibu nasi katika ulimwengu wa teknolojia za IT. Katika kampuni yetu (hivyo hufanyika) miradi mingi haitumii hifadhidata za NoSQL (angalau kwa sasa), kwa hivyo katika hotuba yangu nilizingatia kando kwa kutumia mfano wa HBase na kujaribu kuelekeza uwasilishaji wa nyenzo kwa wale. ambao hawajawahi kuzitumia wamefanya kazi. Hasa, nilionyesha baadhi ya vipengele vya muundo wa kielelezo cha data kwa kutumia mfano niliosoma miaka kadhaa iliyopita katika makala "Utangulizi wa HB ase Schema Design" na Amandeep Khurana. Wakati wa kuchambua mifano, nililinganisha chaguzi kadhaa za kusuluhisha shida ile ile ili kufikisha mawazo makuu kwa wasikilizaji vyema.

Hivi majuzi, "bila chochote cha kufanya," nilijiuliza swali (wikendi ndefu ya Mei katika karantini inafaa sana kwa hii), mahesabu ya kinadharia yatalingana na mazoezi kiasi gani? Kwa kweli, hivi ndivyo wazo la kifungu hiki lilivyozaliwa. Msanidi programu ambaye amekuwa akifanya kazi na NoSQL kwa siku kadhaa anaweza asijifunze chochote kipya kutoka kwayo (na kwa hivyo anaweza kuruka nusu ya kifungu mara moja). Lakini kwa wachambuziKwa wale ambao bado hawajafanya kazi kwa karibu na NoSQL, nadhani itakuwa muhimu kwa kupata ufahamu wa kimsingi wa vipengele vya kubuni mifano ya data kwa HBase.

Uchambuzi wa mfano

Kwa maoni yangu, kabla ya kuanza kutumia hifadhidata za NoSQL, unahitaji kufikiria kwa uangalifu na kupima faida na hasara. Mara nyingi tatizo linaweza kutatuliwa kwa kutumia DBMS za kimahusiano za kitamaduni. Kwa hivyo, ni bora kutotumia NoSQL bila sababu muhimu. Ikiwa hata hivyo uliamua kutumia hifadhidata ya NoSQL, basi unapaswa kuzingatia kwamba mbinu za kubuni hapa ni tofauti. Hasa baadhi yao inaweza kuwa ya kawaida kwa wale ambao hapo awali walishughulikia tu DBMS za uhusiano (kulingana na uchunguzi wangu). Kwa hivyo, katika ulimwengu wa "uhusiano", kwa kawaida tunaanza kwa kuiga kikoa cha tatizo, na kisha tu, ikiwa ni lazima, fanya mfano huo kuwa wa kawaida. Katika NoSQL sisi inapaswa kuzingatia mara moja hali zinazotarajiwa za kufanya kazi na data na hapo awali kudhoofisha data. Kwa kuongeza, kuna idadi ya tofauti nyingine, ambayo itajadiliwa hapa chini.

Wacha tuchunguze shida ifuatayo ya "synthetic", ambayo tutaendelea kufanya kazi nayo:

Inahitajika kuunda muundo wa uhifadhi wa orodha ya marafiki wa watumiaji wa mtandao fulani wa kijamii. Ili kurahisisha, tutafikiria kuwa miunganisho yetu yote imeelekezwa (kama kwenye Instagram, sio Linkedin). Muundo unapaswa kukuwezesha kwa ufanisi:

• Jibu swali kama mtumiaji A anasoma mtumiaji B (muundo wa kusoma)
• Ruhusu kuongeza/kuondoa miunganisho iwapo kuna usajili/kujiondoa kwa mtumiaji A kutoka kwa mtumiaji B (kiolezo cha kubadilisha data)

Bila shaka, kuna chaguzi nyingi za kutatua tatizo. Katika hifadhidata ya kawaida ya uhusiano, tuna uwezekano mkubwa wa kutengeneza jedwali la uhusiano (ikiwezekana kuonyeshwa ikiwa, kwa mfano, tunahitaji kuhifadhi kikundi cha watumiaji: familia, kazi, n.k., ambayo inajumuisha "rafiki" huyu), na kuboresha. kasi ya ufikiaji ingeongeza faharisi/kugawa. Uwezekano mkubwa zaidi, jedwali la mwisho lingeonekana kama hii:

mtumiaji_id
kitambulisho_cha_rafiki

Vasya
Peter

Vasya
Оля

baada ya hapo, kwa uwazi na uelewa mzuri zaidi, nitaonyesha majina badala ya vitambulisho

Kwa upande wa HBase, tunajua kwamba:

• Utafutaji bora ambao hauleti tambazo kamili ya jedwali inawezekana pekee kwa ufunguo
  • kwa kweli, ndiyo sababu kuandika maswali ya SQL yanayojulikana kwa wengi kwa hifadhidata kama hizo ni wazo mbaya; kiufundi, bila shaka, unaweza kutuma swali la SQL na Joins na mantiki nyingine kwa HBase kutoka Impala sawa, lakini itakuwa na ufanisi gani...

Kwa hivyo, tunalazimika kutumia kitambulisho cha mtumiaji kama ufunguo. Na wazo langu la kwanza juu ya mada "wapi na jinsi ya kuhifadhi vitambulisho vya marafiki?" labda wazo la kuzihifadhi kwenye safu. Chaguo hili la wazi zaidi na la "kutojua" litaonekana kama hii (wacha tuiite Chaguo 1 (chaguo-msingi)kwa kumbukumbu zaidi):

RowKey
Spika

Vasya
1: Petya
2: Olya
3: Dasha

Peter
1: Masha
2: Vasya

Hapa, kila mstari unalingana na mtumiaji mmoja wa mtandao. Safu zina majina: 1, 2, ... - kulingana na idadi ya marafiki, na vitambulisho vya marafiki vinahifadhiwa kwenye safu. Ni muhimu kutambua kwamba kila safu itakuwa na idadi tofauti ya safu. Katika mfano kwenye takwimu hapo juu, safu moja ina safu tatu (1, 2 na 3), na ya pili ina mbili tu (1 na 2) - hapa sisi wenyewe tulitumia mali mbili za HBase ambazo hifadhidata za uhusiano hazina:

• uwezo wa kubadilisha muundo wa safu wima (ongeza rafiki -> ongeza safu, ondoa rafiki -> futa safu)
• safu mlalo tofauti zinaweza kuwa na utunzi wa safu wima tofauti

Wacha tuangalie muundo wetu kwa kufuata mahitaji ya kazi:

• Kusoma data: ili kuelewa ikiwa Vasya amejiandikisha kwa Olya, tutahitaji kutoa mstari mzima kwa ufunguo RowKey = "Vasya" na upange kupitia maadili ya safu hadi "tutakutana" na Olya ndani yao. Au rudia kupitia maadili ya safuwima zote, "usifikie" Olya na urudishe jibu Uongo;
• Kuhariri data: kuongeza rafiki: kwa kazi sawa tunahitaji pia kutoa mstari mzima kwa kutumia ufunguo RowKey = "Vasya" kuhesabu jumla ya idadi ya marafiki zake. Tunahitaji jumla ya idadi hii ya marafiki ili kubaini nambari ya safu ambayo tunahitaji kuandika kitambulisho cha rafiki mpya.
• Kubadilisha data: kufuta rafiki:
  • Haja ya kutoa mstari mzima kwa ufunguo RowKey = "Vasya" na upange kupitia nguzo ili kupata moja ambayo rafiki kufutwa imeandikwa;
  • Ifuatayo, baada ya kufuta rafiki, tunahitaji "kubadilisha" data zote kwenye safu moja ili tusipate "mapengo" katika hesabu zao.

Wacha sasa tutathmini jinsi algorithms hizi, ambazo tutahitaji kutekeleza kwa upande wa "matumizi ya masharti", zitakuwa, kwa kutumia O-ishara. Wacha tuonyeshe saizi ya mtandao wetu wa kijamii wa dhahania kama n. Kisha idadi ya juu ya marafiki ambayo mtumiaji anaweza kuwa nayo ni (n-1). Tunaweza kupuuza zaidi hii (-1) kwa madhumuni yetu, kwani ndani ya mfumo wa matumizi ya alama za O sio muhimu.

• Kusoma data: ni muhimu kutoa mstari mzima na kurudia kupitia safu zake zote kwenye kikomo. Hii inamaanisha kuwa makadirio ya juu ya gharama yatakuwa takriban O(n)
• Kuhariri data: kuongeza rafiki: ili kuamua idadi ya marafiki, unahitaji kurudia kupitia safuwima zote za safu, na kisha ingiza safu mpya => O(n)
• Kubadilisha data: kufuta rafiki:
  • Sawa na kuongeza - unahitaji kupitia safu wima zote kwenye kikomo => O(n)
  • Baada ya kuondoa nguzo, tunahitaji "kusonga" kwao. Ikiwa utatekeleza "kichwa-juu", basi katika kikomo utahitaji hadi (n-1) shughuli. Lakini hapa na zaidi katika sehemu ya vitendo tutatumia njia tofauti, ambayo itatumia "pseudo-shift" kwa idadi fulani ya shughuli - ambayo ni, wakati wa mara kwa mara utatumika juu yake, bila kujali n. Wakati huu wa mara kwa mara (O(2) kuwa sawa) unaweza kupuuzwa ikilinganishwa na O(n). Mbinu imeonyeshwa kwenye mchoro hapa chini: tunakili data kutoka safu ya "mwisho" hadi ile ambayo tunataka kufuta data, na kisha kufuta safu ya mwisho:
    

Kwa jumla, katika hali zote tulipokea uchangamano usio na dalili wa O(n).
Labda tayari umegundua kuwa karibu kila wakati tunapaswa kusoma safu nzima kutoka kwa hifadhidata, na katika hali mbili kati ya tatu, kupitia safu zote na kuhesabu jumla ya idadi ya marafiki. Kwa hivyo, kama jaribio la uboreshaji, unaweza kuongeza safu wima ya "hesabu", ambayo huhifadhi jumla ya idadi ya marafiki wa kila mtumiaji wa mtandao. Katika kesi hii, hatuwezi kusoma safu nzima ili kuhesabu jumla ya idadi ya marafiki, lakini soma safu moja tu ya "hesabu". Jambo kuu sio kusahau kusasisha "hesabu" wakati wa kudhibiti data. Hiyo. tunaboreshwa Chaguo 2 (hesabu):

RowKey
Spika

Vasya
1: Petya
2: Olya
3: Dasha
hesabu: 3

Peter
1: Masha
2: Vasya

hesabu: 2

Ikilinganishwa na chaguo la kwanza:

• Kusoma data: kupata jibu la swali "Je, Vasya anasoma Olya?" hakuna kilichobadilika => O(n)
• Kuhariri data: kuongeza rafiki: Tumerahisisha uingizaji wa rafiki mpya, kwa kuwa sasa hatuhitaji kusoma mstari mzima na kurudia juu ya safu zake, lakini tunaweza tu kupata thamani ya safu ya "hesabu", nk. mara moja amua nambari ya safu ili kuingiza rafiki mpya. Hii inasababisha kupungua kwa ugumu wa kimahesabu hadi O(1)
• Kubadilisha data: kufuta rafiki: Tunapofuta rafiki, tunaweza pia kutumia safu wima hii kupunguza idadi ya shughuli za I/O tunapo "hamisha" data kisanduku kimoja kwenda kushoto. Lakini hitaji la kurudia kupitia safuwima kupata ile inayohitaji kufutwa bado inabaki, kwa hivyo => O(n)
• Kwa upande mwingine, sasa tunaposasisha data tunahitaji kusasisha safu wima ya "hesabu" kila wakati, lakini hii inachukua muda mara kwa mara, ambayo inaweza kupuuzwa ndani ya mfumo wa alama za O.

Kwa ujumla, chaguo la 2 linaonekana kuwa bora zaidi, lakini ni kama "mageuzi badala ya mapinduzi." Ili kufanya "mapinduzi" tutahitaji Chaguo la 3 (sawa).
Hebu tugeuze kila kitu "kichwa chini": tutawapa jina la safu kitambulisho cha mtumiaji! Nini kitaandikwa kwenye safu yenyewe sio muhimu tena kwetu, basi iwe nambari 1 (kwa ujumla, vitu muhimu vinaweza kuhifadhiwa huko, kwa mfano, kikundi "familia / marafiki / nk."). Mbinu hii inaweza kumshangaza "mtu asiyejitayarisha" ambaye hana uzoefu wa awali wa kufanya kazi na hifadhidata za NoSQL, lakini ni njia hii ambayo hukuruhusu kutumia uwezo wa HBase katika kazi hii kwa ufanisi zaidi:

RowKey
Spika

Vasya
Petya: 1
Olya: 1
Dasha: 1

Peter
Masha: 1
Vasya: 1

Hapa tunapata faida kadhaa mara moja. Ili kuzielewa, hebu tuchambue muundo mpya na tukadirie ugumu wa hesabu:

• Kusoma data: ili kujibu swali ikiwa Vasya amejiandikisha kwa Olya, inatosha kusoma safu moja "Olya": ikiwa iko, basi jibu ni Kweli, ikiwa sio - Uongo => O (1)
• Kuhariri data: kuongeza rafiki: Kuongeza rafiki: ongeza safu mpya tu "Kitambulisho cha Rafiki" => O(1)
• Kubadilisha data: kufuta rafiki: ondoa tu safu ya Kitambulisho cha Rafiki => O(1)

Kama unaweza kuona, faida kubwa ya mfano huu wa hifadhi ni kwamba katika hali zote tunazohitaji, tunafanya kazi na safu moja tu, kuepuka kusoma safu nzima kutoka kwa hifadhidata na, zaidi ya hayo, kuorodhesha safu zote za safu hii. Tunaweza kuacha hapo, lakini ...

Unaweza kushangazwa na kwenda mbele kidogo kwenye njia ya kuboresha utendaji na kupunguza shughuli za I/O wakati wa kupata hifadhidata. Je, ikiwa tutahifadhi taarifa kamili ya uhusiano moja kwa moja kwenye ufunguo wa safu mlalo wenyewe? Hiyo ni, fanya ufunguo wa mchanganyiko kama userID.friendID? Katika kesi hii, sio lazima hata tusome safu wima za mstari kabisa (Chaguo 4(safu)):

RowKey
Spika

Vasya.Petya
Petya: 1

Vasya.Olya
Olya: 1

Vasya.Dasha
Dasha: 1

Petya.Masha
Masha: 1

Petya.Vasya
Vasya: 1

Ni wazi, tathmini ya hali zote za upotoshaji wa data katika muundo kama huo, kama katika toleo la awali, itakuwa O(1). Tofauti na chaguo 3 itakuwa tu katika ufanisi wa shughuli za I/O kwenye hifadhidata.

Naam, "upinde" wa mwisho. Ni rahisi kuona kuwa katika chaguo la 4, ufunguo wa safu mlalo utakuwa na urefu tofauti, ambao unaweza kuathiri utendaji (hapa tunakumbuka kuwa HBase huhifadhi data kama seti ya baiti na safu mlalo kwenye jedwali zikipangwa kwa ufunguo). Pia tuna kitenganishi ambacho kinaweza kuhitaji kushughulikiwa katika baadhi ya matukio. Ili kuondoa ushawishi huu, unaweza kutumia heshi kutoka kwa kitambulisho cha mtumiaji na ID ya marafiki, na kwa kuwa heshi zote mbili zitakuwa na urefu wa kudumu, unaweza kuziunganisha tu, bila kitenganishi. Kisha data kwenye jedwali itaonekana kama hii (Chaguo la 5 (heshi)):

RowKey
Spika

dc084ef00e94aef49be885f9b01f51c01918fa783851db0dc1f72f83d33a5994
Petya: 1

dc084ef00e94aef49be885f9b01f51c0f06b7714b5ba522c3cf51328b66fe28a
Olya: 1

dc084ef00e94aef49be885f9b01f51c00d2c2e5d69df6b238754f650d56c896a
Dasha: 1

1918fa783851db0dc1f72f83d33a59949ee3309645bd2c0775899fca14f311e1
Masha: 1

1918fa783851db0dc1f72f83d33a5994dc084ef00e94aef49be885f9b01f51c0
Vasya: 1

Kwa wazi, utata wa algorithmic wa kufanya kazi na muundo huo katika matukio tunayozingatia itakuwa sawa na ile ya chaguo 4 - yaani, O (1).
Kwa jumla, hebu tufanye muhtasari wa makadirio yetu yote ya ugumu wa hesabu katika jedwali moja:

Kuongeza rafiki
Kuangalia rafiki
Kuondoa rafiki

Chaguo 1 (chaguo-msingi)
O (n)
O (n)
O (n)

Chaguo 2 (hesabu)
O (1)
O (n)
O (n)

Chaguo 3 (safu wima)
O (1)
O (1)
O (1)

Chaguo la 4 (safu)
O (1)
O (1)
O (1)

Chaguo la 5 (heshi)
O (1)
O (1)
O (1)

Kama unavyoona, chaguzi 3-5 zinaonekana kuwa bora zaidi na zinahakikisha utekelezwaji wa hali zote muhimu za upotoshaji wa data kwa wakati thabiti. Katika hali ya kazi yetu, hakuna hitaji la wazi la kupata orodha ya marafiki wote wa mtumiaji, lakini katika shughuli za mradi halisi, itakuwa vizuri kwetu, kama wachambuzi wazuri, "kutarajia" kwamba kazi kama hiyo inaweza kutokea na. "kueneza majani." Kwa hiyo, huruma zangu ziko upande wa chaguo 3. Lakini kuna uwezekano kabisa kwamba katika mradi halisi ombi hili linaweza tayari kutatuliwa kwa njia nyingine, kwa hiyo, bila maono ya jumla ya tatizo zima, ni bora si kufanya. hitimisho la mwisho.

Maandalizi ya jaribio

Ningependa kujaribu hoja za kinadharia hapo juu kwa vitendo - hili lilikuwa lengo la wazo lililoibuka mwishoni mwa wiki. Ili kufanya hivyo, ni muhimu kutathmini kasi ya uendeshaji wa "matumizi ya masharti" yetu katika hali zote zilizoelezwa za kutumia hifadhidata, pamoja na kuongezeka kwa wakati huu na kuongezeka kwa ukubwa wa mtandao wa kijamii (n). Kigezo lengwa ambacho kinatuvutia na ambacho tutapima wakati wa jaribio ni wakati unaotumiwa na "matumizi ya masharti" kufanya "operesheni moja ya biashara". Kwa "muamala wa biashara" tunamaanisha mojawapo ya yafuatayo:

• Kuongeza rafiki mmoja mpya
• Kuangalia ikiwa Mtumiaji A ni rafiki wa Mtumiaji B
• Kuondoa rafiki mmoja

Kwa hivyo, kwa kuzingatia mahitaji yaliyoainishwa katika taarifa ya awali, hali ya uthibitishaji inajitokeza kama ifuatavyo:

• Kurekodi data. Nasibu toa mtandao wa awali wa saizi n. Ili kupata karibu na "ulimwengu halisi", idadi ya marafiki ambao kila mtumiaji anayo pia ni tofauti ya nasibu. Pima muda ambao "matumizi yetu ya masharti" huandika data yote inayozalishwa kwa HBase. Kisha ugawanye wakati unaotokana na jumla ya idadi ya marafiki walioongezwa - hivi ndivyo tunapata wakati wa wastani wa "operesheni moja ya biashara"
• Kusoma data. Kwa kila mtumiaji, tengeneza orodha ya "binafsi" ambayo unahitaji kupata jibu ikiwa mtumiaji amejisajili kwao au la. Urefu wa orodha = takriban idadi ya marafiki wa mtumiaji, na kwa nusu ya marafiki walioangaliwa jibu linapaswa kuwa "Ndiyo", na kwa nusu nyingine - "Hapana". Cheki hufanywa kwa mpangilio kwamba majibu "Ndio" na "Hapana" yanabadilishana (ambayo ni, katika kila kisa cha pili tutalazimika kupitia safu wima zote za safu kwa chaguzi 1 na 2). Jumla ya muda wa uchunguzi hugawanywa na idadi ya marafiki waliojaribiwa ili kupata wastani wa muda wa uchunguzi kwa kila somo.
• Inafuta data. Ondoa marafiki wote kutoka kwa mtumiaji. Zaidi ya hayo, agizo la kufuta ni la nasibu (yaani, "tunachanganya" orodha asili inayotumika kurekodi data). Jumla ya muda wa kuangalia hugawanywa na idadi ya marafiki walioondolewa ili kupata muda wa wastani kwa kila hundi.

Mazingira yanahitaji kuendeshwa kwa kila moja ya chaguo 5 za muundo wa data na kwa saizi tofauti za mtandao wa kijamii ili kuona jinsi wakati unavyobadilika. Ndani ya n moja, miunganisho kwenye mtandao na orodha ya watumiaji wa kuangalia lazima, bila shaka, iwe sawa kwa chaguo zote 5.
Kwa ufahamu bora zaidi, hapa chini ni mfano wa data inayozalishwa ya n= 5. "Jenereta" iliyoandikwa hutoa kamusi tatu za kitambulisho kama pato:

• ya kwanza ni ya kuingiza
• pili ni kwa ajili ya kuangalia
• tatu - kwa kufuta

{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 друзей

Kama unavyoona, vitambulisho vyote vilivyo zaidi ya 10 kwenye kamusi ya kukaguliwa ni vile ambavyo hakika vitatoa jibu la Uongo. Kuingiza, kuangalia na kufuta "marafiki" hufanywa haswa katika mlolongo uliobainishwa katika kamusi.

Jaribio lilifanywa kwenye kompyuta ndogo inayoendesha Windows 10, ambapo HBase ilikuwa ikifanya kazi kwenye kontena moja la Docker, na Python iliyo na Jupyter Notebook ilikuwa ikifanya kazi katika nyingine. Docker ilitengewa cores 2 za CPU na GB 2 za RAM. Mantiki yote, kama vile uigaji wa "programu ya masharti" na "kusambaza" kwa ajili ya kuzalisha data ya majaribio na muda wa kupima, iliandikwa kwa Python. Maktaba ilitumika kufanya kazi na HBase furahabase, kuhesabu heshi (MD5) kwa chaguo 5 - hahlib

Kwa kuzingatia uwezo wa kompyuta wa kompyuta ya mkononi mahususi, uzinduzi wa n = 10, 30, … ulichaguliwa kwa majaribio. 170 - wakati jumla ya muda wa uendeshaji wa mzunguko kamili wa kupima (matukio yote kwa chaguo zote kwa wote n) ulikuwa wa busara zaidi au chini na unafaa wakati wa sherehe moja ya chai (kwa wastani wa dakika 15).

Hapa ni muhimu kutoa maoni kwamba katika jaribio hili kimsingi hatutathmini takwimu kamili za utendakazi. Hata kulinganisha kwa jamaa kwa chaguzi mbili tofauti kunaweza kuwa sio sahihi kabisa. Sasa tunavutiwa na hali ya mabadiliko ya wakati kulingana na n, kwa kuwa kwa kuzingatia usanidi wa hapo juu wa "msimamo wa majaribio", ni ngumu sana kupata makadirio ya wakati "iliyofutwa" ya ushawishi wa mambo ya nasibu na mengine. na kazi kama hiyo haikuwekwa).

Matokeo ya majaribio

Jaribio la kwanza ni jinsi muda uliotumika kujaza orodha ya marafiki unavyobadilika. Matokeo yake ni katika grafu hapa chini.

Chaguzi 3-5, kama inavyotarajiwa, zinaonyesha karibu kila wakati "muamala wa biashara", ambayo haitegemei ukuaji wa saizi ya mtandao na tofauti isiyoweza kutambulika katika utendaji.
Chaguo la 2 pia linaonyesha utendaji wa mara kwa mara, lakini mbaya zaidi, karibu mara 2 kuhusiana na chaguo 3-5. Na hii haiwezi lakini kufurahi, kwa kuwa inahusiana na nadharia - katika toleo hili idadi ya shughuli za I/O kwenda/kutoka HBase ni kubwa zaidi mara 2. Hii inaweza kutumika kama ushahidi usio wa moja kwa moja kwamba benchi yetu ya majaribio, kimsingi, hutoa usahihi mzuri.
Chaguo la 1 pia, kama inavyotarajiwa, linageuka kuwa la polepole zaidi na linaonyesha ongezeko la mstari katika muda unaotumika katika kuongeza ukubwa wa mtandao.
Hebu sasa tuangalie matokeo ya mtihani wa pili.

Chaguzi 3-5 zinafanya tena kama inavyotarajiwa - wakati wa mara kwa mara, bila kujali saizi ya mtandao. Chaguo 1 na 2 zinaonyesha ongezeko la muda kadiri ukubwa wa mtandao unavyoongezeka na utendakazi sawa. Kwa kuongezea, chaguo la 2 linageuka kuwa polepole - dhahiri kwa sababu ya hitaji la kusahihisha na kusindika safu ya "hesabu" ya ziada, ambayo inaonekana zaidi n inakua. Lakini bado nitaepuka kufanya hitimisho lolote, kwa kuwa usahihi wa kulinganisha huu ni duni. Kwa kuongeza, uwiano huu (ni chaguo gani, 1 au 2, ni kasi) iliyopita kutoka kukimbia hadi kukimbia (wakati wa kudumisha asili ya utegemezi na "kwenda shingo na shingo").

Kweli, grafu ya mwisho ni matokeo ya upimaji wa kuondolewa.

Tena, hakuna mshangao hapa. Chaguzi 3-5 hufanya kuondolewa kwa wakati usiobadilika.
Zaidi ya hayo, cha kufurahisha, chaguo 4 na 5, tofauti na hali zilizopita, zinaonyesha utendaji mbaya zaidi kuliko chaguo la 3. Inavyoonekana, operesheni ya kufuta safu ni ghali zaidi kuliko operesheni ya kufuta safu, ambayo kwa ujumla ni ya mantiki.

Chaguo 1 na 2, kama inavyotarajiwa, zinaonyesha ongezeko la mstari wa wakati. Wakati huo huo, chaguo la 2 ni polepole zaidi kuliko chaguo la 1 - kwa sababu ya operesheni ya ziada ya I/O ya "kudumisha" safu ya hesabu.

Hitimisho la jumla la jaribio:

• Chaguzi 3-5 zinaonyesha ufanisi zaidi wanapotumia HBase; Kwa kuongeza, utendaji wao hutofautiana kwa kila mmoja kwa mara kwa mara na hautegemei ukubwa wa mtandao.
• Tofauti kati ya chaguo 4 na 5 haikurekodiwa. Lakini hii haina maana kwamba chaguo 5 haipaswi kutumiwa. Inawezekana kwamba hali ya majaribio iliyotumiwa, kwa kuzingatia sifa za utendaji wa benchi ya mtihani, haikuruhusu kugunduliwa.
• Hali ya ongezeko la muda unaohitajika kufanya "shughuli za biashara" na data kwa ujumla ilithibitisha mahesabu ya kinadharia yaliyopatikana hapo awali kwa chaguo zote.

Epilogue

Majaribio makali yaliyofanywa hayapaswi kuchukuliwa kuwa ukweli mtupu. Kuna mambo mengi ambayo hayakuzingatiwa na kupotosha matokeo (mabadiliko haya yanaonekana hasa kwenye grafu na ukubwa mdogo wa mtandao). Kwa mfano, kasi ya thrift, ambayo hutumiwa na happybase, kiasi na njia ya kutekeleza mantiki ambayo niliandika katika Python (siwezi kudai kwamba kanuni iliandikwa kikamilifu na kwa ufanisi kutumika uwezo wa vipengele vyote), labda. vipengele vya caching ya HBase, shughuli za chinichini za Windows 10 kwenye kompyuta yangu ndogo, nk. Kwa ujumla, tunaweza kudhani kuwa mahesabu yote ya kinadharia yameonyesha uhalali wao kwa majaribio. Kweli, au angalau haikuwezekana kuwakanusha na "shambulio la kichwa" kama hicho.

Kwa kumalizia, mapendekezo kwa kila mtu anayeanza kuunda miundo ya data katika HBase: muhtasari wa uzoefu wa awali wa kufanya kazi na hifadhidata za uhusiano na kumbuka "amri":

• Wakati wa kubuni, tunaendelea kutoka kwa kazi na mifumo ya upotoshaji wa data, na sio kutoka kwa mfano wa kikoa
• Ufikiaji wa ufanisi (bila uchunguzi kamili wa jedwali) - tu kwa ufunguo
• Kupunguza hali ya kawaida
• Safu mlalo tofauti zinaweza kuwa na safu wima tofauti
• Muundo wa nguvu wa wasemaji

Chanzo: mapenzi.com