Query performance in parent/child approach

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Query performance in parent/child approach

Ankit Jain
Hi All,

We are planning to index documents using parent/child appraoch. 

I would like to know about the performance cost in case of parent/child query compare to normal query.


Thanks,
Ankit

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Reply | Threaded
Open this post in threaded view
|

Re: Query performance in parent/child approach

Ankit Jain
Hi All,

any update ..

Thanks,
Ankit

On Saturday, 8 June 2013 13:38:39 UTC+5:30, Ankit Jain wrote:
Hi All,

We are planning to index documents using parent/child appraoch. 

I would like to know about the performance cost in case of parent/child query compare to normal query.


Thanks,
Ankit

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Reply | Threaded
Open this post in threaded view
|

Re: Query performance in parent/child approach

q42jaap
Hi Ankit,

Performance wise, you'd probably get the best results out of "normal" queries. For "normal" queries you have to denormalize the data.
Depending on the structure of your data, you're either going to lose some precision when you have multiple child objects per parent (in that case you need nested objects and nested queries).

In some cases nested or parent/child queries are a better fit for the problem, but that depends (on a lot of things). Nested queries would most likely also perform better than parent/child queries. Parent child queries also need more memory while the query is running, so if you're doing a lot of these queries, you might run into memory issues.


The exact performance cost would be very difficult to predict without further information. Could you provide more details of the structure of your data? That can tell us whether nested queries are needed.
It's difficult to answer this question in a general case.

Jaap

On Monday, June 10, 2013 7:22:27 AM UTC+2, Ankit Jain wrote:
Hi All,

any update ..

Thanks,
Ankit

On Saturday, 8 June 2013 13:38:39 UTC+5:30, Ankit Jain wrote:
Hi All,

We are planning to index documents using parent/child appraoch. 

I would like to know about the performance cost in case of parent/child query compare to normal query.


Thanks,
Ankit

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Reply | Threaded
Open this post in threaded view
|

Re: Query performance in parent/child approach

Ankit Jain
Hi Jaap,

We have one child for each parent and also in our usecase, we have required to delete the child as well.

Thanks,
Ankit

On Wednesday, 12 June 2013 02:46:18 UTC+5:30, Jaap Taal wrote:
Hi Ankit,

Performance wise, you'd probably get the best results out of "normal" queries. For "normal" queries you have to denormalize the data.
Depending on the structure of your data, you're either going to lose some precision when you have multiple child objects per parent (in that case you need nested objects and nested queries).

In some cases nested or parent/child queries are a better fit for the problem, but that depends (on a lot of things). Nested queries would most likely also perform better than parent/child queries. Parent child queries also need more memory while the query is running, so if you're doing a lot of these queries, you might run into memory issues.


The exact performance cost would be very difficult to predict without further information. Could you provide more details of the structure of your data? That can tell us whether nested queries are needed.
It's difficult to answer this question in a general case.

Jaap

On Monday, June 10, 2013 7:22:27 AM UTC+2, Ankit Jain wrote:
Hi All,

any update ..

Thanks,
Ankit

On Saturday, 8 June 2013 13:38:39 UTC+5:30, Ankit Jain wrote:
Hi All,

We are planning to index documents using parent/child appraoch. 

I would like to know about the performance cost in case of parent/child query compare to normal query.


Thanks,
Ankit

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Reply | Threaded
Open this post in threaded view
|

Re: Query performance in parent/child approach

q42jaap

I would denormalize and store both objects in 1 document. Parent child relations aren't for free.

On Jun 12, 2013 10:07 AM, "Ankit Jain" <[hidden email]> wrote:
Hi Jaap,

We have one child for each parent and also in our usecase, we have required to delete the child as well.

Thanks,
Ankit

On Wednesday, 12 June 2013 02:46:18 UTC+5:30, Jaap Taal wrote:
Hi Ankit,

Performance wise, you'd probably get the best results out of "normal" queries. For "normal" queries you have to denormalize the data.
Depending on the structure of your data, you're either going to lose some precision when you have multiple child objects per parent (in that case you need nested objects and nested queries).

In some cases nested or parent/child queries are a better fit for the problem, but that depends (on a lot of things). Nested queries would most likely also perform better than parent/child queries. Parent child queries also need more memory while the query is running, so if you're doing a lot of these queries, you might run into memory issues.


The exact performance cost would be very difficult to predict without further information. Could you provide more details of the structure of your data? That can tell us whether nested queries are needed.
It's difficult to answer this question in a general case.

Jaap

On Monday, June 10, 2013 7:22:27 AM UTC+2, Ankit Jain wrote:
Hi All,

any update ..

Thanks,
Ankit

On Saturday, 8 June 2013 13:38:39 UTC+5:30, Ankit Jain wrote:
Hi All,

We are planning to index documents using parent/child appraoch. 

I would like to know about the performance cost in case of parent/child query compare to normal query.


Thanks,
Ankit

--
You received this message because you are subscribed to a topic in the Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elasticsearch/g-YoEBm04H8/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Reply | Threaded
Open this post in threaded view
|

Re: Query performance in parent/child approach

bhupiss
This post has NOT been accepted by the mailing list yet.
I am curious how would you denormailze a parent child relationship when the number of children elements are not fixed. For example, one user can have multiple orders. How would you represent such a relationship in json document.?