Elasticsearch 6.2多租户疑问：按租户+文档类型建索引是否可行？

Great question—this is a super common point of confusion when navigating Elasticsearch's evolving best practices, especially for multi-tenant systems! Let's break this down clearly:

先回顾旧版本「过多索引」的内存问题根源 #

Back in pre-7.x Elasticsearch versions (when document types were allowed in a single index), the main memory bottlenecks from too many indexes came down to two key factors:

• Mapping重复与分片级开销：一个索引可以包含多种文档类型，每种类型都有独立的mapping。索引下的每个分片都会加载所有类型的mapping，当索引数量达到数百甚至数千级时，所有分片累计的mapping内存占用会变得非常庞大。
• 臃肿的集群状态：所有索引元数据（mapping、配置、别名）都存储在集群状态中。大量索引会导致集群状态体积暴涨，不仅占用主节点和数据节点的内存，还会拖慢节点间的状态同步速度。

新版本优化：为什么现在多索引更可行？ #

从Elasticsearch 7.x开始（官方移除了文档类型，推荐「一个索引对应一种文档类型」），官方针对多索引场景做了关键优化，大幅缓解了旧版本的问题：

• Mapping元数据共享：如果多个索引的mapping结构相同或相似，Elasticsearch可以在它们之间共享底层元数据结构，减少冗余内存占用。这对你的多租户场景尤其友好——同类型文档的索引mapping大概率是一致的。
• 轻量化集群状态管理：集群状态现在支持增量同步、更高效的元数据压缩，即使索引数量上千，集群状态的膨胀速度也远低于旧版本。
• 分片内存效率提升：分片的内存管理更智能，比如优化了字段数据的缓存策略，降低了索引级元数据的开销。

但要注意：「无限制」多索引依然有风险 #

虽然旧的内存问题被大幅缓解，但并不意味着完全消失：

• 如果你的数万索引都带有独特且差异极大的mapping，元数据共享优化就起不到作用，内存膨胀问题仍会出现。
• 每个索引默认包含5个主分片，过多的总分片（官方建议单节点分片数不超过1000）依然会占用内存用于分片元数据、线程池等开销。

针对你的多租户架构的建议 #

结合你的场景，这里有几个平衡最佳实践和扩展性的方案：

• 租户数量较少时：如果只有几百个以内的租户，「每个租户的每种文档类型单独建索引」完全可行。这种方式权限控制（基于索引的RBAC）简单直接，数据结构也清晰。
• 租户数量庞大时：如果要处理数千级别的租户，建议将多个租户的同类型文档合并到共享索引中，用tenant_id字段做过滤和路由。可以通过索引别名让应用感知不到这种合并，同时控制总索引/分片数，避免内存压力。
• 持续监控：密切关注cluster_state_size、jvm_memory_used、total_shards等集群指标，一旦发现内存压力苗头，及时调整索引策略。

内容的提问来源于stack exchange，提问作者Aashish Upadhyay