Hi Team, Any suggestion or recommendation for the above approach which we are
doing to have better search performance.
--
Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Thanks a lot for your time to respond for my clarifications.
We are having two environment,
ENV A and ENV B ( Both same capacity of RAM ( r5.2xlarge and same number of
shards and replicas type (NRT) for the collection)
ENV A - it is having a collection which is optimized ( segment count 1 and
n
That seems high. It can be tricky to get tests. Are you running with
some kind of test runner? Do you have, say, 3-4 thousand queries
you run? Are you running the tests after warming the searchers?
Also, if you have indexed down to one segment, _then_ tried
adding docs and measuring you are not ge
Thanks Erick for the details and reference to understand better about merging
segment stuff.
When I compare performance of uninterrupted/optimized ( segment count 1)
collection for search request vs (indexing + search) in parallel going on
collection performance is 3 times higher,
for example
Updated documents are marked as deleted in the
old segment and added to a new segment. When
commits happen, merges occur and only then is the
space occupied by the deleted document reclaimed.
Which segments are merged on commit depends
on a number of factors.
Unless you can prove the extra space
Even though same document indexed over and over again due to incremental
update. Index size is being increased.
Do I miss any configuration to make optimization occur by internally ?
--
Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Hi,
We are using SOLR 7.5.0 version, We are testing one collection for both
Search and Index.
Our collection created with below indexerconfig, We are using indexing
process KAFKA connect plugin with every 5 min commit (cloud SOLRJ) as below
https://github.com/jcustenborder/kafka-connect-solr
Our
