Выбор правильного решения для поиска и индексирования

Question

Мы работаем над дизайном и разработкой безголовых приложений. В настоящее время мы сталкиваемся с проблемой **architectural question**, на которую нам нужно найти ответ, чтобы продолжить проектирование системы, мы не являемся экспертами в **search engine**, но мы проводим исследования в этой области.

Наши технологии stack is .net Core/SQL Server, а в будущем мы можем plan to use Raven DB.

Вместо использования API доставки контента мы планируем использовать Query based content delivery, чтобы сделать его более гибким и сократить накладные расходы на разработку API для каждой интерфейсной инфраструктуры. и Мы решили использовать индексирование и индексирование для большей части управления данными, то есть для уменьшения нагрузки на БД. Таким образом, в основном большинство операций с контентом будет обрабатываться с помощью индексов.

Проблема, которую мы наблюдали с поисковой системой: в первом сокращении мы планировали использовать Elastic Search, но снова мы поняли следующее issues.

Система будет иметь dynamic field management and field data management, т.е. пользователь будет редактировать поля и значения полей во время работы системы. каждый раз, когда нам может потребоваться перестроить индекс для обновления поля в поиске elasti c (мы не являемся экспертами в поисковой системе), это увеличит нагрузку на сеть, что для нас может оказаться невозможным для работы в большой многопользовательской среде. .

Итак, мы decided to go with Lucene.net, но перед тем, как продолжить с lucene.net, мы хотим убедиться, что могут быть решены следующие проблемы.

Динамическое обновление поля без перестройки индексации каждый раз, поддерживает ли lucene это или мы можем настроить это для управления?

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

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

Возможно ли распределить Lucene

Так любезно помогите найти решение для двух вышеуказанных проблем, с которыми мы сталкиваемся прямо сейчас.

Answer 1

Elasticsearch внутренне использует только Lucene, каждый индекс elasticsearch (состоящий из одного или нескольких сегментов) внутренне является индексом Lucene. Вы даже можете думать об Elasticsearch как о распределенном Lucene , который можно легко масштабировать до тысяч физических серверов. обновление документа и удаление документа выполняется внутри компании Lucene в случае Elasticsearch, который является частью 1 вашего вопроса.

Ваш первый вопрос

Q: Обновление поля динамически без перестройки индексации каждый раз, поддерживает ли это Lucene или мы можем настроить это для управления?

Вы просто обновляете один документ, это не приведет к перестройке всего индекса и вы получите обновленный документ в течение 1 секунды c (по умолчанию refre sh interval ), или вы, если хотите обновить документ немедленно, вы можете сделать явное refre sh (не рекомендуется).

Переходя к вашему второму вопросу:

Q: Возможно ли распределить реализацию Lucene с помощью иметь раздел исключительно для каждого клиента?

Ответ: Как объяснялось, вы можете думать об Elasticsearch только как о распределенном Lucence и можете легко создать отдельный индекс для каждого из клиентов, и они не будут взаимодействовать с каждым из них. другие данные (хотя, если вы храните несколько индексов в одном кластере Elasticsearch, изоляция внутренних ресурсов (ЦП, память) не будет) et c, и вы можете получить проблему с шумными соседями.