turbopuffer دیگه فقط دیتابیس برداری نیست
خلاصهٔ کامل‌تر
Dan Harrison از تیم turbopuffer تو این پست توضیح داده که turbopuffer v3 نحوهٔ چیدمان، نوشتن، فشرده‌سازی و کوئری گرفتن از سندها و ایندکس‌ها رو عوض می‌کنه. turbopuffer اول به‌عنوان یه دیتابیس برداری serverless شروع شد: object storage منبع اصلی داده بود تا هزینه پایین بمونه و کش‌های NVMe و حافظه سرعت رو تأمین می‌کردن. مشتری‌هایی مثل Cursor و Notion هم از همون اول ازش استفاده کردن.
تو نسخهٔ اول، هر سند فقط یه ID و یه بردار بود. ایندکس ANN (یعنی ایندکسی که نزدیک‌ترین بردارها رو تقریبی پیدا می‌کنه) بر پایهٔ SPANN و بعداً SPFresh ساخته شد: بردارها خوشه‌بندی می‌شن، مرکز خوشه‌ها دوباره خوشه‌بندی می‌شن و یه درخت تشکیل میشه. همه‌چی با ClusterId و LocalId کلید می‌خوره که بهش ANN address می‌گن:
// leaf vectors
K::Vector(C0L0) = vec![0.45, 0.32, ...]
K::Id(C0L0) = 7
K::Vector(C0L1) = vec![-0.28, 0.96, ...]
K::Id(C0L1) = 13تو نسخهٔ ۲، فیلتر روی attributeها، جستجوی متنی BM25، regex، تجمیع و جستجوی sparse اضافه شد، ولی همه هنوز دور همون ANN address می‌چرخیدن. همین طراحی بود که اجازه داد یه ایندکس با بیشتر از ۱۰۰ میلیارد بردار با p99 حدود ۲۰۰ میلی‌ثانیه و بیش از هزار کوئری در ثانیه کار کنه.
نویسنده می‌گه این چیدمان سه تا مشکل داره. اول storage amplification: وقتی یه سند چند تا بردار داره، کل محتواش برای هر بردار تکرار میشه. دوم write amplification: SPFresh برای حفظ کیفیت خوشه‌ها بردارها رو جابه‌جا می‌کنه و چون همه‌چی با ANN address کلید خورده، کل محتوای سند و ایندکس‌های متنی و attribute هم باهاش جابه‌جا می‌شن. آپدیت یه بردار می‌تونه صدها attribute رو جابه‌جا کنه.
مشکل سوم vectorization محدوده، یعنی اجرای حلقه‌های فشرده روی بلوک‌های بزرگ داده که CPU رو پر نگه می‌داره و SIMD رو ممکن می‌کنه. DuckDB با بلوک‌های ۲۰۴۸ ردیفی کار می‌کنه و ClickHouse تا حدود ۶۵ هزار، ولی بلوک‌های turbopuffer به اندازهٔ خوشه‌ها یعنی ۱۰۰ تا ۲۰۰ سند محدودن. وقتی FTS v2 posting listها رو از خوشه‌ها جدا کرد و بلوک‌های حدود ۲۵۶ تایی ساخت، ایندکس ۱۰ برابر کوچیک‌تر و کوئری‌ها تا ۲۰ برابر سریع‌تر شدن.
راه‌حل v3 ساده‌ست: دیگه روی ANN address کلید نزن و ANN رو یه ایندکس فرعی مثل بقیه کن. این ماه ۱۰۰ درصد تست‌های CI روی v3 پاس شده. تیم اول روی درستی تمرکز کرده و حالا می‌خواد سرعت رو برسونه. قراره بنچمارک‌ها رو تو هفته‌های آینده عمومی منتشر کنن و وقتی به برابری عملکرد رسیدن، v3 رو روی production ببرن.
نکات کلیدی:
- turbopuffer v3 ایندکس ANN رو از کلید اصلی به یه ایندکس فرعی تبدیل می‌کنه.
- معماری فعلی ایندکس‌های ۱۰۰ میلیارد برداری رو با p99 حدود ۲۰۰ میلی‌ثانیه سرویس می‌ده.
- بلوک‌های داده الان به اندازهٔ خوشه‌ها، یعنی ۱۰۰ تا ۲۰۰ سند، محدودن.
- FTS v2 با بلوک‌های ۲۵۶ تایی ایندکس رو ۱۰ برابر کوچیک‌تر و کوئری رو تا ۲۰ برابر سریع‌تر کرد.
- ۱۰۰ درصد CI روی v3 پاس شده و بنچمارک‌ها به‌زودی عمومی منتشر می‌شن.
