jesterj

المهرج

نظام استيعاب مستندات مرن للغاية وقابل للتطوير ومتسامح مع الأخطاء ومصمم للبحث.

يتم تشغيل البنيات على البنية التحتية التي تم التبرع بها من قبل

المشكلة

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

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

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

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

حل JesterJ

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

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

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

راجع الموقع والوثائق لمزيد من المعلومات

ابدء

يرجى الاطلاع على الوثائق في الويكي

حالة المشروع

الإصدار الحالي : 1.0-Beta3. هذا هو الإصدار الأفضل للاستخدام، ويجب أن يكون عمليًا في الغالب. (المسألة المعروفة: #189)

الإصدار التالي: 1.0-Beta4 سيتم نشره قريبًا إذا لم يتم العثور على مشكلات خطيرة في غضون أسبوعين، سيتم إصدار 1.0.

ملاحظة: يستهدف الكود الحالي والإصدار 1.0 القادم أي تصميم وتحميل يمكن خدمته بواسطة جهاز واحد. تم تصميم JesterJ بشكل صريح للاستفادة من الأجهزة التي تحتوي على العديد من المعالجات. يمكنك تصميم خطتك باستخدام نسخ مكررة من أبطأ خطواتك لتخفيف الاختناقات. تتضمن كل نسخة مكررة مؤشر ترابط إضافي يعمل على تلك الخطوة. تم التخطيط للقياس التلقائي لسلاسل العمليات للإصدار 1.1 ويعتبر القياس عبر العديد من الأجهزة أولوية رئيسية لإصدارات 2.x. كما هو الحال دائمًا، إذا كنت تريد هذه الميزات عاجلاً، فيرجى بدء مناقشة والمساهمة في العلاقات العامة إذا كنت قادرًا!

إصدارات JDK

حاليًا، تم اختبار JDK 11 فقط بشكل منتظم. يجب أن يعمل أي توزيع لـ JDK 11. تم التخطيط لدعم Java 17 وإصدارات LTS المستقبلية للإصدارات المستقبلية.

خادم الخلاف

ناقش الميزات واطرح الأسئلة وما إلى ذلك على Discord: https://discord.gg/RmdTYvpXr9

سمات:

في هذا الإصدار لدينا الميزات التالية

• القدرة على تصور هيكل خطتك (تنسيق .dot أو .png: مثال من اختبارات الوحدة هنا)
• ماسح ضوئي بسيط لنظام الملفات لمحركات الأقراص المثبتة محليًا (استبدال post.jar)
• الماسح الضوئي JDBC (بديل لمعالج استيراد البيانات!)
• يمكن للماسحات الضوئية أن تتذكر المستندات التي شاهدتها (أو لا، العلامة المنطقية)
• يمكن للماسحات الضوئية التعرف على المحتوى المحدث (أو لا، العلامة المنطقية)
• أرسل إلى معالج Solr بأحجام دفعات قابلة للضبط
• معالج Tika لاستخراج المحتوى من Word/PDF/xml/html وما إلى ذلك (بديل لـ SolrCell!)
• معالج Stax extract لتشريح مستندات XML مباشرة.
• انسخ معالج الحقل لإعادة تسمية الحقول المصدر إلى حقل الفهرس المطلوب
• يستبدل Regexp المعالج لتحرير محتوى الحقل أو إسقاط الحقول غير المتطابقة
• تقسيم معالج الحقل لتقسيم القيم المحددة للحقول متعددة القيم
• قم بإسقاط المعالج الميداني للتخلص من الحقول الزائدة المزعجة.
• معالج القالب الميداني لتكوين محتوى الحقل باستخدام قالب السرعة
• معالج تشفير URL لتشفير قيمة الحقل وجعله آمنًا للاستخدام في عناوين URL
• جلب معالج URL للحصول على المحتوى أو تحسينه عن طريق الاتصال بالأنظمة الأخرى
• قم بتسجيل وإفلات المعالج عند تحديد مستند غير صالح
• معالج إعادة تنسيق التاريخ، لأن التواريخ، التنسيق... دائمًا. ( تنهد )
• معالج حجم الملف القابل للقراءة البشرية
• مرسل Solr لإرسال المستندات إلى Solr على دفعات.
• معالج التحليل المسبق لنقل عبء عمل تحليل Solr من Solr (فقط أعطه schema.xml الخاص بك!)
• خادم Cassandra المضمن (لا حاجة لتثبيت cassandra بنفسك!)
• تكوين Cassandra وموقع البيانات قابلان للتكوين، والإعدادات الافتراضية هي ~/.jj/cassandra
• دعم أحداث تغيير حالة كتابة التسامح مع الخطأ إلى خادم cassandra المضمن
• واجهة برمجة التطبيقات/العملية الأولية لمعالجات المستندات المكتوبة بواسطة المستخدم. (انظر الوثائق)
• تغطية الاختبار 60% (جاكوكو)
• ملف Java واحد بسيط لتكوين كل شيء، يحتاج المبرمجون الذين لا يستخدمون Java إلى اتباع مثال بسيط فقط (لحالات الاستخدام التي لا تتطلب تعليمات برمجية مخصصة)
• إذا كنت بحاجة إلى رمز مخصص، فيمكن حزم هذا الرمز باعتباره uno-jar لتوفير جميع التبعيات المطلوبة والهروب من أي إصدارات مكتبة يستخدمها JesterJ! ما عليك سوى التعامل مع جحيمك الخاص، وليس جحيمنا! بالطبع، يمكنك أيضًا الاعتماد على ما نقدمه بالفعل أيضًا. تفضل أدوات تحميل الفصل للكود المخصص uno-jar الخاص بك ثم تعود افتراضيًا إلى كل ما يتوفر في JesterJ على مسار الفصل الخاص به.
• مثال قابل للتشغيل لتنفيذ خطة تقوم بمسح نظام الملفات وفهرسة المستندات في solr.

TODO للإصدار 1.0 النهائي

• القضايا المتبقية
• إصدار بيتا، اختبار.

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

خريطة الطريق

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