أدت إضافة قدرات البحث المتجهي إلى PostgreSQL عبر pgvector إلى ديمقراطية نشر أنظمة التوليد المعزز بالاسترجاع (RAG) وتطبيقات البحث عن التشابه. ومع ذلك، فإن الانتقال من نموذج أولي لإثبات المفهوم إلى بيئة إنتاجية عالية الإنتاجية يكشف غالباً عن اختناقات في الأداء. يمكن أن تؤدي التنفيذات البدائية إلى بطء الاستعلامات، وارتفاع زمن الاستجابة، واستهلاك غير ضروري لموارد وحدة المعالجة المركزية. يستكشف هذا المقال كيفية تحسين أداء pgvector من خلال استراتيجيات فهرسة ذكية وضبط للاستعلامات.
فهم مشهد الفهرسة
يدعم pgvector حالياً طريقتين رئيسيتين للفهرسة: HNSW (العالم الصغير القابل للتنقل الهرمي) وIVFFlat (ملف معكوس مع تكميم مسطح). يعد اختيار الفهرس المناسب القرار الأكثر تأثيراً الذي يمكنك اتخاذه لتحسين الأداء.
يُنصح عموماً باستخدام HNSW لمعظم حالات الاستخدام الإنتاجية. فهو يوفر معدلات استرجاع أعلى وأوقات استعلام أسرع مقارنة بـ IVFFlat، خاصة مع نمو حجم مجموعة البيانات. وعلى الرغم من أنه يستهلك ذاكرة أكبر ويستغرق وقتاً أطول للبناء، إلا أن قدرته على التنقل بكفاءة عبر بنية الرسم البياني تجعله مثالياً للمتطلبات منخفضة زمن الاستجابة. في المقابل، يكون IVFFlat أخف على الذاكرة وأسرع في البناء، لكنه يتطلب عمليات إدخال/إخراج (I/O) على القرص أكثر وعادة ما يوفر معدلات استرجاع أقل ما لم يتم زيادة عدد القوائم بشكل كبير. وهو الأنسب للحالات التي تكون فيها الذاكرة محدودة أو تكون مجموعات البيانات ثابتة ومتوسطة الحجم.
إنشاء فهارس محسّنة
عند إنشاء فهرس، فإن اختيار مقياس المسافة والمحددات المحددة يحدد جودة البحث. بالنسبة للتضمينات النصية المستمدة من نماذج مثل BERT أو text-embedding-3-small من OpenAI، غالباً ما تكون مسافة جيب التمام هي المعيار. إليك كيفية إنشاء فهرس HNSW محسّن:
CREATE INDEX CONCURRENTLY embedding_idx
ON documents
USING hnsw (embedding vector_cosine_ops);
ومع ذلك، فإن الإعدادات الافتراضية نادراً ما تكون مثالية للإنتاج. يتحكم المعامل m في عدد الروابط ثنائية الاتجاه التي يتم إنشاؤها أثناء بناء الرسم البياني، بينما يؤثر ef_construction على جودة البحث أثناء بناء الفهرس. للحصول على نتائج عالية الجودة، فكر في زيادة ef_construction:
CREATE INDEX CONCURRENTLY embedding_idx
ON documents
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);
تؤدي القيم الأعلى لـ m و ef_construction إلى زيادة استخدام الذاكرة ووقت البناء، لكنها تحسن دقة الاسترجاع بشكل كبير.
ضبط أداء الاستعلام
حتى مع وجود فهرس محسّن جيداً، يمكن أن يتدهور أداء الاستعلام إذا لم يتم ضبط معلمات البحث. يعمل الإعداد hnsw_ef_search كميزانية لخوارزمية البحث. بشكل افتراضي، يتم تعيينه على 40، وهو ما يوازن بين السرعة والدقة. بالنسبة لأحمال العمل الإنتاجية، يجب ضبط هذا بناءً على زمن الاستجابة المقبول ومعدل الاسترجاع المطلوب.
إذا كنت تعاني من ارتفاع في زمن الاستجابة عند النسبة المئوية التاسعة والتسعين (p99)، فحاول تقليل hnsw_ef_search. إذا كانت تطبيقك يتطلب دقة استرجاع قريبة من الكمال، فقم بزيادته. يمكنك تعيين هذا على مستوى الجلسة:
SET hnsw.ef_search = 128;
SELECT *
FROM documents
ORDER BY embedding <#> '[0.1, 0.2, ..., 0.1]'::vector
LIMIT 10;
اعتبارات عملية للتوسع
عندما تتجاوز مجموعة بياناتك مئات الملايين من المتجهات، فكر في تقسيم جداولك بناءً على عمود غير متجهي، مثل معرف المستأجر أو التاريخ. يتيح لك ذلك إنشاء فهارس أصغر وأكثر تركيزاً، مما يقلل من عبء التنقل عبر الرسم البياني. بالإضافة إلى ذلك، تأكد من أن خادم قاعدة البيانات لديه ذاكرة مشتركة كافية (shared_buffers) وإعدادات مستوى سجل المعاملات (WAL) مُهيأة للتعامل مع حمل الكتابة الثقيل المرتبط ببناء الفهارس.
الخاتمة
لا يعد تحسين pgvector إعداداً لمرة واحدة، بل هو عملية تكرارية. ابدأ باستخدام HNSW بسبب ملف أدائه المتوازن، وقم بضبط ef_construction و ef_search لتتوافق مع اتفاقيات مستوى الخدمة (SLAs) الخاصة بزمن الاستجابة والدقة، وراقب المقايضات بين استخدام الذاكرة وسرعة الاستعلام. من خلال تطبيق هذه الاستراتيجيات، يمكنك الاستفادة من قوة البحث المتجهي داخل PostgreSQL دون المساس بالأداء أو الموثوقية.