كيفية إعداد Lucene/Solr لتطبيق الويب B2B؟

Question

معطى:

• 1 قاعدة بيانات لكل عميل (عميل الأعمال)
• 5000 عميل
• لدى العملاء ما بين 2 إلى 2000 مستخدم (AVG هو ~ 100 مستخدم/عميل)
• 100 ألف إلى 10 ملايين سجل لكل قاعدة بيانات
• يحتاج المستخدمون إلى البحث في هذه السجلات في كثير من الأحيان (إنها أفضل طريقة للتنقل في بياناتهم)

ربما معلومات ذات صلة:

• العديد من العملاء الجدد كل أسبوع (في أي وقت خلال ساعات العمل)
• خوادم ويب متعددة وخوادم قاعدة البيانات (يمكن للمستخدمين تسجيل الدخول عبر أي خادم ويب)
• دعونا نبقى غير مؤلف من اللغة أو العلامة التجارية SQL ، لأن Lucene (و SOLR) لديها مجموعة كبيرة من الدعم

فمثلا:

قال جويل سبولسكي في بودكاست #11 أن منتج تطبيق الويب المستضاف الخاص به ، FogBugz At-Demand ، يستخدم Lucene. لديه الآلاف من العملاء عند الطلب. ويحصل كل عميل على قاعدة البيانات الخاصة بهم.

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

السؤال:

كيف يمكنك إعداد Lucene Search حتى لا يتمكن كل عميل من البحث إلا في قاعدة البيانات الخاصة به؟

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

الحلول الممكنة:

قم بعمل فهرس لكل عميل (قاعدة بيانات)

• PRO: البحث أسرع (من طريقة مؤتمر واحد للجميع). المؤشرات مرتبطة بحجم بيانات العميل.
• CON: لست متأكدًا مما يستلزمه هذا ، ولا أعرف ما إذا كان هذا يتجاوز نطاق Lucene.

احصل على فهرس عملاق واحد مع حقل database_name. قم دائمًا بتضمين Database_Name كمرشح.

• المحترف: لست متأكدا. ربما تكون جيدة للدعم الفني أو قسم الفواتير للبحث في جميع قواعد البيانات للحصول على معلومات.
• CON: البحث أبطأ (من طريقة الفهرس الفهرس). الأمان المعيب إذا تمت إزالة مرشح الاستعلام.

شيء أخير:
أود أيضًا أن أقبل إجابة تستخدم سولر (امتداد لوسين). ربما يكون الأمر أكثر ملاءمة لهذه المشكلة. لست متأكدا.

Answer 1

لقد استدعتني من fogbugz stackexchange. اسمي جود ، أنا مهندس البحث الحالي عن Fogbugz.

إليك مخططًا تقريبيًا لكيفية إعداد بنية البحث عن FogBugz on Demand [1]:

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

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

ببساطة ، ما لم يكن مجال البحث الخاص بك مميزًا جدًا أو كنت على استعداد لتكريس مطور للبحث السريع بشكل كبير ، فمن المحتمل أن تتفوق على منتج ممتاز مثل Elasticsearch أو Solr أو Xapian.

إذا كنت أفعل هذا اليوم ، ما لم يكن مجال البحث الخاص بي محددًا للغاية ، فربما سأستخدمه Elasticsearch ، Solr ، أو Xapian لحل البحث الكامل المدعوم من قاعدة البيانات الخاصة بي. بالنسبة إلى ذلك ، فإن هذا يعتمد على احتياجاتك المساعدة (النظام الأساسي ، ونوع الاستعلامات ، والتوسيع ، والتسامح مع مجموعة من المراوغات على أخرى ، وما إلى ذلك)

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

لست متأكدًا مما إذا كان ذلك قد أجاب على سؤالك ، لكنني آمل أن أكون على الأقل رضا فضولك :-)

1]: في عام 2013 ، بدأت Fogbugz في تشغيل قدرات البحث والتصفية مع Elasticsearch. نحن نحبه.

Answer 2

شالين شيخار مانغار أجابني على القائمة البريدية Solr-User وعن طريق البريد الإلكتروني الخاص. شالين مساهم في سولر ومؤلف الكتاب القادم SOLR في العمل.

رده على القائمة البريدية:

كيف يمكنك إعداد الفهرس (ES)؟

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

أين تقوم بتخزين الفهرس (ES)؟

لن يعمل إعداد 5K نوى على مربع واحد. لذلك ستحتاج إلى تقسيم العملاء إلى صناديق متعددة لكل منها مجموعة فرعية من النوى.

هل تحتاج إلى إضافة مرشح إلى جميع استفسارات البحث؟

كلا ، لكنك ستحتاج إلى إرسال الاستعلام إلى المضيف الصحيح (ربما سيساعد رسم خرائط DB)

إذا تم إلغاء عميل ، كيف يمكنك حذف (جزء من) فهرس)؟ (قد يكون هذا تافهة-وليس متأكدًا بعد)

مع وجود نوى مختلفة لكل عميل ، سيكون هذا سهلاً للغاية.

رده عبر البريد الإلكتروني:

لقد عملت على حالة استخدام مماثلة في الماضي واستخدمنا النهج متعدد النواة مع بعض التحسينات الثقيلة على جانب SOLR. نرى http://wiki.apache.org/solr/lotsofcores - لم أتمكن من دفع هذه التغييرات إلى SOLR حتى الآن.

Answer 3

ما زلت غير واضح بشأن ما هو بالضبط من قواعد بيانات 5K التي يبحث عنها المستخدمون ، ولماذا تحتاج إلى Lucene ، وأحجام البيانات في كل قاعدة بيانات. لكني سأضرب على أي حال:

1. يجب أن تنظر إلى SOLR متعدد الأزهار (كل مؤشر = 1) ولديك عنوان URL فريد للاستعلام. ستظل المصادقة مشكلة وطريقة واحدة (الاختراق) للاقتراب ، سيكون من الصعب تخمين عنوان URL.

2. يمكن لخور محفوظات الويب الخاص بك الاستعلام عن مثيل Solr/Core اعتمادًا على ما يمكنهم الوصول إليه.

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

HTH