We have approx 500 customers, each with their own virtual database. We are implementing Hibernate Search, and would like the keep their Lucene indexes separate, as well.

Ideally, the indexes would be stored in $indexBase/$customerID/$entityName. In Hibernate Search, it seems that I can set an indexBase (via .properties), and an entityName (via @Indexed), but I can't break out the indexes by customer.

We don't need to query multiple customers at once. What would be a good solution in this case?

1. Leave everything in one index, using filters to get data back for a single customer.
2. Implement a custom DirectoryProvider. How do we get access to the current entity object from there?
3. Implement sharding. Is it possible to implement index sharding, but not database sharding?

Hi,

I definitely would choose the Filter approach. It will fulfill your requirements w/o the need of extending Hibernate Search itself. The online documentation and also "Hibernate Search in Action" have examples for your use case.

--Hardy

Thanks for the response,

I was able to implement a Filter prototype very quickly. However, we are worried about having all the customers on one index. The load experience by that one index is unnecessarily high, and if the index becomes corrupted it will take down all customers instead of just one customer.

I was also able to prototype a custom DirectoryProvider which receives state on which index to use via a Property object passed in from the caller. However, the Hibernate Search code caches the mapping of entity to index, so we would need to modify the core code if we wanted to continue to use that mechanism.

I also bought "Hibernate Search in Action", and read up on sharding. It would seem that we could shard by customer fairly easily for indexing. But for searching, every index will be queried, which is not what we want.

We are seriously considering creating a local patch for Hibernate Search, which I generally loath to do.

I have found the request HSEARCH-251, http://opensource.atlassian.com/project ... SEARCH-251, which would limit searches to a single shard. This appears to be what I want. I'll join the dev discussion.

Great. We also always need a helping hand ;-)

FYI - There is a fix into trunk on that issue. You can now use a Filter to decide which shards to search against in your indexing strategy.