1. Use filter queries
> Here a example of query, there are any incorrect o anything that can I
> change?
> http://xxx:8893/solr/candidate/select/?q=+(IdCandidateStatus:2)+(IdCobranded:3)+(IdLocation1:12))+(LastLoginDate:[2011-08-26T00:00:00Z
> TO 2012-08-28T00:00:00Z])
What is the logic here? Are
13 GB index isn't too big, but going forward index sharding is the solutions
for large single core indexes. This way you can scale out.
This links will give you some info:
http://lucidworks.lucidimagination.com/display/solr/Distributed+Search+with+Index+Sharding
http://lucidworks.lucidimagination
Have you tried sharding ? The best practices recommend sharding when your
index grows too large and query time is slow.
On Tue, Aug 28, 2012 at 2:02 AM, mpcmarcos wrote:
> Hello,
>
> I have a problem, I'm working with Solr 3.5, with a index that has
> 8.000.000
> of documents (13Gb), each docum
How often the documents are added in the index? Try lessen down the optimize
frequency.
BTW do you optimize only on master (which should be the desired way).
Also specifically for dates ranges, try to use the filter queries, this way
it would be cached and would thus be faster. This would also a
t not as ranges). This might
give an indication of the kind of gain you could get with trie field types
for your numeric fields.
-- Jack Krupansky
-Original Message-
From: mpcmarcos
Sent: Tuesday, August 28, 2012 5:02 AM
To: solr-user@lucene.apache.org
Subject: Query Time problem o
Hello,
I have a problem, I'm working with Solr 3.5, with a index that has 8.000.000
of documents (13Gb), each document has a lot of fields, I include the schema
at bottom the message for more information.
The query time is very high, a simple query has a query time of 300-1.000
ms, and a complex