Как настроить Lucene / Solr для веб-приложения B2B? - PullRequest
5 голосов
/ 25 апреля 2010

Дано:

  • 1 база данных на клиента (бизнес-клиент)
  • 5000 клиентов
  • Клиенты имеют от 2 до 2000 пользователей (в среднем ~ 100 пользователей / клиент)
  • от 100 000 до 10 миллионов записей на базу данных
  • Пользователи должны часто искать эти записи (это лучший способ навигации по своим данным)

Возможно, актуальная информация:

  • Несколько новых клиентов каждую неделю (в любое время в рабочее время)
  • Несколько веб-серверов и серверов баз данных (пользователи могут войти через любой веб-сервер)
  • Давайте не будем зависеть от языка или бренда sql, поскольку Lucene (и Solr) имеют широкую поддержку

Например:

Джоэл Спольски сказал в Podcast # 11 , что его хост-продукт FogBugz On-Demand использует Lucene. У него тысячи клиентов по требованию. И каждый клиент получает свою базу данных.

Они используют индекс для каждого клиента и сохраняют его в базе данных клиента . Я не уверен в деталях. И я не уверен, что это серьезный мод для Lucene.

Вопрос:

Как бы вы настроили поиск Lucene, чтобы каждый клиент мог выполнять поиск только в своей базе данных?

Как бы вы настроили индекс (ы)?
Где вы храните индекс (ы)?
Вам нужно добавить фильтр ко всем поисковым запросам?
Если клиент отменил, как бы вы удалили его (часть) индекс? (это может быть тривиально - пока не уверен)

Возможные решения:

Создание индекса для каждого клиента (базы данных)

  • Pro: поиск выполняется быстрее (чем метод одного индекса для всех). Индексы относятся к размеру данных клиента.
  • Con: Я не уверен, что это влечет за собой, и я не знаю, выходит ли это за рамки Lucene.

Иметь один гигантский индекс с полем database_name. Всегда включайте database_name в качестве фильтра.

  • Pro: не уверен. Может быть, хорошо для технической поддержки или отдела выставления счетов для поиска информации во всех базах данных
  • Con: Поиск медленнее (чем метод индекса на клиента). Ошибка безопасности, если фильтр запросов удален.

И последнее:
Я также принял бы ответ, который использует Solr (расширение Lucene). Возможно, он лучше подходит для этой проблемы. Не уверен.

Ответы [ 3 ]

6 голосов
/ 25 мая 2010

Вы вызвали меня из FogBugz StackExchange. Меня зовут Джуд, я в настоящее время поисковый архитектор FogBugz.

Вот примерный план настройки архитектуры поиска FogBugz On Demand [1]:

  • По причинам, связанным с переносимостью данных, безопасностью и т. Д., Мы разделяем все наши базы данных и индексы по требованию.
  • Хотя мы используем Lucene (фактически Lucene.NET), мы довольно существенно изменили его бэкэнд, чтобы он мог полностью хранить свой индекс в базе данных. Кроме того, на каждом веб-хосте поддерживается локальный кэш, поэтому при любой возможности можно избежать ненужных обращений к базе данных.
  • Наши фильтры почти полностью на стороне базы данных (поскольку они используются аспектами FogBugz вне поиска), поэтому наш анализатор поиска разделяет запросы на полнотекстовые и не полнотекстовые компоненты, выполняет поиск и объединяет результаты, достижения. Это немного прискорбно, так как аннулирует много полезных оптимизаций, которые способен сделать Lucene.

В том, что мы сделали, есть несколько преимуществ. Управлять учетными записями довольно просто, поскольку данные клиента и их индекс хранятся в одном месте. Однако есть и некоторые негативы, такие как набор действительно досадных крайних поисков, которые не соответствуют нашим минимальным стандартам. Ретроспективно наш поиск был классным и хорошо выполненным для своего времени. Однако, если бы я сделал это снова, я бы не одобрил этот подход .

Проще говоря, если ваш поисковый домен не очень особенный или вы не хотите посвятить разработчика невероятно быстрому поиску, вы, вероятно, выиграете у превосходного продукта, такого как ElasticSearch, Solr или Xapian.

Если бы я делал это сегодня, если бы мой поисковый домен не был чрезвычайно конкретным, я бы, вероятно, использовал бы ElasticSearch, Solr или Xapian для своего решения для полнотекстового поиска на основе базы данных. Что касается того, что зависит от ваших вспомогательных потребностей (платформа, тип запросов, расширяемость, допуск для одного набора причуд над другим и т. Д.)

По теме один большой индекс против многих (!) Разбросанных индексов: оба могут работать. Я думаю, что решение действительно зависит от того, какую архитектуру вы хотите построить и какую производительность вам нужно. Вы можете проявить большую гибкость, если решите, что 2-секундный ответ на поиск является разумным, но как только вы начнете говорить, что что-то более 200 мс неприемлемо, ваши варианты начинают довольно быстро исчезать. Хотя ведение единого большого поискового индекса для всех ваших клиентов может быть намного эффективнее , чем обработка множества небольших индексов, это не обязательно быстрее (как вы указали). Я лично чувствую, что в безопасной среде преимущество сохранения данных вашего клиента нельзя недооценивать. Когда ваш индекс будет поврежден, он не остановит весь поиск; маленькие глупые ошибки не будут раскрывать конфиденциальные данные; учетные записи пользователей остаются модульными - проще извлечь набор учетных записей и перенести их на новый сервер; и т.д.

Я не уверен, что это ответило на ваш вопрос, но я надеюсь, что, по крайней мере, удовлетворило ваше любопытство: -)

[1]: В 2013 году FogBugz начал использовать возможности поиска и фильтрации с ElasticSearch. Нам это нравится.

4 голосов
/ 25 апреля 2010

Шалин Шекхар Мангар ответил мне в Solr-user рассылке и по личной электронной почте. Шалин является автором Solr и автором будущей книги Solr in Action .

Его ответ в списке рассылки:

Как бы вы настроили индекс (ы)?

Я бы посмотрел на настройку нескольких ядер для каждого клиента. Вам может понадобиться настроить в зависимости от поискового трафика.

Где вы храните индекс (ы)?

Настройка 5K ядер на одном компьютере не будет работать. Так что вам нужно будет разделить клиенты в несколько ящиков, каждый из которых имеет подмножество ядер.

Вам нужно добавить фильтр ко всем поисковым запросам?

Нет, но вам нужно будет отправить запрос на правильный хост (возможно, сопоставление БД поможет)

Если клиент отменил, как бы вы удалили его (часть) индекс? (это может быть тривиально - пока не уверен)

С разными ядрами для каждого клиента это будет довольно просто.

Его ответ по электронной почте:

В прошлом я работал над похожим сценарием использования, и мы использовали многоядерный подход с некоторыми серьезными оптимизациями на стороне Solr. См. http://wiki.apache.org/solr/LotsOfCores - я еще не смог перенести эти изменения в Solr.

3 голосов
/ 25 апреля 2010

Мне все еще неясно, что именно из баз данных 5K ищут пользователи, зачем вам нужен Lucene, и размеры данных в каждой базе данных. Но я все равно сделаю удар:

  1. Вы должны посмотреть Multicore Solr (каждое ядро ​​= 1 индекс), и у вас есть уникальный URL для запроса. Аутентификация по-прежнему будет проблемой, и один (хакерский) способ ее решения состоит в том, чтобы затруднить угадывание URL.

  2. Ваши веб-серверы могут запрашивать экземпляр / ядро ​​Solr в зависимости от того, к чему у них есть доступ.

Я бы посоветовал держаться подальше от подхода фильтра и создать один огромный индекс, объединяющий все базы данных.

НТН

...