Какие проблемы возникают при внедрении текстового поиска (Lucene / Solr / Hibernate Search) в приложения, размещенные на клиентских сайтах - PullRequest
0 голосов
/ 22 марта 2011

У нас есть корпоративное java-приложение, которое наши клиенты (внешние) развертывают в своих интрасетях.Я изучаю различные варианты полнотекстового поиска: Lucene / Solr / Hibernate Search, и одна общая проблема - это издержки на развертывание / администрирование / настройку для этого.

Это особенно сложно в нашем случае, поскольку мы не размещаем эти приложения.Из того, что я видел, большинство использований этих технологий было в размещенных приложениях.Наши клиенты обычно разворачивают наше приложение в кластерной среде и не имеют никакого опыта работы с Lucene / Solr.

У кого-нибудь есть опыт с этим?С какими проблемами вы столкнулись при таком подходе?Как вы их преодолели?На данный момент я пытаюсь определить, возможно ли это.

Спасибо

Ответы [ 2 ]

0 голосов
/ 15 апреля 2013

Есть два преимущества для встраивания lucene в ваше приложение по сравнению с отправкой запросов в отдельный кластер Solr: производительность и простота развертывания / установки.Встраивание lucene означает запуск lucene в той же JVM, что означает отсутствие дополнительных обращений к серверу.Коммиты должны быть упакованы в отдельную ветку.Встраивание lucene также означает включение еще нескольких JAR-файлов в путь к классу, поэтому отдельная установка для Solr не требуется.

Если ваше приложение поддерживает кластер, тогда опция встроенного lucene становится очень проблематичной.Обновление для одного узла в кластере должно быть доступно для поиска из любого узла в кластере.Синхронизация индекса lucene на всех узлах не дает лучшей производительности, чем использование Solr.С Solr 4 вы можете обнаружить, что администрация не станет препятствием для входа ваших клиентов.Ознакомьтесь с литературой о грубо названном Solr Cloud.

0 голосов
/ 27 марта 2011

Очень возможно развертывать приложения на клиентских сайтах, которые используют Lucene (или Solr).

Некоторые вещи, которые следует иметь в виду: Администрирование

  • вам нужен способ создания версии индекса, поэтому, если / когда вы измените структуру документа
    в индексе, он может быть
    обновлен.
  • , поэтому вам нужен хороший способ принудительно переиндексировать все существующие данные.Вероятно, также хорошая идея предоставить опцию Admin, чтобы позволить Admin также инициировать переиндексацию.
  • Вы также можете предоставить опцию администратора, чтобы позволить optimize () вызываться для вашего индекса, или запланировать это.Лучше всего проверить фактическое влияние, которое это окажет в первую очередь, поскольку оно может не потребоваться в зависимости от формы вашего индекса

Deployement Если вы развертываете в кластерную среду,Самое простое (и самое быстрое с точки зрения скорости разработки и скорости выполнения) решение может состоять в создании индекса для каждого узла.

Настройка * У вас есть разумное приближение к набору данных, которым вы будетеиндексация?Вам необходимо убедиться, что вы понимаете, как масштабируется ваш индекс (как по скорости, так и по размеру), поскольку то, что вы считаете разумным размером набора данных, может не совпадать с вашими клиентами ... Следовательно, вам, по крайней мере, нужно датьклиенты знают, какие факторы приведут к чрезмерно большому размеру индекса и, возможно, к снижению производительности.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...