استراتيجيات للحفاظ على تحديث مؤشر لوسين مع تغييرات نموذج المجال

Question

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

التطبيق المعني هو تطبيق ويب يستند إلى Java/J2EE يستخدم السبات.الطريقة التي أعمل بها حاليًا هي أن كائنات نموذج Hibernate المعينة جميعها تنفذ واجهة مشتركة "قابلة للفهرسة" يمكنها إرجاع مجموعة من أزواج المفاتيح/القيمة المسجلة في Lucene.عندما يتم تنفيذ عملية CRUD تتضمن مثل هذا الكائن، أقوم بإرساله عبر قائمة انتظار JMS إلى حبة مدفوعة بالرسائل تسجل في Lucene المفتاح الأساسي للكائن وأزواج المفتاح/القيمة التي يتم إرجاعها من طريقة الفهرس () للكائن القابل للفهرسة الذي تم متاح.

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

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

Answer 1

تغيير الرسالة:فقط قم بتوفير المفتاح الأساسي والتاريخ الحالي، وليس أزواج المفتاح/القيمة.يقوم mdb الخاص بك بجلب الكيان عن طريق المفتاح الأساسي ويستدعي الفهرس ().بعد الفهرسة قمت بتعيين قيمة "محدث" في الفهرس الخاص بك لتاريخ الرسالة.يمكنك تحديث الفهرس الخاص بك فقط إذا كان تاريخ الرسالة بعد الحقل "المحدث" للفهرس.بهذه الطريقة لا يمكنك التأخر لأنك تقوم دائمًا بإحضار أزواج المفتاح/القيمة الحالية أولاً.

كبديل:القي نظرة على http://www.compass-project.org.

Answer 2

الإجابة المقبولة عمرها 8 سنوات الآن وقديمة جدًا.

لم يعد مشروع Compass قيد الصيانة منذ فترة طويلة، حيث انتقل مطوره الرئيسي إلى إنشاء Elasticsearch الممتاز.

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