Index types
DS directory servers support multiple index types, each corresponding to a different type of search.
View what is indexed by using the backendstat list-indexes command.
For details about a particular index, you can use the backendstat dump-index command.
Presence index
A presence index matches an attribute that is present on the entry, regardless of the value.
By default, the aci attribute is indexed for presence:
$ ldapsearch \
--hostname localhost \
--port 1636 \
--useSsl \
--usePkcs12TrustStore /path/to/opendj/config/keystore \
--trustStorePassword:file /path/to/opendj/config/keystore.pin \
--bindDN uid=admin \
--bindPassword password \
--baseDN dc=example,dc=com \
"(aci=*)" \
aciA presence index takes up less space than other indexes. In a presence index, there is just one key with a list of IDs.
The following command examines the ACI presence index for a server configured with the evaluation profile:
$ stop-ds
$ backendstat \
dump-index \
--backendId dsEvaluation \
--baseDn dc=example,dc=com \
--indexName aci.presence
Key (len 1): PRESENCE
Value (len 3): [COUNT:2] 1 9
Total Records: 1
Total / Average Key Size: 1 bytes / 1 bytes
Total / Average Data Size: 3 bytes / 3 bytesIn this case, entries with ACI attributes have IDs 1 and 9.
Equality index
An equality index matches values that correspond exactly (generally ignoring case) to those in search filters. An equality index requires clients to match values without wildcards or misspellings:
$ ldapsearch \
--hostname localhost \
--port 1636 \
--useSsl \
--usePkcs12TrustStore /path/to/opendj/config/keystore \
--trustStorePassword:file /path/to/opendj/config/keystore.pin \
--bindDN uid=bjensen,ou=People,dc=example,dc=com \
--bindPassword hifalutin \
--baseDN dc=example,dc=com \
"(uid=bjensen)" \
mail
dn: uid=bjensen,ou=People,dc=example,dc=com
mail: bjensen@example.comAn equality index has one list of entry IDs for each attribute value.
Depending on the backend implementation, the keys in a case-insensitive index might not be strings.
For example, a key of 6A656E73656E could represent jensen.
The following command examines the SN equality index for a server configured with the evaluation profile:
$ stop-ds
$ backendstat \
dump-index \
--backendID dsEvaluation \
--baseDN dc=example,dc=com \
--indexName sn.caseIgnoreMatch | grep -A 1 "jensen$"
Key (len 6): jensen
Value (len 26): [COUNT:17] 18 31 32 66 79 94 133 134 150 5996 19415 32834 46253 59672 73091 86510 99929In this case, there are 17 entries that have an SN of Jensen.
Unless the keys are encrypted, the server can reuse an equality index for ordering and initial substring searches.
Approximate index
An approximate index matches values that "sound like" those provided in the filter.
An approximate index on sn lets client applications find people even when they misspell surnames:
$ ldapsearch \
--hostname localhost \
--port 1636 \
--useSsl \
--usePkcs12TrustStore /path/to/opendj/config/keystore \
--trustStorePassword:file /path/to/opendj/config/keystore.pin \
--bindDN uid=bjensen,ou=People,dc=example,dc=com \
--bindPassword hifalutin \
--baseDN dc=example,dc=com \
"(&(sn~=Jansen)(cn=Babs*))" \
cn
dn: uid=bjensen,ou=People,dc=example,dc=com
cn: Barbara Jensen
cn: Babs JensenAn approximate index squashes attribute values into a normalized form.
The following command examines an SN approximate index added to a server configured with the evaluation profile:
$ stop-ds
$ backendstat \
dump-index \
--backendID dsEvaluation \
--baseDN dc=example,dc=com \
--indexName sn.ds-mr-double-metaphone-approx | grep -A 1 "JNSN$"
Key (len 4): JNSN
Value (len 83): [COUNT:74] 18 31 32 59 66 79 94 133 134 150 5928 5939 5940 5941 5996 5997 6033 6034 19347 19358 19359 19360 19415 19416 19452 19453 32766 32777 32778 32779 32834 32835 32871 32872 46185 46196 46197 46198 46253 46254 46290 46291 59604 59615 59616 59617 59672 59673 59709 59710 73023 73034 73035 73036 73091 73092 73128 73129 86442 86453 86454 86455 86510 86511 86547 86548 99861 99872 99873 99874 99929 99930 99966 99967In this case, there are 74 entries that have an SN that sounds like Jensen.
Substring index
A substring index matches values that are specified with wildcards in the filter. Substring indexes can be expensive to maintain, especially for large attribute values:
$ ldapsearch \
--hostname localhost \
--port 1636 \
--useSsl \
--usePkcs12TrustStore /path/to/opendj/config/keystore \
--trustStorePassword:file /path/to/opendj/config/keystore.pin \
--bindDN uid=bjensen,ou=People,dc=example,dc=com \
--bindPassword hifalutin \
--baseDN dc=example,dc=com \
"(cn=Barb*)" \
cn
dn: uid=bfrancis,ou=People,dc=example,dc=com
cn: Barbara Francis
dn: uid=bhal2,ou=People,dc=example,dc=com
cn: Barbara Hall
dn: uid=bjablons,ou=People,dc=example,dc=com
cn: Barbara Jablonski
dn: uid=bjensen,ou=People,dc=example,dc=com
cn: Barbara Jensen
cn: Babs Jensen
dn: uid=bmaddox,ou=People,dc=example,dc=com
cn: Barbara MaddoxIn a substring index, there are enough keys to match any substring in the attribute values. Each key is associated with a list of IDs. The default maximum size of a substring key is 6 bytes.
The following command examines an SN substring index for a server configured with the evaluation profile:
$ stop-ds
$ backendstat \
dump-index \
--backendID dsEvaluation \
--baseDN dc=example,dc=com \
--indexName sn.caseIgnoreSubstringsMatch:6
...
Key (len 1): e
Value (len 25): [COUNT:22] ...
...
Key (len 2): en
Value (len 15): [COUNT:12] ...
...
Key (len 3): ens
Value (len 3): [COUNT:1] 147
Key (len 5): ensen
Value (len 10): [COUNT:9] 18 31 32 66 79 94 133 134 150
...
Key (len 6): jensen
Value (len 10): [COUNT:9] 18 31 32 66 79 94 133 134 150
...
Key (len 1): n
Value (len 35): [COUNT:32] ...
...
Key (len 2): ns
Value (len 3): [COUNT:1] 147
Key (len 4): nsen
Value (len 10): [COUNT:9] 18 31 32 66 79 94 133 134 150
...
Key (len 1): s
Value (len 13): [COUNT:12] 12 26 47 64 95 98 108 131 135 147 149 154
...
Key (len 2): se
Value (len 7): [COUNT:6] 52 58 75 117 123 148
Key (len 3): sen
Value (len 10): [COUNT:9] 18 31 32 66 79 94 133 134 150
...In this case, the SN value Jensen shares substrings with many other entries. The size of the lists and number of keys make a substring index much more expensive to maintain than other indexes. This is particularly true for longer attribute values.
Ordering index
An ordering index is used to match values for a filter that specifies a range.
For example, the ds-sync-hist attribute used by replication has an ordering index by default.
Searches on that attribute often seek entries with changes more recent than the last time a search was performed.
The following example shows a search that specifies a range on the SN attribute value:
$ ldapsearch \
--hostname localhost \
--port 1636 \
--useSsl \
--usePkcs12TrustStore /path/to/opendj/config/keystore \
--trustStorePassword:file /path/to/opendj/config/keystore.pin \
--bindDN uid=bjensen,ou=People,dc=example,dc=com \
--bindPassword hifalutin \
--baseDN dc=example,dc=com \
"(sn>=zyw)" \
sn
dn: uid=user.13401,ou=People,dc=example,dc=com
sn: Zywiel
dn: uid=user.26820,ou=People,dc=example,dc=com
sn: Zywiel
dn: uid=user.40239,ou=People,dc=example,dc=com
sn: Zywiel
dn: uid=user.53658,ou=People,dc=example,dc=com
sn: Zywiel
dn: uid=user.67077,ou=People,dc=example,dc=com
sn: Zywiel
dn: uid=user.80496,ou=People,dc=example,dc=com
sn: Zywiel
dn: uid=user.93915,ou=People,dc=example,dc=com
sn: ZywielIn this case, the server only requires an ordering index if it cannot reuse the (ordered) equality index instead. For example, if the equality index is encrypted, an ordering index must be maintained separately.
Big index
A big index is designed for attributes where many, many entries have the same attribute value.
This can happen for attributes whose values all belong to a known enumeration.
For example, if you have a directory service with an entry for each person in the United States,
the st (state) attribute is the same for more than 30 million Californians (st: CA).
With a regular equality index, a search for (st=CA) would be unindexed.
With a big index, the search is indexed, and optimized for paging through the results.
For an example, refer to
Indexes for attributes with few unique values.
A big index can be easier to configure and to use than a virtual list view index. Consider big indexes when:
-
Many1 entries have the same value for a given attribute.
DS search performance with a big index is equivalent to search performance with a standard index. For attributes with only a few unique values, big indexes support much higher modification rates.
-
Modifications outweigh searches for the attribute.
When attributes have a wide range of possible values, favor standard indexes, except when the attribute is often the target of modifications, and only sometimes part of a search filter.
1 Many, but not all entries.
Do not create a big index for all values of the objectClass attribute, for example.
When all entries have the same value for an attribute, as is the case for objectClass: top,
indexes consume additional system resources and disk space with no benefit.
The DS server must still read every entry to return search results.
In practice, the upper limit is probably somewhat less than half the total entries.
In other words, if half the entries have the same value for an attribute,
it will cost more to maintain the big index than to evaluate all entries to find matches for the search.
Let such searches remain unindexed searches.
Virtual list view (browsing) index
A virtual list view (VLV) or browsing index is designed to help applications that list results. For example, a GUI application might let users browse through a list of users. VLVs help the server respond to clients that request server-side sorting of the search results.
VLV indexes correspond to particular searches. Configure your VLV indexes using the command line.