3. 文档嵌套结构基础

3.1 嵌套文档定义

在搜索引擎与NoSQL数据库中，嵌套文档（Nested Document）是指将一个完整的结构化文档作为另一个文档的字段值进行存储的数据组织方式。与关系型数据库通过外键关联不同，嵌套文档将子实体直接嵌入父实体的内部，形成一种“文档中包含文档”的层次结构。

以电商搜索场景为例，一个订单文档可以嵌套多个商品条目：

{
  "order_id": "ORD20250321001",
  "customer": {
    "name": "张三",
    "level": "VIP"
  },
  "items": [
    {
      "sku": "SKU-A001",
      "name": "机械键盘",
      "quantity": 1,
      "price": 399.00
    },
    {
      "sku": "SKU-B002",
      "name": "鼠标垫",
      "quantity": 2,
      "price": 29.90
    }
  ],
  "total_amount": 458.80
}

在上述结构中，customer 是一个对象嵌套，items 是一个数组嵌套。在Elasticsearch等搜索引擎中，这种结构可以直接映射为 nested 数据类型，保持子文档的独立索引与查询能力。

3.2 关系型与非关系型对比

嵌套文档的设计理念与关系型数据库的范式化设计存在根本差异。下表从多个维度进行对比：

3.3 嵌套的优缺点

3.3.1 优点

• 查询性能高：一次IO即可获取完整数据，避免JOIN操作带来的多次网络往返和内存合并开销。
• 数据局部性好：相关数据物理上存储在一起，符合搜索引擎的索引与缓存机制。
• 写入原子性：父文档与嵌套子文档作为一个整体写入，天然支持事务性写入（单文档级别）。
• 模型直观：业务对象在代码中直接映射为JSON层次结构，开发效率高。
• 水平扩展友好：文档是分布式存储的基本单元，嵌套结构不影响分片路由策略。

3.3.2 缺点

• 更新代价高：修改嵌套文档中的任意字段，通常需要重建整个文档（或至少重新索引该嵌套块）。
• 数据冗余：如果嵌套的子文档在多个父文档中重复出现（如地址信息），会导致存储膨胀。
• 嵌套深度限制：Elasticsearch默认限制嵌套深度为50层，过深的结构会影响解析性能。
• 查询灵活性受限：跨嵌套文档的聚合查询比扁平化结构复杂，需要使用 nested 查询语法。
• 内存开销：嵌套文档在Lucene内部以独立子文档形式存储，会占用额外的内存用于维护父子关系。

3.4 嵌套文档结构示意图

下图展示了嵌套文档在Elasticsearch中的内部存储逻辑：

3.5 嵌套 vs 扁平化 vs 父子关系

在搜索引擎架构中，除了嵌套文档，还有扁平化结构和父子关系两种常见模式。三者的选择直接影响索引性能和查询灵活性：