Milvus External Collection: فهرسة واسترجاع البيانات المقيمة في بحيرة البيانات دون نقلها

في العديد من خطوط أنابيب الذكاء الاصطناعي، تُنتَج التضمينات (embeddings) والبيانات الوصفية وتُخزَّن بالفعل في بحيرة بيانات. قد يكتب خط أنابيب المنتجات سمات المنتجات وتضمينات متعددة الوسائط إلى ملفات Parquet في S3. قد تعيش مجموعة بيانات الاسترجاع أو التدريب في جدول Iceberg أو Lance. بحيرة البيانات هي بالفعل المكان الذي تُنشأ فيه هذه المجموعات، وتُحدَّث، وتُدار إصداراتها، وتستخدمها بقية مكونات البنية التحتية للبيانات.

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

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

Milvus 3.0 المجموعة الخارجية (External Collection) تقدم مسارًا ثالثًا. تظل البيانات المصدر في Parquet أو Iceberg أو Lance أو Vortex أو أي تنسيق خارجي مدعوم آخر، بينما تبني Milvus الفهارس عليها وتقدمها. يمكنك تخطيط الحقول الخارجية في مخطط Milvus، وتحديد الفهارس التي تحتاجها، وتحديث المجموعة، واستخدام واجهات بحث واستعلام Milvus المعتادة—دون نسخ صفوف المصدر أولاً إلى مجموعة مُدارة بواسطة Milvus.

التغيير المعماري واضح: يمكن أن تبقى البيانات في البحيرة، بينما تضيف Milvus طبقة الفهرسة والاسترجاع.

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

ما هي المجموعة الخارجية وما الذي تغيّره

المجموعة الخارجية هي نوع من مجموعات Milvus توجد بياناتها المصدر خارج التخزين المُدار بواسطة Milvus.

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

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

مع المجموعة الخارجية، يصبح الهيكل:

Milvus لا تجعل الملفات الخارجية نسخة بيانات مصدر خاصة بها. بدلاً من ذلك، تحتوي المجموعة الخارجية على المعلومات التي تحتاجها Milvus لتفسير هذه الملفات والبحث فيها:

1. عنصر external_source يحدد الملفات أو الجدول الخارجي.
2. عنصر external_spec يصف تنسيق المصدر والوصول إلى التخزين.
3. تخطيطات external_field التي تربط الحقول في مخطط Milvus بأعمدة مجموعة البيانات الخارجية.
4. الفهارس وملفات البيان (manifests) وحالة التقديم التي تنشئها Milvus للاسترجاع.

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

مجموعة Milvus العادية مقابل المجموعة الخارجية

الجانب	مجموعة مُدارة بواسطة Milvus	مجموعة خارجية
سجلات المصدر	مخزنة ومدارة بواسطة Milvus	تبقى في الملفات أو الجدول الخارجي
كيفية دخول البيانات إلى Milvus	إدراج، أو تحديث، أو استيراد، أو كتابة دفقية	تخطيط المصدر الخارجي + Refresh
التعديلات عبر الإنترنت	مدعومة	للقراءة فقط من جانب Milvus
حداثة البيانات	تتبع مسار الكتابة ونموذج الاتساق في Milvus	تتبع آخر Refresh منشور بنجاح
الحالة المُدارة بواسطة Milvus	البيانات المصدر، البيانات الوصفية، الفهارس، التخزينات المؤقتة	التخطيطات، ملفات البيان، الفهارس، التخزينات المؤقتة
مسار الاستعلام	واجهات بحث واستعلام Milvus	واجهات بحث واستعلام Milvus
الأنسب لـ	البيانات عبر الإنترنت المتغيرة باستمرار	بيانات البحيرة الكبيرة المنتجة دفعاتٍ وكثيفة القراءة

لذلك تُكمِل المجموعة الخارجية مجموعات Milvus العادية بدلاً من استبدالها.

يمكن للنظام الاحتفاظ بالحالة عبر الإنترنت سريعة التغير في مجموعات Milvus العادية مع استخدام المجموعات الخارجية للمجاميع الكبيرة، والكتالوجات، ومجموعات البيانات التاريخية، وخصائص النماذج، أو أي بيانات أخرى أُنتجت وتُحكَم في البحيرة بالفعل.

لماذا يهم إزالة النسخة الثانية

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

التكلفة الأعظم تأتي من إبقاء نظامي بيانات متوافقين.

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

بمجرد أن تصبح نسخة التقديم عبر الإنترنت مستقلة عن البحيرة، يجب أن يعبر كل تغيير تلك الحدود:

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

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

التكلفة	بحيرة + نسخة تقديم منفصلة	مجموعة خارجية
نسخ البيانات المصدر	نسخة البحيرة بالإضافة إلى نسخة تقديم منفصلة	تبقى صفوف المصدر في البحيرة
حركة البيانات	خط أنابيب ETL/استيراد مستمر	Refresh على المصدر الخارجي
حداثة البيانات	تعتمد على إيقاع التصدير/الاستيراد	يتحكم بها وقت نشر Refresh جديد
الحوكمة	يجب أن تظل نسختا المصدر والتقديم متوافقتين	تبقى ملكية المصدر وسلالة البيانات والتحكم في الإصدارات لدى منصة البحيرة
إعادة الاستخدام دون اتصال	قد يجهّز مستهلكون آخرون نسخهم الخاصة	يمكن لأدوات البحيرة الحالية مواصلة قراءة نفس المصدر
موارد التقديم	تُحدَّد أحجامها حول نسخة قاعدة البيانات وحمل عمل الاستعلام	يمكن إدارة الفهرسة وحوسبة الاستعلام والتخزين المؤقت بشكل منفصل عن ملكية صفوف المصدر

يصبح هذا الفرق مهمًا بشكل خاص مع ازدياد تغيّر بيانات الذكاء الاصطناعي.

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

إذا كان كل نظام يملك نسخته الخاصة، فكل تحسين يتحول إلى مهمة مزامنة أخرى.

تغيّر المجموعة الخارجية تلك الحدود: يمكن للأنظمة غير المتصلة مواصلة العمل على مجموعة بيانات البحيرة، بينما تقدّم Milvus الاسترجاع على الأساس نفسه.

ما مصادر البيانات التي تدعمها المجموعة الخارجية

صُممت المجموعة الخارجية حول بيانات مفتوحة مُدارة خارجيًا بدلاً من تخطيط مصدر خاص بـ Milvus. وهي تدعم تنسيقات مصادر خارجية متعددة عبر Storage V3:

التنسيق الخارجي	قيمة format	ما تقرؤه Milvus
Apache Parquet	parquet	دليل أو بادئة تخزين كائنات تحتوي على ملفات Parquet ومجموعات صفوف
Vortex	vortex	ملفات Vortex والبيانات الوصفية لتخطيطها
Lance	lance-table	مجموعة بيانات Lance والبيانات الوصفية لأجزائها
Apache Iceberg	iceberg-table	بيانات Iceberg الوصفية بالإضافة إلى لقطة (snapshot) محددة
لقطة Milvus	milvus-table	لقطة Milvus مدعومة مكشوفة كمصدر خارجي

التخطيط بين المصدر وMilvus صريح.

يمكن لعمود مصدر باسم product_id أن يصبح حقل id في Milvus؛ ويمكن أن يصبح image_vec هو embedding؛ ولا يحتاج جدول مصدر عريض إلى كشف كل عمود للمجموعة. هذا يعني أن منصة البيانات لا تضطر إلى إعادة تسمية مصدرها أو إعادة كتابته فقط لإرضاء قاعدة بيانات التقديم.

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

تظل الملفات الأساسية قابلة للاستخدام من بقية مكونات البنية التحتية للبيانات أيضًا. يمكن لـ Spark وأطر التدريب وأنظمة الحوكمة والأدوات الأخرى المتوافقة مع البحيرات مواصلة قراءة نفس البيانات المفتوحة.

تضيف المجموعة الخارجية مستهلكًا آخر لتلك البيانات؛ ولا تحوّل Milvus إلى المالك الوحيد لها.

الوصول الآمن إلى التخزين الخارجي

تحتاج Milvus أيضًا إلى إذن لقراءة التخزين الخارجي.

اعتمادًا على مزود التخزين، يمكن لعمليات النشر استخدام آليات مثل هوية حمل العمل أو هوية المثيل، أو افتراض دور AWS STS، أو انتحال هوية حساب الخدمة، أو وصولًا قائمًا على SAS، أو أنظمة أدوار خاصة بالمزود، بدلاً من تضمين بيانات اعتماد طويلة الأجل في إعدادات التطبيق.

تتحكم هوية التخزين هذه في كيفية وصول Milvus إلى المصدر. يظل التفويض داخل Milvus حدودًا أمنية منفصلة.

كيفية إنشاء مجموعة خارجية وفهرستها وتحديثها والاستعلام عنها

تتكون دورة حياة المجموعة الخارجية من أربع خطوات رئيسية:

1. حدّد المصدر الخارجي وخطط أعمدةه في مخطط Milvus.
2. حدّد الفهارس التي يحتاجها حمل العمل.
3. شغّل Refresh لتكتشف Milvus البيانات المصدر وتُعدّ إصدارًا قابلًا للاستعلام.
4. حمّل المجموعة واستخدم واجهات بحث واستعلام Milvus المعتادة.

فيما يلي نفس كتالوج المنتجات ممثلًا كمجموعة خارجية:

import json
import time
from pymilvus import DataType, MilvusClient
client = MilvusClient(
uri=“http://localhost:19530”,
token=“root:Milvus”,
)
schema = client.create_schema(
external_source=“s3://my-lake/datasets/products/”,
external_spec=json.dumps(
{
“format”: “parquet”,
“extfs”: {
“cloud_provider”: “aws”,
“region”: “us-east-1”,
“use_iam”: “true”,
“iam_endpoint”: “https://sts.us-east-1.amazonaws.com”,
},
}
),
)
schema.add_field(
field_name=“id”,
datatype=DataType.INT64,
external_field=“product_id”,
)
schema.add_field(
field_name=“embedding”,
datatype=DataType.FLOAT_VECTOR,
dim=768,
external_field=“image_vec”,
)
schema.add_field(
field_name=“title”,
datatype=DataType.VARCHAR,
max_length=256,
external_field=“product_name”,
)
schema.add_field(
field_name=“stock”,
datatype=DataType.INT64,
external_field=“stock”,
)
schema.add_field(
field_name=“rating”,
datatype=DataType.FLOAT,
external_field=“rating”,
)
client.create_collection(
collection_name=“products_ext”,
schema=schema,
)

تستخدم الفهارس واجهة Milvus المعتادة:

index_params = client.prepare_index_params()
index_params.add_index(
    field_name="embedding",
    index_type="HNSW",
    metric_type="COSINE",
)
index_params.add_index(field_name="stock", index_type="AUTOINDEX")
index_params.add_index(field_name="rating", index_type="AUTOINDEX")
client.create_index(
collection_name=“products_ext”,
index_params=index_params,
)

ثم حدّث المصدر الخارجي:

job_id = client.refresh_external_collection(
    collection_name="products_ext",
)
while True:
progress = client.get_refresh_external_collection_progress(job_id=job_id)
if progress.state == “RefreshCompleted”:
break
if progress.state == “RefreshFailed”:
raise RuntimeError(progress.reason)
time.sleep(2)

بمجرد أن يصبح الإصدار المحدث جاهزًا، حمّله وابحث فيه مثل مجموعة Milvus عادية:

client.load_collection("products_ext")
results = client.search(
collection_name=“products_ext”,
data=[query_vec],
anns_field=“embedding”,
filter=“stock > 0 and rating >= 4.0”,
limit=10,
output_fields=[“id”, “title”, “stock”, “rating”],
)

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

كيف يلتقط Refresh التغييرات في البيانات الخارجية

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

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

يقرأ Refresh البيانات الوصفية الخارجية، ويحلل أجزاء المصدر، ويحدّث ملفات البيان (manifests) التي تربطها بمجموعة Milvus، ويُعدّ حالة الفهارس المقابلة.

المفتاح هو أن هذا العمل يمكن أن يكون تدريجيًا.

تحدد Milvus أجزاء المصدر التي لم تتغير ويمكنها إعادة استخدام أعمال المقاطع (segments) والفهارس الموجودة لها. أما الأجزاء الجديدة أو المتغيرة فهي التي تتطلب معالجة جديدة.

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

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

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

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

كيف يقلل التحميل الكسول (Lazy Loading) استخدام الذاكرة لمجموعات البيانات العريضة

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

في وقت تحميل المجموعة، يمكن لعُقد الاستعلام (QueryNodes) الاحتفاظ مبدئيًا ببيانات وصفية خفيفة الوزن فقط، مثل معلومات المخطط وتعريفات الفهارس وخرائط الكتل ومراجع الكائنات البعيدة. تُجلب بيانات الحقول على مستوى الكتلة عندما يحتاجها الاستعلام؛ ويمكن أن تظل الفهارس بعيدة حتى أول استخدام، ثم تُخزَّن محليًا مؤقتًا. تظل البيانات كثيرة الاستخدام ساخنة، بينما يمكن إخراج البيانات الأقل وصولًا.

هذا مفيد بشكل خاص لمجموعات بيانات الذكاء الاصطناعي العريضة.

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

يمكن للمجموعة الخارجية تضييق بصمة التقديم على مستويين:

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

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

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

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

يؤدي تنسيق المصدر دورًا مهمًا هنا أيضًا. يمكن للتنسيقات المصممة لعمليات المسح التحليلي الواسع والتنسيقات المحسّنة للقراءات الأضيق أو العشوائية أن تُنتج سلوك إدخال/إخراج مختلفًا عند الوصول عند الطلب. لا تمحو المجموعة الخارجية تلك المقايضات على مستوى التخزين؛ بل تتيح لـ Milvus بناء طبقة استرجاع فوقها.

ما قدرات البحث والفهرسة التي تدعمها المجموعة الخارجية

لا تكتفي المجموعة الخارجية بتوجيه Milvus إلى دليل من التضمينات ومسح الملفات. بل تبني Milvus هياكل استرجاع على البيانات الخارجية وتنفذ الاستعلامات عبر محرك الاسترجاع القياسي الخاص بها.

فهارس Milvus المبنية فوق البيانات الخارجية

اعتمادًا على الحقول وحمل العمل، يمكن لـ Milvus بناء:

• فهارس متجهات لبحث ANN؛
• فهارس عددية لتصفية البيانات الوصفية؛
• فهارس JSON للسمات شبه المنظمة؛
• فهارس BM25 والنص الكامل للاسترجاع المعجمي.
• حقول مولّدة بالدوال (function-generated) مدعومة من نموذج بيانات Milvus.

يستخدم بحث ANN تلك الفهارس لتضييق مجموعة المرشحين بدلاً من قراءة كل متجه مصدر.

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

أبعد من أفضل K المتجهية

من الأخطاء الشائعة الأخرى قراءة "المجموعة الخارجية" على أنها "بحث متجهي فوق Parquet". هذا يقلل من شأن ما يتطلبه الاسترجاع الإنتاجي فعلاً.

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

لنفترض استعلامًا مثل:

فستان زهري أحمر للصيف، متوفر في المخزون، الأعلى تقييمًا أولاً

قد يحتاج مسار الاسترجاع الإنتاجي إلى عدة إشارات:

• تشابه المتجهات للمعنى الدلالي لـ'فستان صيفي زهري'.
• بحث معجمي أو نص كامل لمصطلح دقيق مثل 'أحمر'.
• مرشحات عددية لإزالة المنتجات غير المتوفرة في المخزون أو الأقل من عتبة تقييم معينة.
• استرجاع وترتيب هجين للجمع بين إشارات استرجاع متعددة.

توسّع Milvus 3.0 أيضًا محرك الاستعلام إلى ما بعد استرجاع أقرب الجيران الأولي بقدرات مثل الترتيب من جانب الخادم، والتجميع، والتصنيف حسب الأوجه (faceting).

المغزى الأوسع هو أن المجموعة الخارجية تمنح البيانات المقيمة في البحيرة مسار استرجاع بمستوى قواعد البيانات—وليس مجرد طريقة لقراءة المتجهات من الملفات.

كيف تدعم نفس بيانات البحيرة التقديم عبر الإنترنت والمعالجة غير المتصلة

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

لنعد إلى كتالوج المنتجات.

خلال النهار، يمكن لـ Milvus تقديم مجموعة خارجية للبحث عن المنتجات، أو التوصيات، أو استرجاع الوكلاء.

في الوقت نفسه، يمكن لأنظمة أخرى العمل مباشرة على مجموعة بيانات البحيرة:

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

المجموعة الخارجية لا تشغّل تلك المهام بنفسها. تبقى Spark كما هي، ويبقى التدريب كما هو. دورها هو إزالة الحدود الإضافية بين التقديم والبيانات.

يمكن للعمل غير المتصل كتابة بيانات محسّنة أو حقول جديدة إلى البحيرة. يجعل Refresh لاحق المصدر المحدث متاحًا لمسار استرجاع Milvus.

لا توجد حلقة تصدير واستيراد منفصلة غرضها الوحيد إعادة بناء نسخة مرجعية أخرى للتقديم.

تظل الحوكمة مقسّمة بوضوح أيضًا. تبقى إصدارات المصدر وسلالة البيانات (lineage) وملكية المصدر لدى منصة البحيرة. تحتفظ Milvus بتفويضها الخاص على مستوى المجموعة وببيانات الاعتماد المطلوبة لقراءة المصدر. مشاركة أساس بيانات واحد لا تعني دمج كل نطاقات الأمان في نظام واحد.

هذا هو الارتباط بـ Vector Lakebase: تظل البحيرة أساس البيانات المشترك، بينما توفر Milvus طبقة استرجاع منخفضة زمن الاستجابة فوقها. المجموعة الخارجية جزء واحد من تلك البنية، إلى جانب Storage V3 واللقطات (Snapshots) وتكامل Spark وتطوّر المخطط والتعبئة بأثر رجعي (backfill).

أين تتناسب المجموعة الخارجية—وأين لا تتناسب

المجموعة الخارجية مناسبة تمامًا عندما:

• تكون بياناتك المرجعية موجودة بالفعل في Parquet أو Vortex أو Lance أو Iceberg أو مصدر خارجي مدعوم آخر.
• تُنتَج مجموعة البيانات بشكل أساسي على دفعات بدلاً من الكتابات التعاملية عالية التردد.
• يسبب الاحتفاظ بنسخة تقديم ثانية أعباء كبيرة على ETL أو الحداثة أو الحوكمة.
• تحتاج أنظمة متعددة إلى العمل مع نفس مجموعة البيانات المفتوحة.
• يكون حد Refresh الصريح مقبولاً لحداثة التقديم.
• تريد استرجاع Milvus الإنتاجي دون جعل Milvus مالكًا لصفوف المصدر.

مجموعة Milvus العادية تظل الخيار الأفضل عندما:

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

هناك عدة حدود جديرة بالانتباه.

• المجموعات الخارجية للقراءة فقط. تحدث تغييرات المصدر خارج Milvus.
• ينطبق النسخ الصفري على صفوف المصدر. لا تزال الفهارس وملفات البيان والتخزينات المؤقتة والحوسبة تكلف موارد.
• Refresh صريح. إنه ليس آلية مزامنة دفقية.
• يجب أن يظل المصدر قابلاً للوصول. لا يزال سلوك البحث والفهرسة والتحديث يعتمد على الوصول إلى التخزين وبيانات الاعتماد.
• Storage V3 مطلوب. في Milvus 3.0 مفتوحة المصدر، يجب تمكينه قبل استخدام المجموعة الخارجية.
• لا تحل المجموعة الخارجية محل المعالجة الأولية (upstream). لا يزال توليد التضمينات والتجميع وإزالة التكرار وتنظيف البيانات تحدث في الأنظمة الأولية المناسبة.

الخيار إذن تكاملي وليس ثنائيًا. يمكن للنظام استخدام مجموعات Milvus العادية للحالة عبر الإنترنت سريعة التغير، والمجموعات الخارجية لمجموعات البيانات الكبيرة المنتجة دفعاتٍ التي يكون موطنها الطبيعي هو البحيرة.

جرّب المجموعة الخارجية في Milvus 3.0

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

للحصول على تفاصيل التنفيذ، راجع:

• إنشاء مجموعة خارجية
• ملاحظات إصدار Milvus 3.0
• مدونة إطلاق Milvus 3.0

إذا كنت تفضل مسارًا مُدارًا، فالمجموعة الخارجية متاحة أيضًا كجزء من Zilliz Vector Lakebase في Zilliz Cloud. راجع:

• المجموعة الخارجية في Zilliz Cloud
• من قاعدة بيانات المتجهات إلى Vector Lakebase
• لماذا بنينا Vector Lakebase: إعادة التفكير في بنية البيانات غير المنظمة للذكاء الاصطناعي

يمكنك أيضًا طرح أسئلة التنفيذ أو تقديم ملاحظاتك إلى مستودع Milvus على GitHub أو مجتمع Milvus على Discord.