one large index vs many small indexes

hello, we must make a design decision for our system. we have many customers wich all should use the same server. now we are thinking about to make a separate lucene index for each customer, or to make one large index and use a filter for each customer. any suggestions, comments or

Re: one large index vs many small indexes

Hi, many small indexes seem more reasonable and much more efficient than one common large index for all customers. I recommend a very good book Lucene in Action - just reading a first few chapters (indexing & searching) will give you a very good idea about Lucene internals, index structure and

Re: one large index vs many small indexes

I would add an additional consideration. Are we aggregating any of the results ? Is any use case where we aggregate the results from different Indexes into one response? In the case we would need to calculate the aggregation overload. This means that if the Index is not that big, sometimes is

Re: one large index vs many small indexes

Lutz Fechner wrote: > separated index will allow you split IO load over multiple > physical drives as well as use different Analyzers (if your > customers are having different content that will make sense). Other ways to get better IO is RAID, SSD or RAM. Multiple

lucene query complexity

Hi, I've been thinking how to use big O annotation to show complexity for different types of queries, like term query, prefix query, phrase query, wild card and fuzzy query. Any ideas? thanks, Zong

Query documents where Field Doesn't Exist

Hello, I read some discussions at Internet and still don't see if there is an official Lucene's solution to support: "query documents where Field Doesn't exist" Do you know if there is some recommended solution? Thanks, Vladimir Kuzmin