Elasticsearch : More indices vs More types

Question

我们在以下用例中使用 elasticsearch。
Elasticsearch 版本:5.1.1
注意:我们使用的是 AWS 托管的 ElasticSearch

我们有一个 Multi-Tenancy 系统，每个租户存储多个事物的数据，并且租户数量会日益增加。

例如:每个租户都会有以下信息。

1] tickets
2] sw_inventory
3] hw_inventory

目前的索引策略如下:

索引名称:
tenant_id (GUID) 例如:tenant_xx1234xx-5b6x-4982-889a-667a758499c8

类型:

1] tickets
2] sw_inventory
3] hw_inventory

我们面临的问题:

1] 公共(public)字段映射冲突例如:(id,name,userId) 在类型 ( tickets,sw_inventory,hw_inventory )
2] 随着租户数量的增加，指数数量也可以达到 1000 或 2000。

如果我们颠倒索引策略会是个好主意吗？

例如:索引名称:

1] tickets
2] sw_inventory
3] hw_inventory

类型:

tenant_tenant_id1
tenant_tenant_id2
tenant_tenant_id3
tenant_tenant_id4

因此将只有 3 个具有 N 种类型的巨大索引作为租户。

那么在这种情况下的问题是哪种解决方案更好？

1] 许多小索引和 3 种类型
或者
2] 3个巨大的索引和多种类型

问候

Answer 1

我建议采用不同的方法:https://www.elastic.co/guide/en/elasticsearch/guide/master/faking-it.html

意思是自定义路由，其中​​每个文档都有一个 tenant_id 或类似的(每个租户唯一的东西)，并将其用于路由和为每个租户定义别名。然后，当仅为特定租户查询文档时，您可以使用别名。

您将以这种方式使用一个索引和一种类型。根据索引的大小，您考虑现有的索引大小和节点数，并尝试以这样的方式提出一些分片，以便它们在所有数据保存节点上或多或少地均匀分割，并且，还遵循您的测试性能是可以接受的。如果将来索引增长太大并且分片变得太大而无法保持相同的性能，请考虑创建一个包含更多主分片的新索引并重新索引该新索引中的所有内容。这不是闻所未闻、未使用或不推荐的方法。

1000-2000 个别名在处理能力方面不算什么。如果您有接近 10 个或超过 10 个节点，我也建议使用 4-6GB 堆大小和至少 4 个 CPU 核心的专用主节点。