About the exploded index format
The index-entry-limit backend configuration property specifies the maximum number of entries kept in an index record before the server stops maintaining that record, begins scanning the whole database, and runs an expensive unindexed search.
|
Because composite indexes are much more efficient than exploded indexes when dealing with large numbers of identical keys, use composite indexes for data sets where large numbers of entries (several thousand or more) share the same value for an indexed attribute. |
If any index keys have already reached this limit, you must rebuild these indexes before they can use a new limit. If you configure index-entry-limit to be greater than 50000, any keys with more than 50000 entries are stored in a separate database in an expanded, or exploded, format.
All keys with less than 50000 entries continue to be stored in one database in a consolidated format so that changes to the key require rewriting all the entry IDs matching the key. All keys with more than 50000 entries and less than the index-entry-limit are stored in a separate database in an exploded format so that changes to the key require writing to the updated entry ID only.
If you increase the index-entry-limit to 100000, any key with an entry count less than 50000 continues to be stored in consolidated format. If a key has an entry count greater than 50000, it is stored in a separate database where each key is stored with its entry ID individually. The consolidated format is efficient for read operations because the server can retrieve a row of entry IDs at once, while the exploded format is efficient for high volumes of write operations because it avoids large on-disk growth.