Elasticsearch中，index和type的关系是什么？移除type后如何设计数据结构？

Question

**问题：Elasticsearch中index和type的关系是什么？移除type后如何设计数据结构？** 在Elasticsearch 6.x版本之前，index（索引）类似于数据库，type（类型）则类似于表。一个index可以包含多个type，每个type用于存储不同类别的文档。然而，从7.x版本开始，官方移除了type的概念，每个index只能有一个隐式类型“_doc”。 移除type后，设计数据结构时需重新考虑分类方式。一种常见方法是通过字段（如“category”或“type”）区分不同文档类型，结合路由（routing）优化查询性能。另一种方法是创建独立的index来存储不同类别的数据，利用别名（alias）统一管理。例如，将用户数据和订单数据分别存入“users”和“orders”索引，而非混合在同一索引中。 需要注意的是，单索引架构可能增加存储成本，但能避免跨type查询的复杂性，同时提升查询效率和数据一致性。

Answer 1

1. Elasticsearch中索引和类型的基本概念

在Elasticsearch 6.x版本之前，index（索引）可以看作是一个数据库，而type（类型）则类似于表。一个索引可以包含多个类型，每个类型用于存储不同类别的文档。

例如：

• 一个名为“ecommerce”的索引可以包含“products”类型和“orders”类型。
• “products”类型存储商品信息，“orders”类型存储订单信息。

然而，从7.x版本开始，官方移除了type的概念，每个索引只能有一个隐式类型“_doc”。这意味着在一个索引内，无法再通过type区分不同的文档类别。

2. 移除type后数据结构设计的挑战与解决方案

移除type后，设计数据结构时需要重新考虑分类方式。以下是两种常见方法：

1. 使用字段区分文档类型：通过添加一个字段（如“category”或“type”）来区分不同类型的文档。
2. 创建独立索引：将不同类别的数据存储在不同的索引中，并利用别名统一管理。

以下是具体的设计思路：

方法	优点	缺点
使用字段区分文档类型	- 简化索引结构 - 减少索引数量	- 可能导致查询复杂性增加 - 数据一致性难以维护
创建独立索引	- 提升查询效率 - 数据隔离性强	- 存储成本可能增加 - 需要额外管理索引别名

3. 示例：通过字段区分文档类型

假设我们需要存储用户数据和订单数据，可以通过添加“type”字段实现：

PUT /my_index/_doc/1
{
  "type": "user",
  "name": "Alice",
  "age": 30
}

PUT /my_index/_doc/2
{
  "type": "order",
  "product": "Laptop",
  "price": 1200
}
    

查询时可以根据“type”字段过滤：

GET /my_index/_search
{
  "query": {
    "term": {
      "type": "user"
    }
  }
}
    

4. 示例：创建独立索引并使用别名

另一种方法是为用户数据和订单数据创建独立的索引：

PUT /users
PUT /orders
    

然后通过别名统一管理：

POST /_aliases
{
  "actions": [
    { "add": { "index": "users", "alias": "ecommerce" } },
    { "add": { "index": "orders", "alias": "ecommerce" } }
  ]
}
    

这样可以通过“ecommerce”别名同时访问用户和订单数据。

5. 查询性能优化与数据一致性

无论是使用字段区分文档类型还是创建独立索引，都需要考虑查询性能和数据一致性。以下是一些建议：

• 路由（routing）优化：通过指定路由值，减少分片间的通信开销。
• 合理设计映射：确保字段类型定义清晰，避免动态映射带来的问题。
• 监控与调优：定期分析集群状态，调整分片和副本数量以提升性能。

例如，使用路由优化查询：

PUT /users/_doc/1?routing=user1
{
  "name": "Alice",
  "age": 30
}
    

流程图如下所示：

graph TD;
            A[数据存储需求] --> B{选择方法};
            B -->|字段区分| C[单索引多字段];
            B -->|独立索引| D[多索引管理];
            C --> E[查询性能优化];
            D --> F[别名统一管理];