RIP، پایگاه داده برداری

ما در حال تغییر معماری ذخیره سازی توربوپافر هستیم تا جستجو را به سطح بعدی برسانیم. turbopuffer v3 نحوه چیدمان، نوشتن، فشرده سازی، و پرس و جوی اسناد و نمایه ها را در توربوپافر تغییر می دهد. این به ما امکان می‌دهد جستجو را از هر نظر سریع‌تر کنیم - از جمله جستجوی متنی، regex و برداری - اما همچنین پایه‌ای را برای انتقال بسیاری از پرس‌و‌جوهای SQL به turbopuffer و سرعت بخشیدن به آنها ایجاد می‌کند.

turbopuffer به عنوان یک پایگاه داده برداری بدون سرور (v1) راه اندازی شد، که بسیار تخصصی برای انجام جستجوهای برداری بسیار ارزان و نسبتا سریع است. ذخیره‌سازی اشیا به‌عنوان منبع حقیقت به اقتصاد کمک می‌کند، و حافظه‌های کش SSD/حافظه NVMe سطحی عملکرد را به ارمغان می‌آورد. ارزش این مبادلات خاص توسط اولین مشتریان ما، از جمله Cursor و Notion تأیید شده است.

turbopoffer تکامل یافته است تا متن و جستجوی regex بسیار قوی (v2) داشته باشد، و برای بسیاری از موارد استفاده غیرجستجو، مانند موتور همگام سازی Linear استفاده می شود. موتور پرس و جو در طول مسیر تکامل یافته است تا از همه این طرح های پرس و جو پشتیبانی کند، اما معماری ذخیره سازی تا حد زیادی بدون تغییر باقی مانده است: شاخص برداری ANN شاخص اولیه ای بود که همه نمایه ها و طرح های پرس و جو دیگر حول آن می چرخند. این طراحی چندین طرح پرس و جو مانند GROUP BY و aggregations را محدود کرده است.

تا جایی که می‌توانیم معماری اولیه وکتور را پیش بردیم و زمان آن فرا رسیده است که ادامه دهیم. ما در حال حرکت به یک شاخص اولیه جدید، و ساختن ANN "فقط یک شاخص دیگر" ثانویه هستیم. ما فکر کردیم که ممکن است سرگرم کننده باشد که درها را باز کنیم و به شما اجازه دهیم دنبال کنید.

برای این اولین به‌روزرسانی، در وهله اول دلیل انجام این کار را مشخص می‌کنیم. با من در یک سفر کوتاه از tpuf v1 تا امروز قدم بزنید.

در نسخه اول توربوپافر، اسناد چیزی جز شناسه و بردار نبود. حکمت غالب در آن زمان، شاخص‌های برداری مبتنی بر نمودار بود، اما یک شاخص خوشه‌بندی سلسله مراتبی با ذخیره‌سازی اشیا بهتر بازی می‌کند. ما با SPANN شروع کردیم و در نهایت برای پشتیبانی از نمایه سازی افزایشی به SPFresh مهاجرت کردیم. بردارها به گروه‌هایی خوشه‌بندی می‌شوند که مرکز آن‌ها به نوبه خود خوشه‌بندی می‌شوند و برای تشکیل درختی با یک ریشه تکرار می‌شوند.

ما این را در بالای یک لایه ذخیره سازی که به عنوان یک نقشه کلید-مقدار ارائه می شود، با کلیدهای مرتب شده و منحصر به فرد پیاده سازی کردیم. به هر خوشه یک ClusterId داده می شود و به بردارهای درون هر خوشه یک LocalId متراکم داده می شود.

همانطور که در بالا می بینید، همه چیز توسط ClusterId و LocalId (به عنوان مثال C0L1) کلید می خورد، که با هم آدرس ANN را می نامیم. این همان چیزی است که می گوییم شاخص ANN شاخص اولیه است.

دو طرح جستجوی جدید انتقال غیررسمی از توربوپافر v1 → v2 را مشخص کردند: فیلتر ویژگی و جستجوی متن کامل.

به طور طبیعی، مشتریان می خواستند بتوانند مقادیر مشخصه را اضافه کنند و جستجوهای برداری را روی آنها فیلتر کنند. برای اینکه فیلتر کردن سریع و فراخوان بالا باشد، اینها را به عنوان یک شاخص معکوس مدل کردیم که یک مقدار مشخصه را به آدرس ANN اسنادی که حاوی آن هستند نگاشت می کند.

برای پیش بینی ها (include_attributes)، ما همچنین ویژگی های سند را در کنار شناسه و بردار ذخیره کردیم.

جستجوی متن کامل BM25 یکی دیگر از طرح های پرس و جو واضح و بسیار مورد تقاضا بود. مشابه جستجوی صفت، جستجوی متن کامل با یافتن اسنادی که عبارت جستجو را دارند (که معمولا «پست‌ها» نامیده می‌شود) کار می‌کند. برای یک شاخص FTS، ما همچنین ابرداده (شمارش ترم، طول سند) لازم برای امتیازدهی BM25 را در نظر می گیریم:

با گذشت زمان، چندین ساختار فهرست دیگر و موتورهای پرس و جو ارسال کرده‌ایم: تجمیع، جستجوی regex، تطبیق فازی، جستجوی برداری پراکنده، و مرتب‌سازی ویژگی‌ها - که همگی حول یک طرح‌بندی ذخیره‌سازی اولیه بردار ساخته شده‌اند.

شاخص اولیه ANN تا امروز به یک دلیل ساده تا حد زیادی دست نخورده باقی مانده است: برای جستجوی ANN در ذخیره سازی اشیا واقعا بسیار خوب عمل می کند. علاوه بر این معماری، ما جستجوی برداری را به فهرست‌های تکی از بردارهای 100B+ که 200 میلی‌ثانیه خواندن p99 را در 1k+ QPS ارائه می‌کنند، سوق داده‌ایم. هر تغییر قابل توجهی در اینجا خطر ایجاد رگرسیون در عملکرد ANN را دارد.

با این حال، این چیدمان ما را از پیشرفته بودن شکل‌های پرس و جو غیر برداری که پشتیبانی می‌کنیم، به سه روش اصلی باز می‌دارد: تقویت ذخیره‌سازی، تقویت نوشتن و بردارسازی محدود.

همانطور که در بالا توضیح داده شد، turbopuffer در حال حاضر محتوای کامل هر سند را تحت آدرس ANN خود قرار می دهد. هنگامی که تنها یک بردار وجود دارد، داده های غیر برداری تنها یک بار در کنار بردار ذخیره می شوند.

با این حال، برای نمایش‌های چند بردار یک سند، مانند تودرتوی سند یا تعامل دیرهنگام، این بدان معناست که باید محتویات هر بردار را کپی کنیم. این دلیل برخی از محدودیت های تاسف بارتر ماست.

هر زمان که سندی درج، به‌روزرسانی یا حذف می‌شود، SPFresh ممکن است بردارها را مجددا متعادل کند تا مطمئن شود که به خوبی خوشه‌بندی می‌شوند (در غیر این صورت ممکن است فراخوانی آسیب ببیند). از آنجایی که همه چیز در یک سند توسط آدرس ANN بردار سند ذخیره می شود، این تعادل مجدد آبشاری به جابجایی محتویات کامل سند و همچنین هر شاخص معکوس (ویژگی و FTS) که به آن ارجاع می دهد منجر می شود. به روز رسانی تنها یک بردار می تواند صدها ویژگی و شاخص های آنها را جابجا کند.

این تقویت نوشتن به اندازه‌ای بزرگ است که تلاش‌های ما برای تنظیم توان نمایه‌سازی شروع به بازدهی کاهشی کرده است.

موتورهای جستجوی مدرن بردار هستند: آنها حلقه های محکمی را روی بلوک های مقادیر اجرا می کنند که هزینه های ثابت هر بلوک را مستهلک می کند، بهتر فشرده می شود، خط لوله CPU را پر نگه می دارد و SIMD را باز می کند. برای مثال، DuckDB در دسته‌های 2048 ردیفی، ClickHouse تا ~65k، بلوک‌های ارسال Lucene 256 سند است، و شاخص ANN ما با خوشه‌هایی از حدود 100 تا 200 سند بهترین کار را دارد. هر طرح پرس و جو دارای اندازه بلوک بهینه است، اما امروزه همه آنها توسط شاخص اولیه ANN محدود شده اند. طرحی که بلاک هایی از هزاران سند را برای اشباع نگه داشتن CPU می خواهد، هنوز در 100-200 باقی مانده است.

ما قبلا مستند کرده‌ایم که این موضوع در توربوپافر چقدر اهمیت دارد. اولین نسخه ما از جستجوی متن کامل فهرست‌های ارسال پست را در امتداد مرزهای خوشه ANN تقسیم بندی کرد و بلوک میانه فقط 1.5 پست را در خود جای داد. FTS v2 پست‌ها را در بلوک‌های ثابت 256 ~ بازنویسی کرد و ایندکس 10 برابر کوچکتر شد و جستجوها تا 20 برابر سریع‌تر شدند. فهرست‌های ارسال می‌توانند این کار را انجام دهند، زیرا آنها به طور جداگانه ذخیره می‌شوند و به اسناد اشاره می‌کنند، بنابراین طرح‌بندی آنها نیازی به پیروی از خوشه‌ها ندارد. تجمیع‌ها و سایر اسکن‌ها خود اسناد را می‌خوانند و آن‌ها یک بلوک در هر خوشه ذخیره می‌شوند.

تا زمانی که آدرس ANN کلید اصلی است، اندازه بلوک آنها به اندازه خوشه محدود می شود، حتی اگر چیزی بزرگتر را ترجیح دهند.

راه حل این مشکلات ساده است: آدرس ANN را کلید نزنید. این دقیقا همان تغییری است که توربوپافر v3 ایجاد می کند. همانطور که می توانید تصور کنید، این یک تغییر بی اهمیت نیست.

v3 پایه جدیدی است که بهبود عملکرد قابل توجهی را در همه طرح‌های پرس‌وجو باز می‌کند، و ما در اوایل این ماه به یک نقطه عطف بزرگ دست یافتیم: 100٪ از CI در توربوپافر v3 می‌گذرد. ما با تمرکز بر درستی شروع کردیم. حالا ما آن را درست و سریع می کنیم. تماشای پایین آمدن اعداد معیار سرگرم کننده است، بنابراین ما می‌خواستیم شما را در روز صفر آسیاب کردن عملکرد معرفی کنیم. ما در هفته‌های آتی معیارها را به صورت عمومی به اشتراک خواهیم گذاشت، زیرا قبل از عرضه نسخه 3 به تولید، به سمت برابری عملکرد (و فراتر از آن) کار می‌کنیم.

turbopuffer یک موتور جستجوی سریع است که اسناد 1T+ را میزبانی می کند، 10M+ نوشتن/ثانیه را مدیریت می کند و 25k+ پرس و جو در ثانیه را ارائه می دهد. ما برای خیلی بیشتر آماده ایم. امیدواریم با سوالات خود به ما اعتماد کنید.