ElasticSearch 7.3 实战：type底层结构及弃用原因

在Elasticsearch 7.x版本中，type的概念发生了显著变化。在早期版本中，一个索引（index）内可以包含多个类型（type），每个类型代表一种文档结构。这意味着在同一个索引内部，可以通过类型来区分具有不同字段结构的文档。然而，这种设计在大规模数据管理上带来了一些问题，主要是由于以下原因：

1. 资源效率低下：
   不同类型的数据即使在同一索引下，其字段也可能存在很大的差异，这会导致大量不必要的空间占用，尤其是在动态映射的情况下，当某些类型的文档不包含另一些类型所具有的字段时，会产生大量的空值存储。

2. 复杂性增加：
   类型级别的映射导致了索引管理上的复杂性提升，尤其是当需要修改映射时，可能会影响到所有类型的文档，而且对于跨类型的聚合和查询也带来了额外的复杂度。

3. API一致性：
   Elasticsearch团队希望简化API模型，统一索引与类型之间的关系，使得索引只对应一种文档结构，从而简化客户端代码和用户理解。

基于以上原因，Elasticsearch 7.x开始逐步弃用type概念，并计划在后续版本（即ES 8.x后）完全移除。从Elasticsearch 7.0开始，创建新索引时，默认不再允许指定多个类型，并且从7.0到7.2版本之间提供了过渡期的支持，通过include_type_name参数控制是否在请求中显式包含类型名称。到了7.3及以上版本，虽然现有的多类型索引仍可继续使用，但已经无法创建新的多类型索引，并且推荐的做法是在逻辑上将不同类型的文档放入不同的索引中。

因此，在Elasticsearch 7.3实战中，应遵循单索引单类型的最佳实践，即每个索引仅存放一种结构的文档，并通过索引名称来区分不同种类的数据。在API调用上，现在使用_doc作为文档类型占位符，但这并不表示它是一个真正的类型，而是指代任何文档类型，本质上强调了“索引-文档”这一层级关系。