A normal Lucene index should be able to handle it.
As long as no frequent insert/update, which can sometimes cause hiccups for
large indexes, one index is enough.
If your customer numbers keep growing, you will need to have one index for
each customer, which isn't that difficult really, especiall
Take a look at Solr - it should be able to handle the scale you describe. My
suggestion is not to partition indexes unless absolutely have to.
- Original Message
From: "spr...@gmx.eu"
To: java-user@lucene.apache.org
Sent: Saturday, February 14, 2009 10:27:58 AM
Subject: RE
Hi,
> You get one answer if each document is 1K, another if it's
> 1G. If you have 2 users or 10,000 users. If you require
> 100 queries/sec response time or 1 query can take 10
> seconds. If you require an update to the index every
> second or month...
Each doc has up to 10 A4 pages text.
There
Define efficiency. Define document. Define user. Define
This kind of question is unanswerable except in gross
generalities unless you take the time to provide details.
You get one answer if each document is 1K, another if it's
1G. If you have 2 users or 10,000 users. If you require
100 querie
can you provide a little more clarification as to what it is you are
trying to achieve (not just the way you hope to achieve it)
Specificly: I can't make sense of what you would expect to get back with a
query like this...
index1:query1 AND index2:query2
...traditionally, a query for "A and
I know it is possible to query against multiple indexes, but is it
possible to create a composite query in which part of the query is
against one index and part is against another (similar to querying
against a default and a second field)?
for example index1:query1 AND index2:query2
I tho
