ElasticSearch的扩展性和多租户考虑。

Question

【以下的问题经过翻译处理】 你好，一位客户正在使用Elastic并增加更多的客户、文档类型和索引。Elastic是他们多租户SaaS方案的重要组成部分。

TL;DR-他们希望将他们的Elastic设置转变为多租户，以创建更好的隔离并适应预期的增长，并有几个问题。

他们考虑一些问题：

1. 目前，每个Elastic索引包含所有租户的文档。然而，随着将来推出新的索引，他们考虑为每个租户创建一个单独的索引。根据计划，他们可能会有数百万个文档，每个租户一个。例如，当前称为“emailMessage”的所有电子邮件的索引将被分裂成许多“emailMessage-TENANTID”。

从系统资源的角度来看，如果他们预计有几千个租户，这意味着什么？由于每个索引至少需要一个单独的分片，而每个分片都意味着系统资源，他们不确定是否不会在某个时候达到某些系统限制，这将阻止他们添加其他租户。

客户就两个附加问题表达了自己的意见-

2. ES如何处理修改–在我们计划的一个索引中，我们预计每个租户将存储几十万到数百万个文档。我们还预计，约50％的文档每天都会有更改。由于ES基本上在每次更新时都会删除一个文档，我们担心ES索引和数据将变得分散，这将导致性能下降。问题是，您是否有ES索引的经验，这些索引需要如此多的更新，以及它们的性能如何表现

Answer

【以下的回答经过翻译处理】 你好，请参考下面的想法：

1. Elasticsearch 的横向扩展性设计非常好。他们需要关注监控，但如果资源开始受到压力，他们可以简单地向集群添加其他节点。随着时间的推移，他们将了解他们的索引和分片有多大，能够计算在添加新的租户时是否需要额外的节点。请参见此博客关于 PB 级别规模的内容 ，其中推荐不要在集群中使用超过 30,000 个分片。
2. Elasticsearch 并非真正设计用于更改。有两件事需要考虑：
a.每秒索引的总文档数量 - 修改将计为重新索引。如果集群在进行重新索引时遇到问题，Elasticsearch 可以进行横向扩展，所以这不是问题。
b.性能。当删除文档时，Elasticsearch 不会从索引中删除。我之前的索引中有数千万条记录和数千万条被删除的记录，但并没有注意到太多性能问题。我们将解决方案重新构建为基于时间的索引，因此每个索引中会有更少的已删除文档。这也允许我们在旧索引不再被写入任何数据后运行强制合并。不要在仍在写入的索引上运行强制合并。因此，关于数据是否适合时间或基于大小的索引进行讨论可能是值得的，例如 emailMessage-TenantId20190527，并每周滚动，或 emailMessageTenantId0001，并达到一定大小时滚动。
3.不幸的是不在此。然而，在谈到工具时，此工具非常有用来管理索引

ElasticSearch的扩展性和多租户考虑。

相关内容