تصور کنید هر بار که جای یک کتاب در کتابخانه تغییر می‌کند، مجبور باشید تمام برچسب‌های دسته‌بندی و فهرست‌های راهنمای آن کتاب را هم بازنویسی کنید. این دقیقاً همان بن‌بستی بود که turbopuffer در معماری قدیمی خود با آن دست‌وپنجه نرم می‌کرد.
به نقل از دن هریسون، مهندس این پروژه، در ۳۰ سپتامبر ۲۰۲۶ اعلام شد که در نسخه v3، جست‌وجوی نزدیک‌ترین همسایه تقریبی (Approximate Nearest Neighbor یا ANN) دیگر لنگر اصلی معماری نیست، بلکه تنها به عنوان یک ایندکس ثانویه عمل می‌کند. این چرخش راهبردی، نحوه چیدمان، نوشتن و کوئری گرفتن از داده‌ها را به‌طور کلی تغییر می‌دهد.
بسیاری از توسعه‌دهندگان از پایگاه‌داده برداری (Vector Database) صرفاً برای پیاده‌سازی تولید بازیابی‌افزا (RAG) استفاده می‌کنند. اما با تکامل این سیستم‌ها، نیاز به عملیات پیچیده مشابه SQL مانند تجمیع (Aggregation) و گروه‌بندی افزایش یافته است؛ قابلیت‌هایی که به‌طور سنتی در قلمرو پایگاه‌داده‌های رابطه‌ای بودند. این چالش‌ها دقیقاً همان نقاط ضعفی هستند که در تحلیل ما درباره شکست سیستم‌های RAG در مقیاس تولید به آن‌ها پرداختیم، جایی که جست‌وجوی برداری ساده دیگر پاسخگوی نیازهای صنعتی نیست. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی بهینه‌سازی لایه‌های ذخیره‌سازی مدل‌های زبانی اشاره کردیم، تضاد میان سرعت جست‌وجوی برداری و کوئری‌های عمومی، بازنگری در نحوه قرارگیری فیزیکی داده‌ها روی دیسک را ضروری می‌کرد.
turbopuffer در ابتدا به عنوان یک پایگاه‌داده برداری بدون سرور (Serverless) برای کاهش هزینه‌ها عرضه شد. این سیستم از Object Storage به عنوان منبع حقیقت استفاده می‌کرد و برای حفظ عملکرد، حافظه‌های کش NVMe SSD و RAM را به کار می‌گرفت. این رویکرد توسط کاربران مقیاس‌بزرگی مانند Cursor و Notion تأیید شد.
در نسخه v2، پشتیبانی از فیلتر کردن ویژگی‌ها و جست‌وجوی تمام‌متن (FTS) اضافه شد. همچنین کاربردهای غیرجست‌وجویی، مانند موتور همگام‌سازی Linear، پشتیبانی شدند. برای حفظ سرعت، تیم از ایندکس‌های معکوس (Inverted Indexes) استفاده کرد که مقادیر ویژگی‌ها را به آدرس ANN اسناد متصل می‌کرد. اما این ساختار باعث شد تمام داده‌ها به موقعیت بردار در درخت خوشه‌ها وابسته باشند.
معماری نسخه‌های v1 و v2
در طراحی اولیه، هر سند تنها شامل یک شناسه و یک بردار بود. سیستم از یک ایندکس خوشه‌بندی سلسله‌مراتبی برای پشتیبانی از ایندکس‌گذاری افزایشی استفاده می‌کرد و از SPANN به SPFresh مهاجرت کرد. بردارها در خوشه‌هایی گروه‌بندی می‌شدند که خود در یک ساختار درختی به یک ریشه واحد ختم می‌شدند.
هر سند بر اساس ClusterId و LocalId یک «آدرس ANN» (مثلاً C0L1) دریافت می‌کرد که به کلید اصلی تبدیل می‌شد. لایه ذخیره‌سازی مانند یک نقشه کلید-مقدار (Key-Value Map) عمل می‌کرد. برای مثال، یک بردار برگ به صورت K::Vector(C0L0) و شناسه آن به صورت K::Id(C0L0) = 7 ذخیره می‌شد.
با اضافه شدن فیلتر ویژگی‌ها، این اطلاعات نیز تحت همان آدرس ANN ذخیره می‌شدند (مثلاً K::Attr(C0L0, "family") = "Alcidae"). برای جست‌وجوی تمام‌متن نیز از امتیازدهی BM25 استفاده می‌شد که نیازمند یافتن «پستینگ‌ها» (اسنادی حاوی عبارت مورد نظر) بود. تمام این قابلیت‌ها، از جست‌وجوی Regex تا بردار‌های پراکنده (Sparse Vectors)، بر پایه همین چیدمان بردار-محور بنا شده بودند.
سه دیوار بلند در ذخیره‌سازی بردار-محور
بر اساس مستندات فنی turbopuffer، این معماری با سه گلوگاه بحرانی مواجه شد:
- تکثیر ذخیره‌سازی (Storage Amplification): چون محتوای کامل سند تحت آدرس ANN ذخیره می‌شد، هر سندی که چندین نمایش برداری داشت، مجبور بود داده‌های غیربرداری خود را برای هر بردار تکرار کند.
- تکثیر نوشتن (Write Amplification): ایندکس SPFresh برای جلوگیری از افت دقت، مرتباً بردارها را بازتعادل (Rebalance) می‌کند. چون تمام ویژگی‌ها به آدرس ANN گره خورده بودند، جابه‌جایی یک بردار باعث جابه‌جایی آبشاری صدها ویژگی مرتبط می‌شد و توان عملیاتی (Throughput) را کاهش می‌داد.
- محدودیت برداری‌سازی (Vectorization): موتورهای مدرن برای بهره‌برداری از SIMD به بلوک‌های بزرگ داده نیاز دارند. در حالی که DuckDB دسته‌های ۲۰۴۸ ردیفی و ClickHouse تا ۶۵ هزار ردیف را ترجیح می‌دهند، ANN در turbopuffer با خوشه‌های ۱۰۰ تا ۲۰۰ تایی بهترین عملکرد را داشت. این موضوع باعث می‌شد سایر کوئری‌ها نیز به همین اندازه کوچک و کند شوند.
راهکار نسخه v3
راهکار v3 جداسازی کامل کلید ذخیره‌سازی اصلی از ایندکس ANN است. با حذف آدرس ANN به عنوان کلید اصلی، سیستم اکنون می‌تواند اندازه بلوک‌ها را برای هر نوع کوئری به‌طور مستقل بهینه کند.
تیم گزارش داده است که این جداسازی در FTS v2 نتایج خیره‌کننده‌ای داشته است؛ با تبدیل پستینگ‌ها به بلوک‌های ثابت ۲۵۶ تایی (به جای تقسیم‌بندی بر اساس خوشه‌های ANN)، اندازه ایندکس ۱۰ برابر کوچک‌تر و سرعت کوئری‌ها تا ۲۰ برابر بیشتر شد. در v3، این منطق به تمام بخش‌های موتور، از جمله تجمیع‌ها و اسکن‌ها، تعمیم یافته است.
تا اوایل اکتبر ۲۰۲۶، ۱۰۰٪ تست‌های یکپارچه‌سازی (CI) در معماری v3 پاس شده‌اند. تمرکز فعلاً بر روی «سایش عملکرد» (Perf Grinding) است تا پیش از عرضه نهایی، برابری یا برتری عملکرد نسبت به v2 تضمین شود. بنچمارک‌های عمومی در هفته‌های آینده منتشر خواهند شد.
این تغییر، این فرض رایج را که پایگاه‌داده‌های برداری باید «بر محور» ایندکس برداری ساخته شوند، به چالش می‌کشد و ایندکس برداری را به ابزاری تخصصی در یک موتور ذخیره‌سازی عمومی و پرقدرت تبدیل می‌کند. این معماری اجازه می‌دهد سیستم به بیش از ۱ تریلیون سند، ۱۰ میلیون نوشتن در ثانیه و ۲۵ هزار کوئری در ثانیه دست یابد، بدون آنکه گرفتار آبشارهای بازتعادل شود.
با تبدیل ANN به یک ایندکس ثانویه، turbopuffer در واقع به سمت یک مدل ترکیبی حرکت می‌کند که قدرت ذخیره‌سازی ستونی (Columnar Store) را با نیازهای تخصصی جست‌وجوی بردار معنایی (Embedding) ادغام می‌کند. این امر اجرای کوئری‌های تحلیلی پیچیده مانند GROUP BY را با سرعتی ممکن می‌سازد که پیش از این در محیط‌های بردار-محور غیرممکن بود.
گام بعدی شما
- بنچمارک‌های عمومی turbopuffer را برای بررسی تأثیر جداسازی ایندکس بر تأخیر (Latency) در مقیاس ۱۰۰ میلیارد بردار دنبال کنید.
- اگر از سیستم‌های RAG با حجم داده بالا استفاده می‌کنید، بررسی کنید که آیا Write Amplification در حال کند کردن ایندکس‌گذاری شماست یا خیر.
- معماری‌های Columnar Store را مطالعه کنید تا درک کنید چرا جداسازی کلیدها برای عملیات تحلیلی ضروری است.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو