掌握ElasticSearch（八）：聚集、文档间的关系

文章目录

一、聚集
- 聚集类型
- 示例
二、文档间的关系
- 1. 对象类型（Object Type）
- 2. 嵌套文档（Nested Documents）
- - 定义嵌套字段
  - 索引嵌套文档
  - 查询嵌套文档
- 3. 父子关系（Parent-Child Relationship）
- - 定义父子关系
  - 索引父文档和子文档
  - - 索引父文档
    - 索引子文档
  - 查询父子关系
  - - 查询父文档及其子文档
    - 查询子文档及其父文档
  - 更新父子关系
  - - 更新父文档
    - 更新子文档
  - 删除父子关系
  - - 删除父文档
    - 删除子文档
- 4. 反规范化（Denormalization）
- - 示例
- 5.性能对比

一、聚集

Elasticsearch 是一个基于 Lucene 的分布式搜索和分析引擎。它允许用户以近乎实时的方式存储、搜索和分析大量的数据。在 Elasticsearch 中，聚集（Aggregations）是一种强大的工具，用于执行复杂的汇总统计，如计数、平均值、最大值、最小值等。通过聚集，可以对数据进行深入分析，帮助我们更好地理解数据集。

聚集类型

Elasticsearch 支持多种类型的聚集，主要包括以下几类：

度量聚集（Metric Aggregations）：
- 这是最基本的聚集类型，用于计算数值字段的度量值。例如，avg（平均值）、sum（总和）、min（最小值）、max（最大值）、value_count（计数）、stats（统计数据）、extended_stats（扩展统计数据）等。
桶聚集（Bucket Aggregations）：
- 桶聚集将文档分成多个组或“桶”，每个桶代表一组满足特定条件的文档。常见的桶聚集包括：
  - terms：根据字段值分组。
  - histogram：根据数值字段创建直方图。
  - date_histogram：根据日期字段创建直方图。
  - range：根据数值或日期范围分组。
  - geo_distance：根据地理位置距离分组。
  - significant_terms：找出显著不同的术语。
管道聚集（Pipeline Aggregations）：
- 管道聚集用于处理其他聚集的结果。它们可以用于计算两个聚集结果之间的差异、百分比变化等。常用的管道聚集有 derivative（导数）、moving_avg（移动平均）、bucket_script（脚本化桶）、bucket_selector（桶选择器）等。
矩阵聚集（Matrix Aggregations）：
- 矩阵聚集用于多变量数据分析，能够计算数值字段之间的相关性和协方差等统计指标。

示例

假设我们有一个包含员工信息的数据集，我们可以使用聚集来找出不同部门的平均工资：

GET /employees/_search
{
  "size": 0,
  "aggs": {
    "by_department": {
      "terms": {
        "field": "department"
      },
      "aggs": {
        "average_salary": {
          "avg": {
            "field": "salary"
          }
        }
      }
    }
  }
}

在这个例子中，by_department 是一个 terms 桶聚集，它按照 department 字段的值将文档分组。然后，在每个部门的文档组中，average_salary 度量聚集计算了 salary 字段的平均值。

虽然聚集功能强大，但它们也可能消耗大量资源，特别是当处理大规模数据集时。因此，在设计查询时应该考虑到性能优化，比如减少返回的桶数量、使用合适的字段类型等。

二、文档间的关系

在 Elasticsearch 中，文档间的关系可以通过几种方式来实现，包括对象类型、嵌套文档、父子关系和反规范化。每种方法都有其适用场景和优缺点。

1. 对象类型（Object Type）

对象类型是最简单的文档内嵌方式，它允许在一个文档中嵌入另一个对象。这种方式适用于对象之间关系紧密且不需要独立索引的情况。

示例：

{
  "name": "John Doe",
  "address": {
    "street": "123 Main St",
    "city": "Anytown",
    "state": "Anystate"
  }
}

优点：
简单易用，适合简单的嵌入关系。
查询效率高，因为所有数据都在同一个文档中。
缺点：
如果嵌入的对象很大或者很复杂，会导致主文档变得臃肿。
嵌入的对象不能独立更新，需要重新索引整个主文档。

2. 嵌套文档（Nested Documents）

嵌套文档（Nested Documents）是 Elasticsearch 中一种高级的数据建模方式，用于处理复杂的数据结构。嵌套文档可以在主文档中嵌入多个子文档，并且每个子文档都可以独立索引和查询。这种方式特别适用于需要对嵌入对象进行精确匹配和复杂查询的场景。

嵌套文档的基本概念

嵌套字段：嵌套字段是一个特殊的字段类型，它允许我们将多个子文档嵌入到主文档中。每个子文档都可以有自己的字段和值。
独立索引：嵌套文档中的每个子文档都是独立索引的，这意味着我们可以对每个子文档进行独立的查询和过滤。
精确匹配：由于嵌套文档是独立索引的，可以对嵌套文档中的字段进行精确匹配，而不会受到其他嵌套文档的影响。

定义嵌套字段

在 Elasticsearch 中，我们需要在映射（mapping）中定义嵌套字段：

PUT /my-index
{
  "mappings": {
    "properties": {
      "name": { "type": "text" },
      "interests": {
        "type": "nested",
        "properties": {
          "name": { "type": "keyword" },
          "type": { "type": "keyword" }
        }
      }
    }
  }
}

在这个示例中，interests 是一个嵌套字段，它包含两个子字段：name 和 type。

索引嵌套文档

当索引一个包含嵌套字段的文档时，Elasticsearch 会自动将嵌套字段中的每个子文档独立索引：

POST /my-index/_doc
{
  "name": "John Doe",
  "interests": [
    { "name": "Hiking", "type": "Outdoor" },
    { "name": "Reading", "type": "Indoor" }
  ]
}

查询嵌套文档

要查询嵌套文档，需要使用 nested 查询。以下是一个示例，查询所有兴趣为 “Hiking” 的文档：

GET /my-index/_search
{
  "query": {
    "nested": {
      "path": "interests",
      "query": {
        "bool": {
          "must": [
            { "match": { "interests.name": "Hiking" }}
          ]
        }
      }
    }
  }
}

性能：嵌套文档会增加索引和查询的复杂度，因为每个嵌套文档都需要独立索引。如果有大量的嵌套文档，可能会对性能产生影响。
内存占用：嵌套文档会占用更多的内存，因为每个嵌套文档都需要独立存储和索引。
更新复杂度：更新嵌套文档需要重新索引整个主文档，这可能会导致额外的开销。

3. 父子关系（Parent-Child Relationship）

在 Elasticsearch 中，父子关系（Parent-Child Relationship）是一种用于处理多级文档关系的方法。这种关系允许将一个文档（子文档）关联到另一个文档（父文档），并且每个子文档可以独立索引和查询。这种方法适用于需要保持文档间关系但又希望每个文档都能独立操作的场景。

父子关系的基本概念

父文档（Parent Document）：父文档是主要的文档，可以包含多个子文档。
子文档（Child Document）：子文档是依赖于父文档的文档，每个子文档都关联到一个父文档。
关系类型（Join Field）：为了建立父子关系，需要在文档中定义一个特殊的关系类型字段，称为 join field。

定义父子关系

在 Elasticsearch 中，需要在索引映射（mapping）中定义关系类型字段：

PUT /my-index
{
  "mappings": {
    "properties": {
      "my_join_field": {
        "type": "join",
        "relations": {
          "question": "answer"
        }
      },
      "title": { "type": "text" },
      "content": { "type": "text" }
    }
  }
}

在这个示例中，my_join_field 是一个关系类型字段，定义了两种关系：question 和 answer。question 是父文档类型，answer 是子文档类型。

索引父文档和子文档

索引父文档

POST /my-index/_doc
{
  "title": "What is the capital of France?",
  "my_join_field": {
    "name": "question"
  }
}

索引子文档

POST /my-index/_doc?routing=1
{
  "content": "The capital of France is Paris.",
  "my_join_field": {
    "name": "answer",
    "parent": "1"
  }
}

在这个示例中，routing 参数指定了父文档的 ID，my_join_field 中的 parent 字段也指定了父文档的 ID。

查询父子关系

查询父文档及其子文档

要查询父文档及其子文档，可以使用 has_child 或 has_parent 查询。以下是一个示例，查询所有有答案的问题：

GET /my-index/_search
{
  "query": {
    "has_child": {
      "type": "answer",
      "query": {
        "match_all": {}
      }
    }
  }
}

查询子文档及其父文档

以下是一个示例，查询所有答案及其对应的问题：

GET /my-index/_search
{
  "query": {
    "has_parent": {
      "parent_type": "question",
      "query": {
        "match_all": {}
      }
    }
  }
}

更新父子关系

更新父子关系文档需要重新索引整个文档。可以使用 update API 来更新文档：

更新父文档

POST /my-index/_update/1
{
  "doc": {
    "title": "What is the capital of France? (Updated)"
  }
}

更新子文档

POST /my-index/_update/2?routing=1
{
  "doc": {
    "content": "The capital of France is Paris. (Updated)"
  }
}

删除父子关系

删除父子关系文档时，可以直接删除相应的文档。删除父文档会自动删除其所有子文档，但删除子文档不会影响父文档。

删除父文档

DELETE /my-index/_doc/1

删除子文档

DELETE /my-index/_doc/2?routing=1

注意事项：

性能：父子关系查询可能比普通查询慢，因为需要跨文档进行关联。
内存占用：父子关系会占用更多的内存，因为每个文档都需要独立存储和索引。
路由：在索引和查询子文档时，必须指定父文档的 ID 作为路由参数，以确保父子文档在同一分片上。

4. 反规范化（Denormalization）

反规范化（Denormalization）是数据建模的一种技术，通过在文档中重复存储相关数据来提高查询性能。在 Elasticsearch 中，反规范化是一种常见的做法，尤其适用于读多写少的场景。通过减少查询时的文档关联和连接操作，反规范化可以显著提升查询速度。

反规范化的概念：

在传统的关系型数据库中，数据通常是规范化存储的，即每个实体（表）只存储一次，通过外键来建立实体之间的关系。这种方式有助于保持数据的一致性和减少数据冗余，但在查询时需要进行多次表连接操作，这可能会导致性能瓶颈。

相比之下，反规范化通过在文档中重复存储相关数据来避免这些连接操作。虽然这样做会增加数据冗余，但可以显著提高查询性能，特别是在处理大规模数据集时。

反规范化的应用场景：

读多写少：如果应用程序中读取操作远多于写入操作，反规范化可以显著提高读取性能。
实时分析：在需要实时分析和快速响应的场景中，反规范化可以减少查询延迟。
复杂查询：对于需要进行复杂聚合和过滤的查询，反规范化可以简化查询逻辑，提高查询效率。

示例

假设我们有一个电子商务系统，其中包含商品（Product）和订单（Order）两个实体。在关系型数据库中，这两个实体可能分别存储在不同的表中，并通过外键关联。在 Elasticsearch 中，可以通过反规范化将订单信息嵌入到商品文档中，或者将商品信息嵌入到订单文档中。

规范化模型：

// 商品文档
{
  "product_id": 1,
  "name": "iPhone 12",
  "category": "Electronics"
}

// 订单文档
{
  "order_id": 101,
  "customer_name": "John Doe",
  "product_id": 1,
  "quantity": 2,
  "total_price": 1998
}

反规范化模型：

（1）将订单信息嵌入到商品文档中

{
  "product_id": 1,
  "name": "iPhone 12",
  "category": "Electronics",
  "orders": [
    {
      "order_id": 101,
      "customer_name": "John Doe",
      "quantity": 2,
      "total_price": 1998
    }
  ]
}

（2）将商品信息嵌入到订单文档中

{
  "order_id": 101,
  "customer_name": "John Doe",
  "product": {
    "product_id": 1,
    "name": "iPhone 12",
    "category": "Electronics"
  },
  "quantity": 2,
  "total_price": 1998
}