Teorya at kasanayan sa paggamit ng HBase

Magandang hapon Ang pangalan ko ay Danil Lipovoy, ang aming koponan sa Sbertech ay nagsimulang gumamit ng HBase bilang isang imbakan para sa data ng pagpapatakbo. Sa kurso ng pag-aaral nito, ang karanasan ay naipon na nais kong i-systematize at ilarawan (umaasa kami na ito ay magiging kapaki-pakinabang sa marami). Ang lahat ng mga eksperimento sa ibaba ay isinagawa gamit ang mga bersyon ng HBase 1.2.0-cdh5.14.2 at 2.0.0-cdh6.0.0-beta1.

1. Pangkalahatang arkitektura
2. Pagsusulat ng data sa HBASE
3. Pagbabasa ng data mula sa HBASE
4. Pag-cache ng data
5. Batch data processing MultiGet/MultiPut
6. Diskarte para sa paghahati ng mga talahanayan sa mga rehiyon (paghahati)
7. Fault tolerance, compactification at data locality
8. Mga setting at pagganap
9. Pagsusuri ng Stress
10. Natuklasan

1. Pangkalahatang arkitektura

Ang backup na Master ay nakikinig sa tibok ng puso ng aktibo sa ZooKeeper node at, kung sakaling mawala, papalitan ang mga tungkulin ng master.

2. Sumulat ng data sa HBASE

Una, tingnan natin ang pinakasimpleng kaso - pagsusulat ng key-value object sa isang table gamit ang put(rowkey). Dapat munang malaman ng kliyente kung saan matatagpuan ang Root Region Server (RRS), na nag-iimbak ng hbase:meta table. Natanggap niya ang impormasyong ito mula sa ZooKeeper. Pagkatapos nito, ina-access nito ang RRS at binabasa ang hbase:meta table, kung saan kinukuha nito ang impormasyon tungkol sa kung aling RegionServer (RS) ang may pananagutan sa pag-imbak ng data para sa ibinigay na rowkey sa talahanayan ng interes. Para sa paggamit sa hinaharap, ang meta table ay naka-cache ng kliyente at samakatuwid ang mga kasunod na tawag ay mas mabilis, direkta sa RS.

Susunod, ang RS, na nakatanggap ng isang kahilingan, una sa lahat ay isinulat ito sa WriteAheadLog (WAL), na kinakailangan para sa pagbawi sa kaso ng isang pag-crash. Pagkatapos ay i-save ang data sa MemStore. Ito ay isang buffer sa memorya na naglalaman ng pinagsunod-sunod na hanay ng mga key para sa isang partikular na rehiyon. Ang isang talahanayan ay maaaring hatiin sa mga rehiyon (mga partisyon), na ang bawat isa ay naglalaman ng magkahiwalay na hanay ng mga susi. Nagbibigay-daan ito sa iyo na maglagay ng mga rehiyon sa iba't ibang mga server upang makamit ang mas mataas na pagganap. Gayunpaman, sa kabila ng pagiging malinaw ng pahayag na ito, makikita natin sa ibang pagkakataon na hindi ito gumagana sa lahat ng kaso.

Pagkatapos maglagay ng entry sa MemStore, ibabalik ang tugon sa kliyente na matagumpay na nai-save ang entry. Gayunpaman, sa katotohanan ito ay naka-imbak lamang sa isang buffer at nakakakuha lamang sa disk pagkatapos ng isang tiyak na tagal ng oras na lumipas o kapag ito ay napuno ng bagong data.

Kapag nagsasagawa ng operasyong "Tanggalin", ang data ay hindi pisikal na tinatanggal. Ang mga ito ay minarkahan lamang bilang tinanggal, at ang pagkasira mismo ay nangyayari sa sandali ng pagtawag sa pangunahing compact function, na inilalarawan nang mas detalyado sa talata 7.

Ang mga file sa format na HFile ay naipon sa HDFS at paminsan-minsan ay inilulunsad ang menor de edad na compact na proseso, na pinagsasama-sama lamang ang maliliit na file sa mas malalaking mga file nang hindi tinatanggal ang anuman. Sa paglipas ng panahon, nagiging problema ito na lumalabas lamang kapag nagbabasa ng data (babalikan natin ito sa ibang pagkakataon).

Bilang karagdagan sa proseso ng paglo-load na inilarawan sa itaas, mayroong isang mas epektibong pamamaraan, na marahil ang pinakamatibay na bahagi ng database na ito - BulkLoad. Ito ay nakasalalay sa katotohanan na tayo ay nakapag-iisa na bumubuo ng mga HFiles at inilalagay ang mga ito sa disk, na nagbibigay-daan sa amin upang perpektong sukat at makamit ang napaka disenteng bilis. Sa katunayan, ang limitasyon dito ay hindi HBase, ngunit ang mga kakayahan ng hardware. Nasa ibaba ang mga resulta ng boot sa isang cluster na binubuo ng 16 na RegionServer at 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 na mga thread), HBase bersyon 1.2.0-cdh5.14.2.

Dito makikita mo na sa pamamagitan ng pagtaas ng bilang ng mga partisyon (rehiyon) sa talahanayan, pati na rin ang mga tagapagpatupad ng Spark, nakakakuha tayo ng pagtaas sa bilis ng pag-download. Gayundin, ang bilis ay depende sa dami ng pag-record. Ang mga malalaking bloke ay nagbibigay ng pagtaas sa MB/seg, maliliit na bloke sa bilang ng mga naipasok na tala sa bawat yunit ng oras, lahat ng iba pang bagay ay pantay.

Maaari ka ring magsimulang mag-load sa dalawang talahanayan nang sabay at doblehin ang bilis. Sa ibaba makikita mo na ang pagsusulat ng 10 KB na mga bloke sa dalawang talahanayan nang sabay-sabay ay nangyayari sa bilis na humigit-kumulang 600 MB/sec sa bawat isa (kabuuang 1275 MB/sec), na tumutugma sa bilis ng pagsulat sa isang talahanayan na 623 MB/sec (tingnan ang No. 11 sa itaas)

Ngunit ang pangalawang pagtakbo na may mga tala na 50 KB ay nagpapakita na ang bilis ng pag-download ay bahagyang lumalaki, na nagpapahiwatig na ito ay papalapit na sa mga halaga ng limitasyon. Kasabay nito, kailangan mong tandaan na halos walang load na nalikha sa HBASE mismo, ang kailangan lang dito ay magbigay muna ng data mula sa hbase:meta, at pagkatapos maglinya ng HFiles, i-reset ang BlockCache data at i-save ang MemStore buffer sa disk, kung ito ay walang laman.

3. Pagbabasa ng data mula sa HBASE

Kung ipagpalagay namin na ang kliyente ay mayroon na ng lahat ng impormasyon mula sa hbase:meta (tingnan ang punto 2), ang kahilingan ay direktang mapupunta sa RS kung saan naka-imbak ang kinakailangang key. Una, ang paghahanap ay ginagawa sa MemCache. Hindi alintana kung mayroong data doon o wala, ang paghahanap ay isinasagawa din sa BlockCache buffer at, kung kinakailangan, sa HFiles. Kung ang data ay natagpuan sa file, ito ay inilalagay sa BlockCache at ibabalik nang mas mabilis sa susunod na kahilingan. Ang paghahanap sa HFile ay medyo mabilis salamat sa paggamit ng filter na Bloom, i.e. pagkakaroon ng pagbabasa ng isang maliit na halaga ng data, agad nitong tinutukoy kung ang file na ito ay naglalaman ng kinakailangang key at kung hindi, pagkatapos ay lumipat sa susunod.

Ang pagkakaroon ng natanggap na data mula sa tatlong mapagkukunang ito, ang RS ay bumubuo ng isang tugon. Sa partikular, maaari itong maglipat ng ilang nahanap na bersyon ng isang bagay nang sabay-sabay kung humiling ang kliyente ng bersyon.

4. Pag-cache ng data

Sinasakop ng MemStore at BlockCache buffer ang hanggang 80% ng inilalaan na on-heap RS memory (ang iba ay nakalaan para sa mga gawain sa serbisyo ng RS). Kung ang karaniwang mode ng paggamit ay tulad na ang mga proseso ay sumulat at agad na nagbabasa ng parehong data, kung gayon makatuwirang bawasan ang BlockCache at dagdagan ang MemStore, dahil Kapag ang pagsusulat ng data ay hindi nakapasok sa cache para sa pagbabasa, ang BlockCache ay hindi gaanong gagamitin. Ang BlockCache buffer ay binubuo ng dalawang bahagi: LruBlockCache (palaging on-heap) at BucketCache (karaniwang off-heap o sa isang SSD). Dapat gamitin ang BucketCache kapag maraming mga kahilingan sa pagbabasa at hindi umaangkop ang mga ito sa LruBlockCache, na humahantong sa aktibong gawain ng Garbage Collector. Kasabay nito, hindi mo dapat asahan ang isang radikal na pagtaas sa pagganap mula sa paggamit ng read cache, ngunit babalik kami dito sa talata 8

Mayroong isang BlockCache para sa buong RS, at mayroong isang MemStore para sa bawat talahanayan (isa para sa bawat Column Family).

Bilang inilarawan sa teorya, kapag nagsusulat, ang data ay hindi napupunta sa cache at sa katunayan, ang mga naturang parameter na CACHE_DATA_ON_WRITE para sa talahanayan at "Cache DATA on Write" para sa RS ay nakatakda sa false. Gayunpaman, sa pagsasagawa, kung sumulat kami ng data sa MemStore, pagkatapos ay i-flush ito sa disk (kaya i-clear ito), pagkatapos ay tanggalin ang resultang file, pagkatapos ay sa pamamagitan ng pagsasagawa ng isang kahilingan sa pagkuha ay matagumpay naming matatanggap ang data. Bukod dito, kahit na ganap mong hindi paganahin ang BlockCache at punan ang talahanayan ng bagong data, pagkatapos ay i-reset ang MemStore sa disk, tanggalin ang mga ito at hilingin ang mga ito mula sa isa pang session, kukunin pa rin sila mula sa isang lugar. Kaya ang HBase ay nag-iimbak hindi lamang ng data, kundi pati na rin ng mga misteryosong misteryo.

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

Ang parameter na "Cache DATA on Read" ay nakatakda sa false. Kung mayroon kang anumang mga ideya, malugod na talakayin ito sa mga komento.

5. Batch data processing MultiGet/MultiPut

Ang pagpoproseso ng mga solong kahilingan (Kunin/Ilagay/Tanggalin) ay medyo mahal na operasyon, kaya kung maaari, dapat mong pagsamahin ang mga ito sa isang Listahan o Listahan, na nagbibigay-daan sa iyong makakuha ng makabuluhang pagpapalakas ng pagganap. Ito ay totoo lalo na para sa pagpapatakbo ng pagsulat, ngunit kapag nagbabasa mayroong sumusunod na pitfall. Ipinapakita ng graph sa ibaba ang oras para magbasa ng 50 record mula sa MemStore. Ang pagbabasa ay isinagawa sa isang thread at ang pahalang na axis ay nagpapakita ng bilang ng mga susi sa kahilingan. Dito makikita mo na kapag tumataas sa isang libong mga susi sa isang kahilingan, bumababa ang oras ng pagpapatupad, i.e. tumataas ang bilis. Gayunpaman, kapag pinagana ang MSLAB mode bilang default, pagkatapos ng threshold na ito, magsisimula ang isang radikal na pagbaba sa pagganap, at kung mas malaki ang dami ng data sa talaan, mas mahaba ang oras ng pagpapatakbo.

Ang mga pagsubok ay isinagawa sa isang virtual machine, 8 core, bersyon HBase 2.0.0-cdh6.0.0-beta1.

Ang MSLAB mode ay idinisenyo upang bawasan ang heap fragmentation, na nangyayari dahil sa paghahalo ng bago at lumang data ng henerasyon. Bilang isang workaround, kapag pinagana ang MSLAB, ang data ay inilalagay sa medyo maliliit na cell (chunks) at pinoproseso sa chunks. Bilang resulta, kapag ang volume sa hiniling na data packet ay lumampas sa inilalaan na laki, ang pagganap ay bumaba nang husto. Sa kabilang banda, hindi rin ipinapayong i-off ang mode na ito, dahil hahantong ito sa mga paghinto dahil sa GC sa mga sandali ng masinsinang pagproseso ng data. Ang isang mahusay na solusyon ay upang madagdagan ang dami ng cell sa kaso ng aktibong pagsulat sa pamamagitan ng ilagay sa parehong oras ng pagbabasa. Ito ay nagkakahalaga ng pagpuna na ang problema ay hindi mangyayari kung, pagkatapos ng pag-record, patakbuhin mo ang flush command, na nagre-reset sa MemStore sa disk, o kung nag-load ka gamit ang BulkLoad. Ipinapakita ng talahanayan sa ibaba na ang mga query mula sa MemStore para sa mas malaki (at parehong halaga) na data ay nagreresulta sa mga pagbagal. Gayunpaman, sa pamamagitan ng pagtaas ng chunksize ibinabalik namin ang oras ng pagproseso sa normal.

Bilang karagdagan sa pagtaas ng chunksize, nakakatulong ang paghahati ng data ayon sa rehiyon, i.e. paghahati ng mesa. Nagreresulta ito sa mas kaunting mga kahilingan na dumarating sa bawat rehiyon at kung magkasya ang mga ito sa isang cell, mananatiling maganda ang tugon.

6. Diskarte para sa paghahati ng mga talahanayan sa mga rehiyon (paghahati)

Dahil ang HBase ay isang key-value storage at ang partitioning ay isinasagawa sa pamamagitan ng key, napakahalaga na hatiin ang data nang pantay-pantay sa lahat ng rehiyon. Halimbawa, ang paghahati ng naturang talahanayan sa tatlong bahagi ay magreresulta sa paghahati ng data sa tatlong rehiyon:

Nangyayari na humahantong ito sa isang matinding paghina kung ang data na na-load sa ibang pagkakataon ay mukhang, halimbawa, mahahabang halaga, karamihan sa mga ito ay nagsisimula sa parehong digit, halimbawa:

1000001
1000002
...
1100003

Dahil ang mga susi ay naka-imbak bilang isang byte array, lahat sila ay magsisimula nang pareho at nabibilang sa parehong rehiyon #1 na nag-iimbak ng hanay ng mga key na ito. Mayroong ilang mga diskarte sa paghahati:

HexStringSplit – Ginagawa ang key sa isang hexadecimal na naka-encode na string sa hanay na "00000000" => "FFFFFFFF" at padding sa kaliwa na may mga zero.

UniformSplit – Ginagawang byte array ang key na may hexadecimal encoding sa hanay na "00" => "FF" at padding sa kanan na may mga zero.

Bilang karagdagan, maaari mong tukuyin ang anumang hanay o hanay ng mga key para sa paghahati at pag-configure ng auto-splitting. Gayunpaman, ang isa sa pinakasimple at pinakaepektibong diskarte ay ang UniformSplit at ang paggamit ng hash concatenation, halimbawa ang pinaka makabuluhang pares ng byte mula sa pagpapatakbo ng key sa pamamagitan ng CRC32(rowkey) function at ang rowkey mismo:

hash + rowkey

Pagkatapos ang lahat ng data ay ipapamahagi nang pantay-pantay sa mga rehiyon. Kapag nagbabasa, ang unang dalawang byte ay itatapon lamang at mananatili ang orihinal na susi. Kinokontrol din ng RS ang dami ng data at mga susi sa rehiyon at, kung lumampas ang mga limitasyon, awtomatikong hatiin ito sa mga bahagi.

7. Fault tolerance at lokalidad ng data

Dahil isang rehiyon lamang ang may pananagutan para sa bawat hanay ng mga susi, ang solusyon sa mga problemang nauugnay sa mga pag-crash o pag-decommission ng RS ay ang pag-imbak ng lahat ng kinakailangang data sa HDFS. Kapag bumagsak ang RS, nade-detect ito ng master sa pamamagitan ng kawalan ng heartbeat sa ZooKeeper node. Pagkatapos ay itinalaga nito ang pinaglilingkuran na rehiyon sa isa pang RS at dahil ang mga HFiles ay naka-imbak sa isang distributed file system, binabasa sila ng bagong may-ari at patuloy na naghahatid ng data. Gayunpaman, dahil ang ilan sa mga data ay maaaring nasa MemStore at walang oras upang makapasok sa HFiles, ang WAL, na nakaimbak din sa HDFS, ay ginagamit upang ibalik ang kasaysayan ng mga operasyon. Matapos mailapat ang mga pagbabago, makakatugon ang RS sa mga kahilingan, ngunit ang paglipat ay humahantong sa katotohanan na ang ilan sa mga data at ang mga prosesong nagseserbisyo sa kanila ay napupunta sa iba't ibang mga node, i.e. ang lokalidad ay bumababa.

Ang solusyon sa problema ay pangunahing compaction - ang pamamaraang ito ay naglilipat ng mga file sa mga node na responsable para sa kanila (kung saan matatagpuan ang kanilang mga rehiyon), bilang isang resulta kung saan sa panahon ng pamamaraang ito ang pag-load sa network at mga disk ay tumataas nang husto. Gayunpaman, sa hinaharap, ang pag-access sa data ay kapansin-pansing pinabilis. Bilang karagdagan, ang major_compaction ay nagsasagawa ng pagsasama-sama ng lahat ng HFiles sa isang file sa loob ng isang rehiyon, at nililinis din ang data depende sa mga setting ng talahanayan. Halimbawa, maaari mong tukuyin ang bilang ng mga bersyon ng isang bagay na dapat panatilihin o ang habambuhay pagkatapos kung saan ang bagay ay pisikal na tinanggal.

Ang pamamaraang ito ay maaaring magkaroon ng napakapositibong epekto sa pagpapatakbo ng HBase. Ipinapakita ng larawan sa ibaba kung paano bumaba ang pagganap bilang resulta ng aktibong pag-record ng data. Dito makikita mo kung paano sumulat ang 40 thread sa isang table at 40 thread nang sabay-sabay na nagbasa ng data. Ang pagsusulat ng mga thread ay bumubuo ng higit pang mga HFile, na binabasa ng iba pang mga thread. Bilang resulta, parami nang parami ang data na kailangang alisin sa memorya at sa kalaunan ay nagsimulang gumana ang GC, na halos nakakaparalisa sa lahat ng trabaho. Ang paglulunsad ng major compaction ay humantong sa paglilinis ng mga nagresultang debris at pagpapanumbalik ng produktibidad.

Ang pagsubok ay isinagawa sa 3 DataNodes at 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 na mga thread). HBase bersyon 1.2.0-cdh5.14.2

Kapansin-pansin na ang pangunahing compaction ay inilunsad sa isang "live" na talahanayan, kung saan ang data ay aktibong isinulat at binasa. May isang pahayag online na maaari itong humantong sa isang maling tugon kapag nagbabasa ng data. Upang suriin, isang proseso ang inilunsad na nakabuo ng bagong data at isinulat ito sa isang talahanayan. Pagkatapos nito ay agad kong binasa at sinuri kung ang resultang halaga ay kasabay ng nakasulat. Habang tumatakbo ang prosesong ito, ang major compaction ay pinatakbo nang humigit-kumulang 200 beses at walang isang pagkabigo ang naitala. Marahil ay madalang na lumilitaw ang problema at sa panahon lamang ng mataas na pagkarga, kaya mas ligtas na ihinto ang mga proseso ng pagsulat at pagbabasa gaya ng binalak at magsagawa ng paglilinis upang maiwasan ang mga naturang GC drawdown.

Gayundin, hindi naaapektuhan ng major compaction ang estado ng MemStore; para i-flush ito sa disk at i-compactify ito, kailangan mong gumamit ng flush (connection.getAdmin().flush(TableName.valueOf(tblName))).

8. Mga setting at pagganap

Gaya ng nabanggit na, ipinapakita ng HBase ang pinakamalaking tagumpay nito kung saan hindi nito kailangang gawin, kapag nagsasagawa ng BulkLoad. Gayunpaman, nalalapat ito sa karamihan ng mga sistema at tao. Gayunpaman, ang tool na ito ay mas angkop para sa pag-iimbak ng data nang maramihan sa malalaking bloke, samantalang kung ang proseso ay nangangailangan ng maraming nakikipagkumpitensyang kahilingan sa pagbasa at pagsulat, ang mga utos na Kumuha at Put na inilarawan sa itaas ay ginagamit. Upang matukoy ang pinakamainam na mga parameter, ang mga paglulunsad ay isinagawa na may iba't ibang mga kumbinasyon ng mga parameter at setting ng talahanayan:

• 10 mga thread ang sabay-sabay na inilunsad 3 beses sa isang hilera (tawagin natin itong isang bloke ng mga thread).
• Ang oras ng pagpapatakbo ng lahat ng mga thread sa isang bloke ay na-average at ang huling resulta ng pagpapatakbo ng bloke.
• Ang lahat ng mga thread ay gumana sa parehong talahanayan.
• Bago ang bawat pagsisimula ng thread block, isang malaking compaction ang isinagawa.
• Ang bawat bloke ay nagsagawa lamang ng isa sa mga sumusunod na operasyon:

—Ilagay
—Kunin
—Kumuha+Ilagay

• Ang bawat bloke ay nagsagawa ng 50 pag-ulit ng operasyon nito.
• Ang block size ng isang record ay 100 bytes, 1000 bytes o 10000 bytes (random).
• Ang mga bloke ay inilunsad na may iba't ibang bilang ng mga hiniling na susi (alinman sa isang susi o 10).
• Ang mga bloke ay pinatakbo sa ilalim ng iba't ibang mga setting ng talahanayan. Binago ang mga parameter:

— BlockCache = naka-on o naka-off
— BlockSize = 65 KB o 16 KB
— Mga partisyon = 1, 5 o 30
— MSLAB = pinagana o hindi pinagana

Kaya ang block ay ganito ang hitsura:

a. Na-on/off ang MSLAB mode.
b. Isang talahanayan ang ginawa kung saan itinakda ang mga sumusunod na parameter: BlockCache = true/none, BlockSize = 65/16 Kb, Partition = 1/5/30.
c. Itinakda ang compression sa GZ.
d. 10 thread ang sabay-sabay na inilunsad ang 1/10 put/get/get+put operations sa table na ito na may mga record na 100/1000/10000 bytes, na gumaganap ng 50 query sa isang row (random keys).
e. Ang point d ay inulit ng tatlong beses.
f. Ang oras ng pagpapatakbo ng lahat ng mga thread ay na-average.

Sinuri ang lahat ng posibleng kumbinasyon. Mahuhulaan na ang bilis ay bababa habang tumataas ang laki ng tala, o ang hindi pagpapagana ng caching ay magdudulot ng pagbagal. Gayunpaman, ang layunin ay upang maunawaan ang antas at kahalagahan ng impluwensya ng bawat parameter, kaya ang nakolektang data ay ipinakain sa input ng isang linear regression function, na ginagawang posible upang masuri ang kahalagahan gamit ang t-statistics. Nasa ibaba ang mga resulta ng mga bloke na nagsasagawa ng mga operasyon ng Put. Buong hanay ng mga kumbinasyon 2*2*3*2*3 = 144 na opsyon + 72 tk. ang ilan ay ginawa nang dalawang beses. Samakatuwid, mayroong 216 na pagtakbo sa kabuuan:

Isinagawa ang pagsubok sa isang mini-cluster na binubuo ng 3 DataNodes at 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 na mga thread). HBase bersyon 1.2.0-cdh5.14.2.

Ang pinakamataas na bilis ng pagpasok na 3.7 segundo ay nakuha sa MSLAB mode na naka-off, sa isang mesa na may isang partition, na pinagana ang BlockCache, BlockSize = 16, mga talaan ng 100 bytes, 10 piraso bawat pack.
Ang pinakamababang bilis ng pagpasok na 82.8 sec ay nakuha sa MSLAB mode na pinagana, sa isang table na may isang partition, na pinagana ang BlockCache, BlockSize = 16, mga talaan ng 10000 bytes, 1 bawat isa.

Ngayon tingnan natin ang modelo. Nakikita namin ang magandang kalidad ng modelo batay sa R2, ngunit ganap na malinaw na ang extrapolation ay kontraindikado dito. Ang aktwal na pag-uugali ng system kapag nagbabago ang mga parameter ay hindi magiging linear; ang modelong ito ay kailangan hindi para sa mga hula, ngunit para sa pag-unawa kung ano ang nangyari sa loob ng ibinigay na mga parameter. Halimbawa, dito nakikita natin mula sa pamantayan ng Mag-aaral na ang BlockSize at BlockCache na mga parameter ay hindi mahalaga para sa operasyon ng Put (na sa pangkalahatan ay medyo predictable):

Ngunit ang katotohanan na ang pagtaas ng bilang ng mga partisyon ay humahantong sa pagbaba sa pagganap ay medyo hindi inaasahan (nakita na natin ang positibong epekto ng pagtaas ng bilang ng mga partisyon na may BulkLoad), bagaman naiintindihan. Una, para sa pagpoproseso, kailangan mong bumuo ng mga kahilingan sa 30 rehiyon sa halip na isa, at ang dami ng data ay hindi ganoong magbubunga ito ng pakinabang. Pangalawa, ang kabuuang oras ng pagpapatakbo ay tinutukoy ng pinakamabagal na RS, at dahil ang bilang ng DataNodes ay mas mababa sa bilang ng mga RS, ang ilang mga rehiyon ay may zero na lokalidad. Well, tingnan natin ang nangungunang limang:

Ngayon suriin natin ang mga resulta ng pagsasagawa ng Get blocks:

Ang bilang ng mga partisyon ay nawalan ng kabuluhan, na marahil ay ipinaliwanag sa pamamagitan ng katotohanan na ang data ay naka-cache nang maayos at ang read cache ay ang pinaka makabuluhang (statistikong) parameter. Naturally, ang pagtaas ng bilang ng mga mensahe sa isang kahilingan ay lubhang kapaki-pakinabang para sa pagganap. Mga nangungunang marka:

Well, sa wakas, tingnan natin ang modelo ng block na unang gumanap na get at pagkatapos ay ilagay:

Ang lahat ng mga parameter ay makabuluhan dito. At ang mga resulta ng mga pinuno:

9. Pagsubok sa pag-load

Well, sa wakas ay maglulunsad kami ng higit pa o hindi gaanong disenteng pagkarga, ngunit palaging mas kawili-wili kapag mayroon kang maihahambing. Sa website ng DataStax, ang pangunahing developer ng Cassandra, mayroon ang mga resulta NT ng isang bilang ng mga storage ng NoSQL, kabilang ang bersyon ng HBase 0.98.6-1. Ang paglo-load ay isinagawa ng 40 mga thread, laki ng data 100 bytes, SSD disks. Ang resulta ng pagsubok sa mga operasyong Read-Modify-Write ay nagpakita ng mga sumusunod na resulta.

Sa pagkakaintindi ko, ang pagbabasa ay isinagawa sa mga bloke ng 100 na talaan at para sa 16 na HBase node, ang pagsubok ng DataStax ay nagpakita ng pagganap ng 10 libong mga operasyon bawat segundo.

Mapalad na ang aming cluster ay mayroon ding 16 na node, ngunit hindi masyadong "masuwerte" na ang bawat isa ay may 64 na mga core (mga thread), habang sa pagsubok ng DataStax ay mayroon lamang 4. Sa kabilang banda, mayroon silang mga SSD drive, habang kami ay may mga HDD. o higit pa ang bagong bersyon ng HBase at paggamit ng CPU sa panahon ng pag-load ay halos hindi tumaas nang malaki (biswal ng 5-10 porsyento). Gayunpaman, subukan nating simulan ang paggamit ng pagsasaayos na ito. Default na mga setting ng talahanayan, ang pagbabasa ay isinasagawa sa key range mula 0 hanggang 50 milyon nang random (ibig sabihin, mahalagang bago sa bawat oras). Ang talahanayan ay naglalaman ng 50 milyong mga talaan, na nahahati sa 64 na mga partisyon. Ang mga susi ay na-hash gamit ang crc32. Ang mga setting ng talahanayan ay default, ang MSLAB ay pinagana. Sa paglulunsad ng 40 thread, ang bawat thread ay nagbabasa ng set ng 100 random na key at agad na nagsusulat ng nabuong 100 byte pabalik sa mga key na ito.

Stand: 16 DataNode at 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 na mga thread). HBase bersyon 1.2.0-cdh5.14.2.

Ang average na resulta ay mas malapit sa 40 libong mga operasyon sa bawat segundo, na mas mahusay kaysa sa pagsubok ng DataStax. Gayunpaman, para sa mga layuning pang-eksperimento, maaari mong bahagyang baguhin ang mga kundisyon. Ito ay medyo hindi malamang na ang lahat ng trabaho ay isasagawa ng eksklusibo sa isang talahanayan, at din lamang sa mga natatanging susi. Ipagpalagay natin na mayroong isang tiyak na "mainit" na hanay ng mga susi na bumubuo ng pangunahing pagkarga. Samakatuwid, subukan nating lumikha ng isang load na may mas malalaking talaan (10 KB), gayundin sa mga batch na 100, sa 4 na magkakaibang talahanayan at nililimitahan ang hanay ng mga hiniling na key sa 50 libo. Ang graph sa ibaba ay nagpapakita ng paglulunsad ng 40 na mga thread, ang bawat thread ay nagbabasa isang set ng 100 key at agad na nagsusulat ng random na 10 KB sa mga key na ito pabalik.

Stand: 16 DataNode at 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 na mga thread). HBase bersyon 1.2.0-cdh5.14.2.

Sa panahon ng pag-load, ang pangunahing compaction ay inilunsad nang maraming beses, tulad ng ipinapakita sa itaas, nang walang pamamaraang ito, ang pagganap ay unti-unting bumababa, gayunpaman, ang karagdagang pagkarga ay lumitaw din sa panahon ng pagpapatupad. Ang mga drawdown ay sanhi ng iba't ibang dahilan. Minsan tapos nang gumana ang mga thread at nagkaroon ng pause habang nire-restart ang mga ito, minsan ang mga third-party na application ay gumawa ng load sa cluster.

Ang pagbabasa at pagsusulat kaagad ay isa sa pinakamahirap na sitwasyon sa trabaho para sa HBase. Kung gagawa ka lamang ng maliliit na kahilingan sa paglalagay, halimbawa 100 bytes, pagsasama-sama ng mga ito sa mga pakete ng 10-50 libong piraso, maaari kang makakuha ng daan-daang libong operasyon bawat segundo, at ang sitwasyon ay katulad ng mga read-only na kahilingan. Kapansin-pansin na ang mga resulta ay mas mahusay kaysa sa nakuha ng DataStax, higit sa lahat dahil sa mga kahilingan sa mga bloke ng 50 libo.

Stand: 16 DataNode at 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 na mga thread). HBase bersyon 1.2.0-cdh5.14.2.

10. Konklusyon

Ang sistemang ito ay medyo nababagay na na-configure, ngunit ang impluwensya ng isang malaking bilang ng mga parameter ay nananatiling hindi alam. Ang ilan sa kanila ay nasubok, ngunit hindi kasama sa resultang set ng pagsubok. Halimbawa, ang mga paunang eksperimento ay nagpakita ng hindi gaanong kahalagahan ng naturang parameter bilang DATA_BLOCK_ENCODING, na nag-e-encode ng impormasyon gamit ang mga halaga ​​mula sa mga kalapit na cell, na nauunawaan para sa random na nabuong data. Kung gumamit ka ng isang malaking bilang ng mga duplicate na bagay, ang pakinabang ay maaaring maging makabuluhan. Sa pangkalahatan, maaari nating sabihin na ang HBase ay nagbibigay ng impresyon ng isang medyo seryoso at pinag-isipang mabuti na database, na maaaring maging produktibo kapag nagsasagawa ng mga operasyon na may malalaking bloke ng data. Lalo na kung posibleng paghiwalayin ang proseso ng pagbasa at pagsulat sa oras.

Kung mayroong isang bagay sa iyong opinyon na hindi sapat na isiwalat, handa akong sabihin sa iyo nang mas detalyado. Inaanyayahan ka naming ibahagi ang iyong karanasan o talakayin kung hindi ka sumasang-ayon sa isang bagay.

Pinagmulan: www.habr.com