Fix realtime get of nested fields with synthetic source

[dnhatn]

Today, for get-from-translog operations, we only need to reindex the root document into an in-memory Lucene, as the _source is stored in the root document and is sufficient. However, synthesizing the source for nested fields requires both the root document and its child documents. This causes realtime-get operations (as well as update and update-by-query operations) to miss nested fields.

Another issue is that the translog operation is reindexed lazily during get-from-translog operations. As a result, two realtime-get operations can return slightly different outputs: one reading from the translog and the other from Lucene.

This change resolves both issues. However, addressing the second issue can degrade the performance of realtime-get and update operations. If slight inconsistencies are acceptable, the translog operation should be reindexed lazily instead.

Closes #119553

[elasticsearchmachine]

Hi @dnhatn, I've created a changelog YAML for you.

[elasticsearchmachine]

Pinging @elastic/es-storage-engine (Team:StorageEngine)

[henningandersen]

Thanks Nhat, left a few clarifying questions.

[henningandersen]

I am not 100% sure I understand why this is necessary for synthetic source and not for regular source, perhaps you can help me out?

[dnhatn]

Synthesizing the source of nested fields requires both the root document and its child documents, whereas the stored source only requires the root document:

elasticsearch/server/src/main/java/org/elasticsearch/index/mapper/NestedObjectMapper.java

Line 466 in 12e86b1

collectChildren(parentDoc, parentDocs, childScorer.iterator());

[henningandersen]

Thanks. I wonder about the field fetch support that is in the GET API, but I suppose it is restricted to not be able to access nested objects in any way?

[martijnvg]

I wonder about the field fetch support that is in the GET API, but I suppose it is restricted to not be able to access nested objects in any way?

I don't think including stored fields of nested (child) documents works today. Looks like the root docid is used in ShardGetService#innerGetFetch(...).

[henningandersen]

The inconsistencies would those purely be white-space and field order or also actual content like order in arrays etc?

I think this is ok, synthetic source and heavy real-time GET / update use cases are probably rare, but I'd like to understand the tradeoff more deeply.

If it is only white-space and field order, could we sort that instead and how difficult would that be? Not asking to implement that now, more about knowing our backdoor in case we need this.

[dnhatn]

Yes, the inconsistencies also include removing duplicate values in an array and returning a single value as an object instead of an array. For example:

{ 
	"f": ["v"]
}

becomes

{
	"f": "v"
}

Or:

{
	"f": ["v1", "v1", "v2"]
}

becomes

{
	"f": ["v1", "v2"]
}

[henningandersen]

LGTM.

[dnhatn]

@henningandersen Thank you for reviewing. I wanted to double-check if you're comfortable with the trade-off decision in this PR. I think the alternative approach - trading slight inconsistency for better performance - is also acceptable. While the implementation for that approach is slightly more complex than this PR, I'm happy to make changes if you think it's the better trade-off.

[martijnvg]

LGTM

[martijnvg]

I wonder about the field fetch support that is in the GET API, but I suppose it is restricted to not be able to access nested objects in any way?

I don't think including stored fields of nested (child) documents works today. Looks like the root docid is used in ShardGetService#innerGetFetch(...).