Hi again,
Since you have a custom high availability solution over your solr
instances, I can't help much I guess... :-)
I usually rely on master/slave replication to separate index build and
index search processes.
The fact is that resources consumption at build time and search time are
not
hi thanks for the big reply ;)
i had the idea with the several and small 5M shards too.
and i think thats the next step i have to go, because our biggest index
grows each day with avg. 50K documents.
but make it sense to keep searcher AND updater cores on one big server? i
dont want to use replic
Hi,
If you only need to sum over "displayed" results, go with the
post-processing of hits solution, that's fast and easy.
If you sum over the whole data set (i.e your sum is not query
dependant), have it computed at indexing time, depending on your
indexing workflow.
Otherwise, (sum over the
yes, this way i am using on another part in my application. i hoped, that
exists another way to avoid the way over php
-
--- System
One Server, 12 GB RAM, 2 Solr Instances, 8 Cores,
1 Core with 45 Million Documents other Co
I Guess,
This has nothing to do with search part. You can post process the search
results(I mean iterate through your results and sum it)
Regds
Pravesh
--
View this message in context:
http://lucene.472066.n3.nabble.com/best-way-for-sum-of-fields-tp3477517p3486536.html
Sent from the Solr - User
sry.
i need the sum of values of the found documents. e.g. the total amount of
one day. each doc in index has ist own amount.
i try out something with StatsComponent but with 48 Million docs in Index
its to slow.
-
--- System ---
Please define "sum of fields". The total number of unique terms for
all the fields?
The sum of some values of some fields for each document?
The count of the number of fields in the index?
Other???
Best
Erick
On Thu, Nov 3, 2011 at 11:43 AM, stockii wrote:
> i am searching for the best way to ge
