Colleagues,
You are definitely right regarding denorm&collapse. It works fine in most
cases, but look at the case more precisely. Moritz needs to update the
parent's fields, if they are copied during denormalization, the price of
update is the same as block join's. With q-time join updates are way
cheaper, but searching time, you know.
19.02.2014 8:15 пользователь "Walter Underwood" <wun...@wunderwood.org>
написал:
> Listen to that advice. Denormalize, denormalize, denormalize. Think about
> the results page and work backwards from that. Flat data model.
>
> wunder
> Search guy at Infoseek, Inktomi, Verity, Autonomy, Netflix, and Chegg
>
> On Feb 18, 2014, at 7:37 PM, Jason Hellman <jhell...@innoventsolutions.com>
> wrote:
>
> > Thinking in terms of normalized data in the context of a Lucene index is
> dangerous. It is not a relational data model technology, and the join
> behaviors available to you have limited use. Each approach requires
> compromises that are likely impermissible for certain uses cases.
> >
> > If it is at all reasonable to consider you will likely be best served
> de-normalizing the data. Of course, your specific details may prove an
> exception to this rule...but generally approach works very well.
> >
> > On Feb 18, 2014, at 4:19 AM, Mikhail Khludnev <
> mkhlud...@griddynamics.com> wrote:
> >
> >> absolutely.
> >>
> >>
> >> On Tue, Feb 18, 2014 at 1:20 PM, <m...@preselect-media.com> wrote:
> >>
> >>> But isn't query time join much slower when it comes to a large amount
> of
> >>> documents?
> >>>
> >>> Zitat von Mikhail Khludnev <mkhlud...@griddynamics.com>:
> >>>
> >>>
> >>> Hello,
> >>>>
> >>>> It sounds like you need to switch to query time join.
> >>>> 15.02.2014 21:57 пользователь <m...@preselect-media.com> написал:
> >>>>
> >>>> Any suggestions?
> >>>>>
> >>>>>
> >>>>> Zitat von m...@preselect-media.com:
> >>>>>
> >>>>> Yonik Seeley <yo...@heliosearch.com>:
> >>>>>
> >>>>>>
> >>>>>> On Thu, Feb 13, 2014 at 8:25 AM, <m...@preselect-media.com> wrote:
> >>>>>>>
> >>>>>>> Is there any workaround to perform atomic updates on blocks or do I
> >>>>>>>> have to
> >>>>>>>> re-index the parent document and all its children always again if
> I
> >>>>>>>> want to
> >>>>>>>> update a field?
> >>>>>>>>
> >>>>>>>>
> >>>>>>> The latter, unfortunately.
> >>>>>>>
> >>>>>>>
> >>>>>> Is there any plan to change this behavior in near future?
> >>>>>>
> >>>>>> So, I'm thinking of alternatives without loosing the benefit of
> block
> >>>>>> join.
> >>>>>> I try to explain an idea I just thought about:
> >>>>>>
> >>>>>> Let's say I have a parent document A with a number of fields I want
> to
> >>>>>> update regularly and a number of child documents AC_1 ... AC_n
> which are
> >>>>>> only indexed once and aren't going to change anymore.
> >>>>>> So, if I index A and AC_* in a block and I update A, the block is
> gone.
> >>>>>> But if I create an additional document AF which only contains
> something
> >>>>>> like an foreign key to A and indexing AF + AC_* as a block (not A +
> AC_*
> >>>>>> anymore), could I perform a {!parent ... } query on AF + AC_* and
> make
> >>>>>> an
> >>>>>> join from the results to get A?
> >>>>>> Does this makes any sense and is it even possible? ;-)
> >>>>>> And if it's possible, how can I do it?
> >>>>>>
> >>>>>> Thanks,
> >>>>>> - Moritz
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >> Sincerely yours
> >> Mikhail Khludnev
> >> Principal Engineer,
> >> Grid Dynamics
> >>
> >> <http://www.griddynamics.com>
> >> <mkhlud...@griddynamics.com>
> >
>
> --
> Walter Underwood
> wun...@wunderwood.org
>
>
>
>
