HBase භාවිතා කිරීමේ න්‍යාය සහ භාවිතය

සුභ සන්ධ්යාවක් මගේ නම Danil Lipovoy, Sbertech හි අපගේ කණ්ඩායම මෙහෙයුම් දත්ත සඳහා ගබඩාවක් ලෙස HBase භාවිතා කිරීමට පටන් ගත්තේය. එය අධ්‍යයනය කිරීමේදී, මට ක්‍රමානුකූල කිරීමට සහ විස්තර කිරීමට අවශ්‍ය වූ අත්දැකීම් සමුච්චය වී ඇත (එය බොහෝ දෙනෙකුට ප්‍රයෝජනවත් වනු ඇතැයි අපි බලාපොරොත්තු වෙමු). පහත සියලුම පරීක්ෂණ HBase අනුවාද 1.2.0-cdh5.14.2 සහ 2.0.0-cdh6.0.0-beta1 සමඟ සිදු කරන ලදී.

1. සාමාන්ය ගෘහ නිර්මාණ ශිල්පය
2. HBASE වෙත දත්ත ලිවීම
3. HBASE වෙතින් දත්ත කියවීම
4. දත්ත ගබඩා කිරීම
5. කණ්ඩායම් දත්ත සැකසීම MultiGet/MultiPut
6. කලාපවලට වගු බෙදීමේ උපාය මාර්ගය (බෙදීම)
7. වැරදි ඉවසීම, සංයුක්ත කිරීම සහ දත්ත ප්‍රදේශය
8. සැකසුම් සහ කාර්ය සාධනය
9. ආතතිය පරීක්ෂා කිරීම
10. සොයා ගැනීම්

1. සාමාන්ය ගෘහ නිර්මාණ ශිල්පය

උපස්ථ මාස්ටර් ZooKeeper node හි ක්‍රියාකාරී එකාගේ හද ගැස්මට සවන් දෙන අතර, අතුරුදහන් වූ විට, ස්වාමියාගේ කාර්යයන් භාර ගනී.

2. HBASE වෙත දත්ත ලියන්න

පළමුව, අපි සරලම අවස්ථාව දෙස බලමු - put(rowkey) භාවිතයෙන් වගුවකට යතුරු-අගය වස්තුවක් ලිවීම. සේවාදායකයා මුලින්ම hbase:meta වගුව ගබඩා කරන Root Region Server (RRS) පිහිටා ඇත්තේ කොහේදැයි සොයා බැලිය යුතුය. ඔහුට මෙම තොරතුරු ලැබෙන්නේ ZooKeeper වෙතින්. ඉන් පසුව එය RRS වෙත ප්‍රවේශ වී hbase:meta වගුව කියවන අතර, එය උනන්දුවක් දක්වන වගුවේ දී ඇති rowkey සඳහා දත්ත ගබඩා කිරීම සඳහා වගකිව යුතු RegionServer (RS) පිළිබඳ තොරතුරු උපුටා ගනී. අනාගත භාවිතය සඳහා, මෙටා වගුව සේවාලාභියා විසින් හැඹිලිගත කර ඇති අතර එම නිසා පසුව ලැබෙන ඇමතුම් වේගයෙන්, කෙලින්ම RS වෙත යයි.

ඊළඟට, RS, ඉල්ලීමක් ලැබීමෙන් පසු, පළමුවෙන්ම එය WriteAheadLog (WAL) වෙත ලියයි, එය බිඳ වැටීමකදී යථා තත්ත්වයට පත් කිරීම සඳහා අවශ්ය වේ. ඉන්පසු දත්ත MemStore වෙත සුරකියි. මෙය දී ඇති කලාපයක් සඳහා අනුපිළිවෙළට සකසන ලද යතුරු කට්ටලයක් අඩංගු මතකයේ බෆරයකි. වගුවක් කලාප (කොටස්) වලට බෙදිය හැකිය, ඒ සෑම එකක්ම එකිනෙකට සම්බන්ධ යතුරු කට්ටලයක් අඩංගු වේ. ඉහළ කාර්ය සාධනයක් ලබා ගැනීම සඳහා විවිධ සේවාදායකයන් මත කලාප තැබීමට මෙය ඔබට ඉඩ සලසයි. කෙසේ වෙතත්, මෙම ප්‍රකාශයේ පැහැදිලි බව තිබියදීත්, මෙය සෑම අවස්ථාවකම ක්‍රියාත්මක නොවන බව පසුව අපට පෙනෙනු ඇත.

MemStore හි ප්‍රවේශයක් තැබීමෙන් පසු, ප්‍රවේශය සාර්ථකව සුරකින ලද බවට ප්‍රතිචාරයක් සේවාදායකයා වෙත ආපසු එවනු ලැබේ. කෙසේ වෙතත්, යථාර්ථයේ දී එය ගබඩා කර ඇත්තේ බෆරයක පමණක් වන අතර තැටියට ලැබෙන්නේ යම් කාල සීමාවක් ගත වූ පසු හෝ එය නව දත්ත පුරවා ඇති විට පමණි.

"මකන්න" මෙහෙයුම සිදු කරන විට, දත්ත භෞතිකව මකා නොදමනු ලැබේ. ඒවා සරලව මකා දැමූ ලෙස සලකුණු කර ඇති අතර, 7 වන ඡේදයේ වඩාත් විස්තරාත්මකව විස්තර කර ඇති ප්‍රධාන සංයුක්ත ශ්‍රිතය ඇමතීමේ මොහොතේදී විනාශය සිදු වේ.

HFile ආකෘතියේ ගොනු HDFS හි සමුච්චිත වන අතර වරින් වර සුළු සංයුක්ත ක්‍රියාවලිය දියත් කරනු ලැබේ, එමඟින් කුඩා ගොනු කිසිවක් මකා දැමීමකින් තොරව විශාල ඒවා බවට ඒකාබද්ධ කරයි. කාලයාගේ ඇවෑමෙන්, මෙය දත්ත කියවීමේදී පමණක් දිස්වන ගැටළුවක් බවට පත්වේ (අපි මෙයට ටිකක් පසුව එන්නෙමු).

ඉහත විස්තර කර ඇති පැටවීමේ ක්රියාවලියට අමතරව, වඩාත් ඵලදායී ක්රියා පටිපාටියක් ඇත, සමහර විට මෙම දත්ත ගබඩාවේ ශක්තිමත්ම පැත්ත වේ - BulkLoad. එය පවතින්නේ අපි ස්වාධීනව HFiles සාදා ඒවා තැටියේ තැබීමයි, එමඟින් අපට පරිපූර්ණ ලෙස පරිමාණය කිරීමට සහ ඉතා හොඳ වේගයක් ලබා ගැනීමට ඉඩ සලසයි. ඇත්ත වශයෙන්ම, මෙහි සීමාව HBase නොවේ, නමුත් දෘඪාංගයේ හැකියාවන්. පහත දැක්වෙන්නේ RegionServers 16 සහ NodeManager YARN (CPU Xeon E16-5 v2680 @ 4GHz * 2.40 නූල්), HBase අනුවාදය 64-cdh1.2.0 කින් සමන්විත පොකුරක් මත ඇරඹුම් ප්‍රතිඵල වේ.

මෙහිදී ඔබට පෙනෙනු ඇත, වගුවේ ඇති කොටස් (කලාප) ගණන මෙන්ම Spark executors වැඩි කිරීමෙන් අපට බාගත කිරීමේ වේගය වැඩි වේ. එසේම, වේගය පටිගත කිරීමේ පරිමාව මත රඳා පවතී. විශාල කුට්ටි MB/sec හි වැඩි වීමක් ලබා දෙයි, කාල ඒකකයකට ඇතුළත් කරන ලද වාර්තා ගණනෙහි කුඩා කොටස්, අනෙක් සියල්ල සමාන වේ.

ඔබට එකවර මේස දෙකකට පැටවීම ආරම්භ කර දෙගුණයක වේගයක් ලබා ගත හැකිය. පහතින් ඔබට පෙනෙන්නේ එක් වගුවකට 10 MB/sec ලිවීමේ වේගය සමඟ සමපාත වන එක් එක් (මුළු 600 MB/sec) 1275 MB/sec පමණ වේගයකින් එකවර වගු දෙකකට 623 KB කුට්ටි ලිවීමයි (බලන්න ඉහත අංක 11)

නමුත් 50 KB වාර්තා සහිත දෙවන ධාවනය පෙන්නුම් කරන්නේ බාගත කිරීමේ වේගය තරමක් වර්ධනය වන බවයි, එයින් පෙන්නුම් කරන්නේ එය සීමිත අගයන් කරා ළඟා වන බවයි. ඒ සමඟම, ඔබ මතක තබා ගත යුතු කරුණක් නම්, ප්‍රායෝගිකව HBASE මතම කිසිදු බරක් නිර්මාණය කර නොමැති බවත්, එයට අවශ්‍ය වන්නේ පළමුව hbase:meta වෙතින් දත්ත ලබා දීම සහ HFiles පෙළ ගැසීමෙන් පසුව, BlockCache දත්ත නැවත සකසා සුරකින්න. MemStore බෆරය තැටියට, එය හිස් නොවේ නම්.

3. HBASE වෙතින් දත්ත කියවීම

සේවාදායකයාට දැනටමත් hbase:meta වෙතින් සියලුම තොරතුරු ඇතැයි අපි උපකල්පනය කරන්නේ නම් (2 වන කරුණ බලන්න), එවිට ඉල්ලීම කෙලින්ම RS වෙත අවශ්‍ය යතුර ගබඩා කර ඇත. පළමුව, සෙවීම MemCache හි සිදු කෙරේ. එහි දත්ත තිබේද නැද්ද යන්න නොසලකා, සෙවුම BlockCache බෆරය තුළ සහ අවශ්‍ය නම් HFiles තුළද සිදු කෙරේ. ගොනුවේ දත්ත සොයා ගත්තේ නම්, එය BlockCache හි තැන්පත් කර ඇති අතර ඊළඟ ඉල්ලීම මත ඉක්මනින් ආපසු ලබා දෙනු ඇත. Bloom ෆිල්ටරය භාවිතා කිරීම නිසා HFile හි සෙවීම සාපේක්ෂව වේගවත් වේ, i.e. කුඩා දත්ත ප්‍රමාණයක් කියවීමෙන් පසු, මෙම ගොනුවට අවශ්‍ය යතුර තිබේද යන්න වහාම තීරණය කරන අතර එසේ නොමැති නම්, ඊළඟ එක වෙත ගමන් කරයි.

මෙම මූලාශ්‍ර තුනෙන් දත්ත ලැබීමෙන් පසු, RS ප්‍රතිචාරයක් ජනනය කරයි. විශේෂයෙන්ම, සේවාලාභියා අනුවාදනය ඉල්ලා සිටියේ නම්, වස්තුවක සොයාගත් අනුවාද කිහිපයක් එකවර මාරු කළ හැකිය.

4. දත්ත ගබඩා කිරීම

MemStore සහ BlockCache බෆර වෙන් කර ඇති on-heap RS මතකයෙන් 80%ක් දක්වා අල්ලා ගනී (ඉතුරු කොටස RS සේවා කාර්යයන් සඳහා වෙන් කර ඇත). සාමාන්‍ය භාවිත ප්‍රකාරය එකම දත්ත ලිවීමට සහ වහාම කියවන ආකාරයට ක්‍රියා කරයි නම්, BlockCache අඩු කිරීම සහ MemStore වැඩි කිරීම අර්ථවත් කරයි. දත්ත ලිවීමේදී කියවීම සඳහා හැඹිලියට ඇතුල් නොවන විට, BlockCache අඩුවෙන් භාවිතා වේ. BlockCache බෆරය කොටස් දෙකකින් සමන්විත වේ: LruBlockCache (සැමවිටම ගොඩගැසී ඇත) සහ BucketCache (සාමාන්‍යයෙන් off-heap හෝ SSD මත). BucketCache භාවිතා කළ යුත්තේ කියවීමේ ඉල්ලීම් විශාල ප්‍රමාණයක් ඇති විට සහ ඒවා LruBlockCache වලට නොගැලපෙන විට, එය කුණු එකතුකරන්නාගේ ක්‍රියාකාරී වැඩකටයුතුවලට මග පාදයි. ඒ අතරම, කියවීමේ හැඹිලිය භාවිතා කිරීමෙන් කාර්ය සාධනයේ රැඩිකල් වැඩි වීමක් ඔබ අපේක්ෂා නොකළ යුතුය, නමුත් අපි 8 ඡේදයෙන් මේ වෙත ආපසු යන්නෙමු.

සම්පූර්ණ RS සඳහා එක් BlockCache එකක් ඇති අතර, එක් එක් වගුව සඳහා එක් MemStore එකක් ඇත (එක් එක් තීරු පවුල සඳහා එකක්).

කොහොමද විස්තර කර ඇත න්‍යායාත්මකව, ලිවීමේදී දත්ත හැඹිලිය තුළට නොයන අතර ඇත්ත වශයෙන්ම, වගුව සඳහා CACHE_DATA_ON_WRITE සහ RS සඳහා “හැඹිලි දත්ත ලිවීම” අසත්‍ය ලෙස සකසා ඇත. කෙසේ වෙතත්, ප්‍රායෝගිකව, අපි MemStore වෙත දත්ත ලියන්නේ නම්, එය තැටියට ෆ්ලෂ් කරන්න (එමගින් එය ඉවත් කරන්න), ඉන්පසු ලැබෙන ගොනුව මකා දමන්න, එවිට ලබා ගැනීමේ ඉල්ලීමක් ක්‍රියාත්මක කිරීමෙන් අපට දත්ත සාර්ථකව ලැබෙනු ඇත. එපමනක් නොව, ඔබ 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. කණ්ඩායම් දත්ත සැකසීම MultiGet/MultiPut

තනි ඉල්ලීම් සැකසීම (Get/Put/Delete) තරමක් මිල අධික මෙහෙයුමකි, එබැවින් හැකි නම්, ඔබ ඒවා ලැයිස්තුවකට හෝ ලැයිස්තුවකට ඒකාබද්ධ කළ යුතුය, එමඟින් ඔබට සැලකිය යුතු කාර්ය සාධනයක් ලබා ගැනීමට ඉඩ සලසයි. ලිවීමේ මෙහෙයුම සඳහා මෙය විශේෂයෙන්ම සත්‍ය වේ, නමුත් කියවීමේදී පහත අන්තරාය පවතී. පහත ප්‍රස්ථාරය MemStore වෙතින් වාර්තා 50ක් කියවීමට කාලය පෙන්වයි. කියවීම එක් නූල් එකකින් සිදු කරන ලද අතර තිරස් අක්ෂය ඉල්ලීමේ යතුරු ගණන පෙන්වයි. එක් ඉල්ලීමක යතුරු දහසක් දක්වා වැඩි වන විට, ක්‍රියාත්මක කිරීමේ කාලය පහත වැටෙන බව මෙහිදී ඔබට දැක ගත හැකිය, i.e. වේගය වැඩි වේ. කෙසේ වෙතත්, MSLAB මාදිලිය පෙරනිමියෙන් සක්‍රීය කර ඇති අතර, මෙම සීමාවෙන් පසු කාර්ය සාධනයේ රැඩිකල් පහත වැටීමක් ආරම්භ වන අතර, වාර්තාවේ ඇති දත්ත ප්‍රමාණය විශාල වන තරමට මෙහෙයුම් කාලය වැඩි වේ.

අතථ්‍ය යන්ත්‍රයක්, මධ්‍ය 8ක්, HBase 2.0.0-cdh6.0.0-beta1 අනුවාදයක් මත පරීක්ෂණ සිදු කරන ලදී.

MSLAB මාදිලිය නිර්මාණය කර ඇත්තේ ගොඩවල් ඛණ්ඩනය අඩු කිරීම සඳහා වන අතර එය නව සහ පැරණි පරම්පරාවේ දත්ත මිශ්‍ර කිරීම හේතුවෙන් සිදු වේ. විසඳුමක් ලෙස, MSLAB සක්‍රීය කර ඇති විට, දත්ත සාපේක්ෂව කුඩා සෛල (කුට්ටි) තුළට තැන්පත් කර කුට්ටි තුළ සකසනු ලැබේ. ප්රතිඵලයක් වශයෙන්, ඉල්ලූ දත්ත පැකට්ටුවේ පරිමාව වෙන් කළ ප්රමාණයට වඩා වැඩි වන විට, කාර්ය සාධනය තියුනු ලෙස පහත වැටේ. අනෙක් අතට, මෙම ප්‍රකාරය අක්‍රිය කිරීම ද සුදුසු නොවේ, මන්ද එය දැඩි දත්ත සැකසීමේ අවස්ථා වලදී GC හේතුවෙන් නැවතුම් වලට තුඩු දෙනු ඇත. හොඳ විසඳුමක් වන්නේ කියවීමේදීම තැබීම හරහා ක්‍රියාකාරී ලිවීමේදී සෛල පරිමාව වැඩි කිරීමයි. පටිගත කිරීමෙන් පසු, ඔබ MemStore තැටියට නැවත සකසන ෆ්ලෂ් විධානය ක්‍රියාත්මක කරන්නේ නම් හෝ ඔබ BulkLoad භාවිතයෙන් පූරණය කරන්නේ නම් ගැටළුව සිදු නොවන බව සඳහන් කිරීම වටී. විශාල (සහ එම ප්‍රමාණයම) දත්ත සඳහා MemStore වෙතින් විමසුම් මන්දගාමී වීමට හේතු වන බව පහත වගුව පෙන්වයි. කෙසේ වෙතත්, කුට්ටි ප්රමාණය වැඩි කිරීමෙන් අපි සැකසුම් කාලය සාමාන්ය තත්වයට පත් කරමු.

කුට්ටි ප්‍රමාණය වැඩි කිරීමට අමතරව, කලාපය අනුව දත්ත බෙදීම උපකාරී වේ, i.e. මේසය බෙදීම. මෙහි ප්‍රතිඵලයක් ලෙස එක් එක් කලාපයට ලැබෙන ඉල්ලීම් අඩු වන අතර ඒවා සෛලයකට ගැලපේ නම්, ප්‍රතිචාරය යහපත්ව පවතී.

6. කලාපවලට වගු බෙදීමේ උපාය මාර්ගය (බෙදීම)

HBase යනු ප්‍රධාන වටිනාකම් ගබඩාවක් වන අතර කොටස් කිරීම සිදු කරනු ලබන්නේ යතුර මගින් බැවින්, දත්ත සෑම කලාපයකම ඒකාකාරව බෙදීම අතිශයින් වැදගත් වේ. උදාහරණයක් ලෙස, එවැනි වගුවක් කොටස් තුනකට බෙදීමෙන් දත්ත කලාප තුනකට බෙදනු ඇත:

පසුව පටවන ලද දත්ත දිගු අගයන් මෙන් පෙනේ නම් මෙය තියුණු මන්දගාමිත්වයකට තුඩු දෙයි, උදාහරණයක් ලෙස, ඒවායින් බොහොමයක් එකම ඉලක්කම් වලින් ආරම්භ වේ, උදාහරණයක් ලෙස:

1000001
1000002
...
1100003

යතුරු බයිට් අරාවක් ලෙස ගබඩා කර ඇති බැවින්, ඒවා සියල්ලම එකම ලෙස ආරම්භ වන අතර මෙම යතුරු පරාසය ගබඩා කරන #1 කලාපයට අයත් වේ. කොටස් කිරීමේ උපාය මාර්ග කිහිපයක් තිබේ:

HexStringSplit – යතුර "00000000" => "FFFFFFFF" පරාසයේ ෂඩාස්‍රාකාර කේතනය කරන ලද තන්තුවක් බවට පත් කරන අතර වම් පසින් බිංදු සමඟ පිරවුම් කරයි.

UniformSplit – "00" => "FF" පරාසයේ ෂඩාස්‍රාකාර කේතනය සහ දකුණු පසින් ශුන්‍ය සමඟ පෑඩින් සමඟ යතුර බයිට් අරාවක් බවට පත් කරයි.

ඊට අමතරව, ඔබට බෙදීම සඳහා ඕනෑම පරාසයක් හෝ යතුරු කට්ටලයක් නියම කර ස්වයංක්‍රීයව බෙදීම වින්‍යාසගත කළ හැකිය. කෙසේ වෙතත්, සරලම සහ වඩාත් ඵලදායී ප්‍රවේශයන්ගෙන් එකක් වන්නේ UniformSplit සහ හෑෂ් සංකෝචනය භාවිතයයි, උදාහරණයක් ලෙස CRC32(rowkey) ශ්‍රිතය සහ rowkey හරහා යතුර ධාවනය කිරීමෙන් ලැබෙන වඩාත්ම වැදගත් බයිට් යුගලය:

hash + rowkey

එවිට සියලුම දත්ත කලාප හරහා ඒකාකාරව බෙදා හරිනු ලැබේ. කියවන විට, පළමු බයිට් දෙක සරලව ඉවත දමන අතර මුල් යතුර ඉතිරි වේ. RS කලාපයේ දත්ත සහ යතුරු ප්‍රමාණය පාලනය කරන අතර, සීමාවන් ඉක්මවා ගියහොත්, එය ස්වයංක්‍රීයව කොටස් වලට කැඩී යයි.

7. වැරදි ඉවසීම සහ දත්ත ප්‍රදේශය

සෑම යතුරු කට්ටලයක් සඳහාම එක් කලාපයක් පමණක් වගකිව යුතු බැවින්, RS බිඳ වැටීම් හෝ ඉවත් කිරීම සම්බන්ධ ගැටළු වලට විසඳුම වන්නේ HDFS හි අවශ්ය සියලු දත්ත ගබඩා කිරීමයි. RS වැටෙන විට, ZooKeeper node හි හෘද ස්පන්දනයක් නොමැති වීම හරහා ස්වාමියා මෙය හඳුනා ගනී. ඉන්පසු එය සේවා කළ කලාපය වෙනත් RS එකකට පවරන අතර HFiles බෙදා හරින ලද ගොනු පද්ධතියක ගබඩා කර ඇති බැවින් නව හිමිකරු ඒවා කියවා දත්ත දිගටම සේවය කරයි. කෙසේ වෙතත්, සමහර දත්ත MemStore හි තිබිය හැකි අතර HFiles වෙත යාමට කාලය නොමැති බැවින්, HDFS හි ගබඩා කර ඇති WAL, මෙහෙයුම් ඉතිහාසය ප්‍රතිස්ථාපනය කිරීමට භාවිතා කරයි. වෙනස්කම් යෙදීමෙන් පසු, RS හට ඉල්ලීම් වලට ප්‍රතිචාර දැක්වීමට හැකි වේ, නමුත් මෙම පියවර මඟින් සමහර දත්ත සහ ඒවාට සේවා සපයන ක්‍රියාවලීන් විවිධ නෝඩ් මත අවසන් වේ, i.e. දේශීයත්වය අඩු වෙමින් පවතී.

ගැටලුවට විසඳුම ප්‍රධාන සංයුක්තතාවයයි - මෙම ක්‍රියා පටිපාටිය මඟින් ලිපිගොනු ඒවාට වගකිව යුතු (ඒවායේ කලාප පිහිටා ඇති) වෙත ගොනු ගෙන යයි, එහි ප්‍රති result ලයක් ලෙස මෙම ක්‍රියා පටිපාටිය අතරතුර ජාලයේ සහ තැටිවල බර තියුනු ලෙස වැඩි වේ. කෙසේ වෙතත්, අනාගතයේදී, දත්ත වෙත ප්රවේශය සැලකිය යුතු ලෙස වේගවත් වේ. ඊට අමතරව, major_compaction මඟින් සියලුම HFiles කලාපයක් තුළ එක් ගොනුවකට ඒකාබද්ධ කිරීම සිදු කරයි, තවද වගු සැකසීම් මත පදනම්ව දත්ත පිරිසිදු කරයි. උදාහරණයක් ලෙස, ඔබට රඳවා ගත යුතු වස්තුවක අනුවාද ගණන හෝ වස්තුව භෞතිකව මකා දැමූ ආයු කාලය නියම කළ හැක.

මෙම ක්රියාපටිපාටිය HBase හි ක්රියාකාරිත්වයට ඉතා ධනාත්මක බලපෑමක් ඇති කළ හැකිය. සක්‍රීය දත්ත පටිගත කිරීමේ ප්‍රතිඵලයක් ලෙස කාර්ය සාධනය පිරිහුණු ආකාරය පහත පින්තූරයේ දැක්වේ. එක් වගුවකට නූල් 40 ක් සහ නූල් 40 ක් එකවර දත්ත කියවන ආකාරය මෙහිදී ඔබට දැක ගත හැකිය. නූල් ලිවීමෙන් තවත් HFiles ජනනය වන අතර ඒවා වෙනත් නූල් මගින් කියවනු ලැබේ. ප්රතිඵලයක් වශයෙන්, වැඩි වැඩියෙන් දත්ත මතකයෙන් ඉවත් කිරීමට අවශ්ය වන අතර අවසානයේ GC වැඩ කිරීමට පටන් ගනී, එය ප්රායෝගිකව සියලු වැඩ අඩාල කරයි. ප්රධාන සංයුක්ත දියත් කිරීම ප්රතිඵලයක් ලෙස සුන්බුන් ඉවත් කිරීම සහ ඵලදායිතාව ප්රතිෂ්ඨාපනය කිරීමට හේතු විය.

පරීක්ෂණය DataNodes 3 සහ RS 4 (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 නූල්) මත සිදු කරන ලදී. HBase අනුවාදය 1.2.0-cdh5.14.2

දත්ත සක්‍රියව ලියා කියවන ලද “සජීවී” වගුවක් මත ප්‍රධාන සංයුක්තය දියත් කර ඇති බව සඳහන් කිරීම වටී. දත්ත කියවීමේදී මෙය වැරදි ප්‍රතිචාරයකට තුඩු දිය හැකි බවට අන්තර්ජාලයේ ප්‍රකාශයක් විය. පරීක්ෂා කිරීම සඳහා, නව දත්ත උත්පාදනය කර එය වගුවකට ලියන ක්රියාවලියක් දියත් කරන ලදී. ඉන් පසුව මම වහාම කියවා එහි ප්‍රතිඵලයක් ලෙස ලැබෙන අගය ලියා ඇති දේ සමඟ සමපාත වේදැයි පරීක්ෂා කළෙමි. මෙම ක්‍රියාවලිය ක්‍රියාත්මක වන අතරතුර, ප්‍රධාන සම්පීඩනය 200 වාරයක් පමණ ධාවනය වූ අතර එකදු අසාර්ථකත්වයක් වාර්තා නොවීය. සමහර විට ගැටලුව දිස්වන්නේ කලාතුරකිනි සහ අධික බර පැටවීමේදී පමණි, එබැවින් සැලසුම් කර ඇති පරිදි ලිවීමේ සහ කියවීමේ ක්‍රියාවලීන් නැවැත්වීම සහ එවැනි GC ඇඳීම් වළක්වා ගැනීම සඳහා පිරිසිදු කිරීම සිදු කිරීම ආරක්ෂිත වේ.

එසේම, ප්‍රධාන සංයුක්ත කිරීම MemStore හි තත්වයට බලපාන්නේ නැත; එය තැටියට ෆ්ලෂ් කිරීමට සහ එය සංයුක්ත කිරීමට, ඔබ ෆ්ලෂ් භාවිතා කළ යුතුය (connection.getAdmin().flush(TableName.valueOf(tblName))).

8. සැකසුම් සහ කාර්ය සාධනය

දැනටමත් සඳහන් කර ඇති පරිදි, BulkLoad ක්‍රියාත්මක කිරීමේදී කිසිවක් කිරීමට අවශ්‍ය නොවන තැන HBase එහි විශාලතම සාර්ථකත්වය පෙන්නුම් කරයි. කෙසේ වෙතත්, මෙය බොහෝ පද්ධති සහ පුද්ගලයන් සඳහා අදාළ වේ. කෙසේ වෙතත්, මෙම මෙවලම විශාල කුට්ටි වල දත්ත තොග වශයෙන් ගබඩා කිරීම සඳහා වඩාත් සුදුසු වන අතර, ක්‍රියාවලියට තරඟකාරී කියවීම සහ ලිවීමේ ඉල්ලීම් කිහිපයක් අවශ්‍ය නම්, ඉහත විස්තර කර ඇති Get and Put විධානයන් භාවිතා වේ. ප්‍රශස්ත පරාමිතීන් තීරණය කිරීම සඳහා, වගු පරාමිතීන් සහ සැකසුම් වල විවිධ සංයෝජන සමඟ දියත් කිරීම් සිදු කරන ලදී:

• නූල් 10 ක් එකවර 3 වතාවක් එකවර දියත් කරන ලදී (මෙය නූල් බ්ලොක් එකක් ලෙස හඳුන්වමු).
• බ්ලොක් එකක සියලුම නූල් වල මෙහෙයුම් කාලය සාමාන්යය වන අතර එය බ්ලොක් මෙහෙයුමේ අවසාන ප්රතිඵලය විය.
• සියලුම නූල් එකම වගුව සමඟ වැඩ කළා.
• නූල් බ්ලොක් එකේ එක් එක් ආරම්භයට පෙර, ප්රධාන සංයුක්ත කිරීමක් සිදු කරන ලදී.
• සෑම බ්ලොක් එකක්ම සිදු කළේ පහත සඳහන් මෙහෙයුම් වලින් එකක් පමණි:

- දමන්න
- ලබා ගන්න
- ගන්න+ දාන්න

• සෑම බ්ලොක් එකක්ම එහි ක්‍රියාකාරිත්වයේ පුනරාවර්තන 50 ක් සිදු කළේය.
• වාර්තාවක වාරණ ප්‍රමාණය බයිට් 100, බයිට් 1000 හෝ බයිට් 10000 (අහඹු) වේ.
• විවිධ ඉල්ලූ යතුරු සංඛ්‍යාවක් (එක් යතුරක් හෝ 10ක්) සමඟ බ්ලොක් දියත් කරන ලදී.
• බ්ලොක් විවිධ වගු සැකසුම් යටතේ ධාවනය විය. පරාමිති වෙනස් විය:

— BlockCache = සක්‍රිය හෝ අක්‍රිය කර ඇත
— BlockSize = 65 KB හෝ 16 KB
- කොටස් = 1, 5 හෝ 30
— MSLAB = සක්‍රීය හෝ අබල කර ඇත

එබැවින් බ්ලොක් එක මේ වගේ ය:

ඒ. MSLAB මාදිලිය සක්‍රිය/අක්‍රිය කර ඇත.
බී. පහත පරාමිතීන් සකසා ඇති වගුවක් සාදන ලදී: BlockCache = true/none, BlockSize = 65/16 Kb, Partition = 1/5/30.
c. සම්පීඩනය GZ ලෙස සකසා ඇත.
ඈ මෙම වගුවට බයිට් 10/1/10 ක වාර්තා සහිත 100/1000 දැමීම / ලබා ගැනීම / ලබා ගැනීම + දැමීමේ මෙහෙයුම් සිදු කරමින් නූල් 10000 ක් එකවර දියත් කරන ලදී, පේළියක විමසුම් 50 ක් සිදු කරයි (අහඹු යතුරු).
ඊ. ලක්ෂ්‍යය d තුන් වතාවක් පුනරාවර්තනය විය.
f. සියලුම නූල් වල මෙහෙයුම් කාලය සාමාන්යය විය.

හැකි සියලුම සංයෝජන පරීක්ෂා කර ඇත. වාර්තාගත ප්‍රමාණය වැඩි වන විට වේගය පහත වැටෙනු ඇතැයි පුරෝකථනය කළ හැකිය, නැතහොත් හැඹිලිගත කිරීම අක්‍රිය කිරීම මන්දගාමී වීමට හේතු වේ. කෙසේ වෙතත්, ඉලක්කය වූයේ එක් එක් පරාමිතියෙහි බලපෑමේ මට්ටම සහ වැදගත්කම අවබෝධ කර ගැනීමයි, එබැවින් එකතු කරන ලද දත්ත රේඛීය ප්‍රතිගාමී ශ්‍රිතයක ආදානයට ලබා දෙන අතර එමඟින් t-සංඛ්‍යාලේඛන භාවිතයෙන් වැදගත්කම තක්සේරු කිරීමට හැකි වේ. Put මෙහෙයුම් සිදු කරන බ්ලොක් වල ප්‍රතිඵල පහත දැක්වේ. සම්පූර්ණ සංයෝජන කට්ටලය 2 * 2 * 3 * 2 * 3 = 144 විකල්ප + 72 tk. සමහරක් දෙපාරක් කළා. ඒ අනුව මුළු ලකුණු 216යි.

DataNodes 3 සහ RS 4 (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 නූල්) වලින් සමන්විත කුඩා පොකුරක් මත පරීක්ෂණ සිදු කරන ලදී. HBase අනුවාදය 1.2.0-cdh5.14.2.

BlockCache සක්‍රීය කර ඇති, BlockSize = 3.7, බයිට් 16ක වාර්තා, පැකේජයකට කෑලි 100 බැගින් එක් කොටසක් සහිත මේසයක් මත MSLAB මාදිලිය ක්‍රියා විරහිත කර තත්පර 10ක ඉහළම ඇතුළත් කිරීමේ වේගය ලබා ගන්නා ලදී.
BlockCache සක්‍රීය කර ඇති, BlockSize = 82.8, බයිට් 16 ක වාර්තා, එක් කොටසක් සහිත මේසයක් මත, MSLAB මාදිලිය සක්‍රීය කර ඇති, තත්පර 10000 ක අඩුම ඇතුළත් කිරීමේ වේගය ලබා ගන්නා ලදී.

දැන් අපි ආකෘතිය දෙස බලමු. R2 මත පදනම් වූ ආකෘතියේ හොඳ ගුණාත්මක භාවය අපට පෙනේ, නමුත් මෙහි Extrapolation contraindicated බව සම්පූර්ණයෙන්ම පැහැදිලිය. පරාමිති වෙනස් වන විට පද්ධතියේ සැබෑ හැසිරීම රේඛීය නොවේ; මෙම ආකෘතිය අවශ්‍ය වන්නේ අනාවැකි සඳහා නොව, දී ඇති පරාමිතීන් තුළ සිදු වූ දේ තේරුම් ගැනීමට ය. උදාහරණයක් ලෙස, මෙහිදී අපි සිසුන්ගේ නිර්ණායකයෙන් දකිමු BlockSize සහ BlockCache පරාමිතීන් Put මෙහෙයුම සඳහා වැදගත් නොවේ (එය සාමාන්‍යයෙන් තරමක් පුරෝකථනය කළ හැකිය):

නමුත් කොටස් ගණන වැඩි කිරීම කාර්ය සාධනය අඩුවීමට හේතු වන බව තරමක් අනපේක්ෂිත ය (BulkLoad සමඟ කොටස් ගණන වැඩි කිරීමේ ධනාත්මක බලපෑම අප දැනටමත් දැක ඇත), තේරුම් ගත හැකි වුවද. පළමුව, සැකසීම සඳහා, ඔබ එක් කලාපයක් වෙනුවට කලාප 30 කට ඉල්ලීම් ජනනය කළ යුතු අතර, දත්ත පරිමාව ප්‍රතිලාභයක් ලබා දෙන පරිදි නොවේ. දෙවනුව, සම්පූර්ණ මෙහෙයුම් කාලය තීරණය වන්නේ මන්දගාමීම RS වලින් වන අතර, DataNodes ගණන RS ගණනට වඩා අඩු බැවින්, සමහර කලාපවල ශුන්‍ය ප්‍රදේශයක් ඇත. හොඳයි, අපි පළමු පහ දෙස බලමු:

දැන් අපි Get blocks ක්‍රියාත්මක කිරීමේ ප්‍රතිඵල තක්සේරු කරමු:

කොටස් ගණනේ වැදගත්කම නැති වී ඇත, එය දත්ත හොඳින් හැඹිලිගත කර ඇති අතර කියවීමේ හැඹිලිය වඩාත්ම වැදගත් (සංඛ්‍යානමය) පරාමිතිය වන නිසා එය පැහැදිලි කළ හැකිය. ස්වාභාවිකවම, ඉල්ලීමක පණිවිඩ ගණන වැඩි කිරීම කාර්ය සාධනය සඳහා ඉතා ප්රයෝජනවත් වේ. ඉහළම ලකුණු:

හොඳයි, අවසාන වශයෙන්, අපි මුලින්ම ලබා ගත් බ්ලොක් එකේ ආකෘතිය දෙස බලමු, ඉන්පසු තබන්න:

සියලුම පරාමිතීන් මෙහි වැදගත් වේ. සහ නායකයින්ගේ ප්රතිඵල:

9. බර පරීක්ෂා කිරීම

හොඳයි, අවසාන වශයෙන් අපි වැඩි හෝ අඩු හොඳ බරක් දියත් කරන්නෙමු, නමුත් ඔබට සැසඳීමට යමක් ඇති විට එය සැමවිටම වඩාත් සිත්ගන්නා සුළුය. Cassandra හි ප්‍රධාන සංවර්ධකයා වන DataStax වෙබ් අඩවියේ ඇත результаты HBase අනුවාදය 0.98.6-1 ඇතුළුව NoSQL ගබඩා ගණනාවක NT. පැටවීම නූල් 40 ක්, දත්ත ප්රමාණය බයිට් 100 ක්, SSD තැටි මගින් සිදු කරන ලදී. Read-Modify-Write මෙහෙයුම් පරීක්ෂා කිරීමේ ප්‍රතිඵලය පහත ප්‍රතිඵල පෙන්වයි.

මට වැටහෙන පරිදි, කියවීම් වාර්තා 100 ක කොටස්වල සිදු කරන ලද අතර, HBase නෝඩ් 16 ක් සඳහා, DataStax පරීක්ෂණය තත්පරයට මෙහෙයුම් 10 ක කාර්ය සාධනයක් පෙන්නුම් කළේය.

අපගේ පොකුරට ද නෝඩ් 16ක් තිබීම වාසනාවකි, නමුත් එක් එක් කෝර් (නූල්) 64ක් තිබීම එතරම් “වාසනාවන්ත” නොවේ, ඩේටාස්ටැක්ස් පරීක්ෂණයේදී ඇත්තේ 4ක් පමණි. අනෙක් අතට, ඔවුන් සතුව ඇත්තේ එස්එස්ඩී ඩ්‍රයිව් වන අතර, අපට HDD තිබේ. හෝ ඊට වැඩි ගණනක් පැටවීමේදී HBase සහ CPU භාවිතයේ නව අනුවාදය ප්‍රායෝගිකව සැලකිය යුතු ලෙස වැඩි නොවීය (දෘෂ්‍යව සියයට 5-10 කින්). කෙසේ වෙතත්, මෙම වින්‍යාසය භාවිතා කිරීම ආරම්භ කිරීමට උත්සාහ කරමු. පෙරනිමි වගු සැකසීම්, කියවීම අහඹු ලෙස මිලියන 0 සිට 50 දක්වා යතුරු පරාසය තුළ සිදු කෙරේ (එනම්, සෑම අවස්ථාවකම අත්යවශ්යයෙන්ම නව). වගුව කොටස් 50 කට බෙදා ඇති වාර්තා මිලියන 64 ක් අඩංගු වේ. crc32 භාවිතයෙන් යතුරු හැෂ් කර ඇත. වගු සැකසීම් පෙරනිමිය, MSLAB සබල කර ඇත. නූල් 40ක් දියත් කරමින්, සෑම ත්‍රෙඩ් එකක්ම සසම්භාවී යතුරු 100ක කට්ටලයක් කියවන අතර වහාම ජනනය කරන ලද බයිට් 100 මෙම යතුරු වෙත නැවත ලියයි.

ස්ථාවරය: 16 DataNode සහ 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 නූල්). HBase අනුවාදය 1.2.0-cdh5.14.2.

සාමාන්‍ය ප්‍රති result ලය තත්පරයකට මෙහෙයුම් 40 දහසකට ආසන්න වන අතර එය DataStax පරීක්ෂණයට වඩා සැලකිය යුතු ලෙස වඩා හොඳය. කෙසේ වෙතත්, පර්යේෂණාත්මක අරමුණු සඳහා, ඔබට කොන්දේසි තරමක් වෙනස් කළ හැකිය. සියලුම වැඩ කටයුතු එක් මේසයක් මත පමණක් සිදුවනු ඇති අතර අද්විතීය යතුරු මත පමණක් සිදුවනු ඇතැයි සිතිය නොහැක. ප්‍රධාන භාරය ජනනය කරන නිශ්චිත “උණුසුම්” යතුරු කට්ටලයක් ඇතැයි උපකල්පනය කරමු. එබැවින්, විශාල වාර්තා (10 KB) සහිත බරක් නිර්මාණය කිරීමට උත්සාහ කරමු, විවිධ වගු 100 කින් සහ 4 කාණ්ඩ වලින් සහ ඉල්ලූ යතුරු පරාසය 50 දක්වා සීමා කරන්න. පහත ප්‍රස්ථාරයෙන් නූල් 40 ක් දියත් කිරීම පෙන්වයි, සෑම නූල් එකක්ම කියවයි යතුරු 100 ක කට්ටලයක් සහ වහාම මෙම යතුරු මත අහඹු ලෙස 10 KB ලියන්න.

ස්ථාවරය: 16 DataNode සහ 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 නූල්). HBase අනුවාදය 1.2.0-cdh5.14.2.

භාරය අතරතුර, ඉහත පෙන්වා ඇති පරිදි, ප්‍රධාන සංයුක්ත කිරීම කිහිප වතාවක් දියත් කරන ලදී, මෙම ක්‍රියා පටිපාටිය නොමැතිව, කාර්ය සාධනය ක්‍රමයෙන් පිරිහෙනු ඇත, කෙසේ වෙතත්, ක්‍රියාත්මක කිරීමේදී අමතර බරක් ද පැන නගී. ඇද වැටීම් විවිධ හේතු නිසා සිදු වේ. සමහර විට නූල් වැඩ අවසන් වූ අතර ඒවා නැවත ආරම්භ කරන විට විරාමයක් ඇති විය, සමහර විට තෙවන පාර්ශවීය යෙදුම් පොකුර මත බරක් නිර්මාණය කළේය.

කියවීම සහ වහාම ලිවීම HBase සඳහා වඩාත්ම දුෂ්කර වැඩ අවස්ථාවන්ගෙන් එකකි. ඔබ කුඩා ඉල්ලීම් පමණක් කරන්නේ නම්, උදාහරණයක් ලෙස බයිට් 100 ක්, ඒවා කෑලි 10-50 දහසක් ඇසුරුම්වලට ඒකාබද්ධ කිරීම, ඔබට තත්පරයකට මෙහෙයුම් සිය දහස් ගණනක් ලබා ගත හැකි අතර, කියවීමට පමණක් ඉල්ලීම් සමඟ තත්වය සමාන වේ. ප්‍රතිඵල DataStax විසින් ලබාගත් ඒවාට වඩා රැඩිකල් ලෙස වඩා හොඳ බව සඳහන් කිරීම වටී, සියල්ලටම වඩා 50 ක කුට්ටි වල ඉල්ලීම් හේතුවෙන්.

ස්ථාවරය: 16 DataNode සහ 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 නූල්). HBase අනුවාදය 1.2.0-cdh5.14.2.

10. නිගමන

මෙම පද්ධතිය තරමක් නම්‍යශීලී ලෙස වින්‍යාස කර ඇත, නමුත් පරාමිති විශාල සංඛ්‍යාවක බලපෑම තවමත් නොදනී. ඒවායින් සමහරක් පරීක්ෂාවට ලක් කර ඇත, නමුත් ප්රතිඵල පරීක්ෂණ කට්ටලයට ඇතුළත් කර නැත. උදාහරණයක් ලෙස, අහඹු ලෙස ජනනය කරන ලද දත්ත සඳහා තේරුම් ගත හැකි අසල්වැසි සෛලවල අගයන් භාවිතයෙන් තොරතුරු කේතනය කරන DATA_BLOCK_ENCODING වැනි පරාමිතියක නොවැදගත් වැදගත්කමක් මූලික අත්හදා බැලීම්වලින් පෙන්නුම් කෙරේ. ඔබ අනුපිටපත් වස්තු විශාල සංඛ්යාවක් භාවිතා කරන්නේ නම්, ලාභය සැලකිය යුතු විය හැකිය. සාමාන්‍යයෙන්, අපට පැවසිය හැක්කේ HBase තරමක් බැරෑරුම් සහ හොඳින් සිතා බලා දත්ත සමුදායක් පිළිබඳ හැඟීමක් ලබා දෙන බවයි, එය විශාල දත්ත කොටස් සමඟ මෙහෙයුම් සිදු කිරීමේදී තරමක් ඵලදායි විය හැකිය. විශේෂයෙන්ම කියවීමේ සහ ලිවීමේ ක්‍රියාවලීන් නියමිත වේලාවට වෙන් කිරීමට හැකි නම්.

ඔබේ අදහසේ ප්‍රමාණවත් ලෙස හෙළි නොකළ දෙයක් ඇත්නම්, මම ඔබට වඩාත් විස්තරාත්මකව කියන්නට සූදානම්. ඔබගේ අත්දැකීම් බෙදා ගැනීමට හෝ ඔබ යම් දෙයකට එකඟ නොවන්නේ නම් සාකච්ඡා කිරීමට අපි ඔබට ආරාධනා කරන්නෙමු.

මූලාශ්රය: www.habr.com