About Indexes And Indexing Performance - Red Hat DIRECTORY SERVER 7.1 - ADMINISTRATOR Administrator's Manual

About Indexes

About Indexes and Indexing Performance

Indexes are stored in files in the directory's databases. Each index is composed of
a table of index keys and matching entry ID lists. This entry ID list is used by the
directory to build a list of candidate entries that may match a client application's
search request, which speeds up searches.
The names of the files are based on the indexed attribute, not the type of index
contained in the file. Each index file may contain multiple types of indexes if
multiple indexes are maintained for the specific attribute. For example, all indexes
maintained for the common name attribute are contained in the
Indexes are time- and resource-consuming for the directory to maintain. For every
modification to an indexed attribute, new indexes are generated. Also, index files
can be large for large databases and become larger as the number of attributes and
types of indexes increase. See "Balancing the Benefits of Indexing," on page 395
for an example of maintaining indexes. However, for large directories (larger than
1000 entries) the cost of maintaining indexes is balanced by overall improved
performance. Also, the secondary index structure has been redesigned to allow
grately improved indexing, write (change), and search performance, which also
offsets the costs of indexing.
In previous versions, write performance was limited by the number of bytes per
second that could be written into the storage manager s transaction log file. The
secondary index structure was separated into two levels:
• The ID list structures, which were the province of the Directory Server
backend and opaque to the storage manager.
• The storage manager structures (Btrees), which were opaque to the Directory
Server backend code.
Because it had no insight into the internal structure of the ID lists, the storage
manager had to treat ID lists as opaque byte arrays. From the storage manager's
perspective, when the content of an ID list changed, the entire list had changed.
For a single ID that was inserted or deleted from an ID list, the corresponding
number of bytes written to the transaction log was the maximum configured size
for that ID list, about 8Kbytes; log file verbosity could easily be 100 times the
corresponding number of bytes changed in the Directory Server since most of the
log file contents relate to index changes (insert and delete operations). Also, every
database page on which the list was stored was marked as dirty, since the "entire"
list had changed.
386 Red Hat Directory Server Administrator's Guide • May 2005
file.
cn.db3