Difference of Parent to Child Documents and a Nested Document

I can understand the different between a multi-value field that contains
many objects and a Nested Document.
The main problem solvable by nested objects is "cross object" matching, see
http://www.elasticsearch.org/guide/reference/mapping/nested-type.html

But why would I use a nested object vs. a parent object & one or more
child objects?

For query that includes the child, I can use a has_child query (or filter)
http://www.elasticsearch.org/guide/reference/query-dsl/has-child-query.html
For a query that includes a nested document I can use a nested_ query
http://www.elasticsearch.org/guide/reference/query-dsl/nested-query.html
Both result in 1 document for the parent and 1 for each child.

Is one of the primary differences between nested object and a
child/parent is that
A nested type is defined/changed/deleted by indexing a new parent
while a child document can have a different lifecycle than its parent?

My application of parent/child would definitely be a case where the
children come along at different times after the parent is created.

-Paul

--

1 Like

On Thu, 2012-08-23 at 15:19 -0700, P. Hill wrote:

I can understand the different between a multi-value field that contains
many objects and a Nested Document.
The main problem solvable by nested objects is "cross object" matching, see
Elasticsearch Platform — Find real-time answers at scale | Elastic

But why would I use a nested object vs. a parent object & one or more
child objects?

For query that includes the child, I can use a has_child query (or filter)
Elasticsearch Platform — Find real-time answers at scale | Elastic
For a query that includes a nested document I can use a nested_ query
Elasticsearch Platform — Find real-time answers at scale | Elastic
Both result in 1 document for the parent and 1 for each child.

Is one of the primary differences between nested object and a
child/parent is that
A nested type is defined/changed/deleted by indexing a new parent
while a child document can have a different lifecycle than its parent?

Correct

My application of parent/child would definitely be a case where the
children come along at different times after the parent is created.

It's also a question of the number of children.

I'd guess (not sure) that nested docs probably perform better than
parent-child docs, but if you could have thousands of children, you will
probably do better with parent-child.

clint

-Paul

--

Hi Paul,

With nested objects you basically need to know your parent child
relation upfront. You can't add a nested object after the main
document is added. This isn't the case with parent child objects. So
based on your requirements I would suggest that parent child type
object is the way to go.

Martijn

On 24 August 2012 08:36, Clinton Gormley clint@traveljury.com wrote:

On Thu, 2012-08-23 at 15:19 -0700, P. Hill wrote:

I can understand the different between a multi-value field that contains
many objects and a Nested Document.
The main problem solvable by nested objects is "cross object" matching, see
Elasticsearch Platform — Find real-time answers at scale | Elastic

But why would I use a nested object vs. a parent object & one or more
child objects?

For query that includes the child, I can use a has_child query (or filter)
Elasticsearch Platform — Find real-time answers at scale | Elastic
For a query that includes a nested document I can use a nested_ query
Elasticsearch Platform — Find real-time answers at scale | Elastic
Both result in 1 document for the parent and 1 for each child.

Is one of the primary differences between nested object and a
child/parent is that
A nested type is defined/changed/deleted by indexing a new parent
while a child document can have a different lifecycle than its parent?

Correct

My application of parent/child would definitely be a case where the
children come along at different times after the parent is created.

It's also a question of the number of children.

I'd guess (not sure) that nested docs probably perform better than
parent-child docs, but if you could have thousands of children, you will
probably do better with parent-child.

clint

-Paul

--

--
Met vriendelijke groet,

Martijn van Groningen

--