هل يجب تحسين الفهرس بعد الفهارس الإضافية في لوسين؟

Question

نقوم بإجراء عمليات إعادة فهرسة كاملة كل 7 أيام (أي.إنشاء الفهرس من الصفر) على فهرس Lucene الخاص بنا والفهارس الإضافية كل ساعتين أو نحو ذلك.يحتوي فهرسنا على حوالي 700000 مستند ويستغرق الفهرس الكامل حوالي 17 ساعة (وهي ليست مشكلة).

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

ال لوسينالأسئلة الشائعة يذكر أن:

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

...ولكن يبدو أن هذا لا يعطي أي تعريف لما تعنيه كلمة "في كثير من الأحيان".يتطلب التحسين استخدام وحدة المعالجة المركزية (CPU) ومكثفًا للغاية لعمليات الإدخال/الإخراج، لذلك نفضل عدم القيام بذلك إذا تمكنا من الإفلات من العقاب.ما مدى نجاح تشغيل الاستعلامات على فهرس غير محسّن (أفكر بشكل خاص فيما يتعلق بأداء الاستعلام بعد إعادة الفهرسة الكاملة مقارنةً بعد 20 فهرسًا إضافيًا حيث تم تغيير 50000 مستند على سبيل المثال)؟هل ينبغي لنا أن نقوم بالتحسين بعد كل مؤشر تزايدي أم أن الأداء الذي حققناه لا يستحق كل هذا العناء؟

Answer 1

مات، نظرًا لأنه يبدو أن لديك فكرة جيدة عن المدة التي تستغرقها عمليتك الحالية، أقترح عليك إزالة ملف optimize() وقياس التأثير.

هل تتغير العديد من المستندات خلال فترتي الساعتين؟إذا تمت إعادة فهرسة جزء صغير فقط (50000/700000 حوالي 7٪)، فلا أعتقد أنك تحصل على قيمة كبيرة من optimize().

بعض الافكار:

• لا تفعل تزايدي optimize() على الاطلاق.تقول تجربتي أنك لا ترى تحسنًا كبيرًا في الاستعلام على أي حال.
• افعل optimize() يوميا بدلا من ساعتين.
• افعل optimize() خلال أوقات انخفاض الحجم (وهو ما javadoc يقول).

وتأكد من أخذ القياسات.هذه الأنواع من التغييرات يمكن أن تكون بمثابة طلقة في الظلام بدونها.

Answer 2

ان optimize تقوم العملية بقراءة الفهرس بأكمله وكتابته، ولهذا السبب فهي مكثفة جدًا لعمليات الإدخال والإخراج!

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

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

نظرًا لأن أداء الاستعلام يرتبط ارتباطًا وثيقًا بعدد الأجزاء في الفهرس الخاص بك، فإن الأمر بسيط ls -1 index/segments_* | count يمكن أن يكون مؤشرًا مفيدًا عندما تكون هناك حاجة فعلية للتحسين.

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

Answer 3

في هذا البريد, ، نصائح أوتيس Gospodnetic ضد باستخدام التحسين، إذا كان الفهرس الخاص بك يرى تحديثات مستمرة.انها من عام 2007، ولكن الدعوة optimize() هي بطبيعتها عملية IO ثقيلة.يمكنك التفكير في استخدام نهج أكثر تدريجيًا؛أ MergeScheduler