Как установить Lucene/Solr для веб-приложения B2B?
Данный:
- 1 база данных на клиент (корпоративный клиент)
- 5 000 клиентов
- Клиенты имеют между 2 - 2 000 пользователей (в среднем ~100 пользователей/клиентов),
- 100k к 10 миллионам записей для каждой базы данных
- Пользователи должны часто искать те записи (это - лучший способ переместиться по их данным),
Возможно соответствующая информация:
- Несколько новых клиентов каждую неделю (любое время во время рабочего времени)
- Несколько веб-серверов и серверов баз данных (пользователи могут войти в систему через любой веб-сервер),
- Давайте останемся агностик языка или бренда sql, так как Lucene (и Solr) имеют ширину поддержки
Например:
Joel Spolsky сказал в Подкасте № 11, что его размещенный продукт веб-приложения, FogBugz, По запросу, использует Lucene. У него есть тысячи клиентов по запросу. И каждый клиент получает их собственную базу данных.
Они используют индекс на клиент и хранят его в базе данных клиента. Я не уверен в деталях. И я не уверен, является ли это серьезной модификацией к Lucene.
Вопрос:
Как Вы установили бы поиск Lucene так, чтобы каждый клиент мог только искать в его базе данных?
Как Вы установили бы индекс (индексы)?
Где Вы храните индекс (индексы)?
Необходимо ли было бы добавить фильтр ко всем поисковым запросам?
Если бы клиент отменил, как Вы удалили бы их (часть) индекс? (это может быть тривиально - не уверенный все же),
Возможные решения:
Сделайте индекс для каждого клиента (база данных)
- Pro: Поиск быстрее (чем one-index-for-all метод). Индексы относительно размера данных клиента.
- Довод "против": я не уверен, что это влечет за собой, и при этом я не знаю, ли это вне объема Lucene.
Имейте единственный, гигантский индекс с database_name полем. Всегда включайте database_name как фильтр.
- Pro:Не уверен. возможно, хороший для технической поддержки или тарификационного отдела для поиска всех баз данных информацию.
- Довод "против": Поиск медленнее (чем метод индекса на клиент). Дефектная безопасность, если фильтр запроса удален.
Одна последняя вещь:
Я также принял бы ответ, который использует Solr (расширение Lucene). Возможно, это лучше подходит для этой проблемы.Не уверен.
3 ответа
Вы вызвали меня из FogBugz StackExchange. Меня зовут Джуд, я текущий разработчик поиска для FogBugz.
Вот примерный план того, как настроена архитектура поиска FogBugz On Demand [1]:
- По причинам, связанным с переносимостью данных, безопасностью и т. Д., Мы храним все наши базы данных по запросу и индексы отдельно.
- Хотя мы действительно используем Lucene (на самом деле Lucene.NET), мы довольно существенно модифицировали его бэкэнд, чтобы он мог полностью хранить свой индекс в базе данных. Кроме того, на каждом веб-хосте поддерживается локальный кеш, чтобы можно было избежать ненужных обращений к базе данных, когда это возможно.
- Наши фильтры почти полностью относятся к базе данных (поскольку они используются аспектами FogBugz вне поиска), поэтому наш поисковый синтаксический анализатор разделяет запросы на полнотекстовые и неполнотекстовые компоненты, выполняет поиск и объединяет результаты, достижения. Это немного прискорбно, так как лишается многих полезных оптимизаций, которые может выполнить Lucene.
У того, что мы сделали, есть несколько преимуществ. Управлять учетными записями довольно просто, поскольку данные клиентов и их индекс хранятся в одном месте. Однако есть и некоторые недостатки, такие как набор действительно надоедливых поисков по краям, которые не соответствуют нашим минимальным стандартам. Оглядываясь назад, наш поиск был классным и хорошо сделанным для своего времени. Однако, если бы я сделал это снова, я бы воспрепятствовал этому подходу .
Проще говоря, если ваша поисковая область не является особенной или вы не желаете посвятить разработчика невероятно быстрому поиску, вы, вероятно, проиграете таким отличным продуктам, как ElasticSearch, Solr или Xapian.
Если бы я делал это сегодня, если бы мой домен поиска не был чрезвычайно конкретным, я, вероятно, использовал бы ElasticSearch, Solr или Xapian для моего решения полнотекстового поиска на основе базы данных. Что касается того, что зависит от ваших дополнительных потребностей (платформа, тип запросов, расширяемость, терпимость к одному набору причуд по сравнению с другим и т. Д.)
По теме одного большого индекса по сравнению с множеством (!) Разрозненных индексов: Оба может работать. Я думаю, что решение действительно зависит от того, какую архитектуру вы хотите построить и какая производительность вам нужна. Вы можете проявить большую гибкость, если решите, что 2-секундный поисковый ответ является разумным, но как только вы начнете говорить, что что-то более 200 мс недопустимо, ваши варианты довольно быстро исчезнут. Хотя поддержание единого большого поискового индекса для всех ваших клиентов может быть намного эффективнее , чем обработка большого количества небольших индексов, это не обязательно быстрее (как вы отметили). Я лично считаю, что в безопасной среде нельзя недооценивать преимущества разделения клиентских данных. Когда ваш индекс поврежден, это не остановит весь поиск; маленькие глупые ошибки не раскрывают конфиденциальные данные; учетные записи пользователей остаются модульными - проще извлечь набор учетных записей и перенести их на новый сервер; и т. д.
Я не уверен, что это ответил на ваш вопрос, но я надеюсь, что, по крайней мере, удовлетворил ваше любопытство: -)
[1]: В 2013 году FogBugz начал расширять свои возможности поиска и фильтрации с помощью ElasticSearch. Нам это нравится.
Шалин Шекхар Мангар ответила мне на список рассылки пользователей Solr и на личный адрес электронной почты. Шалин является соавтором Solr и автором будущей книги Solr в действии .
Его ответ в списке рассылки:
Как бы вы настроили индекс (а)?
Я бы посмотрел на настройку нескольких ядер для каждого клиента. Вам также может потребоваться настроить ведомых устройств в зависимости от поискового трафика.
Где вы храните индексы?
Настройка ядер 5K на одном устройстве не сработает. Таким образом, вам нужно будет разделить клиентов на несколько блоков, каждый из которых имеет подмножество ядер.
Нужно ли вам добавить фильтр ко всем поисковым запросам?
Нет, но вам нужно будет отправить запрос на правильный хост (возможно, поможет база данных сопоставления )
Если клиент отменен, как бы вы удалили их (часть) индекса? (это может быть тривиально - пока не уверен)
С разными ядрами для каждого клиента это было бы довольно просто.
Его ответ по электронной почте:
Я работал над подобным вариантом использования в прошлом, и мы использовали многоядерный подход с некоторыми серьезными оптимизациями на стороне Solr. См. http: //wiki.apache.org / solr / LotsOfCores - Мне еще не удалось внести эти изменения в Solr.
Я до сих пор не понимаю, что именно из баз данных 5K ищут пользователи, почему вам нужен Lucene и размеры данных в каждой базе данных. Но я все равно приму удар:
Вы должны смотреть на Multicore Solr (каждое ядро = 1 индекс), и у вас есть уникальный URL-адрес для запроса. Аутентификация по-прежнему будет проблемой, и один (хакерский) способ приблизиться к ней - сделать URL трудно угадываемым.
Ваши веб-серверы могут запрашивать экземпляр / ядро Solr в зависимости от того, к чему у них есть доступ.
Я бы посоветовал отказаться от подхода с использованием фильтров и создать один огромный индекс, объединяющий все базы данных.
HTH