Полнотекстовый поиск с несколькими индексами и сложными требованиями

Question

Мы создаем приложение, которое потребует от нас индексировать данные для каждого из наших пользователей, чтобы мы могли обеспечить полнотекстовый поиск по их данным.Вот несколько примечательных моментов, связанных с приложением:

A) Данные для каждого пользователя совершенно не связаны с любым другим пользователем.Это дает нам несколько преимуществ:

1. мы можем сохранять наши индексы небольшими по размеру.
2. объединение / сопоставление фрагментированного индекса займет меньше времени.
3. если некоторые индексы становятсянедоступный по какой-либо причине (коррупция?), затрагиваются только эти пользователи.На других пользователей это не влияет, и услуга для них доступна.

B) Каждый пользователь может иметь несколько разных типов данных.Мы хотим хранить каждый тип в отдельных папках по тем же причинам, что и выше.

Итак, наша иерархия индексов будет выглядеть примерно так:
/user1/type1/<index files><br> /user1/type2/<index files><br> /user2/type1/<index files><br> /user3/type3/<index files>

C) Часто, вероятно,с каждой итерацией мы будем добавлять «типы» данных, которые можно индексировать.
Поэтому мы хотим иметь эффективный / программный способ добавления схем для разных «типов».Мы хотели бы избежать фиксированной схемы для индексации.Мне нравится бессмысленный способ индексации вещей в Lucene.

D) Пользователи могут запускать поисковые запросы, которые будут искать: - в пределах определенного «типа» для этого пользователя - во всех типах для этого пользователя: в этомВ случае, если мы хотим запустить параллельный запрос, как Lucene.( ParallelMultiSearcher )

E) Нам требуется обновление индекса в реальном времени. Это необходимо.

F) Мы планируем разделить наш индекс на несколько машин.Для этого мы также хотим:
, если осколок становится недоступным, затрагиваются только те пользователи, данные которых находятся в этом осколке.Другие пользователи получают бесперебойное обслуживание.

Мы рассматривали Lucene, Sphinx и Solr, чтобы сделать это.Вот что мы нашли:

• Сфинкс: нет эффективного способа сделать A, B, C, F. Или есть?
• Luecne: Все выглядит возможным, так как это оченьнизкий уровень.Но мы должны написать обертки для F и создать коммуникационный уровень между веб-сервером и поисковым сервером.
• Solr: Не уверен, что мы можем легко сделать A, B, C.Можем ли мы?

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

Answer 1

Я не вижу, чтобы Solr мог обрабатывать A или B, поскольку модель Solr должна иметь все в одном индексе (на осколок ядро).Solr может обрабатывать C, если вы используете типы динамических полей .Хотя Solr может выполнять индексирование в режиме реального времени, он не такой быстрый, как Lucene (даже с использованием Embedded Solr, по моему опыту).Все это указывает на то, что Lucene - ваш единственный выбор.

Answer 2

Я думаю, что Solr может очень хорошо сработать для вас.

Ключевая особенность Solr, которая будет хорошо работать для вас в вашей ситуации, - это понятие ядра. Смотри http://wiki.apache.org/solr/CoreAdmin

Одним из способов реализации этого является то, что каждая комбинация пользователь / тип может быть отдельным ядром Solr. Это удовлетворяет (A) и (B). Клиент может либо направить поиск по одному ядру, либо он может направить поиск сразу по нескольким ядрам (и необязательно на разных серверах Solr), что вам и нужно при поиске по одному пользователю и по всем типам. Это удовлетворяет (D) и (F). Или вы можете использовать одно ядро ​​для каждого пользователя с полем «type», по которому вы можете фильтровать.

Что касается (C), у Solr есть понятие динамических полей. Смотри http://wiki.apache.org/solr/SchemaXml#Dynamic_fields

Что касается (E), у Solr пока нет "истинного" индексирования в реальном времени. Но если допустимо отставание в несколько секунд, то Solr справится с этим.