LanceDB تعداد ۱۰۰ هزار embedding مدل OpenAI را ۲۲ برابر سریع‌تر از pgvector بارگذاری کرد، در حالی که pgvector به همان حجم کاری از هشت کلاینت همزمان، ۱.۸ برابر سریع‌تر پاسخ داد. شکاف در تأخیر تک‌رشته‌ای (single-thread latency) و کارایی ذخیره‌سازی نیز به نفع LanceDB بود که به توسعه‌دهندگان روشی داده‌محور برای انتخاب یک ذخیره‌ساز برداری (vector store) می‌دهد.

چرا یک بنچمارک در حال حاضر اهمیت دارد

جستجوی برداری از آزمایشگاه‌های تحقیقاتی به سرویس‌های عملیاتی مانند موتورهای توصیه‌گر و تولید تقویت‌شده با بازیابی (RAG) منتقل شده است. اکثر تیم‌ها در حال حاضر از PostgreSQL استفاده می‌کنند، بنابراین افزونه pgvector وعده جستجوی شباهت را بدون نیاز به زیرساخت جدید می‌دهد. با این حال، ذخیره‌سازهای اختصاصی مانند LanceDB ادعای تأخیر کمتر و ذخیره‌سازی ارزان‌تر را دارند. تیم‌ها باید بین «اضافه کردن آن به آنچه داریم» و «اجرای یک موتور تخصصی» یکی را انتخاب کنند؛ تصمیمی که با بزرگ شدن مجموعه‌داده‌ها و افزایش نرخ درخواست‌ها، بر هزینه و عملکرد تأثیر می‌گذارد.

نحوه تنظیم تست

هر دو سیستم همان ۱۰۰ هزار بردار را که هر کدام دارای ۱۵۳۶ بُعد بودند و توسط مدل embedding OpenAI تولید شده بودند، ایندکس کردند. ما سرعت بارگذاری (ingestion speed)، میزان استفاده از دیسک، تأخیر پرس‌وجوی تک‌رشته‌ای و توان عملیاتی (throughput) را با هشت کلاینت همزمان اندازه‌گیری کردیم.

نتایج رودررو

  • سرعت بارگذاری – LanceDB برتری ۲۲ برابری را ثبت کرد.
  • میزان اشغال دیسک – LanceDB بردارها را در حدود یک‌سوم فضای مورد استفاده pgvector ذخیره کرد.
  • تأخیر تک‌رشته‌ای – پرس‌وجوها در LanceDB حدود دو برابر سریع‌تر اجرا شدند.
  • مقیاس‌پذیری همزمانی – با هشت کلاینت موازی، pgvector توان عملیاتی ۱.۸ برابر بیشتر از LanceDB ارائه داد.

ریشه‌های معماری تفاوت‌ها

LanceDB یک کتابخانه تعبیه‌شده (embedded) است که درون فرآیند Python میزبان اپلیکیشن اجرا می‌شود. تمام عملیات‌ها درون همان فرآیند باقی می‌مانند، بنابراین داده‌ها هرگز از مرز شبکه عبور نمی‌کنند و به‌روزرسانی ایندکس با کمترین سربار انجام می‌شود. این طراحی برای حجم کارهای تک‌وظیفه‌ای عالی است، اما زمانی که چندین رشته (thread) پایتون برای رقابت بر سر قفل مفسر جهانی (GIL) تلاش می‌کنند، به سقف محدودیت می‌رسد؛ قفلی که مانع از اجرای موازی واقعی بایت‌کد پایتون می‌شود.

pgvector PostgreSQL را در سمت سرور گسترش می‌دهد. هر اتصال کلاینت، یک فرآیند سرور مجزا را راه‌اندازی می‌کند و به‌طور کامل از GIL عبور می‌کند. برنامه‌ریز (planner) PostgreSQL تصمیم می‌گیرد که چگونه یک جستجوی شباهت را انجام دهد و سرور می‌تواند فرآیندهای زیادی را برای پاسخگویی به درخواست‌های همزمان ایجاد کند. این جداسازی، دلیل مقیاس‌پذیری بهتر در زیر بار کاری را توضیح می‌دهد.

ویژگی‌های خاص فیلتر کردن و برنامه‌ریزی پرس‌وجو

خط لوله‌های RAG در دنیای واقعی اغلب شباهت برداری را با فیلترهای سنتی ترکیب می‌کنند (مثلاً WHERE user_id = 42). LanceDB یک پیش‌فیلتر (prefilter) اعمال می‌کند که در اجراهای مختلف رفتاری قابل پیش‌بینی دارد. pgvector به برنامه‌ریز پرس‌وجوی PostgreSQL متکی است که بسته به آمار موجود، ممکن است یک اسکن ایندکس سریع را انتخاب کند یا به یک اسکن دقیق (exact scan) کندتر بازگردد. اجرای دستور ANALYZE پس از بارگذاری انبوه یک جدول در pgvector، آن آمار را به‌روز می‌کند؛ بدون آن، میزان بازیابی (recall) می‌تواند به نزدیک صفر برسد و عملاً جستجو را از کار بیندازد.

چه زمانی هر گزینه منطقی است

pgvector را انتخاب کنید اگر

  • پشته تکنولوژی (stack) شما در حال حاضر شامل PostgreSQL است و می‌خواهید از اضافه کردن سرویس دیگری خودداری کنید.
  • انتظار کاربران همزمان یا فراخوانی‌های API زیادی را دارید.
  • تضمین‌های ACID و ابزارهای آشنای DBA برایتان مهم است.

LanceDB را انتخاب کنید اگر

  • گردش کار شما یک خط لوله یادگیری ماشین (ML pipeline) است که به‌طور مکرر embeddingهای جدید را بارگذاری می‌کند.
  • به سریع‌ترین مسیر نوشتن و کمترین تأخیر برای عامل‌های تک‌درخواستی (مانند چت‌بات‌ها) نیاز دارید.
  • هزینه دیسک برایتان مهم است و می‌توانید سقف عملکرد تک‌رشته‌ای را تحمل کنید.

خلاصه کلام: اگر سرعت بارگذاری خام، حداقل فضای ذخیره‌سازی و تأخیر تک‌درخواستی بیشترین اهمیت را دارند، LanceDB برنده است. اگر باید به کاربران زیادی به‌طور همزمان سرویس‌دهی کنید و به یک استقرار موجود PostgreSQL متکی هستید، مزیت همزمانی pgvector آن را به گزینه‌ای امن‌تر تبدیل می‌کند. از اعداد این بنچمارک استفاده کنید تا ذخیره‌ساز را با حیاتی‌ترین معیار محصول خود مطابقت دهید.