قام LanceDB بتحميل 100 ألف من تضمينات (embeddings) OpenAI أسرع بـ 22 مرة من pgvector، بينما أجاب pgvector على نفس عبء العمل من ثمانية عملاء متزامنين أسرع بـ 1.8 مرة. كما مالت الفجوة في زمن انتقال الخيط الواحد (single-thread latency) وكفاءة التخزين لصالح LanceDB، مما يمنح المطورين طريقة قائمة على البيانات لاختيار مخزن المتجهات (vector store).

لماذا تكتسب الاختبارات المرجعية أهمية الآن

انتقل البحث المتجهي (Vector search) من المختبرات البحثية إلى خدمات الإنتاج مثل محركات التوصية والتوليد المعزز بالاسترجاع (RAG). تعمل معظم الفرق بالفعل على PostgreSQL، لذا تعد إضافة pgvector بإمكانية البحث عن التشابه دون الحاجة إلى بنية تحتية جديدة. ومع ذلك، تدعي المخازن المخصصة مثل LanceDB توفير زمن انتقال أقل وتخزين أرخص. يجب على الفرق الاختيار بين "إضافته إلى ما لدينا بالفعل" وبين "تشغيل محرك مخصص لهذا الغرض"، وهو قرار يؤثر على التكلفة والأداء مع نمو مجموعات البيانات وارتفاع معدلات الطلب.

كيف تم إعداد الاختبار

قام كلا النظامين بفهرسة نفس الـ 100 ألف متجه، كل منها بـ 1536 بُعدًا، تم إنشاؤها بواسطة نموذج التضمين (embedding model) من OpenAI. قمنا بقياس سرعة الإدخال (ingestion speed)، واستهلاك القرص، وزمن انتقال الاستعلام للخيط الواحد، والإنتاجية (throughput) مع ثمانية عملاء متزامنين.

النتائج المباشرة

  • سرعة الإدخال – سجل LanceDB تفوقًا بمقدار 22 ضعفًا.
  • مساحة القرص – خزن LanceDB المتجهات في حوالي ثلث المساحة التي استخدمها pgvector.
  • زمن انتقال الخيط الواحد – كانت الاستعلامات تعمل أسرع بمرتين تقريبًا على LanceDB.
  • توسع التزامن – مع ثمانية عملاء متوازيين، قدم pgvector إنتاجية أعلى بمقدار 1.8 مرة من LanceDB.

الجذور المعمارية للاختلافات

LanceDB عبارة عن مكتبة مدمجة (embedded library) تعمل داخل عملية Python التي تستضيف التطبيق. تظل جميع العمليات داخل العملية نفسها، لذا لا تعبر البيانات حدود الشبكة أبدًا، ويتم تحديث الفهرس بأقل قدر من العبء الإضافي. يتألق هذا التصميم في أعباء العمل ذات المهمة الواحدة، ولكنه يصطدم بسقف عندما تتنافس خيوط Python المتعددة على قفل المفسر العام (GIL)، والذي يمنع التنفيذ المتوازي الحقيقي لـ Python bytecode.

يقوم pgvector بتوسيع PostgreSQL من جانب الخادم. تطلق كل عملية اتصال للعميل عملية خادم منفصلة، مما يتجاوز GIL تمامًا. يقرر مخطط PostgreSQL كيفية تلبية البحث عن التشابه، ويمكن للخادم تشغيل العديد من العمليات لخدمة الطلبات المتزامنة. يفسر هذا العزل التوسع الأفضل تحت ضغط العمل.

غرائب التصفية وتخطيط الاستعلام

غالبًا ما تجمع خطوط أنابيب RAG في العالم الحقيقي بين التشابه المتجهي والفلاتر التقليدية (مثل WHERE user_id = 42). يطبق LanceDB تصفية مسبقة (prefilter) تعمل بشكل يمكن التنبؤ به عبر عمليات التشغيل. يعتمد pgvector على مخطط استعلام PostgreSQL، والذي قد يختار فحص فهرس سريع أو يلجأ إلى فحص دقيق أبطأ اعتمادًا على الإحصائيات. يؤدي تشغيل ANALYZE بعد التحميل الضخم لجدول pgvector إلى تحديث تلك الإحصائيات؛ وبدون ذلك، يمكن أن ينخفض الاستدعاء (recall) إلى ما يقرب من الصفر، مما يؤدي فعليًا إلى تعطل البحث.

متى يكون كل خيار منطقيًا

اختر pgvector إذا

  • كانت مجموعتك التقنية (stack) تتضمن بالفعل PostgreSQL وتريد تجنب إضافة خدمة أخرى.
  • كنت تتوقع العديد من المستخدمين المتزامنين أو استدعاءات API.
  • كانت ضمانات ACID وأدوات DBA المألوفة مهمة بالنسبة لك.

اختر LanceDB إذا

  • كان سير عملك عبارة عن خط أنابيب تعلم آلي (ML pipeline) يقوم بإدخال تضمينات جديدة بشكل متكرر.
  • كنت بحاجة إلى أسرع مسار كتابة وزمن انتقال منخفض للوكلاء ذوي الطلب الواحد (مثل روبوتات الدردشة).
  • كانت تكلفة القرص مصدر قلق ويمكنك تحمل سقف أداء الخيط الواحد.

الخلاصة: إذا كانت سرعة الإدخال الخام، والحد الأدنى من التخزين، وزمن انتقال الطلب الواحد هي الأكثر أهمية، فإن LanceDB هو الفائز. أما إذا كان يجب عليك خدمة العديد من المستخدمين في وقت واحد والاعتماد على نشر PostgreSQL الحالي، فإن ميزة التزامن في pgvector تجعله الرهان الأكثر أمانًا. استخدم الأرقام من هذا الاختبار المرجعي لمطابقة المخزن مع المقياس الأكثر أهمية لمنتجك.