ذخیره سازی فایل های کم حجم یکی از مسائلی هست که اکثر برنامهنویسهای وب باهاش برخورد میکنن و ممکنه خیلی ساده به نظر بیاد. البته اکثر برنامه نویسها راه حلهای سادهای برای این مسئله دارن.
ایده خیلی سادهست. فایلها رو روی دیسک ذخیره میکنیم و آدرس اونها به عنوان Meta در دیتابیس ذخیره میکنیم. بنابراین خیلی راحت میشه با داشتن آدرسها به فایلها دسترسی داشت. اکثر اوقات این فایلها به صورت Local ذخیره میشن و گاهی هم از طریق nfs روی وبسرور مانت میشن.
این روش تا حالا برای کاربردهای معمولی و ساده خیلی خوب جواب داده اما اگر با چند صد میلیون فایل روبرو باشیم این روش دو ایراد خیلی بزرگ داره.
۱) عدم مقیاس پذیری (فضای ذخیره سازی / توزیع بار) : به عبارتی ساده خوندن و نوشتن داده به یک سرور محدود میشه که محدودیت دیسک و کارت شبکه مهمترین عامل افت کارایی خواهد بود.
۲) عدم وجود نسخه دوم (replication) : هیچ نسخه دومی از فایلها وجود نداره و در صورتی که فایلی به هر دلیلی مثل خرابی دیسک از بین بره راهی برای بازیابی وجود نداره.
MOB
MOB یا Medium Object Storage قابلیتی هست که برای براورده کردن چنین نیازمندی در نسخه ۲ HBase ارائه شده. این قابلیت باعث میشه که HBase فایلهایی با حجم بین چند کیلو بایت تا ۱۰ مگابایت رو به خوبی و با تاخیر پایین ذخیره و بازیابی کنه.
در حقیقت در نسخههای قبلی HBase به دلیل وجود Compactionهای متعدد ، نوشتن و خوندن فایلها با تاخیر زیاد مواجه میشد. بنابراین در نسخه جدید با در نظر گرفتن این مسئله ، تا حدی در ذخیره سازی فایلهای کم حجم بهبود داشته.
فایلها یا همون MOB objects ها در یک Region با اسم MOB در قالب یک سری فایل ذخیره میشن. پس به طور خلاصه فایلهای کم حجم در در فایلهای بزرگتری ذخیره میشن و HBase با داشتن Metaها قابلیت جواب دادن درخواستهای READ رو داره.
فایلهای MOB در ابتدای کار ممکنه حجم کمی داشته باشن (مثلا کمتر از بلاکهای HDFS) بنابراین در طول زمان این فایلها بر اساس یک سری سیاستها با هم دیگه ادغام میشن (اصطلاحا MOB compaction) و فایلهای بزرگتری رو به وجود میارن.
برای اینکه بیشتر با این روند آشنا بشیم فرض کنید یک جدول داریم به اسم t1 و Column Family به اسم cf1. این جدول از دو ریجن D279186428a75016b17e4df5ea43d080 و D41d8cd98f00b204e9800998ecf8427e تشکیل شده.
برای ریجن اول در هر کدام از تاریخهای 1/1/2016 و 1/2/2016 دو فایل MOB ایجاد شدن و برای ریجن دوم هم سه فایل MOB داریم که هر سه در تاریخ 1/1/2016 بوجود اومدن.
بنابراین انتظار داریم روی hdfs در مسیر زیر ۷ فایل MOB داشته باشیم
hdfs dfs -ls /hbase/data/mobdir/data/default/t1/78e317a6e78a0fceb27b9fa0cb9dcf5b/cf1
D279186428a75016b17e4df5ea43d08020160101f9d9713ab2fb4a8b825485f6a8acfcd5
D279186428a75016b17e4df5ea43d08020160101af7713ab2fbf4a8abc5135f6a8467ca8
D279186428a75016b17e4df5ea43d080201601029013ab2fceda8b825485f6a8acfcd515
D279186428a75016b17e4df5ea43d080201601029a7978013ab2fceda8b825485f6a8acf
D41d8cd98f00b204e9800998ecf8427e20160101fc94af623c2345f1b241887721e32a48
D41d8cd98f00b204e9800998ecf8427e20160101d0954af623c2345f1b241887721e3259
D41d8cd98f00b204e9800998ecf8427e20160101439adf4af623c2345f1b241887721e32
فرض کنید سیاست Compaction طوری باشه که همهی فایلهای مربوط به یک روز با همدیگه ادغام بشن. بنابراین انتظار داریم فایلهای تاریخ 1/1/2016 با هم و 1/2/2016 با هم و …
در نتیجه فقط ۳ فایل باید داشته باشیم :
D279186428a75016b17e4df5ea43d08020160101f49a9d9713ab2fb4a8b825485f6a8acf
D279186428a75016b17e4df5ea43d08020160102bc9176d09424e49a9d9065caf9713ab2
D41d8cd98f00b204e9800998ecf8427e20160101d9cb0954af623c2345f1b241887721e3
با توجه به اینکه طی سال ۳۶۵ روز داریم ، حداقل (۳۶۵ x تعداد ریجنها) فایل MOB برای یک سال خواهیم داشت. بنابراین برای ۱۰۰۰ ریجن ، طی ۱۰ سال حدود ۳.۶ میلیون فایل MOB داریم و تعدادشون رفته رفته بیشتر هم میشه. از طرفی hdfs برای داشتن تعداد فایلهای بیشتر به ram بیشتری نیاز داره و افزایش تعداد این فایلها باعث میشه NameNode به حافظه بیشتری نیاز داشته باشه. همچنین پارامتری در hdfs بیشترین تعداد فایلهای موجود در یک دایرکتوری رو مشخص میکنه (dfs.namenode.fs-limits.max-directory-items) که به صورت پیشفرض مقدار اون یک میلیون هست. که برای ۱۰۰۰ ریجن فقط حدود ۳ سال دوام میاره.
در HBASE-16981 برای کاهش این مشکلات روشهای ادغام هفتگی و ماهانه معرفی شد. در این حالت به ازای یک هفته/ماه فقط یک فایل به وجود میاد که به مراتب حجم بیشتری داره.
نحوه اجرای این ادغام اهمیت زیادی داره. مثلا فرض کنید از روش ادغام ماهانه استفاده میکنیم. در آخر هر روز فایلهای روز فعلی باید با فایلهای روز قبل ادغام بشن. بنابراین تا پایان ماه فایلهای مروبط به روز اول ۳۰ بار نوشته و خونده میشن! واضحه که چنین سیاستی کارایی سیستم رو به شکل قابل توجهی تحت تاثیر قرار میده .
پیاده سازی نهایی
برای جلوگیری از ادغامهای مکرر دادههای یکسان، HBASE-16981 پیشنهاد شد. در شکل بالا فایلهای مربوط به روز ۱۵ نوامبر با هم و ۱۴ نوامبر هم به طور مجزا با هم ادغام شدن. همچنین فایلهای تقویم هفتگی (روزهای ۷ نوامبر تا ۱۳ نوامبر) هم به طور مجزا با هم و فایلهای تقویم هفتگی اول ماه با هم ادغام شدن. به همین ترتیب بر اساس تقویم ماهانه فایلهای مربوط به ماه گذشته با هم ادغام شدن.ممکنه فکر کنید که یک اشتباه رخ داده و هفته اول ماه بجای ۷ روز ، ۶ روز در نظر گرفته شده. اما باید دقت کنید که اولین تقویم هفتگی نوامبر ۲۰۱۶ از تاریخ ۱۰/۳۱/۲۰۱۶ تا ۱۱/۶/۲۰۱۶ هست و چون ادغام ماهانه اتفاق افتاده فایلهای مربوط به روز اول این هفته با فایلهای ماه قبل ادغام شدن (:
بنابراین تا این مرحله باید فقط ۵ فایل داشته باشیم. با این پیاده سازی فایلها معمولا ۳ بار ادغام میشن ( یکبار ادغام روزانه و یکبار هفتهای و یکبار دیگر ماهانه)
اصل این مقاله رو میتونید از بلاگ کلودرا که هنوز تحریم نیست بخونید (: