|< Day Day Up >|| |
In Chapter 1, we saw that the directory server is specialized for high performance in information retrieval. Indexes are a tool to facilitate high-speed information retrieval. Besides the database files containing the actual data, there are index files used to access this data more rapidly. Indexes are built on behalf of attributes. Depending on your implementation, a few of them are predefined. On most directory servers, you will find an index for the attribute "objectClass." This index helps to speed up subtree searches in the directory.
You can configure further indexes, depending on the requirements of the directory server. This means that you should know which attributes in your implementation are frequently used for searches. These could be, for example, the "sn" and "givenName" and "uid" attributes. Again, this depends strongly on the purpose of your particular implementation. In a company phone book, users often look up a phone number using the surname and name. The opposite approach — using a phone number to look up a surname and name — is used less frequently. You can configure a number of indexes and verify their usage later on with the help of the log files.
You can even fine-tune the indexes. However, to do so, you need a thorough knowledge of the exact needs of the applications requesting data from your directory server. There are a number of different index types. Most directory server implementations recognize the following types:
Presence: This type of filter is useful if the directory server executes a lot of queries that only look to see whether an attribute is defined in a given entry. For example, the filter (mobile = *) could be used to identify everyone in the organization who has a mobile phone.
Equality: This filter parses for simple equality, e.g., the query filter (sn = Parker).
Substring: The substring increases search efficiency if you frequently use wildcards. For example, the query (sn = *ker) would find all words ending in "ker," such as Parker or Marker. This filter type is resource intensive and is the most expensive to maintain.
Approximate: We discussed the concept of "approximate matching" earlier in this chapter. This index type is used to accelerate the "sounds like" search in the database you. Remember, however, that this feature is language dependent. Consult the documentation that ships with your software to find out more. It may be that your language is not even supported. A number of vendors support U.S. English only.
Depending on your implementation, you may find other useful types of filters.
You will find that indexes are quite handy, but they come at a cost, depending on the index type and the number of indexes you define. The costs come in three forms:
Increased modify and insert time: The more indexes you have defined, the longer it will take to update or create them all in a modification or insert request.
Increased memory usage: Indexes are held in memory to increase their efficiency. The more indexes you use, the greater is the memory occupied by your directory server process.
Increased disk file usage: Index files occupy additional disk space.
You should carefully evaluate the benefit of indexes against these drawbacks and only use the indexes that you truly need. Of course, the choice of indexes depends on the demands that applications make upon your directory.
|< Day Day Up >|| |