Индексирование Lucene: общий или изолированный по аккаунту?

Question

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

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

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

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

Спасибо.

EDIT

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

Answer 1

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

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.

Answer 2

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

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

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

Answer 3

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

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

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

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

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

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

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

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