Paş nîvro Navê min Danil Lipovoy e, tîmê me li Sbertech dest bi karanîna HBase wekî hilanînê ji bo daneyên xebitandinê kir. Di dema xwendina wê de, ezmûnek ku min dixwest ez bi pergalî û vebêjim berhev bikim (em hêvî dikin ku ew ê ji gelek kesan re kêrhatî be). Hemî ceribandinên jêrîn bi guhertoyên HBase 1.2.0-cdh5.14.2 û 2.0.0-cdh6.0.0-beta1 hatin kirin.
- Mîmariya Giştî
- Daneyên nivîsandina HBASE
- Daneyên ji HBASE dixwînin
- Data Caching
- Pêvajoya daneya berhevokê MultiGet/MultiPut
- Stratejiya ji bo dabeşkirina tabloyan li herêman (parçebûn)
- Tolerasyona xeletiyê, berhevkirin û cîhê daneyê
- Mîheng û performansa
- Testkirina Stresê
- vebiguherin
1. Mîmariya giştî
Masterê paşverû guhê xwe dide lêdana dilê yê çalak li ser girêka ZooKeeper û, di rewşek windabûnê de, fonksiyonên master digire.
2. Daneyên HBASE binivîsin
Pêşî, ka em li rewşa herî hêsan binêrin - bi karanîna put(rowkey) li ser maseyê tiştek nirx-kilît binivîsin. Pêdivî ye ku xerîdar pêşî fêr bibe ku Servera Herêmê ya Root (RRS), ku tabloya hbase:meta hilîne, li ku ye. Ew van agahiyan ji ZooKeeper distîne. Pişt re ew xwe digihîne RRS û tabloya hbase:meta dixwîne, ku jê agahdarî derdixe ka kîjan RegionServer (RS) berpirsiyar e ji bo hilanîna daneyan ji bo rêzek diyarkirî di tabloya balkêş de. Ji bo karanîna pêşerojê, tabloya meta ji hêla xerîdar ve tê girtin û ji ber vê yekê bangên paşîn zûtir diçin, rasterast berbi RS-ê.
Dûv re, RS, ku daxwazek wergirtiye, berî her tiştî wê ji WriteAheadLog (WAL) re dinivîse, ku ji bo başbûnê di rewşek qezayê de pêdivî ye. Dûv re daneyan li MemStore tomar dike. Ev tamponek di bîranînê de ye ku ji bo herêmek diyar komek bişkokên birêkûpêk vedihewîne. Tabloyek dikare li herêman (parçeyan) were dabeş kirin, ku her yek ji wan komek ji kilîtan veqetandî dihewîne. Ev dihêle hûn deveran li ser serverên cihêreng bicîh bikin da ku performansa bilindtir bi dest bixin. Lêbelê, tevî eşkerebûna vê gotinê, em ê paşê bibînin ku ev di hemî rewşan de ne kar dike.
Piştî danîna têketinek li MemStore, bersivek ji xerîdar re tê vegerandin ku têketin bi serfirazî hate tomar kirin. Lêbelê, di rastiyê de ew tenê di tamponek de tête hilanîn û tenê piştî ku demek diyar derbas bû an jî dema ku ew bi daneyên nû dagirtî digihîje dîskê.
Dema ku operasyona "Delete" tê kirin, dane bi fîzîkî nayê jêbirin. Ew bi tenê wekî jêbirin têne nîşankirin, û hilweşîn bixwe di dema bangkirina fonksiyona mezin a kompakt de, ku di paragrafa 7-ê de bi hûrgulî tête diyar kirin, pêk tê.
Pelên di formata HFile de di HDFS de têne berhev kirin û dem bi dem pêvajoyek hûrgelê ya piçûk tê destpêkirin, ku bi tenê pelên piçûk di nav yên mezin de yek dike bêyî ku tiştek jê bibe. Bi demê re, ev vediguhere pirsgirêkek ku tenê dema xwendina daneyan xuya dike (em ê hinekî paşê vegerin ser vê).
Digel pêvajoya barkirinê ya ku li jor hatî destnîşan kirin, pêvajoyek pir bi bandortir heye, ku dibe ku aliyek herî bihêz a vê databasê ye - BulkLoad. Ew di rastiyê de ye ku em serbixwe HFiles ava dikin û wan li ser dîskê datînin, ku rê dide me ku em bi rengek bêkêmasî pîvandin û bilezên pir maqûl bi dest bixin. Bi rastî, tixûb li vir ne HBase, lê kapasîteyên hardware ye. Li jêr encamên bootê hene ku ji 16 RegionServers û 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads), guhertoya HBase 1.2.0-cdh5.14.2 pêk tê.
Li vir hûn dikarin bibînin ku bi zêdekirina hejmara dabeşan (herêm) di tabloyê de, û her weha îcrakar Spark, em leza dakêşanê zêde dibin. Di heman demê de, bilez bi qebareya tomarkirinê ve girêdayî ye. Blokên mezin di MB / sec de zêdebûnek didin, blokên piçûk di hejmara tomarên ku di yekîneya demê de têne danîn, hemî tiştên din wekhev in.
Her weha hûn dikarin di heman demê de dest bi barkirina du tabloyan bikin û leza ducarî bistînin. Li jêr hûn dikarin bibînin ku nivîsandina blokên 10 KB li ser du tabloyan bi yekcarî bi leza 600 MB/sec di her yekê de pêk tê (bi tevahî 1275 MB/sec), ku bi leza nivîsandina tabloyek 623 MB/sec re hevaheng e (binêre Hejmar 11 li jor)
Lê gera duyemîn bi tomarên 50 KB nîşan dide ku leza dakêşanê hinekî mezin dibe, ku ev yek nîşan dide ku ew nêzîkê nirxên sînor dibe. Di heman demê de, divê hûn ji bîr mekin ku di pratîkê de ti barek li ser HBASE bixwe nehatiye afirandin, ya ku jê re tê xwestin ew e ku hûn pêşî daneyan ji hbase:meta bidin, û piştî rêzkirina HFiles, daneyên BlockCache-ê ji nû ve saz bikin û tomar bikin. MemStore tampon dîskê, ger ne vala be.
3. Daneyên xwendinê ji HBASE
Ger em texmîn bikin ku xerîdar jixwe hemî agahdariya ji hbase:meta heye (binihêre xala 2), wê hingê daxwaz rasterast diçe RS-ê ku li wir mifteya pêwîst tê hilanîn. Pêşîn, lêgerîn di MemCache de tête kirin. Tevî ku li wir dane hene an na, lêgerîn di tampona BlockCache de û, ger hewce be, di HFiles de jî tê kirin. Ger data di pelê de hat dîtin, ew li BlockCache tê danîn û li ser daxwaziya din dê zûtir were vegerandin. Lêgerîna di HFile de bi saya karanîna Parzûna Bloom-ê bi lez e, yanî. piştî xwendina hejmarek piçûk a daneyê, ew tavilê diyar dike ka ev pel mifteya pêwîst dihewîne an na, wê hingê derbasî ya din dibe.
Piştî ku daneyên ji van sê çavkaniyan wergirtin, RS bersivek diafirîne. Bi taybetî, heke ku xerîdar guhertoyek bixwaze, ew dikare çend guhertoyên dîtbar ên tiştek yekcar veguhezîne.
4. Data Caching
Tamponên MemStore û BlockCache heya 80% ji bîranîna RS-ya ser-heap veqetandî digire (ya mayî ji bo karên karûbarê RS ve hatî veqetandin). Ger moda karanîna tîpîk wusa be ku pêvajoyan heman daneyan dinivîsin û yekser dixwînin, wê hingê maqûl e ku meriv BlockCache kêm bike û MemStore zêde bike, ji ber ku Dema ku daneya nivîsandinê ji bo xwendinê nekeve kaşê, BlockCache dê kêm caran were bikar anîn. Tampona BlockCache ji du beşan pêk tê: LruBlockCache (her gav li ser-heap) û BucketCache (bi gelemperî ji-heap an li ser SSD-ê). Pêdivî ye ku BucketCache were bikar anîn dema ku gelek daxwazên xwendinê hene û ew di LruBlockCache de cih nagirin, ku rê li ber xebata çalak a Berhevkarê Garbage vedike. Di heman demê de, divê hûn ji karanîna cache-ya xwendinê li hêviya zêdebûnek radîkal a performansê nebin, lê em ê di paragrafa 8-ê de vegerin ser vê
Ji bo tevahiya RS yek BlockCache heye, û ji bo her maseyê yek MemStore heye (yek ji bo her Malbata Stûnê).
çawa di teorîyê de, dema nivîsandinê, dane naçe nav cacheyê û bi rastî, pîvanên weha CACHE_DATA_ON_WRITE ji bo tabloyê û "Daneyên Cache li ser Nivîsandinê" ji bo RS-ê wekî xelet têne danîn. Lêbelê, di pratîkê de, heke em daneyan li MemStore binivîsin, dûv re wê li ser dîskê bişon (bi vî rengî wê paqij bikin), dûv re pelê encam jêbirin, wê hingê bi pêkanîna daxwazek wergirtinê em ê daneyan bi serfirazî bistînin. Wekî din, her çend hûn BlockCache bi tevahî neçalak bikin û tabloyê bi daneyên nû tije bikin, dûv re MemStore-ê li dîskê sifir bikin, wan jêbikin û wan ji danişînek din bixwazin, ew ê dîsa jî ji deverekê werin derxistin. Ji ber vê yekê HBase ne tenê daneyan, lê di heman demê de sirên nepenî jî hilîne.
hbase(main):001:0> create 'ns:magic', 'cf'
Created table ns:magic
Took 1.1533 seconds
hbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me'
Took 0.2610 seconds
hbase(main):003:0> flush 'ns:magic'
Took 0.6161 seconds
hdfs dfs -mv /data/hbase/data/ns/magic/* /tmp/trash
hbase(main):002:0> get 'ns:magic', 'key1'
cf:c timestamp=1534440690218, value=try_to_delete_me
Parametreya "Daneyên Cache li ser Xwendinê" wekî xelet hatî danîn. Ger ramanên we hebin, bi xêr hatin ku hûn di şîroveyan de wê nîqaş bikin.
5. Pêvajoya daneya berhevokê MultiGet/MultiPut
Pêvajoya daxwazên yekane (Gotin / Bixe / Jêbirin) operasyonek pir biha ye, ji ber vê yekê heke gengaz be, divê hûn wan di nav Lîsteyek an Lîsteyek de berhev bikin, ku dihêle hûn performansek girîng zêde bikin. Ev bi taybetî ji bo operasyona nivîsandinê rast e, lê dema xwendinê xeletiya jêrîn heye. Grafika jêrîn dema xwendina 50 tomar ji MemStore nîşan dide. Xwendin di yek mijarekê de hate kirin û tebeqeya horizontî di daxwaznameyê de hejmara kilît nîşan dide. Li vir hûn dikarin bibînin ku dema ku di yek daxwazê de bi hezar kilît zêde dibe, dema darvekirinê dadikeve, yanî. lez zêde dibe. Lêbelê, digel ku moda MSLAB-ê ji hêla xwerû ve hatî çalak kirin, piştî vê bendavê daketinek radîkal di performansê de dest pê dike, û her ku mîqdara daneya di tomarê de mezintir be, dema xebitandinê dirêjtir dibe.
Test li ser makîneyek virtual, 8 core, guhertoya HBase 2.0.0-cdh6.0.0-beta1 hatin kirin.
Moda MSLAB ji bo kêmkirina perçebûna girikê, ku ji ber tevlihevkirina daneyên nifşê nû û kevn pêk tê, hatî çêkirin. Wekî çareseriyek, dema ku MSLAB tê çalak kirin, dane di nav şaneyên piçûk (çiçikan) de têne danîn û di perçeyan de têne hilberandin. Wekî encamek, gava ku hêjmara di pakêta daneya daxwazkirî de ji mezinahiya veqetandî derbas dibe, performans bi tundî dadikeve. Ji hêla din ve, qutkirina vê modê jî nayê pêşniyar kirin, ji ber ku ew ê di demên pêvajoyek daneya zirav de ji ber GC-ê rawestîne. Çareseriyek baş ev e ku di rewşa nivîsandina çalak de bi riya danînê di heman demê de bi xwendinê re hêjmara şaneyê zêde bike. Hêjayî gotinê ye ku heke, piştî tomarkirinê, hûn fermana flush-ê, ku MemStore-ê li ser dîskê vegerîne, an heke hûn bi karanîna BulkLoad-ê bar dikin, pirsgirêk dernakeve. Tabloya jêrîn nîşan dide ku lêpirsînên ji MemStore-ê ji bo daneya mezintir (û heman mîqdar) dibe sedema hêdîbûnê. Lêbelê, bi zêdekirina çunksize em dema pêvajoyê vedigerînin normal.
Ji bilî zêdekirina chunksize, dabeşkirina daneyan li gorî herêmê dibe alîkar, ango. dabeşkirina sifrê. Ev dibe sedema ku kêmtir daxwaz werin her herêmê û ger ew di hucreyek de cih bigirin, bersiv baş dimîne.
6. Stratejiya dabeşkirina tabloyan li herêman (parçebûn)
Ji ber ku HBase hilanînek nirx-kilît e û dabeşkirin ji hêla mifteyê ve tête kirin, pir girîng e ku daneyan bi rengek wekhev li hemî deveran dabeş bikin. Mînakî, dabeşkirina tabloyek weha li sê beşan dê encam bide ku dane li sê deveran were dabeş kirin:
Diqewime ku ev dibe sedema hêdîbûnek tûj ger daneyên ku paşê hatine barkirin mîna, mînakî, nirxên dirêj xuya dikin, piraniya wan bi heman hejmarê dest pê dikin, mînakî:
1000001
1000002
...
1100003
Ji ber ku bişkok wekî rêzek byte têne hilanîn, ew ê hemî bi heman rengî dest pê bikin û girêdayî heman devera #1 bin ku vê rêze mifteyan hilîne. Gelek stratejiyên dabeşkirinê hene:
HexStringSplit - Miftê di rêza "00000000" => "FFFFFFFF" de vediguherîne rêzikek şîfrekirî ya hexadecimal û li milê çepê bi sifiran dixe.
UniformSplit - Miftê bi şîfrekirina hexadecimal di rêza "00" => "FF" de vedigerîne rêzek byte û li milê rastê bi sifiran vedişêre.
Digel vê yekê, hûn dikarin her cûrbecûr an komek bişkokên ji bo parçebûnê diyar bikin û veqetandina otomatîkî mîheng bikin. Lêbelê, yek ji nêzîkatiyên herî hêsan û bibandor UniformSplit e û karanîna hevgirêdana hash e, mînakî cotê herî girîng ê baytê ji xebitandina mifteyê bi fonksiyona CRC32 (rowkey) û rowkey bixwe:
hash + rowkey
Dûv re hemî dane dê bi rengek wekhev li herêman were belav kirin. Dema xwendinê, du baytên pêşîn bi hêsanî têne avêtin û mifteya orîjînal dimîne. RS di heman demê de mîqdara dane û kilîtên li herêmê jî kontrol dike û heke sînor derbas bibin, bixweber wê perçe dike.
7. Tolerasyona xeletî û cîhê daneyê
Ji ber ku tenê yek herêm ji bo her komek kilîtan berpirsiyar e, çareseriya pirsgirêkên ku bi têkçûna RS-ê ve girêdayî ye an hilweşandin ev e ku hemî daneyên pêwîst di HDFS de hilîne. Dema ku RS dikeve, master vê yekê bi nebûna lêdana dil a li ser girêka ZooKeeper nas dike. Dûv re ew herêma servekirî ji RS-ya din re destnîşan dike û ji ber ku HFiles di pergalek pelê ya belavkirî de têne hilanîn, xwediyê nû wan dixwîne û xizmeta daneyan didomîne. Lêbelê, ji ber ku hin dane dibe ku di MemStore-ê de bin û wext tune ku têkevin HFiles, WAL, ku di HDFS-ê de jî tê hilanîn, ji bo sererastkirina dîroka xebatan tê bikar anîn. Piştî ku guheztin têne sepandin, RS dikare bersivê bide daxwazan, lê tevger rê li ber vê yekê vedike ku hin dane û pêvajoyên ku ji wan re xizmet dikin bi dawî dibin li ser girêkên cihêreng, ango. herêmî kêm dibe.
Çareseriya pirsgirêkê berhevkirina mezin e - ev prosedur pelan diguhezîne wan girêkên ku ji wan re berpirsiyar in (ku herêmên wan lê ne), wekî encamek di vê pêvajoyê de barkirina li ser torê û dîskan bi tundî zêde dibe. Lêbelê, di pêşerojê de, gihîştina daneyan bi baldarî bileztir dibe. Digel vê yekê, major_compaction hemî HFileyan di yek pelê de di nav herêmek de yek dike, û li gorî mîhengên tabloyê jî daneyan paqij dike. Mînakî, hûn dikarin hejmara guhertoyên tiştekê ku divê were hilanîn an jî heyama ku piştî ku ew tişt bi fizîkî tê jêbirin diyar bikin.
Ev prosedur dikare bandorek pir erênî li ser xebata HBase bike. Wêneya jêrîn nîşan dide ka performansê çawa di encama tomarkirina daneya çalak de xera dibe. Li vir hûn dikarin bibînin ka 40 mijaran li ser tabloyek çawa dinivîsin û 40 mijaran di heman demê de daneyan dixwînin. Mijarên nivîsandinê her ku diçe bêtir HFile çêdikin, ku ji hêla mijarên din ve têne xwendin. Wekî encamek, pêdivî ye ku bêtir û bêtir dane ji bîranînê werin rakirin û di dawiyê de GC dest bi xebatê dike, ku bi pratîkî hemî xebatê felc dike. Destpêkirina berhevkirina mezin bû sedema paqijkirina bermahiyên encam û vegerandina hilberînê.
Test li ser 3 DataNodes û 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 Mijar) hate kirin. Guhertoya HBase 1.2.0-cdh5.14.2
Hêjayî gotinê ye ku berhevokek mezin li ser tabloyek "zindî" hate destpêkirin, ku tê de dane bi rengek çalak hate nivîsandin û xwendin. Daxuyaniyek serhêl hebû ku ev dibe sedema bersivek xelet dema xwendina daneyan. Ji bo kontrolkirinê, pêvajoyek hate destpêkirin ku daneyên nû hilberand û li ser tabloyek nivîsand. Piştra min tavilê xwend û kontrol kir ka nirxa encam bi ya ku hatî nivîsandin re hevûdu ye. Di dema ku ev pêvajo dimeşiya, bi qasî 200 caran tevliheviyek mezin hate meşandin û yek têkçûnek jî nehat tomarkirin. Dibe ku pirsgirêk kêm kêm û tenê di dema barkirina zêde de xuya bibe, ji ber vê yekê ewletir e ku meriv pêvajoyên nivîsandin û xwendinê wekî ku hatî plansaz kirin rawestîne û paqijkirinê bike da ku pêşî li kêşeyên weha yên GC bigire.
Di heman demê de, berhevkirina mezin bandorê li rewşa MemStore nake, da ku hûn wê berbi dîskê vekin û wê tevlihev bikin, hûn hewce ne ku flush bikar bînin (connection.getAdmin().flush(TableName.valueOf(tblName))).
8. Mîheng û performansa
Wekî ku berê jî behs kir, HBase serkeftina xwe ya herî mezin nîşan dide ku ew ne hewce ye ku tiştek bike, dema ku BulkLoad bicîh tîne. Lêbelê, ev ji bo pir pergal û mirovan derbas dibe. Lêbelê, ev amûr ji bo hilanîna daneyan bi girseyî di blokên mezin de maqûltir e, di heman demê de heke pêvajo hewceyê pir daxwazên xwendin û nivîsandinê yên hevrikî bike, emrên Get û Put ku li jor hatine destnîşan kirin têne bikar anîn. Ji bo destnîşankirina parametreyên çêtirîn, destpêkirin bi cûrbecûr cûrbecûr pîvan û mîhengên tabloyê hatin kirin:
- 10 mijar bi hevdemî 3 caran li pey hev hatin destpêkirin (ka em jê re bibêjin blokek têlan).
- Dema xebitandinê ya hemî têlên di blokê de navînî bû û encama dawî ya xebata blokê bû.
- Hemî mijarên bi heman tabloyê dixebitin.
- Berî her destpêkirina bloka tîrêjê, berhevkirinek mezin hate kirin.
- Her blokê tenê yek ji van operasyonên jêrîn pêk anî:
-Raxistan
-Stendin
— Bigir+Danîn
- Her blokek 50 dubareyên operasyona xwe pêk anîn.
- Mezinahiya bloka tomarek 100 byte, 1000 bytes an 10000 bytes (random) ye.
- Blok bi hejmarên cûda yên bişkojkên daxwazkirî (yan yek key an jî 10) hatin destpêkirin.
- Blok di bin mîhengên tabloya cihêreng de hatin meşandin. Parametre hatin guhertin:
- BlockCache = vebûye an vekiriye
- BlockSize = 65 KB an 16 KB
- Dabeş = 1, 5 an 30
- MSLAB = çalak an neçalak
Ji ber vê yekê bloka weha xuya dike:
yek. Moda MSLAB vebû/çalak bû.
b. Tabloyek ku ji bo wê pîvanên jêrîn hatine danîn hate afirandin: BlockCache = rast/tune, BlockSize = 65/16 Kb, Parçekirin = 1/5/30.
c. Compression li GZ hate danîn.
d. 10 mijar bi hevdemî hatin destpêkirin û 1/10 operasyonên danîn/girtin/girtin+ danîn li ser vê tabloyê bi tomarên 100/1000/10000 byte, 50 pirs li pey hev kirin (bişkojkên random).
e. Xala d sê caran hate dubare kirin.
f. Dema xebatê ya hemî mijaran navîn bû.
Hemî tevliheviyên gengaz hatin ceribandin. Tê pêşbînîkirin ku her ku mezinbûna tomarê zêde dibe leza wê dakeve, an jî neçalakkirina cachkirinê dê bibe sedema hêdîbûnê. Lêbelê, armanc ev bû ku meriv asta û girîngiya bandora her parameterê fam bike, ji ber vê yekê daneyên berhevkirî di nav têketina fonksiyonek paşvekêşana xêz de hate xwarin, ku ev gengaz dike ku bi karanîna statîstîkên t-ê girîngiyê binirxîne. Li jêr encamên blokên ku operasyonên Put dikin hene. Komek tevahî ya kombînasyonan 2*2*3*2*3 = 144 vebijark + 72 tk. hinek du caran hatin kirin. Ji ber vê yekê, bi tevahî 216 rêve hene:
Testkirin li ser mînî-klusterek ku ji 3 DataNodes û 4 RS pêk tê (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 mijarên) hate kirin. Guhertoya HBase 1.2.0-cdh5.14.2.
Leza ketina herî bilind a 3.7 saniyeyan bi moda MSLAB vegirtî, li ser tabloyek bi yek dabeşkirinê, bi çalakkirina BlockCache, BlockSize = 16, tomarên 100 byte, 10 perçe ji her pakêtê re hate bidestxistin.
Leza têketina herî hindik a 82.8 saniyeyê bi moda MSLAB ve hatî çalak kirin, li ser maseyek bi yek dabeşkirinê, bi çalakkirina BlockCache, BlockSize = 16, tomarên 10000 byte, 1 her yek.
Niha em li modelê binêrin. Em qalîteya baş a modela li ser bingeha R2 dibînin, lê bê guman eşkere ye ku ekstrapolasyon li vir berevajî ye. Tevgera rastîn a pergalê dema ku parametre biguhezîne dê ne xêz be, ev model ne ji bo pêşbîniyan, lê ji bo têgihîştina tiştê ku di nav parametreyên diyarkirî de qewimiye pêdivî ye. Mînakî, li vir em ji pîvana Xwendekarê dibînin ku parametreyên BlockSize û BlockCache ji bo operasyona Put ne girîng e (ku bi gelemperî pir pêşbîn e):
Lê rastiya ku zêdekirina hejmara dabeşan dibe sedema kêmbûna performansê hinekî neçaverê ye (me berê jî bandora erênî ya zêdekirina hejmara dabeşan bi BulkLoad re dîtiye), her çend têgihîştî ye. Pêşîn, ji bo pêvajoyê, hûn neçar in ku li şûna yekê ji 30 deveran daxwazan biafirînin, û qebareya daneyê ne wusa ye ku ev ê qezencek bide. Ya duyemîn, dema xebatê ya tevayî ji hêla RS-ya herî hêdî ve tê destnîşankirin, û ji ber ku hejmara DataNodes ji hejmara RS-an kêmtir e, hin herêm xwedî cihek sifir in. Werin, em li pênc top binêrin:
Naha werin em encamên pêkanîna blokên Get binirxînin:
Hejmara dabeşan girîngiya xwe winda kiriye, ku dibe ku bi vê yekê ve were ravekirin ku dane baş têne vegirtin û cache-ya xwendinê parametera herî girîng (ji hêla îstatîstîkî ve) ye. Bi xwezayî, zêdekirina hejmara peyamên di daxwazekê de ji bo performansê jî pir bikêr e. Pûanên herî bilind:
Welê, di dawiyê de, em li modela bloka ku yekem pêk anîn û dûv re danîn binêre:
Hemî pîvan li vir girîng in. Û encamên rêberên:
9. Testkirina barkirinê
Welê, di dawiyê de em ê bargiraniyek kêm-zêde maqûl bidin destpêkirin, lê gava ku hûn tiştek ku hûn pê re berhev bikin her gav balkêştir e. Li ser malpera DataStax, pêşdebirê sereke yê Cassandra, heye NT ya hejmarek hilanîna NoSQL, di nav de guhertoya HBase 0.98.6-1. Barkirin ji hêla 40 mijaran, mezinahiya daneyê 100 bytes, dîskên SSD ve hate kirin. Encama ceribandina operasyonên Read-Guherandin-Nivîs encamên jêrîn nîşan da.
Bi qasî ku ez fêm dikim, xwendin di blokên 100 tomar de û ji bo 16 girêkên HBase hate kirin, testa DataStax performansek 10 hezar operasyon di çirkeyê de nîşan da.
Bextewar e ku koma me jî 16 girêk hene, lê ne pir "bext" e ku her yekê 64 naverok (mijar) hene, dema ku di testa DataStax de tenê 4 hene. Ji aliyekî din ve, ajokarên SSD hene, dema ku HDD-yên me hene. an jî bêtir guhertoya nû ya karanîna HBase û CPU di dema barkirinê de bi pratîkî pir zêde zêde nebû (bi dîtbarî ji sedî 5-10). Lêbelê, em hewl bidin ku dest bi karanîna vê veavakirinê bikin. Mîhengên tabloya xwerû, xwendin di rêza kilît de ji 0 heta 50 mîlyon bêserûber tê kirin (ango, bi bingehîn her car nû). Di tabloyê de 50 mîlyon tomar hene, ku di nav 64 dabeşan de têne dabeş kirin. Bişkojk bi karanîna crc32 têne haş kirin. Mîhengên tabloyê xwerû ne, MSLAB çalak e. Bi destpêkirina 40 mijaran, her mijar komek ji 100 bişkokên bêserûber dixwîne û tavilê 100 baytên hatî çêkirin vedigere van bişkojan.
Stand: 16 DataNode û 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 têlan). Guhertoya HBase 1.2.0-cdh5.14.2.
Encama navîn di çirkeyê de nêzî 40 hezar operasyon e, ku ji ceribandina DataStax-ê pir çêtir e. Lêbelê, ji bo armancên ceribandinê, hûn dikarin şert û mercan hinekî biguhezînin. Pir ne mimkûn e ku hemî kar bi taybetî li ser yek maseyê, û her weha tenê li ser bişkokên bêhempa bêne kirin. Ka em texmîn bikin ku komek bişkokên "germ" hene ku barkirina sereke çêdike. Ji ber vê yekê, em hewl bidin ku barkêşek bi tomarên mezintir (10 KB), di heman demê de di komên 100 de, di 4 tabloyên cihêreng de biafirînin û rêza kilîtên daxwazkirî bi 50 hezarî re sînordar bikin Grafika jêrîn destpêkirina 40 têlan nîşan dide, her mijar dixwîne komek ji 100 bişkokan û yekser 10 KB li ser van bişkokan paşve dinivîse.
Stand: 16 DataNode û 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 têlan). Guhertoya HBase 1.2.0-cdh5.14.2.
Di dema barkirinê de, berhevkirina mezin çend caran hate destpêkirin, wekî ku li jor hatî destnîşan kirin, bêyî vê prosedurê, performans hêdî hêdî kêm dibe, di heman demê de, barek zêde jî di dema darvekirinê de derdikeve. Kêmbûn ji ber sedemên cûda çêdibin. Carinan karûbar diqede û dema ku ew ji nû ve dest pê kirin sekinînek hebû, carinan serîlêdanên partiya sêyemîn barek li ser komê diafirînin.
Xwendin û yekser nivîsandin ji bo HBase yek ji senaryoyên xebatê yên herî dijwar e. Ger hûn tenê daxwazên danîna piçûk bikin, mînakî 100 byte, wan di pakêtên 10-50 hezar perçeyan de berhev bikin, hûn dikarin di çirkeyê de bi sed hezaran operasyonan bistînin, û rewş bi daxwazên tenê-xwendinê re jî wisa ye. Hêjayî gotinê ye ku encam ji yên ku ji hêla DataStax ve hatine bidestxistin radîkal çêtir in, ya herî zêde ji ber daxwazên di blokên 50 hezarî de.
Stand: 16 DataNode û 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 têlan). Guhertoya HBase 1.2.0-cdh5.14.2.
10. Encam
Ev pergal bi rengek nermî hatî mîheng kirin, lê bandora hejmareke mezin a parametreyan hîn jî nenas dimîne. Hin ji wan hatin ceribandin, lê di testa encam de nehatin girtin. Mînakî, ceribandinên pêşîn girîngiyek ne girîng a parametreyek wekî DATA_BLOCK_ENCODING, ku agahdariya bi karanîna nirxên ji hucreyên cîran kod dike, ku ji bo daneyên ku bi rengek rasthatî têne hilberandin têne fam kirin, nîşan dan. Ger hûn hejmareke mezin ji tiştên dubare bikar bînin, qezenc dikare girîng be. Bi gelemperî, em dikarin bibêjin ku HBase nîşana danegehek pir ciddî û xweş-ramandî dide, ku dema ku operasyonan bi blokên mezin ên daneyê re dike dikare pir hilberdar be. Bi taybetî jî heke gengaz be ku pêvajoyên xwendin û nivîsandinê di wextê de ji hev veqetînin.
Ger tiştek di dîtina we de hebe ku têra xwe nehatibe eşkere kirin, ez amade me ku bi berfirehî ji we re vebêjim. Em we vedixwînin ku hûn serpêhatiya xwe parve bikin an jî nîqaş bikin ger hûn bi tiştekî re ne razî bin.
Source: www.habr.com
