Multi-location dans la recherche élastique

Question

Nous prévoyons d'introduire la recherche élastique (AWS) pour notre application de multi-location. Nous avons ci-dessous les options,

1. En utilisant un indice par des locataires
2. Utilisation d'un type par locataire
3. Tous les locataires Partager un index avec routage personnalisé

Selon ce blog https://www.elastic.co/blog/found-multi-tenancy la première option donner un problème de mémoire. Mais pas clair sur d'autres options.

Il semble que si nous utilisons la troisième option, il n'y a pas de ségrégation de données. Pas sûr de la sécurité.

Je crois que la deuxième option serait une meilleure option que les données seraient séparées. Aidez-moi à identifier la meilleure option pour procéder à la recherche élastique avec Multi tenancy.

Veuillez noter que nous tirerons parti de l'infrastructure AWS.

Answer 1

Nous examinons actuellement la même question, et les articles suivants d'Elasticsearch nous ont été très utiles.

Commencez ici: https://www.elastic.co/guide/en/elasticsearch/guide/current/scale.html

Et lire chaque article suivant jusqu'à ce que vous appuyez sur celui-ci: https://www.elastic.co/guide/en/elasticsearch/guide/current/finite-scale.html

Les deux suivants ont été très révélatrices pour moi:

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

Le plat à emporter de base:

• Alias ​​par client
• Shard routage
• Maintenant vous pouvez avoir des indices pour les gros clients, index partagés pour les petits clients, et ils semblent tous être des indices distincts

Answer 2

Ceci est un lien trop importante ne pas être mentionné ici: http://www.bigeng.io/elasticsearch-scaling-multitenant/

Bons dilemmes d'architecture, et grande analyse de performance/raisonnement.

tldr; ils avaient des groupes d'index qui sont construits autour du filtrage d'allocation de partition pour séparer la charge entre les nœuds du cluster