Maybe he can use updateable docvalues (LUCENE-5189)? I heard that was a
thing. Has it made its way into Solr in some way?
-Mike
On 2/19/2014 4:23 AM, Mikhail Khludnev wrote:
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
