PostgreSQL یا MySQL؛ workload می‌تواند برندهٔ benchmark را عوض کند

برای انتخاب میان PostgreSQL و MySQL برندهٔ ثابتی در کارایی وجود ندارد. بار کاری، از خواندن یک ردیف تا نوشتن هم‌زمان و اجرای گزارش تحلیلی، تعیین می‌کند کدام نتیجه برای برنامهٔ شما اهمیت دارد. راهنمای سنجش MySQL هشدار می‌دهد که اختلاف چنددرصدی ممکن است در محیطی دیگر وارونه شود؛ بنابراین عددی که بدون شرح بار کاری منتشر شده، مبنای محکمی برای انتخاب نیست.

پاسخ عملی این است: عملیات پرتکرار و عملیات حساس به تأخیر را در هر دو موتور، با داده و شرایط استقرار همسان، اندازه بگیرید. اگر برنامه بیشتر ردیف‌ها را با کلید اصلی می‌خواند، نتیجهٔ همان مسیر مهم است؛ اگر گلوگاه آن join، جست‌وجوی JSON یا نوشتن است، رتبهٔ حاصل از آزمون خواندن ساده کمکی نمی‌کند. نرخ انجام کار، تأخیر درخواست‌های کند و هزینهٔ نگهداری باید کنار هم دیده شوند.

ماتریس تصمیم برای بارهای کاری متفاوت

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

• خواندن ساده: بازیابی ردیف با کلید اصلی را با اندازهٔ پاسخ، نسبت داده‌های حاضر در حافظه و تعداد درخواست‌های هم‌زمان بسنجید. نرخ بالای پرس‌وجو زمانی ارزش دارد که تأخیر انتهایی نیز پذیرفتنی باشد.
• نوشتن سنگین: درج تک‌ردیفی، درج دسته‌ای و به‌روزرسانی ردیف‌های مشترک را از هم جدا کنید. نرخ تراکنش، انتظار برای قفل، رشد فضای ذخیره‌سازی و اثر نوشتن بر خواندن‌های هم‌زمان را ثبت کنید.
• Join پیچیده: پرس‌وجوهای چندجدولی را با توزیع واقعی داده، شرط‌های معمول و حجم خروجی مورد انتظار اجرا کنید. زمان پاسخ را در کنار طرح اجرای انتخاب‌شده بخوانید.
• JSON: جست‌وجو در مسیرهای ثابت را از جست‌وجو در مسیرهای متغیر سند جدا کنید. شاخص مناسب، اندازهٔ آن و هزینهٔ به‌روزرسانی سند بخشی از نتیجه‌اند.
• تحلیل: زمان تکمیل اسکن، تجمیع و مرتب‌سازی را بسنجید و اثر گزارش بر تراکنش‌های هم‌زمان را نیز ثبت کنید. سریع‌تر شدن گزارش اگر درخواست‌های اصلی را کند کند، لزوماً به سود برنامه نیست.

چرا یک آزمون خواندن ساده هم حکم کلی نمی‌دهد؟

حتی نتیجهٔ بازیابی یک ردیف را نمی‌توان از شهرت یک موتور حدس زد. در آزمون منتشرشدهٔ Readyset، PostgreSQL 16 و Percona MySQL 8.4 برای خواندن با کلید اصلی روی یک سرور آزمایش شدند و در اوجِ ۱٬۱۲۰ اتصال، به‌ترتیب ۲٬۱۸۱٬۹۸۱ و ۱٬۵۷۳٬۵۶۵ پرس‌وجو در ثانیه ثبت کردند. این ارقام مربوط به آزمون همان شرکت، نسخه‌ها و مسیر مشخصِ پرس‌وجوی آماده‌شده‌اند؛ به خواندن‌های دیگر یا استقرارهای متفاوت تعمیم پیدا نمی‌کنند.

در آزمون نوشتن نیز تعریف تراکنش نتیجه را تغییر می‌دهد. درج پیوسته، به‌روزرسانی چند ردیف در یک تراکنش و رقابت نویسنده‌ها بر سر یک ردیف، فشار یکسانی بر پایگاه‌داده وارد نمی‌کنند. اگر برنامه هنگام نوشتن همچنان باید پاسخ‌گوی خواندن باشد، آزمونِ صرفاً نوشتنی گلوگاه مهمی را پنهان می‌کند. نسبت عملیات، اندازهٔ تراکنش و تعداد نویسنده‌ها باید همان وضعیتی را بازسازی کنند که قرار است درباره‌اش تصمیم گرفته شود.

Join و تحلیل را در کنار ترافیک اصلی بسنجید

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

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

در JSON، نوع شاخص می‌تواند نتیجه را تغییر دهد

مقایسهٔ دو ستون JSON بدون درنظرگرفتن شاخص، مقایسهٔ دو طرح ناقص است. مستندات JSONB در PostgreSQL توضیح می‌دهد که شاخص GIN می‌تواند جست‌وجوی کلیدها و ترکیب‌های کلید و مقدار را در اسناد پشتیبانی کند؛ عملگر پرس‌وجو و نوع شاخص تعیین می‌کنند این امکان در عمل به کار بیاید یا نه. شاخصی که کل سند را پوشش می‌دهد انعطاف بیشتری دارد، اما ممکن است از شاخصی که فقط مسیر موردنیاز را پوشش می‌دهد بزرگ‌تر باشد.

در MySQL نیز راه شاخص‌گذاری به شکل پرس‌وجو بستگی دارد. مستندات JSON در MySQL می‌گوید ستون JSON مستقیماً شاخص‌گذاری نمی‌شود، اما می‌توان مقدار استخراج‌شده از یک مسیر را در ستون تولیدشده شاخص‌گذاری کرد؛ InnoDB برای آرایه‌های JSON شاخص چندمقداری هم دارد. بنابراین برای مسیری ثابت و پرتکرار، هر موتور باید با شاخص مناسب خودش سنجیده شود. اگر مسیرهای جست‌وجو مرتب تغییر می‌کنند، انعطاف شاخص و هزینهٔ نگهداری آن نیز در تصمیم اثر دارد؛ جزئیات شاخص‌گذاری JSON به همین انتخاب مربوط است.

طرح benchmark همسان چگونه ساخته می‌شود؟

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

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

مستندات pgbench اجرای نشست‌های هم‌زمان، سناریوی تراکنش سفارشی و اندازه‌گیری نرخ تراکنش را شرح می‌دهد و دربارهٔ نتیجه‌گیری از آزمون چندثانیه‌ای هشدار می‌دهد. pgbench برای PostgreSQL ساخته شده است؛ برای مقایسهٔ مستقیم با MySQL، بار منطقی یکسان را با تولیدکنندهٔ بار مشترک یا سناریوهای معادل اجرا کنید. تعریف «یک تراکنش» و شمار پرس‌وجوهای آن باید در دو طرف برابر باشد، وگرنه مقایسهٔ نرخ تراکنش معنای روشنی ندارد.

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

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

اگر هر دو موتور با بار واقعی به حد موردنیازِ توان عملیاتی و تأخیر می‌رسند، اختلاف کوچک را در کنار مهارت تیم، نیازهای داده‌ای و هزینهٔ مهاجرت بسنجید. اگر یکی هنگام عملیات پرتکرار یا زیر فشار هم‌زمانی از حد تأخیر قابل‌قبول عبور می‌کند، همان رفتار دلیل فنی مشخص‌تری برای انتخاب دیگری است. تصمیم به نتیجهٔ همان ترکیبِ داده، پرس‌وجو و پیکربندی وابسته می‌ماند؛ با تغییر چشمگیر هرکدام، اندازه‌گیری نیز باید دوباره انجام شود.

بیشتر بخوانید:

• PostgreSQL یا MySQL برای JSON؛ نوع ایندکس نتیجه را دو برابر می‌کند
• SQLite یا PostgreSQL؛ یک نویسنده سریع است، ۱۶ نویسنده برنده را عوض می‌کنند
• Shopify یا WooCommerce؛ فروش بیشتر می‌تواند برندهٔ ارزان‌تر را عوض کند