Does this mean it will not be impactful in performance to use Nested
Indexing in production with such an indexing rate?

We have tried POC on inplace updates and found its not impactful either wrt
our project, so we would not be using this in combination too

*Thanks & Regards,*
*Uday Kumar*
*Product Search Tech*


On Thu, Feb 27, 2025 at 12:31 PM Mikhail Khludnev <m...@apache.org> wrote:

> Changing one child rewrites the whole block period.
> However in-place updating child docValues is promising in theory, although
> I don't know how it works in practice.
>
> On Thu, Feb 27, 2025 at 8:05 AM Uday Kumar <uday.p...@indiamart.com
> .invalid>
> wrote:
>
> > Hi all,
> > We are doing a POC on indexing nested documents in expectation of
> reducing
> > grouping overhead while querying time.
> >
> > On Prod Indexing, we are using the traditional approach of reindexing the
> > entire document if there is any change in any of the fields. [we reindex
> > ~2cr documents per day, FYI]
> > Solr Version: v9.6.1
> >
> > But I have come across a caution in solr documentation: *DOC
> > <
> >
> https://solr.apache.org/guide/solr/latest/indexing-guide/indexing-nested-documents.html#:~:text=By%20way%20of%20examples%3A%20nested,%2F%20colors)%20and%20supporting%20documentation%20(
> > >*,
> > where it says: *Solr must internally reindex an entire nested document
> tree
> > if there are updates to it.*
> > Which means If a root or parent has 1000 child documents, even with a
> > change in single document  in any one of the fields, entire nested childs
> > are reindexed, which is not good enough.
> >
> > This made us rethink of performance gains that we will have, if nested
> > documents are used in production.
> >
> > If that's the case, pls let us know if there are any other solutions
> which
> > would help us in performance gains.
> >
> > *Note:*
> > We have already done POC on external file fields and In-Place updates
> where
> > we found they are not impactful for our project.
> >
> > *Thanks & Regards,*
> > *Uday Kumar*
> >
>
>
> --
> Sincerely yours
> Mikhail Khludnev
>

Reply via email to