MariaDB یا MySQL؛ انتخاب درست برای پروژه شما

سرور را بالا آورده‌اید، اسکریپت نصب را اجرا کرده‌اید و حالا روی صفحه مانده‌اید: mariadb-server را نصب کنید یا mysql-server؟ اگر از هاست اشتراکی آمده باشید، احتمالاً تا دیروز فقط یک دکمه «ساخت دیتابیس» دیده‌اید و حالا باید خودتان تصمیم بگیرید. تصمیم اشتباه هم فوری خودش را نشان نمی‌دهد؛ سه ماه بعد، وقتی می‌خواهید ارتقا بدهید یا یک افزونه را فعال کنید، معلوم می‌شود.

خبر خوب این است که در ۹۰٪ موارد پاسخ ساده است. خبر بد این است که آن ۱۰٪ باقی‌مانده دقیقاً همان جایی است که پروژه‌های واقعی زمین می‌خورند.

MariaDB یا MySQL؛ ماجرای جدایی از کجا شروع شد

تا سال ۲۰۰۹ این دو یکی بودند. بعد از خریداری MySQL توسط Oracle، تیم اصلی پروژه فورک را برداشت و MariaDB را ساخت. تا سال‌ها این دو تقریباً یک کد بودند و همین باعث شد خیلی‌ها فکر کنند تفاوتشان اسمی است. از MySQL 8.0 به بعد این فرض غلط شد.

امروز دو خط توسعه جدا داریم. MySQL 8.0 و 8.4 مسیر خودش را رفت؛ MariaDB از 10.2 به بعد مسیر دیگری. هر دو SQL استاندارد را می‌فهمند، هر دو InnoDB دارند (در MariaDB نسخه‌ای به نام XtraDB که فورک قدیمی‌تر InnoDB است)، ولی در جزئیات موتور ذخیره‌سازی، توابع، و رفتار بهینه‌ساز از هم دور شده‌اند.

تفاوت‌هایی که در عمل به آن‌ها می‌خورید

• JSON: در MySQL نوع داده واقعی JSON با ایندکس‌گذاری روی مسیر داریم. در MariaDB همان JSON در واقع LONGTEXT با یک CHECK constraint است. اگر روی ستون JSON کوئری سنگین می‌زنید، این تفاوت را حس می‌کنید.
• CTE و پنجره‌ها: هر دو دارند، ولی MySQL از 8.0 و MariaDB از 10.2. اگر روی نسخه قدیمی‌تر هستید، کوئری‌های تحلیلی‌تان کار نمی‌کند.
• موتورهای ذخیره‌سازی: MariaDB موتورهای Aria، ColumnStore و MyRocks را در بسته اصلی دارد. MySQL برای معادل‌ها باید سراغ نسخه‌های تجاری یا پلاگین برود.
• Replication: MariaDB از GTID با فرمت خودش استفاده می‌کند که با GTID در MySQL سازگار نیست. این یعنی نمی‌توانید یک اسلیو MariaDB را به مستر MySQL وصل کنید و انتظار داشته باشید بی‌دردسر کار کند.

کدام را انتخاب کنم؟ یک قاعده عملی

اگر پروژه‌تان روی وردپرس، جوملا، یا هر CMS رایج است، MariaDB را بردارید. دلیلش تعصب نیست؛ دلیلش این است که اکثر پنل‌های هاستینگ و اسکریپت‌های نصب خودکار سال‌هاست روی MariaDB تست می‌شوند و کمترین اصطکاک را دارید. روی سرور مجازی ایران هم نصب MariaDB با یک apt install mariadb-server تمام می‌شود و به هیچ تنظیم اضافه‌ای نیاز ندارد.

اگر روی MySQL 8.0 قفل هستید، معمولاً یک دلیل مشخص دارید: یک اپلیکیشن تجاری که رسماً فقط MySQL را پشتیبانی می‌کند، یا تیمی که سال‌ها روی ابزارهای مانیتورینگ مخصوص MySQL کار کرده. در این حالت با MySQL بمانید. تغییر دادنش فقط برای «آزاد بودن» ارزش ریسک ندارد.

مهاجرت از یکی به دیگری؛ جایی که همه گیر می‌کنند

مهاجرت از MariaDB به MySQL (یا برعکس) در تئوری یک mysqldump است. در عمل، سه چیز جلوی شما را می‌گیرد.

اول: نسخه‌ها را چک کنید، نه فقط اسم را

mysql --version
mariadb --version
SELECT VERSION();

اگر خروجی 10.11.6-MariaDB است، شما روی MariaDB هستید حتی اگر دستور mysql را زده باشید. این گیج‌کننده‌ترین بخش ماجراست: باینری‌ها و کلاینت‌ها در MariaDB هنوز اسم mysql را یدک می‌کشند تا سازگاری حفظ شود. خیلی‌ها فکر می‌کنند MySQL دارند و در واقع MariaDB دارند.

دوم: dump را کورکورانه برنگردانید

mysqldump --single-transaction --routines --triggers --events \
  --default-character-set=utf8mb4 mydb > mydb.sql

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

سوم: charset را جدی بگیرید

اگر دیتابیس‌تان روی utf8 قدیمی (که در واقع سه‌بایتی است) ساخته شده، مهاجرت به utf8mb4 را همین حالا انجام دهید. ایموجی و بعضی کاراکترهای فارسی در utf8 سه‌بایتی درست ذخیره نمی‌شوند و بعد از مهاجرت به شکل ???? ظاهر می‌شوند. این خطا در لاگ نمی‌آید؛ فقط در سایت می‌بینید.

اینجا اشتباه می‌کنند: خیلی‌ها dump را با --default-character-set=latin1 می‌گیرند چون در کانفیگ قدیمی سرور همین بوده، بعد روی سرور جدید که پیش‌فرضش utf8mb4 است برمی‌گردانند و کل متن فارسی به هم می‌ریزد. علائمش این است که سایت بالا می‌آید، جداول سالم به نظر می‌رسند، ولی همه‌چیز شبیه سلام است. راه درست این است که charset مبدأ را از SHOW CREATE DATABASE بخوانید و همان را در dump مشخص کنید.

کارایی؛ عدد واقعی به چه معناست

در بنچمارک‌های OLTP سبک، تفاوت این دو معمولاً زیر ۵٪ است. یعنی اگر سایت شما با ۲۰۰ کوئری در ثانیه کار می‌کند، تغییر دیتابیس سرعتش را دو برابر نمی‌کند. آنچه واقعاً سرعت را عوض می‌کند سه چیز است: ایندکس درست، اندازه innodb_buffer_pool_size، و دیسک.

روی یک سرور با ۸ گیگابایت رم، مقدار پیش‌فرض innodb_buffer_pool_size در MariaDB حدود ۱۲۸ مگابایت است. این عدد برای یک سایت وردپرسی متوسط فاجعه است. آن را روی ۴ تا ۵ گیگابایت بگذارید و تفاوت را در TTFB ببینید. اگر روی دیسک SATA هستید، مهاجرت به NVMe بیشتر از تغییر دیتابیس به شما سرعت می‌دهد.

برای دیدن اینکه گلوگاه واقعاً کجاست، قبل از هر تغییری وضعیت فعلی را اندازه بگیرید. ابزارهای شبکه و تست سرعت می‌توانند نشان دهند مشکل از دیتابیس است یا از لایه وب. اگر TTFB بالا دارید ولی کوئری‌ها سریع‌اند، احتمالاً مشکل جای دیگری است و وقت‌تان را روی دیتابیس هدر می‌دهید.

وقتی پروژه بزرگ می‌شود

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

اگر به نقطه‌ای رسیدید که یک سرور جواب نمی‌دهد، قبل از عوض کردن دیتابیس به معماری سرور فکر کنید. برای بارهای سنگین دیتابیس، جدا کردن دیتابیس روی یک ماشین فیزیکی جداگانه با دیسک NVMe معمولاً مؤثرتر از هر تغییری در نرم‌افزار است. مستندات و پایگاه دانش سرورنت هم تنظیمات پیشنهادی برای بارهای مختلف را دارد که می‌تواند نقطه شروع خوبی باشد.

یک نکته که کمتر گفته می‌شود: MariaDB در نسخه‌های اخیرش بعضی رفتارهای بهینه‌ساز را تغییر داده که روی کوئری‌های پیچیده با JOIN زیاد می‌تواند کندتر از MySQL 8.0 عمل کند. اگر اپلیکیشن‌تان کوئری‌های تحلیلی سنگین دارد، قبل از مهاجرت با داده واقعی تست کنید، نه با دیتاست نمونه.

پرسش‌های پرتکرار

آیا MariaDB جایگزین کامل MySQL است؟

برای اکثر کاربردهای وب، بله. MariaDB طوری ساخته شده که drop-in replacement باشد و اکثر کدهایی که با MySQL کار می‌کنند بدون تغییر روی آن اجرا می‌شوند. اما «اکثر» با «همه» فرق دارد. اگر از ویژگی‌های مخصوص MySQL 8.0 مثل نوع داده JSON واقعی یا توابع خاص آن استفاده می‌کنید، جایگزینی کامل نیست.

چطور بفهمم سرورم MySQL دارد یا MariaDB؟

دستور mysql --version را بزنید. اگر در خروجی کلمه MariaDB دیدید، سرور MariaDB است. همچنین می‌توانید داخل کلاینت SELECT VERSION(); را اجرا کنید. نکته مهم این است که وجود باینری با نام mysql به معنی MySQL بودن سرور نیست؛ MariaDB برای حفظ سازگاری همان نام‌ها را نگه داشته است.

مهاجرت از MySQL به MariaDB چقدر طول می‌کشد؟

برای یک دیتابیس چند گیگابایتی، خود عملیات dump و restore معمولاً بین ۱۰ تا ۴۰ دقیقه طول می‌کشد، بسته به سرعت دیسک و تعداد جداول. اما زمان واقعی پروژه بیشتر صرف تست می‌شود. حداقل یک بار روی یک محیط staging مهاجرت را تمرین کنید و بعد روی production اجرا کنید.

آیا می‌توانم هر دو را روی یک سرور داشته باشم؟

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

تصمیم نهایی ساده است: اگر دلیل مشخصی برای MySQL ندارید، MariaDB را بردارید و وقت‌تان را روی تنظیم innodb_buffer_pool_size و ایندکس‌گذاری بگذارید. آن دو، سرعت سایت را بیشتر از هر بحثی درباره برند دیتابیس تغییر می‌دهند.