Multi-location dans Elastic Search
Nous prévoyons d'introduire la recherche élastique (AWS) pour notre application multi-locataire. Nous avons ci-dessous des options,
- Utilisation d'un index par locataire
- Utilisation d'un type par locataire
- Tous les locataires partagent un index avec un routage personnalisé
Selon ce blog https://www.elastic.co/blog/found-multi-tenancy la première option donnerait un problème de mémoire. Mais pas clair sur les autres options.
Il semble que si nous utilisons la troisième option, il n'y a pas de séparation des données. Pas sûr de la sécurité.
Je crois que la deuxième option serait une meilleure option car les données seraient séparées.
Aidez-moi à identifier la meilleure option pour effectuer une recherche élastique avec Multi tenancy.
Veuillez noter que nous exploiterions l'infrastructure AWS.
Nous examinons la même question en ce moment, et la série d'articles suivante d'Elasticsearch a été très utile.
Commencez ici: https://www.elastic.co/guide/en/elasticsearch/guide/current/scale.html
Et lisez chaque article suivant jusqu'à ce que vous frappiez celui-ci: https://www.elastic.co/guide/en/elasticsearch/guide/current/finite-scale.html
Les deux suivants m'ont ouvert les yeux:
https://www.elastic.co/guide/en/elasticsearch/guide/current/faking-it.htmlhttps://www.elastic.co/guide/en/ elasticsearch/guide/current/one-big-user.html
Les plats à emporter de base:
- Alias par client
- Acheminement des fragments
- Vous pouvez maintenant avoir des index pour les gros clients, des index partagés pour les petits clients, et ils semblent tous être des index distincts
Ceci est un lien trop important pour ne pas être mentionné ici: http://www.bigeng.io/elasticsearch-scaling-multitenant/
Bons dilemmes d'architecture et grande analyse/raisonnement des performances.
tldr; ils avaient des groupes d'index qui sont construits autour du filtrage d'allocation de fragments pour séparer la charge entre les nœuds du cluster