NoSQLمقایسه و انتخاب

چرا گاردین از مانگودی‌بی به پستگرس مهاجرت کرد ؟

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

در چند هفته اخیر، در خبرنامه های مختلف حوزه‌ داده به مقاله جدیدی که سایت روزنامه معروف گاردین با عنوان «بای بای مانگو، سلام پستگرس» منتشر کرده بود، برخوردم که تصمیم گرفتم برای تکمیل مباحث، خلاصه این مقاله را هم برای علاقه‌مندان بازگو کنم.

روزنامه گاردین با حدود ۲٫۳ میلیون سند، درخواستهای روزانه زیادی را برای ویرایش و ثبت اخبار و نظرات و مشابه آن از سرتاسر دنیا مدیریت می‌کند. نرم افزار مدیریت محتوای گاردین با نام کامپوزر به خوبی با مانگو دی بی که در دیتاسنترهای داخلی روزنامه قرار داشت، کار می‌کرد. تا اینکه در سال ۲۰۱۵ و با رخداد گرمای بی‌سابقه لندن که مجبور به خاموش کردن برخی سرورهای خود شدند، تصمیم گرفتند معماری داده خود را بر مبنای رایانش ابری و استفاده از فضای ابری آمازون، تعریف کنند تا در صورت رخداد مسایلی مانند این، به سرویسهای ارائه شده توسط این روزنامه خللی وارد نشود.

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

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

عدم وجود رمزگذاری دستورات REST در مانگو‌دی‌بی (البته از نسخه ۳٫۲ مانگو در نسخه سازمانی آن این امکان اضافه شده است) هم از دیگر دلایل ایجاد نارضایتی گاردین از این دیتابیس بود.

با لحاظ تمام این موارد، در جولای سال ۲۰۱۷ تیم فنی گاردین، با بررسی‌های مختلف، به سرویس Postgres on AWS RDS رسیدند که توسط آمازون ارائه می‌شد و عملیات انتقال به پستگرس در گاردین، شروع شد.

این عملیات بسیار زمان‌بر بود و گام‌های گوناگونی برای تبدیل تمامی اسناد و مقالات به فرمت JSONB پستگرس، باید انجام می‌شد(که در مقاله فوق به طور کامل پوشش داده شده است). نهایتا بعد از ده‌ماه کوشش مداوم و استفاده از پشته مانیتورینگ الاستیک سرچ (ELK) در اواسط سال ۲۰۱۸ این مهاجرت به پایان رسید و امروزه، زیر ساخت اطلاعاتی گاردین، بر پستگرس بنانهاده شده است.

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

مجتبی بنائی

دانشجوی دکترای نرم‌افزار دانشگاه تهران (yun.ir/smbanaie)، مدرس دانشگاه و فعال در حوزه توسعه نرم‌افزار و مهندسی داده که تمرکز کاری خود را در چند سال اخیر بر روی مطالعه و تحقیق در حوزه کلان‌داده و زیرساخت‌های پردازش داده و تولید محتوای تخصصی و کاربردی به زبان فارسی و انتشار آنها در سایت مهندسی داده گذاشته است. مدیریت پروژه‌های نرم‌افزاری و طراحی سامانه‌های مقیاس‌پذیر اطلاعاتی از دیگر فعالیتهای صورت گرفته ایشان در چند سال گذشته است.

۲ دیدگاه

  1. خیلی جالب هست که یک مسائل طبیعی مثل گرمای لندن تاثیر مستقیم درمهاجرت به رایانش ابری داشته و چالش های در ادامه …

  2. درود ممنون از نوشته ها تون علاقه مند شدم و می‌خوانم ، پر انرژی ادامه دهید

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

جای خالی در معادله زیر را با کی برد انگلیسی وارد کنید : * Time limit is exhausted. Please reload CAPTCHA.

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

دکمه بازگشت به بالا