🚀 جرب Zilliz Cloud، الـ Milvus المدارة بالكامل، مجاناً — تجربة أداء أسرع بـ 10 أضعاف! جرب الآن>>

milvus-logo
LFAI

البنية الشاملة

  • Scenarios
July 29, 2021
milvus

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

شركة Vipshop هي شركة رائدة في مجال البيع بالتجزئة للعلامات التجارية عبر الإنترنت للعلامات التجارية في الصين. تقدم الشركة منتجات عالية الجودة وذات علامات تجارية شهيرة للمستهلكين في جميع أنحاء الصين بخصم كبير عن أسعار التجزئة. ولتحسين تجربة التسوق لعملائها، قررت الشركة بناء نظام توصية بحث مخصص يعتمد على الكلمات الرئيسية لاستعلام المستخدم وصور المستخدم.

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

البيانات مثل معلومات المنتج ونية بحث المستخدم وتفضيلاته كلها بيانات غير منظمة. لقد حاولنا حساب تشابه هذه البيانات باستخدام CosineSimilarity(7.x) من محرك البحث Elasticsearch (ES)، ولكن هذا النهج له العيوب التالية

  • وقت الاستجابة الحسابي الطويل - يبلغ متوسط زمن الاستجابة الحسابية لاسترداد نتائج TopK من ملايين العناصر حوالي 300 مللي ثانية.

  • تكلفة الصيانة العالية لفهارس ES - يتم استخدام نفس مجموعة الفهارس لكل من ناقلات ميزات السلع والبيانات الأخرى ذات الصلة، مما يسهل بالكاد بناء الفهرس، ولكنه ينتج عنه كمية هائلة من البيانات.

لقد حاولنا تطوير مكون التجزئة الإضافي الحساس محليًا الخاص بنا لتسريع حساب CosineSimilarity لـ ES. على الرغم من تحسن الأداء والإنتاجية بشكل كبير بعد التسريع، إلا أن زمن الاستجابة الذي يزيد عن 100 مللي ثانية كان لا يزال من الصعب تلبية متطلبات استرجاع المنتجات الفعلية عبر الإنترنت.

بعد إجراء بحث شامل، قررنا استخدام Milvus، وهي قاعدة بيانات متجهة مفتوحة المصدر، والتي تتميز بدعم النشر الموزع، وحزم SDK متعددة اللغات، وفصل القراءة/الكتابة، وما إلى ذلك، مقارنةً بـ Faiss المستقل شائع الاستخدام.

باستخدام نماذج مختلفة للتعلم العميق، نقوم بتحويل البيانات الضخمة غير المهيكلة إلى متجهات مميزة، واستيراد المتجهات إلى Milvus. وبفضل الأداء الممتاز لـ Milvus، يمكن لنظام توصيات البحث في التجارة الإلكترونية الخاص بنا الاستعلام بكفاءة عن متجهات TopK المشابهة للمتجهات المستهدفة.

البنية الشاملة

![الهندسة المعمارية] (https://assets.zilliz.com/1_01551e7b2b.jpg "الهندسة المعمارية.) كما هو موضح في الرسم التخطيطي، تتكون البنية الكلية للنظام من جزأين رئيسيين.

  • عملية الكتابة: يتم تطبيع ناقلات سمات العنصر (المشار إليها فيما يلي باسم ناقلات العناصر) التي تم إنشاؤها بواسطة نموذج التعلم العميق وكتابتها في MySQL. ثم تقوم MySQL بقراءة متجهات سمات العناصر المعالجة باستخدام أداة مزامنة البيانات (ETL) واستيرادها إلى قاعدة بيانات المتجهات Milvus.

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

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

تقوم عقد الكتابة في Milvus بتنفيذ جميع عمليات الكتابة، بما في ذلك إنشاء مجموعات البيانات، وبناء الفهارس، وإدراج المتجهات، وما إلى ذلك، وتقديم الخدمات للجمهور بأسماء نطاقات الكتابة. تقوم عقد القراءة Milvus بتنفيذ جميع عمليات القراءة وتقدم خدمات للجمهور بأسماء نطاقات للقراءة فقط.

في حين أن الإصدار الحالي من Milvus لا يدعم تبديل الأسماء المستعارة للمجموعات، فإننا نقدم Redis لتبديل الأسماء المستعارة بسلاسة بين مجموعات بيانات متعددة كاملة.

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

تفاصيل التنفيذ

تحديث البيانات

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

  1. لنفترض أنه قبل بناء البيانات بالكامل، توفر المجموعة أ خدمة البيانات للجمهور، ويتم توجيه البيانات المستخدمة بالكامل إلى المجموعة أ (redis key1 = CollectionA). الغرض من بناء كامل البيانات هو إنشاء مجموعة جديدة CollectionB.

  2. التحقق من بيانات السلع - التحقق من رقم الصنف لبيانات السلع في جدول MySQL، ومقارنة بيانات السلع بالبيانات الموجودة في المجموعةA. يمكن تعيين التنبيه وفقًا للكمية أو النسبة المئوية. إذا لم يتم الوصول إلى الكمية المحددة (النسبة المئوية)، لن يتم بناء البيانات بالكامل، وسيتم اعتبار ذلك بمثابة فشل عملية البناء هذه، مما يؤدي إلى إطلاق التنبيه؛ بمجرد الوصول إلى الكمية المحددة (النسبة المئوية)، تبدأ عملية بناء البيانات بالكامل.

  3. ابدأ بناء البيانات بالكامل - قم بتهيئة الاسم المستعار للبيانات التي يتم بناؤها بالكامل، وقم بتحديث Redis. بعد التحديث، يتم توجيه الاسم المستعار لكامل البيانات الجاري بناؤها إلى المجموعة ب (redis key2 = CollectionB).

  4. إنشاء مجموعة كاملة جديدة - تحديد ما إذا كانت المجموعة ب موجودة. إذا كانت موجودة، فاحذفها قبل إنشاء مجموعة جديدة.

  5. كتابة البيانات على دفعات - احسب معرّف القسم لكل بيانات سلعة بمعرفها الخاص باستخدام عملية التعديل، واكتب البيانات إلى أقسام متعددة إلى المجموعة المنشأة حديثًا على دفعات.

  6. إنشاء فهرس وتحميله مسبقًا - إنشاء فهرس (createIndex()) للمجموعة الجديدة. يتم تخزين ملف الفهرس في خادم التخزين الموزع GlusterFS. يقوم النظام تلقائيًا بمحاكاة الاستعلام على المجموعة الجديدة وتحميل الفهرس مسبقًا لإحماء الاستعلام.

  7. التحقق من بيانات المجموعة - التحقق من رقم عنصر البيانات في المجموعة الجديدة، ومقارنة البيانات مع المجموعة الحالية، وتعيين الإنذارات بناءً على الكمية والنسبة المئوية. إذا لم يتم الوصول إلى الرقم المحدد (النسبة المئوية)، فلن يتم تبديل المجموعة وستعتبر عملية البناء فاشلة، مما يؤدي إلى إطلاق الإنذار.

  8. تبديل المجموعة - التحكم في الاسم المستعار. بعد تحديث ريديس، يتم توجيه الاسم المستعار للبيانات المستخدمة بالكامل إلى المجموعة ب (redis key1 = CollectionB)، ويتم حذف مفتاح ريديس الأصلي2، وتكتمل عملية البناء.

استدعاء البيانات

يتم استدعاء بيانات قسم ميلفوس عدة مرات لحساب التشابه بين متجهات المستخدم، التي تم الحصول عليها بناءً على الكلمات الرئيسية لاستعلام المستخدم وصورة المستخدم، ومتجه العنصر، ويتم إرجاع متجهات العناصر TopK بعد الدمج. مخطط سير العمل الكلي كما يلي: workflowسير العمل يسرد الجدول التالي الخدمات الرئيسية المشاركة في هذه العملية. يمكن ملاحظة أن متوسط زمن الاستجابة لاستدعاء متجهات TopK يبلغ حوالي 30 مللي ثانية.

الخدمةالدورمعلمات الإدخالمعلمات الإخراجزمن الاستجابة
الحصول على متجهات المستخدمالحصول على متجه المستخدممعلومات المستخدم + الاستعلاممتجه المستخدم10 مللي ثانية
بحث ميلفوسحساب تشابه المتجه وإرجاع نتائج TopKمتجه المستخدممتجه العنصر10 مللي ثانية
منطق الجدولةاستدعاء النتائج المتزامنة ودمجهامتجهات العناصر المسترجعة متعددة القنوات ودرجة التشابهأعلىK العناصر10 مللي ثانية

عملية التنفيذ:

  1. بناءً على الكلمات الرئيسية لاستعلام المستخدم وصورة المستخدم، يتم حساب متجه المستخدم بواسطة نموذج التعلم العميق.
  2. الحصول على الاسم المستعار للمجموعة لكامل البيانات المستخدمة من Redis currentInUseKeyKeyRef والحصول على اسم المجموعة Milvus CollectionName. هذه العملية هي خدمة مزامنة البيانات، أي تبديل الاسم المستعار إلى Redis بعد تحديث البيانات بالكامل.
  3. يتم استدعاء Milvus بشكل متزامن وغير متزامن مع متجه المستخدم للحصول على البيانات من أقسام مختلفة من نفس المجموعة، ويحسب Milvus التشابه بين متجه المستخدم ومتجه العنصر، ويُرجع أفضل عدد من متجهات العناصر المتشابهة في كل قسم.
  4. دمج متجهات العناصر TopK التي تم إرجاعها من كل قسم، وترتيب النتائج بالترتيب العكسي لمسافة التشابه، والتي يتم حسابها باستخدام الضرب الداخلي ل IP (كلما زادت المسافة بين المتجهات، كلما كانت أكثر تشابهًا). يتم إرجاع متجهات العناصر النهائية TopK.

استشراف المستقبل

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

ستلعب Milvus دورًا حاسمًا كبرنامج وسيط لمزيد من السيناريوهات، بما في ذلك استدعاء البحث في الموقع الرئيسي وتوصيات جميع السيناريوهات.

فيما يلي أهم ثلاث ميزات متوقعة من ميلفوس في المستقبل

  • منطق تبديل الأسماء المستعارة للمجموعات - تنسيق التبديل عبر المجموعات بدون مكونات خارجية.
  • آلية التصفية - يدعم Milvus v0.11.0 الإصدار 0.11.0 آلية تصفية ES DSL فقط في الإصدار المستقل. يدعم الإصدار Milvus 2.0 الذي تم إصداره حديثًا التصفية العددية وفصل القراءة/الكتابة.
  • دعم التخزين لنظام ملفات Hadoop الموزعة (HDFS) - يدعم الإصدار Milvus v0.10.6 الذي نستخدمه واجهة ملفات POSIX فقط، وقد نشرنا GlusterFS مع دعم FUSE كواجهة تخزين خلفية. ومع ذلك، فإن HDFS هو الخيار الأفضل من حيث الأداء وسهولة التوسع.

الدروس المستفادة وأفضل الممارسات

  1. بالنسبة للتطبيقات التي تكون فيها عمليات القراءة هي التركيز الأساسي، يمكن أن يؤدي نشر فصل القراءة عن الكتابة إلى زيادة قوة المعالجة وتحسين الأداء بشكل كبير.
  2. يفتقر عميل Milvus Java إلى آلية إعادة الاتصال لأن عميل Milvus الذي تستخدمه خدمة الاستدعاء مقيم في الذاكرة. يتعين علينا بناء تجمع الاتصال الخاص بنا لضمان توافر الاتصال بين عميل جافا والخادم من خلال اختبار نبضات القلب.
  3. تحدث استعلامات بطيئة في بعض الأحيان على Milvus. ويرجع ذلك إلى عدم كفاية إحماء المجموعة الجديدة. من خلال محاكاة الاستعلام على المجموعة الجديدة، يتم تحميل ملف الفهرس في الذاكرة لتحقيق إحماء الفهرس.
  4. nlist هي معلمة بناء الفهرس و nprobe هي معلمة الاستعلام. تحتاج إلى الحصول على قيمة عتبة معقولة وفقًا لسيناريو عملك من خلال تجارب اختبار الضغط لتحقيق التوازن بين أداء الاسترجاع والدقة.
  5. بالنسبة لسيناريو البيانات الثابتة، يكون من الأكثر كفاءة استيراد جميع البيانات إلى المجموعة أولاً وبناء الفهارس لاحقًا.

Try Managed Milvus for Free

Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.

Get Started

Like the article? Spread the word

استمر في القراءة