Optimizing after daily Replication - Does optimization resets cache?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Optimizing after daily Replication - Does optimization resets cache?

Paras Lehana
Hi,

*The Scenario: *We *atomically* update (*no deletion*) data for our
Auto-Suggest index every morning on master. The slave is our production
server. Master replicates to slave when the traffic is least on production
server.

*Objective: *Faster search. Real-Time updates are really not necessary.

*Query: *I was reading articles about optimizations, merging and
committing. My basic queries can be summed up as:

   1. Should we optimize the index after atomic updates before replication?
   This equates to single optimization operation daily during low traffic
   (morning).
   2. Since speed is our focus (and not storage resource at this time) and
   that optimizations builds the index again by merging, does this mean that
   the whole cache is also refreshed? If yes, this would mean that we would be
   flushing cache everyday and if we really want to go ahead with this, I
   think, we should relook about autowarming.
   3. What's tradeoff in our scenario? Storage v/s Speed? Or am I missing
   something. What if I choose not to optimize?


--
--
Regards,

*Paras Lehana* [65871]
Software Programmer, Auto-Suggest,
IndiaMART Intermesh Ltd.

8th Floor, Tower A, Advant-Navis Business Park, Sector 142,
Noida, UP, IN - 201303

Mob.: +91-9560911996
Work: 01203916600 | Extn:  *8173*

--
IMPORTANT: 
NEVER share your IndiaMART OTP/ Password with anyone.
Reply | Threaded
Open this post in threaded view
|

Re: Optimizing after daily Replication - Does optimization resets cache?

Emir Arnautović
Hi Paras,
In master-slave model, optimisation will affect only master since slaves will get optimised segments from master. But note that slaves get what changed from master and in case of optimisation entire index will be replicated so you can experience longer replications and in case of large indices you can run into issues with network unless you throttle replication (which will again result in longer replication time). When it comes to caches, there are some per segment caches but majority of caches are invalidated on any index searcher reopening so it does not matter if you optimised or not. What you need to do is autowarm caches if you do not want to experience performance drops. When it comes to performance, optimisation will give you some boost since you are searching single segment instead of many, but you should not expect significant difference. Optimisation might be a good option in case you do a lot of deletes/updates so your big segments end up with large number of deleted documents, but you can also consider using reclaimDeletesWeight to tune merge policy or use expungeDeletes.

HTH,
Emir
--
Monitoring - Log Management - Alerting - Anomaly Detection
Solr & Elasticsearch Consulting Support Training - http://sematext.com/



> On 16 Sep 2019, at 08:06, Paras Lehana <[hidden email]> wrote:
>
> Hi,
>
> *The Scenario: *We *atomically* update (*no deletion*) data for our
> Auto-Suggest index every morning on master. The slave is our production
> server. Master replicates to slave when the traffic is least on production
> server.
>
> *Objective: *Faster search. Real-Time updates are really not necessary.
>
> *Query: *I was reading articles about optimizations, merging and
> committing. My basic queries can be summed up as:
>
>   1. Should we optimize the index after atomic updates before replication?
>   This equates to single optimization operation daily during low traffic
>   (morning).
>   2. Since speed is our focus (and not storage resource at this time) and
>   that optimizations builds the index again by merging, does this mean that
>   the whole cache is also refreshed? If yes, this would mean that we would be
>   flushing cache everyday and if we really want to go ahead with this, I
>   think, we should relook about autowarming.
>   3. What's tradeoff in our scenario? Storage v/s Speed? Or am I missing
>   something. What if I choose not to optimize?
>
>
> --
> --
> Regards,
>
> *Paras Lehana* [65871]
> Software Programmer, Auto-Suggest,
> IndiaMART Intermesh Ltd.
>
> 8th Floor, Tower A, Advant-Navis Business Park, Sector 142,
> Noida, UP, IN - 201303
>
> Mob.: +91-9560911996
> Work: 01203916600 | Extn:  *8173*
>
> --
> IMPORTANT:
> NEVER share your IndiaMART OTP/ Password with anyone.