为何要定义Parent/Child关系？父文档删除后子文档仍存在的疑问

Great question! It makes total sense to scratch your head over this—after all, not automatically deleting child docs when the parent goes away feels a bit odd at first. Let’s break down why Parent/Child relationships are still a powerful tool in Elasticsearch, even with this behavior:

- Efficient Cross-Document Queries Without Denormalization #

If you didn’t use Parent/Child, you’d have two less-than-ideal alternatives:

1. Nested documents: As you noted, this only works well for low child doc counts and read-heavy workloads. With thousands or millions of child docs, updating any nested entry forces reindexing the entire parent document—slow and resource-draining.
2. Denormalization: Duplicating parent data across every child doc. This turns updates into a nightmare (you’d have to edit every child if the parent changes) and bloats your index unnecessarily.

Parent/Child lets you run targeted has_parent or has_child queries to link related docs on the fly. For example, you could quickly find all subaccounts tied to the "Blaze pizza" parent, or locate parent accounts with subaccounts in Denver—no data duplication or full-parent reindexing required.

- Independent Updates & Better Scalability #

Since parent and child docs are fully independent, updating a parent doesn’t require touching any of its children, and vice versa. In your example, if you need to rename the "Blaze pizza" parent account, you only update that single document—no need to reindex every subaccount under it. This is a game-changer for scenarios with large numbers of frequently changing child documents, which is exactly the use case Parent/Child was designed for.

- Optimized Performance via Shared Routing #

Notice in your document creation commands you used routing=1 for both parent and child? Parent/Child requires related docs to share the same routing value, ensuring they’re stored on the same shard. This eliminates cross-shard searches when querying parent-child relationships, making your queries faster and more efficient.

And while cascading deletions aren’t automatic, you can easily clean up orphaned child docs with a _delete_by_query call targeting the parent ID:

POST account/_delete_by_query
{
  "query": {
    "has_parent": {
      "parent_type": "account",
      "query": {
        "term": {
          "id": "1"
        }
      }
    }
  }
}

It’s an extra step, but it’s flexible—sometimes you might want to retain child docs for auditing or historical purposes even after the parent is deleted.

- Flexible Document Structures #

Child docs don’t have to match the parent’s structure at all. Unlike nested documents (which are tied to an array field in the parent), child docs can have their own unique mappings and fields. This is perfect if your child documents have varying schemas that don’t fit neatly into a parent’s nested array.

Wrap-Up #

The lack of automatic cascading deletions is a trade-off for the flexibility, performance, and scalability that Parent/Child relationships offer. They’re specifically built for scenarios where you have lots of child documents that change frequently—cases where nested documents would become too slow or unwieldy.

内容的提问来源于stack exchange，提问作者Sahil Gupta