Home
Blog
كيفية الترقية بأمان من Milvus 2.5.x إلى Milvus 2.6.x

كيفية الترقية بأمان من Milvus 2.5.x إلى Milvus 2.6.x

Tutorials

December 25, 2025

Yiqing Lu

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

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

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

تغييرات البنية من ميلفوس 2.5 إلى ميلفوس 2.6

قبل الغوص في سير عمل الترقية نفسها، دعنا أولاً نفهم كيف تتغير بنية Milvus في Milvus 2.6.

بنية ميلفوس 2.5

Milvus 2.5 Architecture بنية ميلفوس 2.5

في ميلفوس 2.5، كان سير العمل المتدفق والدفعي متشابكًا عبر عقد عاملة متعددة:

عالجتQueryNode كلاً من الاستعلامات التاريخية والاستعلامات الإضافية (المتدفقة).
عالجتDataNode كلاً من تدفق البيانات في وقت الاستيعاب وضغط البيانات التاريخية في الخلفية.

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

بنية ميلفوس 2.6

Milvus 2.6 Architecture بنية ميلفوس 2.6

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

تتعاملQueryNode الآن مع الاستعلامات الدفعية فقط على المقاطع التاريخية.
تتعاملDataNode الآن مع مهام البيانات التاريخية فقط مثل الضغط وبناء الفهرس.

تستوعب StreamingNode جميع المهام المتعلقة بالبث التي كانت مقسمة بين DataNode وQueryNode وحتى الوكيل في Milvus 2.5، مما يضفي وضوحًا ويقلل من مشاركة الحالة بين الأدوار.

Milvus 2.5.x مقابل Milvus 2.6.x: مقارنة بين كل مكون على حدة

	Milvus 2.5.x	ميلفوس 2.6.x	ما الذي تغير
خدمات المنسق	RootCoord / QueryCoord / DataCoord (أو MixCoord)	MixCoord	يتم دمج إدارة البيانات الوصفية وجدولة المهام في MixCoord واحد، مما يبسط منطق التنسيق ويقلل من التعقيد الموزع.
طبقة الوصول	الوكيل	الوكيل	يتم توجيه طلبات الكتابة فقط من خلال عقدة البث لاستيعاب البيانات.
العقد العاملة	-	عقدة التدفق	عقدة معالجة دفق مخصصة مسؤولة عن جميع منطق المعالجة التزايدية (المقاطع المتزايدة)، بما في ذلك: - استيعاب البيانات التزايدية- الاستعلام عن البيانات التزايدية- نقل البيانات التزايدية إلى مخزن الكائنات- الكتابة القائمة على الدفق- استرداد الفشل استنادًا إلى WAL
	عقدة الاستعلام	عقدة الاستعلام	عقدة معالجة الدفعات التي تعالج الاستعلامات على البيانات التاريخية فقط.
	عقدة البيانات	عقدة البيانات	عقدة معالجة الدفعات المسؤولة عن البيانات التاريخية فقط، بما في ذلك الضغط وبناء الفهرس.
	عقدة الفهرس	-	تم دمج عقدة الفهرس في عقدة البيانات، مما يبسط تعريفات الأدوار وطوبولوجيا النشر.

باختصار، يرسم الإصدار Milvus 2.6 خطًا واضحًا بين أعباء العمل المتدفقة والدُفعات؛ مما يزيل التشابك بين المكونات التي شوهدت في الإصدار 2.5 ويخلق بنية أكثر قابلية للتطوير والصيانة.

أبرز ميزات الإصدار 2.6 من ميلفوس

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

تحسينات التكلفة والكفاءة

تكميمRaBitQ للفهارس الأساسية - طريقة تكميم جديدة ذات 1 بت تضغط فهارس المتجهات إلى 1/32 من حجمها الأصلي. وبالاقتران مع إعادة ترتيب SQ8، فإنها تقلل من استخدام الذاكرة إلى 28% تقريبًا، وتعزز QPS بنسبة 4 أضعاف، وتحافظ على نسبة استرجاع تصل إلى 95% تقريبًا، مما يقلل من تكاليف الأجهزة بشكل كبير.
البحث عن النص الكاملالمحسّن BM25 - تسجيل نقاط BM25 الأصلي المدعوم بمتجهات متناثرة ذات وزن مصطلح متناثر. يعمل البحث عن الكلمات الرئيسية بسرعة 3-4 أضعاف (حتى 7 أضعاف في بعض مجموعات البيانات) مقارنةً ب Elasticsearch، مع الحفاظ على حجم الفهرس في حدود ثلث البيانات النصية الأصلية.
فهرسة مسار JSON مع فهرسة JSON Shredding - أصبحت التصفية المهيكلة على JSON المتداخلة أسرع بشكل كبير وأكثر قابلية للتنبؤ. تقلل مسارات JSON المفهرسة مسبقًا من زمن انتقال التصفية من 140 مللي ثانية إلى 1.5 مللي ثانية (P99: 480 مللي ثانية إلى 10 مللي ثانية)، مما يجعل البحث المتجه الهجين + تصفية البيانات الوصفية أكثر استجابة بشكل ملحوظ.
دعم نوع البيانات الموسّع - يضيف أنواع متجهات Int8، وحقول هندسية (POINT / LINESTRING / POLYGON)، وصفيف الهياكل. تدعم هذه الإضافات أعباء العمل الجغرافية المكانية ونمذجة البيانات الوصفية الأكثر ثراءً ومخططات أنظف.
Upsert للتحديثات الجزئية - يمكنك الآن إدراج الكيانات أو تحديثها باستخدام استدعاء مفتاح أساسي واحد. تقوم التحديثات الجزئية بتعديل الحقول المتوفرة فقط، مما يقلل من تضخيم الكتابة ويبسط خطوط الأنابيب التي تقوم بتحديث البيانات الوصفية أو التضمينات بشكل متكرر.

تحسينات البحث والاسترجاع

تحسين معالجة النصوص ودعم متعدد اللغات: تعمل معالجات لينديرا و ICU الرمزية الجديدة على تحسين معالجة النصوص اليابانية والكورية ومتعددة اللغات. يدعم Jieba الآن القواميس المخصصة. run_analyzer يساعد في تصحيح سلوك الترميز، وتضمن المحللات متعددة اللغات إجراء بحث متسق عبر اللغات.
مطابقة نصية عالية الدقة: تفرض مطابقة العبارات استعلامات العبارات المرتبة مع انحدار قابل للتكوين. يعمل فهرس NGRAM الجديد على تسريع الاستعلامات الفرعية و LIKE على كل من حقول VARCHAR ومسارات JSON، مما يتيح مطابقة سريعة للنص الجزئي والمطابقة الضبابية.
إعادة الترتيب الواعية بالوقت والبيانات الوصفية الواعية: يقوم مصنفو التضاؤل (الأسي، الخطي، الغوسي) بتعديل الدرجات باستخدام الطوابع الزمنية؛ بينما يطبق مصنفو التعزيز قواعد تعتمد على البيانات الوصفية لترقية النتائج أو تخفيضها. يساعد كلاهما في ضبط سلوك الاسترجاع دون تغيير البيانات الأساسية.
تكامل مبسط للنموذج والتوجيه التلقائي: تسمح عمليات التكامل المدمجة مع OpenAI وHugging Face وموفري التضمين الآخرين لـ Milvus بتحويل النص تلقائيًا إلى ناقلات أثناء عمليات الإدراج والاستعلام. لا مزيد من خطوط أنابيب التضمين اليدوية لحالات الاستخدام الشائعة.
تحديثات المخطط عبر الإنترنت للحقول العددية: إضافة حقول قياسية جديدة إلى المجموعات الحالية دون توقف أو إعادة تحميلها، مما يبسّط تطور المخطط مع نمو متطلبات البيانات الوصفية.
اكتشاف التكرار القريب من التكرار مع MinHash: يتيح MinHash + LSH إمكانية الكشف الفعال عن التكرارات شبه المكررة عبر مجموعات البيانات الكبيرة دون إجراء مقارنات دقيقة مكلفة.

ترقيات البنية وقابلية التوسع

تخزين متدرج لإدارة البيانات الباردة والساخنة: يفصل بين البيانات الساخنة والباردة عبر SSD وتخزين الكائنات؛ ويدعم التحميل البطيء والجزئي؛ ويزيل الحاجة إلى تحميل المجموعات بالكامل محلياً؛ ويقلل من استخدام الموارد بنسبة تصل إلى 50% ويسرّع أوقات التحميل لمجموعات البيانات الكبيرة.
خدمة البث في الوقت الحقيقي: تضيف عُقد تدفق مخصصة مدمجة مع Kafka/Pulsar للاستيعاب المستمر؛ وتتيح الفهرسة الفورية وتوافر الاستعلام؛ وتحسّن إنتاجية الكتابة وتسرّع من استرداد الأعطال لأحمال العمل سريعة التغير في الوقت الفعلي.
تعزيز قابلية التوسع والاستقرار: يدعم Milvus الآن أكثر من 100,000 مجموعة للبيئات الكبيرة متعددة المستأجرين. تعمل ترقيات البنية التحتية - Woodpecker (WAL بدون قرص)، والتخزين v2 (انخفاض IOPS/الذاكرة)، ودمج المنسق - على تحسين استقرار المجموعة وتمكين التوسع المتوقع في ظل أعباء العمل الثقيلة.

للاطلاع على قائمة كاملة بميزات الإصدار Milvus 2.6، راجع ملاحظات إصدار Milvus.

كيفية الترقية من Milvus 2.5.x إلى Milvus 2.6.x

للحفاظ على النظام متاحًا قدر الإمكان أثناء الترقية، يجب ترقية مجموعات Milvus 2.5 إلى Milvus 2.6 بالترتيب التالي.

1. بدء تشغيل عقدة البث أولاً

ابدأ تشغيل عقدة البث أولاً. يجب نقل المفوض الجديد (المكون الموجود في عقدة الاستعلام المسؤول عن معالجة بيانات التدفق) إلى عقدة تدفق ميلفوس 2.6.

2. ترقية MixCoord

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

3. ترقية عقدة الاستعلام

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

4. ترقية عقدة البيانات

بمجرد إيقاف عقد البيانات Milvus 2.5 DataNodes، تصبح عمليات التدفق غير متوفرة، وقد تستمر البيانات في القطاعات المتزايدة في التراكم حتى تتم ترقية جميع العقد بالكامل إلى Milvus 2.6.

5. ترقية الوكيل

بعد ترقية وكيل إلى Milvus 2.6، ستظل عمليات الكتابة على هذا الوكيل غير متاحة حتى تتم ترقية جميع مكونات المجموعة إلى 2.6.

6. إزالة عقدة الفهرس

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

ملاحظات:

من اكتمال ترقية عقدة البيانات حتى اكتمال ترقية الوكيل، تكون عمليات التدفق غير متاحة.
من وقت ترقية الوكيل الأول حتى تتم ترقية جميع عقد الوكيل، تكون بعض عمليات الكتابة غير متاحة.
عند الترقية مباشرةً من Milvus 2.5.x إلى 2.6.6.6، تكون عمليات DDL (لغة تعريف البيانات) غير متوفرة أثناء عملية الترقية بسبب التغييرات في إطار عمل DDL.

كيفية الترقية إلى ميلفوس 2.6 باستخدام مشغل ميلفوس

مشغل MilvusOperator هو مشغل Kubernetes مفتوح المصدر يوفر طريقة قابلة للتطوير ومتاحة بشكل كبير لنشر وإدارة وترقية مجموعة خدمات Milvus بأكملها على مجموعة Kubernetes المستهدفة. تتضمن مجموعة خدمات Milvus التي يديرها المشغل ما يلي:

مكونات ميلفوس الأساسية
التبعيات المطلوبة مثل etcd، وPulsar، وMinIO

يتبع مشغل Milvus نمط مشغل Kubernetes القياسي. يقدم مورد Milvus المخصص (CR) الذي يصف الحالة المرغوبة لمجموعة Milvus، مثل الإصدار والطوبولوجيا والتكوين.

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

مثال على مورد Milvus المخصص (CR)

apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: my-milvus-mansion    
  namespace: dev       
spec:
  mode: cluster                  # cluster or standalone
  # Milvus Components
  components:
    image: milvusdb/milvus:v2.6.5
    imageUpdateMode: rollingUpgrade 
    proxy:                   
      replicas: 1          
    mixCoord:              
      replicas: 1           
    dataNode:               
      replicas: 1          
    queryNode:              
      replicas: 2           
      resources:
        requests:
          cpu: "2"
          memory: "8Gi"  
  # Dependencies, including etcd, storage and message stream
  dependencies:
    etcd:                   
      inCluster:
        values:
          replicaCount: 3    
    storage:                 
      type: MinIO
      inCluster:
        values:
          mode: distributed     
    msgStreamType: pulsar    
    pulsar:
      inCluster:
        values:
          bookkeeper:
            replicas: 3   
  # Milvus configs
  config:
    dataCoord:
      enableActiveStandby: true

ترقيات متجددة من Milvus 2.5 إلى 2.6 باستخدام مشغل Milvus

يوفر مشغل Milvus دعمًا مدمجًا للترقيات المتجددة من Milvus 2.5 إلى 2.6 في وضع التجميع، مع تكييف سلوكه لمراعاة التغييرات المعمارية المقدمة في 2.6.

1. اكتشاف سيناريو الترقية

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

فحص علامة الصورة المحددة في spec.components.image ، أو
قراءة الإصدار الصريح المحدد في spec.components.version

ثم يقوم المشغل بمقارنة هذا الإصدار المطلوب مع الإصدار قيد التشغيل حاليًا، والذي يتم تسجيله في status.currentImage أو status.currentVersion. إذا كان الإصدار الحالي هو 2.5 والإصدار المطلوب هو 2.6، يقوم المشغل بتحديد الترقية كسيناريو ترقية 2.5 → 2.6.

2. ترتيب تنفيذ الترقية المتداول

عندما يتم الكشف عن ترقية 2.5 → 2.6 ويتم تعيين وضع الترقية إلى ترقية متجددة (spec.components.imageUpdateMode: rollingUpgrade ، وهو الوضع الافتراضي)، يقوم مشغل Milvus تلقائيًا بتنفيذ الترقية بترتيب محدد مسبقًا يتماشى مع بنية Milvus 2.6:

بدء تشغيل عقدة البث ← ترقية MixCoord ← ترقية عقدة الاستعلام ← ترقية عقدة البيانات ← ترقية الوكيل ← إزالة عقدة الفهرس

3. دمج المنسق التلقائي

يستبدل برنامج Milvus 2.6 مكونات المنسق المتعددة بمنسق واحد MixCoord. يعالج مشغل ميلفوس هذا الانتقال المعماري تلقائيًا.

عندما يتم تكوين spec.components.mixCoord ، يقوم المشغل بإحضار MixCoord وينتظر حتى يصبح جاهزًا. بمجرد تشغيل MixCoord بشكل كامل، يقوم المشغل بإيقاف تشغيل مكونات المنسق القديم بأمان - الجذر، والاستعلام، والبيانات - لإكمال عملية الترحيل دون الحاجة إلى أي تدخل يدوي.

خطوات الترقية من ميلفوس 2.5 إلى 2.6

1- قم بترقية مشغل Milvus إلى أحدث إصدار (في هذا الدليل، نستخدم الإصدار 1.3.3، وهو أحدث إصدار وقت كتابة هذا الدليل).

# Option 1: Using Helm
helm upgrade --install milvus-operator \
  -n milvus-operator --create-namespace \
  https://github.com/zilliztech/milvus-operator/releases/download/v1.3.3/milvus-operator-1.3.3.tgz
 # Option 2: Using kubectl & raw manifests
 kubectl apply -f https://raw.githubusercontent.com/zilliztech/milvus-operator/v1.3.3/deploy/manifests/deployment.yaml

2- دمج مكونات المنسق

kubectl patch milvus my-release -n demo-operator --type=merge -p '
{
  "spec": {
    "components": {
      "mixCoord": {
        "replicas": 1
      }
    }
  }
}'

3- تأكد من أن المجموعة تعمل بنظام Milvus 2.5.16 أو أحدث

kubectl patch milvus my-release -n demo-operator --type=merge -p '
{
  "spec": {
    "components": {
      "image": "milvusdb/milvus:v2.5.22"
    }
  }
}'
# wait till updated
kubectl wait milvus my-release -n demo-operator --for=condition=milvusupdated --timeout=1h

4- ترقية ميلفوس إلى الإصدار 2.6

kubectl patch milvus my-release -n demo-operator --type=merge -p '
{
  "spec": {
    "components": {
      "image": "milvusdb/milvus:v2.6.5"
    }
  }
}'
# wait till updated
kubectl wait milvus my-release -n demo-operator --for=condition=milvusupdated --timeout=1h

كيفية الترقية إلى Milvus 2.6 باستخدام Helm

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

لا يزال من الممكن ترقية Milvus من 2.5 إلى 2.6 باستخدام Helm باتباع الخطوات التالية.

متطلبات النظام

إصدار Helm: ≥ 3.14.0
إصدار Kubernetes: ≥ 1.20.0

1- قم بترقية مخطط Milvus Helm إلى أحدث إصدار. في هذا الدليل، نستخدم الإصدار 5.0.7 من المخطط، والذي كان الأحدث في وقت كتابة هذا الدليل.

helm repo add zilliztech https://zilliztech.github.io/milvus-helm
helm repo update

2- إذا تم نشر المجموعة بمكونات منسقين متعددين، قم أولاً بترقية Milvus إلى الإصدار 2.5.16 أو أحدث وتمكين MixCoord.

mixCoordinator
。
helm upgrade -i my-release zilliztech/milvus \
  --namespace=helm-demo \
  --set image.all.tag="v2.5.22" \
  --set mixCoordinator.enabled=true \
  --set rootCoordinator.enabled=false \
  --set indexCoordinator.enabled=false \
  --set queryCoordinator.enabled=false \
  --set dataCoordinator.enabled=false \
  --set streaming.enabled=false \
  --set indexNode.enabled=true \
  --reset-then-reuse-values \
  --version=5.0.7 \
  --wait --timeout 1h

3- ترقية ميلفوس إلى الإصدار 2.6

helm upgrade my-release zilliztech/milvus \
  --namespace=helm-demo \
  --set image.all.tag="v2.6.5" \
  --set streaming.enabled=true \
  --set indexNode.enabled=false \
  --reset-then-reuse-values \
  --version=5.0.7 \
  --wait --timeout 1h

الأسئلة الشائعة حول ترقية الإصدار 2.6 من ميلفوس وعملياته

س1: برنامج Milvus Helm مقابل برنامج Milvus Operator - أيهما يجب أن أستخدم؟

بالنسبة لبيئات الإنتاج، يوصى بشدة باستخدام مشغل Milvus Helm.

راجع الدليل الرسمي للحصول على التفاصيل: https://github.com/zilliztech/milvus-operator?tab=readme-ov-file#milvus-operator-vs-helm

س2: كيف يمكنني اختيار قائمة انتظار الرسائل (MQ)؟

يعتمد MQ الموصى به على وضع النشر والمتطلبات التشغيلية:

1. الوضع المستقل: بالنسبة لعمليات النشر الحساسة من حيث التكلفة، يوصى باستخدام RocksMQ.

2. الوضع العنقودي

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

3. نقار الخشب (تم تقديمه في ميلفوس 2.6): يزيل Woodpecker الحاجة إلى قائمة انتظار رسائل خارجية، مما يقلل من التكلفة والتعقيد التشغيلي.

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

س3: هل يمكن تبديل قائمة انتظار الرسائل أثناء الترقية؟

لا، تبديل قائمة انتظار الرسائل أثناء الترقية غير مدعوم حاليًا. ستقدم الإصدارات المستقبلية واجهات برمجة تطبيقات الإدارة لدعم التبديل بين Pulsar وKafka وWoodpecker وRocksMQ.

س4: هل تحتاج تكوينات تحديد المعدل إلى تحديثها من أجل Milvus 2.6؟

لا، تظل تكوينات تحديد المعدل الحالية فعالة وتنطبق أيضًا على عقدة البث الجديدة. لا يلزم إجراء أي تغييرات.

س5: بعد دمج المنسق، هل تتغير أدوار المراقبة أو التكوينات؟

تظل أدوار المراقبة دون تغيير (RootCoord ، QueryCoord ، DataCoord).
تستمر خيارات التكوين الحالية في العمل كما كانت من قبل.
يتم تقديم خيار تكوين جديد، mixCoord.enableActiveStandby ، وسيعود إلى rootcoord.enableActiveStandby إذا لم يتم تعيينه بشكل صريح.

س 6: ما هي إعدادات الموارد الموصى بها لعقدة البث؟

بالنسبة للاستيعاب الخفيف في الوقت الحقيقي أو أعباء عمل الكتابة والاستعلام العرضية، يكفي تكوين أصغر، مثل 2 نواة وحدة معالجة مركزية و8 جيجابايت من الذاكرة.
أما بالنسبة للإدخال في الوقت الحقيقي الثقيل أو أعباء عمل الكتابة والاستعلام المستمرة، يوصى بتخصيص موارد مماثلة لتلك الموجودة في عقدة الاستعلام.

س7: كيف يمكنني ترقية عملية نشر مستقلة باستخدام Docker Compose؟

بالنسبة لعمليات النشر المستقلة المستندة إلى Docker Compose، ما عليك سوى تحديث علامة صورة Milvus في docker-compose.yaml.

راجع الدليل الرسمي للحصول على التفاصيل: https://milvus.io/docs/upgrade_milvus_standalone-docker.md.

الخلاصة

يمثل Milvus 2.6 تحسنًا كبيرًا في كل من البنية والعمليات. من خلال الفصل بين معالجة الدفق والمعالجة المجمعة مع تقديم StreamingNode، ودمج المنسقين في MixCoord، وتبسيط أدوار العاملين، يوفر Milvus 2.6 أساسًا أكثر استقرارًا وقابلية للتطوير وأسهل في التشغيل لأعباء عمل المتجهات واسعة النطاق.

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

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

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