اگر امروز برای مدیریت داده‌های برداری در ابر هزینه می‌پردازید، احتمالاً با گلوگاه‌های هزینه‌ای و تأخیرهای آزاردهنده دست‌وپنجه نرم می‌کنید. دیتابریکس با معرفی یک معماری جدید، ادعا می‌کند که هزینه‌های این زیرساخت را در مقایسه با متداول‌ترین ابزار فعلی، یعنی pgvector، تا ۷۵٪ کاهش داده است.
در ۲۸ سپتامبر ۲۰۲۶، این شرکت Lakebase Search را معرفی کرد؛ موتور داخلی برای پایگاه‌داده Lakebase Postgres که نیاز به موتورهای جست‌وجوی مجزا و خطوط لوله‌ی پیچیده‌ی انتقال داده (ETL) را از بین می‌برد.
بسیاری از عامل‌های هوش مصنوعی (AI Agents) امروز با تأخیر بالا در بازیابی داده‌های عملیاتی دست‌وپنجه نرم می‌کنند. سیستم‌های سنتی OLTP برای نیازهای عامل‌های هوش مصنوعی — که نیازمند بازیابی سریع، دقیق و جست‌وجوهای موازی گسترده هستند — طراحی نشده‌اند. همان‌طور که در تحلیل قبلی ما درباره‌ی نقش ایندکس‌های ANN در کاهش ۶۰ برابری تأخیر اشاره کردیم، دیتابریکس اکنون این کارایی را مستقیماً به لایه‌ی پایگاه‌داده آورده است. این یعنی توسعه‌دهندگان می‌توانند جست‌وجوهای معنایی، کلیدواژه‌ای و ترکیبی را بدون انتقال داده به یک ذخیره‌ساز برداری شخص ثالث، روی داده‌های اصلی خود اجرا کنند. این رویکرد در راستای تلاش‌های گسترده‌تر برای بهینه‌سازی بازیابی است، مشابه آنچه در بررسی مدل SPARSEUP برای کاهش هزینه‌های استنتاج در بازیابی معنایی مشاهده کردیم.
به گزارش unite.ai، این سیستم از طریق دو افزونه عرضه شده است: lakebasevector برای جست‌وجوی نزدیک‌ترین همسایه تقریبی (ANN) و lakebasetext برای جست‌وجوی تمام‌متن BM25. هر دو افزونه اکنون روی AWS و Azure در دسترس هستند. دیتابریکس اعلام کرده که این محصول بر اساس بازخوردهای صدها مشتری در نسخه‌ی بتا ساخته شده است.
عملکرد و بنچمارک‌ها
طبق اعلام دیتابریکس و بر اساس محک VectorDBBench 100M روی مجموعه‌داده LAION، نتایج زیر به دست آمده است:
- توان عملیاتی (Throughput): افزونه lakebase_vector دو برابر بیشتر از بهترین سیستم رقیب توان عملیاتی دارد.
- تأخیر (Latency): تأخیر P99 در سطح ۷۱ میلی‌ثانیه با نرخ بازیابی (Recall) ۹۷٪ ثبت شده است؛ به این معنا که سیستم در ۹۷٪ مواقع توانسته است نزدیک‌ترین همسایگان واقعی را با موفقیت بازیابی کند.
- هزینه: این سیستم حتی پیش از اعمال تخفیفات مقیاس‌دهی خودکار (Autoscaling)، چهار برابر ارزان‌تر از ارائه‌دهندگان ابری Postgres است که از pgvector استفاده می‌کنند.
- مقایسه: دیتابریکس اشاره کرد که در این بنچمارک‌ها، pgvector و DiskANN تنها روی یک نمونه (Instance) بزرگ تست شده‌اند.
استقرار واقعی در شرکت Conexiom نشان داد که جست‌وجوی ترکیبی روی ۱۰۰ میلیون ردیف، تنها به نیمی از منابع محاسباتیِ پیکربندی قبلی با pgvector نیاز دارد. جردن ووز، معمار AI/ML در Conexiom، تأیید کرد که هزینه‌های زیرساختی سه برابر کاهش و توان عملیاتی پنج برابر افزایش یافته است. او می‌گوید: «Lakebase Search سطح جدیدی از مقیاس‌پذیری را به ما می‌دهد و قابلیت BM25 را در همان پایگاه‌داده بدون سرور فعال می‌کند. ما از Lakebase برای متصل کردن داده‌ها به عامل‌هایمان در مقیاس بالا استفاده می‌کنیم.» این تمرکز بر مقیاس‌پذیری عامل‌ها، یادآور عملکرد برتر عامل‌های جست‌وجوی Iris در محک‌های استدلال وب است که استانداردهای جدیدی را برای بازیابی داده‌ها تعریف کرده‌اند.
رفع گلوگاه‌های pgvector
دیتابریکس سه نقطه ضعف اصلی در افزونه pgvector — که پرکاربردترین افزونه در Lakebase Postgres است — شناسایی کرده است.
نخست اینکه pgvector ایندکس HNSW را در حافظه نگه می‌دارد. به محض اینکه ایندکس به دیسک منتقل شود، عملکرد ۱۰ تا ۵۰ برابر افت می‌کند؛ زیرا جست‌وجوی HNSW بر پیمایش گراف با دسترسی تصادفی متکی است. یک بردار float32 با ۷۶۸ بُعد، با احتساب لینک‌های گراف و سربارهای Postgres، حدود ۳.۳ کیلوبایت حافظه اشغال می‌کند. برای ۱۰۰ میلیون ردیف، حدود ۳۳۰ گیگابایت رم لازم است تا داده‌ها در حافظه باقی بمانند؛ این مقدار رم باید فارغ از حجم پرس‌وجوها، به‌طور کامل رزرو و تأمین شود.
دوم، نگهداری ایندکس بسیار کند است. ساخت ایندکس در حالتی که داده‌ها به دیسک منتقل شوند، روی یک نمونه استاندارد ممکن است نزدیک به ۵۰ ساعت زمان ببرد. به دلیل نبود تعادل جهانی (Global Rebalancing) در HNSW، برای بازیابی کیفیت باید عملیات REINDEX کامل انجام شود که باعث قفل شدن جدول و توقف کامل نوشتن داده‌ها در محیط عملیاتی می‌شود. همچنین درج بردارها به دلیل نیاز به پیمایش دسترسی تصادفی و تغییر در چندین لایه‌ی گراف، با همین گلوگاه مواجه است.
سوم، پرس‌وجوهای pgvector قابلیت موازی‌سازی ندارند. هر پرس‌وجو توسط تنها یک فرآیند بک‌اند Postgres مدیریت می‌شود؛ بنابراین برای رسیدن به نرخ بازیابی بالاتر، نیاز به خواندن‌های تصادفی بیشتر از حافظه و در نتیجه تأخیر بیشتر است. در حال حاضر، افزایش توان عملیاتی مستلزم افزودن اتصالات بیشتر به پایگاه‌داده یا ایجاد نسخه‌های Read Replica است.
معماری فنی
پایگاه‌داده Lakebase Postgres این مشکل را با جداسازی ذخیره‌سازی از محاسبات (Compute) حل می‌کند. داده‌های دائمی در ذخیره‌سازهای ارزان‌قیمت ابری (Object Storage) می‌مانند و رم و NVMe محلی به‌عنوان حافظه‌های پنهان (Cache) کوتاه‌مدت برای داده‌های فعال عمل می‌کنند.
برای بهینه‌سازی جست‌وجو، دیتابریکس از دو مکانیزم استفاده می‌کند:
- خوشه‌بندی سلسله‌مراتبی IVF: بردارها در خوشه‌هایی گروه‌بندی می‌شوند که به‌صورت بلوک‌های متوالی ذخیره شده‌اند. سیستم امتیاز مرکز خوشه‌ها را در حافظه محاسبه کرده و به‌جای پرش‌های تصادفی، خوانش‌های متوالی بزرگ انجام می‌دهد.
- کوانتیزاسیون باینری (Binary Quantization): با استفاده از روش RaBitQ، بردارها به یک بیت در هر بُعد فشرده می‌شوند. این کار حجم آن‌ها را ۳۲ برابر کمتر از float32 می‌کند و به سیستم اجازه می‌دهد ابتدا کاندیداهای احتمالی را سریعاً شناسایی و سپس با دقت کامل بازرتبه‌بندی (Reranking) کند.
به دلیل طراحی بدون وضعیت (Stateless)، این سیستم می‌تواند تا صفر مقیاس شود. دیتابریکس گزارش داد که برای نخستین پرس‌وجو پس از یک رویداد scale-to-zero روی مجموعه‌ای با ۱۰۰ میلیون بردار و ۷۶۸ بُعد، تأخیر P90 برابر ۱.۱۳ ثانیه بوده است. همچنین، ۱۰۰ میلیون بردار را می‌توان تنها با یک واحد محاسباتی Lakebase سرویس داد. این قابلیت مقیاس‌پذیری به صفر، در راستای چشم‌انداز استفاده از بردار‌های سرورلس برای کاهش هزینه‌های عملیاتی به صفر است که جایگزینی بهینه برای مدل‌های سنگین LLM در لایه‌ی بازیابی محسوب می‌شود.
ایندکس‌گذاری و مقیاس‌پذیری
ساخت ایندکس با آموزش مراکز خوشه‌ها روی یک نمونه تصادفی کوچک بهینه شده است. هر بردار سپس کوانتیده شده و به‌عنوان یک عملیات مستقل در بلوک خود نوشته می‌شود که اجازه می‌دهد کار بین تمام هسته‌های موجود توزیع شود.
دیتابریکس از معماری LTAP استفاده می‌کند تا ساخت ایندکس را از پایگاه‌داده اصلی به موتورهای توزیع‌شده‌ای مانند Spark منتقل کند و زمان ساخت را از چند روز به چند دقیقه برساند. از آنجا که فیلترها (Predicates) در حین اسکن بلوک اعمال می‌شوند، پرس‌وجوهای فیلترشده از واکشی بیش از حد کاندیداها جلوگیری کرده و یک پرس‌وجوی واحد می‌تواند روی چندین هسته CPU موازی شود.
قابلیت‌های جست‌وجوی ترکیبی
افزونه lakebase_text با استفاده از فرکانس معکوس سند جهانی (Global IDF)، جست‌وجوی استاندارد tsvector در Postgres را بهبود بخشیده است. این روش به کلمات نادر با قصد بالا وزن بیشتری می‌دهد و کلمات پرکننده رایج را نادیده می‌گیرد. همچنین با بررسی حد بالای امتیاز در حین پیمایش ایندکس، بلوک‌هایی که تأثیری در نتایج برتر (Top-K) ندارند را حذف می‌کند و سریع‌تر از tsvector با ایندکس‌های GIN عمل می‌کند.
با ترکیب این دو افزونه، کاربران می‌توانند یک پرس‌وجوی SQL واحد اجرا کنند که جداول عملیاتی زنده را متصل کرده، فیلترها را اعمال کند و امتیاز معنایی را با ارتباط کلیدواژه‌ای BM25 ادغام نماید. این معماری به‌طور خاص برای عامل‌های هوش مصنوعی طراحی شده که ممکن است در چند ثانیه هزاران درخواست هم‌زمان ایجاد کنند. این سیستم برای مقیاس‌پذیری از یک ردیف تا یک میلیارد بردار و از یک پرس‌وجو در ثانیه تا هزاران درخواست بدون نیاز به پیکربندی دستی ساخته شده است.
این چرخش به این معناست که سازمان‌ها دیگر مجبور نیستند بین سادگی یک پایگاه‌داده رابطه‌ای و قدرت یک موتور جست‌وجوی اختصاصی یکی را انتخاب کنند. در حالی که Databricks AI Search همچنان موتور مدیریت‌شده و آماده است، Lakebase Search بخش «عملیاتی» تولید بازیابی‌افزا (RAG) — شبیه به دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — را هدف قرار داده است. کاربران اکنون می‌توانند این افزونه‌ها را در محیط‌های موجود Lakebase روی AWS و Azure فعال کنند تا افزایش توان عملیاتی را در برابر استقرار فعلی pgvector خود بسنجند.
گام بعدی شما
- اگر از pgvector استفاده می‌کنید، هزینه استنتاج و میزان مصرف رم خود را با مدل‌های بدون وضعیت (Stateless) مقایسه کنید.
- برای کاهش تأخیر در عامل‌های هوش مصنوعی، استراتژی جست‌وجوی ترکیبی (Hybrid Search) را جایگزین جست‌وجوی صرفاً برداری کنید.
- بررسی کنید که آیا جداسازی لایه‌ی محاسبات از ذخیره‌سازی می‌تواند هزینه‌های زیرساخت ابری شما را کاهش دهد یا خیر.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو