‏turbopuffer v3: اولین موتور جستجو با اجرای کاملاً vectorized

آدرین گراند از تیم turbopuffer تو این پست می‌گه وقتی turbopuffer v3 اواخر امسال به production برسه، همه‌ی کوئری‌ها از یه pipeline کاملاً vectorized رد می‌شن. vectorized execution اینجا ربطی به جستجوی برداری نداره؛ یعنی موتور کوئری به‌جای یه ردیف، هر بار یه دسته ردیف رو پردازش می‌کنه. به گفته‌ی تیم، تا جایی که خبر دارن turbopuffer اولین موتور جستجوییه که این معماری رو کامل پیاده می‌کنه؛ معماری‌ای که بیشتر تو دیتابیس‌های تحلیلی دیده می‌شه.

برای فهمیدنش باید از مدل Volcano شروع کرد. تو این مدل قدیمی، اجرای کوئری یه زنجیره از operatorهای عمومیه. برای کوئری زیر سه operator داریم: SequentialScan که ردیف‌های جدول product رو می‌خونه، Filter که ردیف‌های با قیمت بالای ۳۲ رو حذف می‌کنه و Aggregate که جمع قیمت‌ها رو حساب می‌کنه.

SELECT sum(price)
FROM product
WHERE price <= 32

تو Volcano هر operator ردیف‌ها رو یکی‌یکی از operator قبلی می‌کشه. پس برای هر ردیف و تو هر operator، هزینه‌ی صدا زدن تابع، dynamic dispatch (یعنی پیدا کردن تابع درست موقع اجرا) و تفسیر پرداخت می‌شه. نتیجه اینکه CPU بیشتر وقتش رو صرف فهمیدن کار بعدی می‌کنه تا انجام خود کار.

دو راه‌حل برای این مشکل پیدا شده: موتورهای compiled مثل Hyper که برای هر کوئری کد مخصوص می‌سازن، و موتورهای vectorized مثل DuckDB. موتورهای vectorized همون operatorهای عمومی Volcano رو نگه می‌دارن، ولی دسته‌هایی از ردیف‌ها رو پردازش می‌کنن که تو cache جا می‌شن. این‌طوری هزینه‌ی dispatch بین کل دسته پخش می‌شه و CPU بهتر استفاده می‌شه.

چرا موتورهای جستجو تا حالا سراغش نرفتن؟ نویسنده می‌گه کارشون محدود بوده: پیدا کردن top-k نتیجه‌ی شبیه به کوئری، چه متنی چه برداری. این رو می‌شه با یه حلقه‌ی تخصصی نوشت، پس هزینه‌ی dispatch اصلاً پیش نمیاد. الگوریتم‌هایی مثل block-max WAND برای متن و HNSW برای بردار هم اول شباهت یه سند رو حساب می‌کنن و بعد تصمیم می‌گیرن سراغ کدوم سند برن. این داده‌ی کمتری می‌خونه، ولی CPU تا جواب نیاد نمی‌تونه قدم بعدی رو پیش‌بینی کنه.

به گفته‌ی تیم، دو چیز باعث این تغییر شده: کوئری‌های مشتری‌ها پیچیده‌تر شدن و سخت‌افزار امروزی به دسترسی دسته‌ای و قابل‌پیش‌بینی به داده پاداش می‌ده. turbopuffer v1 فقط یه operator شباهت برداری داشت و نیازی به dynamic dispatch نبود، ولی جستجو حالا از اون بازیابی محدود فراتر رفته. یعنی با operatorهای عمومی و دسته‌ای، v3 می‌تونه روی انواع مختلف کوئری عملکرد خوبی داشته باشه.

نکات کلیدی:

• turbopuffer v3 اواخر امسال به production می‌رسه و همه‌ی کوئری‌هاش vectorized اجرا می‌شن
• مدل Volcano ردیف‌ها رو یکی‌یکی بین operatorها رد می‌کنه و برای هر ردیف هزینه‌ی dispatch داره
• Hyper نمونه‌ی موتور compiled و DuckDB نمونه‌ی موتور vectorized هست
• block-max WAND و HNSW به‌خاطر وابستگی داده‌ای سخت vectorized می‌شن
• دلیل تغییر: کوئری‌های پیچیده‌تر مشتری‌ها و استفاده‌ی بهتر از CPUهای امروزی