pgvector یا Pinecone؛ سه‌برابر توان عملیاتی می‌تواند ۴٫۸ برابر گران‌تر شود

در آزمون منتشرشدهٔ Markaicode روی یک میلیون بردار مصنوعی، پاد Pinecone s1.x1 در recall نزدیک به ۹۹٪ توان عملیاتی ۱۲۰۰ پرس‌وجو در ثانیه را در برابر ۴۰۰ پرس‌وجوی pgvector 0.7.0 با IVFFlat ثبت کرد؛ هزینهٔ محاسبه‌شده برای هر هزار پرس‌وجو نیز ۰٫۱۲ دلار در برابر ۰٫۰۲۵ دلار بود: سه‌برابر توان عملیاتی با ۴٫۸ برابر هزینهٔ واحد. این نسبت به همان پیکربندی و روش محاسبه تعلق دارد.

برای تیمی که دادهٔ رابطه‌ای و ظرفیت آزاد PostgreSQL دارد، pgvector معمولاً گزینهٔ آغازین معقولی است. Pinecone زمانی جذاب‌تر می‌شود که بار بازیابی، ظرفیت پایگاه موجود را تحت فشار بگذارد یا ادارهٔ نمایه و منابع آن برای تیم پرهزینه باشد. انتخاب را با تعداد بردارها، نرخ میانگین و اوج پرس‌وجو، recall لازم و هزینهٔ کار عملیاتی بسنجید؛ هیچ‌کدام از این ورودی‌ها به‌تنهایی برنده را تعیین نمی‌کند.

چرا نتایج آزمون‌ها یکسان نیست؟

مقایسهٔ Supabase در اکتبر ۲۰۲۳ روی یک میلیون بردار واقعی ۱۵۳۶بعدی، pgvector با نمایهٔ HNSW و نمونهٔ 2XL را در برابر پادهای Pinecone با بودجهٔ ماهانهٔ نزدیک به هم گذاشت و در پیکربندی‌های گزارش‌شده، توان عملیاتی بالاتری برای pgvector یافت. آن آزمون از درخواست‌های هم‌زمان برای یافتن بیشینهٔ توان عملیاتی استفاده کرد. آزمون مبنای اعداد آغاز متن، بردارهای مصنوعی ۷۶۸بعدی و IVFFlat را به کار برد؛ بنابراین اختلاف نتیجه را نمی‌توان به نام محصول به‌تنهایی نسبت داد.

مقایسهٔ خود Pinecone نیز می‌گوید اندازه‌گیری‌های اصلی‌اش به آوریل ۲۰۲۴ و پیش از pgvector 0.8.0 برمی‌گردد؛ همان صفحه توضیح می‌دهد آزمون‌های قدیمی مبتنی بر پاد، نسل‌های دیگر سرویس را نمی‌سنجند. برای خواندن هر نسبت سرعت یا هزینه باید نسل Pinecone، نسخهٔ pgvector، نوع نمایه، داده، معیار فاصله و روش اعمال فیلتر را کنار آن دید.

شرح روش آزمون آغاز متن هم یک ابهام مهم دارد: اجرای درخواست‌ها را پی‌درپی توصیف می‌کند، اما توان عملیاتی اعلام‌شده با وارون تأخیر میانهٔ همان اجرا سازگار نیست. در جدول تنظیمات نیز پارامتر جست‌وجوی HNSW کنار نمایهٔ IVFFlat آمده است. تا وقتی نقش هم‌زمانی و تنظیم واقعی نمایه روشن نباشد، آن نسبت‌ها مبنای مطمئنی برای خرید ظرفیت نیستند؛ ارزششان نشان‌دادن مبادلهٔ احتمالی میان سرعت و هزینه در یک گزارش مشخص است.

recall و فیلتر، مقایسهٔ سرعت را چگونه عوض می‌کنند؟

توان عملیاتی فقط وقتی قابل مقایسه است که هر دو سامانه پاسخ‌هایی با کیفیت موردنیاز بدهند. recall سهم همسایه‌های واقعی است که در نتیجهٔ جست‌وجوی تقریبی پیدا می‌شوند؛ برای سنجش آن باید مجموعهٔ پاسخ دقیق، معیار فاصله و تعداد نتایج در دو طرف یکسان باشد. افزایش شمار نامزدهایی که نمایه بررسی می‌کند می‌تواند recall را بهتر کند، اما معمولاً زمان پردازش بیشتری می‌خواهد. تأخیر میانه نیز تجربهٔ درخواست‌های کندتر را نشان نمی‌دهد؛ صدک‌های بالای تأخیر زیر بار هم‌زمان برای ظرفیت‌سنجی لازم‌اند.

مستندات رسمی pgvector توضیح می‌دهد که در نمایه‌های تقریبی، فیلتر پس از پیمایش نمایه اعمال می‌شود و نسخهٔ 0.8.0 پیمایش تکراری را برای جست‌وجوی نامزدهای بیشتر اضافه کرده است؛ همان مستندات ef_search را تنظیم HNSW و probes را تنظیم IVFFlat معرفی می‌کند. پیمایش تکراری نیز حدی دارد. اگر شرطی مانند شناسهٔ مستأجر تنها بخش کوچکی از ردیف‌ها را مجاز کند، جست‌وجوی سریعِ بدون فیلتر چیزی دربارهٔ کامل‌بودن پاسخ فیلترشده نمی‌گوید.

در PostgreSQL می‌توان بسته به توزیع داده از نمایهٔ ستون فیلتر، نمایهٔ جزئی یا بخش‌بندی جدول کمک گرفت. هزینه و فایدهٔ هرکدام به شمار مقادیر فیلتر و برنامهٔ اجرای واقعی پرس‌وجو بستگی دارد. برای مقایسهٔ منصفانه، همان فیلترها، درج و حذف داده و تعداد درخواست‌های هم‌زمانِ بار اصلی برنامه باید در هر دو طرف حضور داشته باشند.

برگهٔ محاسبه برای دو حجم و سه نرخ پرس‌وجو

یک مثال فرضی را در نظر بگیرید: هر بردار ۷۶۸ مؤلفه دارد و هر مؤلفه چهار بایت فضای خام می‌گیرد. خود بردارها برای یک میلیون رکورد ۳٫۰۷۲ گیگابایت و برای ده میلیون رکورد ۳۰٫۷۲ گیگابایت می‌شوند. این فقط اندازهٔ دادهٔ خام است؛ شناسه، فراداده، نمایه، سربار ذخیره‌سازی، نسخهٔ پشتیبان و فضای لازم هنگام ساخت نمایه به آن افزوده می‌شود. در نتیجه، ده‌برابرشدن شمار بردارها به معنای ده‌برابرشدن سادهٔ هزینهٔ ماشین نیست.

برای ماه فرضی ۳۰روزه با ترافیک یکنواخت، حجم درخواست را برای هر دو اندازهٔ مجموعه‌داده از نرخ پرس‌وجو جدا حساب کنید. همان نرخ در مجموعهٔ بزرگ‌تر تعداد درخواست بیشتری تولید نمی‌کند، اما ممکن است حافظه، زمان پاسخ و منابع لازم برای هر درخواست را تغییر دهد:

• ۰٫۱ پرس‌وجو در ثانیه: ۲۵۹٬۲۰۰ درخواست در ماه.
• ۱ پرس‌وجو در ثانیه: ۲٬۵۹۲٬۰۰۰ درخواست در ماه.
• ۱۰ پرس‌وجو در ثانیه: ۲۵٬۹۲۰٬۰۰۰ درخواست در ماه.

این ترکیب، شش حالت هزینه می‌سازد: هر سه نرخ برای یک میلیون و ده میلیون بردار. در کنار میانگین، نرخ اوج را هم ثبت کنید؛ ماشین PostgreSQL باید دورهٔ شلوغ را پاسخ دهد، در حالی که صورت‌حساب سرویس مبتنی بر مصرف به الگوی استفاده وابسته است. اگر نمایهٔ مجموعهٔ بزرگ‌تر از حافظهٔ مؤثر بیرون بزند، هزینه و تأخیر pgvector می‌تواند به‌صورت پله‌ای تغییر کند. بنابراین برای ستون هزینهٔ این برگه، اندازهٔ واقعی نمایه و ظرفیت لازم برای recall و تأخیر هدف باید اندازه‌گیری شود.

هزینهٔ ماهانه از کدام اجزا ساخته می‌شود؟

در قیمت‌گذاری Pinecone، مصرف ذخیره‌سازی، خواندن و نوشتن برای On-Demand جداگانه محاسبه می‌شود و گزینهٔ Dedicated Read Nodes مدل ظرفیت دیگری دارد. به همین دلیل، هزینهٔ واحدِ محاسبه‌شده برای پاد در آزمون آغاز متن را نمی‌توان در شمار درخواست‌های ماهانه ضرب کرد و صورت‌حساب استقرار تازه دانست. حجم فراداده، تعداد واحدهای خواندن هر درخواست، به‌روزرسانی رکوردها و طرح انتخابی بر مبلغ نهایی اثر دارند.

برای pgvector، هزینهٔ افزایشیِ پردازنده و حافظهٔ PostgreSQL، فضای داده و نمایه، پشتیبان‌گیری، تکرار داده و زمان نگهداری را جمع کنید. اگر پایگاه موجود ظرفیت آزاد دارد، نسبت‌دادن کل هزینهٔ آن به قابلیت جست‌وجوی برداری گمراه‌کننده است. اگر افزودن نمایه ارتقای ماشین یا نمونهٔ خواندنی تازه بخواهد، حذف این هزینه نیز مقایسه را منحرف می‌کند. در هر شش حالت برگه، هزینه را برای recall، تأخیر و نرخ اوج یکسان محاسبه کنید.

هزینهٔ عملیاتی دو شکل متفاوت دارد. نگه‌داشتن بردار کنار ردیف رابطه‌ای در pgvector می‌تواند نیاز به هماهنگ‌کردن دو مخزن داده را کم کند، اما تنظیم نمایه، رشد حافظه، اثر نوشتن‌ها و برنامهٔ نگهداری PostgreSQL بر عهدهٔ تیم می‌ماند. Pinecone ادارهٔ زیرساخت جست‌وجو را به سرویس منتقل می‌کند، در عوض تغییر و حذف داده باید میان پایگاه اصلی برنامه و نمایهٔ جداگانه هماهنگ شود. برای بار کوچکِ جاگرفته در پایگاه موجود، سادگی مسیر داده می‌تواند تعیین‌کننده باشد؛ با رشد بار، هزینهٔ ظرفیت و وقت مهندسی ممکن است کفهٔ انتخاب را عوض کند.

بیشتر بخوانید:

• pgvector یا Pinecone؛ دیتابیس دوم فقط وقتی مقیاس آن را توجیه کند
• مصاحبهٔ ساختاریافته یا آزاد؛ یک مصاحبه می‌تواند جای چهار مصاحبه را بگیرد
• PostgreSQL یا MySQL برای JSON؛ نوع ایندکس نتیجه را دو برابر می‌کند