سيستم‌هاي فايلي در عصر کلان داده

سرویس S3 آمازون و سيستم فایلی Dynamo

همزمان با ايجاد پلتفرم ارائه خدمات وب توسط شرکت آمازون، اين شرکت با مشکلاتي مواجه شد که کاملاً متفاوت از مشکلات گوگل بود. تا همين اواخر داينامو نيز همانند GFS، به صورت مستقیم در اختيار مشتريان قرار نگرفته بود. بر اساس گفته ورنت فوگلز (Wernet Vogels) مدير فني ارشد آمازون که در سال ۲۰۰۷ در وب‌لاگ شخصي او منتشر شد، تنها کاربردها و امکانات اوليه ساختار ذخيره‌سازي سرویس‌های وبی شرکت آمازون است که به طور گسترده در اختيار مشتريان آمازون قرار گرفته است. سرويس Simple Storage Service يا ‌S3 و SimpleDB از جمله اين موارد است. اما در ژانويه امسال (۲۰۱۲) شرکت آمازون سرويس پايگاه‌داده‌اي به نام داينامو DB را معرفي کرد که بر اساس آخرين اصلاحات انجام شده روي داينامو، عرضه شده‌بود. اين محيط، يک رابط مستقيم براي کار با يک پايگاه‌داده NoSQL را به مشتريان عرضه مي‌کرد. سيستم داينامو، شباهت‌هاي محدودي با GFS و HDFS دارد. اين سيستم‌فايلي نيز نگراني و توجه کمتري به ثبات داده در سطح سيستم دارد و تبادل داده براي دسترسي‌پذيري بالا را پشتيباني مي‌کند. اين سيستم‌فايلي روي مجموعه‌اي عظيم از سخت‌افزارهاي شرکت آمازون اجرا خواهد شد. به غير از اين موارد، شباهت‌هاي اين سيستم با موارد قبلي ناچيز است، زيرا نيازمندي‌هاي شرکت آمازون که منجر به پياده‌سازي داينامو شد، کاملاً متفاوت بودند.

شکل ۳- دیاگرام ساده شده سیستم‌فایلی داینامو

آمازون به سيستم‌فايلي‌اي نياز دارد که با روش‌هاي معمول‌تر دسترسي به داده سازگار باشد. مواردي نظير تجارت الکترونيک اين شرکت، سبدهاي خريد مشتريان و ساير سيستم‌هاي با ماهيت تراکنشي شديد، از جمله نيازهاي اين شرکت به شمار مي‌رود. اين شرکت همچنين نيازمند دسترسي پوياتر به حجم کمتري از داده است. اين سيستم‌فايلي به جاي آن که براي دسترسي به جريان‌هاي بزرگ داده بهينه‌سازي شده ‌باشد، بايد طوري طراحي مي‌شد که بتواند دسترسي تصادفي به قطعات کوچک‌تر داده را بهتر انجام دهد. به عنوان مثال، يکي از نيازهاي آمازون سرويس‌دهي به صفحات وب و دسترسي به اين صفحات است. در مستندات فوگلز و تيم کاري او که در اکتبر ۲۰۰۷، در سمپوزيومي درباره مباني سيستم‌عامل‌ها منتشر شد، اين طور عنوان شده که: «داينامو براي پاسخ‌گويي به نياز برنامه‌هايي طراحي شده که داده‌هاي آن به نسبت کوچک است و اندازه داده معمولاً کمتر از يک مگابايت است.» اين سيستم به جاي آن‌که بيشتر براي خواندن داده‌ها، بهينه‌سازي شده ‌باشد، طوري طراحي شده که بتواند هميشه از امکان نوشتن مجدد پشتيباني کند و بيشتر براي نوشتن داده در دسترس باشد که از اين جهت کاملاً عکس مدل شرکت گوگل ‌است. در‌ مستندات گروه Amazon داينامو آمده است: «در بعضي از سرويس‌ها، اگر درخواست‌هاي مشتريان براي به‌روزرساني داده‌ها رد شود، در اين صورت با عدم رضايت مشتريان مواجه مي‌شويم. براي مثال، سرويس سبد خريد بايد به مشتريان اجازه دهد تا موارد مورد نظر خود را به سبد خريد بيافزايند يا حذف کنند حتي اگر با بروز خطا در سطح سرور يا شبکه، مواجه باشيم.» در عين حال، سرويس‌هاي مبتني بر داينامو را مي‌توان در مورد مجموعه داده‌هاي بزرگ‌تر نيز به کار برد. در حقيقت شرکت آمازون سرويس مبتني بر هادوپ خود با نام Elastic Map Reduce را براساس S3 عرضه مي‌کند که خود روي لايه داينامو، استوار است.

براي پاسخ‌گويي به اين دسته از نيازمندي‌ها، معماري سيستم‌فايلي داينامو، کاملاً معکوس معماري GFS است. اين معماري بيشتر شبيه به سيستم‌هاي نظيربه‌نظير(Peer to Peer) است که در مقابل سيستم‌ مرجع-پيرو (master-slave) قرار مي‌گيرد. نحوه پياده‌سازي ثبت و ذخیره داده در سيستم‌فايلي داينامو متفاوت است و مسئله شناسايي کپي معتبر در بين داده‌هاي موجود، مطرح نمي‌شود. در نتيجه فرآيند شناسايي تناقضات در هنگام خواندن داده انجام مي‌شود. به اين ترتيب سيستم‌فايلي داينامو، هيچ‌گاه درخواست‌هاي نوشتن را بي‌پاسخ نمي‌گذارد، چه اين درخواست از نوع نوشتن داده جديد باشد، چه از نوع تغيير در داده موجود. به طور کلي فرآيند تهيه کپي از داده، بعداً انجام مي‌شود. به دليل نگراني در مورد بروز خطا در سرور مرجع و تبديل شدن آن به عامل شکست کل سيستم‌فايلي (اين مسئله بر اساس تجربه قبلي از دسترس خارج شدن سرويس‌ها و سيستم‌ها مطرح شد) و همچنين به دليل سرعت بالاي افزوده شدن سخت‌افزار به زيرساختار محيط ابري آمازون، گروه فوگلز تصميم گرفت تا يک رويکرد غيرمتمرکز براي کپي‌برداري از داده‌ها، ارائه دهد. اين روش بر اساس يک الگوي شخصي از تکه‌تکه کردن داده‌ها مطرح شد که بر‌اساس مفهومي به نام Consistent Hashing پياده‌سازي شده است. منابع هر يک از کلاسترهاي سيستم‌فايلي داينامو به صورت يک زنجيره از فضاهاي آدرس در نظر گرفته مي‌شوند. در اين روش به هر يک از نودهاي رسانه ذخيره‌سازي در زمان افزوده شدن به کلاستر، يک شماره تصادفي اختصاص مي‌يابد. اين عدد نشان‌دهنده جايگاه‌ آن نود در زنجيره سيستم‌فايلي داينامو است. متناسب با تعداد نودهاي رسانه‌هاي ذخيره‌سازي در هر‌يک از کلاسترها، هر نود بر اساس موقعيت خود، وظيفه پاسخ‌گويي به درخواست‌هايي را دارد که براي تعدادي از فضاهاي آدرس ارسال مي‌شود. با افزوده شدن نودهاي ذخيره‌سازي به حلقه، فضاهاي آدرس در اختيار آن‌ها نيز قرار مي‌گيرد و نودهاي مستقر در هر دو سمت نود جديد، محدوده آدرسي را که مسئول پاسخ‌گويي به آن هستند، از نو تنظيم مي‌کنند. از آنجا که آمازون نگران عدم توازن بارکاري روي سيستم رسانه ذخيره‌سازي بود و احتمال وقوع اين مشکل به موازات افزوده شدن سخت‌افزارهاي جديدتر و بهتر وجود داشت، در نتيجه داينامو اين قابليت را در نظر گرفت که بتواند چندين نود مجازي را به هر يک از نودهاي فيزيکي اختصاص دهد. به اين ترتيب، سهم بزرگ‌تري از بار پاسخ‌گويي به درخواست فضاي آدرس را براي سيستم‌هايي از سطح کلاستر که عملکرد و توانايي بيشتري دارند، در نظر مي‌گيرد. با نوشتن داده در سيستم‌فايلي داينامو از طريق ارسال درخواست از نوع “put”، سيستم به شيء داده‌اي که بايد نوشته شود، يک کليد اختصاص مي‌دهد. اين کليد به يک MD5 hash 128 بيتي خورانده مي‌شود. رقم توليد شده به عنوان آدرس داده در حلقه داينامو در نظر گرفته مي‌شود. نود داده مسئول آن آدرس به عنوان «نود هماهنگ‌کننده» يا «coordinator node» در نظر گرفته مي‌شود و مسئول پاسخ‌گويي به درخواست‌هايي است که به ازاي اين داده ارسال مي‌شود و همچنين مسئوليت تهيه کپي از اين داده روي ساير نودهاي حلقه نيز به عهده همين نود است. در شکل ۳ دياگرام انجام اين فرآيند را مشاهده مي‌کنيد. اين کار باعث توزيع داده در سطح همه نودهاي سيستم مي‌شود و در صورت خرابي يک نود، همسايه‌هاي مجازي آن در سطح حلقه درخواست‌ها را دريافت کرده و جاي خالي نود خراب را با پرکردن فضاي خالي از طريق کپي‌هاي داده، مديريت مي‌کنند. در مرحله بعد، الگوي کنترل ثبات داده مطرح مي‌شود. زماني که درخواستي از نوع “get” توسط کلاينت‌ها، مطرح مي‌شود. داينامو به بررسي نودها مي‌پردازد تا نودي که داده مذکور را در اختيار دارد، شناسايي کند. هر يک از نودهايي که کپي داده را در اختيار دارند پاسخ‌داده و اطلاعاتي را در مورد زماني که آخرين تغيير در آن‌ها اعمال شده، اعلام مي‌کنند و يک سيستم کنترل نگارش(با نام Vector Clock) که مسئول رديابي وابستگي بين تغييرات است، از اين داده‌ها استفاده مي‌کند. متناسب با تنظيمات سيستم‌فايلي، پردازه درخواست‌کننده مي‌تواند منتظر نخستين پاسخ شود و آن‌را بازگرداند (اگر برنامه براي دسترسي به داده عجله داشته‌باشد حالتی رخ مي‌دهد که همانند سيستم‌فايلي هادوپ به احتمال کم ممکن است تناقضاتي در داده دريافتي وجود داشته‌باشد.) يا آن‌که برنامه مي‌تواند منتظر باشد تا دو، سه يا چندين کپي از داده را در اختيار بگیرد. در صورت دريافت جواب‌هاي مختلف از نودهاي ذخيره‌سازي، پردازه درخواست‌کننده داده‌ها را با هم مقايسه مي‌کند تا جديدترين داده را داشته باشد و به نودهاي ديگر اعلام مي‌کند که داده آن‌ها کهنه و قديمي است و بايد جديدترين کپي داده را از نود خاصي دريافت کنند، يا آن‌که پردازه به ادغام داده‌هايي مي‌پردازد که ويرايش‌هاي غيرمتناقض در آن‌ها وجود دارد. اين الگو در بيشتر موارد انعطاف‌پذيري مورد نياز را فراهم مي‌کند. اگر نودها از مدار خارج شوند و نودهاي جديد وارد مدار شوند نيز آخرين داده در نود جديد کپي مي‌شود.

آخرين اصلاحات و بهبودها در سيستم‌فايلي داينامو و همچنين ايجاد داينامو DB، مي‌تواند پاسخ‌گوي اين سؤال باشد که چرا توسعه‌دهندگان اين شرکت حاضر نشدند خود داينامو را به عنوان زيربناي برنامه‌هاي خود در نظر بگیرند و در عوض به سرويس‌هايي نظير سرويس‌هاي S3، SimpleDB و Elastic Block Storage اتکا کردند که روي اين سيستم‌فايلي ايجاد شده بود. مشکلاتي که آمازون در ماه آوريل ۲۰۱۱ با آن‌ها مواجه شد، نتيجه کمبود منابع بود و اين مورد نيز در اثر تنظيمات محيط کپي‌برداري بين خوشه‌ها بود که داده حاصل از آن بيشتر از ظرفيت استکی بود که براي برنامه Elastic Block Storage در نظر گرفته شده‌بود. البته در مورد مذکور، کپي داده ظرفيت اضافي موجود را به طور کامل پرکرد و مشکل در واقع ناشي از ايرادات داينامو نبود. ثبات کلي سيستم‌فايلي داينامو، آن‌را به ايده‌اي الهام‌بخش براي ابزارهاي مشابه منبع باز تبديل کرده‌است؛ همان‌طور که GFS پيش‌از اين چنين نقشي ايفا کرده ‌بود. براي مثال، در حال حاضر فيس‌بوک از Cassandra استفاده مي‌کند که يک پروژه از بنياد آپاچي است که بر اساس سيستم‌فايلي داينامو طراحي شد. همچنين یک پايگاه‌داده NoSQL با نام Basho’s Riak نيز بر اساس معماري داينامو طراحي و ارائه شده‌است.