اختيار قاعدة بيانات المتجهات للبحث عن الشبكة العنكبوتية في Reddit

كتب هذا المنشور كريس فورني، مهندس البرمجيات في ريديت، ونُشر في الأصل على موقع ريديت، ويُعاد نشره هنا بإذن.

في عام 2024، استخدمت فرق ريديت مجموعة متنوعة من الحلول لإجراء بحث متجه الجار الأقرب التقريبي (ANN). بدءًا من Vertex AI Vector Search من Google وتجربة استخدام بحث متجه ANN في أباتشي سولر (Apache Solr ) في بعض مجموعات البيانات الأكبر حجمًا، إلى مكتبة FAISS من فيسبوك لمجموعات البيانات الأصغر (المستضافة في سيارات جانبية متدرجة رأسيًا). أراد المزيد والمزيد من الفرق في Reddit حلاً مدعومًا على نطاق واسع للبحث عن متجهات ANN يكون فعالاً من حيث التكلفة، ويتمتع بميزات البحث التي يرغبون فيها، ويمكنه التوسع في بيانات بحجم Reddit. لتلبية هذه الحاجة، بحثنا في عام 2025 عن قاعدة بيانات المتجهات المثالية لفرق Reddit.

يصف هذا المنشور العملية التي استخدمناها لاختيار أفضل قاعدة بيانات متجهة لاحتياجات Reddit اليوم. وهو لا يصف أفضل قاعدة بيانات متجهات بشكل عام، ولا مجموعة المتطلبات الوظيفية وغير الوظيفية الأكثر أهمية لجميع الحالات. إنه يصف ما قدّره ريديت وثقافته الهندسية وأعطاه الأولوية عند اختيار قاعدة بيانات المتجهات. قد يكون هذا المنشور بمثابة مصدر إلهام لجمع المتطلبات الخاصة بك وتقييمها، ولكن لكل مؤسسة ثقافتها وقيمها واحتياجاتها الخاصة.

عملية التقييم

بشكل عام، كانت خطوات الاختيار هي

1. جمع السياق من الفرق

2. التقييم النوعي للحلول

3. التقييم الكمي لأفضل المتنافسين

4. الاختيار النهائي

1. جمع السياق من الفرق

تم جمع ثلاثة أجزاء من السياق من الفرق المهتمة بإجراء بحث متجه الشبكة النانوية الاصطناعية:

• المتطلبات الوظيفية (على سبيل المثال، البحث المتجه الهجين والبحث المعجمي؟ استعلامات بحث النطاق؟ التصفية حسب السمات غير المتجهة؟)

• المتطلبات غير الوظيفية (على سبيل المثال، هل يمكن أن يدعم متجهات 1B؟ هل يمكن أن يصل زمن الوصول إلى أقل من 100 مللي ثانية من زمن الاستجابة P99؟)

• كانت فرق قواعد بيانات المتجهات مهتمة بالفعل

إجراء مقابلات مع الفرق لمعرفة المتطلبات ليس بالأمر الهيّن. سيصف الكثيرون احتياجاتهم من حيث كيفية حلهم للمشكلة حاليًا، والتحدي الذي يواجهك هو فهم هذا التحيز وإزالته.

على سبيل المثال، كان أحد الفرق يستخدم بالفعل FAISS للبحث عن ناقلات الشبكة الوسيطة وذكر أن الحل الجديد يجب أن يُرجع 10 آلاف نتيجة بكفاءة لكل استدعاء بحث. بعد مزيد من المناقشة، كان السبب في الحصول على 10 آلاف نتيجة هو أنهم كانوا بحاجة إلى إجراء تصفية لاحقة، ولا يوفر FAISS تصفية نتائج الشبكة العصبية الاصطناعية في وقت الاستعلام. كانت مشكلتهم الفعلية هي أنهم كانوا بحاجة إلى التصفية، لذا فإن أي حل يوفر تصفية فعالة سيكون كافياً، وكان إرجاع 10 آلاف نتيجة مجرد حل بديل مطلوب لتحسين عملية التذكر. كانوا يرغبون بشكل مثالي في التصفية المسبقة للمجموعة بأكملها قبل العثور على أقرب الجيران.

كما كان طلب قواعد بيانات المتجهات التي تستخدمها الفرق بالفعل أو مهتمة بها أمراً قيماً أيضاً. إذا كان لدى فريق واحد على الأقل وجهة نظر إيجابية عن الحل الحالي، فهذه علامة على أن قاعدة بيانات المتجهات يمكن أن تكون حلاً مفيداً يمكن مشاركته عبر الشركة بأكملها. إذا كان لدى الفرق وجهات نظر سلبية فقط عن الحل، فلا ينبغي أن ندرجه كخيار. كما أن قبول الحلول التي كانت الفرق مهتمة بها كان أيضًا وسيلة للتأكد من أن الفرق شعرت بأنها مشمولة في العملية وساعدنا في تشكيل قائمة أولية من المتنافسين الرئيسيين لتقييمها؛ فهناك الكثير من حلول البحث عن المتجهات في قواعد البيانات الجديدة والحالية في قواعد البيانات الجديدة والحالية بحيث لا يمكن اختبارها جميعًا بشكل شامل.

2. التقييم النوعي للحلول

بدءًا من قائمة الحلول التي كانت الفرق مهتمة بها، ولإجراء تقييم نوعي لحلول البحث عن متجهات الشبكة العصبية الاصطناعية التي تناسب احتياجاتنا بشكل أفضل، قمنا

• بحثنا في كل حل وقمنا بتسجيل مدى استيفائه لكل متطلب مقابل الأهمية المرجحة لذلك المتطلب

• إزالة الحلول بناءً على المعايير النوعية والمناقشة

• اخترنا أفضل الحلول N لاختبارها كميًا

تضمنت قائمتنا الأولية لحلول البحث عن متجهات الشبكة العصبية الاصطناعية ما يلي:

• ميلفوس

• Qdrant

• ويفييت

• البحث المفتوح

• Pgvector (يستخدم بالفعل Postgres كنظام إدارة محتوى رقمي RDBMS)

• ريديس (مستخدم بالفعل كمخزن KV وذاكرة تخزين مؤقت)

• كاساندرا (يستخدم بالفعل للبحث غير الشبكي)

• Solr (يُستخدم بالفعل في البحث المعجمي وجرّب البحث المتجه)

• فيسبا

• بينيكون

• Vertex AI (مستخدمة بالفعل للبحث عن متجهات الشبكة العصبية الاصطناعية)

ثم أخذنا بعد ذلك كل المتطلبات الوظيفية وغير الوظيفية التي ذكرتها الفرق، بالإضافة إلى بعض القيود الأخرى التي تمثل قيمنا وأهدافنا الهندسية، وقمنا بوضع هذه الصفوف في جدول بيانات، وقمنا بتقييم مدى أهميتها (من 1 إلى 3؛ كما هو موضح في الجدول المختصر أدناه).

بالنسبة لكل حل كنا نقارنه، قمنا بتقييم (على مقياس من 0 إلى 3) مدى تلبية كل نظام لهذا المطلب (كما هو موضح في الجدول أدناه). كان التقييم بهذه الطريقة غير موضوعي إلى حد ما، لذلك اخترنا نظامًا واحدًا وأعطينا أمثلة على الدرجات مع مبررات مكتوبة وجعلنا المراجعين يرجعون إلى تلك الأمثلة. قدمنا أيضًا الإرشادات التالية لتعيين قيمة كل درجة: قم بتعيين هذه القيمة إذا:

• 0: لا يوجد دعم/دليل على دعم المتطلبات

• 1: دعم أساسي أو غير كافٍ للمتطلبات.

• 2: دعم المتطلبات بشكل معقول

• 3: دعم المتطلبات القوي الذي يتجاوز الحلول المماثلة

ثم أنشأنا بعد ذلك درجة إجمالية لكل حل من خلال أخذ مجموع حاصل ضرب درجة دعم المتطلبات الخاصة بالحل وأهمية ذلك المتطلب (على سبيل المثال، حصل Qdrant على 3 درجات لإعادة الترتيب/التصنيف، والتي لها أهمية 2، لذا 3 × 2 = 6، كرر ذلك لجميع الصفوف وجمعها معًا). في النهاية، يكون لدينا نتيجة إجمالية يمكن استخدامها كأساس لترتيب الحلول ومناقشتها، وأي المتطلبات أكثر أهمية (لاحظ أن النتيجة لا تُستخدم لاتخاذ قرار نهائي ولكن كأداة للمناقشة).

ملاحظة المحرر: استندت هذه المراجعة إلى Milvus 2.4. لقد قمنا منذ ذلك الحين بطرح Milvus 2.5 و Milvus 2.6 و Milvus 3.0 على الأبواب، لذا قد تكون بعض الأرقام قديمة. ومع ذلك، لا تزال المقارنة تقدم رؤى قوية وتظل مفيدة للغاية.

الفئة	الأهمية	كيودرانت	ميلفوس (2.4)	كاساندرا	ويفييت	سولر	فيرتكس للذكاء الاصطناعي
نوع البحث
بحث هجين	1	3	2	0	2	2	2
البحث عن الكلمات المفتاحية	1	2	2	2	2	3	1
بحث تقريبي في الشبكة العصبية	3	3	3	2	2	2	2
بحث المدى	1	3	3	2	2	0	0
إعادة الترتيب/الجمع بين النتائج	2	3	2	0	2	2	1
طريقة الفهرسة
HNSW	3	3	3	2	2	2	0
يدعم طرق الفهرسة المتعددة	3	0	3	1	2	1	1
التحويل الكمي	1	3	3	0	3	0	0
التجزئة الحساسة للموقع (LSH)	1	0	0ملاحظة: يدعمها Milvus 2.6.	0	0	0	0
البيانات
أنواع المتجهات غير العائمة	1	2	2	0	2	2	0
سمات البيانات الوصفية على المتجهات (تدعم سمات متعددة، وحجم سجل كبير، إلخ)	3	3	2	2	2	2	1
خيارات تصفية البيانات الوصفية (يمكن التصفية على البيانات الوصفية، ولها تصفية قبل/بعد التصفية)	2	3	2	2	2	3	2
أنواع بيانات سمة البيانات الوصفية (مخطط قوي، مثل bool، int، سلسلة، json، مصفوفات)	1	3	3	2	2	3	1
حدود سمات البيانات الوصفية (استعلامات النطاق، على سبيل المثال 10 < س < 15)	1	3	3	2	2	2	1
تنوع النتائج حسب السمة (على سبيل المثال الحصول على ما لا يزيد عن N نتائج من كل موقع فرعي في الرد)	1	2	1	2	3	3	0
المقياس
مؤشر متجه مئات الملايين	3	2	3		1	2	3
مؤشر متجه المليار	1	2	2		1	2	2
متجهات الدعم 2k على الأقل	2	2	2	2	2	1	1
متجهات الدعم أكبر من 2 ك	2	2	2	2	1	1	1
زمن انتقال P95 من 50 إلى 100 مللي ثانية في الثانية X QPS	3	2	2	2	1	1	2
زمن انتقال P99 <= 10 مللي ثانية عند X QPS	3	2	2	2	3	1	2
99.9% استرجاع التوفر 99.9%	2	2	2	3	2	2	2
توفر الفهرسة/التخزين بنسبة 99.99%	2	1	1	3	2	2	2
عمليات التخزين
قابلة للاستضافة في AWS	3	2	2	2	2	3	0
متعدد المناطق	1	1	2	3	1	2	2
ترقيات وقت التعطيل الصفري	1	2	2	3	2	2	1
متعدد السحابة	1	3	3	3	2	2	0
واجهات برمجة التطبيقات/المكتبات
gRPC	2	2	2	2	2	0	2
واجهة برمجة تطبيقات RESTful	1	3	2	2	2	1	2
الذهاب للمكتبة	3	2	2	2	2	1	2
مكتبة جافا	2	2	2	2	2	2	2
بايثون	2	2	2	2	2	2	2
لغات أخرى (C++، روبي، إلخ)	1	2	2	3	2	2	2
عمليات وقت التشغيل
مقاييس بروميثيوس	3	2	2	2	3	2	0
عمليات قاعدة البيانات الأساسية	3	2	2	2	2	2	2
إدراج	2	2	2	2	1	2	2
مشغل Kubernetes	2	2	2	2	2	2	0
ترقيم الصفحات للنتائج	2	2	2	2	2	2	0
تضمين البحث عن طريق المعرف	2	2	2	2	2	2	2
إرجاع التضمينات مع معرف المرشح ودرجات المرشح	1	3	2	2	2	2	2
المعرف المقدم من المستخدم	2	2	2	2	2	2	2
القدرة على البحث في سياق دفعي واسع النطاق	1	2	1	1	2	1	2
النسخ الاحتياطية / اللقطات: يدعم إمكانية إنشاء نسخ احتياطية لقاعدة البيانات بأكملها	1	2	2	2	3	3	2
دعم الفهرس الكبير الفعال (التمييز بين التخزين البارد والساخن)	1	3	2	2	2	1	2
الدعم/المجتمع
حياد البائعين	3	3	2	3	2	3	0
دعم قوي لواجهة برمجة التطبيقات	3	3	3	2	2	2	2
دعم البائعين	2	2	2	2	2	2	0
سرعة المجتمع	2	3	2	2	2	2	0
قاعدة مستخدمي الإنتاج	2	3	3	2	2	1	2
شعور المجتمع	1	3	2	2	2	2	1
نجوم جيثب	1	2	2	2	2	2	0
التكوين
التعامل مع الأسرار	2	2	2	2	1	2	2
المصدر
المصدر المفتوح	3	3	3	3	2	3	0
اللغة	2	3	3	2	3	2	0
الإصدارات	2	3	3	2	2	2	2
اختبار المنبع	1	2	3	3	2	2	2
توافر الوثائق	3	3	3	2	1	2	1
التكلفة
فعالة من حيث التكلفة	2	2	2	2	2	2	1
الأداء
دعم ضبط استخدام الموارد لوحدة المعالجة المركزية والذاكرة والقرص	3	2	2	2	2	2	2
التجزئة متعددة العُقد (الحجرة)	3	2	2	3	2	2	2
امتلاك القدرة على ضبط النظام لتحقيق التوازن بين زمن الاستجابة والإنتاجية	2	2	2	3	2	2	2
التقسيم المحدد من قبل المستخدم (الكتابة)	1	3	2	3	1	2	0
متعدد المستأجرين	1	3	2	1	3	2	2
التقسيم	2	2	2	3	2	2	2
النسخ المتماثل	2	2	2	3	2	2	2
التكرار	1	2	2	3	2	2	2
التجاوز التلقائي للفشل التلقائي	3	2	0 ملاحظة: يدعمه Milvus 2.6.	3	2	2	2
موازنة التحميل	2	2	2	3	2	2	2
دعم وحدة معالجة الرسومات	1	0	2	0	0	0	0
		كدرانت	ميلفوس	كاساندرا	ويفييت	سولر	فيرتكس للذكاء الاصطناعي
النتائج الإجمالية للحلول		292	281	264	250	242	173

ناقشنا الدرجات الإجمالية والمتطلبات لمختلف الأنظمة، وسعينا إلى فهم ما إذا كنا قد قمنا بترجيح أهمية المتطلبات بشكل مناسب، وما إذا كانت بعض المتطلبات مهمة للغاية بحيث يجب اعتبارها قيودًا أساسية. كان أحد هذه المتطلبات التي حددناها هو ما إذا كان الحل مفتوح المصدر أم لا، لأننا كنا نرغب في حل يمكننا المشاركة فيه والمساهمة فيه وإصلاح المشاكل الصغيرة بسرعة إذا واجهنا مشاكل صغيرة على نطاقنا. المساهمة في البرمجيات مفتوحة المصدر واستخدامها جزء مهم من ثقافة Reddit الهندسية. وقد أدى ذلك إلى استبعاد الحلول المستضافة فقط (Vertex AI وPinecone) من حساباتنا.

خلال المناقشات، وجدنا أن بعض المتطلبات الرئيسية الأخرى كانت ذات أهمية كبيرة بالنسبة لنا:

• النطاق والموثوقية: أردنا أن نرى دليلاً على وجود شركات أخرى تدير الحل مع أكثر من 100 مليون أو حتى 1 مليار ناقل

• المجتمع: أردنا حلاً يتمتع بمجتمع سليم يتمتع بزخم كبير في هذا المجال سريع النضج

• أنواع معبرة من البيانات الوصفية والتصفية لتمكين المزيد من حالات الاستخدام لدينا (التصفية حسب التاريخ أو حسب المنطقية أو غيرها)

• دعم أنواع متعددة من الفهارس (وليس فقط HNSW أو DiskANN) لتناسب الأداء بشكل أفضل للعديد من حالات الاستخدام الفريدة لدينا

قادتنا نتيجة مناقشاتنا وصقلنا للمتطلبات الرئيسية إلى اختيار الاختبار (بالترتيب) الكمي

1. Qdrant

2. ميلفوس

3. فيسبا، و

4. ويفييت

لسوء الحظ، مثل هذه القرارات تستغرق وقتًا وموارد، ولا توجد منظمة لديها كميات غير محدودة من أي منهما. بالنظر إلى ميزانيتنا، قررنا اختبار Qdrant و Milvus، وتركنا اختبار Vespa و Weviate كأهداف ممتدة.

كما كان اختبار Qdrant مقابل Milvus اختبارًا مثيرًا للاهتمام بين بنيتين مختلفتين:

• Qdrant أنواع العقد المتجانسة التي تؤدي جميع عمليات قاعدة بيانات ناقلات الشبكة الوطنية المتجهة

• ميلفوس: أنواع عقد غير متجانسة (ميلفوس؛ واحدة للاستعلامات، وأخرى للفهرسة، وأخرى لاستيعاب البيانات، ووكيل، إلخ).

أيهما كان سهل الإعداد (اختبار لوثائقهما)؟ أيهما كان من السهل تشغيله (اختبار لميزات المرونة والصقل الخاصة بهم)؟ وأيهما أفضل أداء لحالات الاستخدام والحجم الذي يهمنا؟ هذه الأسئلة التي سعينا للإجابة عليها أثناء المقارنة الكمية بين الحلول.

3. التقييم الكمي لأفضل المتنافسين

أردنا أن نفهم بشكل أفضل مدى قابلية كل حل للتطوير، وفي هذه العملية، اختبرنا كيف سيكون إعداد كل حل وتكوينه وصيانته وتشغيله على نطاق واسع. للقيام بذلك، قمنا بجمع ثلاث مجموعات بيانات من متجهات المستندات والاستعلامات لثلاث حالات استخدام مختلفة، وقمنا بإعداد كل حل بموارد مماثلة داخل Kubernetes، وقمنا بتحميل المستندات في كل حل، وأرسلنا أحمال استعلام متطابقة باستخدام K6 من Grafana مع منفذ معدل وصول متزايد لتسخين الأنظمة قبل الوصول إلى الإنتاجية المستهدفة (على سبيل المثال، 100 QPS).

لقد اختبرنا الإنتاجية، ونقطة الانهيار لكل حل، والعلاقة بين الإنتاجية وزمن الوصول، وكيفية تفاعلها مع فقدان العُقد تحت الحمل (معدل الخطأ، وتأثير زمن الوصول، وما إلى ذلك). كان تأثير التصفية على زمن الكمون من أهم الأمور التي أثارت اهتمامنا. كان لدينا أيضًا اختبارات بسيطة بنعم/لا للتحقق من أن الإمكانية في الوثائق تعمل كما هو موصوف (على سبيل المثال، عمليات الإدراج والحذف والحصول على حسب المعرف وإدارة المستخدم، إلخ) ولتجربة بيئة العمل الخاصة بواجهات برمجة التطبيقات هذه.

تم إجراء الاختبار على Milvus v2.4 و Qdrant v1.12. ونظراً لضيق الوقت، لم نقم بضبط أو اختبار جميع أنواع إعدادات الفهرس بشكل شامل؛ تم استخدام إعدادات مماثلة مع كل حل، مع التحيز نحو استدعاء ANN عالٍ، وركزت الاختبارات على أداء فهارس HNSW. كما تم إعطاء موارد وحدة معالجة مركزية وذاكرة مماثلة لكل حل.

في تجاربنا، وجدنا بعض الاختلافات المثيرة للاهتمام بين الحلين. في التجارب التالية، كان لكل حل ما يقرب من 340 مليون متجه من متجهات رديت البريدية ذات 384 بُعدًا لكل منها، بالنسبة لـ HNSW، M=16، و efConstruction=100.

في إحدى التجارب، وجدنا أنه بالنسبة لنفس معدل إنتاجية الاستعلام (100 كيو بي إس مع عدم وجود استيعاب في نفس الوقت)، أثرت إضافة التصفية على زمن انتقال ميلفوس أكثر من Qdrant.

نشرات كمون الاستعلام مع التصفية

من ناحية أخرى، وجدنا أن هناك تفاعلاً أكبر بكثير بين الابتلاع وحمل الاستعلام على Qdrant مقارنةً بـ Milvus (كما هو موضح أدناه عند معدل إنتاجية ثابت). ويرجع هذا على الأرجح إلى بنيتها؛ حيث تقسم Milvus الكثير من عمليات الاستيعاب على أنواع عقد منفصلة عن تلك التي تخدم حركة الاستعلام، بينما تخدم Qdrant حركة الاستيعاب والاستعلام من نفس العقد.

نشر كمون الاستعلام بـ 100 QPS أثناء الاستيعاب

عند اختبار تنوع النتائج حسب السمة (على سبيل المثال الحصول على ما لا يزيد عن N من النتائج من كل موقع فرعي في الاستجابة)، وجدنا أنه بالنسبة لنفس الإنتاجية، كان زمن استجابة ميلفوس أسوأ من Qdrant (عند 100 QPS).

كمون ما بعد الاستعلام مع تنوع النتائج

أردنا أيضًا أن نرى مدى فعالية كل حل عند إضافة المزيد من النسخ المتماثلة للبيانات (أي زيادة عامل النسخ المتماثل، RF، من 1 إلى 2). في البداية، بالنظر إلى عامل التردد اللاسلكي = 1، كان Qdrant قادرًا على منحنا زمن استجابة مُرضٍ مقابل إنتاجية أكبر من Milvus (لم تظهر QPS الأعلى لأن الاختبارات لم تكتمل دون أخطاء).

ينشر Qdrant زمن استجابة RF=1 لمعدل كمون متفاوت للإنتاجية المتفاوتة

ينشر Milvus زمن استجابة = 1 لزمن انتقال لمعدل إنتاجية متفاوت

ومع ذلك، عند زيادة عامل النسخ المتماثل، تحسن زمن انتقال Qdrant p99، لكن Milvus كان قادرًا على الحفاظ على إنتاجية أعلى من Qdrant، مع زمن انتقال مقبول (لم يتم عرض Qdrant 400 QPS لأن الاختبار لم يكتمل بسبب زمن الانتقال العالي والأخطاء).

ينشر Milvus زمن استجابة RF=2 لزمن انتقال متفاوت للإنتاجية المتفاوتة

تنشر Qdrant زمن استجابة RF=2 لزمن انتقال متفاوت للإنتاجية المتفاوتة

نظرًا لضيق الوقت، لم يكن لدينا وقت كافٍ لمقارنة استدعاء الشبكة العصبية الاصطناعية بين الحلول على مجموعات البيانات الخاصة بنا، لكننا أخذنا في الاعتبار قياسات استدعاء الشبكة العصبية الاصطناعية للحلول المقدمة من https://ann-benchmarks.com/ على مجموعات البيانات المتاحة للجمهور.

4. الاختيار النهائي

منناحية الأداء، وبدون الكثير من الضبط وباستخدام HNSW فقط، بدا أن Qdrant يتمتع بزمن استجابة خام أفضل من Milvus في العديد من الاختبارات. ومع ذلك، بدا أن Milvus يبدو أنه سيتوسع بشكل أفضل مع زيادة النسخ المتماثل، وكان لديه عزل أفضل بين الاستيعاب وحمل الاستعلام بسبب بنيته متعددة العقد.

من ناحية التشغيل، على الرغم من تعقيد بنية ميلفوس (أنواع متعددة من العقد، والاعتماد على سجل خارجي للكتابة الأمامية مثل كافكا ومخزن بيانات وصفية مثل إلخd)، كان لدينا وقت أسهل في تصحيح أخطاء ميلفوس وإصلاحها مقارنةً ب Qdrant عندما يدخل أي من الحلين في حالة سيئة. يحتوي Milvus أيضًا على إعادة توازن تلقائية عند زيادة عامل النسخ المتماثل للمجموعة، بينما في Qdrant مفتوح المصدر، يلزم إنشاء أو إسقاط الأجزاء يدويًا لزيادة عامل النسخ المتماثل (وهي ميزة كان علينا أن نبنيها بأنفسنا أو نستخدم الإصدار غير مفتوح المصدر).

Milvus هي تقنية "على شكل ريديت" أكثر من Qdrant؛ فهي تشترك في أوجه تشابه أكثر مع بقية مجموعتنا التقنية. كُتبت Milvus بلغة Golang، وهي لغة البرمجة الخلفية المفضلة لدينا، وبالتالي يسهل علينا المساهمة فيها أكثر من Qdrant، المكتوبة بلغة Rust. ويتمتع Milvus بسرعة ممتازة في تنفيذ المشاريع في مشروعه المفتوح المصدر مقارنةً ب Qdrant، كما أنه يلبي المزيد من متطلباتنا الرئيسية.

في النهاية، استوفى كلا الحلين معظم متطلباتنا، وفي بعض الحالات، كان لدى Qdrant ميزة في الأداء، لكننا شعرنا أنه يمكننا توسيع نطاق Milvus بشكل أكبر، وشعرنا براحة أكبر في تشغيله، وكان أفضل تطابقًا لمؤسستنا من Qdrant. كنا نتمنى لو كان لدينا المزيد من الوقت لاختبار Vespa و Weaviate، ولكن ربما تم اختيارهما أيضًا بسبب الملاءمة التنظيمية (كون Vespa يعتمد على Java) والبنية (كون Weaviate من نوع العقدة الواحدة مثل Qdrant).

الوجبات الرئيسية

• تحدي المتطلبات التي يتم إعطاؤك إياها ومحاولة إزالة التحيز للحلول الحالية.

• قيّم الحلول المرشحة واستخدم ذلك لإثراء مناقشة المتطلبات الأساسية، وليس كحل نهائي

• تقييم الحلول من الناحية الكمية، ولكن على طول الطريق، قم بتدوين ما يشبه العمل مع الحل

• اختر الحل الأنسب لمؤسستك من منظور الصيانة والتكلفة وسهولة الاستخدام والأداء، وليس فقط لأن الحل هو الأفضل أداءً.

شكر وتقدير

قام بهذا العمل التقييم بن كوتشي وتشارلز نجوروجي وأميت كومار وأنا. كما نشكر الآخرين الذين ساهموا في هذا العمل، بما في ذلك آني يانغ، وكونراد رايش، وسابرينا كونغ، وأندرو جونسون، على البحث النوعي للحلول.

ملاحظات المحرر

نريد أن نقدم شكرًا حقيقيًا لفريق ريديت الهندسي - ليس فقط لاختيارهم ميلفوس لأعباء عمل البحث المتجه، ولكن أيضًا لتخصيصهم الوقت لنشر مثل هذا التقييم المفصل والعادل. من النادر أن نرى هذا المستوى من الشفافية في كيفية مقارنة الفرق الهندسية الحقيقية لقواعد البيانات، وستكون كتابتهم مفيدة لأي شخص في مجتمع ميلفوس (وخارجه) يحاول فهم مشهد قواعد البيانات المتجهة المتنامية.

كما ذكر كريس في المنشور، لا توجد قاعدة بيانات متجهة واحدة "أفضل". ما يهم هو ما إذا كان النظام يناسب عبء العمل والقيود والفلسفة التشغيلية. تعكس مقارنة ريديت هذا الواقع جيدًا. لا يتصدر ميلفوس كل فئة، وهذا متوقع تمامًا نظرًا للمفاضلة بين نماذج البيانات المختلفة وأهداف الأداء.

شيء واحد يستحق التوضيح: استخدم تقييم ريديت برنامج Milvus 2.4، والذي كان الإصدار المستقر في ذلك الوقت. بعض الميزات - مثل LSH والعديد من تحسينات الفهرس - إما أنها لم تكن موجودة بعد أو لم تكن ناضجة في الإصدار 2.4، لذا فإن بعض النتائج تعكس بطبيعة الحال ذلك الإصدار الأساسي الأقدم. منذ ذلك الحين، أصدرنا ميلفوس 2.5 ثم ميلفوس 2.6، وهو نظام مختلف تمامًا من حيث الأداء والكفاءة والمرونة. كانت استجابة المجتمع قوية، وقد قامت العديد من الفرق بالترقية بالفعل.

فيما يلي نظرة سريعة على الجديد في الإصدار 2.6 من ميلفوس:

• استخدام أقل للذاكرة بنسبة تصل إلى 72% واستعلامات أسرع 4 مرات مع تكميم RaBitQ 1 بت

• تخفيض التكلفة بنسبة 50% مع التخزين المتدرج الذكي

• بحث في النص الكامل BM25 أسرع 4× 4 مرات مقارنة ب Elasticsearch

• تصفية JSON أسرع 100× أسرع مع فهرس المسار الجديد

• بنية جديدة خالية من الأقراص للبحث الأحدث بتكلفة أقل

• سير عمل أبسط "إدخال البيانات وإخراجها" لتضمين خطوط الأنابيب

• دعم لأكثر من 100 ألف مجموعة للتعامل مع البيئات الكبيرة متعددة المستأجرين

إذا كنت تريد التفاصيل الكاملة، فإليك بعض المتابعات الجيدة:

• مدونة: تقديم ميلفوس 2.6: بحث متجه ميسور التكلفة على نطاق المليار

• ملاحظات إصدار ميلفوس 2.6: ملاحظات الإصدار:

• VDBBench 1.0: المقارنة المعيارية في العالم الحقيقي لقواعد بيانات المتجهات - مدونة ميلفوس

هل لديك أسئلة أو تريد التعمق في أي ميزة؟ انضم إلى قناة Discord الخاصة بنا أو قم بتسجيل المشكلات على GitHub. يمكنك أيضًا حجز جلسة فردية مدتها 20 دقيقة للحصول على رؤى وإرشادات وإجابات لأسئلتك من خلال ساعات عمل Milvus المكتبية.