Inngangur
„Þú verður að hlaupa eins hratt og þú getur bara til að vera á sínum stað,
og til að komast eitthvað þarftu að hlaupa að minnsta kosti tvöfalt hraðar!“
(c) Lísa í Undralandi
Fyrir nokkru var ég beðinn um að halda fyrirlestur sérfræðingar fyrirtæki okkar um að hanna gagnalíkön, vegna þess að við sitjum á verkefnum í langan tíma (stundum í nokkur ár) missum við sjónar á því sem er að gerast í kringum okkur í heimi upplýsingatæknitækninnar. Í fyrirtækinu okkar (það gerist bara) nota mörg verkefni ekki NoSQL gagnagrunna (að minnsta kosti í bili), svo í fyrirlestri mínum veitti ég þeim sérstaka athygli með því að nota dæmið HBase og reyndi að beina framsetningu efnisins að þeim. sem hafa aldrei notað þá hafa unnið. Sérstaklega sýndi ég nokkra eiginleika gagnalíkanahönnunar með því að nota dæmi sem ég las fyrir nokkrum árum . Við greiningu dæma bar ég saman nokkra möguleika til að leysa sama vandamálið til að koma helstu hugmyndum betur á framfæri við áhorfendur.
Nýlega, „af engu að gera,“ spurði ég sjálfan mig spurningarinnar (langa maíhelgin í sóttkví er sérstaklega til þess fallin að gera þetta), hversu mikið munu fræðilegir útreikningar samsvara framkvæmd? Í raun, þetta er hvernig hugmyndin að þessari grein fæddist. Hönnuður sem hefur unnið með NoSQL í nokkra daga getur ekki lært neitt nýtt af því (og getur því strax sleppt hálfri greininni). En fyrir sérfræðingarFyrir þá sem hafa ekki enn unnið náið með NoSQL held ég að það muni nýtast vel til að öðlast grunnskilning á eiginleikum hönnunar gagnalíkana fyrir HBase.
Dæmi greining
Að mínu mati, áður en þú byrjar að nota NoSQL gagnagrunna, þarftu að hugsa vel um og vega kosti og galla. Oft er líklegast hægt að leysa vandamálið með því að nota hefðbundnar DBMS-tengingar. Þess vegna er betra að nota ekki NoSQL án verulegra ástæðna. Ef þú ákvaðst samt að nota NoSQL gagnagrunn, þá ættir þú að taka með í reikninginn að hönnunaraðferðirnar hér eru nokkuð mismunandi. Sérstaklega sumir þeirra geta verið óvenjulegir fyrir þá sem áður hafa aðeins fengist við tengsla-DBMS (samkvæmt athugunum mínum). Svo, í „tengsla“ heiminum, byrjum við venjulega á því að móta vandamálasvæðið og aðeins þá, ef nauðsyn krefur, afeðla líkanið. Í NoSQL við ætti strax að taka tillit til væntanlegra atburðarása við að vinna með gögn og upphaflega afnormalisera gögnin. Að auki er fjöldi annarra muna, sem fjallað verður um hér að neðan.
Við skulum íhuga eftirfarandi „tilbúið“ vandamál, sem við munum halda áfram að vinna með:
Nauðsynlegt er að hanna geymslukerfi fyrir lista yfir vini notenda á einhverju óhlutbundnu samfélagsneti. Til að einfalda, gerum við ráð fyrir að öllum tengingum okkar sé beint (eins og á Instagram, ekki Linkedin). Uppbyggingin ætti að gera þér kleift að:
- Svaraðu spurningunni hvort notandi A lesi notanda B (lestrarmynstur)
- Leyfa að bæta við/fjarlægja tengingar ef um er að ræða áskrift/uppsögn notanda A frá notanda B (sniðmát gagnabreytinga)
Auðvitað eru margir möguleikar til að leysa vandamálið. Í venjulegum tengslagagnagrunni myndum við líklegast einfaldlega búa til töflu yfir tengsl (hugsanlega dæmigerð ef við þurfum til dæmis að geyma notendahóp: fjölskyldu, vinnu o.s.frv., sem inniheldur þennan „vin“), og til að hagræða aðgangshraðinn myndi bæta við vísitölum/skiptingu. Líklegast myndi lokaborðið líta einhvern veginn svona út:
USER_ID
friend_id
Vasya
Petya
Vasya
Оля
Hér á eftir mun ég, til glöggvunar og betri skilnings, tilgreina nöfn í stað skilríkja
Þegar um HBase er að ræða vitum við að:
- skilvirk leit sem leiðir ekki til fullrar töfluskönnunar er möguleg eingöngu með lyklum
- í raun er það slæm hugmynd að skrifa SQL fyrirspurnir sem margir þekkja í slíka gagnagrunna; tæknilega séð er auðvitað hægt að senda SQL fyrirspurn með Joins og annarri rökfræði til HBase frá sömu Impala, en hversu áhrifarík verður hún...
Þess vegna neyðumst við til að nota notandakennið sem lykil. Og fyrsta hugsun mín um efnið "hvar og hvernig á að geyma skilríki vina?" kannski hugmynd að geyma þær í dálkum. Þessi augljósasti og „barnalegasti“ valkostur mun líta eitthvað svona út (köllum það Valkostur 1 (sjálfgefið)til frekari tilvísunar):
RowKey
Hátalarar
Vasya
1: Petya
2: Olía
3: Dasha
Petya
1: Masha
2: Vasya
Hér samsvarar hver lína einum netnotanda. Dálkarnir bera nöfn: 1, 2, ... - eftir fjölda vina, og auðkenni vina eru geymd í dálkunum. Það er mikilvægt að hafa í huga að hver röð mun hafa mismunandi fjölda dálka. Í dæminu á myndinni hér að ofan hefur ein röð þrjá dálka (1, 2 og 3) og önnur hefur aðeins tvo (1 og 2) - hér notuðum við sjálf tvo HBase eiginleika sem venslagagnagrunnar hafa ekki:
- hæfileikinn til að breyta samsetningu dálka á virkan hátt (bæta við vini -> bæta við dálki, fjarlægja vin -> eyða dálki)
- mismunandi línur geta haft mismunandi dálkasamsetningu
Við skulum athuga uppbyggingu okkar til að uppfylla kröfur verkefnisins:
- Að lesa gögn: til að skilja hvort Vasya er áskrifandi að Olya, verðum við að draga frá alla línuna með lyklinum RowKey = „Vasya“ og flokkaðu dálkgildin þar til við „hittum“ Olya í þeim. Eða endurtaktu gildi allra dálka, „hittu ekki“ Olya og skilaðu svarinu Rangt;
- Breyta gögnum: bæta við vini: fyrir svipað verkefni þurfum við líka að draga frá alla línuna með því að nota takkann RowKey = “Vasya” til að telja heildarfjölda vina sinna. Við þurfum þennan heildarfjölda vina til að ákvarða númer dálksins þar sem við þurfum að skrifa niður auðkenni nýja vinarins.
- Að breyta gögnum: eyða vini:
- Þarf að draga frá alla línuna með lyklinum RowKey = “Vasya” og flokkaðu dálkana til að finna þann sem vinurinn sem á að eyða er skráður í;
- Næst, eftir að hafa eytt vini, þurfum við að „skipta“ öllum gögnum í einn dálk til að fá ekki „eyður“ í númerun þeirra.
Við skulum nú meta hversu afkastamikil þessi reiknirit, sem við þurfum að innleiða á „skilyrt umsókn“ hliðinni, verða með því að nota . Við skulum tákna stærð ímyndaðs félagslegs nets okkar sem n. Þá er hámarksfjöldi vina sem einn notandi getur átt (n-1). Við getum enn vanrækt þetta (-1) í okkar tilgangi, þar sem innan ramma notkunar O-tákna skiptir það engu máli.
- Að lesa gögn: það er nauðsynlegt að draga alla línuna frá og endurtaka í gegnum alla dálka hennar í mörkunum. Þetta þýðir að efri áætlun um kostnað verður um það bil O(n)
- Breyta gögnum: bæta við vini: til að ákvarða fjölda vina þarftu að fara í gegnum alla dálka línunnar og setja svo inn nýjan dálk => O(n)
- Að breyta gögnum: eyða vini:
- Svipað og að bæta við - þú þarft að fara í gegnum alla dálka í mörkunum => O(n)
- Eftir að hafa fjarlægt dálkana þurfum við að „færa“ þá. Ef þú innleiðir þetta „head-on“, þá þarftu allt að (n-1) aðgerðir í mörkunum. En hér og lengra í verklega hlutanum munum við nota aðra nálgun, sem mun innleiða „gervi-vakt“ fyrir fastan fjölda aðgerða - það er stöðugur tími verður varið í það, óháð n. Það er hægt að vanrækja þennan fasta tíma (O(2) til að vera nákvæmur miðað við O(n). Aðferðin er sýnd á myndinni hér að neðan: við afritum einfaldlega gögnin úr „síðasta“ dálknum yfir í þann sem við viljum eyða gögnum úr og eyðum síðan síðasta dálknum:
Alls í öllum tilfellum fengum við einkennalausa reikniflókið O(n).
Þú hefur sennilega þegar tekið eftir því að við þurfum nánast alltaf að lesa alla röðina úr gagnagrunninum og í tveimur tilfellum af þremur, bara til að fara í gegnum alla dálka og reikna út heildarfjölda vina. Þess vegna, sem tilraun til hagræðingar, geturðu bætt við „telja“ dálki sem geymir heildarfjölda vina hvers netnotanda. Í þessu tilviki getum við ekki lesið alla röðina til að reikna út heildarfjölda vina, heldur lesið aðeins einn „telja“ dálk. Aðalatriðið er ekki að gleyma að uppfæra „telja“ þegar unnið er með gögn. Það. við bætum okkur Valkostur 2 (telja):
RowKey
Hátalarar
Vasya
1: Petya
2: Olía
3: Dasha
telja: 3
Petya
1: Masha
2: Vasya
telja: 2
Í samanburði við fyrsta valmöguleikann:
- Að lesa gögn: til að fá svar við spurningunni "Les Vasya Olya?" ekkert hefur breyst => O(n)
- Breyta gögnum: bæta við vini: Við höfum einfaldað innsetningu nýs vinar, þar sem nú þurfum við ekki að lesa alla línuna og endurtaka yfir dálka hennar, heldur getum við aðeins fengið gildi „telja“ dálksins o.s.frv. ákvarða strax dálknúmerið til að setja inn nýjan vin. Þetta leiðir til minnkunar á flækjustigi útreikninga í O(1)
- Að breyta gögnum: eyða vini: Þegar vini er eytt getum við líka notað þennan dálk til að fækka inn/út aðgerðum þegar gögnunum er „fært“ um eina reit til vinstri. En þörfin á að fara í gegnum dálkana til að finna þann sem þarf að eyða er enn eftir, svo => O(n)
- Aftur á móti, nú þegar gögn eru uppfærð þurfum við að uppfæra „telja“ dálkinn í hvert skipti, en þetta tekur stöðugan tíma, sem hægt er að vanrækja innan ramma O-tákna
Almennt séð virðist valkostur 2 aðeins ákjósanlegri, en hann er meira eins og „þróun í stað byltingar“. Til að gera „byltingu“ þurfum við Valkostur 3 (col).
Snúum öllu „á hvolf“: við munum úthluta dálknafn notandakenni! Það sem verður skrifað í sjálfan dálkinn er ekki lengur mikilvægt fyrir okkur, látum það vera númer 1 (almennt séð er hægt að geyma gagnlega hluti þar, td hópinn „fjölskylda/vinir/o.s.frv.“). Þessi nálgun gæti komið óundirbúnum „leikmanni“ á óvart sem hefur enga fyrri reynslu af því að vinna með NoSQL gagnagrunna, en það er einmitt þessi nálgun sem gerir þér kleift að nýta möguleika HBase í þessu verkefni á mun skilvirkari hátt:
RowKey
Hátalarar
Vasya
Petya: 1
Óli: 1
Dasha: 1
Petya
Masha: 1
Vasya: 1
Hér fáum við nokkra kosti í einu. Til að skilja þá skulum við greina nýju skipulagið og meta flókið útreikninga:
- Að lesa gögn: til að svara spurningunni hvort Vasya sé áskrifandi að Olya, er nóg að lesa einn dálk „Olya“: ef hann er þar, þá er svarið satt, ef ekki – Ósatt => O(1)
- Breyta gögnum: bæta við vini: Að bæta við vini: bættu bara við nýjum dálki „Friend ID“ => O(1)
- Að breyta gögnum: eyða vini: fjarlægðu bara Friend ID dálkinn => O(1)
Eins og þú sérð er verulegur kostur við þetta geymslulíkan að í öllum þeim tilfellum sem við þurfum, þá vinnum við með aðeins einn dálk, forðumst að lesa alla línuna úr gagnagrunninum og að auki telja upp alla dálka þessarar línu. Við gætum stoppað þar, en...
Þú getur verið undrandi og farið aðeins lengra á leiðinni til að hámarka afköst og draga úr I/O aðgerðum þegar þú opnar gagnagrunninn. Hvað ef við geymdum allar upplýsingar um sambandið beint í línulyklinum sjálfum? Það er að segja, gera lykilinn samsettan eins og userID.friendID? Í þessu tilfelli þurfum við alls ekki að lesa dálka línunnar (Valkostur 4 (röð)):
RowKey
Hátalarar
Vasya.Petya
Petya: 1
Vasya.Olya
Óli: 1
Vasya.Dasha
Dasha: 1
Petya.Masha
Masha: 1
Petya.Vasya
Vasya: 1
Augljóslega verður mat á öllum gagnasnúningsatburðarásum í slíkri uppbyggingu, eins og í fyrri útgáfu, O(1). Munurinn á valkosti 3 mun eingöngu liggja í skilvirkni I/O aðgerða í gagnagrunninum.
Jæja, síðasta "boga". Það er auðvelt að sjá að í valmöguleika 4 mun línulykillinn hafa breytilega lengd, sem gæti hugsanlega haft áhrif á frammistöðu (hér munum við að HBase geymir gögn sem bætisett og raðir í töflum eru flokkaðar eftir lyklum). Auk þess höfum við skilju sem gæti þurft að meðhöndla í sumum tilfellum. Til að útrýma þessum áhrifum er hægt að nota kjötkássa úr userID og friendID, og þar sem báðir kjötkássarnir verða með stöðuga lengd geturðu einfaldlega sett þau saman, án skilju. Þá munu gögnin í töflunni líta svona út (Valkostur 5 (hash)):
RowKey
Hátalarar
dc084ef00e94aef49be885f9b01f51c01918fa783851db0dc1f72f83d33a5994
Petya: 1
dc084ef00e94aef49be885f9b01f51c0f06b7714b5ba522c3cf51328b66fe28a
Óli: 1
dc084ef00e94aef49be885f9b01f51c00d2c2e5d69df6b238754f650d56c896a
Dasha: 1
1918fa783851db0dc1f72f83d33a59949ee3309645bd2c0775899fca14f311e1
Masha: 1
1918fa783851db0dc1f72f83d33a5994dc084ef00e94aef49be885f9b01f51c0
Vasya: 1
Augljóslega mun reikniritflækjustigið við að vinna með slíka uppbyggingu í þeim atburðarásum sem við erum að íhuga vera það sama og valkostur 4 - það er O(1).
Í heildina skulum við draga saman öll áætlanir okkar um flókið útreikninga í einni töflu:
Bætir við vini
Er að athuga með vin
Að fjarlægja vin
Valkostur 1 (sjálfgefið)
O (n)
O (n)
O (n)
Valkostur 2 (telja)
O (1)
O (n)
O (n)
Valkostur 3 (dálkur)
O (1)
O (1)
O (1)
Valkostur 4 (röð)
O (1)
O (1)
O (1)
Valkostur 5 (hash)
O (1)
O (1)
O (1)
Eins og þú sérð virðast valmöguleikar 3-5 vera ákjósanlegastir og tryggja fræðilega framkvæmt allar nauðsynlegar gagnavinnsluatburðarásir á stöðugum tíma. Í skilyrðum verkefnisins okkar er engin skýr krafa um að fá lista yfir alla vini notandans, en í raunverulegri verkefnastarfsemi væri gott fyrir okkur, sem góða greiningaraðila, að „búa fyrir“ að slíkt verkefni gæti komið upp og "dreifa strái." Þess vegna er samúð mín hlið við valkost 3. En það er mjög líklegt að í alvöru verkefni hefði verið hægt að leysa þessa beiðni með öðrum hætti, þess vegna, án almennrar sýn á allan vandann, er betra að gera ekki lokaniðurstöður.
Undirbúningur tilraunarinnar
Mig langar að prófa ofangreind fræðileg rök í reynd - þetta var markmið hugmyndarinnar sem kom upp um langa helgi. Til að gera þetta er nauðsynlegt að meta rekstrarhraða „skilyrtrar umsóknar“ okkar í öllum lýstum atburðarásum fyrir notkun gagnagrunnsins, sem og aukninguna á þessum tíma með vaxandi stærð samfélagsnetsins (n). Markbreytan sem vekur áhuga okkar og sem við munum mæla meðan á tilrauninni stendur er tíminn sem „skilyrta forritið“ eyðir til að framkvæma eina „viðskiptaaðgerð“. Með „viðskiptafærslu“ er átt við eitt af eftirfarandi:
- Bætir einum nýjum vini við
- Athugar hvort notandi A sé vinur notanda B
- Fjarlægir einn vin
Þannig, að teknu tilliti til krafnanna sem lýst er í upphaflegu yfirlýsingunni, kemur sannprófunarsviðið fram sem hér segir:
- Upptaka gagna. Búðu til upphafsnet af handahófi af stærð n. Til að komast nær „raunveruleikanum“ er fjöldi vina sem hver notandi á einnig slembibreyta. Mældu tímann sem „skilyrta forritið“ okkar skrifar öll mynduð gögn til HBase. Deildu síðan tímanum sem myndast með heildarfjölda vina sem bætt var við - þannig fáum við meðaltíma fyrir eina „viðskiptaaðgerð“
- Að lesa gögn. Fyrir hvern notanda skaltu búa til lista yfir „persónuleika“ sem þú þarft að fá svar við hvort notandinn sé áskrifandi að þeim eða ekki. Lengd listans = um það bil fjöldi vina notandans, og fyrir helming vina sem merkt er við ætti svarið að vera „Já“ og fyrir hinn helminginn „Nei“. Athugunin er framkvæmd í þeirri röð að svörin „Já“ og „Nei“ skiptast á (það er, í öðru hverju tilviki verðum við að fara í gegnum alla dálka línunnar fyrir valkosti 1 og 2). Heildarskimunartímanum er síðan deilt með fjölda vina sem prófaðir voru til að fá meðalskimunartíma á einstakling.
- Eyðir gögnum. Fjarlægðu alla vini frá notandanum. Þar að auki er eyðingarröðin af handahófi (það er að við „stokkum“ upprunalega listann sem notaður var til að skrá gögnin). Heildarskoðunartímanum er síðan deilt með fjölda vina sem fjarlægðir eru til að fá meðaltíma á hverja ávísun.
Það þarf að keyra sviðsmyndirnar fyrir hvern og einn af gagnalíkönunum 5 og fyrir mismunandi stærðir samfélagsnetsins til að sjá hvernig tíminn breytist eftir því sem hann stækkar. Innan eins n verða tengingar á netinu og notendalisti til að athuga að sjálfsögðu að vera eins fyrir alla 5 valkostina.
Til að fá betri skilning er hér að neðan dæmi um mynduð gögn fyrir n= 5. Skrifaða „rafallinn“ framleiðir þrjár auðkennisorðabækur sem úttak:
- sá fyrsti er til innsetningar
- annað er til að athuga
- þriðja - til eyðingar
{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 друзей
Eins og þú sérð eru öll auðkenni stærri en 10 í orðabókinni til að athuga einmitt þau sem munu örugglega gefa svarið Rangt. Að setja inn, athuga og eyða „vinum“ fer fram nákvæmlega í þeirri röð sem tilgreind er í orðabókinni.
Tilraunin var gerð á fartölvu sem keyrir Windows 10, þar sem HBase var í gangi í einum Docker gámnum og Python með Jupyter Notebook var í gangi í hinum. Docker fékk úthlutað 2 CPU kjarna og 2 GB af vinnsluminni. Öll rökfræðin, bæði eftirlíking af „skilyrtu forritinu“ og „pípunni“ til að búa til prófunargögn og mæla tíma, var skrifuð í Python. Bókasafnið var notað til að vinna með HBase , til að reikna út kjötkássa (MD5) fyrir valkost 5 - hashlib
Að teknu tilliti til tölvugetu tiltekinnar fartölvu, var ræsing fyrir n = 10, 30, … valin í tilraunaskyni. 170 – þegar heildarrekstrartími alls prófunarlotunnar (allar aðstæður fyrir alla valkosti fyrir öll n) var jafnvel meira og minna sanngjarn og passaði í einu teboði (að meðaltali 15 mínútur).
Hér er nauðsynlegt að gera athugasemd við að í þessari tilraun er ekki fyrst og fremst verið að leggja mat á alger frammistöðutölur. Jafnvel hlutfallslegur samanburður á mismunandi tveimur valkostum gæti ekki verið alveg réttur. Nú höfum við áhuga á eðli tímabreytingarinnar sem fer eftir n, þar sem að teknu tilliti til ofangreindrar uppsetningar „prófunarborðsins“ er mjög erfitt að fá tímamat „hreinsað“ af áhrifum tilviljunarkenndra og annarra þátta ( og slíkt verkefni var ekki sett).
Niðurstaða tilrauna
Fyrsta prófið er hvernig tíminn sem fer í að fylla út vinalistann breytist. Niðurstaðan er á grafinu hér að neðan.
Valmöguleikar 3-5, eins og búist var við, sýna nánast stöðugan „viðskiptaviðskiptatíma“, sem er ekki háður vexti netstærðarinnar og ógreinanlegum mun á frammistöðu.
Valkostur 2 sýnir einnig stöðuga, en aðeins verri árangur, næstum nákvæmlega 2 sinnum miðað við valkosti 3-5. Og þetta getur ekki annað en fagnað, þar sem það tengist kenningum - í þessari útgáfu er fjöldi I/O aðgerða til/frá HBase nákvæmlega 2 sinnum meiri. Þetta getur þjónað sem óbein sönnun þess að prófunarbekkurinn okkar veitir í grundvallaratriðum góða nákvæmni.
Valkostur 1 reynist líka, eins og búist var við, vera hægastur og sýnir línulega aukningu á þeim tíma sem fer í að bæta hver öðrum við stærð netsins.
Við skulum nú líta á niðurstöður seinni prófsins.
Valkostir 3-5 hegða sér aftur eins og búist er við - stöðugur tími, óháð stærð netsins. Valmöguleikar 1 og 2 sýna fram á línulega aukningu í tíma eftir því sem netstærðin eykst og svipuð afköst. Þar að auki reynist valkostur 2 vera aðeins hægari - greinilega vegna þess að þörf er á að prófarkalesa og vinna úr viðbótar „talning“ dálknum, sem verður meira áberandi eftir því sem n stækkar. En ég mun samt forðast að draga neinar ályktanir, þar sem nákvæmni þessa samanburðar er tiltölulega lítil. Að auki breyttust þessi hlutföll (hvor valmöguleikinn, 1 eða 2, er hraðari) frá hlaupi til hlaups (samhliða því að viðhalda eðli ósjálfstæðisins og „fara í háls og háls“).
Jæja, síðasta línuritið er niðurstaða flutningsprófa.
Aftur kemur ekkert á óvart hér. Valkostir 3-5 framkvæma fjarlægingu á stöðugum tíma.
Þar að auki, athyglisvert, sýna valkostir 4 og 5, ólíkt fyrri atburðarásum, áberandi örlítið verri frammistöðu en valkostur 3. Svo virðist sem aðgerðin til að eyða línum er dýrari en súleyðingaraðgerðin, sem er almennt rökrétt.
Valmöguleikar 1 og 2, eins og búist var við, sýna línulega aukningu í tíma. Á sama tíma er valkostur 2 stöðugt hægari en valkostur 1 - vegna viðbótar I/O aðgerðarinnar til að „viðhalda“ talningarsúlunni.
Almennar niðurstöður tilraunarinnar:
- Valkostir 3-5 sýna meiri skilvirkni þar sem þeir nýta sér HBase; Þar að auki er frammistaða þeirra mismunandi miðað við hvert annað með fasta og fer ekki eftir stærð netsins.
- Munurinn á valkostum 4 og 5 var ekki skráður. En þetta þýðir ekki að ekki eigi að nota valmöguleika 5. Líklegt er að tilraunasviðsmyndin sem notuð var, að teknu tilliti til frammistöðueiginleika prófunarbekksins, hafi ekki gert kleift að greina hana.
- Eðli aukningar tímans sem þarf til að framkvæma „viðskiptaaðgerðir“ með gögnum staðfesti almennt áður fengna fræðilega útreikninga fyrir alla valkosti.
Eftirmáli
Ekki ætti að líta á þær grófu tilraunir sem gerðar eru sem algjöran sannleika. Það eru margir þættir sem ekki var tekið með í reikninginn og skekktu niðurstöðurnar (þessar sveiflur eru sérstaklega áberandi á línuritum með lítilli netstærð). Til dæmis, hraði sparnaðar, sem er notaður af happybase, rúmmálið og aðferðin til að útfæra rökfræðina sem ég skrifaði í Python (ég get ekki fullyrt að kóðinn hafi verið skrifaður sem best og notaði möguleika allra íhluta á áhrifaríkan hátt), kannski eiginleikar HBase skyndiminni, bakgrunnsvirkni Windows 10 á fartölvunni minni o.s.frv. Almennt má gera ráð fyrir að allir fræðilegir útreikningar hafi sýnt fram á réttmæti þeirra með tilraunum. Jæja, eða að minnsta kosti var ekki hægt að hrekja þá með slíkri „árás“.
Að lokum, ráðleggingar fyrir alla sem eru að byrja að hanna gagnalíkön í HBase: útdráttur frá fyrri reynslu af því að vinna með venslagagnagrunna og mundu eftir „boðorðunum“:
- Þegar við hönnum förum við út frá verkefninu og mynstrum gagnameðferðar, en ekki frá lénslíkaninu
- Skilvirkur aðgangur (án fullrar borðskönnunar) - aðeins með lykli
- Afeðlun
- Mismunandi línur geta innihaldið mismunandi dálka
- Dynamisk samsetning hátalara
Heimild: www.habr.com