من الاسترجاع إلى النتائج المُهيكلة: التجميع وORDER BY في Milvus 3.0

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

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

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

كانت قاعدة البيانات المتجهية تعثر على المرشحين؛ وكان على التطبيق تحويلهم إلى نتيجة منظمة.

ينقل Milvus 3.0 المزيد من هذا العمل إلى محرك الاسترجاع. ويضيف ثلاث قدرات مترابطة لكنها متميزة:

• تجميع الاستعلامات يحسب count وsum وavg وmin وmax على الصفوف المرئية والمفلترة، مع حقول GROUP BY اختيارية.
• تجميع البحث ينظم مرشحي أقرب الجيران التقريبيين (ANN) المحتفظ بهم في دلاء، ويحسب مقاييس لكل دلو، ويبني دلاء متداخلة، ويعيد نتائج تمثيلية.
• من جانب الخادم يفرز **ORDER BY** نتائج الاستعلام أو مرشحي ANN حسب حقل قياسي واحد أو أكثر قبل أن يتلقاها التطبيق.

التمييز بين الاستعلام والبحث مهم:

القدرة	البيانات التي يجري تلخيصها أو ترتيبها	الشكل الأساسي للنتيجة	حدود الدقة
تجميع الاستعلامات	كل الصفوف المرئية التي تطابق عامل التصفية	صف واحد لكل مجموعة، مع قيم تجميعية	دقيق على مجموعة الصفوف المرئية للاستعلام
تجميع البحث	المرشحون المحتفظ بهم عبر بحث ANN ومرحلة التجميع	دلاء، ومقاييس، ونتائج تمثيلية، ودلاء فرعية اختيارية	تقريبي بطبيعته
ORDER BY في الاستعلام	الصفوف المرئية التي تطابق عامل التصفية	صفوف مرتبة	دقيق على نتيجة الاستعلام المفلترة
ORDER BY في البحث	مرشحو ANN	نتائج بحث أو مجموعات مرتبة	لا يوسّع حدود استدعاء ANN

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

لماذا ينهار ما بعد المعالجة من جانب التطبيق

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

ينقل التطبيق بيانات أكثر بكثير مما تحتويه الإجابة

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

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

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

الفرز المحلي للصفحة ليس فرزًا عالميًا

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

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

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

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

لا يستطيع العميل إعادة إنتاج رؤية قاعدة البيانات

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

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

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

والآن، لنلقِ نظرة على ما يقدمه Milvus 3.0.

تجميع الاستعلامات: إحصاءات دقيقة على الصفوف المرئية

يجيب تجميع الاستعلامات عن أسئلة مثل:

• كم عدد المنتجات المتاحة في المخزون في كل فئة؟
• ما متوسط السعر لكل علامة تجارية؟
• ما الحد الأدنى والحد الأقصى للطوابع الزمنية للأحداث لكل مضيف؟
• كم عدد السجلات المتبقية بعد تطبيق عامل تصفية ورؤية TTL؟

تبدو واجهة API مألوفة لأي شخص استخدم SQL: مرّر حقلًا واحدًا أو أكثر في group_by_fields، ثم ضع تعبيرات التجميع في output_fields.

res = client.query(
    collection_name="products",
    filter='status == "on_sale"',
    group_by_fields=["category"],
    output_fields=["category", "count(*)", "avg(price)"],
)
# [
#     {"category": "books", "count(*)": 18734, "avg(price)": 45.3},
#     …
# ]

الصياغة هي الجزء البسيط. أما نموذج التنفيذ فهو ما يجعل النتيجة مفيدة في قاعدة بيانات متجهية موزعة.

تحل الحالات المحلية للمقاطع محل نقل الصفوف الخام

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

لذلك يدفع Milvus التجميع إلى المقاطع:

1. يطبق كل مقطع عامل التصفية وقواعد رؤية MVCC محليًا.
2. يصدر المقطع حالة جزئية واحدة لكل مجموعة بدلًا من صفوفه المطابقة.
3. تُدمج الحالات الجزئية داخل عقدة الاستعلام.
4. ينفذ الوكيل الدمج النهائي عبر العقد ويعيد المجموعات المكتملة.

يتوسع مقدار البيانات الوسيطة الآن مع عدد المجموعات وحالات التجميع، بدلًا من التوسع مباشرة مع عدد الصفوف المطابقة.

تعتمد عملية الدمج على التجميع:

التجميع	الحالة الجزئية	قاعدة الدمج
count	عدد جزئي	إضافة الأعداد
sum	مجموع جزئي	إضافة المجاميع
min	حد أدنى جزئي	أخذ الحد الأدنى
max	حد أقصى جزئي	أخذ الحد الأقصى
avg	مجموع وعدد جزئيان	إضافة كلتا الحالتين، ثم القسمة مرة واحدة في المرحلة النهائية

avg هي الحالة التعليمية. فحساب متوسط متوسطين جزئيين غير صحيح عندما تحتوي الأقسام على أعداد مختلفة من الصفوف. يحمل Milvus sum وcount بشكل مستقل ويحسب المتوسط النهائي فقط بعد دمج كليهما عالميًا.

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

تُطبّق الرؤية قبل التجميع

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

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

أصبح limit يحسب المجموعات

في الاستعلام العادي، يتحكم limit في عدد صفوف الكيانات التي تُعاد. في الاستعلام المجمّع، يتحكم في عدد المجموعات التي تُعاد. ولأن عدد النتائج يُحدد بالمجموعات بدلًا من الصفوف المطابقة، يمكن لتجميع الاستعلام أيضًا حذف limit عندما يحتاج إلى كل مجموعة.

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

تجميع البحث: عرض قائم على الدلاء لمرشحي ANN

يجيب تجميع الاستعلامات عن سؤال: “كيف تبدو الصفوف المرئية المطابقة لهذا الفلتر؟” أما تجميع البحث فيطرح سؤالًا مختلفًا: “كيف تبدو مجموعة المرشحين المسترجعة لهذا المتجه؟”

لا توجد لهذه العملية مكافئة SQL دقيقة. يبدأ بحث ANN بإنشاء حدود مرشحين مدفوعة بالتشابه. ثم ينظم Milvus المرشحين المحتفظ بهم حسب مفاتيح قياسية ويعيد شجرة دلاء بدلًا من قائمة نتائج مسطحة عادية.

يمكن أن يحتوي الدلو على:

• مفتاح مثل brand أو مفتاح مركب مثل (brand, color)؛
• عدد المرشحين المحتفظ بهم؛
• مقاييس تشمل count وsum وavg وmin وmax؛
• كيانات تمثيلية مختارة باستخدام top_hits؛ و
• sub_aggregation متداخل ينشئ دلاء فرعية.

بالنسبة لصفحة البحث عن المنتجات، يمكن لطلب واحد إرجاع دلاء العلامات التجارية، ومتوسط السعر داخل كل دلو، وثلاثة منتجات تمثيلية لكل علامة تجارية:

from pymilvus import SearchAggregation, TopHits
aggregation = SearchAggregation(
fields=[“brand”],
size=10,                                    # Return up to 10 brand buckets
metrics={“avg_price”: {“avg”: “price”}},
order=[{“_count”: “desc”}],               # Order by retained-candidate count
top_hits=TopHits(
size=3,
sort=[{“_score”: “desc”}],            # Use “asc” for L2 distance
),
)
res = client.search(
collection_name=“products”,
data=[query_vector],
anns_field=“embedding”,
search_aggregation=aggregation,
output_fields=[“title”, “brand”, “price”],
)
buckets = res.agg_buckets[0]

عند تعيين search_aggregation، تكون قائمة النتائج العادية فارغة. يقرأ التطبيق استجابة الدلاء من result.agg_buckets.

تحدد مواصفة التجميع حدين مختلفين

لا يشغل تجميع البحث GROUP BY على كل كيان في المجموعة، ولا يأخذ ببساطة استجابة Top-K عادية ويجمع تلك القائمة المسطحة.

يتكون تنفيذه من ثلاث مراحل:

1. يشغّل Milvus بحث ANN لاسترجاع المرشحين القريبين من متجه الاستعلام.
2. تحتفظ مرحلة التجميع بعدد محدود من المرشحين لكل مفتاح دلو كامل.
3. يبني Milvus الدلاء، ويحسب المقاييس على المرشحين المحتفظ بهم، ويرتب الدلاء، ويرفق نتائج تمثيلية أو دلاء فرعية.

يتحكم معلمان في أجزاء مختلفة من النتيجة:

• SearchAggregation.size يحد من عدد الدلاء التي تُعاد عند مستوى التجميع ذلك.
• أكبر TopHits.size في أي مكان في شجرة التجميع يحدد ميزانية المرشحين المحتفظ بهم لكل مفتاح مركب كامل. إذا لم يتضمن الطلب أي top_hits، تكون الميزانية الافتراضية لكل مفتاح واحدًا.

لا يتحكم limit الخاص بالبحث على المستوى الأعلى في هذا الوضع ويتم تجاهله عند وجود search_aggregation.

هذا التمييز أساسي عند قراءة count أو المقاييس الخاصة بدلو. مع TopHits(size=3)، يمكن لدلو علامة تجارية أن يلخص على الأكثر ثلاثة مرشحين محتفظًا بهم لمفتاحه الكامل، حتى لو كانت المجموعة تحتوي على آلاف المنتجات ذات الصلة من تلك العلامة التجارية. زيادة TopHits.size توسّع نافذة المقاييس لكل مفتاح، لكنها لا تحول بحث ANN إلى مسح دقيق.

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

تجميع البحث والبحث بالتجميع يحلان مشكلات مختلفة

دعم Milvus البحث بالتجميع (group_by)منذ Milvus 2.4. من السهل رؤية كلمة “تجميع” في الميزتين وافتراض أنهما واجهتان للعملية نفسها. لكن عقود المخرجات مختلفة.

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

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

حاجة التطبيق	الأفضلية	الاستهلاك
قائمة كيانات مرتبة مع تنوع أكبر عبر حقل	البحث بالتجميع	نتائج البحث العادية
أعداد الواجهات، أو مقاييس لكل مجموعة، أو نتائج تمثيلية، أو توزيعات متداخلة	تجميع البحث	كائنات AggregationBucket في result.agg_buckets

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

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

ORDER BY: انقل الفرز إلى ما قبل حدود التطبيق

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

يعرض Milvus 3.0 الفرز في كل من الاستعلام والبحث، لكن المسارين يستخدمان معاملات SDK مختلفة ويعملان على مجموعات إدخال مختلفة.

فرز الاستعلام يرتب مجموعة الصفوف المفلترة

يستخدم استعلام PyMilvus order_by، معبرًا عنه كقائمة من سلاسل "field:direction". يطبق المحرك عامل التصفية، ويرتب الصفوف المرئية، ثم يطبق limit وoffset.

res = client.query(
    collection_name="products",
    filter='category == "books"',
    output_fields=["title", "price"],
    order_by=["price:desc", "title:asc"],
    limit=10,
    offset=10,  # Rows 11-20 in the filtered, price-sorted result
)

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

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

فرز البحث يعيد ترتيب مجموعة مرشحي ANN

يستخدم بحث PyMilvus order_by_fields، حيث يسمي كل إدخال حقلًا قياسيًا واتجاهًا:

res = client.search(
    collection_name="products",
    data=[query_vector],
    anns_field="embedding",
    limit=50,
    output_fields=["title", "price"],
    order_by_fields=[
        {"field": "price", "order": "asc"},
    ],
)

لا يزال ANN يحدد أي الكيانات تصبح مرشحة. يغيّر order_by_fields طريقة إرجاع أولئك المرشحين؛ ولا يجعل البحث يمسح المجموعة عالميًا للعثور على أرخص المنتجات.

يمنح ذلك الحد واجهتي API وظيفتين متميزتين:

• استخدم الاستعلام مع order_by عندما يحدد الترتيب القياسي نفسه النتيجة، مثل أرخص عشرة منتجات متاحة في المخزون.
• استخدم البحث مع order_by_fields عندما تحدد الصلة الدلالية أو المتجهية مجموعة المرشحين ويحدد حقل قياسي كيفية عرض هؤلاء المرشحين.

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

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

ما الذي تتيحه هذه القدرات

واجهات API هي بدائيات عامة لقواعد البيانات، لكن عدة أعباء عمل للاسترجاع تستفيد منها فورًا.

RAG والوكلاء: فحص تركّز الاسترجاع

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

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

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

التجارة الإلكترونية وتوصية المحتوى: إرجاع الواجهات مع البحث

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

السجلات والأمان: الجمع بين التشابه وتوزيع الحوادث

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

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

العمليات واستكشاف البيانات: احسب بدلًا من التصدير

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

الحدود: ما الذي لا يستبدله التجميع وORDER BY

توسّع هذه الميزات محرك الاسترجاع؛ لكنها لا تحول Milvus إلى نظام معالجة تحليلية عبر الإنترنت (OLAP).

• يدعم تجميع الاستعلامات التجميع مع count وsum وavg وmin وmax. ولا يضيف عمليات ربط أو دوال نافذة أو استعلامات فرعية معقدة. لا تزال الوظائف التحليلية الكبيرة غير المتصلة تنتمي إلى أنظمة مثل Spark، التي يمكنها العمل مع لقطات Milvus 3.0 ومسارات التخزين المشتركة.
• تدعم مفاتيح مجموعات الاستعلام حقول الأعداد الصحيحة وVARCHAR وTIMESTAMPTZ. وتدعم مفاتيح دلاء تجميع البحث أيضًا الحقول المنطقية. لا تُعد قيم الفاصلة العائمة أو المتجهات أو JSON أو المصفوفات مفاتيح دلاء.
• بالنسبة لتجميع البحث، يقبل count "*" أو مصدرًا غير JSON وغير ديناميكي؛ ويتطلب sum وavg مصادر رقمية؛ ويدعم min وmax أيضًا مصادر السلاسل وTIMESTAMPTZ. يتبع تجميع الاستعلامات حدود الأنواع الحسابية نفسها. راجع دليل API قبل تطبيق تجميع على نوع حقل معقد.
• يمكن لتجميع الاستعلامات ترتيب الناتج المجمّع حسب مفاتيح المجموعات، بينما يبقى الترتيب حسب تجميع محسوب مثل count(*) حدًا حاليًا. وبدون ترتيب صريح، لا يكون ترتيب المجموعات مضمونًا.
• لا يمكن حاليًا دمج تجميع البحث مع البحث الهجين، أو البحث بالتجميع، أو مكررات البحث، أو إزاحة غير صفرية، أو التمييز في الطلب نفسه.
• تصف أعداد ومقاييس تجميع البحث مرشحي ANN المحتفظ بهم، وليس المجموعة الكاملة ولا كل كيان قد يكون ذا صلة دلاليًا.
• يغيّر ORDER BY في البحث طريقة عرض المرشحين. ولا يصلح مرشحي ANN المفقودين أو يحول الاسترجاع بالتشابه إلى استعلام Top-N قياسي دقيق.

أنظف طريقة للاختيار بين البدائيات الجديدة هي البدء بالسؤال:

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

من قوائم المرشحين إلى نتائج منظمة

حسّنت قواعد البيانات المتجهية تقليديًا سؤالًا واحدًا: أي K كيانات هي الأقرب إلى هذا المتجه؟

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

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

ليست النتيجة محرك OLAP مخفيًا داخل قاعدة بيانات متجهية. بل هي محرك استرجاع يستطيع إرجاع المزيد من البنية التي تحتاجها التطبيقات فعليًا.

جرّب التجميع وORDER BY في Milvus 3.0

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

للاطلاع على الإصدار الأوسع، راجع مدونة إطلاق Milvus 3.0، وملاحظات إصدار Milvus 3.0، ومستودع milvus-io/milvus.

إذا كنت تريد تقييم واجهات API نفسها دون تشغيل العنقود بنفسك، فجرّبها على Zilliz Cloud. يصف مرجع استعلام Zilliz Cloud الحالي ومرجع البحث التوفر والمعلمات لأنواع العناقيد المُدارة.

لمناقشة عبء عمل أو حالة طرفية مع الفريق، انضم إلى مجتمع Milvus على Discord أو احجز جلسة Milvus Office Hours.