> ... > 1. I've not tested my application with single index as initially (a few > years back) we thought smaller the index size (7 indexes for default 80% > searches) the faster the search time would be ...
Possibly. Maybe it will be acceptable to make some searches a bit slower in order to make the slow ones faster. But my guess would still be that a single index with filtered searches would be quicker for most searches. > 2. For sharing/caching we create index readers once the server starts and > use these throughout the server's life (1 day). At the time of searches, > number of indexes to be read are decided by analyzing the search parameters. > IndexSearchers are created on persistent IndexReaders and finally a > ParallelMultiSearcher is created from these IndexSearchers (I hope this is > not a problem, or is it???) Sounds fine, except that in latest versions of lucene, ParallelMultiSearcher is deprecated. > 3. I had gone through the link you provided and some of the things are > already implemented (e.g. readOnly=true, NIOFSDirectory, optmizing, etc.). > We are using filters for some of the fields and caching those filters in the > memory, through hashtable. Sounds good. > Will reducing number of tokens in a particular field in index reduce the > search time (or CPU, memory etc)? Yes, in theory, but unless the numbers are really high I doubt you'll notice it. > E.g. I have 11 documents and tokens in field (fld1) are > 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9 and 2.0. > > The query is - fld1:[ 1.0 TO 2.0 ] > > Would it make any difference if the tokens in documents (in the same field) > would be > 1,1,1,1,1,1,1,1,1,2 > ?? Unlikely. But if those are all always numbers it would be worth looking at NumericField and NumericRangeQuery. -- Ian. --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
