HBase استعمال ڪرڻ جو نظريو ۽ عمل

منجهند جو سلام منهنجو نالو ڊينيل ليپووائي آهي، 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. عام فن تعمير

بيڪ اپ ماسٽر زو ڪيپر نوڊ تي فعال جي دل جي ڌڙڪن کي ٻڌي ٿو ۽ غائب ٿيڻ جي صورت ۾، ماسٽر جي ڪمن کي سنڀاليندو آهي.

2. HBASE ڏانهن ڊيٽا لکو

پهرين، اچو ته آسان ترين صورت تي نظر رکون - put(rowkey) استعمال ڪندي ٽيبل تي هڪ اهم-قيمتي اعتراض لکڻ. ڪلائنٽ کي پهريان اهو معلوم ڪرڻ گهرجي ته ڪٿي روٽ ريجن سرور (RRS)، جيڪو اسٽور ڪري ٿو hbase:meta table، واقع آهي. هن اها معلومات ZooKeeper کان حاصل ڪئي. جنهن کان پوءِ اهو RRS تائين پهچندو آهي ۽ پڙهي ٿو hbase:meta ٽيبل، جنهن مان اها معلومات ڪڍي ٿي جنهن بابت RegionServer (RS) دلچسپي جي جدول ۾ ڏنل قطار لاءِ ڊيٽا محفوظ ڪرڻ جو ذميوار آهي. مستقبل جي استعمال لاءِ، ميٽا ٽيبل ڪلائنٽ طرفان ڪيش ڪئي وئي آهي ۽ تنهن ڪري ايندڙ ڪالون تيز ٿين ٿيون، سڌو سنئون RS ڏانهن.

اڳيون، RS، هڪ درخواست حاصل ڪرڻ کان پوء، سڀ کان پهريان اهو لکي ٿو WriteAheadLog (WAL)، جيڪو حادثي جي صورت ۾ بحالي لاء ضروري آهي. پوءِ ڊيٽا کي محفوظ ڪري ٿو MemStore ۾. هي ميموري ۾ هڪ بفر آهي جنهن ۾ ڏنل علائقي لاءِ چاٻين جي ترتيب ڏنل سيٽ شامل آهي. ھڪڙي ٽيبل کي علائقن ۾ ورهائي سگھجي ٿو (پارٽيشنز)، جن مان ھر ھڪ ۾ ڪنجين جو جدا جدا سيٽ ھوندو آھي. هي توهان کي اجازت ڏئي ٿو علائقن کي مختلف سرورن تي رکڻ لاءِ اعليٰ ڪارڪردگي حاصل ڪرڻ لاءِ. بهرحال، هن بيان جي واضح هجڻ جي باوجود، اسان بعد ۾ ڏسندا سين ته اهو سڀني ڪيسن ۾ ڪم نٿو ڪري.

MemStore ۾ داخلا رکڻ کان پوء، ڪلائنٽ ڏانهن جواب واپس اچي ٿو ته داخلا ڪاميابي سان محفوظ ٿي وئي. جڏهن ته، حقيقت ۾ اهو صرف هڪ بفر ۾ ذخيرو ٿيل آهي ۽ ڊسڪ تائين پهچي ٿو صرف هڪ خاص وقت کان پوء گذري چڪو آهي يا جڏهن اهو نئين ڊيٽا سان ڀريل آهي.

جڏهن "خارج ڪريو" آپريشن کي انجام ڏيو، ڊيٽا کي جسماني طور تي ختم نه ڪيو ويو آهي. اهي صرف نشان لڳل آهن حذف ٿيل طور تي، ۽ تباهي خود وڏي ڪمپيڪٽ فنڪشن کي سڏڻ جي وقت تي ٿيندي آهي، جنهن کي پيراگراف 7 ۾ وڌيڪ تفصيل سان بيان ڪيو ويو آهي.

HFile فارميٽ ۾ فائلون HDFS ۾ گڏ ڪيون وينديون آهن ۽ وقت بوقت ننڍڙو ڪمپيڪٽ پروسيس شروع ڪيو ويندو آهي، جيڪو صرف ننڍن فائلن کي ڪنهن به شيء کي حذف ڪرڻ کان سواء وڏين فائلن ۾ ضم ڪري ٿو. وقت سان گڏ، اهو هڪ مسئلو ۾ بدلجي ٿو جيڪو صرف ظاهر ٿئي ٿو جڏهن ڊيٽا پڙهڻ (اسين هن تي ٿوري دير بعد واپس ايندا).

مٿي بيان ڪيل لوڊشيڊنگ جي عمل کان علاوه، هڪ تمام گهڻو اثرائتو طريقو آهي، جيڪو شايد هن ڊيٽابيس جو مضبوط ترين پاسو آهي - بلڪ لوڊ. اهو حقيقت ۾ آهي ته اسان آزاد طور تي HFiles ٺاهيندا آهيون ۽ انهن کي ڊسڪ تي رکون ٿا، جيڪا اسان کي مڪمل طور تي ماپڻ ۽ تمام مهذب رفتار حاصل ڪرڻ جي اجازت ڏئي ٿي. حقيقت ۾، هتي حد HBase نه آهي، پر هارڊويئر جون صلاحيتون. ھيٺ ڏنل آھن بوٽ جا نتيجا ھڪڙي ڪلستر تي مشتمل آھن 16 RegionServers ۽ 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads)، 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 ڊيٽا کي ري سيٽ ڪريو ۽ محفوظ ڪريو. MemStore بفر کي ڊسڪ، جيڪڏھن اھو خالي نه آھي.

3. HBASE کان ڊيٽا پڙهڻ

جيڪڏهن اسان فرض ڪريون ٿا ته ڪلائنٽ وٽ اڳ ۾ ئي hbase:meta (ڏسو پوائنٽ 2) کان سڀ معلومات آهي، پوءِ درخواست سڌو RS ڏانهن وڃي ٿي جتي گهربل چيڪ محفوظ ٿيل آهي. پهرين، ڳولا ڪئي وئي آهي MemCache ۾. ان جي باوجود ته اتي ڊيٽا موجود آهي يا نه، ڳولا پڻ ڪئي وئي آهي BlockCache بفر ۾ ۽، جيڪڏهن ضروري هجي ته، HFiles ۾. جيڪڏهن ڊيٽا فائل ۾ ملي ٿي، اها BlockCache ۾ رکيل آهي ۽ ايندڙ درخواست تي تيزيء سان موٽائي ويندي. HFile ۾ ڳولڻ نسبتا تيز آهي بلوم فلٽر جي استعمال جي مهرباني، يعني. ڊيٽا جي هڪ ننڍڙي مقدار کي پڙهڻ کان پوء، اهو فوري طور تي طئي ڪري ٿو ته ڇا هن فائل ۾ گهربل ڪنجي شامل آهي ۽ جيڪڏهن نه، پوء اڳتي هلي ٿو.

انهن ٽن ذريعن کان ڊيٽا حاصل ڪرڻ، RS هڪ جواب پيدا ڪري ٿو. خاص طور تي، جيڪڏهن ڪلائنٽ ورزننگ جي درخواست ڪئي ته اهو هڪ ڀيرو هڪ اعتراض جي ڪيترن ئي مليل نسخن کي منتقل ڪري سگهي ٿو.

4. ڊيٽا ڪيشنگ

MemStore ۽ BlockCache بفرز مختص ڪيل آن-هيپ RS ميموري جو 80٪ تائين قبضو ڪن ٿا (باقي RS سروس جي ڪمن لاءِ مخصوص آهي). جيڪڏهن عام استعمال جو طريقو اهڙو آهي جيڪو پروسيس ڪري ٿو ۽ ساڳئي ڊيٽا کي فوري طور تي پڙهي ٿو، پوء اهو سمجھندو آهي بلاڪ ڪيچ کي گهٽائڻ ۽ MemStore کي وڌائڻ، ڇاڪاڻ ته جڏهن لکڻ جي ڊيٽا پڙهڻ لاءِ ڪيش ۾ نه ايندي آهي، BlockCache گهٽ استعمال ڪيو ويندو. BlockCache بفر ٻن حصن تي مشتمل آهي: LruBlockCache (هميشه آن هيپ) ۽ BucketCache (عام طور تي آف هيپ يا 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

ھڪڙي درخواستن تي عمل ڪرڻ (حاصل ڪريو / وجھو / حذف ڪريو) ھڪڙو قيمتي آپريشن آھي، تنھنڪري جيڪڏھن ممڪن ھجي، توھان کي انھن کي ھڪڙي فهرست يا لسٽ ۾ گڏ ڪرڻ گھرجي، جيڪو توھان کي اجازت ڏئي ٿو ھڪڙي قابل ڪارڪردگي واڌارو حاصل ڪرڻ جي. اهو خاص طور تي لکڻ جي عمل لاء صحيح آهي، پر جڏهن پڙهڻ ۾ هيٺ ڏنل نقصان آهي. هيٺ ڏنل گراف ڏيکاري ٿو 50 رڪارڊ پڙهڻ جو وقت MemStore کان. پڙھڻ ھڪڙي سلسلي ۾ ڪيو ويو آھي ۽ افقي محور درخواست ۾ ڪنجين جو تعداد ڏيکاري ٿو. هتي توهان ڏسي سگهو ٿا ته جڏهن هڪ درخواست ۾ هڪ هزار چابمن ڏانهن وڌندي، عملدرآمد جو وقت گهٽجي ٿو، يعني. رفتار وڌائي ٿي. بهرحال، 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" جي حد ۾ هيڪساڊيڪل انڪوڊ ٿيل اسٽرنگ ۾ تبديل ڪري ٿو ۽ کاٻي پاسي زيرو سان پيڊنگ.

UniformSplit - ڪيئي کي بائيٽ ايري ۾ تبديل ڪري ٿو هيڪساڊيڪل انڪوڊنگ سان رينج "00" => "FF" ۾ ۽ ساڄي پاسي زيرو سان پيڊنگ.

ان کان علاوه، توھان وضاحت ڪري سگھو ٿا ڪنھن حد يا سيٽ جي چاٻين کي تقسيم ڪرڻ ۽ ترتيب ڏيڻ لاءِ خودڪار ورهائڻ. بهرحال، هڪ آسان ۽ تمام مؤثر طريقو آهي UniformSplit ۽ هيش ڪنٽينشن جو استعمال، مثال طور CRC32 (rowkey) فنڪشن ۽ rowkey ذريعي ڪيئي کي هلائڻ کان بائيٽ جو سڀ کان اهم جوڙو:

hash + rowkey

پوء سڀني ڊيٽا کي برابر طور تي علائقن ۾ ورهايو ويندو. جڏهن پڙهڻ، پهرين ٻه بائيٽ صرف رد ڪيا ويا آهن ۽ اصل ڪنجي رهي ٿي. RS علائقي ۾ ڊيٽا ۽ ڪنجين جي مقدار کي پڻ ڪنٽرول ڪري ٿو ۽، جيڪڏهن حد کان وڌي وڃي ٿي، خودڪار طور تي ان کي حصن ۾ ٽوڙي ٿو.

7. غلطي رواداري ۽ ڊيٽا جي جڳھ

جيئن ته چاٻين جي هر سيٽ لاءِ صرف هڪ علائقو ذميوار آهي، RS حادثن يا ختم ڪرڻ سان لاڳاپيل مسئلن جو حل HDFS ۾ سڀني ضروري ڊيٽا کي ذخيرو ڪرڻ آهي. جڏهن RS پوي ٿو، ماسٽر زو ڪيپر نوڊ تي دل جي ڌڙڪڻ جي غير موجودگي جي ذريعي هن کي ڳولي ٿو. ان کان پوء اهو خدمت ڪيل علائقي کي ٻئي RS کي تفويض ڪري ٿو ۽ جيئن ته HFiles هڪ ورهايل فائل سسٽم ۾ ذخيرو ٿيل آهن، نئون مالڪ انهن کي پڙهي ٿو ۽ ڊيٽا جي خدمت جاري رکي ٿو. جڏهن ته، ڪجهه ڊيٽا ٿي سگهي ٿي MemStore ۾ ۽ HFiles ۾ حاصل ڪرڻ جو وقت نه آهي، WAL، جيڪو پڻ HDFS ۾ ذخيرو ٿيل آهي، آپريشن جي تاريخ کي بحال ڪرڻ لاء استعمال ڪيو ويندو آهي. تبديلين کي لاڳو ٿيڻ کان پوء، RS درخواستن جو جواب ڏيڻ جي قابل آهي، پر اهو قدم حقيقت ڏانهن وٺي ٿو ته ڪجهه ڊيٽا ۽ انهن جي خدمت ڪرڻ وارا عمل مختلف نوڊس تي ختم ٿين ٿا، يعني. مقاميت گهٽجي رهي آهي.

مسئلي جو حل وڏو ٺهڪندڙ آهي - اهو طريقو فائلن کي منتقل ڪري ٿو انهن نوڊس جيڪي انهن لاء ذميوار آهن (جتي انهن جا علائقا واقع آهن)، جنهن جي نتيجي ۾ هن طريقي سان نيٽ ورڪ ۽ ڊسڪ تي لوڊ تيزيء سان وڌي ٿو. بهرحال، مستقبل ۾، ڊيٽا تائين رسائي کي تيزيء سان تيز ڪيو ويندو. ان کان علاوه، major_compaction سڀني HFiles کي ھڪڙي علائقي ۾ ھڪڙي فائل ۾ ضم ڪري ٿو، ۽ ٽيبل سيٽنگن جي لحاظ سان ڊيٽا کي صاف ڪري ٿو. مثال طور، توھان وضاحت ڪري سگھو ٿا ھڪڙي اعتراض جي نسخن جو تعداد جيڪو برقرار رکڻ گھرجي يا زندگي گذارڻ بعد جنھن کان پوء اعتراض کي جسماني طور تي ختم ڪيو وڃي.

هن طريقيڪار HBase جي آپريشن تي هڪ تمام مثبت اثر ٿي سگهي ٿو. هيٺ ڏنل تصوير ڏيکاري ٿي ته ڪارڪردگي ڪيئن خراب ٿي وئي فعال ڊيٽا رڪارڊنگ جي نتيجي ۾. هتي توهان ڏسي سگهو ٿا ته ڪيئن 40 سلسلا هڪ ٽيبل تي لکيا ويا ۽ 40 موضوعن سان گڏ ڊيٽا پڙهي. لکڻ جا سلسلا وڌيڪ ۽ وڌيڪ HFiles ٺاهيندا آهن، جيڪي ٻين موضوعن پاران پڙهيا ويندا آهن. نتيجي طور، وڌيڪ ۽ وڌيڪ ڊيٽا کي ميموري مان هٽائڻ جي ضرورت آهي ۽ آخرڪار GC ڪم ڪرڻ شروع ڪري ٿو، جيڪو عملي طور تي سڀني ڪم کي مفلوج ڪري ٿو. وڏي ٺهڪندڙ جي شروعات نتيجي ۾ ملبے کي صاف ڪرڻ ۽ پيداوار جي بحالي جي ڪري ٿي.

ٽيسٽ 3 DataNodes ۽ 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 موضوعن) تي ڪئي وئي. HBase ورجن 1.2.0-cdh5.14.2

اها ڳالهه نوٽ ڪرڻ جي قابل آهي ته اهم compaction هڪ "لائيو" ٽيبل تي شروع ڪيو ويو، جنهن ۾ ڊيٽا کي فعال طور تي لکيو ويو ۽ پڙهيو ويو. اتي هڪ بيان آن لائن هو ته اهو غلط جواب ڏئي سگهي ٿو جڏهن ڊيٽا پڙهڻ. چيڪ ڪرڻ لاء، هڪ عمل شروع ڪيو ويو جيڪو نئين ڊيٽا ٺاهي ۽ ان کي ٽيبل تي لکيو. جنهن کان پوءِ مون فوري طور تي پڙهيو ۽ چيڪ ڪيو ته ڇا نتيجي ۾ آيل قيمت ان سان ٺهڪي اچي ٿي جيڪا لکيل هئي. جڏهن ته اهو عمل هلي رهيو هو، وڏي ڪمپيشن تقريباً 200 ڀيرا هلائي وئي ۽ هڪ به ناڪامي رڪارڊ نه ڪئي وئي. شايد اهو مسئلو تمام گهٽ ۽ صرف تيز لوڊ دوران ظاهر ٿئي ٿو، تنهنڪري اهو وڌيڪ محفوظ آهي ته لکڻ ۽ پڙهڻ جي عمل کي روڪيو وڃي جيئن منصوبابندي ڪئي وڃي ۽ اهڙي قسم جي GC ڊراڻ کي روڪڻ لاء صفائي کي انجام ڏيو.

ان سان گڏ، وڏي ٺهڪندڙ MemStore جي حالت کي متاثر نٿو ڪري؛ ان کي ڊسڪ ۾ فلش ڪرڻ ۽ ان کي ڪمپيڪٽ ڪرڻ لاء، توهان کي فلش استعمال ڪرڻ جي ضرورت آهي (connection.getAdmin().flush(TableName.valueOf(tblName))).

8. سيٽنگون ۽ ڪارڪردگي

جيئن اڳ ۾ ئي ذڪر ڪيو ويو آهي، HBase پنهنجي وڏي ڪاميابي ڏيکاري ٿو جتي ان کي ڪجهه ڪرڻ جي ضرورت ناهي، جڏهن بلڪ لوڊ تي عمل ڪندي. بهرحال، اهو سڀ کان وڌيڪ سسٽم ۽ ماڻهن تي لاڳو ٿئي ٿو. بهرحال، هي اوزار وڏين بلاڪن ۾ وڏي تعداد ۾ ڊيٽا کي محفوظ ڪرڻ لاءِ وڌيڪ موزون آهي، جڏهن ته جيڪڏهن پروسيس کي گهربل ڪيترن ئي مقابلي واري پڙهڻ ۽ لکڻ جي درخواستن جي ضرورت آهي، مٿي بيان ڪيل Get and Put ڪمانڊ استعمال ڪيا ويندا آهن. بهترين پيٽرولر جو تعين ڪرڻ لاء، ميز جي پيٽرولن ۽ سيٽنگن جي مختلف مجموعن سان لانچ ڪيا ويا:

• 10 موضوعن کي هڪ ئي وقت ۾ 3 ڀيرا شروع ڪيو ويو (اچو ته ان کي سڏين ٿا سلسلي جو هڪ بلاڪ).
• بلاڪ ۾ سڀني موضوعن جو آپريٽنگ وقت اوسط ڪيو ويو ۽ بلاڪ جي آپريشن جو آخري نتيجو هو.
• سڀئي سلسلا هڪ ئي ٽيبل سان ڪم ڪن ٿا.
• ٿريڊ بلاڪ جي هر شروعات کان اڳ، هڪ اهم ڪمپريشن ڪيو ويو.
• هر بلاڪ هيٺ ڏنل عملن مان صرف هڪ ڪيو:

- لڳايو
- حاصل
-Get+Put

• هر بلاڪ پنهنجي آپريشن جا 50 ورهاڱي ڪيا.
• رڪارڊ جي بلاڪ سائيز 100 بائيٽ، 1000 بائيٽ يا 10000 بائيٽ (بي ترتيب) آھي.
• بلاڪ شروع ڪيا ويا مختلف نمبرن جي درخواست ڪيل چاٻين سان (يا ته ھڪڙي چاٻي يا 10).
• بلاڪ مختلف ٽيبل سيٽنگن جي تحت هليا ويا. تبديل ٿيل پيٽرولر:

- BlockCache = چالو يا بند
- بلاڪ سائيز = 65 KB يا 16 KB
- ورهاڱي = 1، 5 يا 30
- MSLAB = فعال يا غير فعال

تنهنڪري بلاڪ هن طرح نظر اچي ٿو:

هڪ MSLAB موڊ آن / آف ڪيو ويو.
ب. ھڪڙي جدول ٺاھيو ويو جنھن لاءِ ھيٺيون پيٽرول مقرر ڪيا ويا: BlockCache = سچو/ڪو به، بلاڪ سائز = 65/16 Kb، ورهاڱي = 1/5/30.
ج. ڪمپريشن GZ تي مقرر ڪيو ويو.
ڊي. 10 ٿريڊز هڪ ئي وقت شروع ڪيا ويا 1/10 put/get/get+put آپريشن ڪندي هن ٽيبل ۾ 100/1000/10000 بائيٽ جي رڪارڊ سان، هڪ قطار ۾ 50 سوالن کي انجام ڏيڻ (بي ترتيب ڪيز).
e. پوائنٽ ڊي ٽي ڀيرا بار بار ڪيو ويو.
f. سڀني موضوعن جو آپريٽنگ وقت اوسط ڪيو ويو.

سڀ ممڪن مجموعا آزمايا ويا. اهو اڳڪٿي ڪري سگهجي ٿو ته رفتار گهٽجي ويندي جيئن رڪارڊ سائيز وڌندي، يا ته ڪيچنگ کي غير فعال ڪرڻ سست ٿيڻ جو سبب بڻجندو. بهرحال، مقصد هر پيٽرولر جي اثر جي درجي ۽ اهميت کي سمجهڻ هو، تنهن ڪري گڏ ڪيل ڊيٽا کي لڪير ريگريشن فنڪشن جي ان پٽ ۾ ڀريو ويو، جيڪو اهو ممڪن بڻائي ٿو ته t-statistics استعمال ڪندي اهميت جو اندازو لڳائڻ. هيٺ ڏنل بلاڪن جا نتيجا آهن جيڪي Put آپريشن ڪري رهيا آهن. مجموعن جو پورو سيٽ 2*2*3*2*3 = 144 آپشنز + 72 tk. ڪجهه ٻه ڀيرا ڪيا ويا. تنهن ڪري، مجموعي طور تي 216 رنسون آهن:

جانچ ڪئي وئي هڪ ميني ڪلستر تي جنهن ۾ 3 DataNodes ۽ 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 پاران طئي ڪيو ويندو آهي، ۽ جيئن ته DataNodes جو تعداد RS جي تعداد کان گهٽ آهي، ڪجهه علائقن ۾ صفر مقامي آهي. خير، اچو ته مٿين پنجن کي ڏسو:

ھاڻي اچو ته نتيجن جو جائزو وٺون حاصل ڪريو بلاڪ حاصل ڪريو:

ورهاڱي جو تعداد اھميت وڃائي چڪو آھي، جيڪا شايد حقيقت جي وضاحت ڪئي وئي آھي ته ڊيٽا چڱي طرح سان گڏ ٿيل آھي ۽ پڙھيل ڪيش سڀ کان وڌيڪ اھم آھي (شماراتي طور تي) پيٽرولر. قدرتي طور تي، هڪ درخواست ۾ پيغامن جو تعداد وڌائڻ پڻ ڪارڪردگي لاء تمام مفيد آهي. مٿيون اسڪور:

خير، آخرڪار، اچو ته بلاڪ جي ماڊل تي نظر رکون جيڪو پهريون ڀيرو حاصل ڪيو ۽ پوء رکيو:

سڀ پيراگراف هتي اهم آهن. ۽ اڳواڻن جا نتيجا:

9. لوڊ ٽيسٽ

خير، آخرڪار اسان هڪ وڌيڪ يا گهٽ مهذب لوڊ لانچ ڪنداسين، پر اهو هميشه وڌيڪ دلچسپ هوندو آهي جڏهن توهان وٽ مقابلو ڪرڻ لاءِ ڪجهه هوندو. DataStax جي ويب سائيٽ تي، Cassandra جي اهم ڊولپر، اتي آهي نتيجن NoSQL اسٽوريج جو NT، HBase ورجن 0.98.6-1 سميت. لوڊشيڊنگ 40 سلسلا، ڊيٽا سائيز 100 بائيٽ، ايس ايس ڊي ڊسڪ ذريعي ڪئي وئي. پڙھڻ-تبديل ڪرڻ-لکڻ جي عملن جي جاچ جا نتيجا ھيٺ ڏنل نتيجا ڏيکاريا.

جيتري قدر مان سمجهان ٿو، پڙهڻ 100 ريڪارڊز جي بلاڪن ۾ ڪيو ويو ۽ 16 HBase نوڊس لاءِ، DataStax ٽيسٽ 10 هزار آپريشن في سيڪنڊ جي ڪارڪردگي ڏيکاري.

اها خوش قسمتي آهي ته اسان جي ڪلسٽر ۾ 16 نوڊس به آهن، پر اهو ”خوش قسمت“ نه آهي ته هر هڪ ۾ 64 ڪور (ٿريڊ) آهن، جڏهن ته DataStax ٽيسٽ ۾ صرف 4 آهن. ٻئي طرف، انهن وٽ SSD ڊرائيو آهي، جڏهن ته اسان وٽ 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.

سراسري نتيجو 40 هزار آپريشن في سيڪنڊ جي ويجهو آهي، جيڪو خاص طور تي ڊيٽا اسٽيڪس ٽيسٽ کان بهتر آهي. بهرحال، تجرباتي مقصدن لاء، توهان ٿورڙي حالتون تبديل ڪري سگهو ٿا. اهو ممڪن ناهي ته سڀ ڪم خاص طور تي هڪ ميز تي، ۽ صرف منفرد ڪنجين تي ڪيا ويندا. اچو ته فرض ڪريون ته اتي هڪ خاص "گرم" سيٽن جو سيٽ آهي جيڪو مکيه لوڊ ٺاهي ٿو. تنهن ڪري، اچو ته هڪ لوڊ ٺاهڻ جي ڪوشش ڪريون وڏي رڪارڊ (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 هزار ٽڪرن جي پيڪن ۾ گڏ ڪري، توهان في سيڪنڊ سوين هزارين آپريشن حاصل ڪري سگهو ٿا، ۽ صورتحال صرف پڙهڻ جي درخواستن سان ساڳي آهي. اهو سمجهڻ جي قابل آهي ته نتيجا بنيادي طور تي بهتر آهن جيڪي ڊيٽا اسٽيڪس پاران حاصل ڪيا ويا آهن، سڀ کان وڌيڪ 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