Многоуровневая аренда в эластичном поиске

Мы планируем внедрить Elastic search (AWS) для нашего приложения Multi tenancy. У нас есть варианты ниже,

Согласно этому блогу https://www.elastic.co/blog/found-multi-tenancy, первый вариант может вызвать проблемы с памятью. Но не ясно, о других вариантах.

Кажется, если мы используем третий вариант, то нет разделения данных. Не уверен насчет безопасности.

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

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

Обратите внимание, что мы будем использовать инфраструктуру AWS.

Ответы

Ответ 1

Мы рассматриваем тот же вопрос прямо сейчас, и следующий набор статей от Elasticsearch был очень полезен.

Начните здесь: https://www.elastic.co/guide/en/elasticsearch/guide/current/scale.html

И прочитайте каждую последующую статью, пока не нажмете на нее: https://www.elastic.co/guide/en/elasticsearch/guide/current/finite-scale.html

Следующие два были для меня очень открытыми:

https://www.elastic.co/guide/en/elasticsearch/guide/current/faking-it.html https://www.elastic.co/guide/en/elasticsearch/guide/current/one-big-user.html

Основной вынос:

Псевдоним для клиента
Облицовка маршрута
Теперь у вас могут быть индексы для крупных клиентов, общие индексы для маленьких клиентов, и все они выглядят как отдельные индексы.

Ответ 2

Это слишком важная ссылка, которая не упоминается здесь: http://www.bigeng.io/elasticsearch-scaling-multitenant/

Хорошие дилеммы в архитектуре и большой анализ производительности/рассуждения.

TL;DR; у них были индексные группы, которые построены вокруг фильтрации распределения осколков для разделения нагрузки между узлами в кластере