تئوری و عمل استفاده از 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 گوش می دهد و در صورت ناپدید شدن، وظایف استاد را بر عهده می گیرد.

2. داده ها را در HBASE بنویسید

ابتدا، بیایید ساده ترین حالت را بررسی کنیم - نوشتن یک شی با مقدار کلید در جدول با استفاده از put(rowkey). کلاینت ابتدا باید دریابد که سرور منطقه ریشه (RRS) که جدول hbase:meta را ذخیره می کند، در کجا قرار دارد. او این اطلاعات را از ZooKeeper دریافت می کند. پس از آن به RRS دسترسی پیدا می‌کند و جدول hbase:meta را می‌خواند، که از آن اطلاعاتی در مورد اینکه RegionServer (RS) مسئول ذخیره‌سازی داده‌ها برای یک کلید ردیف معین در جدول مورد نظر است، استخراج می‌کند. برای استفاده در آینده، جدول متا توسط مشتری ذخیره می شود و بنابراین تماس های بعدی سریعتر و مستقیماً به RS می روند.

سپس، RS پس از دریافت درخواست، ابتدا آن را در WriteAheadLog (WAL) می نویسد، که برای بازیابی در صورت خرابی ضروری است. سپس داده ها را در MemStore ذخیره می کند. این یک بافر در حافظه است که شامل مجموعه ای از کلیدهای مرتب شده برای یک منطقه معین است. یک جدول را می توان به مناطق (پارتیشن) تقسیم کرد که هر کدام شامل مجموعه ای از کلیدهای مجزا است. این به شما این امکان را می دهد که مناطق را روی سرورهای مختلف قرار دهید تا عملکرد بالاتری داشته باشید. با این حال، با وجود بدیهی بودن این گفته، بعداً خواهیم دید که این در همه موارد کارساز نیست.

پس از قرار دادن یک ورودی در MemStore، پاسخی به مشتری باز می گردد که ورودی با موفقیت ذخیره شده است. با این حال، در واقعیت فقط در یک بافر ذخیره می شود و تنها پس از گذشت مدت زمان معینی یا زمانی که با داده های جدید پر می شود، به دیسک می رسد.

هنگام انجام عملیات "حذف"، داده ها به صورت فیزیکی حذف نمی شوند. آنها به سادگی به عنوان حذف شده علامت گذاری می شوند و خود تخریب در لحظه فراخوانی عملکرد فشرده اصلی رخ می دهد که با جزئیات بیشتر در بند 7 توضیح داده شده است.

فایل‌های با فرمت HFile در HDFS انباشته می‌شوند و هر از چند گاهی فرآیند فشرده کوچک راه‌اندازی می‌شود که به سادگی فایل‌های کوچک را بدون حذف چیزی در فایل‌های بزرگ‌تر ادغام می‌کند. با گذشت زمان، این به مشکلی تبدیل می‌شود که فقط هنگام خواندن داده‌ها ظاهر می‌شود (کمی بعد به این موضوع باز خواهیم گشت).

علاوه بر فرآیند بارگیری که در بالا توضیح داده شد، روش بسیار مؤثرتری وجود دارد که شاید قوی ترین طرف این پایگاه داده باشد - BulkLoad. این در این واقعیت نهفته است که ما به طور مستقل HFiles را تشکیل می دهیم و آنها را روی دیسک قرار می دهیم، که به ما امکان می دهد به طور عالی مقیاس کنیم و به سرعت های بسیار مناسبی دست یابیم. در واقع، محدودیت در اینجا HBase نیست، بلکه قابلیت های سخت افزار است. در زیر نتایج بوت در یک کلاستر متشکل از 16 RegionServer و 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 Threads)، نسخه HBase 1.2.0-cdh5.14.2 آمده است.

در اینجا مشاهده می کنید که با افزایش تعداد پارتیشن ها (منطقه ها) در جدول و همچنین مجری های Spark، سرعت دانلود را افزایش می دهیم. همچنین سرعت به میزان صدای ضبط بستگی دارد. بلوک های بزرگ باعث افزایش در مگابایت بر ثانیه می شوند، بلوک های کوچک در تعداد رکوردهای درج شده در واحد زمان، همه چیزهای دیگر برابر هستند.

همچنین می توانید به طور همزمان بارگذاری را در دو جدول شروع کنید و سرعت آن را دو برابر کنید. در زیر می بینید که نوشتن 10 کیلوبایت بلوک روی دو جدول به طور همزمان با سرعتی در حدود 600 مگابایت بر ثانیه در هر کدام (در مجموع 1275 مگابایت بر ثانیه) اتفاق می افتد که همزمان با سرعت نوشتن یک جدول به 623 مگابایت بر ثانیه است. شماره 11 بالا)

اما اجرای دوم با رکوردهای 50 کیلوبایتی نشان می دهد که سرعت دانلود کمی در حال رشد است که نشان دهنده نزدیک شدن به مقادیر حدی است. در عین حال، باید در نظر داشته باشید که عملاً هیچ باری روی خود HBASE ایجاد نمی‌شود، تنها چیزی که لازم است این است که ابتدا داده‌ها را از hbase:meta داده و پس از خط‌بندی HFiles، داده‌های BlockCache را ریست کرده و ذخیره کنید. بافر MemStore به دیسک، اگر خالی نباشد.

3. خواندن داده ها از HBASE

اگر فرض کنیم که کلاینت از قبل تمام اطلاعات hbase:meta را دارد (نقطه 2 را ببینید)، آنگاه درخواست مستقیماً به RS می رود که در آن کلید مورد نیاز ذخیره می شود. ابتدا جستجو در MemCache انجام می شود. صرف نظر از اینکه داده وجود دارد یا خیر، جستجو در بافر BlockCache و در صورت لزوم در HFiles نیز انجام می شود. اگر داده‌ای در فایل یافت شد، در BlockCache قرار می‌گیرد و در درخواست بعدی سریع‌تر بازگردانده می‌شود. جستجو در HFile به لطف استفاده از فیلتر Bloom، یعنی. با خواندن مقدار کمی از داده ها، بلافاصله تعیین می کند که آیا این فایل حاوی کلید مورد نیاز است یا خیر و اگر نه، سپس به بعدی می رود.

با دریافت داده از این سه منبع، RS یک پاسخ تولید می کند. به ویژه، اگر مشتری درخواست نسخه‌سازی را داشته باشد، می‌تواند چندین نسخه یافت شده از یک شی را به طور همزمان منتقل کند.

4. کش داده ها

بافرهای MemStore و BlockCache تا 80 درصد از حافظه اختصاصی RS روی هیپ را اشغال می کنند (بقیه برای وظایف خدمات RS محفوظ است). اگر حالت استفاده معمولی به گونه ای است که پردازش ها همان داده ها را می نویسند و بلافاصله می خوانند، پس منطقی است که BlockCache را کاهش دهیم و MemStore را افزایش دهیم، زیرا وقتی داده‌های نوشتن برای خواندن وارد حافظه پنهان نمی‌شوند، از BlockCache کمتر استفاده می‌شود. بافر BlockCache از دو بخش تشکیل شده است: LruBlockCache (همیشه روی هیپ) و BucketCache (معمولاً off-heap یا روی SSD). BucketCache باید زمانی استفاده شود که درخواست‌های خواندن زیادی وجود دارد و آنها در LruBlockCache قرار نمی‌گیرند، که منجر به کار فعال Garbage Collector می‌شود. در عین حال، نباید انتظار افزایش شدید عملکرد را از استفاده از حافظه پنهان خواندن داشته باشید، اما در پاراگراف 8 به این موضوع باز خواهیم گشت.

یک BlockCache برای کل RS وجود دارد، و یک MemStore برای هر جدول (یکی برای هر Column Family) وجود دارد.

مانند شرح داده شده در تئوری، هنگام نوشتن، داده ها به حافظه پنهان نمی روند و در واقع، چنین پارامترهایی CACHE_DATA_ON_WRITE برای جدول و "Cache DATA on Write" برای RS روی false تنظیم می شوند. با این حال، در عمل، اگر داده‌ها را در 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

پارامتر "Cache DATA on Read" روی false تنظیم شده است. اگر ایده ای دارید، خوش آمدید در نظرات درباره آن صحبت کنید.

5. پردازش دسته ای داده MultiGet/MultiPut

پردازش درخواست های منفرد (Get/Put/Delete) عملیات بسیار گرانی است، بنابراین در صورت امکان، باید آنها را در یک لیست یا فهرست ترکیب کنید که به شما امکان می دهد عملکرد قابل توجهی را افزایش دهید. این امر به ویژه در مورد عملیات نوشتن صادق است، اما هنگام خواندن مشکل زیر وجود دارد. نمودار زیر زمان خواندن 50 رکورد از MemStore را نشان می دهد. خواندن در یک رشته انجام شد و محور افقی تعداد کلیدهای درخواست را نشان می دهد. در اینجا می توانید ببینید که هنگام افزایش به هزار کلید در یک درخواست، زمان اجرا کاهش می یابد، یعنی. سرعت افزایش می یابد. با این حال، با فعال بودن حالت MSLAB به طور پیش‌فرض، پس از این آستانه، افت شدید عملکرد شروع می‌شود و هر چه مقدار داده در رکورد بیشتر باشد، زمان عملیات طولانی‌تر می‌شود.

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

حالت MSLAB برای کاهش تکه تکه شدن پشته طراحی شده است که به دلیل اختلاط داده های نسل جدید و قدیمی رخ می دهد. به عنوان یک راه حل، هنگامی که MSLAB فعال است، داده ها در سلول های نسبتا کوچک (تکه ها) قرار می گیرند و به صورت تکه ای پردازش می شوند. در نتیجه، وقتی حجم بسته داده درخواستی از اندازه تخصیص داده شده بیشتر شود، عملکرد به شدت کاهش می یابد. از سوی دیگر، خاموش کردن این حالت نیز توصیه نمی شود، زیرا در لحظات پردازش فشرده داده منجر به توقف به دلیل GC می شود. یک راه حل خوب افزایش حجم سلول در مورد نوشتن فعال از طریق put همزمان با خواندن است. شایان ذکر است که اگر پس از ضبط، دستور flush را اجرا کنید، که MemStore را به دیسک بازنشانی می کند، یا با استفاده از BulkLoad بارگیری کنید، مشکل ایجاد نمی شود. جدول زیر نشان می‌دهد که درخواست‌های MemStore برای داده‌های بزرگتر (و به همان میزان) منجر به کاهش سرعت می‌شود. با این حال، با افزایش حجم، زمان پردازش را به حالت عادی برمی‌گردانیم.

علاوه بر افزایش حجم، تقسیم داده ها بر اساس منطقه کمک می کند، یعنی. جدا کردن جدول این منجر به ارسال درخواست های کمتری به هر منطقه می شود و اگر آنها در یک سلول قرار بگیرند، پاسخ خوب باقی می ماند.

6. استراتژی برای تقسیم جداول به مناطق (تقسیم)

از آنجایی که HBase یک ذخیره سازی کلید-مقدار است و پارتیشن بندی توسط کلید انجام می شود، بسیار مهم است که داده ها را به طور مساوی در همه مناطق تقسیم کنید. به عنوان مثال، تقسیم چنین جدولی به سه قسمت منجر به تقسیم داده ها به سه منطقه می شود:

این اتفاق می افتد که اگر داده های بارگذاری شده بعداً مانند مقادیر طولانی به نظر برسد که بیشتر آنها با یک رقم شروع می شوند، منجر به کاهش شدید سرعت می شود، به عنوان مثال:

1000001
1000002
...
1100003

از آنجایی که کلیدها به عنوان یک آرایه بایت ذخیره می شوند، همه آنها یکسان شروع می شوند و به همان منطقه شماره 1 تعلق دارند که این محدوده از کلیدها را ذخیره می کند. چندین استراتژی پارتیشن بندی وجود دارد:

HexStringSplit – کلید را به یک رشته کدگذاری شده هگزادسیمال در محدوده "00000000" => "FFFFFFFF" تبدیل می کند و در سمت چپ با صفر قرار می دهد.

UniformSplit – کلید را به یک آرایه بایت با کدگذاری هگزا دسیمال در محدوده "00" => "FF" تبدیل می کند و در سمت راست با صفر قرار می گیرد.

علاوه بر این، می توانید هر محدوده یا مجموعه ای از کلیدها را برای تقسیم و پیکربندی تقسیم خودکار مشخص کنید. با این حال، یکی از ساده‌ترین و مؤثرترین رویکردها، UniformSplit و استفاده از الحاق هش است، برای مثال مهم‌ترین جفت بایت از اجرای کلید از طریق تابع CRC32 (rowkey) و خود کلید ردیف:

هش + rowkey

سپس تمام داده ها به طور مساوی در بین مناطق توزیع می شود. هنگام خواندن، دو بایت اول به سادگی کنار گذاشته می شوند و کلید اصلی باقی می ماند. RS همچنین مقدار داده ها و کلیدهای منطقه را کنترل می کند و در صورت تجاوز از محدودیت ها، به طور خودکار آن را به قطعات تقسیم می کند.

7. تحمل خطا و محل داده ها

از آنجایی که تنها یک منطقه مسئول هر مجموعه از کلیدها است، راه حل مشکلات مرتبط با خرابی یا از کار افتادن RS، ذخیره تمام داده های لازم در HDFS است. وقتی RS می افتد، استاد این را از طریق عدم وجود ضربان قلب در گره ZooKeeper تشخیص می دهد. سپس منطقه ارائه شده را به 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 Thread) انجام شد. نسخه HBase 1.2.0-cdh5.14.2

شایان ذکر است که فشرده سازی عمده روی یک جدول "زنده" راه اندازی شد که داده ها به طور فعال در آن نوشته و خوانده می شد. بیانیه ای آنلاین وجود داشت که این می تواند منجر به پاسخ نادرست هنگام خواندن داده ها شود. برای بررسی، فرآیندی راه‌اندازی شد که داده‌های جدیدی تولید کرد و آن‌ها را در جدول نوشت. پس از آن بلافاصله خواندم و بررسی کردم که آیا مقدار حاصل با آنچه که نوشته شده بود مطابقت دارد یا خیر. در حالی که این فرآیند در حال اجرا بود، تراکم عمده حدود 200 بار اجرا شد و حتی یک شکست نیز ثبت نشد. شاید این مشکل به ندرت و فقط در زمان بارگذاری زیاد ظاهر شود، بنابراین ایمن‌تر است که فرآیند نوشتن و خواندن را طبق برنامه‌ریزی شده متوقف کنید و برای جلوگیری از چنین کاهش‌هایی GC تمیز کنید.

همچنین، تراکم عمده بر وضعیت MemStore تأثیر نمی‌گذارد؛ برای تراکم آن روی دیسک و فشرده‌سازی آن، باید از flush (connection.getAdmin().flush(TableName.valueOf(tblName)) استفاده کنید.

8. تنظیمات و عملکرد

همانطور که قبلا ذکر شد، HBase بیشترین موفقیت خود را در جایی نشان می دهد که نیازی به انجام کاری نداشته باشد، هنگام اجرای BulkLoad. با این حال، این برای اکثر سیستم ها و افراد صدق می کند. با این حال، این ابزار برای ذخیره داده‌ها به صورت انبوه در بلوک‌های بزرگ مناسب‌تر است، در حالی که اگر فرآیند نیازمند چندین درخواست خواندن و نوشتن رقیب باشد، از دستورات Get و 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.
ج. فشرده سازی روی GZ تنظیم شد.
د 10 رشته به طور همزمان با انجام عملیات 1/10 put/get/get+put در این جدول با رکوردهای 100/1000/10000 بایت، انجام 50 پرس و جو در یک ردیف (کلیدهای تصادفی) راه اندازی شد.
ه. نقطه d سه بار تکرار شد.
f. مدت زمان کار تمام نخ ها به طور متوسط ​​محاسبه شد.

تمام ترکیبات ممکن مورد آزمایش قرار گرفتند. قابل پیش بینی است که با افزایش اندازه رکورد سرعت کاهش می یابد یا غیرفعال کردن حافظه پنهان باعث کاهش سرعت می شود. با این حال، هدف درک درجه و اهمیت تأثیر هر پارامتر بود، بنابراین داده‌های جمع‌آوری‌شده به ورودی یک تابع رگرسیون خطی وارد شدند، که امکان ارزیابی اهمیت با استفاده از آماره t را ممکن می‌سازد. در زیر نتایج بلوک هایی که عملیات Put را انجام می دهند آورده شده است. مجموعه کامل ترکیبات 2*2*3*2*3 = 144 گزینه + 72 tk. برخی دو بار انجام شد. بنابراین، در مجموع 216 اجرا وجود دارد:

آزمایش بر روی یک مینی خوشه متشکل از 3 DataNodes و 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 Thread) انجام شد. نسخه HBase 1.2.0-cdh5.14.2.

بالاترین سرعت درج 3.7 ثانیه با حالت MSLAB خاموش، در جدولی با یک پارتیشن، با فعال کردن BlockCache، BlockSize = 16، رکوردهای 100 بایت، 10 قطعه در هر بسته به دست آمد.
کمترین سرعت درج 82.8 ثانیه با فعال کردن حالت MSLAB، روی یک جدول با یک پارتیشن، با فعال کردن BlockCache، BlockSize = 16، رکوردهای 10000 بایت، هر کدام 1 به دست آمد.

حالا بیایید به مدل نگاه کنیم. ما شاهد کیفیت خوب مدل مبتنی بر R2 هستیم، اما کاملاً واضح است که برون یابی در اینجا ممنوع است. رفتار واقعی سیستم در هنگام تغییر پارامترها خطی نخواهد بود؛ این مدل نه برای پیش بینی، بلکه برای درک آنچه در پارامترهای داده شده اتفاق افتاده است مورد نیاز است. به عنوان مثال، در اینجا از معیار Student می‌بینیم که پارامترهای BlockSize و BlockCache برای عملیات Put مهم نیستند (که معمولاً کاملاً قابل پیش‌بینی است):

اما این واقعیت که افزایش تعداد پارتیشن ها منجر به کاهش عملکرد می شود تا حدودی غیرمنتظره است (ما قبلاً تأثیر مثبت افزایش تعداد پارتیشن ها با BulkLoad را مشاهده کرده ایم)، اگرچه قابل درک است. اولاً، برای پردازش، شما باید به جای یک منطقه، درخواست‌ها را به 30 منطقه ایجاد کنید، و حجم داده‌ها به اندازه‌ای نیست که سود داشته باشد. ثانیا، کل زمان عملیاتی توسط کندترین RS تعیین می شود و از آنجایی که تعداد DataNode ها از تعداد RS ها کمتر است، برخی از مناطق دارای محلی بودن صفر هستند. خوب، بیایید به پنج مورد برتر نگاه کنیم:

حالا بیایید نتایج اجرای بلوک های Get را ارزیابی کنیم:

تعداد پارتیشن ها اهمیت خود را از دست داده است، که احتمالاً با این واقعیت توضیح داده می شود که داده ها به خوبی کش می شوند و حافظه پنهان خوانده شده مهم ترین پارامتر (از نظر آماری) است. طبیعتا افزایش تعداد پیام ها در یک درخواست نیز برای عملکرد بسیار مفید است. بالاترین امتیازها:

خوب، در نهایت، بیایید به مدل بلوکی که ابتدا دریافت و سپس قرار دادیم نگاه کنیم:

همه پارامترها در اینجا مهم هستند. و نتایج رهبران:

9. تست بار

خوب، در نهایت ما یک بار کم و بیش مناسب راه اندازی خواهیم کرد، اما زمانی که چیزی برای مقایسه داشته باشید همیشه جالب تر است. در وب سایت DataStax، توسعه دهنده کلیدی Cassandra، وجود دارد یافته ها NT تعدادی از حافظه های NoSQL، از جمله نسخه HBase 0.98.6-1. بارگذاری توسط 40 رشته، حجم داده 100 بایت، دیسک های SSD انجام شد. نتیجه آزمایش عملیات Read-Modify-Write نتایج زیر را نشان داد.

تا آنجا که من متوجه شدم، خواندن در بلوک های 100 رکوردی انجام شد و برای 16 گره HBase، تست DataStax عملکرد 10 هزار عملیات در ثانیه را نشان داد.

خوشبختانه خوشه ما همچنین دارای 16 گره است، اما خیلی خوش شانس نیست که هر کدام 64 هسته (رشته) دارند، در حالی که در تست DataStax فقط 4 هسته وجود دارد. از طرف دیگر، آنها درایوهای SSD دارند، در حالی که ما هارد دیسک داریم. یا بیشتر، نسخه جدید 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 Threads). نسخه HBase 1.2.0-cdh5.14.2.

میانگین نتیجه نزدیک به 40 هزار عملیات در ثانیه است که به طور قابل توجهی بهتر از تست DataStax است. با این حال، برای اهداف آزمایشی، می توانید کمی شرایط را تغییر دهید. بعید است که تمام کارها منحصراً روی یک میز و همچنین فقط روی کلیدهای منحصر به فرد انجام شود. بیایید فرض کنیم که مجموعه‌ای از کلیدهای داغ وجود دارد که بار اصلی را ایجاد می‌کند. بنابراین بیایید سعی کنیم یک بار با رکوردهای بزرگتر (10 کیلوبایت) نیز در دسته های 100 تایی در 4 جدول مختلف ایجاد کنیم و محدوده کلیدهای درخواستی را به 50 هزار محدود کنیم. مجموعه ای از 40 کلید و بلافاصله 100 کیلوبایت تصادفی روی این کلیدها می نویسد.

پایه: 16 DataNode و 16 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 Threads). نسخه 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 Threads). نسخه HBase 1.2.0-cdh5.14.2.

10. نتیجه گیری

این سیستم کاملاً انعطاف‌پذیر پیکربندی شده است، اما تأثیر تعداد زیادی از پارامترها هنوز ناشناخته باقی مانده است. برخی از آنها مورد آزمایش قرار گرفتند، اما در مجموعه آزمایشی حاصل قرار نگرفتند. برای مثال، آزمایش‌های اولیه اهمیت ناچیز پارامتری مانند DATA_BLOCK_ENCODING را نشان داد که اطلاعات را با استفاده از مقادیر سلول‌های همسایه رمزگذاری می‌کند، که برای داده‌های تولید شده به‌طور تصادفی قابل درک است. اگر از تعداد زیادی اشیاء تکراری استفاده می کنید، بهره می تواند قابل توجه باشد. به طور کلی می توان گفت که HBase تصور یک پایگاه داده نسبتاً جدی و سنجیده را ایجاد می کند که می تواند هنگام انجام عملیات با بلوک های بزرگ داده کاملاً سازنده باشد. به خصوص اگر بتوان فرآیند خواندن و نوشتن را به موقع از هم جدا کرد.

اگر چیزی به نظر شما وجود دارد که به اندازه کافی فاش نشده است، من آماده هستم که جزئیات بیشتری را به شما بگویم. ما از شما دعوت می کنیم تا در صورت مخالفت با چیزی، تجربیات خود را به اشتراک بگذارید یا بحث کنید.

منبع: www.habr.com