Sharing Configuration Example
The IndexShardingStrategy also allows for optimizing searches by selecting which shard to run the query against. By activating a filter (see Section 5.3.1, “Using filters in a sharded environment”), a sharding strategy can select a subset of the shards used to answer a query (IndexShardingStrategy.getDirectoryProvidersForQuery) and thus speed up the query execution. Each shard has an independent directory provider configuration. The DirectoryProvider index names for the Animal entity in Example 3.5, “Sharding configuration for entity Animal” are Animal.0 to Animal.4. In other words, each shard has the name of it's owning index followed by . (dot) and its index number (see also Section 3.2, “Directory configuration”). Example 3.5. Sharding configuration for entity Animal hibernate.search.default.indexBase /usr/lucene/indexes hibernate.search.Animal.sharding_strategy.nbr_of_shards 5 hibernate.search.Animal.directory_provider filesystem hibernate.search.Animal.0.indexName Animal00 hibernate.search.Animal.3.indexBase /usr/lucene/sharded hibernate.search.Animal.3.indexName Animal03 In Example 3.5, “Sharding configuration for entity Animal”, the configuration uses the default id string hashing strategy and shards the Animal index into 5 sub-indexes. All sub-indexes are filesystem instances and the directory where each sub-index is stored is as followed: for sub-index 0: /usr/lucene/indexes/Animal00 (shared indexBase but overridden indexName) for sub-index 1: /usr/lucene/indexes/Animal.1 (shared indexBase, default indexName) for sub-index 2: /usr/lucene/indexes/Animal.2 (shared indexBase, default indexName) for sub-index 3: /usr/lucene/shared/Animal03 (overridden indexBase, overridden indexName) for sub-index 4: /usr/lucene/indexes/Animal.4 (shared indexBase, default indexName)