Re: child docs
Hello, John.
The choice is guided by the form of search results. You need to ask what
you need to paginate, count numFound. You need to index as top level docs
what you need to find.
On Thu, Mar 7, 2019 at 9:08 PM John Blythe wrote:
> hi all!
>
> curious about how child docs and performance interact.
>
> i'll have a bunch of transactions coming in from various entities. i'm
> debating nesting them all under a single, 'master' parent entity or to have
> the parent and children be entity specific.
>
> so either:
>
> [platonic ideal parent item]
> child1: {entity1, tranx1}
> child2: {entity1, tranx2}
> child3: {entity2, tranx3}
> child4: {entity3, tranx4}
>
> VS.
>
> [entity1's parent item]
> child1: {tranx1}
> child2: {tranx2}
> [entity2's parent item]
> child1: {tranx3}
> [entity3's parent item]
> child1: {tranx4}
>
> could be up to several hundred child docs per entity, though usually will
> be double digits only (per entity), sometimes as low as < 10.
>
> hope this makes sense. thanks for any insight!
>
> best,
> --
> John Blythe
>
--
Sincerely yours
Mikhail Khludnev
Re: child docs
thanks for the quick response! that was my inkling from what i've read thus
far, but was curious if any benefits could make it potentially worthwhile.
interested in other "gotchas" the nesting may cause us to incur.
thanks again!
--
John Blythe
On Thu, Mar 7, 2019 at 10:23 AM Erick Erickson
wrote:
> First of all, if your problem space allows it you're usually better off
> denormalizing for many reasons, not the least of which is that a change to
> any record in a parent/child relationship requires that the entire block be
> re-indexed anyway. Plus, nested docs have quite a number of “gotchas”.
>
> If you really need nested docs, your first option would require the entire
> “platonic” parent and all child docs to be re-indexed every time, so I’d go
> with 2 for that reason alone.
>
> Best,
> Erick
>
> > On Mar 7, 2019, at 10:08 AM, John Blythe wrote:
> >
> > hi all!
> >
> > curious about how child docs and performance interact.
> >
> > i'll have a bunch of transactions coming in from various entities. i'm
> > debating nesting them all under a single, 'master' parent entity or to
> have
> > the parent and children be entity specific.
> >
> > so either:
> >
> > [platonic ideal parent item]
> >child1: {entity1, tranx1}
> >child2: {entity1, tranx2}
> >child3: {entity2, tranx3}
> >child4: {entity3, tranx4}
> >
> > VS.
> >
> > [entity1's parent item]
> >child1: {tranx1}
> >child2: {tranx2}
> > [entity2's parent item]
> >child1: {tranx3}
> > [entity3's parent item]
> >child1: {tranx4}
> >
> > could be up to several hundred child docs per entity, though usually will
> > be double digits only (per entity), sometimes as low as < 10.
> >
> > hope this makes sense. thanks for any insight!
> >
> > best,
> > --
> > John Blythe
>
>
Re: child docs
First of all, if your problem space allows it you're usually better off
denormalizing for many reasons, not the least of which is that a change to any
record in a parent/child relationship requires that the entire block be
re-indexed anyway. Plus, nested docs have quite a number of “gotchas”.
If you really need nested docs, your first option would require the entire
“platonic” parent and all child docs to be re-indexed every time, so I’d go
with 2 for that reason alone.
Best,
Erick
> On Mar 7, 2019, at 10:08 AM, John Blythe wrote:
>
> hi all!
>
> curious about how child docs and performance interact.
>
> i'll have a bunch of transactions coming in from various entities. i'm
> debating nesting them all under a single, 'master' parent entity or to have
> the parent and children be entity specific.
>
> so either:
>
> [platonic ideal parent item]
>child1: {entity1, tranx1}
>child2: {entity1, tranx2}
>child3: {entity2, tranx3}
>child4: {entity3, tranx4}
>
> VS.
>
> [entity1's parent item]
>child1: {tranx1}
>child2: {tranx2}
> [entity2's parent item]
>child1: {tranx3}
> [entity3's parent item]
>child1: {tranx4}
>
> could be up to several hundred child docs per entity, though usually will
> be double digits only (per entity), sometimes as low as < 10.
>
> hope this makes sense. thanks for any insight!
>
> best,
> --
> John Blythe
