بنچمارکهای دیتابیس؛ چرا نباید کامل باورشون کنی
تستخلاصهٔ کاملتر
نویسنده با یه تشبیه شروع میکنه: یه بنچمارک خوب باید مثل مسابقهٔ دوی المپیک باشه، ولی در عمل بیشتر شبیه اون مسابقههای عجیب اینترنتیه که باید همزمان با دویدن، یه آهنگ رو دقیق سوت بزنی؛ پس لزوماً سریعترین دونده برنده نمیشه. به گفتهٔ اون یه بنچمارک دیتابیس کاملاً منصفانه مثل اسب تکشاخهست: پیدا کردنش شانس میخواد. برای نشوندادن این، سراغ بنچمارک عمومی و شناختهشدهٔ ClickBench میره، ولی تأکید میکنه هدفش زیر سؤال بردن همهٔ بنچمارکهاست، نه فقط ClickBench.
ClickBench یه بار کاری یکسان (یه جدول حدوداً ۱۰۰ میلیون ردیفی و ۴۳ کوئری تحلیلی) رو روی هر سیستم اجرا میکنه. هر کوئری دو حالت داره: اجرای «سرد» (اولین اجرا با کشهای خالی) و اجرای «گرم» (سه بار اجرا و برداشتن کمترین زمانِ اجرای دوم و سوم). نویسنده اشاره میکنه که اجرای سرد یه نامتقارنی پنهان داره: پاککردن کش سیستمعامل و ریاستارت سرور فقط روی دیتابیسی که خودت میزبانیش میکنی ممکنه، پس سرویسهای ابری هیچوقت واقعاً سرد سنجیده نمیشن.
یه نکتهٔ ظریف که کل مقاله روش سواره اینه که هر اسکریپت، زمان داخلی خودِ موتور رو ثبت میکنه، نه زمان راهاندازی پروسه یا کلاینت. پس زندهنگهداشتن پروسه نمیتونه با حذف زمان راهاندازی امتیاز رو عوض کنه، چون اون زمان اصلاً تو عدد نبوده؛ فقط از طریق گرمموندن کش پروسه اثر میذاره. امتیاز نهایی هم میانگین هندسی نسبت هر کوئری به سریعترین سیستمه، و کمتر بهتره.
تو سناریوی اول، پنج موتور که مستقیم فایل Parquet رو میخونن مقایسه شدن و تو حالت پیشفرض DuckDB و Polars جلو بودن و Hyper آخر. ولی نویسنده یه سؤال میپرسه: آیا منصفانهست که برای هر کوئری کل پروسهٔ CLI ریاستارت بشه؟ وقتی پروسهها رو بین اجراها زنده نگه داشتن، Hyper از آخر به رتبهٔ سوم پرید (۲٫۱۷ برابر سریعتر)، چون هزینهٔ کامپایل کوئری و گرمکردن بافر که فکر میکردن بیرون از زمانسنجیه، در واقع داخلش بود.
جالبترین درس از Polars میاد: خروجیش تو هر دو اجرا بایتبهبایت یکیه، چون ClickBench از اول اون رو بهصورت نشست ماندگار اجرا میکنه، پس این تغییر روش هیچ اثری روش نداره. با این حال امتیازش بدتر شد و از رتبهٔ اول به دوم افتاد. دلیلش اینه که امتیاز نسبت به سریعترین سیستمه و چون بقیه سریعتر شدن، خط مبنا زیر پاش جابهجا شد. یعنی یه دیتابیس میتونه دقیقاً همون کارو تو همون زمان بکنه ولی امتیازش بدتر بشه.
سناریوی دوم روی ذخیرهسازی بومیه و به مسئلهٔ گرمشدن موتورهای JVM میپردازه. کامپایلر JIT همینطور که کد اجرا میشه بهینهترش میکنه، پس سه بار تکرار میتونه یه موتور JVM رو وسط گرمشدن گیر بندازه. با بردن تعداد تکرار به ۱۰، موتورهای JVM مثل QuestDB و CrateDB سریعتر شدن، ولی ClickHouseِ ازپیشکامپایلشده تقریباً ثابت موند. بعد با زندهنگهداشتن DuckDB، این موتور ۱٫۶۹ برابر سریعتر شد و از رتبهٔ سوم به اول پرید.
نویسنده میگه تو هیچکدوم از این سناریوها تقلب نکردن: نه کوئریای عوض شد، نه روش زمانسنجی، نه داده. فقط زندهموندن پروسه و تعداد اجرا تغییر کرد و هر دو هم قابلدفاعان. پیامش اینه که دفعهٔ بعد که یه مقالهٔ «ما همه رو تو بنچمارک X شکست دادیم» دیدی، عجله نکن؛ ببین اون سناریو چهقدر شبیه نحوهٔ کار واقعی اپلیکیشن خودته. بهترین نتیجه همیشه اونیه که رو ماشین و بار کاری خودت میسنجی، و صادقانه اضافه میکنه که این حرف دربارهٔ بنچمارکهای خودِ QuestDB هم صدق میکنه.
نکات کلیدی:
- امتیاز ClickBench میانگین هندسی نسبت هر کوئری به سریعترین سیستمه، پس نسبیه
- زندهنگهداشتن پروسه، کش گرم رو حفظ میکنه و میتونه رتبهها رو جابهجا کنه
- موتورهای JVM با تکرار بیشتر گرم میشن؛ ۳ تکرار برای رسیدن به حالت پایدارشون کمه
- یه دیتابیس میتونه همون کارو تو همون زمان بکنه ولی چون خط مبنا حرکت کرده امتیازش بدتر بشه
- بهترین بنچمارک اونیه که رو ماشین و بار کاری خودت اجرا میکنی
