HBase નો ઉપયોગ કરવાનો સિદ્ધાંત અને પ્રેક્ટિસ

શુભ બપોર મારું નામ ડેનિલ લિપોવોય છે, Sbertech ખાતેની અમારી ટીમે ઓપરેશનલ ડેટા માટે HBase નો ઉપયોગ કરવાનું શરૂ કર્યું. તેના અભ્યાસ દરમિયાન, અનુભવ સંચિત થયો છે કે હું વ્યવસ્થિત અને વર્ણન કરવા માંગતો હતો (અમે આશા રાખીએ છીએ કે તે ઘણાને ઉપયોગી થશે). નીચેના બધા પ્રયોગો HBase વર્ઝન 1.2.0-cdh5.14.2 અને 2.0.0-cdh6.0.0-beta1 સાથે કરવામાં આવ્યા હતા.

1. સામાન્ય આર્કિટેક્ચર
2. HBASE ને ડેટા લખી રહ્યા છીએ
3. HBASE માંથી ડેટા વાંચી રહ્યા છે
4. ડેટા કેશીંગ
5. બેચ ડેટા પ્રોસેસિંગ મલ્ટિગેટ/મલ્ટીપુટ
6. કોષ્ટકોને પ્રદેશોમાં વિભાજીત કરવા માટેની વ્યૂહરચના (વિભાજન)
7. ફોલ્ટ ટોલરન્સ, કોમ્પેક્ટિફિકેશન અને ડેટા લોકેલિટી
8. સેટિંગ્સ અને પ્રદર્શન
9. તણાવ પરીક્ષણ
10. તારણો

1. સામાન્ય આર્કિટેક્ચર

બેકઅપ માસ્ટર ZooKeeper નોડ પર સક્રિય વ્યક્તિના ધબકારા સાંભળે છે અને ગાયબ થવાના કિસ્સામાં, માસ્ટરના કાર્યોને સંભાળે છે.

2. HBASE ને ડેટા લખો

પ્રથમ, ચાલો સૌથી સરળ કેસ જોઈએ - put(rowkey) નો ઉપયોગ કરીને ટેબલ પર કી-વેલ્યુ ઑબ્જેક્ટ લખવું. ક્લાયન્ટે પહેલા એ શોધવાનું રહેશે કે રૂટ રીજન સર્વર (RRS), જે hbase:meta ટેબલનો સંગ્રહ કરે છે, તે ક્યાં સ્થિત છે. તેને આ માહિતી ZooKeeper પાસેથી મળે છે. જે પછી તે RRS ને ઍક્સેસ કરે છે અને hbase:meta ટેબલ વાંચે છે, જેમાંથી તે માહિતી મેળવે છે કે કયા RegionServer (RS) રસના કોષ્ટકમાં આપેલ રો-કી માટે ડેટા સ્ટોર કરવા માટે જવાબદાર છે. ભવિષ્યના ઉપયોગ માટે, મેટા ટેબલ ક્લાયન્ટ દ્વારા કેશ કરવામાં આવે છે અને તેથી અનુગામી કૉલ્સ ઝડપથી RS પર જાય છે.

આગળ, RS, વિનંતી પ્રાપ્ત કર્યા પછી, સૌ પ્રથમ તેને WriteAheadLog (WAL) પર લખે છે, જે ક્રેશના કિસ્સામાં પુનઃપ્રાપ્તિ માટે જરૂરી છે. પછી ડેટા મેમસ્ટોરમાં સેવ કરે છે. આ મેમરીમાં એક બફર છે જે આપેલ પ્રદેશ માટે ચાવીઓનો સૉર્ટ કરેલ સેટ ધરાવે છે. કોષ્ટકને પ્રદેશો (પાર્ટીશનો) માં વિભાજિત કરી શકાય છે, જેમાંના દરેકમાં કીનો અલગ-અલગ સમૂહ હોય છે. આ તમને ઉચ્ચ પ્રદર્શન પ્રાપ્ત કરવા માટે વિવિધ સર્વર પર પ્રદેશો મૂકવાની મંજૂરી આપે છે. જો કે, આ નિવેદનની સ્પષ્ટતા હોવા છતાં, અમે પછીથી જોઈશું કે આ તમામ કેસોમાં કામ કરતું નથી.

મેમસ્ટોરમાં એન્ટ્રી મૂક્યા પછી, ક્લાયન્ટને જવાબ આપવામાં આવે છે કે એન્ટ્રી સફળતાપૂર્વક સાચવવામાં આવી હતી. જો કે, વાસ્તવમાં તે ફક્ત બફરમાં જ સંગ્રહિત થાય છે અને ચોક્કસ સમય પસાર થયા પછી અથવા જ્યારે તે નવા ડેટાથી ભરાય ત્યારે જ ડિસ્ક પર આવે છે.

"કાઢી નાખો" ઓપરેશન કરતી વખતે, ડેટા ભૌતિક રીતે કાઢી નાખવામાં આવતો નથી. તેઓ ફક્ત કાઢી નાખેલ તરીકે ચિહ્નિત થયેલ છે, અને વિનાશ પોતે મુખ્ય કોમ્પેક્ટ કાર્યને કૉલ કરવાની ક્ષણે થાય છે, જે ફકરા 7 માં વધુ વિગતવાર વર્ણવેલ છે.

HFile ફોર્મેટમાંની ફાઇલો HDFSમાં સંચિત થાય છે અને સમયાંતરે નાની કોમ્પેક્ટ પ્રક્રિયા શરૂ કરવામાં આવે છે, જે કંઈપણ કાઢી નાખ્યા વિના નાની ફાઇલોને મોટી ફાઇલોમાં મર્જ કરે છે. સમય જતાં, આ એક સમસ્યામાં ફેરવાય છે જે ફક્ત ડેટા વાંચતી વખતે જ દેખાય છે (અમે થોડી વાર પછી આ પર પાછા આવીશું).

ઉપર વર્ણવેલ લોડિંગ પ્રક્રિયા ઉપરાંત, એક વધુ અસરકારક પ્રક્રિયા છે, જે કદાચ આ ડેટાબેઝની સૌથી મજબૂત બાજુ છે - બલ્કલોડ. તે એ હકીકતમાં રહેલું છે કે અમે સ્વતંત્ર રીતે HFiles બનાવીએ છીએ અને તેમને ડિસ્ક પર મૂકીએ છીએ, જે અમને સંપૂર્ણ રીતે સ્કેલ કરવાની અને ખૂબ જ યોગ્ય ઝડપ પ્રાપ્ત કરવાની મંજૂરી આપે છે. હકીકતમાં, અહીં મર્યાદા HBase નથી, પરંતુ હાર્ડવેરની ક્ષમતાઓ છે. નીચે 16 RegionServers અને 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 થ્રેડ્સ), HBase સંસ્કરણ 1.2.0-cdh5.14.2 ધરાવતા ક્લસ્ટર પરના બૂટ પરિણામો છે.

અહીં તમે જોઈ શકો છો કે કોષ્ટકમાં પાર્ટીશનો (પ્રદેશો) ની સંખ્યામાં વધારો કરીને, તેમજ સ્પાર્ક એક્ઝિક્યુટર્સ, અમને ડાઉનલોડ ઝડપમાં વધારો થાય છે. ઉપરાંત, ઝડપ રેકોર્ડિંગ વોલ્યુમ પર આધાર રાખે છે. મોટા બ્લોક્સ એમબી/સેકંડમાં વધારો આપે છે, સમયના એકમ દીઠ દાખલ કરેલા રેકોર્ડ્સની સંખ્યામાં નાના બ્લોક્સ, અન્ય તમામ વસ્તુઓ સમાન છે.

તમે એક જ સમયે બે કોષ્ટકોમાં લોડ કરવાનું શરૂ કરી શકો છો અને બમણી ઝડપ મેળવી શકો છો. નીચે તમે જોઈ શકો છો કે બે કોષ્ટકો પર એક સાથે 10 KB બ્લોક લખવાનું દરેકમાં લગભગ 600 MB/sec (કુલ 1275 MB/sec) ની ઝડપે થાય છે, જે એક ટેબલ પર લખવાની ઝડપ 623 MB/sec (જુઓ. ઉપર નંબર 11)

પરંતુ 50 KB ના રેકોર્ડ સાથેનો બીજો રન બતાવે છે કે ડાઉનલોડની ઝડપ થોડી વધી રહી છે, જે દર્શાવે છે કે તે મર્યાદાના મૂલ્યોની નજીક આવી રહી છે. તે જ સમયે, તમારે ધ્યાનમાં રાખવાની જરૂર છે કે HBASE પર જ વ્યવહારીક રીતે કોઈ લોડ બનાવવામાં આવ્યો નથી, તેના માટે જે જરૂરી છે તે પહેલા hbase:meta માંથી ડેટા આપવાનું છે, અને HFiles લાઇનિંગ કર્યા પછી, BlockCache ડેટા રીસેટ કરો અને સાચવો. ડિસ્ક પર મેમસ્ટોર બફર, જો તે ખાલી ન હોય.

3. HBASE માંથી ડેટા વાંચવું

જો આપણે ધારીએ કે ક્લાયન્ટ પાસે પહેલેથી જ hbase:meta (બિંદુ 2 જુઓ) માંથી બધી માહિતી છે, તો વિનંતી સીધી RS પર જાય છે જ્યાં જરૂરી કી સંગ્રહિત છે. પ્રથમ, શોધ MemCache માં કરવામાં આવે છે. ત્યાં ડેટા છે કે નહીં તે ધ્યાનમાં લીધા વિના, બ્લોકકેચ બફરમાં અને જો જરૂરી હોય તો, HFiles માં પણ શોધ હાથ ધરવામાં આવે છે. જો ફાઇલમાં ડેટા મળી આવ્યો હોય, તો તે BlockCache માં મૂકવામાં આવે છે અને આગલી વિનંતી પર ઝડપથી પરત કરવામાં આવશે. બ્લૂમ ફિલ્ટરના ઉપયોગને કારણે HFile માં શોધ કરવી પ્રમાણમાં ઝડપી છે, એટલે કે. થોડી માત્રામાં ડેટા વાંચ્યા પછી, તે તરત જ નિર્ધારિત કરે છે કે આ ફાઇલમાં જરૂરી કી છે કે કેમ અને જો નહીં, તો પછીની એક પર આગળ વધે છે.

આ ત્રણ સ્ત્રોતોમાંથી ડેટા પ્રાપ્ત કર્યા પછી, RS પ્રતિભાવ જનરેટ કરે છે. ખાસ કરીને, જો ક્લાયંટ વર્ઝનિંગની વિનંતી કરે તો તે ઑબ્જેક્ટના અનેક મળેલા વર્ઝનને એકસાથે ટ્રાન્સફર કરી શકે છે.

4. ડેટા કેશીંગ

MemStore અને BlockCache બફર્સ ફાળવેલ ઓન-હીપ RS મેમરીના 80% સુધી કબજો કરે છે (બાકીની RS સેવા કાર્યો માટે આરક્ષિત છે). જો સામાન્ય વપરાશ મોડ એવી હોય કે જે પ્રક્રિયાઓ લખે છે અને તરત જ સમાન ડેટા વાંચે છે, તો બ્લોકકેશ ઘટાડવા અને મેમસ્ટોર વધારવાનો અર્થપૂર્ણ છે, કારણ કે જ્યારે લેખન ડેટા વાંચવા માટે કેશમાં આવતો નથી, ત્યારે બ્લોકકેચનો ઉપયોગ ઓછો વાર કરવામાં આવશે. BlockCache બફર બે ભાગો ધરાવે છે: LruBlockCache (હંમેશા ઓન-હીપ) અને BucketCache (સામાન્ય રીતે ઓફ-હીપ અથવા SSD પર). જ્યારે ઘણી બધી વાંચન વિનંતીઓ હોય અને તે LruBlockCache માં બંધબેસતી ન હોય ત્યારે BucketCache નો ઉપયોગ કરવો જોઈએ, જે ગાર્બેજ કલેક્ટરનું સક્રિય કાર્ય તરફ દોરી જાય છે. તે જ સમયે, તમારે રીડ કેશનો ઉપયોગ કરવાથી પ્રભાવમાં ધરમૂળથી વધારાની અપેક્ષા રાખવી જોઈએ નહીં, પરંતુ અમે ફકરા 8 માં આ પર પાછા આવીશું.

સમગ્ર RS માટે એક BlockCache છે, અને દરેક ટેબલ માટે એક MemStore છે (દરેક કૉલમ ફેમિલી માટે એક).

કેવી રીતે વર્ણવેલ સિદ્ધાંતમાં, લખતી વખતે, ડેટા કેશમાં જતો નથી અને ખરેખર, ટેબલ માટે આવા પરિમાણો CACHE_DATA_ON_WRITE અને RS માટે "કેશ ડેટા ઓન રાઈટ" ખોટા પર સેટ છે. જો કે, વ્યવહારમાં, જો આપણે મેમસ્ટોર પર ડેટા લખીએ, પછી તેને ડિસ્ક પર ફ્લશ કરીએ (આમ તેને સાફ કરીએ), પછી પરિણામી ફાઇલને કાઢી નાખીએ, પછી ગેટ રિક્વેસ્ટને એક્ઝિક્યુટ કરીને સફળતાપૂર્વક ડેટા પ્રાપ્ત કરીશું. તદુપરાંત, જો તમે BlockCache ને સંપૂર્ણપણે અક્ષમ કરો અને નવા ડેટા સાથે કોષ્ટક ભરો, તો પણ MemStore ને ડિસ્ક પર રીસેટ કરો, તેમને કાઢી નાખો અને તેમને બીજા સત્રમાંથી વિનંતી કરો, તો પણ તે ક્યાંકથી પુનઃપ્રાપ્ત થશે. તેથી HBase માત્ર ડેટા જ નહીં, પણ રહસ્યમય રહસ્યો પણ સંગ્રહિત કરે છે.

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

"વાંચવા પર કેશ ડેટા" પેરામીટર ખોટા પર સેટ કરેલ છે. જો તમારી પાસે કોઈ વિચારો હોય, તો ટિપ્પણીઓમાં તેની ચર્ચા કરવા માટે આપનું સ્વાગત છે.

5. બેચ ડેટા પ્રોસેસિંગ મલ્ટિગેટ/મલ્ટીપુટ

સિંગલ વિનંતીઓ પર પ્રક્રિયા કરવી (ગેટ/પુટ/ડિલીટ) ખૂબ ખર્ચાળ ઑપરેશન છે, તેથી જો શક્ય હોય તો, તમારે તેમને સૂચિ અથવા સૂચિમાં જોડવું જોઈએ, જે તમને નોંધપાત્ર કામગીરી બૂસ્ટ મેળવવા માટે પરવાનગી આપે છે. આ લખવાની કામગીરી માટે ખાસ કરીને સાચું છે, પરંતુ વાંચતી વખતે નીચેની ખામી છે. નીચેનો ગ્રાફ મેમસ્ટોરમાંથી 50 રેકોર્ડ્સ વાંચવાનો સમય દર્શાવે છે. વાંચન એક થ્રેડમાં કરવામાં આવ્યું હતું અને આડી અક્ષ વિનંતીમાં કીની સંખ્યા દર્શાવે છે. અહીં તમે જોઈ શકો છો કે જ્યારે એક વિનંતીમાં હજાર કી સુધી વધારો થાય છે, ત્યારે એક્ઝેક્યુશનનો સમય ઘટી જાય છે, એટલે કે. ઝડપ વધે છે. જો કે, ડિફૉલ્ટ રૂપે MSLAB મોડ સક્ષમ હોવા સાથે, આ થ્રેશોલ્ડ પછી કામગીરીમાં ધરમૂળથી ઘટાડો શરૂ થાય છે, અને રેકોર્ડમાં ડેટાનો જથ્થો જેટલો મોટો હશે, તેટલો ઓપરેટિંગ સમય લાંબો હશે.

વર્ચ્યુઅલ મશીન, 8 કોરો, સંસ્કરણ HBase 2.0.0-cdh6.0.0-beta1 પર પરીક્ષણો કરવામાં આવ્યા હતા.

MSLAB મોડની રચના હીપ ફ્રેગમેન્ટેશનને ઘટાડવા માટે કરવામાં આવી છે, જે નવી અને જૂની પેઢીના ડેટાના મિશ્રણને કારણે થાય છે. વર્કઅરાઉન્ડ તરીકે, જ્યારે MSLAB સક્ષમ હોય છે, ત્યારે ડેટાને પ્રમાણમાં નાના કોષો (ચંક્સ) માં મૂકવામાં આવે છે અને ટુકડાઓમાં પ્રક્રિયા કરવામાં આવે છે. પરિણામે, જ્યારે વિનંતી કરેલ ડેટા પેકેટમાં વોલ્યુમ ફાળવેલ કદ કરતાં વધી જાય છે, ત્યારે કામગીરીમાં તીવ્ર ઘટાડો થાય છે. બીજી બાજુ, આ મોડને બંધ કરવાનું પણ સલાહભર્યું નથી, કારણ કે તે સઘન ડેટા પ્રોસેસિંગની ક્ષણો દરમિયાન GCને કારણે અટકી જશે. એક સારો ઉકેલ એ છે કે વાંચન સાથે જ પુટ દ્વારા સક્રિય લેખનના કિસ્સામાં સેલ વોલ્યુમ વધારવું. એ નોંધવું યોગ્ય છે કે જો રેકોર્ડિંગ કર્યા પછી, તમે ફ્લશ કમાન્ડ ચલાવો છો, જે મેમસ્ટોરને ડિસ્ક પર રીસેટ કરે છે અથવા જો તમે બલ્કલોડનો ઉપયોગ કરીને લોડ કરો છો તો સમસ્યા ઊભી થતી નથી. નીચે આપેલ કોષ્ટક બતાવે છે કે મેમસ્ટોર તરફથી મોટી (અને સમાન રકમ) ડેટા માટેની ક્વેરી મંદીમાં પરિણમે છે. જો કે, ચંકસાઇઝ વધારીને અમે પ્રોસેસિંગ સમયને સામાન્ય પર પાછા આપીએ છીએ.

ચંકસાઇઝ વધારવા ઉપરાંત, ડેટાને પ્રદેશ દ્વારા વિભાજીત કરવામાં મદદ મળે છે, એટલે કે. ટેબલ વિભાજન. આના પરિણામે દરેક પ્રદેશમાં ઓછી વિનંતીઓ આવે છે અને જો તે કોષમાં ફિટ થાય છે, તો પ્રતિસાદ સારો રહે છે.

6. કોષ્ટકોને પ્રદેશોમાં વિભાજીત કરવા માટેની વ્યૂહરચના (વિભાજન)

કારણ કે HBase એ કી-વેલ્યુ સ્ટોરેજ છે અને પાર્ટીશનીંગ કી દ્વારા હાથ ધરવામાં આવે છે, તે તમામ પ્રદેશોમાં સમાનરૂપે ડેટાને વિભાજીત કરવા માટે અત્યંત મહત્વપૂર્ણ છે. ઉદાહરણ તરીકે, આવા કોષ્ટકને ત્રણ ભાગોમાં વિભાજીત કરવાથી ડેટાને ત્રણ પ્રદેશોમાં વિભાજિત કરવામાં આવશે:

એવું બને છે કે આ તીવ્ર મંદી તરફ દોરી જાય છે જો પાછળથી લોડ થયેલ ડેટા જેવો દેખાય છે, ઉદાહરણ તરીકે, લાંબા મૂલ્યો, તેમાંના મોટા ભાગના સમાન અંકથી શરૂ થાય છે, ઉદાહરણ તરીકે:

1000001
1000002
...
1100003

ચાવીઓ બાઈટ એરે તરીકે સંગ્રહિત હોવાથી, તે બધા એકસરખા શરૂ થશે અને કીની આ શ્રેણીને સંગ્રહિત કરતા સમાન પ્રદેશ #1 ની છે. ત્યાં ઘણી પાર્ટીશન વ્યૂહરચના છે:

HexStringSplit – કીને "00000000" => "FFFFFFFF" શ્રેણીમાં હેક્સાડેસિમલ એન્કોડેડ સ્ટ્રિંગમાં ફેરવે છે અને ડાબી બાજુએ શૂન્ય સાથે પેડિંગ કરે છે.

યુનિફોર્મસ્પ્લિટ - "00" => "FF" શ્રેણીમાં હેક્સાડેસિમલ એન્કોડિંગ સાથે કીને બાઈટ એરેમાં ફેરવે છે અને જમણી બાજુએ શૂન્ય સાથે પેડિંગ કરે છે.

વધુમાં, તમે વિભાજન માટે કોઈપણ શ્રેણી અથવા કીના સેટનો ઉલ્લેખ કરી શકો છો અને સ્વતઃ-વિભાજનને ગોઠવી શકો છો. જો કે, સૌથી સરળ અને સૌથી અસરકારક અભિગમોમાંનો એક છે યુનિફોર્મસ્પ્લિટ અને હેશ કન્કેટનેશનનો ઉપયોગ, ઉદાહરણ તરીકે CRC32(રોકી) ફંક્શન અને રો-કી દ્વારા કી ચલાવવાથી બાઇટ્સની સૌથી નોંધપાત્ર જોડી:

hash + rowkey

પછી તમામ ડેટા પ્રદેશોમાં સમાનરૂપે વિતરિત કરવામાં આવશે. વાંચતી વખતે, પ્રથમ બે બાઇટ્સ ખાલી કાઢી નાખવામાં આવે છે અને મૂળ કી રહે છે. RS પ્રદેશમાં ડેટા અને કીના જથ્થાને પણ નિયંત્રિત કરે છે અને, જો મર્યાદા ઓળંગાઈ જાય, તો તેને આપમેળે ભાગોમાં તોડી નાખે છે.

7. ફોલ્ટ સહિષ્ણુતા અને ડેટા સ્થાનિકતા

કીના દરેક સેટ માટે માત્ર એક જ પ્રદેશ જવાબદાર હોવાથી, RS ક્રેશ અથવા ડિકમિશનિંગ સાથે સંકળાયેલી સમસ્યાઓનો ઉકેલ HDFSમાં તમામ જરૂરી ડેટા સ્ટોર કરવાનો છે. જ્યારે RS પડે છે, ત્યારે માસ્ટર તેને ZooKeeper નોડ પર ધબકારા ન હોવાની ગેરહાજરી દ્વારા શોધી કાઢે છે. પછી તે સેવા આપેલ પ્રદેશને બીજા RS ને સોંપે છે અને HFiles વિતરિત ફાઇલ સિસ્ટમમાં સંગ્રહિત હોવાથી, નવા માલિક તેમને વાંચે છે અને ડેટાને સેવા આપવાનું ચાલુ રાખે છે. જો કે, કેટલાક ડેટા મેમસ્ટોરમાં હોઈ શકે છે અને HFiles માં પ્રવેશવાનો સમય ન હોવાથી, WAL, જે HDFS માં પણ સંગ્રહિત છે, તેનો ઉપયોગ કામગીરીના ઇતિહાસને પુનઃસ્થાપિત કરવા માટે થાય છે. ફેરફારો લાગુ થયા પછી, RS વિનંતીઓનો પ્રતિસાદ આપવામાં સક્ષમ છે, પરંતુ આ પગલું એ હકીકત તરફ દોરી જાય છે કે કેટલાક ડેટા અને તેમને સેવા આપતી પ્રક્રિયાઓ વિવિધ ગાંઠો પર સમાપ્ત થાય છે, એટલે કે. સ્થાનિકતા ઘટી રહી છે.

સમસ્યાનો ઉકેલ એ મુખ્ય કોમ્પેક્શન છે - આ પ્રક્રિયા ફાઇલોને તે ગાંઠો પર ખસેડે છે જે તેમના માટે જવાબદાર છે (જ્યાં તેમના પ્રદેશો સ્થિત છે), પરિણામે આ પ્રક્રિયા દરમિયાન નેટવર્ક અને ડિસ્ક પરનો ભાર ઝડપથી વધે છે. જો કે, ભવિષ્યમાં, ડેટાની ઍક્સેસ નોંધપાત્ર રીતે ઝડપી છે. વધુમાં, major_compaction તમામ HFilesને એક પ્રદેશમાં એક ફાઇલમાં મર્જ કરે છે, અને ટેબલ સેટિંગ્સના આધારે ડેટાને પણ સાફ કરે છે. ઉદાહરણ તરીકે, તમે ઑબ્જેક્ટના વર્ઝનની સંખ્યાનો ઉલ્લેખ કરી શકો છો જેને જાળવી રાખવાની જરૂર છે અથવા આજીવન કે જેના પછી ઑબ્જેક્ટ ભૌતિક રીતે કાઢી નાખવામાં આવે છે.

આ પ્રક્રિયા HBase ના ઓપરેશન પર ખૂબ હકારાત્મક અસર કરી શકે છે. નીચેનું ચિત્ર બતાવે છે કે સક્રિય ડેટા રેકોર્ડિંગના પરિણામે પ્રદર્શન કેવી રીતે બગડ્યું. અહીં તમે જોઈ શકો છો કે એક ટેબલ પર 40 થ્રેડો કેવી રીતે લખે છે અને 40 થ્રેડો એકસાથે ડેટા વાંચે છે. થ્રેડો લખવાથી વધુ ને વધુ HFiles જનરેટ થાય છે, જે અન્ય થ્રેડો દ્વારા વાંચવામાં આવે છે. પરિણામે, મેમરીમાંથી વધુ અને વધુ ડેટા દૂર કરવાની જરૂર છે અને આખરે GC કામ કરવાનું શરૂ કરે છે, જે વ્યવહારીક રીતે તમામ કાર્યને લકવો કરે છે. મેજર કોમ્પેક્શનની શરૂઆતથી પરિણામી કાટમાળને સાફ કરવામાં અને ઉત્પાદકતા પુનઃસ્થાપિત થઈ.

પરીક્ષણ 3 ડેટાનોડ્સ અને 4 આરએસ (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 થ્રેડો) પર કરવામાં આવ્યું હતું. HBase સંસ્કરણ 1.2.0-cdh5.14.2

તે નોંધવું યોગ્ય છે કે મુખ્ય કોમ્પેક્શન "લાઇવ" ટેબલ પર શરૂ કરવામાં આવ્યું હતું, જેમાં ડેટા સક્રિય રીતે લખવામાં અને વાંચવામાં આવ્યો હતો. ઓનલાઈન એક નિવેદન હતું કે ડેટા વાંચતી વખતે આ ખોટો પ્રતિસાદ આપી શકે છે. તપાસવા માટે, એક પ્રક્રિયા શરૂ કરવામાં આવી હતી જેણે નવો ડેટા જનરેટ કર્યો હતો અને તેને ટેબલ પર લખ્યો હતો. જે પછી મેં તરત જ વાંચ્યું અને તપાસ્યું કે પરિણામી મૂલ્ય જે લખવામાં આવ્યું હતું તેની સાથે સુસંગત છે કે કેમ. જ્યારે આ પ્રક્રિયા ચાલી રહી હતી, ત્યારે મેજર કોમ્પેક્શન લગભગ 200 વખત ચલાવવામાં આવ્યું હતું અને એક પણ નિષ્ફળતા નોંધવામાં આવી ન હતી. કદાચ સમસ્યા ભાગ્યે જ અને માત્ર ઊંચા ભાર દરમિયાન જ દેખાય છે, તેથી યોજના મુજબ લેખન અને વાંચન પ્રક્રિયાઓ બંધ કરવી અને આવા GC ડ્રોડાઉનને રોકવા માટે સફાઈ કરવી વધુ સુરક્ષિત છે.

ઉપરાંત, મેજર કોમ્પેક્શન મેમસ્ટોરની સ્થિતિને અસર કરતું નથી; તેને ડિસ્ક પર ફ્લશ કરવા અને તેને કોમ્પેક્ટ કરવા માટે, તમારે ફ્લશ (connection.getAdmin().flush(TableName.valueOf(tblName))) નો ઉપયોગ કરવાની જરૂર છે.

8. સેટિંગ્સ અને પ્રદર્શન

પહેલેથી જ ઉલ્લેખ કર્યો છે તેમ, HBase તેની સૌથી મોટી સફળતા દર્શાવે છે જ્યાં તેને બલ્કલોડ એક્ઝિક્યુટ કરતી વખતે કંઈપણ કરવાની જરૂર નથી. જો કે, આ મોટાભાગની સિસ્ટમો અને લોકોને લાગુ પડે છે. જો કે, આ ટૂલ મોટા બ્લોક્સમાં જથ્થાબંધ ડેટા સ્ટોર કરવા માટે વધુ યોગ્ય છે, જ્યારે જો પ્રક્રિયામાં બહુવિધ સ્પર્ધાત્મક વાંચન અને લખવાની વિનંતીઓ જરૂરી હોય, તો ઉપર વર્ણવેલ ગેટ અને પુટ આદેશોનો ઉપયોગ કરવામાં આવે છે. શ્રેષ્ઠ પરિમાણો નક્કી કરવા માટે, ટેબલ પરિમાણો અને સેટિંગ્સના વિવિધ સંયોજનો સાથે લોંચ કરવામાં આવ્યા હતા:

• 10 થ્રેડો એકસાથે 3 વખત એકસાથે લોંચ કરવામાં આવ્યા હતા (ચાલો આને થ્રેડોનો બ્લોક કહીએ).
• બ્લોકમાં તમામ થ્રેડોનો ઓપરેટિંગ સમય સરેરાશ કરવામાં આવ્યો હતો અને તે બ્લોકની કામગીરીનું અંતિમ પરિણામ હતું.
• બધા થ્રેડો સમાન ટેબલ સાથે કામ કરે છે.
• થ્રેડ બ્લોકની દરેક શરૂઆત પહેલાં, મુખ્ય કોમ્પેક્શન કરવામાં આવ્યું હતું.
• દરેક બ્લોકે નીચેનામાંથી માત્ર એક જ કામગીરી કરી હતી:

- મૂકો
- મેળવો
—Get+Put

• દરેક બ્લોકે તેની કામગીરીના 50 પુનરાવર્તનો કર્યા.
• રેકોર્ડનું બ્લોકનું કદ 100 બાઇટ્સ, 1000 બાઇટ્સ અથવા 10000 બાઇટ્સ (રેન્ડમ) છે.
• વિનંતિ કરેલ કીની વિવિધ સંખ્યાઓ (ક્યાં તો એક કી અથવા 10) સાથે બ્લોક લોન્ચ કરવામાં આવ્યા હતા.
• બ્લોક્સ વિવિધ ટેબલ સેટિંગ્સ હેઠળ ચલાવવામાં આવ્યા હતા. પરિમાણો બદલાયા:

— BlockCache = ચાલુ અથવા બંધ
— બ્લોકસાઈઝ = 65 KB અથવા 16 KB
— પાર્ટીશનો = 1, 5 અથવા 30
— MSLAB = સક્ષમ અથવા અક્ષમ

તેથી બ્લોક આના જેવો દેખાય છે:

a MSLAB મોડ ચાલુ/બંધ કરવામાં આવ્યો હતો.
b એક કોષ્ટક બનાવવામાં આવ્યું હતું જેના માટે નીચેના પરિમાણો સુયોજિત હતા: બ્લોકકેશ = સાચું/કોઈ નહીં, બ્લોકસાઈઝ = 65/16 Kb, પાર્ટીશન = 1/5/30.
c કમ્પ્રેશન GZ પર સેટ કરવામાં આવ્યું હતું.
ડી. આ કોષ્ટકમાં 10/1/10 બાઈટના રેકોર્ડ સાથે 100/1000 પુટ/ગેટ/ગેટ+પુટ ઑપરેશન્સ કરીને 10000 થ્રેડો એકસાથે લૉન્ચ કરવામાં આવ્યા હતા, એક પંક્તિમાં 50 ક્વેરીઝ (રેન્ડમ કી) કરી હતી.
ઇ. બિંદુ ડી ત્રણ વખત પુનરાવર્તિત કરવામાં આવ્યું હતું.
f તમામ થ્રેડોનો ઓપરેટિંગ સમય સરેરાશ કરવામાં આવ્યો હતો.

તમામ સંભવિત સંયોજનોનું પરીક્ષણ કરવામાં આવ્યું હતું. તે અનુમાન કરી શકાય છે કે રેકોર્ડ કદમાં વધારો થતાં ઝડપ ઘટશે અથવા કેશીંગને અક્ષમ કરવાથી મંદી આવશે. જો કે, ધ્યેય દરેક પરિમાણના પ્રભાવની ડિગ્રી અને મહત્વને સમજવાનો હતો, તેથી એકત્રિત ડેટાને રેખીય રીગ્રેશન ફંક્શનના ઇનપુટમાં ખવડાવવામાં આવ્યો હતો, જે ટી-આંકડાઓનો ઉપયોગ કરીને મહત્વનું મૂલ્યાંકન કરવાનું શક્ય બનાવે છે. નીચે પુટ ઑપરેશન કરતા બ્લોક્સના પરિણામો છે. સંયોજનોનો સંપૂર્ણ સેટ 2*2*3*2*3 = 144 વિકલ્પો + 72 tk. કેટલાક બે વખત કરવામાં આવ્યા હતા. તેથી, કુલ 216 રન છે:

3 ડેટાનોડ્સ અને 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 થ્રેડો) ધરાવતા મિની-ક્લસ્ટર પર પરીક્ષણ હાથ ધરવામાં આવ્યું હતું. HBase સંસ્કરણ 1.2.0-cdh5.14.2.

MSLAB મોડ બંધ કરીને, એક પાર્ટીશન સાથેના ટેબલ પર, BlockCache સક્ષમ સાથે, BlockSize = 3.7, 16 બાઇટ્સનો રેકોર્ડ, પેક દીઠ 100 ટુકડાઓ સાથે 10 સેકન્ડની સર્વોચ્ચ નિવેશ ઝડપ મેળવવામાં આવી હતી.
82.8 સેકન્ડની સૌથી ઓછી નિવેશ ગતિ MSLAB મોડ સક્ષમ સાથે, એક પાર્ટીશન સાથેના ટેબલ પર, બ્લોકકેશ સક્ષમ સાથે, બ્લોકસાઈઝ = 16, 10000 બાઈટ્સના રેકોર્ડ્સ, દરેક 1 સાથે મેળવવામાં આવી હતી.

હવે ચાલો મોડેલ જોઈએ. અમે R2 પર આધારિત મોડેલની સારી ગુણવત્તા જોયે છે, પરંતુ તે એકદમ સ્પષ્ટ છે કે એક્સ્ટ્રાપોલેશન અહીં બિનસલાહભર્યું છે. જ્યારે પરિમાણો બદલાશે ત્યારે સિસ્ટમની વાસ્તવિક વર્તણૂક રેખીય રહેશે નહીં; આ મોડેલ આગાહીઓ માટે નહીં, પરંતુ આપેલ પરિમાણોમાં શું થયું તે સમજવા માટે જરૂરી છે. ઉદાહરણ તરીકે, અહીં આપણે વિદ્યાર્થીના માપદંડ પરથી જોઈએ છીએ કે બ્લોકસાઇઝ અને બ્લોકકેશ પેરામીટર પુટ ઓપરેશન માટે કોઈ વાંધો નથી (જે સામાન્ય રીતે તદ્દન અનુમાનિત છે):

પરંતુ હકીકત એ છે કે પાર્ટીશનોની સંખ્યામાં વધારો કરવાથી કામગીરીમાં ઘટાડો થાય છે તે કંઈક અંશે અણધારી છે (અમે પહેલાથી જ બલ્કલોડ સાથે પાર્ટીશનોની સંખ્યા વધારવાની હકારાત્મક અસર જોઈ છે), જોકે સમજી શકાય તેવું છે. સૌપ્રથમ, પ્રક્રિયા કરવા માટે, તમારે એકને બદલે 30 પ્રદેશોમાં વિનંતીઓ જનરેટ કરવી પડશે, અને ડેટાનું પ્રમાણ એવું નથી કે તેનાથી ફાયદો થાય. બીજું, કુલ ઓપરેટિંગ સમય સૌથી ધીમું RS દ્વારા નક્કી કરવામાં આવે છે, અને ડેટાનોડ્સની સંખ્યા RS ની સંખ્યા કરતા ઓછી હોવાથી, કેટલાક પ્રદેશોમાં શૂન્ય સ્થાન હોય છે. સારું, ચાલો ટોચના પાંચ જોઈએ:

હવે ચાલો ગેટ બ્લોક્સ ચલાવવાના પરિણામોનું મૂલ્યાંકન કરીએ:

પાર્ટીશનોની સંખ્યાએ મહત્વ ગુમાવ્યું છે, જે સંભવતઃ એ હકીકત દ્વારા સમજાવવામાં આવે છે કે ડેટા સારી રીતે કેશ થયેલ છે અને રીડ કેશ એ સૌથી નોંધપાત્ર (આંકડાકીય રીતે) પરિમાણ છે. સ્વાભાવિક રીતે, વિનંતીમાં સંદેશાઓની સંખ્યા વધારવી પણ કામગીરી માટે ખૂબ ઉપયોગી છે. ટોચના સ્કોર:

ઠીક છે, છેવટે, ચાલો બ્લોકના મોડેલને જોઈએ જેણે પહેલા મેળવ્યું અને પછી મૂક્યું:

બધા પરિમાણો અહીં નોંધપાત્ર છે. અને નેતાઓના પરિણામો:

9. લોડ પરીક્ષણ

ઠીક છે, આખરે અમે વધુ કે ઓછા યોગ્ય લોડ લોન્ચ કરીશું, પરંતુ જ્યારે તમારી પાસે સરખામણી કરવા માટે કંઈક હોય ત્યારે તે હંમેશા વધુ રસપ્રદ હોય છે. DataStax ની વેબસાઇટ પર, Cassandra ના મુખ્ય વિકાસકર્તા, ત્યાં છે результаты HBase સંસ્કરણ 0.98.6-1 સહિત સંખ્યાબંધ NoSQL સ્ટોરેજનું NT. લોડિંગ 40 થ્રેડો, ડેટા કદ 100 બાઇટ્સ, SSD ડિસ્ક દ્વારા હાથ ધરવામાં આવ્યું હતું. વાંચન-સંશોધિત-લખો કામગીરીના પરીક્ષણના પરિણામ નીચેના પરિણામો દર્શાવે છે.

જ્યાં સુધી હું સમજું છું, વાંચન 100 રેકોર્ડ્સના બ્લોકમાં કરવામાં આવ્યું હતું અને 16 HBase નોડ્સ માટે, DataStax ટેસ્ટ પ્રતિ સેકન્ડમાં 10 હજાર ઓપરેશન્સનું પ્રદર્શન દર્શાવે છે.

તે નસીબદાર છે કે અમારા ક્લસ્ટરમાં પણ 16 નોડ્સ છે, પરંતુ તે ખૂબ "નસીબદાર" નથી કે દરેકમાં 64 કોરો (થ્રેડો) છે, જ્યારે ડેટાસ્ટેક્સ ટેસ્ટમાં ફક્ત 4 છે. બીજી બાજુ, તેમની પાસે SSD ડ્રાઇવ છે, જ્યારે અમારી પાસે HDD છે. અથવા વધુ HBase અને CPU ના નવા સંસ્કરણ લોડ દરમિયાન વ્યવહારીક રીતે નોંધપાત્ર રીતે (5-10 ટકા જેટલો) વધારો થયો નથી. જો કે, ચાલો આ ગોઠવણીનો ઉપયોગ શરૂ કરવાનો પ્રયાસ કરીએ. ડિફૉલ્ટ ટેબલ સેટિંગ્સ, રીડિંગ કી રેન્જમાં 0 થી 50 મિલિયન રેન્ડમલી (એટલે ​​​​કે, દરેક વખતે આવશ્યકપણે નવું) કરવામાં આવે છે. કોષ્ટકમાં 50 મિલિયન રેકોર્ડ્સ છે, જે 64 પાર્ટીશનોમાં વિભાજિત છે. કીઓ crc32 નો ઉપયોગ કરીને હેશ કરવામાં આવે છે. કોષ્ટક સેટિંગ્સ ડિફૉલ્ટ છે, MSLAB સક્ષમ છે. 40 થ્રેડો શરૂ કરીને, દરેક થ્રેડ 100 રેન્ડમ કીનો સમૂહ વાંચે છે અને તરત જ જનરેટ કરેલ 100 બાઇટ્સ આ કી પર પાછા લખે છે.

સ્ટેન્ડ: 16 ડેટાનોડ અને 16 આરએસ (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 થ્રેડો). HBase સંસ્કરણ 1.2.0-cdh5.14.2.

સરેરાશ પરિણામ પ્રતિ સેકન્ડ 40 હજાર ઓપરેશન્સની નજીક છે, જે DataStax ટેસ્ટ કરતાં નોંધપાત્ર રીતે વધુ સારું છે. જો કે, પ્રાયોગિક હેતુઓ માટે, તમે શરતોને સહેજ બદલી શકો છો. તે તદ્દન અસંભવિત છે કે તમામ કાર્ય ફક્ત એક ટેબલ પર જ હાથ ધરવામાં આવશે, અને તે પણ ફક્ત અનન્ય કી પર. ચાલો ધારીએ કે મુખ્ય લોડ જનરેટ કરતી કીઓનો ચોક્કસ "ગરમ" સમૂહ છે. તેથી, ચાલો મોટા રેકોર્ડ્સ (10 KB) સાથે લોડ બનાવવાનો પ્રયાસ કરીએ, તે પણ 100 ની બેચમાં, 4 અલગ-અલગ કોષ્ટકોમાં અને વિનંતી કરેલ કીની શ્રેણીને 50 હજાર સુધી મર્યાદિત કરીએ. નીચેનો આલેખ 40 થ્રેડોનો પ્રારંભ દર્શાવે છે, દરેક થ્રેડ વાંચે છે. 100 કીઓનો સમૂહ અને તરત જ આ કી પર રેન્ડમ 10 KB લખે છે.

સ્ટેન્ડ: 16 ડેટાનોડ અને 16 આરએસ (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 થ્રેડો). HBase સંસ્કરણ 1.2.0-cdh5.14.2.

લોડ દરમિયાન, મેજર કોમ્પેક્શન ઘણી વખત લોંચ કરવામાં આવ્યું હતું, ઉપર બતાવ્યા પ્રમાણે, આ પ્રક્રિયા વિના, કામગીરી ધીમે ધીમે ઘટશે, જો કે, એક્ઝેક્યુશન દરમિયાન વધારાનો લોડ પણ ઉભો થાય છે. ડ્રોડાઉન વિવિધ કારણોસર થાય છે. કેટલીકવાર થ્રેડો કામ કરવાનું સમાપ્ત કરે છે અને જ્યારે તેઓ પુનઃપ્રારંભ કરવામાં આવે ત્યારે થોભો હતો, કેટલીકવાર તૃતીય-પક્ષ એપ્લિકેશન્સ ક્લસ્ટર પર લોડ બનાવે છે.

વાંચવું અને તરત જ લખવું એ HBase માટે સૌથી મુશ્કેલ કામના દૃશ્યોમાંનું એક છે. જો તમે માત્ર નાની પુટ વિનંતીઓ કરો છો, ઉદાહરણ તરીકે 100 બાઇટ્સ, તેમને 10-50 હજાર ટુકડાઓના પેકમાં જોડીને, તમે સેકન્ડ દીઠ સેંકડો હજારો ઑપરેશન મેળવી શકો છો, અને પરિસ્થિતિ ફક્ત વાંચવા માટેની વિનંતીઓ જેવી જ છે. તે નોંધવું યોગ્ય છે કે પરિણામો ડેટાસ્ટેક્સ દ્વારા મેળવેલા પરિણામો કરતાં ધરમૂળથી સારા છે, મોટાભાગે 50 હજારના બ્લોક્સમાં વિનંતીઓને કારણે.

સ્ટેન્ડ: 16 ડેટાનોડ અને 16 આરએસ (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 થ્રેડો). HBase સંસ્કરણ 1.2.0-cdh5.14.2.

10. નિષ્કર્ષ

આ સિસ્ટમ તદ્દન લવચીક રીતે ગોઠવવામાં આવી છે, પરંતુ મોટી સંખ્યામાં પરિમાણોનો પ્રભાવ હજુ પણ અજ્ઞાત છે. તેમાંના કેટલાકનું પરીક્ષણ કરવામાં આવ્યું હતું, પરંતુ પરિણામી પરીક્ષણ સમૂહમાં સમાવેશ કરવામાં આવ્યો ન હતો. ઉદાહરણ તરીકે, પ્રારંભિક પ્રયોગોએ DATA_BLOCK_ENCODING જેવા પેરામીટરનું નજીવું મહત્વ દર્શાવ્યું હતું, જે પડોશી કોષોમાંથી મૂલ્યોનો ઉપયોગ કરીને માહિતીને એન્કોડ કરે છે, જે રેન્ડમલી જનરેટ થયેલ ડેટા માટે સમજી શકાય તેવું છે. જો તમે મોટી સંખ્યામાં ડુપ્લિકેટ વસ્તુઓનો ઉપયોગ કરો છો, તો ફાયદો નોંધપાત્ર હોઈ શકે છે. સામાન્ય રીતે, આપણે કહી શકીએ કે HBase એકદમ ગંભીર અને સારી રીતે વિચારેલા ડેટાબેઝની છાપ આપે છે, જે ડેટાના મોટા બ્લોક્સ સાથે કામગીરી કરતી વખતે તદ્દન ઉત્પાદક બની શકે છે. ખાસ કરીને જો સમયસર વાંચન અને લેખન પ્રક્રિયાઓને અલગ કરવી શક્ય હોય.

જો તમારા અભિપ્રાયમાં કંઈક એવું હોય જે પૂરતું જાહેર ન થયું હોય, તો હું તમને વધુ વિગતવાર જણાવવા તૈયાર છું. અમે તમને તમારો અનુભવ શેર કરવા અથવા ચર્ચા કરવા માટે આમંત્રિત કરીએ છીએ જો તમે કોઈ વાત સાથે અસંમત હોવ.

સોર્સ: www.habr.com