يقع البحث المتجهي في أساس كثير من ميزات الذكاء الاصطناعي: الاسترجاع في RAG، والتخزين المؤقت الدلالي، وذاكرة الوكلاء. ويأتي Redis 8 بمجموعات المتجهات، وهي نوع بيانات في مرحلة تجريبية، مدمجة في الخادم، لذا فهو المقارنة البديهية. حمّلنا تضمينات OpenAI نفسها في HotKV وفي Redis 8.10.2، وشغّلنا على كل منهما الاستعلامات نفسها وعددها 1,000 بعدد اتصالات متزامنة للعملاء من 1 إلى 100، وقسنا مدى دقة الإجابات، وعدد الاستعلامات التي قدّمها كل محرك في الثانية، والمدة التي استغرقها كل استعلام.
باختصار. على 999,000 متجه، وعند حد أدنى للاستدعاء يبلغ 95%، قدّم HotKV عددًا من الاستعلامات في الثانية يبلغ 1.4 ضعف ما قدّمه Redis مع عميل واحد، و7.9 ضعف مع 100 عميل (51,146 مقابل 6,510). وعند استدعاء 99% كانت النسبتان 1.8 و5.4. وكان وسيط زمن الاستجابة لدى HotKV أقل عند كل عدد من العملاء. استقرت إنتاجية Redis بحلول 32 عميلًا، بينما واصلت إنتاجية HotKV النمو حتى 100. وحمّل HotKV المتجهات أسرع بنحو 5 أضعاف، وكان استدعاؤه أعلى عند كل عمق بحث. هذه مجموعة بيانات واحدة على جهاز واحد، ونسخة HotKV نسخة تطوير لم تُطرح بعد، ولم نقس Redis Query Engine ولا وضعه بدقة 8 بت، لذا اقرأ النتائج بوصفها قياسًا، لا ترتيبًا.
ما الذي اختبرناه
البيانات
أول 999,000 صف من dbpedia-entities-openai-1M من إعداد Kumar Shivendu وNirant Kasliwal (ترخيص MIT)، وبالنسبة إلى الفهرس الأصغر، أول 100,000 صف. الصفوف كيانات من DBpedia ضُمّنت باستخدام OpenAI text-embedding-ada-002، بعدد أبعاد 1,536. وآخر 1,000 صف هي الاستعلامات، فلا يظهر أي صف في المجموعتين معًا. ومفتاح الإجابات هو أقرب 10 جيران فعليًا لكل استعلام، محسوبين بالبحث الشامل (brute force) بأرقام الفاصلة العائمة بدقة 64 بت، بمعزل عن المحركين كليهما، لذا يُقيَّم كلاهما وفق الحقيقة المرجعية نفسها.
المحركات والإعدادات
- المحركات. HotKV عند الإيداع (commit)
c8dafd37(VSIM.CREATEINDEXوVSIM.SETوVSIM.SEARCH)، وهي نسخة تطوير لم تُطرح بعد، جُمِّعت بخيارات الإصدار الافتراضية، لا بـ-march=native. وRedis 8.10.2 مبنيًا من وسم الإصدار الخاص به باستخدامmakeقياسي (VADDوVSIM). ويبني كلاهما رسوم HNSW البيانية. - إعدادات الفهرس. تشابه جيب التمام، وHNSW مع
M=16وef_construction=200في كليهما، مضبوطة صراحةً. وهي أيضًا القيم الافتراضية لكل محرك. - الدقة. متجهات float32 بدقة كاملة في كليهما. يستخدم Redis افتراضيًا التكميم بدقة 8 بت، لذا شُغّل مع
NOQUANT. - الجهاز. جهاز Azure Standard_D160alds_v7 واحد (AMD EPYC 9V45، و160 vCPU). ثُبّت الخادمان كلاهما على وحدات vCPU نفسها وعددها 128، ومولّدات الحمل على الـ32 الأخرى، وكل ذلك عبر واجهة الاسترجاع المحلية (loopback). عمل HotKV بـ 128 خيطًا، وRedis بخيوط I/O الافتراضية لديه. جرّبنا 1 و4 و8 و16 ولم يُحدث هذا الإعداد فرقًا ثابتًا.
- مولّد الحمل. عملية واحدة لكل اتصال عميل، تُبقي كل منها طلبًا واحدًا قيد الانتظار، مع إعداد الطلبات قبل الجزء المؤقَّت. استخدمت أكثر عمليات مولّد الحمل انشغالًا 8% من معالج واحد في أي تشغيل، لذا لم يكن العميل هو ما يفرض الحد في أي وقت.
الإجراء
عند أعماق البحث (ef) البالغة 40 و80 و150 و300، و500 على الفهرس الأكبر، شغّلنا الاستعلامات الـ1,000 مرارًا مع 1 و2 و4 و8 و16 و32 و50 و100 عميل: ثانية واحدة للإحماء، ثم أربع ثوانٍ محسوبة، ثلاث مرات لكلٍّ منها، مع التناوب في ترتيب المحركين. ونعرض الوسيط. وقيس الاستدعاء بشكل منفصل، عبر اتصال واحد. وحُمّل HotKV عبر 32 اتصالًا في كل تشغيل. أما فهارس Redis فبُنيت مرة واحدة، عبر 32 اتصالًا باستخدام VADD ... CAS، ثم حُفظت، وحُمّلت للقياسات. السكربتات وكل تجربة موجودة في مستودع اختبار الأداء.
النتائج
أهداف استدعاء متطابقة
لا يبلغ المحركان الاستدعاء نفسه عند قيمة ef نفسها، لذا نقارن الإنتاجية عند أهداف مشتركة للحد الأدنى من الاستدعاء: لكل هدف، أسرع عمق بحث مقيس يبلغه. الأعماق وقيم الاستدعاء المحققة مذكورة في الجداول، لأنها تختلف قليلًا. ويعتمد هذا على أعماق مقيسة، لا على الاستيفاء. الاستعلامات في الثانية على 999,000 متجه:
| هدف Recall@10 | العملاء | HotKV | Redis 8.10.2 | HotKV مقابل Redis | وسيط زمن الاستجابة |
|---|---|---|---|---|---|
| 95% أو أفضل | 1 | 1,328 (ef 80, 0.970) | 946 (ef 80, 0.962) | 1.40x | 0.77 / 1.07 ms |
| 95% أو أفضل | 8 | 10,342 | 5,531 | 1.87x | 0.79 / 1.43 ms |
| 95% أو أفضل | 16 | 18,500 | 7,265 | 2.55x | 0.87 / 2.15 ms |
| 95% أو أفضل | 50 | 37,508 | 6,825 | 5.50x | 1.33 / 7.17 ms |
| 95% أو أفضل | 100 | 51,146 | 6,510 | 7.86x | 1.91 / 13.49 ms |
| 99% أو أفضل | 1 | 507 (ef 300, 0.993) | 287 (ef 500, 0.994) | 1.77x | 1.99 / 3.31 ms |
| 99% أو أفضل | 16 | 6,961 | 2,322 | 3.00x | 2.30 / 6.70 ms |
| 99% أو أفضل | 50 | 12,393 | 2,483 | 4.99x | 4.02 / 18.91 ms |
| 99% أو أفضل | 100 | 13,843 | 2,583 | 5.36x | 7.11 / 37.65 ms |
وسيط زمن الاستجابة معروض بالصيغة HotKV / Redis. وتكرر النمط نفسه عند هدف 90%: 90,003 مقابل 7,973 استعلامًا في الثانية مع 100 عميل (11.3 ضعف)، وكلاهما عند ef 40.
كل أعماق البحث
| ef | استدعاء HotKV | استدعاء Redis | HotKV، 1 عميل | Redis، 1 عميل | HotKV، 50 عميلًا | Redis، 50 عميلًا | HotKV، 100 عميل | Redis، 100 عميل |
|---|---|---|---|---|---|---|---|---|
| 40 | 0.940 | 0.923 | 2,108 | 1,259 | 63,897 | 8,061 | 90,003 | 7,973 |
| 80 | 0.970 | 0.962 | 1,328 | 946 | 37,508 | 6,825 | 51,146 | 6,510 |
| 150 | 0.987 | 0.980 | 875 | 636 | 21,912 | 5,241 | 26,122 | 4,942 |
| 300 | 0.993 | 0.990 | 507 | 396 | 12,393 | 3,454 | 13,843 | 3,402 |
| 500 | 0.997 | 0.994 | 338 | 287 | 7,688 | 2,483 | 8,843 | 2,583 |
الاستعلامات في الثانية على 999,000 متجه. وعلى 100,000 متجه يتكرر النمط نفسه. عند استدعاء 95% قدّم HotKV عددًا من الاستعلامات في الثانية يبلغ 1.5 ضعف ما قدّمه Redis مع عميل واحد (1,816 مقابل 1,214)، و8.9 ضعف مع 100 عميل (63,247 مقابل 7,119).
ما مقدار الضجيج في هذه الأرقام
كل خلية هي وسيط ثلاث تجارب. في نصف الخلايا كان الفارق بين أدنى تجربة وأعلاها 1.3% من الوسيط أو أقل، وفي تسع من كل عشر خلايا 7% أو أقل، وكان أوسع فارق 26% (Redis، 100,000 متجه، ef 300، 50 عميلًا). ويسرد التقرير كل التجارب.
قيس الاستدعاء مرة واحدة لكل بناء للفهرس. واختلفت ثلاث عمليات بناء مستقلة لكل محرك على 100,000 متجه بما يصل إلى 0.013 عند العمق نفسه، لذا فإن الاستدعاء الأعلى لدى HotKV واضح حتى ef 300، ويقع ضمن التباين بين عمليات البناء عند ef 500 على الفهرس الأصغر.
التحميل والذاكرة
عند التحميل عبر 32 اتصالًا لكل منهما، استغرق HotKV مدة 188 ثانية لتحميل المتجهات الـ999,000 (5,325 في الثانية)، واستغرق Redis مدة 935 ثانية (1,069 في الثانية)، بما في ذلك الوقت الذي قضاه مولّد الحمل في تنسيق كل متجه. وعلى 100,000 متجه كانت المدة 15 ثانية مقابل 57. وكان تحميل Redis أسرع مع CAS منه بدونه في فحص على 20,000 متجه (2,279 مقابل 1,488 متجهًا في الثانية)، لذا استخدمناه. جرى تحميل Redis في خطوة سابقة مع تثبيت Redis على أربع وحدات vCPU بينما كانت فحوصات أخرى تعمل على الجهاز؛ وحمّل HotKV وحده على 128 وحدة vCPU. لذا فإن زمن تحميل Redis حدٌّ أدنى لسرعته وليس مقارنة متكافئة.
بعد تحميل 999,000 متجه، كانت عملية HotKV تشغل 6.77 GB، وكانت عملية Redis تشغل 7.01 GB.
ما الذي يحدّ Redis 8.10.2 هنا
تشغّل مجموعات المتجهات في Redis كل عملية بحث على خيط خاص بها، لكن شيفرة HNSW فيها عدد ثابت من خانات الخيوط (32، يُحدَّد عند تجميع Redis)، وتُضاف المتجهات على الخيط الرئيسي. في تشغيلاتنا، ومن 32 عميلًا فما فوق، أبقى Redis ما بين 6 و30 من وحدات vCPU في الجهاز مشغولة، وكانت إنتاجيته قد استقرت. أما HotKV فأبقى نحو 92 وحدة vCPU مشغولة مع 100 عميل عند ef 80، وكانت إنتاجيته لا تزال تنمو. هذا هو سلوك كل محرك على هذا الجهاز، وليس أمرًا ضبطه اختبار الأداء.
القيود
هذه قياسات أجرتها HotKV Ltd على الإصدارات والتكوين المذكورة أعلاه، وليست ادعاءً بشأن كل عمليات نشر Redis.
إعداد الاختبار
- نسخة تطوير. الإيداع
c8dafd37نسخة تطوير، وليس إصدارًا. - مجموعة بيانات واحدة، جهاز واحد. تضمينات OpenAI بعدد أبعاد 1,536، وأقرب 10 فقط، وfloat32، وجيب التمام. وقد تعطي أبعاد أو بيانات أو عتاد آخر نسبًا مختلفة.
- العميل يتشارك الجهاز. عملت مولّدات الحمل على وحدات vCPU منفصلة، لكنها تشاركت نظام الذاكرة وذاكرة التخزين المؤقت من المستوى الأخير (last-level cache) مع الخوادم.
- الاستمرارية معطّلة. لم يكتب أي من الخادمين لقطات أو ملف إلحاق فقط (append-only file).
ما لم يُقَس
- وضع 8 بت في Redis. يخزّن Redis افتراضيًا متجهات مكمّمة بدقة 8 بت، وهو ما يستهلك ذاكرة أقل. وقد قارنّا float32 بـ float32.
- Redis Query Engine. يقدّم Redis أيضًا بحثًا متجهيًا عبر
FT.CREATEوFT.SEARCH. اختبرنا مجموعات المتجهات فقط، لذا لا تقول النتائج شيئًا عن Query Engine. - تحميل Redis وإعادة تحميله. بُنيت فهارس Redis في تشغيل سابق مع تثبيت Redis على أربع وحدات vCPU، ثم حُفظت وأُعيد تحميلها للقياسات، لذا فإن أزمنة تحميل Redis حدٌّ أدنى ولا تُقارن بشكل متكافئ مع أزمنة HotKV. وكان البحث في فهرس أُعيد تحميله أبطأ بنحو 10 بالمئة من فهرس بُني حديثًا في فحص على 20,000 متجه، لذا قد تكون أرقام استعلامات Redis أدنى بنحو ذلك.
جرّبه بنفسك
البحث المتجهي مدمج في الخادم نفسه الذي يضم الذاكرة المؤقتة للمطالبات في HotKV، وفهرس المتجهات نفسه هو أساس ذاكرته المؤقتة الدلالية وذاكرة الوكلاء. البحث المتجهي متضمَّن في كل خطط HotKV Cloud. أما الذاكرة المؤقتة للمطالبات والذاكرة المؤقتة الدلالية وذاكرة الوكلاء فتأتي مع خطة Performance وما فوقها. ابدأ على HotKV Cloud، أو تواصل مع المبيعات لاختبار أدائه على تضميناتك الخاصة.
تابع النقاش
التعليقات
لديك أسئلة عن المنهجية؟ حصلت على نتيجة مختلفة على عتادك؟ شارك ما توصلت إليه. تُراجَع التعليقات قبل ظهورها.