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
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>
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
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
wrote:
> Thinking in terms of norma
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 al
absolutely.
On Tue, Feb 18, 2014 at 1:20 PM, wrote:
> But isn't query time join much slower when it comes to a large amount of
> documents?
>
> Zitat von Mikhail Khludnev :
>
>
> Hello,
>>
>> It sounds like you need to switch to query time join.
>> 15.02.2014 21:57 пользователь написал:
>>
>>
But isn't query time join much slower when it comes to a large amount
of documents?
Zitat von Mikhail Khludnev :
Hello,
It sounds like you need to switch to query time join.
15.02.2014 21:57 пользователь написал:
Any suggestions?
Zitat von m...@preselect-media.com:
Yonik Seeley :
O
Hello,
It sounds like you need to switch to query time join.
15.02.2014 21:57 пользователь написал:
> Any suggestions?
>
>
> Zitat von m...@preselect-media.com:
>
> Yonik Seeley :
>>
>>> On Thu, Feb 13, 2014 at 8:25 AM, wrote:
>>>
Is there any workaround to perform atomic updates on bloc
Any suggestions?
Zitat von m...@preselect-media.com:
Yonik Seeley :
On Thu, Feb 13, 2014 at 8:25 AM, 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,
Yonik Seeley :
On Thu, Feb 13, 2014 at 8:25 AM, 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 behavio
On Thu, Feb 13, 2014 at 8:25 AM, 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.
-Yonik
http://heliosearch.org - native off-heap filter
Hello,
I'm using block join to store nested documents with a huge number of children.
I want to update some fields in the parent document using atomic
updates, because I don't want to re-index all the child documents again.
So, as far as I understood atomic updates, solr is reindexing the
w
12 matches
Mail list logo
