Ok, I figured you had some setup like that. Personally, I would prefer one large index. The overhead associated with opening/closing/managing thousands of searchers/modifiers is much bigger than to incorporate the personal restriction in the query. Also, you risk running out of filepointers, depending on your OS. If your documents are indexed like (userId, title, text, date), it's no hassle to search the subset of a certain userId even if the index is several million records big, by using a MultiFieldQuery which enforces the userId field. I have personally deployed this tactic in several projects where we've handled user restrictions / subset searches, and it's very convinient. Regarding the IndexModifier - you can only have one modifier open at once since they take write-looks. So, you would probably want to have a "crawler" which updates the index continously while you have an arbitrary amount of IndexSearchers (read-only) attached to the very same index.
Anyway, my $0.02! On 5/26/06, acorcutt <[EMAIL PROTECTED]> wrote:
sorry I did not mention this will be on a web server.. so if its one index per user it would mean many indexmodifiers running at once on the server. I guess mainly im trying to determine if running many indexmodifiers is a bad thing - I can see that smaller indexs will be quicker, but would that speed be lost by running maybe 1000 at once? -- View this message in context: http://www.nabble.com/Should+I+use+one+or+many+index%27s--t1684400.html#a4574646 Sent from the Lucene - General forum at Nabble.com.
