Just a side note. Sidecar index might be really useful for updating blocked
docs, but it's in experimenting stage iirc.
http://www.lucenerevolution.org/2013/Sidecar-Index-Solr-Components-for-Parallel-Index-Management
On Wed, Feb 19, 2014 at 10:42 AM, Mikhail Khludnev <
mkhlud...@griddynamics.com> wrote:
> 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
>>
>>
>>
>>
--
Sincerely yours
Mikhail Khludnev
Principal Engineer,
Grid Dynamics
<http://www.griddynamics.com>
<mkhlud...@griddynamics.com>
