ElasticSearch：父子关系是否最优？求替代数据建模方案

Hey there! I totally get the pain with parent-child relationships as your dataset scales—they're handy but definitely not the most performant option, as Elasticsearch's docs call out. Let's break down some better alternatives that'll fit your use case of querying documents by their pages and vice versa:

1. Nested Objects #

Instead of splitting documents and pages into separate indices, embed all related pages as a nested field directly inside the document entry. This keeps all related data on the same shard, making queries way faster since there's no cross-index joining overhead.

How it works: #

Your document structure would look like this:

{
  "document_id": "book_123",
  "title": "Elasticsearch Modeling Guide",
  "author": "Jane Doe",
  "pages": [
    {
      "page_id": "page_456",
      "content": "Nested objects explained...",
      "page_number": 5
    },
    {
      "page_id": "page_789",
      "content": "Performance tips...",
      "page_number": 10
    }
  ]
}

Pros: #

• Blazing fast queries since all data lives in one document/shard
• No extra overhead from parent-child join logic

Cons: #

• Updating a single page requires reindexing the entire document (not ideal if pages are frequently modified)
• If a document has hundreds/thousands of pages, it can bloat the document size and hit Elasticsearch's document size limits

Best for: #

Documents with a small-to-moderate number of pages, or pages that don't get updated often.

2. Denormalization (Data Flattening) #

This approach involves duplicating document-level fields into every single page document. So each page has all the metadata from its parent document, plus its own page-specific data.

How it works: #

Each page document would look like this:

{
  "page_id": "page_456",
  "document_id": "book_123",
  "document_title": "Elasticsearch Modeling Guide",
  "document_author": "Jane Doe",
  "content": "Nested objects explained...",
  "page_number": 5
}

Pros: #

• Fastest query performance—no joins needed at all. Querying pages by document attributes is just a simple filter, and querying documents by page attributes can be done with aggregations (like terms on document_id).
• Pages can be updated independently without affecting the parent document.

Cons: #

• Data redundancy: If you update a document's metadata (like changing the title), you have to update every single page linked to that document. This can lead to consistency issues if your update process isn't robust.
• Uses more storage space due to duplicated data.

Best for: #

Read-heavy workloads where document metadata doesn't change often, or where you can tolerate the extra storage and update overhead for the sake of query speed.

3. Separate Indices with Shared Routing #

If you still need to keep documents and pages in separate indices (maybe for independent indexing/updating), you can use a shared routing key to ensure related documents and pages are stored on the same shard. This eliminates the cross-shard overhead that plagues parent-child relationships.

How it works: #

• When indexing a document, use its document_id as the routing key.
• When indexing a page linked to that document, use the same document_id as the routing key.
• When querying (e.g., "get all pages for document X"), specify the routing key in your query to limit the request to only the shard where both the document and its pages live.

Example query for pages linked to a document:

GET /pages/_search
{
  "query": {
    "term": {
      "document_id": "book_123"
    }
  },
  "routing": "book_123"
}

Pros: #

• Keeps documents and pages in separate indices, allowing independent updates
• Avoids cross-shard joins, so queries are much faster than parent-child
• No document size limits from embedding pages

Cons: #

• You have to manage the routing key consistently for all writes/queries—if you forget to specify it, you might get incomplete results.
• Shard balancing could be affected if some documents have way more pages than others (leading to uneven shard sizes).

Best for: #

Large datasets where documents and pages need to be managed independently, and you want to avoid the overhead of nested objects or denormalization.

Quick Decision Guide #

• Go with Nested Objects if your pages are few and rarely change.
• Go with Denormalization if read performance is your top priority and document metadata is stable.
• Go with Shared Routing if you need separate indices and frequent independent updates for documents/pages.

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