Filtering is really searching. As Shawn says, you _might_ get away with it in
some circumstances, but it’s not something I’d recommend.
Here’s the problem: For most searches, you’re trying to ask “for term X, what
docs contain it?”. That’s exactly what the inverted index is for, it’s an
ordered
On 9/14/2019 4:29 PM, Mikhail Khludnev wrote:
Shawn, would you mind to provide some numbers?
I'm experimenting with lucene 8.0.0.
I have 100 shard index of 100M docs with 2000 docVals only updateable
fields. Searching for such field turns to be blazingly fast
$ curl 'localhost:39200/books/_search
ot; : {
"subscription_0x1" : {
"type" : "integer",
"boost" : 1.0,
"index" : false,
"store" : false,
"doc_values" : true,
"term_vector" : &quo
On 9/10/2019 7:15 AM, Doss wrote:
4 to 5 million documents.
For an NTR index, we need a field to be updated very frequently and filter
results based on it. Will In-Place updates help us?
Although you CAN search on docValues-only fields, the performance is
terrible. So the answer I have
ones.
These are updateable inplace.
On Tue, Sep 10, 2019 at 4:15 PM Doss wrote:
> Hi,
>
> 4 to 5 million documents.
>
> For an NTR index, we need a field to be updated very frequently and filter
> results based on it. Will In-Place updates help us?
>
> docValues="true
Hi,
4 to 5 million documents.
For an NTR index, we need a field to be updated very frequently and filter
results based on it. Will In-Place updates help us?
Thanks,
Doss.
ah, right, sorry
On 11.04.2018 17:38, Emir Arnautović wrote:
Hi Hendrik,
Documentation clearly states conditions when in-place updates are possible:
https://lucene.apache.org/solr/guide/6_6/updating-parts-of-documents.html#UpdatingPartsofDocuments-In-PlaceUpdates
<https://lucene.apache.
Hi Hendrik,
Documentation clearly states conditions when in-place updates are possible:
https://lucene.apache.org/solr/guide/6_6/updating-parts-of-documents.html#UpdatingPartsofDocuments-In-PlaceUpdates
<https://lucene.apache.org/solr/guide/6_6/updating-parts-of-documents.h
Hi,
in
http://lucene.472066.n3.nabble.com/In-Place-Updates-not-working-as-expected-tp4375621p4380035.html
some restrictions on the supported fields are given. I could however not
find if in-place updates are supported for are field types or if they
only work for say numeric fields.
thanks
I have a scenario as follows:
There are 2 separate threads where each will try to update the same document
in a single index for 2 separate fields, for which we are using atomic OR
in-place updates. For e.g.
id is the unique field in the index
thread-1 will update following info:
id:1001
field
putDocuments);
>
> I just want to know whether, we need to do something specific for in-place
> updates ?
>
> Kindly let me know,
>
> Regards,
>
>
>
>
> --
> Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
or in-place
updates ?
Kindly let me know,
Regards,
--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
ing solrj to update the document. Is there any spl API to be used for
> in place Updates ?
>
> Yes are we are updating in Batch of 1000 documents.
>
> As I mentioned before, since I am updating only docvalues i expect it should
> update in faster than updating
On 3/14/2018 8:27 AM, mganeshs wrote:
As I mentioned before, since I am updating only docvalues i expect it should
update in faster than updating normal field. Isn't it ?
Maybe. But not always.
To do an in-place update, Solr must rewrite the docValues data for that
field in that segment. It
Hi Emir,
I am using solrj to update the document. Is there any spl API to be used for
in place Updates ?
Yes are we are updating in Batch of 1000 documents.
As I mentioned before, since I am updating only docvalues i expect it should
update in faster than updating normal field. Isn'
> lot of fields and it's bit huge. We have a functionality, where we need to
> go and update a specific field or add new field in to that document. Since
> we have to do this for all 1M documents, it's taking up more time and it's
> not acceptable.
>
> So
more time and it's
not acceptable.
So we thought of using "In Place Updates".
As per documentation, we have made sure it's following this criteria
---
*An atomic update operation is performed using this approach only when the
fields to be updat
f update will be very close X.
>From this simple test I conclude that router.field somehow prevents updates
from being performed as in-place updates.
Can anyone confirm? Is this a bug? Anybody care to open a Jira item if
necessary?
According to the first comment on
https://issues.apache.o
> For in-place updates, the documentation states that only the fields being
> modified are updated, but does that mean that all other fields don't need
> to be stored?
Correct, in general there's no need to store the other fields. However,
there's a niche case
I need some clarity on atomic vs in-place updates. For atomic I understand
that all fields need to be stored, either explicitly or through docValues,
since the entire document is re-indexed.
For in-place updates, the documentation states that only the fields being
modified are updated, but does
20 matches
Mail list logo
