lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian Ohrt" <juliano...@gmx.net>
Subject AW: Howto verify that update is "in-place"
Date Tue, 17 Oct 2017 10:33:31 GMT
Hi Emir nad Amrit,

@Emir: Nice idea but after changing any document in any way and after committing the changes,
all Doc counter (Num, Max, Deleted) are still the same, only thing that changes is the Version
(increases by steps of 2) .

@Amrit: Are you saying that the _version_ field should not change when performing an atomic
update operation?

Thanks
James

-----Urspr├╝ngliche Nachricht-----
Von: Amrit Sarkar [mailto:sarkaramrit2@gmail.com] 
Gesendet: Dienstag, 17. Oktober 2017 11:35
An: solr-user@lucene.apache.org
Betreff: Re: Howto verify that update is "in-place"

Hi James,

As for each update you are doing via atomic operation contains the "id" / "uniqueKey". Comparing
the "_version_" field value for one of them would be fine for a batch. Rest, Emir has list
them out.

Amrit Sarkar
Search Engineer
Lucidworks, Inc.
415-589-9269
www.lucidworks.com
Twitter http://twitter.com/lucidworks
LinkedIn: https://www.linkedin.com/in/sarkaramrit2

On Tue, Oct 17, 2017 at 2:47 PM, Emir Arnautovi─ç < emir.arnautovic@sematext.com> wrote:

> Hi James,
> I did not try, but checking max and num doc might give you info if 
> update was in-place or atomic - atomic is reindexing of existing doc 
> so the old doc will be deleted. In-place update should just update doc 
> values of existing doc so number of deleted docs should not change.
>
> HTH,
> Emir
> --
> Monitoring - Log Management - Alerting - Anomaly Detection Solr & 
> Elasticsearch Consulting Support Training - http://sematext.com/
>
>
>
> > On 17 Oct 2017, at 09:57, James <james@ohrt.info> wrote:
> >
> > I am using Solr 6.6 and carefully read the documentation about 
> > atomic and in-place updates. I am pretty sure that everything is set 
> > up as it
> should.
> >
> >
> >
> > But how can I make certain that a simple update command actually
> performs an
> > in-place update without internally re-indexing all other fields?
> >
> >
> >
> > I am issuing this command to my server:
> >
> > (I am using implicit document routing, so I need the "Shard" 
> > parameter.)
> >
> >
> >
> > {
> >
> > "ID":1133,
> >
> > "Property_2":{"set":124},
> >
> > "Shard":"FirstShard"
> >
> > }
> >
> >
> >
> >
> >
> > The log outputs:
> >
> >
> >
> > 2017-10-17 07:39:18.701 INFO  (qtp1937348256-643) [c:MyCollection 
> > s:FirstShard r:core_node27 x:MyCollection_FirstShard_replica1]
> > o.a.s.u.p.LogUpdateProcessorFactory 
> > [MyCollection_FirstShard_replica1]
> > webapp=/solr path=/update
> > params={commitWithin=1000&boost=1.0&overwrite=true&wt=
> json&_=1508221142230}{
> > add=[1133 (1581489542869811200)]} 0 1
> >
> > 2017-10-17 07:39:19.703 INFO  (commitScheduler-283-thread-1)
> [c:MyCollection
> > s:FirstShard r:core_node27 x:MyCollection_FirstShard_replica1]
> > o.a.s.u.DirectUpdateHandler2 start
> > commit{,optimize=false,openSearcher=false,waitSearcher=true,
> expungeDeletes=f
> > alse,softCommit=true,prepareCommit=false}
> >
> > 2017-10-17 07:39:19.703 INFO  (commitScheduler-283-thread-1)
> [c:MyCollection
> > s:FirstShard r:core_node27 x:MyCollection_FirstShard_replica1]
> > o.a.s.s.SolrIndexSearcher Opening
> > [Searcher@32d539b4[MyCollection_FirstShard_replica1] main]
> >
> > 2017-10-17 07:39:19.703 INFO  (commitScheduler-283-thread-1)
> [c:MyCollection
> > s:FirstShard r:core_node27 x:MyCollection_FirstShard_replica1]
> > o.a.s.u.DirectUpdateHandler2 end_commit_flush
> >
> > 2017-10-17 07:39:19.703 INFO
> > (searcherExecutor-268-thread-1-processing-n:192.168.117.142:8983_sol
> > r
> > x:MyCollection_FirstShard_replica1 s:FirstShard c:MyCollection
> > r:core_node27) [c:MyCollection s:FirstShard r:core_node27 
> > x:MyCollection_FirstShard_replica1] o.a.s.c.QuerySenderListener 
> > QuerySenderListener sending requests to 
> > Searcher@32d539b4[MyCollection_FirstShard_replica1]
> > main{ExitableDirectoryReader(UninvertingDirectoryReader(
> Uninverting(_i(6.6.0
> > ):C5011/1) Uninverting(_j(6.6.0):C478) Uninverting(_k(6.6.0):C345)
> > Uninverting(_l(6.6.0):C4182) Uninverting(_m(6.6.0):C317)
> > Uninverting(_n(6.6.0):C399) Uninverting(_q(6.6.0):C1)))}
> >
> > 2017-10-17 07:39:19.703 INFO
> > (searcherExecutor-268-thread-1-processing-n:192.168.117.142:8983_sol
> > r
> > x:MyCollection_FirstShard_replica1 s:FirstShard c:MyCollection
> > r:core_node27) [c:MyCollection s:FirstShard r:core_node27 
> > x:MyCollection_FirstShard_replica1] o.a.s.c.QuerySenderListener 
> > QuerySenderListener done.
> >
> > 2017-10-17 07:39:19.703 INFO
> > (searcherExecutor-268-thread-1-processing-n:192.168.117.142:8983_sol
> > r
> > x:MyCollection_FirstShard_replica1 s:FirstShard c:MyCollection
> > r:core_node27) [c:MyCollection s:FirstShard r:core_node27 
> > x:MyCollection_FirstShard_replica1] o.a.s.c.SolrCore 
> > [MyCollection_FirstShard_replica1] Registered new searcher 
> > Searcher@32d539b4[MyCollection_FirstShard_replica1]
> > main{ExitableDirectoryReader(UninvertingDirectoryReader(
> Uninverting(_i(6.6.0
> > ):C5011/1) Uninverting(_j(6.6.0):C478) Uninverting(_k(6.6.0):C345)
> > Uninverting(_l(6.6.0):C4182) Uninverting(_m(6.6.0):C317)
> > Uninverting(_n(6.6.0):C399) Uninverting(_q(6.6.0):C1)))}
> >
> >
> >
> > If I issue another, non-in-place update to another field which is 
> > not a DocValue, the log output is very similar. Can I increase 
> > verbosity? Will
> it
> > tell me more about the type of update then?
> >
> >
> >
> > Thank you!
> >
> > James
> >
> >
> >
> >
> >
> >
> >
>
>


Mime
View raw message