Inleiding
"Jy moet so vinnig as wat jy kan hardloop net om in plek te bly,
en om iewers te kom, moet jy minstens twee keer so vinnig hardloop!”
(c) Alice in Wonderland
’n Tyd gelede is ek gevra om ’n lesing te gee ontleders ons maatskappy oor die ontwerp van datamodelle, want as ons vir 'n lang tyd (soms vir 'n paar jaar) aan projekte sit, verloor ons uit die oog van wat rondom ons in die wêreld van IT-tegnologie gebeur. In ons maatskappy (dit gebeur net so) gebruik baie projekte nie NoSQL-databasisse nie (ten minste vir nou), so in my lesing het ek afsonderlik aandag daaraan gegee deur die voorbeeld van HBase te gebruik en probeer om die aanbieding van die materiaal te oriënteer. wat hulle nog nooit gebruik het nie, het gewerk. Ek het veral sommige van die kenmerke van datamodelontwerp geïllustreer deur 'n voorbeeld te gebruik wat ek etlike jare gelede gelees het . Toe ek voorbeelde ontleed het, het ek verskeie opsies vergelyk om dieselfde probleem op te los om die hoofgedagtes beter aan die gehoor oor te dra.
Onlangs, "uit niks om te doen nie," het ek myself die vraag gevra (die lang Mei-naweek in kwarantyn is veral bevorderlik hiervoor), hoeveel sal teoretiese berekeninge ooreenstem met praktyk? Eintlik is dit hoe die idee vir hierdie artikel gebore is. 'n Ontwikkelaar wat al 'n paar dae met NoSQL werk, sal dalk niks nuuts daaruit leer nie (en kan dus dadelik die helfte van die artikel oorslaan). Maar vir ontledersVir diegene wat nog nie nou saam met NoSQL gewerk het nie, dink ek dit sal nuttig wees om 'n basiese begrip te kry van die kenmerke van die ontwerp van datamodelle vir HBase.
Voorbeeld analise
Na my mening, voordat jy NoSQL-databasisse begin gebruik, moet jy mooi dink en die voor- en nadele opweeg. Dikwels kan die probleem heel waarskynlik opgelos word deur tradisionele relasionele DBBS'e te gebruik. Daarom is dit beter om nie NoSQL sonder noemenswaardige redes te gebruik nie. As jy nietemin besluit het om 'n NoSQL-databasis te gebruik, moet jy in ag neem dat die ontwerpbenaderings hier ietwat anders is. Veral sommige van hulle kan ongewoon wees vir diegene wat voorheen net met relasionele DBBS'e te doen gehad het (volgens my waarnemings). Dus, in die "relasionele" wêreld, begin ons gewoonlik deur die probleemdomein te modelleer, en eers dan, indien nodig, die model te denormaliseer. In NoSQL het ons moet onmiddellik die verwagte scenario's vir die werk met data in ag neem en aanvanklik die data te denormaliseer. Daarbenewens is daar 'n aantal ander verskille, wat hieronder bespreek sal word.
Kom ons kyk na die volgende "sintetiese" probleem waarmee ons sal voortgaan om te werk:
Dit is nodig om 'n stoorstruktuur te ontwerp vir die lys vriende van gebruikers van een of ander abstrakte sosiale netwerk. Om dit te vereenvoudig, sal ons aanvaar dat al ons verbindings gerig is (soos op Instagram, nie Linkedin nie). Die struktuur moet jou in staat stel om effektief:
- Beantwoord die vraag of gebruiker A gebruiker B lees (leespatroon)
- Laat toe om verbindings by te voeg/verwyder in geval van intekening/uittekening van gebruiker A van gebruiker B (dataveranderingsjabloon)
Natuurlik is daar baie opsies om die probleem op te los. In 'n gewone relasionele databasis sal ons heel waarskynlik bloot 'n tabel van verhoudings maak (moontlik getipeer as ons byvoorbeeld 'n gebruikersgroep moet stoor: familie, werk, ens., wat hierdie "vriend") insluit), en om te optimaliseer toegangspoed sal indekse/partisionering byvoeg. Heel waarskynlik sal die finale tafel iets soos volg lyk:
gebruiker_id
vriend_id
Vasya
Petya
Vasya
Оля
hierna, vir duidelikheid en beter begrip, sal ek name in plaas van ID's aandui
In die geval van HBase weet ons dat:
- doeltreffende soektog wat nie 'n volledige tabelskandering tot gevolg het nie, is moontlik uitsluitlik per sleutel
- trouens, dit is hoekom die skryf van SQL-navrae wat vir baie bekend is na sulke databasisse 'n slegte idee is; tegnies kan jy natuurlik 'n SQL-navraag met Joins en ander logika vanaf dieselfde Impala na HBase stuur, maar hoe effektief sal dit wees...
Daarom word ons gedwing om die gebruikers-ID as 'n sleutel te gebruik. En my eerste gedagte oor die onderwerp "waar en hoe om vriende se ID's te stoor?" dalk 'n idee om dit in kolomme te stoor. Hierdie mees voor die hand liggende en "naïewe" opsie sal so iets lyk (kom ons noem dit Opsie 1 (verstek)vir verdere verwysing):
RowKey
luidsprekers
Vasya
1: Petya
2: Ola
3: Dasha
Petya
1: Masha
2: Vasya
Hier stem elke lyn ooreen met een netwerkgebruiker. Die kolomme het name: 1, 2, ... - volgens die aantal vriende, en die ID's van vriende word in die kolomme gestoor. Dit is belangrik om daarop te let dat elke ry 'n ander aantal kolomme sal hê. In die voorbeeld in die figuur hierbo het een ry drie kolomme (1, 2 en 3), en die tweede het net twee (1 en 2) - hier het ons self twee HBase-eienskappe gebruik wat relasionele databasisse nie het nie:
- die vermoë om die samestelling van kolomme dinamies te verander (voeg 'n vriend by -> voeg 'n kolom by, verwyder 'n vriend -> vee 'n kolom uit)
- verskillende rye kan verskillende kolomsamestellings hê
Kom ons kyk na ons struktuur vir voldoening aan die vereistes van die taak:
- Lees data: om te verstaan of Vasya op Olya ingeteken is, sal ons moet aftrek die hele lyn deur die sleutel RowKey = "Vasya" en sorteer deur die kolomwaardes totdat ons Olya daarin "ontmoet". Of herhaal die waardes van alle kolomme, "ontmoet nie" Olya en gee die antwoord Onwaar;
- Wysig data: voeg 'n vriend by: vir 'n soortgelyke taak moet ons ook aftrek die hele lyn gebruik die sleutel RowKey = "Vasya" om die totale aantal van sy vriende te bereken. Ons het hierdie totale aantal vriende nodig om die nommer van die kolom te bepaal waarin ons die ID van die nuwe vriend moet neerskryf.
- Verander data: vee 'n vriend uit:
- Moet aftrek die hele lyn deur die sleutel RowKey = “Vasya” en sorteer deur die kolomme om die een te vind waarin die vriend wat uitgevee moet word, aangeteken is;
- Vervolgens, nadat ons 'n vriend uitgevee het, moet ons al die data in een kolom "skuif" om nie "gapings" in hul nommering te kry nie.
Kom ons evalueer nou hoe produktief hierdie algoritmes, wat ons aan die “voorwaardelike toepassing”-kant sal moet implementeer, sal wees, met . Kom ons dui die grootte van ons hipotetiese sosiale netwerk aan as n. Dan is die maksimum aantal vriende wat een gebruiker kan hê (n-1). Ons kan dit verder nalaat (-1) vir ons doeleindes, aangesien dit binne die raamwerk van die gebruik van O-simbole onbelangrik is.
- Lees data: dit is nodig om die hele lyn af te trek en deur al sy kolomme in die limiet te herhaal. Dit beteken die boonste skatting van koste sal ongeveer O(n) wees
- Wysig data: voeg 'n vriend by: om die aantal vriende te bepaal, moet jy deur al die kolomme van die ry herhaal, en dan 'n nuwe kolom invoeg => O(n)
- Verander data: vee 'n vriend uit:
- Soortgelyk aan byvoeging - jy moet deur alle kolomme in die limiet gaan => O(n)
- Nadat ons die kolomme verwyder het, moet ons dit "skuif". As jy hierdie "kop-aan" implementeer, sal jy in die limiet tot (n-1) bewerkings benodig. Maar hier en verder in die praktiese deel sal ons 'n ander benadering gebruik, wat 'n "pseudo-skuif" sal implementeer vir 'n vaste aantal operasies - dit wil sê, konstante tyd sal daaraan bestee word, ongeag n. Hierdie konstante tyd (O(2) om presies te wees) kan verwaarloos word in vergelyking met O(n). Die benadering word in die onderstaande figuur geïllustreer: ons kopieer eenvoudig die data van die "laaste" kolom na die een waaruit ons data wil uitvee, en vee dan die laaste kolom uit:
In totaal het ons in alle scenario's 'n asimptotiese berekeningskompleksiteit van O(n) ontvang.
Jy het seker al opgemerk dat ons amper altyd die hele ry vanaf die databasis moet lees, en in twee gevalle uit drie, net om deur al die kolomme te gaan en die totale aantal vriende te bereken. Daarom, as 'n poging tot optimalisering, kan u 'n "telling"-kolom byvoeg, wat die totale aantal vriende van elke netwerkgebruiker stoor. In hierdie geval kan ons nie die hele ry lees om die totale aantal vriende te bereken nie, maar slegs een "telling"-kolom lees. Die belangrikste ding is om nie te vergeet om "telling" by te werk wanneer data gemanipuleer word nie. Daardie. ons word verbeter Opsie 2 (tel):
RowKey
luidsprekers
Vasya
1: Petya
2: Ola
3: Dasha
tel: 3
Petya
1: Masha
2: Vasya
tel: 2
In vergelyking met die eerste opsie:
- Lees data: om 'n antwoord te kry op die vraag "Lees Vasya Olya?" niks het verander nie => O(n)
- Wysig data: voeg 'n vriend by: Ons het die invoeging van 'n nuwe vriend vereenvoudig, aangesien ons nou nie die hele reël hoef te lees en oor sy kolomme te herhaal nie, maar net die waarde van die "tel"-kolom, ens. bepaal onmiddellik die kolomnommer om 'n nuwe vriend in te voeg. Dit lei tot 'n vermindering in berekeningskompleksiteit na O(1)
- Verander data: vee 'n vriend uit: Wanneer 'n vriend uitgevee word, kan ons ook hierdie kolom gebruik om die aantal I/O-bewerkings te verminder wanneer die data een sel na links "verskuif". Maar die behoefte om deur die kolomme te herhaal om die een te vind wat uitgevee moet word, bly steeds, dus => O(n)
- Aan die ander kant, nou wanneer ons data opdateer, moet ons die "telling" kolom elke keer opdateer, maar dit neem konstante tyd, wat verwaarloos kan word binne die raamwerk van O-simbole
Oor die algemeen lyk opsie 2 'n bietjie meer optimaal, maar dit is meer soos "evolusie in plaas van rewolusie." Om 'n "revolusie" te maak sal ons nodig hê Opsie 3 (kol).
Kom ons draai alles "onderstebo": ons sal aanstel kolomnaam gebruiker-ID! Wat in die kolom self geskryf gaan word, is nie meer vir ons belangrik nie, laat dit die nommer 1 wees (oor die algemeen kan nuttige goed daar gestoor word, byvoorbeeld die groep “familie/vriende/ens.”). Hierdie benadering kan die onvoorbereide "leek" verras wat geen vorige ondervinding het om met NoSQL-databasisse te werk nie, maar dit is juis hierdie benadering wat jou toelaat om die potensiaal van HBase in hierdie taak baie meer effektief te gebruik:
RowKey
luidsprekers
Vasya
Petia: 1
Olya: 1
Dasha: 1
Petya
Masha: 1
Vasya: 1
Hier kry ons verskeie voordele gelyktydig. Om dit te verstaan, kom ons ontleed die nuwe struktuur en skat die berekeningskompleksiteit:
- Lees data: om die vraag te beantwoord of Vasya op Olya ingeteken is, is dit genoeg om een kolom “Olya” te lees: as dit daar is, dan is die antwoord Waar, indien nie – Onwaar => O(1)
- Wysig data: voeg 'n vriend by: Voeg 'n vriend by: voeg net 'n nuwe kolom "Vriend ID" => O(1)
- Verander data: vee 'n vriend uit: verwyder net die Vriend ID kolom => O(1)
Soos u kan sien, is 'n beduidende voordeel van hierdie bergingsmodel dat ons in al die scenario's wat ons benodig, met slegs een kolom werk, vermy die lees van die hele ry vanaf die databasis en boonop opsom al die kolomme van hierdie ry. Ons kan daar stop, maar...
Jy kan verbaas wees en 'n bietjie verder gaan op die pad van die optimalisering van werkverrigting en die vermindering van I/O-bewerkings wanneer jy toegang tot die databasis kry. Wat as ons die volledige verhoudingsinligting direk in die rysleutel self gestoor het? Dit wil sê, maak die sleutel saamgestel soos userID.friendID? In hierdie geval hoef ons glad nie eers die kolomme van die reël te lees nie (Opsie 4 (ry)):
RowKey
luidsprekers
Vasya.Petya
Petia: 1
Vasya.Olya
Olya: 1
Vasya.Dasha
Dasha: 1
Petya.Masha
Masha: 1
Petya.Vasya
Vasya: 1
Uiteraard sal die assessering van alle datamanipulasie-scenario's in so 'n struktuur, soos in die vorige weergawe, O(1) wees. Die verskil met opsie 3 sal slegs in die doeltreffendheid van I/O-bewerkings in die databasis wees.
Wel, die laaste “boog”. Dit is maklik om te sien dat in opsie 4 die rysleutel 'n veranderlike lengte sal hê, wat moontlik prestasie kan beïnvloed (hier onthou ons dat HBase data stoor as 'n stel grepe en rye in tabelle word volgens sleutel gesorteer). Boonop het ons 'n skeier wat dalk in sommige scenario's hanteer moet word. Om hierdie invloed uit te skakel, kan jy hashes van userID en friendID gebruik, en aangesien beide hashes 'n konstante lengte sal hê, kan jy hulle eenvoudig aaneenskakel, sonder 'n skeiding. Dan sal die data in die tabel so lyk (Opsie 5 (hash)):
RowKey
luidsprekers
dc084ef00e94aef49be885f9b01f51c01918fa783851db0dc1f72f83d33a5994
Petia: 1
dc084ef00e94aef49be885f9b01f51c0f06b7714b5ba522c3cf51328b66fe28a
Olya: 1
dc084ef00e94aef49be885f9b01f51c00d2c2e5d69df6b238754f650d56c896a
Dasha: 1
1918fa783851db0dc1f72f83d33a59949ee3309645bd2c0775899fca14f311e1
Masha: 1
1918fa783851db0dc1f72f83d33a5994dc084ef00e94aef49be885f9b01f51c0
Vasya: 1
Uiteraard sal die algoritmiese kompleksiteit van die werk met so 'n struktuur in die scenario's wat ons oorweeg dieselfde wees as dié van opsie 4 - dit wil sê O(1).
In totaal, kom ons som al ons skattings van berekeningskompleksiteit in een tabel op:
Voeg 'n vriend by
Kyk na 'n vriend
Verwyder 'n vriend
Opsie 1 (verstek)
O (n)
O (n)
O (n)
Opsie 2 (tel)
O (1)
O (n)
O (n)
Opsie 3 (kolom)
O (1)
O (1)
O (1)
Opsie 4 (ry)
O (1)
O (1)
O (1)
Opsie 5 (hash)
O (1)
O (1)
O (1)
Soos u kan sien, blyk opsies 3-5 die beste te wees en teoreties verseker die uitvoering van alle nodige datamanipulasie-scenario's in konstante tyd. In die voorwaardes van ons taak is daar geen uitdruklike vereiste om 'n lys van al die gebruiker se vriende te bekom nie, maar in werklike projekaktiwiteite sal dit goed wees vir ons, as goeie ontleders, om te “verwag” dat so 'n taak kan ontstaan en "sprei 'n strooitjie." Daarom is my simpatie aan die kant van opsie 3. Maar dit is heel waarskynlik dat in 'n werklike projek hierdie versoek reeds op ander maniere opgelos kon gewees het, daarom, sonder 'n algemene visie van die hele probleem, is dit beter om nie te maak nie finale gevolgtrekkings.
Voorbereiding van die eksperiment
Ek wil graag bogenoemde teoretiese argumente in die praktyk toets – dit was die doel van die idee wat oor die langnaweek ontstaan het. Om dit te doen, is dit nodig om die werkspoed van ons "voorwaardelike toepassing" te evalueer in alle beskryfde scenario's vir die gebruik van die databasis, sowel as die toename in hierdie tyd met toenemende grootte van die sosiale netwerk (n). Die teikenparameter wat ons interesseer en wat ons tydens die eksperiment sal meet, is die tyd wat die "voorwaardelike toepassing" spandeer om een "besigheidsoperasie" uit te voer. Met “besigheidstransaksie” bedoel ons een van die volgende:
- Voeg een nuwe vriend by
- Kontroleer of gebruiker A 'n vriend van gebruiker B is
- Verwyder een vriend
Dus, met inagneming van die vereistes wat in die aanvanklike verklaring uiteengesit is, kom die verifikasiescenario soos volg na vore:
- Data opname. Genereer willekeurig 'n aanvanklike netwerk van grootte n. Om nader aan die "regte wêreld" te kom, is die aantal vriende wat elke gebruiker het ook 'n ewekansige veranderlike. Meet die tyd waartydens ons "voorwaardelike toepassing" alle gegenereerde data na HBase skryf. Deel dan die gevolglike tyd deur die totale aantal bygevoegde vriende - dit is hoe ons die gemiddelde tyd vir een "besigheidsoperasie" kry
- Lees data. Skep vir elke gebruiker 'n lys van "persoonlikhede" waarvoor jy 'n antwoord moet kry of die gebruiker op hulle ingeteken is of nie. Die lengte van die lys = ongeveer die aantal van die gebruiker se vriende, en vir die helfte van die gemerkte vriende moet die antwoord "Ja" wees, en vir die ander helfte - "Nee". Die kontrole word in so 'n volgorde uitgevoer dat die antwoorde "Ja" en "Nee" afwissel (dit wil sê, in elke tweede geval sal ons deur al die kolomme van die reël vir opsies 1 en 2 moet gaan). Die totale siftingstyd word dan gedeel deur die aantal vriende wat getoets is om die gemiddelde siftingstyd per vak te verkry.
- Vee data uit. Verwyder alle vriende van die gebruiker. Boonop is die uitveevolgorde ewekansig (dit wil sê, ons "skuifel" die oorspronklike lys wat gebruik is om die data op te teken). Die totale tjektyd word dan gedeel deur die aantal vriende wat verwyder is om die gemiddelde tyd per tjek te verkry.
Die scenario's moet vir elk van die 5 datamodel-opsies en vir verskillende groottes van die sosiale netwerk uitgevoer word om te sien hoe tyd verander soos dit groei. Binne een n moet verbindings in die netwerk en die lys gebruikers wat nagegaan moet word, natuurlik dieselfde wees vir al 5 opsies.
Vir 'n beter begrip, hieronder is 'n voorbeeld van gegenereerde data vir n= 5. Die geskrewe "generator" produseer drie ID-woordeboeke as uitvoer:
- die eerste een is vir invoeging
- die tweede is vir kontrolering
- derde – vir skrap
{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 друзей
Soos u kan sien, is alle ID's groter as 10 000 in die woordeboek vir kontrolering presies dié wat beslis die antwoord Onwaar sal gee. Die invoeging, kontrolering en verwydering van "vriende" word uitgevoer presies in die volgorde wat in die woordeboek gespesifiseer word.
Die eksperiment is uitgevoer op 'n skootrekenaar met Windows 10, waar HBase in een Docker-houer geloop het, en Python met Jupyter Notebook in die ander. Docker is 2 SVE-kerne en 2 GB RAM toegeken. Al die logika, soos die nabootsing van die "voorwaardelike toepassing" en die "pyp" vir die generering van toetsdata en meting van tyd, is in Python geskryf. Die biblioteek is gebruik om met HBase te werk , om hashes (MD5) te bereken vir opsie 5 - hashlib
Met inagneming van die rekenaarkrag van 'n spesifieke skootrekenaar, is 'n bekendstelling vir n = 10, 30, … eksperimenteel gekies. 170 – wanneer die totale bedryfstyd van die volle toetssiklus (alle scenario's vir alle opsies vir alle n) selfs min of meer redelik en fiks was tydens een teepartytjie (gemiddeld 15 minute).
Hier is dit nodig om 'n opmerking te maak dat ons in hierdie eksperiment nie primêr absolute prestasiesyfers evalueer nie. Selfs 'n relatiewe vergelyking van verskillende twee opsies is dalk nie heeltemal korrek nie. Nou is ons geïnteresseerd in die aard van die verandering in tyd, afhangende van n, aangesien met inagneming van die bogenoemde konfigurasie van die "toetsstand", dit baie moeilik is om tydskattings te verkry "uitgevee" van die invloed van ewekansige en ander faktore ( en so 'n taak is nie opgestel nie).
Eksperiment resultaat
Die eerste toets is hoe die tyd wat spandeer word om die vriendelys in te vul, verander. Die resultaat is in die grafiek hieronder.
Opsies 3-5, soos verwag, toon 'n byna konstante "besigheidstransaksie" tyd, wat nie afhang van die groei van die netwerkgrootte en 'n ononderskeibare verskil in prestasie nie.
Opsie 2 toon ook konstante, maar effens swakker prestasie, amper presies 2 keer relatief tot opsies 3-5. En dit kan nie anders as om bly te wees nie, aangesien dit met teorie korreleer - in hierdie weergawe is die aantal I/O-bewerkings na/van HBase presies 2 keer groter. Dit kan as indirekte bewys dien dat ons toetsbank in beginsel goeie akkuraatheid verskaf.
Opsie 1 blyk ook, soos verwag, die stadigste te wees en toon 'n lineêre toename in die tyd wat spandeer word om mekaar by die grootte van die netwerk te voeg.
Kom ons kyk nou na die resultate van die tweede toets.
Opsies 3-5 tree weer soos verwag op - konstante tyd, onafhanklik van die grootte van die netwerk. Opsies 1 en 2 toon 'n lineêre toename in tyd namate die netwerkgrootte toeneem en soortgelyke werkverrigting. Boonop blyk opsie 2 'n bietjie stadiger te wees - blykbaar as gevolg van die behoefte om die bykomende "tel"-kolom te proeflees en te verwerk, wat meer opvallend word soos n groei. Maar ek sal my steeds daarvan weerhou om enige gevolgtrekkings te maak, aangesien die akkuraatheid van hierdie vergelyking relatief laag is. Daarbenewens het hierdie verhoudings (watter opsie, 1 of 2, vinniger is) verander van hardloop na hardloop (terwyl die aard van die afhanklikheid gehandhaaf word en "nek en nek gaan").
Wel, die laaste grafiek is die resultaat van verwyderingstoetsing.
Weereens, geen verrassings hier nie. Opsies 3-5 voer verwydering in konstante tyd uit.
Boonop, interessant genoeg, toon opsies 4 en 5, anders as die vorige scenario's, merkbaar effens swakker werkverrigting as opsie 3. Blykbaar is die ry-skrap-operasie duurder as die kolom-skrap-operasie, wat oor die algemeen logies is.
Opsies 1 en 2, soos verwag, toon 'n lineêre toename in tyd. Terselfdertyd is opsie 2 konsekwent stadiger as opsie 1 - as gevolg van die bykomende I/O-bewerking om die telkolom te "onderhou".
Algemene gevolgtrekkings van die eksperiment:
- Opsies 3-5 demonstreer groter doeltreffendheid aangesien hulle voordeel trek uit HBase; Boonop verskil hul prestasie relatief tot mekaar met 'n konstante en hang nie af van die grootte van die netwerk nie.
- Die verskil tussen opsies 4 en 5 is nie aangeteken nie. Maar dit beteken nie dat opsie 5 nie gebruik moet word nie. Dit is waarskynlik dat die eksperimentele scenario wat gebruik is, met inagneming van die prestasie-eienskappe van die toetsbank, nie toegelaat het dat dit opgespoor word nie.
- Die aard van die toename in die tyd wat nodig is om "sakebedrywighede" met data uit te voer, het oor die algemeen die voorheen verkry teoretiese berekeninge vir alle opsies bevestig.
Epiloog
Die rowwe eksperimente wat uitgevoer word, moet nie as absolute waarheid beskou word nie. Daar is baie faktore wat nie in ag geneem is nie en die resultate verwring het (hierdie fluktuasies is veral sigbaar in die grafieke met 'n klein netwerkgrootte). Byvoorbeeld, die spoed van spaarsaamheid, wat deur happybase gebruik word, die volume en metode om die logika wat ek in Python geskryf het te implementeer (ek kan nie beweer dat die kode optimaal geskryf is en die vermoëns van alle komponente effektief gebruik het nie), miskien die kenmerke van HBase-kas, agtergrondaktiwiteit van Windows 10 op my skootrekenaar, ens. Oor die algemeen kan ons aanvaar dat alle teoretiese berekeninge hul geldigheid eksperimenteel gedemonstreer het. Wel, of dit was ten minste nie moontlik om hulle met so 'n "kop-aan-aanval" te weerlê nie.
Ten slotte, aanbevelings vir almal wat net begin om datamodelle in HBase te ontwerp: abstrak uit vorige ondervinding van werk met relasionele databasisse en onthou die "opdragte":
- Wanneer ons ontwerp, gaan ons uit van die taak en patrone van datamanipulasie, en nie van die domeinmodel nie
- Doeltreffende toegang (sonder volledige tafelskandering) – slegs deur sleutel
- Denormalisering
- Verskillende rye kan verskillende kolomme bevat
- Dinamiese samestelling van sprekers
Bron: will.com