هل يجب تخزين متجهات الـ embeddings في قاعدة بيانات PostgreSQL باستخدام الامتداد pgvector، أم تكليف هذه المهمة لقاعدة بيانات متجهة مخصصة؟ يقترح دليل تقني الإجابة على السؤال باستخدام قياسات الأداء بدلاً من الحجج النظرية، من خلال مقارنة pgvector مع Qdrant.
هندستان مختلفتان، هدف واحد
pgvector هو امتداد مفتوح المصدر لـ PostgreSQL، بالإصدار 0.8.6، متوافق مع PostgreSQL 13 والإصدارات الأحدث، وفقًا لمستودعه الرسمي على GitHub. يضيف إلى القاعدة نوع عمود مخصص للمتجهات، بالإضافة إلى بحث دقيق وتقريبي عن أقرب الجيران. عمليًا، يمكن تخزين embedding، أي التمثيل الرقمي للمحتوى في شكل متجه، في نفس الجدول الذي يحتوي على البيانات التي يشير إليها، والاستعلام عنه باستخدام لغة SQL المعتادة. يتم تقديم خمس دوال للمسافة، بما في ذلك جيب التمام والضرب النقطي.
قاعدة البيانات المتجهة المخصصة هي، على العكس، خدمة منفصلة، مزودة بمحرك تخزين خاص بها ومصممة حول البحث المتجه. يذكر الدليل على وجه الخصوص Pinecone وQdrant وWeaviate وMilvus وChromaDB. يتطلب اختيار الهندسة هذا نشر ومراقبة ونسخ احتياطي لنظام إضافي، والحفاظ على مزامنته مع القاعدة التي تحتوي على البيانات المرجعية.
قياسات محلية، ثم على نطاق واسع
يقترح الدليل اختبارًا قابلًا للتكرار على حاسوب محمول، باستخدام Docker وPython 3.10 أو إصدار أحدث وحوالي 8 جيجابايت من ذاكرة الوصول العشوائي الحرة. مجموعة البيانات اصطناعية: 100,000 متجه بأبعاد 1536، وهو حجم نموذج embeddings شائع، محملة في كلا النظامين بنفس معاملات فهرس HNSW. على مثل هذا الجهاز، تقع زمنات الانتقال، وفقًا للمؤلف، بين بضعة ميلي ثانية وبضع عشرات من الميلي ثانية، مع تباينات كبيرة حسب المعالج والذاكرة المتاحة. يظل هذا الحجم متواضعًا جدًا لاستخلاص نتيجة إنتاجية.
للإجابة على هذا السؤال، يعتمد الدليل على دراسة نشرتها Tiger Data. تدرس الدراسة 50 مليونًا من embeddings من Cohere بأبعاد 768، تم اختبارها على أجهزة AWS من نوع r6id.4xlarge (16 vCPU، 128 جيجابايت ذاكرة وصول عشوائي)، باستخدام نسخة معدلة من أداة ANN-Benchmarks. يسلط الدليل الضوء على نقطة مهمة: تم إجراء الاختبار باستخدام pgvector مقترنًا بـ pgvectorscale، وهو امتداد من Timescale يضيف نوعًا آخر من الفهرس، StreamingDiskANN، وليس باستخدام pgvector وحده.
وفقًا لهذه النتائج، عند نسبة استرجاع 99%، حقق PostgreSQL مع pgvectorscale 471.57 طلبًا في الثانية، مقابل 41.47 لـ Qdrant. كان زمن الانتقال الوسيط متطابقًا تقريبًا، حيث بلغ 31.07 مللي ثانية مقابل 30.75 مللي ثانية. يتميز Qdrant، على العكس، في زمنات الانتقال القصوى: بلغت النسبة المئوية 99 (p99) له 38.71 مللي ثانية، مقابل 74.60 مللي ثانية، وتم بناء فهرسه في 3.3 ساعات، مقابل 11.1 ساعة. بالنسبة للدليل، يظل كلا النظامين تحت 100 مللي ثانية في جميع النسب المئوية المقاسة.
أي خيار حسب عبء العمل
يقدّر الدليل أن pgvector مناسب لحجم يصل إلى حوالي 5 إلى 10 ملايين متجه، مع منافسة متوسطة في الطلبات وعندما يكون الفريق ماهرًا بالفعل في PostgreSQL. كما يسلط الضوء على الاتساق المعاملاتي بين البيانات العلاقية والمتجهات، مما يسمح بتحديث مستند ومتجهه في نفس المعاملة.
على العكس، فإن قاعدة البيانات المخصصة مبررة، وفقًا للمقال، لحجم يصل إلى عدة مئات الملايين أو عدة مليارات من المتجهات، أو لقيود صارمة على زمن الانتقال القصوى أثناء عمليات البحث المرشحة عالية الحمل، وهو المجال الذي يتمتع فيه Qdrant بالميزة المقاسة. يُذكر Milvus للتسريع بالفهرس باستخدام وحدات معالجة الرسومات، وPinecone لخدمة مُدارة بالكامل دون حاجة لإدارة داخلية.
