Local DB Composite Index

Note: this component is designated "advanced", which means that objects of this type are not expected to be created or altered in most environments. If you believe that such a change is necessary, you may want to contact support in order to understand the potential impact of that change.

Local DB Composite Indexes may be used to define an index based on a filter pattern and an optional base DN pattern.

At the present time, the server's composite index support largely overlaps with what is already available in the form of an attribute index. However, there may be a couple of advantages to using a composite index over an equality, ordering, or substring attribute index:

• The scope of an attribute index is the entire set of entries below the backend base DN. A composite index can be scoped to only a specified portion of the DIT using the index-base-dn-pattern property. The value of this property can be a fixed DN, but it can also be a DN pattern that makes use of wildcards that allow it to match a range of base DNs (for example, in a directory with a large number of branches and where the search base DN is often scoped so that it is at or below one of those branches).
• An attribute index indexes values for a single attribute type. A composite index filter pattern can index combinations of values for two or more attribute types. For example, in a directory with tenancy indicated by an entry's 'tenantID' attribute value and where the search filter is often an AND of 'tenantID' and another attribute type, composite indexes can be created such that each composite index's filter pattern references 'tenantID' and one other attribute type.
• In order for attribute indexes to be used to process both equality and ordering filters, separate indexes must be created and maintained. A single equality composite index, however, will be used to process equality and ordering filters.
• Attribute indexes use one of two extremes when maintaining the entry ID set associated with each key: either the entire ID set for a given index key is encoded as a single blob with all of the entry IDs, or it is an exploded index in which each entry ID is associated with a separate copy of the same key. For a large entry ID set, using one big blob is better for read performance, while using the exploded index approach of multiple copies of the same key is better for write performance. Composite indexes offer support for a middle ground in which the entire ID set can be broken up into pages of no more than a specified number of entry IDs. This leads to dramatically fewer database read operations than an exploded index when retrieving a large ID set, and when updating an ID set, you only need to update the page(s) that were altered.

dsconfig Usage

To list the configured Local DB Composite Indexes:

dsconfig list-local-db-composite-indexes
     [--property {propertyName}] ...

To view the configuration for an existing Local DB Composite Index:

dsconfig get-local-db-composite-index-prop
     --index-name {name}
     --backend-name {name}
     [--tab-delimited]
     [--script-friendly]
     [--property {propertyName}] ...

To update the configuration for an existing Local DB Composite Index:

dsconfig set-local-db-composite-index-prop
     --index-name {name}
     --backend-name {name}
     (--set|--add|--remove) {propertyName}:{propertyValue}
     [(--set|--add|--remove) {propertyName}:{propertyValue}] ...

To create a new Local DB Composite Index:

dsconfig create-local-db-composite-index
     --index-name {name}
     --backend-name {name}
     --set index-filter-pattern:{propertyValue}
     [--set {propertyName}:{propertyValue}] ...

To delete an existing Local DB Composite Index:

dsconfig delete-local-db-composite-index
     --index-name {name}
     --backend-name {name}