Home
Blog
توقف عن الدفع مقابل البيانات الباردة: تخفيض التكلفة بنسبة 80% مع تحميل البيانات الباردة والساخنة عند الطلب في التخزين المتدرج في ميلفوس

توقف عن الدفع مقابل البيانات الباردة: تخفيض التكلفة بنسبة 80% مع تحميل البيانات الباردة والساخنة عند الطلب في التخزين المتدرج في ميلفوس

Engineering

December 15, 2025

Buqian Zheng

كم منكم لا يزال يدفع فواتير بنية تحتية متميزة للبيانات التي بالكاد يلمسها نظامك؟ كن صادقًا - معظم الفرق تفعل ذلك.

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

منصات SaaS متعددة المستأجرين: مئات من المستأجرين المسجلين، ولكن 10-15% فقط نشطون في أي يوم. أما البقية فيظلون باردين ولكنهم لا يزالون يشغلون الموارد.
أنظمة توصيات التجارة الإلكترونية: مليون وحدة تخزين، ومع ذلك فإن أعلى 8% من المنتجات تولد معظم التوصيات وحركة البحث.
البحث بالذكاء الاصطناعي: أرشيفات هائلة من التضمينات، على الرغم من أن 90% من استعلامات المستخدم تصل إلى عناصر من الأسبوع الماضي.

إنها القصة نفسها في مختلف المجالات: أقل من 10% من بياناتك يتم الاستعلام عنها بشكل متكرر، ولكنها غالباً ما تستهلك 80% من مساحة التخزين والذاكرة. يعلم الجميع أن هذا الخلل موجود - ولكن حتى وقت قريب، لم تكن هناك طريقة معمارية نظيفة لإصلاحه.

تغير ذلك مع الإصدار Milvus 2.6.

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

التخزين المتدرج هو الحل.

يقدم الإصدار Milvus 2.6 بنية تخزين متدرج جديدة مع تحميل حقيقي عند الطلب، مما يسمح للنظام بالتمييز بين البيانات الساخنة والباردة تلقائيًا:

تبقى المقاطع الساخنة مخزنة مؤقتًا بالقرب من الحوسبة
تعيش المقاطع الباردة بثمن بخس في تخزين الكائنات عن بُعد
لا يتم سحب البيانات إلى العقد المحلية إلا عندما يحتاجها الاستعلام فعليًا

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

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

لماذا ينهار التحميل الكامل على نطاق واسع

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

في الإصدار Milvus 2.5 والإصدارات الأقدم، عندما يصدر المستخدم طلبًا Collection.load() ، تقوم كل عقدة استعلام بتخزين المجموعة بأكملها مؤقتًا محليًا، بما في ذلك البيانات الوصفية وبيانات الحقل والفهارس. يتم تنزيل هذه المكونات من وحدة تخزين الكائنات وتخزينها إما بشكل كامل في الذاكرة أو يتم تعيين الذاكرة (mmap) على القرص المحلي. فقط بعد توفر كل هذه البيانات محليًا يتم وضع علامة على المجموعة على أنها محملة وجاهزة لخدمة الاستعلامات.

وبعبارة أخرى، لا يمكن الاستعلام عن المجموعة حتى تتواجد مجموعة البيانات الكاملة - الساخنة أو الباردة - على العقدة.

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

لمعرفة لماذا يصبح هذا الأمر إشكاليًا، خذ مثالًا ملموسًا:

لنفترض أن لديك مجموعة بيانات متجهة متوسطة الحجم تحتوي على

100 مليون متجه
768 بُعدًا (تضمينات BERT)
دقةعائمة32 (4 بايت لكل بُعد)
فهرس HNSW

في هذا الإعداد، يستهلك فهرس HNSW وحده - بما في ذلك المتجهات الخام المضمنة - حوالي 430 جيجابايت من الذاكرة. بعد إضافة حقول قياسية شائعة مثل معرّفات المستخدم أو الطوابع الزمنية أو تسميات الفئات، يتجاوز إجمالي استخدام الموارد المحلية بسهولة 500 جيجابايت.

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

بالنسبة لبعض أحمال العمل، يكون هذا السلوك مقبولاً:

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

ومع ذلك، في أحمال العمل التي تكون فيها 80% أو أكثر من البيانات موجودة في الذيل الطويل، تظهر عيوب التحميل الكامل بسرعة، سواء من حيث الأداء أو التكلفة.

اختناقات الأداء

في الممارسة العملية، يؤثر التحميل الكامل على أكثر من أداء الاستعلام، وغالبًا ما يؤدي إلى إبطاء سير العمل التشغيلي الروتيني:

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

عدم كفاءة التكلفة

يؤدي التحميل الكامل أيضًا إلى زيادة تكاليف البنية التحتية. على سبيل المثال، في مثيلات السحابة السائدة المحسّنة للذاكرة، يكلف تخزين 1 تيرابايت من البيانات محلياً حوالي $**70, 000 في السنة*، است$ ناداً $(AW$ $70,000 في السنة**، استناداً إلى التسعير المحافظ (AWS r6i: ~$ $*، استناداً إلى التسعير المحافظ (AWS r6i$ : $5.74 / GB / شهر؛ GCP n4-highmem: ~ 5$ $. 68 / جيجابايت / شهر؛ سلسلة AzureE :$ $5.68 / جيجابايت / شهر؛ سلسلة Azure E: ~$ 5. $68/جيجابايت/شهر؛ AzureE -$ $السلسلة$ : $5.67 / جيجابايت / شهر).$

ضع في اعتبارك الآن نمط وصول أكثر واقعية، حيث تكون 80% من تلك البيانات باردة ويمكن تخزينها في تخزين الكائنات بدلاً من ذلك (بسعر 0.023 دولارًا أمريكيًا / جيجابايت / شهر تقريبًا):

200 جيجابايت بيانات ساخنة × 5.68 دولار
800 جيجابايت بيانات باردة × 0.023 دولار

التكلفة السنوية: (200 × 5.68+800 × 0.023 دولار) × 12 × 14,000 دولار

هذا تخفيض بنسبة 80% في التكلفة الإجمالية للتخزين، دون التضحية بالأداء في الأماكن المهمة بالفعل.

ما هو التخزين المتدرج وكيف يعمل؟

لإزالة هذه المفاضلة، قدم Milvus 2.6 التخزين المتدرج، الذي يوازن بين الأداء والتكلفة من خلال التعامل مع التخزين المحلي على أنه ذاكرة تخزين مؤقتة بدلاً من حاوية لمجموعة البيانات بأكملها.

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

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

من الناحية العملية، يعمل التخزين المتدرج على النحو التالي:

الاحتفاظ بالبيانات الساخنة محليًا: ما يقرب من 20٪ من البيانات التي يتم الوصول إليها بشكل متكرر تبقى مقيمة على العقد المحلية، مما يضمن زمن استجابة منخفض لـ 80٪ من الاستعلامات الأكثر أهمية.
تحميل البيانات الباردة عند الطلب: لا يتم جلب الـ 80% المتبقية من البيانات التي نادرًا ما يتم الوصول إليها إلا عند الحاجة إليها، مما يؤدي إلى تحرير معظم موارد الذاكرة والأقراص المحلية.
التكيف ديناميكيًا مع الإخلاء المستند إلى LRU: يستخدم Milvus استراتيجية الإخلاء المستندة إلى LRU (الأقل استخدامًا مؤخرًا) لضبط البيانات التي تعتبر ساخنة أو باردة باستمرار. يتم إخلاء البيانات غير النشطة تلقائيًا لإفساح المجال للبيانات التي تم الوصول إليها حديثًا.

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

تحت الغطاء، يتم تمكين هذا السلوك من خلال ثلاث آليات تقنية أساسية:

1. التحميل البطيء

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

كيفية عمل تحميل المجموعات في ميلفوس 2.5

كيفية عمل التحميل البطيء في Milvus 2.6 والإصدارات الأحدث

تنقسم البيانات الوصفية التي تم تحميلها أثناء التهيئة إلى أربع فئات رئيسية:

إحصائيات المقطع (المعلومات الأساسية مثل عدد الصفوف وحجم المقطع والبيانات الوصفية للمخطط)
الطوابع الزمنية (تُستخدم لدعم استعلامات السفر عبر الزمن)
إدراج وحذف السجلات (مطلوب للحفاظ على اتساق البيانات أثناء تنفيذ الاستعلام)
مرشحات بلوم (تُستخدم للتصفية المسبقة السريعة لإزالة المقاطع غير ذات الصلة بسرعة)

2. التحميل الجزئي

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

فهارس المتجهات: التحميل الواعي للمستأجر

واحدة من أكثر القدرات تأثيرًا التي تم تقديمها في Milvus 2.6+ هي التحميل الواعي للمستأجرين للفهارس المتجهة، المصممة خصيصًا لأحمال العمل متعددة المستأجرين.

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

يوفر هذا التصميم العديد من الفوائد:

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

الحقول العددية: التحميل الجزئي على مستوى العمود

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

ضع في اعتبارك مجموعة تحتوي على 50 حقلاً من حقول المخطط، مثل id و vector و و title و description و category و price و stock و tags ، وتحتاج فقط إلى إرجاع ثلاثة حقول -id و title و price.

في Milvus 2.5، يتم تحميل جميع الحقول القياسية الخمسين بغض النظر عن متطلبات الاستعلام.
في Milvus 2.6+، يتم تحميل الحقول الثلاثة المطلوبة فقط. تبقى الحقول الـ 47 المتبقية غير محملة ويتم جلبها بشكل كسول فقط إذا تم الوصول إليها لاحقًا.

يمكن أن تكون وفورات الموارد كبيرة. إذا كان كل حقل قياسي يشغل 20 جيجابايت:

يتطلب تحميل جميع الحقول 1,000 جيجابايت (50 × 20 جيجابايت)
يستهلك تحميل الحقول الثلاثة المطلوبة فقط 60 جيجابايت

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

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

3. إخلاء ذاكرة التخزين المؤقت المستند إلى LRU

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

يتبع إخلاء LRU (الأقل استخدامًا مؤخرًا) قاعدة بسيطة: يتم إخلاء البيانات التي لم يتم الوصول إليها مؤخرًا أولاً. هذا يحرر مساحة محلية للبيانات التي تم الوصول إليها حديثًا مع الاحتفاظ بالبيانات المستخدمة بشكل متكرر في ذاكرة التخزين المؤقت.

تقييم الأداء: التخزين المتدرج مقابل التحميل الكامل

لتقييم التأثير الواقعي للتخزين المتدرج في العالم الحقيقي، قمنا بإعداد بيئة اختبار تعكس عن كثب أعباء عمل الإنتاج. قمنا بمقارنة Milvus مع التخزين المتدرج وبدونه عبر خمسة أبعاد: وقت التحميل واستخدام الموارد وأداء الاستعلام والسعة الفعالة وكفاءة التكلفة.

الإعداد التجريبي

مجموعة البيانات

100 مليون متجه بأبعاد 768 (تضمينات BERT)
حجم فهرس المتجهات: حوالي 430 جيجابايت
10 حقول قياسية، بما في ذلك المعرف والطابع الزمني والفئة

تكوين الأجهزة

1 QueryNode مع 4 وحدات تحكم افتراضية وذاكرة 32 جيجابايت و1 تيرابايت NVMe SSD
شبكة 10 جيجابت في الثانية
مجموعة تخزين كائنات MinIO كواجهة خلفية للتخزين عن بُعد

نمط الوصول

تتبع الاستعلامات توزيعًا واقعيًا للوصول السريع والبارد:

80% من الاستعلامات تستهدف البيانات من آخر 30 يومًا (≈20% من إجمالي البيانات)
15٪ من البيانات المستهدفة من 30-90 يومًا (≈30٪ من إجمالي البيانات)
5٪ بيانات مستهدفة أقدم من 90 يومًا (≈50٪ من إجمالي البيانات)

النتائج الرئيسية

1. وقت تحميل أسرع بـ 33 مرة

المرحلة	ميلفوس 2.5	ميلفوس 2.6+ (تخزين متدرج)	تسريع
تنزيل البيانات	22 دقيقة	28 ثانية	47×
تحميل الفهرس	3 دقائق	17 ثانية	10.5×
الإجمالي	25 دقيقة	45 ثانية	33×

في Milvus 2.5، استغرق تحميل المجموعة 25 دقيقة. مع التخزين المتدرج في الإصدار Milvus 2.6+، يكتمل نفس عبء العمل في 45 ثانية فقط، مما يمثل تحسنًا كبيرًا في كفاءة التحميل.

2. انخفاض بنسبة 80% في استخدام الموارد المحلية

المرحلة	Milvus 2.5	Milvus 2.6+ (التخزين المتدرج)	التخفيض
بعد التحميل	430 جيجابايت	12 جيجابايت	-97%
بعد 1 ساعة	430 جيجابايت	68 جيجابايت	-84%
بعد 24 ساعة	430 جيجابايت	85 جيجابايت	-80%
الحالة المستقرة	430 جيجابايت	85-95 جيجابايت	~80%

في الإصدار Milvus 2.5، يظل استخدام الموارد المحلية ثابتًا عند 430 جيجابايت، بغض النظر عن عبء العمل أو وقت التشغيل. في المقابل، يبدأ Milvus 2.6+ ب 12 جيجابايت فقط بعد التحميل مباشرة.

أثناء تشغيل الاستعلامات، يتم تخزين البيانات التي يتم الوصول إليها بشكل متكرر مؤقتًا محليًا ويزداد استخدام الموارد تدريجيًا. بعد حوالي 24 ساعة تقريبًا، يستقر النظام عند 85-95 جيجابايت، مما يعكس مجموعة العمل من البيانات الساخنة. على المدى الطويل، ينتج عن ذلك انخفاض بنسبة 80٪ تقريبًا في استخدام الذاكرة المحلية والأقراص دون التضحية بتوافر الاستعلام.

3. تأثير شبه معدوم على أداء البيانات الساخنة

نوع الاستعلام	زمن استجابة ميلفوس 2.5 P99	وقت استجابة P99 + P99 ميلفوس 2.6+	التغيير
استعلامات البيانات الساخنة	15 مللي ثانية	16 مللي ثانية	+6.7%
استعلامات البيانات الساخنة	15 مللي ثانية	28 مللي ثانية	+86%
استعلامات البيانات الباردة (الوصول الأول)	15 مللي ثانية	120 مللي ثانية	+700%
استعلامات البيانات الباردة (تخزين مؤقت)	15 مللي ثانية	18 مللي ثانية	+20%

بالنسبة للبيانات الساخنة، والتي تمثل 80% تقريبًا من جميع الاستعلامات، يزيد زمن انتقال P99 بنسبة 6.7% فقط، مما يؤدي إلى عدم وجود تأثير ملموس في الإنتاج.

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

4. سعة فعالة أكبر بمقدار 4.3 × 4.3

في ظل ميزانية الأجهزة نفسها - ثمانية خوادم بسعة 64 جيجابايت من الذاكرة لكل منها (إجمالي 512 جيجابايت) - يمكن ل Milvus 2.5 تحميل 512 جيجابايت من البيانات على الأكثر، أي ما يعادل 136 مليون ناقل تقريبًا.

مع تمكين التخزين المتدرج في Milvus 2.6+، يمكن للأجهزة نفسها دعم 2.2 تيرابايت من البيانات، أو ما يقرب من 590 مليون ناقل. يمثل هذا زيادة 4.3 أضعاف في السعة الفعالة، مما يتيح تقديم مجموعات بيانات أكبر بكثير دون توسيع الذاكرة المحلية.

5. تخفيض التكلفة بنسبة 80.1%

باستخدام مجموعة بيانات متجهية سعتها 2 تيرابايت في بيئة AWS كمثال، وبافتراض أن 20% من البيانات ساخنة (400 جيجابايت)، تكون مقارنة التكلفة على النحو التالي:

العنصر	ميلفوس 2.5	ميلفوس 2.6+ (تخزين متدرج)	التوفير
التكلفة الشهرية	$11,802	$2,343	$9,459
التكلفة السنوية	$141,624	$28,116	$113,508
معدل التوفير	-	-	80.1%

ملخص المعيار

عبر جميع الاختبارات، يوفر التخزين المتدرج تحسينات متسقة وقابلة للقياس:

أوقات تحميل أسرع بـ 33 مرة: تقليل وقت تحميل المجموعة من 25 دقيقة إلى 45 ثانية.
انخفاض استخدام الموارد المحلية بنسبة 80%: في حالة التشغيل الثابتة، ينخفض استخدام الذاكرة والقرص المحلي بنسبة 80% تقريباً.
تأثير شبه معدوم على أداء البيانات الساخنة: يزيد وقت استجابة P99 للبيانات الساخنة بأقل من 10%، مما يحافظ على أداء الاستعلام منخفض الكمون.
الكمون المتحكم فيه للبيانات الباردة: تتكبد البيانات الباردة زمن انتقال أعلى في أول وصول، ولكن هذا مقبول نظرًا لانخفاض تكرار الوصول إليها.
4.3× سعة فعّالة أعلى: يمكن للأجهزة نفسها خدمة بيانات أكثر بـ 4-5 أضعاف البيانات بدون ذاكرة إضافية.
تخفيض التكلفة بنسبة تزيد عن 80%: يتم تخفيض تكاليف البنية التحتية السنوية بأكثر من 80%.

متى يتم استخدام التخزين المتدرج في Milvus

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

حالات الاستخدام الأنسب

1. منصات البحث المتجهية متعددة المستأجرين

الخصائص: عدد كبير من المستأجرين مع نشاط متفاوت للغاية؛ البحث المتجه هو عبء العمل الأساسي.
نمط الوصول: يولد أقل من 20% من المستأجرين أكثر من 80% من الاستعلامات المتجهة.
الفوائد المتوقعة: تخفيض التكلفة بنسبة 70-80%؛ زيادة السعة 3-5 أضعاف.

2. أنظمة توصيات التجارة الإلكترونية (أعباء عمل البحث المتجه)

الخصائص: انحراف شعبي قوي بين المنتجات ذات الشعبية الكبيرة والذيل الطويل.
نمط الوصول: أعلى 10% من المنتجات تمثل حوالي 80% من حركة البحث المتجه.
الفوائد المتوقعة: لا حاجة إلى سعة إضافية خلال أحداث الذروة؛ خفض التكلفة بنسبة 60-70%

3. مجموعات بيانات واسعة النطاق مع فصل واضح بين الساخن والبارد (يهيمن عليها المتجهات)

الخصائص: مجموعات بيانات بمقياس تيرابايت أو مجموعات بيانات أكبر، مع انحياز الوصول بشكل كبير للبيانات الحديثة.
نمط الوصول: التوزيع الكلاسيكي 80/20: 20٪ من البيانات تخدم 80٪ من الاستفسارات
الفوائد المتوقعة تخفيض التكلفة بنسبة 75-85%

حالات الاستخدام المناسبة

1. أعباء العمل الحساسة للتكلفة

الخصائص: ميزانيات ضيقة مع بعض التسامح مع بعض المفاضلات الطفيفة في الأداء.
نمط الوصول: الاستعلامات المتجهة مركزة نسبياً.
الفوائد المتوقعة: تخفيض التكلفة بنسبة 50-70%؛ قد تتكبد البيانات الباردة حوالي 500 مللي ثانية من زمن الوصول الأول، وهو ما يجب تقييمه مقابل متطلبات اتفاقية مستوى الخدمة.

2. الاحتفاظ بالبيانات التاريخية والبحث الأرشيفي

الخصائص: أحجام كبيرة من المتجهات التاريخية مع تكرار استعلام منخفض للغاية.
نمط الوصول: حوالي 90% من الاستعلامات تستهدف البيانات الحديثة.
الفوائد المتوقعة: الاحتفاظ بمجموعات البيانات التاريخية الكاملة؛ الحفاظ على إمكانية التنبؤ بتكاليف البنية التحتية والتحكم فيها

حالات الاستخدام غير الملائمة

1. أعباء عمل البيانات الساخنة بشكل موحد

الخصائص: يتم الوصول إلى جميع البيانات بوتيرة متشابهة، مع عدم وجود تمييز واضح بين الساخن والبارد.
لماذا غير مناسب: فائدة محدودة لذاكرة التخزين المؤقت؛ تعقيد إضافي للنظام دون مكاسب مجدية

2. أعباء العمل ذات الكمون المنخفض للغاية

الخصائص: أنظمة حساسة للغاية لوقت الاستجابة مثل التداول المالي أو المزايدة في الوقت الفعلي
لماذا غير مناسب: حتى الاختلافات الصغيرة في زمن الاستجابة غير مقبولة؛ يوفر التحميل الكامل أداءً أكثر قابلية للتنبؤ به

بداية سريعة: جرب التخزين المتدرج في ميلفوس 2.6+

# Download Milvus 2.6.1+
$ wget https://github.com/milvus-io/milvus/releases/latest
# Configure Tiered Storage
$ vi milvus.yaml
queryNode.segcore.tieredStorage:
  warmup:
    scalarField: disable
    scalarIndex: disable
    vectorField: disable
    vectorIndex: disable
  evictionEnabled: true
# Launch Milvus
$ docker-compose up -d

الخلاصة

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

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

لمزيد من المعلومات حول التخزين المتدرج، راجع الوثائق أدناه:

التخزين المتدرج | وثائق ميلفوس

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