Elasticsearch / الأساسي: عقود المستندات والاستعلامات / الدرس 1
المستندات والفهارس وظهورها للبحث
حدّد موضع طلب بحث في مقتنيات متحف ضمن Elasticsearch، وميّز إقرار قبول الفهرسة عن ظهور المستند في نتائج البحث.
في هذه الصفحة
أهداف الدرس
- اشرح هوية المستند وحدود الفهرس ومعنى الأجزاء.
- ميّز refresh وديمومة الكتابة والجلب الفوري بالمعرّف.
فهرس البحث نموذج مشتق للتطبيق
قد تحتفظ مجموعة مقتنيات المتحف بسجلات الاقتناء المعتمدة في نظام معاملاتي، بينما يستخدم التطبيق Elasticsearch للبحث في أوصاف القطع. المستند هو تمثيل بصيغة JSON أُعدّ لخدمة هذا البحث؛ ولا يصبح تلقائياً بديلاً كاملاً لنظام السجل المعتمد. حدّد كيف تُبنى نسخة البحث، وكيف تصل التحديثات إليها، وما مقدار التأخر الذي يقبله المنتج. خزّن هوية القطعة الثابتة حتى يمكن الانتقال من نتيجة البحث إلى تفاصيلها المعتمدة. وإذا قالت النتيجة إن قطعة متاحة، فإن حداثة هذه المعلومة لا تتجاوز حداثة مسار إدخال البيانات. لذلك يجب على التطبيق إعادة التحقق من قرارات الحجز أو الملكية المهمة لدى النظام الذي يملك سلطة اعتمادها.
يحدد الفهرس والمعرّف الهدف
يضم الفهرس مستندات مترابطة، ويحدد تعيين الحقول فيه كيفية التعامل مع كل حقل. يمكن أن توجد قيمة _id نفسها في فهارس مختلفة، لذلك احتفظ بسياق الفهرس أو المجموعة المنطقية عند تفسير النتيجة. جسم المستند التوضيحي هنا مخصص للطلب PUT museum-artifacts-v1/_doc/art-101. تجعل الهوية الصريحة معنى الاستبدال قابلاً للمراجعة. أما المعرّفات التي يولدها النظام تلقائياً فقد تلائم بعض الأحداث التي تُضاف دون تعديل، لكنها تصعّب اكتشاف تسليم الحدث نفسه مرتين. في العناقيد ذات الإصدارات المحددة، يوزع Elasticsearch الفهرس على أجزاء أساسية ونسخ متماثلة منها. الجزء وحدة توزيع مادية، وليس علاقة بين جداول الأعمال ولا حداً مستقلاً لتفويض مستخدمي التطبيق.
{"artifact_id":"art-101","title":"Bronze navigation compass","status":"displayed","year":1890}هذا مستند مصدر اصطناعي يحمل معرّفاً ثابتاً في مجموعة المقتنيات. المعروض جسم طلب فقط، ولم يُرسل إلى أي خدمة.
الإقرار لا يعني ظهوراً فورياً في البحث
يعمل البحث في Elasticsearch وفق نموذج قريب من الزمن الحقيقي. لا يعني نجاح استجابة الفهرسة أن البحث التالي سيرى المستند فوراً؛ إذ تتيح عملية refresh التغييرات الحديثة للبحث. وتختلف رؤية طلب GET الفوري بالمعرّف عن رؤية استعلام البحث. كذلك تختلف refresh عن flush وعن ضمانات ديمومة البيانات في مسار الكتابة. لا تستخدم هذه المصطلحات بالتبادل عند تفسير تأخر نتيجة. في الأساس التعليمي 8.19، تُجرى refresh دورياً عادة للفهرس العادي النشط، لكن الإعدادات ونموذج النشر قد يغيران التوقيت. ولهذا لا تعد هذه الدورة بظهور البيانات خلال ثانية واحدة من بداية مسار الإدخال إلى نهايته.
اقرأ الاستجابة كدليل محدد النطاق
قد تتضمن الاستجابة الحقول _index و_id و_version و_seq_no و_primary_term ومعلومات الأجزاء. تحدد هذه البيانات العملية المقبولة وتساعد في ضبط التزامن، لكن القيم المعروضة في أي مثال ليست ثوابت تصلح لكل نشر. حُذفت من الاستجابة المبسطة أدناه عمداً بيانات التعريف التي تعتمد على البيئة. تختلف النتيجة created عن updated، وقد تنتهي مهلة الاتصال قبل أن يعرف العميل هل قَبِل الخادم العملية. احتفظ بهوية المستند المقصودة قبل إعادة المحاولة. فإذا ولّد العميل معرّفاً جديداً في كل مرة، فقد ينشئ مستندات مكررة رغم أن كل طلب بمفرده يحتوي JSON صحيحاً.
{"_index":"museum-artifacts-v1","_id":"art-101","result":"created"}هذه استجابة تخطيطية لكتابة أولى ناجحة، وليست مخرجات Elasticsearch جُمعت أثناء العمل. وعند استبدال مستند قائم، تكون النتيجة المعتادة updated.
افصل نموذج الخادم عن المشروع المدار
تستخدم هذه الدورة دلالات مرجع الإصدار 8.19 للفهرسة العادية وواجهات البرمجة التي لا تستخدم أنواع التعيين القديمة. ولا تدعي أن 8.19 هو أحدث إصدار، ولا تحدد مدة دعمه. تمثل Elastic Cloud Serverless نموذج مشاريع مستمر التحديث، وله مسؤوليات بنية تحتية وإعدادات مدعومة تختلف عن العنقود ذي الإصدار المحدد؛ فلا تنقل إليه إجراءات إدارة العقد والأجزاء كما هي. وتختلف أيضاً قسمة المسؤوليات بين النشر الذاتي وHosted وECK وECE. حدّد إصدار الخادم الفعلي والاشتراك قبل تطبيق المثال. جميع الطلبات هنا تحمل runnable:false، ولم يُتصل بأي عنقود أو حساب سحابي أو عنوان خدمة مهيأ.
الأخطاء الشائعة وإصلاحها
يغيب المستند الجديد عن نتائج البحث
- لماذا يحدث؟
- قُبلت الكتابة، لكن لم تحدث refresh مناسبة تتيحها للبحث بعد.
- كيف تصلحه؟
- قارن هوية المستند والفهرس المستهدف وتوقعات الرؤية قبل تعديل البيانات.
- كيف تتجنب تكراره؟
- حدّد عقد حداثة البحث، وتجنب فرض refresh بعد كل حدث.
index_not_found_exception
- لماذا يحدث؟
- يسمي الطلب فهرساً غير موجود، أو لا يستطيع الحساب الوصول إلى الفهرس المقصود.
- كيف تصلحه؟
- تحقق من اسم الفهرس أو الاسم البديل الموثق، ومن الحساب المصرح له باستخدامه.
- كيف تتجنب تكراره؟
- اجعل أسماء الأهداف الخاصة بكل بيئة صريحة في الإعدادات.
تنشئ إعادة المحاولة قطعاً مكررة
- لماذا يحدث؟
- خصصت كل إعادة إرسال معرّفاً جديداً للعنصر التجاري نفسه.
- كيف تصلحه؟
- طابق السجلات باستخدام هوية القطعة الثابتة، واختر معنى الكتابة المقصود صراحة.
- كيف تتجنب تكراره؟
- ضمّن التسليم المكرر ضمن حالات مراجعة تصميم الإدخال.
اختبر فهمك
1. لماذا قد يجد GET بالمعرّف قطعة لا يجدها البحث في العنوان بعد؟
اعرض الحل المشروح
للعمليتين ضمانات رؤية مختلفة. قد يرى GET الفوري كتابة قُبلت قبل أن تتيح refresh تلك الكتابة للبحث. تحقّق أولاً من أن الطلبين يستخدمان الفهرس والمعرّف نفسيهما، ثم افحص توقعات refresh وتعيين الحقل المستخدم في البحث كلّاً على حدة. لا تستنتج فقدان مستند المصدر من بحث واحد أُجري مبكراً.
2. هل يمثل الجزء الأساسي قسماً واحداً من أقسام المتحف؟
اعرض الحل المشروح
لا. توزع الأجزاء بيانات الفهرس، ولا تتبع ملكية أقسام العمل تلقائياً. يجب تصميم شرط القسم أو قاعدة التفويض صراحة. وقد يغير التوجيه موضع البيانات، لكنه لا يحل محل التحكم في الوصول. أبقِ هوية مجموعة المقتنيات المنطقية منفصلة عن طريقة توزيعها المادي.
أهم ما تعلمته
- هوية المستند وديمومة الكتابة ورؤية البحث عقود مستقلة.
- يحدد نموذج النشر الأمثلة التشغيلية التي يمكن تطبيقها.