یکپارچه‌سازی قابلیت‌های جستجوی برداری در PostgreSQL از طریق pgvector، استقرار سیستم‌های تولید تقویت‌شده با بازیابی (RAG) و برنامه‌های جستجوی شباهت را دموکراتیک کرده است. با این حال، حرکت از یک نمونه اولیه اثبات مفهوم به یک محیط تولید با توان عملیاتی بالا، اغلب گلوگاه‌های عملکردی را آشکار می‌کند. یک پیاده‌سازی ساده می‌تواند منجر به کوئری‌های کند، تأخیر بالا و بار پردازشی غیرضروری شود. این پست به بررسی نحوه بهینه‌سازی عملکرد pgvector از طریق استراتژی‌های هوشمندانه نمایه‌سازی و تنظیم کوئری می‌پردازد.
درک منظره نمایه‌سازی
pgvector در حال حاضر از دو روش اصلی نمایه‌سازی پشتیبانی می‌کند: HNSW (جهان کوچک ناوبری سلسله‌مراتبی) و IVFFlat (فایل معکوس با کم‌توان‌سازی تخت). انتخاب نمایه مناسب، تأثیرگذارترین تصمیمی است که می‌توانید برای عملکرد بگیرید.
HNSW به طور کلی برای بیشتر موارد استفاده تولیدی توصیه می‌شود. این روش نرخ بازیابی برتر و زمان‌های کوئری سریع‌تری نسبت به IVFFlat ارائه می‌دهد، به ویژه با افزایش اندازه مجموعه داده. اگرچه حافظه بیشتری مصرف می‌کند و زمان ساخت طولانی‌تری نیاز دارد، اما توانایی آن در ناوبری کارآمد ساختار گراف، آن را برای الزامات تأخیر پایین ایده‌آل می‌سازد. در مقابل، IVFFlat سبک‌تر از نظر حافظه است و سریع‌تر ساخته می‌شود، اما به ورودی/خروجی دیسک بیشتری نیاز دارد و به طور کلی نرخ بازیابی پایین‌تری ارائه می‌دهد، مگر اینکه تعداد لیست‌ها به طور قابل توجهی افزایش یابد. این روش برای سناریوهایی که حافظه محدود است یا مجموعه داده‌ها ایستا و به اندازه متوسط هستند، مناسب‌ترین گزینه است.
ایجاد نمایه‌های بهینه
هنگام ایجاد یک نمایه، انتخاب متریک فاصله و پارامترهای خاص، کیفیت جستجو را تعیین می‌کند. برای بردارهای متنی استخراج‌شده از مدل‌هایی مانند 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 را برای همخوانی با SLAهای تأخیر و دقت خود تنظیم کنید و مبادلات بین مصرف حافظه و سرعت کوئری را نظارت کنید. با اعمال این استراتژی‌ها، می‌توانید از قدرت جستجوی برداری در داخل PostgreSQL بهره ببرید بدون آنکه بر عملکرد یا قابلیت اطمینان آن تأثیر منفی بگذارد.