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" <spr...@gmx.eu> To: java-user@lucene.apache.org Sent: Saturday, February 14, 2009 10:27:58 AM Subject: RE: Multiple indexes vs single index 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 will be about 100 customers/clients/companies (not users, every customer will have about 10 users). I would expect 1 query/s not more. No updates to the index. > You have two problems with maintaining one index/user. > 1> Trying to maintain N indexes is much harder than one, > especially when you factor in backups, etc. This is the biggest problem I see. > 2> There is a cost to opening an index. If you look at the > Wiki you'll see that the recommendation is that you > open an index, and run a few warmup queries to fill > caches etc. before, for instance, measuring performance. > So if you maintain an index/user, how do you expect > to handle this issue? I would open the index on demand and close it after a period of inactivity. --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
