د HBase کارولو تیوري او عمل

بعد له غرمه مو پخیر زما نوم ډینیل لیپوووی دی، په سبرټیک کې زموږ ټیم د عملیاتي معلوماتو لپاره د ذخیره کولو په توګه د 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 جدول ذخیره کوي، چیرته موقعیت لري. هغه دا معلومات د 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 تارونه)، د 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 لاین کولو وروسته ، د بلاک کیچ ډیټا بیا تنظیم کړئ او خوندي کړئ. MemStore بفر ډیسک ته، که دا خالي نه وي.

3. د HBASE څخه د معلوماتو لوستل

که موږ فرض کړو چې پیرودونکي دمخه د hbase: meta څخه ټول معلومات لري (پوائنټ 2 وګورئ) ، نو بیا غوښتنه مستقیم RS ته ځي چیرې چې اړین کیلي زیرمه شوې. لومړی، لټون په MemCache کې ترسره کیږي. پرته لدې چې دلته معلومات شتون ولري یا نه ، لټون هم د بلاک کیچ بفر کې ترسره کیږي او که اړتیا وي ، په HFiles کې. که چیرې ډاټا په فایل کې وموندل شي، دا په بلاک کیچ کې ځای پرځای شوي او په راتلونکې غوښتنې کې به ګړندي بیرته راستانه شي. په HFile کې لټون کول نسبتا ګړندي دي د بلوم فلټر کارولو څخه مننه ، د بیلګې په توګه. د لږ مقدار ډیټا لوستلو سره ، دا سمدلاسه مشخص کوي چې ایا دا فایل اړین کیلي لري او که نه ، بیا راتلونکي ته ځي.

د دې دریو سرچینو څخه د معلوماتو ترلاسه کولو سره ، RS یو ځواب رامینځته کوي. په ځانګړي توګه ، دا کولی شي په یوځل کې د یو شی څو موندل شوي نسخې انتقال کړي که چیرې پیرودونکي د نسخې غوښتنه وکړي.

4. د معلوماتو ذخیره کول

د MemStore او BlockCache بفرونه تر 80٪ پورې تخصیص شوي آن هایپ RS حافظه نیسي (باقي د RS خدماتو دندو لپاره ساتل شوي). که د کارونې عادي حالت داسې وي چې پروسس کوي او سمدلاسه ورته ډاټا لیکي، نو دا د BlockCache کمولو او د MemStore زیاتولو معنی لري، ځکه چې کله چې د لیکلو ډاټا د لوستلو لپاره کیچ ته نه راځي، د بلاک کیچ به لږ وخت وکارول شي. د BlockCache بفر دوه برخې لري: LruBlockCache (همیشه په خیټه کې) او BucketCache (معمولا آف هیپ یا په SSD کې). BucketCache باید وکارول شي کله چې د لوستلو ډیری غوښتنې شتون ولري او دوی په LruBlockCache کې مناسب نه وي ، کوم چې د کثافاتو راټولونکي فعال کار لامل کیږي. په ورته وخت کې ، تاسو باید د لوستلو کیچ کارولو څخه په فعالیت کې د بنسټیز زیاتوالي تمه ونه کړئ ، مګر موږ به دې ته په 8 پراګراف کې بیرته راستانه کړو.

د ټول RS لپاره یو BlockCache شتون لري، او د هر میز لپاره یو MemStore شتون لري (یو د هر کالم کورنۍ لپاره).

څنګه بیان شوی په تیوري کې، کله چې لیکل کیږي، ډاټا زیرمې ته نه ځي او په حقیقت کې، دا ډول پیرامیټونه د میز لپاره CACHE_DATA_ON_WRITE او د RS لپاره "کیچ ډیټا په لیکلو" غلط ټاکل شوي. که څه هم، په عمل کې، که موږ په میمسټور کې ډاټا لیکو، بیا یې ډیسک ته فلش کړئ (په دې توګه یې پاک کړئ)، بیا پایله شوې فایل حذف کړئ، بیا د ترلاسه کولو غوښتنې په پلي کولو سره موږ به په بریالیتوب سره ډاټا ترلاسه کړو. سربیره پردې ، حتی که تاسو په بشپړ ډول بلاک کیچ غیر فعال کړئ او جدول د نوي ډیټا سره ډک کړئ ، نو بیا 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

د واحد غوښتنو پروسس کول (ترلاسه کول / حذف کول) خورا ګران عملیات دي ، نو که امکان ولري ، تاسو باید دوی په لیست یا لیست کې یوځای کړئ ، کوم چې تاسو ته اجازه درکوي د پام وړ فعالیت وده ترلاسه کړئ. دا په ځانګړې توګه د لیکلو عملیاتو لپاره ریښتیا ده، مګر کله چې لوستل کیږي لاندې نیمګړتیا شتون لري. لاندې ګراف د MemStore څخه د 50 ریکارډونو لوستلو وخت ښیې. لوستل په یوه تار کې ترسره شوي او افقی محور په غوښتنه کې د کلیدونو شمیر ښیې. دلته تاسو لیدلی شئ کله چې په یوه غوښتنه کې زرو کلیدونو ته وده ورکړئ، د اجرا کولو وخت راټیټیږي، د بیلګې په توګه. سرعت زیاتیږي. په هرصورت، د ډیفالټ په واسطه د MSLAB حالت فعالولو سره، د دې حد څخه وروسته په فعالیت کې د پام وړ کمښت پیل کیږي، او په ریکارډ کې د ډیټا اندازه لوی وي، د عملیاتي وخت اوږد وي.

ازموینې په مجازی ماشین کې ترسره شوې، 8 کورونه، نسخه HBase 2.0.0-cdh6.0.0-beta1.

د MSLAB حالت د ټوټو ټوټې کمولو لپاره ډیزاین شوی، کوم چې د نوي او زاړه نسل ډیټا مخلوط کولو له امله پیښیږي. د کار د حل په توګه، کله چې MSLAB فعال شي، ډاټا په نسبتا کوچني حجرو (ټوټو) کې ځای پرځای کیږي او په ټوټو کې پروسس کیږي. د پایلې په توګه، کله چې د غوښتل شوي ډیټا پاکټ حجم د ټاکل شوي اندازې څخه ډیر شي، فعالیت په چټکۍ سره راټیټیږي. له بلې خوا ، د دې حالت بندول هم د مشورې وړ ندي ، ځکه چې دا به د ډیټا پروسس کولو دقیقو شیبو کې د GC له امله ودریږي. یو ښه حل دا دی چې د فعال لیکلو په حالت کې د لوستلو په ورته وخت کې د پوټ له لارې د حجرو حجم زیات کړئ. د یادولو وړ ده چې ستونزه نه پیښیږي که چیرې د ثبت کولو وروسته ، تاسو د فلش کمانډ پرمخ وړئ ، کوم چې میمسټور ډیسک ته بیا تنظیموي ، یا که تاسو د بلک لوډ په کارولو سره بار کړئ. لاندې جدول ښیې چې د لوی (او ورته مقدار) ډیټا لپاره د میم سټور څخه پوښتنې د ورو کیدو لامل کیږي. په هرصورت، د chunksize په زیاتولو سره موږ د پروسس وخت نورمال ته راګرځوو.

د chunksize زیاتولو سربیره، د سیمې په واسطه د معلوماتو ویشل مرسته کوي، د بیلګې په توګه. د میز ویش. دا په هره سیمه کې د لږو غوښتنو په پایله کې راځي او که دوی په یوه حجره کې فټ شي، ځواب ښه پاتې کیږي.

6. په سیمو کې د میزونو ویشلو لپاره ستراتیژي (ویشل کول)

څرنګه چې HBase د کلیدي ارزښت ذخیره ده او تقسیم کول د کیلي په واسطه ترسره کیږي، نو دا خورا مهم دي چې ډاټا په ټولو سیمو کې په مساوي ډول ویشل شي. د مثال په توګه، د داسې جدول په دریو برخو ویشل به پایله ولري چې ډاټا په دریو برخو ویشل کیږي:

دا پیښیږي چې دا د ګړندي سستیدو لامل کیږي که چیرې وروسته بار شوي ډیټا داسې ښکاري ، د مثال په توګه ، اوږد ارزښتونه ، ډیری یې د ورته عدد سره پیل کیږي ، د مثال په توګه:

1000001
1000002
...
1100003

څرنګه چې کیلي د بایټ سرې په توګه زیرمه شوي، دوی ټول به ورته پیل وکړي او د ورته سیمې #1 پورې اړه ولري چې د کیلي دا لړۍ ذخیره کوي. د ویشلو ډیری ستراتیژۍ شتون لري:

HexStringSplit – کیلي په "00000000" => "FFFFFFFF" کې د هیکساډیسیمل کوډ شوي تار بدلوي او کیڼ اړخ ته د صفر سره پیډ کول.

یونیفارم سپلیټ – کیلي د "00" => "FF" حد کې د هیکساډیسیمل کوډ کولو سره او ښي خوا ته د صفر سره پیډینګ سره کیلي په بایټ سري بدلوي.

برسېره پردې، تاسو کولی شئ د ویشلو لپاره د کیلي هر ډول لړۍ یا سیټ مشخص کړئ او د اتوماتیک ویشلو ترتیب کړئ. په هرصورت، یو له ساده او خورا اغیزمنو لارو څخه یونیفورم سپلیټ او د هش کنټینیشن کارول دي، د بیلګې په توګه د CRC32 (rowkey) فنکشن او پخپله rowkey له لارې د کیلي چلولو څخه د بایټ خورا مهم جوړه:

hash + rowkey

بیا به ټول معلومات په مساوي ډول په سیمو کې توزیع شي. کله چې لوستل کیږي، لومړی دوه بایټونه په ساده ډول رد شوي او اصلي کیلي پاتې کیږي. RS په سیمه کې د ډیټا او کیلي مقدار هم کنټرولوي او که چیرې حدونه تیر شي نو په اتوماتيک ډول یې په برخو کې ماتوي.

7. د غلطۍ زغم او د معلوماتو ځای

څنګه چې یوازې یوه سیمه د کیلي هرې سیټ لپاره مسؤله ده ، د RS حادثې یا ډیکمیشن کولو پورې اړوند ستونزو حل په HDFS کې ټول اړین معلومات ذخیره کول دي. کله چې RS راښکته شي، ماسټر دا په ZooKeeper نوډ کې د زړه د ټکان د نشتوالي له لارې کشف کوي. بیا دا خدمت شوی سیمه بل RS ته ګماري او له هغه وخته چې HFiles په توزیع شوي فایل سیسټم کې زیرمه شوي ، نو نوی مالک دوی لوستل کوي او د معلوماتو خدمت ته دوام ورکوي. په هرصورت، څنګه چې ځینې ډاټا ممکن په میمسټور کې وي او HFiles ته د ننوتلو وخت نه درلود، WAL، کوم چې په HDFS کې هم زیرمه شوی، د عملیاتو تاریخ بیا رغولو لپاره کارول کیږي. د بدلونونو پلي کیدو وروسته ، RS د دې وړتیا لري چې غوښتنو ته ځواب ووایی ، مګر حرکت د دې حقیقت لامل کیږي چې ځینې معلومات او پروسې چې دوی ته خدمت کوي په مختلف نوډونو کې پای ته رسیږي ، د بیلګې په توګه. سیمه کمیږي.

د ستونزې حل لوی ترکیب دی - دا کړنلاره فایلونه هغه نوډونو ته لیږدوي چې د دوی لپاره مسؤل دي (چیرې چې د دوی سیمې موقعیت لري) ، د دې پروسې په جریان کې د شبکې او ډیسکونو بار په چټکۍ سره وده کوي. په هرصورت، په راتلونکي کې، معلوماتو ته لاسرسی د پام وړ ګړندی کیږي. سربیره پردې ، major_compaction په یوه سیمه کې په یوه فایل کې د ټولو HFiles ادغام ترسره کوي ، او د میز تنظیماتو پورې اړوند ډیټا هم پاکوي. د مثال په توګه، تاسو کولی شئ د یو شی د نسخو شمیر مشخص کړئ چې باید وساتل شي یا د ژوند موده چې وروسته یې اعتراض په فزیکي توګه حذف شوی وي.

دا کړنلاره کولی شي د HBase په عملیاتو خورا مثبت اغیزه ولري. لاندې انځور ښیې چې د فعال ډیټا ثبتولو په پایله کې فعالیت څنګه خراب شوی. دلته تاسو لیدلی شئ چې څنګه 40 تارونه یو میز ته لیکلي او 40 تارونه په یو وخت کې ډاټا لوستل کیږي. د تارونو لیکل ډیر او ډیر HFiles رامینځته کوي ، کوم چې د نورو تارونو لخوا لوستل کیږي. د پایلې په توګه، ډیری او ډیرو معلوماتو ته اړتیا ده چې له حافظې څخه لیرې شي او بالاخره GC کار پیل کړي، کوم چې په عملي توګه ټول کارونه فلج کوي. د لوی کمپکشن پیل کول د پایله شوي کثافاتو پاکولو او د محصولاتو بیا رغولو لامل شو.

ازموینه په 3 ډیټا نوډونو او 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 ځله په پرله پسې ډول پیل شوي (راځئ چې دې ته د تارونو بلاک ووایو).
• په بلاک کې د ټولو تارونو عملیاتي وخت اوسط شوی و او د بلاک د عملیاتو وروستۍ پایله وه.
• ټول تارونه د ورته میز سره کار کوي.
• د تار بلاک د هر پیل دمخه، یو لوی کمپکشن ترسره شوی و.
• هر بلاک د لاندې عملیاتو څخه یوازې یو ترسره کړی:

– ولګوه
- ترلاسه کړئ
- ترلاسه کړئ + واچوئ

• هر بلاک د خپلو عملیاتو 50 تکرارونه ترسره کړل.
• د ریکارډ د بلاک اندازه 100 بایټس، 1000 بایټس یا 10000 بایټس (تصادفي) ده.
• بلاکونه د غوښتل شوي کیلي مختلف شمیر سره پیل شوي (یا یوه کیلي یا 10).
• بلاکونه د مختلف میز ترتیباتو لاندې چلول شوي. پیرامیټونه بدل شوي:

- بلاک کیچ = فعال یا بند شوی
- د بلاک اندازه = 65 KB یا 16 KB
- تقسیمونه = 1، 5 یا 30
MSLAB = فعال یا غیر فعال

نو بلاک داسې ښکاري:

a. د MSLAB حالت فعال / بند شو.
ب. یو جدول جوړ شوی و چې لاندې پیرامیټونه یې تنظیم شوي وو: بلاک کیچ = ریښتیني/هیڅ، د بلاک سایز = 65/16 Kb، ویش = 1/5/30.
ج. کمپریشن GZ ته ټاکل شوی و.
d. 10 تارونه په ورته وخت کې په دې جدول کې د 1/10/100 بایټس ریکارډونو سره د 1000/10000 put/get/get+put عملیاتو په ترسره کولو سره پیل شوي ، په قطار کې 50 پوښتنې ترسره کوي (تصادفي کیلي).
e. ټکي D درې ځله تکرار شو.
f. د ټولو تارونو عملیاتي وخت اوسط شوی.

ټول احتمالي ترکیبونه ازمول شوي. دا د وړاندوینې وړ ده چې سرعت به د ریکارډ اندازې په زیاتوالي سره راټیټ شي، یا دا چې د کیشینګ غیر فعال کول به د ورو کیدو لامل شي. په هرصورت، موخه دا وه چې د هر پیرامیټر د نفوذ درجې او اهمیت پوه شي، نو راټول شوي ډاټا د خطي ریګریشن فنکشن ان پټ ته ورکړل شوي، کوم چې د T-احصایې په کارولو سره د اهمیت ارزونه ممکنه کوي. لاندې د بلاکونو پایلې دي چې د پوټ عملیات ترسره کوي. د ترکیبونو بشپړ سیټ 2*2*3*2*3 = 144 اختیارونه + 72 tk. ځینې ​​​​دوه ځله ترسره شوي. نو په ټولیزه توګه ۲۱۶ منډې لري:

ازموینه په مینی کلستر کې ترسره شوه چې پکې 3 ډیټا نوډونه او 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 تارونه) شامل دي. د HBase نسخه 1.2.0-cdh5.14.2.

د 3.7 ثانیو ترټولو لوړ داخلولو سرعت د MSLAB حالت بندیدو سره ترلاسه شوی ، په میز کې د یوې برخې سره ، د بلاک کیچ فعال سره ، د بلاک سایز = 16 ، د 100 بایټ ریکارډونه ، په هر کڅوړه کې 10 ټوټې.
د 82.8 ثانیو ترټولو ټیټ داخلولو سرعت د MSLAB حالت فعال شوي، په میز کې د یوې برخې سره، د بلاک کیچ فعال سره، د بلاک سایز = 16، د 10000 بایټ ریکارډونه، هر یو.

اوس راځئ چې ماډل ته وګورو. موږ د R2 پراساس د ماډل ښه کیفیت ګورو ، مګر دا په بشپړ ډول روښانه ده چې دلته استخراج مخنیوی کیږي. د سیسټم ریښتیني چلند کله چې د پیرامیټونو بدلون به خطي نه وي؛ دا ماډل د وړاندوینې لپاره نه بلکه د دې پوهیدو لپاره چې په ورکړل شوي پیرامیټونو کې پیښ شوي. د مثال په توګه، دلته موږ د زده کونکي له معیار څخه ګورو چې د BlockSize او BlockCache پیرامیټرې د Put عملیات لپاره مهم ندي (کوم چې عموما د اټکل وړ وي):

مګر دا حقیقت چې د برخو شمیر زیاتول د فعالیت کمیدو لامل کیږي یو څه غیر متوقع دی (موږ دمخه د بلک لوډ سره د برخو شمیر زیاتولو مثبت اغیز لیدلی) ، که څه هم د پوهیدو وړ دی. لومړی ، د پروسس کولو لپاره ، تاسو باید د یوې پرځای 30 سیمو ته غوښتنې رامینځته کړئ ، او د ډیټا حجم داسې ندي چې دا به ګټه ترلاسه کړي. دوهم، ټول عملیاتي وخت د ورو ورو RS لخوا ټاکل کیږي، او څنګه چې د ډیټا نوډونو شمیر د RSs شمیر څخه کم دی، ځینې سیمې صفر ځای لري. ښه، راځئ چې پورته پنځه ته وګورو:

اوس راځئ چې د Get blocks اجرا کولو پایلې ارزونه وکړو:

د برخو شمیر اهمیت له لاسه ورکړی، کوم چې شاید د دې حقیقت لخوا تشریح شوي چې ډاټا په ښه توګه ساتل کیږي او د لوستلو کیچ خورا مهم (احصایوي) پیرامیټر دی. په طبیعي توګه، په غوښتنه کې د پیغامونو شمیر زیاتول هم د فعالیت لپاره خورا ګټور دي. غوره نمرې:

ښه ، په نهایت کې ، راځئ چې د بلاک ماډل ته وګورو چې لومړی یې ترلاسه کړ او بیا یې کېښود:

دلته ټول پارامترونه د پام وړ دي. او د مشرانو هیلې:

9. د بار ازموینه

ښه ، په نهایت کې به موږ ډیر یا لږ ښه بار پیل کړو ، مګر دا تل خورا په زړه پوري وي کله چې تاسو د پرتله کولو لپاره یو څه لرئ. د ډیټا سټیکس ویب پا onه کې ، د کاسندرا کلیدي پراختیا کونکی ، شتون لري پایلې د یو شمیر NoSQL ذخیره کولو NT، په شمول د HBase نسخه 0.98.6-1. بار کول د 40 تارونو ، د ډیټا اندازه 100 بایټس ، SSD ډیسکونو لخوا ترسره شوي. د لوستلو - ترمیم - لیکلو عملیاتو ازموینې پایلې لاندې پایلې ښودلې.

تر هغه ځایه چې زه پوهیږم، لوستل د 100 ریکارډونو بلاکونو کې ترسره شوي او د 16 HBase نوډونو لپاره، د DataStax ازموینې په هره ثانیه کې د 10 زره عملیاتو فعالیت ښودلی.

دا خوشبختانه ده چې زموږ کلستر هم 16 نوډونه لري، مګر دا ډیر "خوشحاله" نه دی چې هر یو یې 64 کورونه (مسلکي) لري، پداسې حال کې چې د ډیټاسټیکس ازموینه کې یوازې 4 شتون لري. له بلې خوا، دوی SSD ډرایو لري، پداسې حال کې چې موږ HDDs لرو. یا نور د 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