Блог

Я оцениваю Lucene для реализации функции глобального поиска в приложении SaaS.

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

Лучше иметь один индекс с полем идентификатора учетной записи или один индекс для каждой учетной записи? Каковы преимущества и недостатки каждого подхода?

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

Спасибо.

Редактировать

• Предполагаемое общее количество документов: 500,0000
• Количество учетных записей: 4000
• Индексируемые данные никогда не передаются между учетными записями
• Пользователи учетных записей могут обновлять свои индексируемые данные несколько раз в день (в большинстве случаев не более 100)
• Объем индексируемых данных, как правило, стабилен после первоначального процесса настройки
• Нам нужно хранить 10-20 полей в документе

вот некоторые вещи, о которых я бы подумал в дополнение к обычным проблемам (например, обновления индекса и тому подобное):

1. Способ, которым lucene возвращает ранжированные результаты, зависит от некоторой статистики «всего корпуса», например, от общего количества документов, в которых термин появляется для этого поля. Итак, если статистика индекса для клиента a не подходит для клиента b, это повредит значимости для обоих клиентов, помимо того, что представляет угрозу безопасности … если Оскар достаточно умен, он действительно может начать изменять документы Боба из-за природы инвертированного индекса:http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.159.9682 Вероятно, вы могли бы обойти это с помощью чего-то вроде этого алгоритма ранжирования: https://issues.apache.org/jira/browse/LUCENE-2864
2. Некоторые другие вещи в lucene применимы к «полю в целом» или «индексу в целом», и вы должны знать, что они не могут быть изменены индивидуально для каждого клиента, если вы группируете индексы вместе: такие вещи, как omitTF (если вы установите его в одном документе для поля, оно будет опущено по всем направлениям для этого поля), сходство (в любой выпущенной версии lucene вы можете установить только сходство по всем направлениям, поэтому клиенты не смогут настроить модель ранжирования), проверка орфографии (вам пришлось бы что-то взломать, где у каждого клиента есть свой собственный «отфильтрованный» индекс проверки орфографии), …
3. С другой стороны, если у вас много терминов, требуется довольно много оперативной памяти, и, предоставляя каждому клиенту свой собственный индекс, вам потребуется больше памяти для хранения индекса терминов в оперативной памяти для всех индексов. Однако вы можете несколько снизить это значение, настроив такие вещи, как termIndexInterval / Divisor.

На моем месте, если бы не было нормативных причин, по которым вы не можете, я бы свалил их все в один индекс. Это просто моя шляпа, говорящая «не оптимизируйте то, что вам не нужно».

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

Предполагая, что вы можете, тогда следующий вопрос заключается в том, какое влияние другие пользователи окажут друг на друга. Если пользователь A использует систему, а пользователь B находится в процессе импорта своих 100 тыс. документов, повлияет ли это на пользователя A? Влияет ли это на пользователя A из-за того, как работает Lucene, или просто из-за общей нагрузки на систему, возникающей при импорте и индексировании документов.

Попробуйте и убедитесь.

Главное — убедиться, что ваши клиентские системы обращаются к Lucene не напрямую, а скорее через какой-то фасад. Этот фасад — идеальное место для принудительного разделения клиентов, а также хорошее место для перенаправления трафика, если позже вы решите, что вам нужно разделить свои индексы.

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

Но решайте прямо сейчас, какой путь лучше? Эх, кажется, рано.

500 Тыс. документов — это не так уж много данных для Lucene. Просто убедитесь, что у вас есть гибкость в реализации, чтобы добавить возможность позже, если вы обнаружите, что размещать все это в одном экземпляре нецелесообразно. И под «добавить возможность» я имею в виду именно это, добавьте ее. На самом деле не РЕАЛИЗОВЫВАЙТЕ, скажем, сегментирование на основе клиента. Но, скорее, есть хороший момент, когда это можно было бы реализовать, не переделывая кучу настроек позже.

Я сделал несколько индексов с «урезанной безопасностью» здесь и там — определенно возможно, если это разрешено. Тем не менее, моя общая склонность к материалам типа SAAS с несколькими клиентами заключалась бы в том, чтобы максимально разделить клиентов по нескольким причинам:

a) Гарантирует, что ошибки кодирования не приведут к утечке данных, недовольным клиентам, судебным искам и прочим неприятностям.
б) Значительно упрощает настройку для каждого клиента — всей вашей кодовой базе не нужно обрабатывать специфичные для клиента запросы fubar
в) С первого дня заставляет вас использовать горизонтально масштабируемую архитектуру — масштабирование легко, если легко добавлять экземпляры, верно?

О, и определенно примите совет Уилла Хартунга — поиск по фасаду, этот материал действительно не должен выползать за пределы своего уровня.