پارسر SQL جدید پستهاگ؛ ۷۰ برابر سریعتر با کمک کلود
هوش مصنوعیخلاصهٔ کاملتر
پستهاگ به کاربرا اجازه میده مستقیم با SQL به دادههاشون دسترسی داشته باشن، ولی این کوئریها رو پشتصحنه به SQL خام ClickHouse ترجمه میکنه تا بتونه یه نمای منطقی مستقل از ساختار فیزیکی دیتابیس بده و کنترل دسترسی و بهینهسازی بهش اضافه کنه. اولین چیزی که هر کوئری بهش میخوره همین پارسره، پس روی ورودی نامطمئن کار میکنه و بقیهٔ زنجیره به درختی که میسازه تکیه دارن.
نویسنده میگه تا قبل از عصر کدنویسی با هوش مصنوعی، نوشتن پارسر دستی خیلی سخت بود، برای همین از ANTLR استفاده میکردن که از روی فایل گرامر، بیشتر کد پارسر رو خودش تولید میکنه. مشکل اینه که ANTLR گرامر رو به یه گراف تبدیل میکنه و موقع اجرا یه مفسر عمومی اون گراف رو پیمایش میکنه، پس برای هر توکن کار خیلی بیشتری انجام میده. به گفتهٔ نویسنده یه مفسر گرافپیما هیچوقت نمیتونه به سرعت یه پارسر بازگشتی دستنویس برسه.
نویسنده میگه گفتن به کلود که «یه پارسر بنویس و اشتباه نکن» جواب نداد؛ مدل کلی خطا میکرد و هی شک میکرد که اصلاً این بازنویسی شدنیه یا نه. برای همین دو مسیر موازی رو تست کرد: یکی که روی سرعت تمرکز داشت (پارسر بازگشتی با حلقهٔ عبارت Pratt) و یکی که تا جای ممکن رفتار ANTLR رو دنبال میکرد ولی گذارها رو بهجای پیمایش گراف، صریح کد میزد. آخرش هر دو تقریباً به یه اندازه خوب کار کردن.
کلید ماجرا داشتن یه «مرجع» بود: همون پارسر C++ قدیمی. نویسنده میتونست هر SQLای که دو پارسر سرش اختلاف داشتن رو پیدا کنه، پارسر جدید رو درست کنه تا با مرجع بخونه، و همین حلقه رو تکرار کنه. برای ساختن ورودیهای تستی از یه کتابخونهٔ تست مبتنی بر ویژگی (Hypothesis) استفاده کرد که سعی میکنه ورودیهایی بسازه که خاصیت موردنظر (یعنی توافق با مرجع) توش نقض بشه، و حتی یه ابزار نوشت که از روی همون فایل گرامر، تولیدکنندهٔ SQL بسازه.
نویسنده میگه چون پارسر جدید اینقدر سریع بود، تونست تو حالت «سایه» کنار پارسر C++ فعلی تو پروداکشن اجراش کنه و هر اختلافی رو گزارش بده؛ رو میلیونها کوئری صفر اختلاف دید و بعد چند ساعت ترافیک رو کامل جابهجا کرد. رو کوئریهای واقعی پروداکشن بهطور میانگین ۴۵۴ برابر سریعتر بود (عدد ۷۰ برابر تو عنوان از یه بنچمارک روی لپتاپ میاد). کل کد رو Claude Opus 4.7 به زبان Rust نوشت.
نویسنده تأکید میکنه با اینکه یه خط کد رو هم دستی ننوشته، این کارو «وایبکدینگ» نمیدونه؛ چون ستآپ تست مبتنی بر ویژگی با ورودیهای تولیدشده از گرامر و هدایتشده با پوشش کد، تقریباً همسطح بهترین روشهای فازینگ پارسره. به نظرش این مدل کار کمکم به روال عادی تبدیل میشه: یه تولیدکنندهٔ پارسر نقش مرجع رو بازی میکنه و بعد یه مدل زبانی یه پارسر پرسرعتتر دستساز مینویسه که باهاش بخونه.
نکات کلیدی:
- پارسر اولین جاییه که یه کوئری بهش میخوره و روی ورودی نامطمئن کار میکنه
- داشتن یه پارسر مرجع (oracle) اجازه داد توسعه بهسبک TDD پیش بره
- تست مبتنی بر ویژگی و کشیدن کوئری از لاگ پروداکشن، تستکیسهای اختلاف تولید کردن
- اجرای «سایه» تو پروداکشن نشون داد رو میلیونها کوئری صفر اختلاف هست
- نتیجه تا ۴۵۴ برابر سریعتر تو پروداکشن، همه نوشتهشده با Claude Opus 4.7 به زبان Rust
