ابزار و کتابخانه ها

یوتیوب، وایتِس و حل مشکل مقیاس‌پذیری MySQL

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

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

قبلاً در همین وبلاگ، TiDB را یک جانشین مقیاس‌پذیر MySQL‌ معرفی کردیم (چند گزینه دیگر هم در آن فرسته، معرفی شد) اما در هر صورت، اگر بتوانیم با خود MySQL مشکل Sharding (توزیع داده‌ها در یک شبکه) را حل کنیم، راه حل مناسب‌تری برای این موضوع خواهد بود.

یوتیوب حدود نه سال پیش به این مشکل برخورد. هم نیاز به راه حلی داشت که بتواند کوئری های ارسال شده را به یک شبکه از سرویس های MySQL ارسال کند و هم اینکه به خاطر کوئری‌های مختلفی که افراد تیم مهندسی یوتیوب بر روی سرورهای MySQL اجرا می‌کردند، سرویس دهی این بانک اطلاعاتی، دچار اشکال نشود.

Sugu Sougoumarane و همکارانش تصمیم گرفتند یک معماری جانبی به عنوان یک میان افزار برای MySQL‌ طراحی کنند که هم بتواند نقش یک پروکسی و توزیع کننده کوئری‌ها را برعهده بگیرد و هم از اجرای کوئری های نامناسب که زمان زیادی از سرورها را به خود اختصاص می‌دهد جلوگیری کرده، آنها را بهینه و بازنویسی کنند. خروجی این تلاش، پروژه متن‌باز Vitess شد که امروزه بسیاری از سایتهای مطرح دنیا با تعداد درخواست‌های روزانه میلیونی، از این معماری برای مقیاس‌پذیر کردن کلاسترهای MySQL خود استفاده کرده‌اندو مطمئنا راه حلی که برای یوتیوب، اسلک و Hubspot مناسب بوده است، می‌تواند هر نیاز دیگری را هم پاسخگو باشد.

معماری وایتِس

در معماری وایتِس با دو مولفه اصلی بیشتر سرو کار نداریم یکی VTGATE که واسط بین برنامه‌ها و کلاستر MySQL است و توزیع کوئری‌ها در شبکه و مدیریت کانکشن‌ها را برعهده دارد و دومی هم VTTABLET که در کنار هر سرویس MySQL‌ قرار می‌گیرد و به عنوان یک پروکسی، هم محافظ این سرویس، مدیریت خودکار و افزایش کارآیی آن از طریق بازنویسی کوئری‌ها است. درخواست‌های مدیریتی هم از طریق VTCTL به کلاستر ارسال می شود.

منبع : سایت رسمی vitess

مزایای وایتِس

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

منبع : صفحه اصلی سایت Vitess.io

بنابراین توضیحات، اگر با MySQL‌ به اشکال برخورده‌اید و یا نگران از آینده استفاده ازاین دیتابیس در حجم بالای داده‌ها هستید، این میان افزار قدرتمند را که حدود ده روز پیش، نسخه ۳ آن وارد بازار شده است را نصب کرده و با قدرت به کار با MySQL خود ادامه دهید و دنبال راه‌حل‌های دیگر نباشید.

برچسب ها
مشاهده بیشتر

مجتبی بنائی

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

۵ دیدگاه

  1. از نظر شما اقبال به بانک های رابطه ای در حال حاضر در مقایسه با سالیان گذشته که  Nosql ها رواج یافتند، در حال افزایشه ؟

    1. به نظر بنده معماری هایی نوین اطلاعاتی حول بانک های اطلاعاتی رابطه ای شکل می‌گیرند و در کنار آنها، در صورت نیاز از الاستیک سرچ، کاساندرا، ردیس و سایر دیتابیس های غیررابطه‌ای استفاده می‌شود.

      1. به نظر شما چه نقطه ضعفی در مورد nosql ها وجود داشته که باعث شده شرکتهای بزرگ به فکر این باشند برای هندل کردن مقیاس پیذیری بجای استفاده از اونها، روی دیتابیس های رابطه ای wrapper بنویسند؟ در  حالیکه مقیاس پیذیری به صورت پیشفرض در اکثر دیتابیس های nosql وجود داره.

        1. همانطور که خودتون اشاره کردید، یک دلیل اصلی نیاز به دیتابیس های NoSQL بحث عدم مقیاس پذیری مناسب دیتابیس های کلاسیک بود که در سالهای اخیر، با جنبش NewSQL ای که راه افتاد، یا معماری این دیتابیس های قدیمی به گونه ای تغییر کرد که مشکل مقیاس پذیری حل شود و یا به کمک کتابخان های واسطی مانند وایتس، این نقیصه به حداقل برسد. بنابراین یکی از دلایل اصلی رفتن به سمت NoSQL ها تا حدود زیادی کمرنگ شده است. البته همیشه بحث مقیاس پذیری نیست. مثلا در دیتابیسی مانند کاساندرا، هدف اصلی شما سرعت پاسخگویی بالا در بین حجم عظیمی از داده هاست که مجبور میشوید برای رسیدن به این سرعت، برخی اصول پذیرفته شده بانک های اطلاعاتی رابطه ای مانند عدم تکرار داده را زیرپا بگذارید.

پاسخی بگذارید

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

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

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