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. عمومی فن تعمیر

بیک اپ ماسٹر زو کیپر نوڈ پر ایکٹو کے دل کی دھڑکن کو سنتا ہے اور غائب ہونے کی صورت میں ماسٹر کے کاموں کو سنبھالتا ہے۔

2. HBASE پر ڈیٹا لکھیں۔

سب سے پہلے، آئیے سب سے آسان کیس کو دیکھیں - put(rowkey) کا استعمال کرتے ہوئے ٹیبل پر کلیدی قدر والی چیز لکھیں۔ کلائنٹ کو پہلے یہ معلوم کرنا چاہیے کہ روٹ ریجن سرور (RRS)، جو hbase:meta table کو ذخیرہ کرتا ہے، کہاں واقع ہے۔ وہ یہ معلومات زو کیپر سے حاصل کرتا ہے۔ جس کے بعد یہ RRS تک رسائی حاصل کرتا ہے اور hbase:meta ٹیبل کو پڑھتا ہے، جس سے یہ معلومات نکالتا ہے کہ کون سا RegionServer (RS) دلچسپی کے ٹیبل میں دیے گئے rowkey کے لیے ڈیٹا اسٹور کرنے کا ذمہ دار ہے۔ مستقبل کے استعمال کے لیے، میٹا ٹیبل کو کلائنٹ کے ذریعے کیش کیا جاتا ہے اور اس لیے بعد میں آنے والی کالیں براہ راست RS تک جاتی ہیں۔

اس کے بعد، RS، درخواست موصول ہونے کے بعد، سب سے پہلے اسے WriteAheadLog (WAL) پر لکھتا ہے، جو حادثے کی صورت میں بحالی کے لیے ضروری ہے۔ پھر ڈیٹا کو MemStore میں محفوظ کرتا ہے۔ یہ میموری میں ایک بفر ہے جس میں دیئے گئے علاقے کے لیے کلیدوں کا ترتیب شدہ سیٹ ہوتا ہے۔ ایک میز کو خطوں (پارٹیشنز) میں تقسیم کیا جا سکتا ہے، جن میں سے ہر ایک میں چابیاں کا ایک جداگانہ سیٹ ہوتا ہے۔ یہ آپ کو اعلی کارکردگی حاصل کرنے کے لیے مختلف سرورز پر علاقوں کو رکھنے کی اجازت دیتا ہے۔ تاہم، اس بیان کے واضح ہونے کے باوجود، ہم بعد میں دیکھیں گے کہ یہ تمام معاملات میں کام نہیں کرتا ہے۔

میم اسٹور میں اندراج رکھنے کے بعد، کلائنٹ کو جواب دیا جاتا ہے کہ اندراج کامیابی کے ساتھ محفوظ ہو گیا تھا۔ تاہم، حقیقت میں یہ صرف ایک بفر میں ذخیرہ کیا جاتا ہے اور ایک مخصوص مدت گزر جانے کے بعد یا نئے ڈیٹا سے بھر جانے کے بعد ہی ڈسک پر پہنچتا ہے۔

"ڈیلیٹ" آپریشن کرتے وقت، ڈیٹا کو جسمانی طور پر حذف نہیں کیا جاتا ہے۔ انہیں صرف حذف شدہ کے طور پر نشان زد کیا گیا ہے، اور تباہی بذات خود بڑے کمپیکٹ فنکشن کو کال کرنے کے وقت واقع ہوتی ہے، جسے پیراگراف 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 پر مشتمل کلسٹر پر بوٹ کے نتائج ہیں۔

یہاں آپ دیکھ سکتے ہیں کہ ٹیبل میں پارٹیشنز (علاقوں) کی تعداد میں اضافہ کرنے کے ساتھ ساتھ اسپارک ایگزیکیوٹرز، ہمیں ڈاؤن لوڈ کی رفتار میں اضافہ ہوتا ہے۔ اس کے علاوہ، رفتار ریکارڈنگ کے حجم پر منحصر ہے. بڑے بلاکس MB/sec میں اضافہ کرتے ہیں، چھوٹے بلاکس فی یونٹ وقت کے داخل کردہ ریکارڈز کی تعداد میں، باقی تمام چیزیں برابر ہیں۔

آپ ایک ہی وقت میں دو ٹیبلز میں لوڈ کرنا بھی شروع کر سکتے ہیں اور دوگنی رفتار حاصل کر سکتے ہیں۔ ذیل میں آپ دیکھ سکتے ہیں کہ دو ٹیبلز پر ایک ساتھ 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 میں کی جاتی ہے۔ اس سے قطع نظر کہ وہاں ڈیٹا موجود ہے یا نہیں، تلاش BlockCache بفر میں اور اگر ضروری ہو تو HFiles میں بھی کی جاتی ہے۔ اگر فائل میں ڈیٹا پایا جاتا ہے، تو اسے BlockCache میں رکھا جاتا ہے اور اگلی درخواست پر اسے تیزی سے واپس کر دیا جائے گا۔ بلوم فلٹر کے استعمال کی بدولت HFile میں تلاش کرنا نسبتاً تیز ہے، یعنی تھوڑی مقدار میں ڈیٹا پڑھنے کے بعد، یہ فوری طور پر تعین کرتا ہے کہ آیا اس فائل میں مطلوبہ کلید ہے اور اگر نہیں، تو اگلی فائل پر چلی جاتی ہے۔

ان تین ذرائع سے ڈیٹا حاصل کرنے کے بعد، RS ایک ردعمل پیدا کرتا ہے۔ خاص طور پر، اگر کلائنٹ نے ورژننگ کی درخواست کی ہے تو یہ ایک ہی وقت میں کسی چیز کے کئی پائے جانے والے ورژنز کو منتقل کر سکتا ہے۔

4. ڈیٹا کیشنگ

MemStore اور BlockCache بفرز مختص شدہ آن ہیپ RS میموری کا 80% تک قابض ہیں (باقی RS سروس کے کاموں کے لیے مخصوص ہے)۔ اگر عام استعمال کا موڈ ایسا ہے کہ اسی ڈیٹا کو فوری طور پر لکھنے اور پڑھنے پر عمل کرتا ہے، تو BlockCache کو کم کرنا اور MemStore کو بڑھانا سمجھ میں آتا ہے، کیونکہ جب ڈیٹا لکھنا پڑھنے کے لیے کیشے میں نہیں آتا ہے، تو BlockCache کو کم کثرت سے استعمال کیا جائے گا۔ BlockCache بفر دو حصوں پر مشتمل ہے: LruBlockCache (ہمیشہ آن ہیپ) اور BucketCache (عام طور پر آف ہیپ یا SSD پر)۔ BucketCache کو اس وقت استعمال کیا جانا چاہئے جب پڑھنے کی بہت سی درخواستیں ہوں اور وہ LruBlockCache میں فٹ نہیں ہوتی ہیں، جس کی وجہ سے گاربیج کلیکٹر کا کام فعال ہوتا ہے۔ ایک ہی وقت میں، آپ کو پڑھنے والے کیشے کے استعمال سے کارکردگی میں بنیادی اضافے کی توقع نہیں رکھنی چاہیے، لیکن ہم پیراگراف 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. بیچ ڈیٹا پروسیسنگ ملٹی گیٹ/ملٹی پٹ

واحد درخواستوں پر کارروائی کرنا (گیٹ/پٹ/ڈیلیٹ) کافی مہنگا آپریشن ہے، لہذا اگر ممکن ہو تو، آپ کو انہیں ایک فہرست یا فہرست میں یکجا کرنا چاہیے، جس سے آپ کو کارکردگی میں نمایاں اضافہ حاصل ہو سکتا ہے۔ یہ خاص طور پر لکھنے کے عمل کے لیے درست ہے، لیکن پڑھتے وقت مندرجہ ذیل خرابی ہوتی ہے۔ نیچے کا گراف MemStore سے 50 ریکارڈز پڑھنے کا وقت دکھاتا ہے۔ ریڈنگ ایک تھریڈ میں کی گئی تھی اور افقی محور درخواست میں کیز کی تعداد کو ظاہر کرتا ہے۔ یہاں آپ دیکھ سکتے ہیں کہ جب ایک درخواست میں ایک ہزار کلیدوں تک بڑھتے ہوئے، عمل درآمد کا وقت گر جاتا ہے، یعنی رفتار بڑھ جاتی ہے. تاہم، ڈیفالٹ کے طور پر MSLAB موڈ فعال ہونے کے ساتھ، اس حد کے بعد کارکردگی میں بنیادی کمی شروع ہو جاتی ہے، اور ریکارڈ میں ڈیٹا کی مقدار جتنی زیادہ ہوگی، آپریٹنگ کا وقت اتنا ہی لمبا ہوگا۔

ٹیسٹ ایک ورچوئل مشین، 8 کور، ورژن HBase 2.0.0-cdh6.0.0-beta1 پر کیے گئے۔

MSLAB موڈ کو ہیپ فریگمنٹیشن کو کم کرنے کے لیے ڈیزائن کیا گیا ہے، جو کہ نئی اور پرانی نسل کے ڈیٹا کے اختلاط کی وجہ سے ہوتا ہے۔ ایک کام کے طور پر، جب MSLAB کو فعال کیا جاتا ہے، ڈیٹا کو نسبتاً چھوٹے سیلز (ٹکڑوں) میں رکھا جاتا ہے اور ٹکڑوں میں پروسیس کیا جاتا ہے۔ نتیجے کے طور پر، جب درخواست کردہ ڈیٹا پیکٹ کا حجم مختص سائز سے زیادہ ہو جاتا ہے، تو کارکردگی تیزی سے گر جاتی ہے۔ دوسری طرف، اس موڈ کو آف کرنا بھی مناسب نہیں ہے، کیونکہ یہ ڈیٹا پراسیسنگ کے انتہائی لمحات کے دوران GC کی وجہ سے رک جائے گا۔ ایک اچھا حل یہ ہے کہ ایکٹو رائٹنگ کے معاملے میں سیل والیوم کو ایک ہی وقت میں پڑھنے کے ساتھ ہی ڈال کر بڑھایا جائے۔ یہ بات قابل غور ہے کہ اگر ریکارڈنگ کے بعد، آپ فلش کمانڈ چلاتے ہیں، جو MemStore کو ڈسک پر ری سیٹ کرتا ہے، یا اگر آپ بلک لوڈ کا استعمال کرتے ہوئے لوڈ کرتے ہیں تو یہ مسئلہ پیدا نہیں ہوتا ہے۔ نیچے دی گئی جدول سے پتہ چلتا ہے کہ MemStore سے بڑے (اور اسی رقم) ڈیٹا کے لیے سوالات سست روی کا باعث بنتے ہیں۔ تاہم، chunksize کو بڑھا کر ہم پروسیسنگ کے وقت کو معمول پر لاتے ہیں۔

chunksize بڑھانے کے علاوہ، ڈیٹا کو علاقے کے لحاظ سے تقسیم کرنے میں مدد ملتی ہے، یعنی میز کی تقسیم. اس کے نتیجے میں ہر علاقے میں کم درخواستیں آتی ہیں اور اگر وہ سیل میں فٹ ہوجاتی ہیں تو جواب اچھا رہتا ہے۔

6. میزوں کو علاقوں میں تقسیم کرنے کی حکمت عملی (تقسیم)

چونکہ HBase کلیدی قدر کا ذخیرہ ہے اور تقسیم کلید کے ذریعے کی جاتی ہے، اس لیے تمام خطوں میں ڈیٹا کو یکساں طور پر تقسیم کرنا انتہائی ضروری ہے۔ مثال کے طور پر، اس طرح کے ٹیبل کو تین حصوں میں تقسیم کرنے کے نتیجے میں ڈیٹا کو تین علاقوں میں تقسیم کیا جائے گا:

ایسا ہوتا ہے کہ یہ تیز رفتار سست روی کا باعث بنتا ہے اگر بعد میں لوڈ کردہ ڈیٹا کی طرح لگتا ہے، مثال کے طور پر، لمبی قدریں، جن میں سے اکثر ایک ہی ہندسے سے شروع ہوتی ہیں، مثال کے طور پر:

1000001
1000002
...
1100003

چونکہ چابیاں بائٹ اری کے طور پر محفوظ کی جاتی ہیں، اس لیے وہ سب ایک ہی طرح سے شروع ہوں گی اور ان کا تعلق ایک ہی خطہ نمبر 1 سے ہو گا جس کی اس رینج کو ذخیرہ کیا جا رہا ہے۔ تقسیم کی کئی حکمت عملییں ہیں:

HexStringSplit - کلید کو "00000000" => "FFFFFFFF" رینج میں ایک ہیکساڈیسیمل انکوڈ شدہ سٹرنگ میں بدلتا ہے اور بائیں طرف زیرو کے ساتھ پیڈنگ کرتا ہے۔

یونیفارم اسپلٹ - "00" => "FF" رینج میں ہیکساڈیسیمل انکوڈنگ کے ساتھ کلید کو بائٹ سرنی میں بدلتا ہے اور صفر کے ساتھ دائیں طرف پیڈنگ کرتا ہے۔

اس کے علاوہ، آپ تقسیم کرنے کے لیے کسی بھی رینج یا کلیدوں کے سیٹ کی وضاحت کر سکتے ہیں اور خودکار تقسیم کو ترتیب دے سکتے ہیں۔ تاہم، سب سے آسان اور موثر طریقہ یونیفارم اسپلٹ اور ہیش کنکٹنیشن کا استعمال ہے، مثال کے طور پر CRC32 (rowkey) فنکشن اور خود rowkey کے ذریعے کلید کو چلانے سے بائٹس کا سب سے اہم جوڑا:

hash + rowkey

پھر تمام ڈیٹا تمام خطوں میں یکساں طور پر تقسیم کیا جائے گا۔ پڑھتے وقت، پہلے دو بائٹس کو صرف رد کر دیا جاتا ہے اور اصل کلید باقی رہتی ہے۔ RS خطے میں ڈیٹا اور کیز کی مقدار کو بھی کنٹرول کرتا ہے اور اگر حد سے تجاوز کر جائے تو اسے خود بخود حصوں میں تقسیم کر دیتا ہے۔

7. غلطی کی رواداری اور ڈیٹا لوکلٹی

چونکہ کلیدوں کے ہر سیٹ کے لیے صرف ایک خطہ ذمہ دار ہے، اس لیے RS کے کریش ہونے یا ڈیکمیشن سے منسلک مسائل کا حل HDFS میں تمام ضروری ڈیٹا کو اسٹور کرنا ہے۔ جب RS گرتا ہے، تو ماسٹر زو کیپر نوڈ پر دل کی دھڑکن کی عدم موجودگی کے ذریعے اس کا پتہ لگاتا ہے۔ پھر یہ پیش کردہ علاقے کو دوسرے RS کو تفویض کرتا ہے اور چونکہ HFiles تقسیم شدہ فائل سسٹم میں محفوظ ہوتے ہیں، اس لیے نیا مالک انہیں پڑھتا ہے اور ڈیٹا کی خدمت جاری رکھتا ہے۔ تاہم، چونکہ کچھ ڈیٹا MemStore میں ہو سکتا ہے اور HFiles میں جانے کا وقت نہیں ہے، WAL، جو HDFS میں بھی محفوظ ہے، آپریشن کی تاریخ کو بحال کرنے کے لیے استعمال کیا جاتا ہے۔ تبدیلیوں کے لاگو ہونے کے بعد، RS درخواستوں کا جواب دینے کے قابل ہو جاتا ہے، لیکن اس اقدام سے اس حقیقت کی طرف جاتا ہے کہ کچھ ڈیٹا اور ان کی خدمت کرنے والے عمل مختلف نوڈس پر ختم ہوتے ہیں، یعنی مقامی آبادی کم ہو رہی ہے.

مسئلہ کا حل بڑا کمپیکشن ہے - یہ طریقہ کار فائلوں کو ان نوڈس پر منتقل کرتا ہے جو ان کے ذمہ دار ہیں (جہاں ان کے علاقے واقع ہیں)، جس کے نتیجے میں اس طریقہ کار کے دوران نیٹ ورک اور ڈسک پر بوجھ تیزی سے بڑھ جاتا ہے۔ تاہم، مستقبل میں، ڈیٹا تک رسائی کو نمایاں طور پر تیز کیا جائے گا۔ اس کے علاوہ، major_compaction تمام HFiles کو ایک علاقے کے اندر ایک فائل میں ضم کرنے کا کام انجام دیتا ہے، اور ٹیبل کی ترتیبات کے لحاظ سے ڈیٹا کو بھی صاف کرتا ہے۔ مثال کے طور پر، آپ کسی آبجیکٹ کے ورژنز کی تعداد بتا سکتے ہیں جنہیں برقرار رکھا جانا چاہیے یا زندگی بھر جس کے بعد آبجیکٹ کو جسمانی طور پر حذف کر دیا گیا ہے۔

یہ طریقہ کار HBase کے آپریشن پر بہت مثبت اثر ڈال سکتا ہے۔ نیچے دی گئی تصویر سے پتہ چلتا ہے کہ فعال ڈیٹا ریکارڈنگ کے نتیجے میں کارکردگی کس طرح گر گئی۔ یہاں آپ دیکھ سکتے ہیں کہ کس طرح 40 تھریڈز ایک ٹیبل پر لکھتے ہیں اور 40 تھریڈ بیک وقت ڈیٹا کو پڑھتے ہیں۔ تھریڈز لکھنے سے زیادہ سے زیادہ HFiles پیدا ہوتے ہیں، جنہیں دوسرے تھریڈز پڑھتے ہیں۔ نتیجے کے طور پر، زیادہ سے زیادہ ڈیٹا کو میموری سے ہٹانے کی ضرورت ہے اور آخر کار جی سی کام کرنا شروع کر دیتا ہے، جس سے تمام کام عملی طور پر مفلوج ہو جاتے ہیں۔ بڑے کمپیکشن کے آغاز کے نتیجے میں ملبے کو صاف کرنے اور پیداواری صلاحیت کی بحالی کا باعث بنا۔

ٹیسٹ 3 DataNodes اور 4 RS (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)۔
• بلاکس مختلف میز کی ترتیبات کے تحت چلائے گئے تھے۔ پیرامیٹرز کو تبدیل کیا گیا:

- بلاک کیچ = آن یا آف
- بلاک سائز = 65 KB یا 16 KB
پارٹیشنز = 1، 5 یا 30
MSLAB = فعال یا غیر فعال

تو بلاک اس طرح لگتا ہے:

a MSLAB موڈ کو آن/آف کر دیا گیا تھا۔
ب ایک ٹیبل بنایا گیا تھا جس کے لیے درج ذیل پیرامیٹرز سیٹ کیے گئے تھے: BlockCache = true/none، BlockSize = 65/16 Kb، Partition = 1/5/30۔
c کمپریشن GZ پر سیٹ کیا گیا تھا۔
d اس ٹیبل میں 10/1/10 بائٹس کے ریکارڈ کے ساتھ 100 دھاگوں کو بیک وقت 1000/10000 put/get/get+put آپریشنز کرتے ہوئے شروع کیا گیا تھا، لگاتار 50 سوالات (رینڈم کیز) کرتے ہوئے۔
e پوائنٹ ڈی کو تین بار دہرایا گیا۔
f تمام تھریڈز کے آپریٹنگ ٹائم کا اوسط لگایا گیا تھا۔

تمام ممکنہ امتزاج کی جانچ کی گئی۔ یہ پیشین گوئی کی جا سکتی ہے کہ ریکارڈ سائز بڑھنے کے ساتھ ہی رفتار کم ہو جائے گی، یا یہ کہ کیشنگ کو غیر فعال کرنے سے سست روی آئے گی۔ تاہم، مقصد ہر پیرامیٹر کے اثر و رسوخ کی ڈگری اور اہمیت کو سمجھنا تھا، لہٰذا جمع کردہ ڈیٹا کو لکیری ریگریشن فنکشن کے ان پٹ میں فیڈ کیا گیا، جس سے t-statistics کے استعمال سے اہمیت کا اندازہ لگانا ممکن ہو جاتا ہے۔ پوٹ آپریشنز کرنے والے بلاکس کے نتائج ذیل میں ہیں۔ مجموعہ کا مکمل سیٹ 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۔

3.7 سیکنڈ کی سب سے زیادہ اندراج کی رفتار MSLAB موڈ کو آف کرنے کے ساتھ حاصل کی گئی، ایک پارٹیشن کے ساتھ ایک ٹیبل پر، بلاک کیچ فعال، BlockSize = 16، 100 بائٹس کے ریکارڈ، 10 ٹکڑے فی پیک۔
82.8 سیکنڈ کی سب سے کم اندراج کی رفتار MSLAB موڈ فعال، ایک پارٹیشن کے ساتھ ٹیبل پر، BlockCache فعال کے ساتھ، BlockSize = 16، 10000 بائٹس کے ریکارڈ، 1 ہر ایک کے ساتھ حاصل کی گئی۔

اب ماڈل کو دیکھتے ہیں۔ ہم R2 پر مبنی ماڈل کے اچھے معیار کو دیکھتے ہیں، لیکن یہ بالکل واضح ہے کہ یہاں ایکسٹراپولیشن متضاد ہے۔ نظام کا اصل رویہ جب پیرامیٹرز تبدیل ہوتے ہیں تو لکیری نہیں ہوں گے؛ اس ماڈل کی ضرورت پیشین گوئیوں کے لیے نہیں، بلکہ یہ سمجھنے کے لیے ہے کہ دیے گئے پیرامیٹرز کے اندر کیا ہوا ہے۔ مثال کے طور پر، یہاں ہم طالب علم کے معیار سے دیکھتے ہیں کہ BlockSize اور BlockCache کے پیرامیٹرز Put آپریشن کے لیے کوئی فرق نہیں رکھتے (جو کہ عام طور پر کافی حد تک قابل قیاس ہے):

لیکن یہ حقیقت کہ پارٹیشنز کی تعداد میں اضافہ کارکردگی میں کمی کا باعث بنتا ہے کسی حد تک غیر متوقع ہے (ہم نے پہلے ہی بلک لوڈ کے ساتھ پارٹیشنز کی تعداد میں اضافے کے مثبت اثرات دیکھے ہیں)، اگرچہ قابل فہم ہے۔ سب سے پہلے، پروسیسنگ کے لیے، آپ کو ایک کے بجائے 30 خطوں میں درخواستیں جنریٹ کرنی ہوں گی، اور ڈیٹا کا حجم ایسا نہیں ہے کہ اس سے فائدہ حاصل ہو۔ دوم، کل آپریٹنگ وقت کا تعین سب سے سست RS سے ہوتا ہے، اور چونکہ ڈیٹا نوڈس کی تعداد RS کی تعداد سے کم ہے، اس لیے کچھ علاقوں میں صفر کی جگہ ہوتی ہے۔ ٹھیک ہے، آئیے سب سے اوپر پانچ کو دیکھتے ہیں:

اب آئیے گیٹ بلاکس پر عمل درآمد کے نتائج کا جائزہ لیتے ہیں:

پارٹیشنز کی تعداد نے اہمیت کھو دی ہے، جس کی شاید اس حقیقت سے وضاحت کی گئی ہے کہ ڈیٹا کو اچھی طرح سے کیش کیا گیا ہے اور پڑھا ہوا کیش سب سے اہم (اعداد و شمار کے لحاظ سے) پیرامیٹر ہے۔ قدرتی طور پر، درخواست میں پیغامات کی تعداد میں اضافہ کارکردگی کے لیے بھی بہت مفید ہے۔ ٹاپ سکور:

ٹھیک ہے، آخر میں، آئیے اس بلاک کے ماڈل کو دیکھتے ہیں جس نے پہلے حاصل کیا اور پھر ڈال دیا:

تمام پیرامیٹرز یہاں اہم ہیں۔ اور لیڈروں کے نتائج:

9. لوڈ ٹیسٹنگ

ٹھیک ہے، آخر میں ہم کم و بیش ایک معقول بوجھ شروع کریں گے، لیکن جب آپ کے پاس موازنہ کرنے کے لیے کچھ ہوتا ہے تو یہ ہمیشہ زیادہ دلچسپ ہوتا ہے۔ کیسینڈرا کے کلیدی ڈویلپر ڈیٹا اسٹیکس کی ویب سائٹ پر موجود ہے۔ نتائج متعدد NoSQL اسٹوریجز کا NT، بشمول HBase ورژن 0.98.6-1۔ لوڈنگ 40 تھریڈز، ڈیٹا سائز 100 بائٹس، ایس ایس ڈی ڈسک کے ذریعے کی گئی۔ Read-Modify-Write آپریشنز کی جانچ کے نتیجے میں درج ذیل نتائج سامنے آئے۔

جہاں تک میں سمجھتا ہوں، ریڈنگ 100 ریکارڈز کے بلاکس میں کی گئی اور 16 HBase نوڈس کے لیے، DataStax ٹیسٹ نے فی سیکنڈ 10 ہزار آپریشنز کی کارکردگی دکھائی۔

یہ خوش قسمتی ہے کہ ہمارے کلسٹر میں بھی 16 نوڈس ہیں، لیکن یہ بہت "خوش قسمت" نہیں ہے کہ ہر ایک میں 64 کور (تھریڈز) ہیں، جبکہ ڈیٹا سٹیکس ٹیسٹ میں صرف 4 ہیں۔ دوسری طرف، ان کے پاس ایس ایس ڈی ڈرائیوز ہیں، جبکہ ہمارے پاس ایچ ڈی ڈیز ہیں۔ یا اس سے زیادہ لوڈ کے دوران HBase اور CPU کے نئے ورژن کے استعمال میں عملی طور پر نمایاں اضافہ نہیں ہوا (بصری طور پر 5-10 فیصد)۔ تاہم، آئیے اس ترتیب کا استعمال شروع کرنے کی کوشش کرتے ہیں۔ ڈیفالٹ ٹیبل سیٹنگز، ریڈنگ کلیدی رینج میں 0 سے 50 ملین تک تصادفی طور پر کی جاتی ہے (یعنی ہر بار بنیادی طور پر نیا)۔ جدول میں 50 ملین ریکارڈز ہیں، جنہیں 64 پارٹیشنز میں تقسیم کیا گیا ہے۔ کلیدوں کو crc32 کا استعمال کرتے ہوئے ہیش کیا جاتا ہے۔ ٹیبل کی ترتیبات ڈیفالٹ ہیں، MSLAB فعال ہے۔ 40 تھریڈز لانچ کرتے ہوئے، ہر تھریڈ 100 رینڈم کیز کا ایک سیٹ پڑھتا ہے اور فوری طور پر تیار کردہ 100 بائٹس کو ان کیز پر لکھ دیتا ہے۔

اسٹینڈ: 16 ڈیٹا نوڈ اور 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 تھریڈز)۔ HBase ورژن 1.2.0-cdh5.14.2۔

اوسط نتیجہ فی سیکنڈ 40 ہزار آپریشنز کے قریب ہے، جو ڈیٹا سٹیکس ٹیسٹ کے مقابلے میں نمایاں طور پر بہتر ہے۔ تاہم، تجرباتی مقاصد کے لیے، آپ حالات کو قدرے تبدیل کر سکتے ہیں۔ یہ بالکل امکان نہیں ہے کہ تمام کام صرف ایک میز پر اور صرف منفرد چابیاں پر کئے جائیں گے. آئیے فرض کریں کہ کلیدوں کا ایک مخصوص "گرم" سیٹ ہے جو مرکزی بوجھ پیدا کرتا ہے۔ لہذا، آئیے بڑے ریکارڈز (10 KB) کے ساتھ ایک لوڈ بنانے کی کوشش کرتے ہیں، 100 کے بیچوں میں بھی، 4 مختلف جدولوں میں اور درخواست کردہ کیز کی حد کو 50 ہزار تک محدود کرتے ہیں۔ نیچے کا گراف 40 تھریڈز کے اجراء کو ظاہر کرتا ہے، ہر تھریڈ پڑھتا ہے۔ 100 کیز کا ایک سیٹ اور فوری طور پر ان کیز پر 10 KB بے ترتیب لکھتا ہے۔

اسٹینڈ: 16 ڈیٹا نوڈ اور 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 تھریڈز)۔ HBase ورژن 1.2.0-cdh5.14.2۔

لوڈ کے دوران، میجر کمپیکشن کئی بار شروع کیا گیا، جیسا کہ اوپر دکھایا گیا ہے، اس طریقہ کار کے بغیر، کارکردگی بتدریج گرے گی، تاہم، عمل درآمد کے دوران اضافی بوجھ بھی پیدا ہوتا ہے۔ کمی مختلف وجوہات کی وجہ سے ہوتی ہے۔ کبھی کبھی تھریڈز کام کرنا ختم کر دیتے ہیں اور انہیں دوبارہ شروع کرنے کے دوران ایک وقفہ ہوتا ہے، بعض اوقات تھرڈ پارٹی ایپلی کیشنز نے کلسٹر پر بوجھ پیدا کر دیا تھا۔

پڑھنا اور فوری طور پر لکھنا HBase کے لیے کام کے سب سے مشکل حالات میں سے ایک ہے۔ اگر آپ صرف چھوٹی پوٹ درخواستیں کرتے ہیں، مثال کے طور پر 100 بائٹس، انہیں 10-50 ہزار ٹکڑوں کے پیک میں ملا کر، آپ کو فی سیکنڈ سیکڑوں ہزاروں آپریشن مل سکتے ہیں، اور صورتحال صرف پڑھنے کی درخواستوں کے ساتھ ملتی ہے۔ یہ بات قابل غور ہے کہ نتائج DataStax کے حاصل کردہ نتائج سے یکسر بہتر ہیں، زیادہ تر 50 ہزار بلاکس میں درخواستوں کی وجہ سے۔

اسٹینڈ: 16 ڈیٹا نوڈ اور 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