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
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
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?pretty=20' -d '
{"query": {"bool": {"filter":
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
It's worth to try. I know about folks who build NRT system on it. One
thing, I might be wrong but, "pint" might mean points which is hardly
compatible with inPlace update. It should be the simplest numbers, if you
can debug Solr, check that it creates NumericDocValues, not sorted ones.
These are
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
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
Hi,
That’s how you build regular document. Incremental/atomic updates need to use
update commands.
Did not check latest Solrj, so maybe there is built in way of doing that, but
quick googling showed how it can be achieved:
SolrInputDocument doc2 = new SolrInputDocument();
Hi Emir,
It's normal setfield and addDocument
for ex.
in a for loop
solrInputDocument.setField(sFieldId, fieldValue);
and after this, we add the created document.
solrClient.add(collectionName, solrInputDocuments);
I just want to know whether, we need to do something specific for
Hi,
Can you share part of code where you prepare update.
Thanks,
Emir
--
Monitoring - Log Management - Alerting - Anomaly Detection
Solr & Elasticsearch Consulting Support Training - http://sematext.com/
> On 14 Mar 2018, at 15:27, mganeshs wrote:
>
> Hi Emir,
>
> I am
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.
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't it ?
Hi,
Did you confirm that it actually does in place update? In case of in place
update, after update (maybe try single) only doc values file should change (if
my understanding is right).
Do you update a full document or some test doc with a single field?
Do you batch updates or send one by one?
> 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 where if a simultaneous
14 matches
Mail list logo