[Date Prev][Date Next]
With the introduction of back_hdb in OpenLDAP 2.2.4, the speed of
adding/deleting directory entries is expected to
be increased. But how about the speed of modify indexed attributes? Is it
still the same as OpenLDAP 2.0..?
The high write concurrency in back-hdb has been largely defeated by the
syncrepl entryCSN update code, which serializes all modifications in both
back-bdb and back-hdb.
Modifying indexed attributes is slightly improved in OpenLDAP 2.1/2.2 vs
OpenLDAP 2.0 but not to any great extent.
It seems that back_hdb uses a indexing mechanism directed based on Berkely
DB. How deos this indexing method
compared with the original indexing used in back_bdb, in terms of performance
(or computational complexity)?
back-hdb is 95% identical to back-bdb. Both use the same indexing mechanism.
What is the function of bdb_modify_internal?
Its purpose is already fully described in the comments above it. It
consolidates the attribute value modifications that are needed by both
LDAPModify and LDAPModRdn processing.
The 'ndn' in bdb_cache_find_ndn means what? Normalized DN?
In bdb_dn2id_add, the key is set to dn and data is set to id when put into
the database, while
in hdb_dn2id_add, the order is reversed. I do not understand this. Could you
give some hint?
The back-hdb DN2ID structure uses RDNs, not full DNs. The layout was chosen
to efficiently support hierarchical descent from the root, as well as ascent
from a leaf node. Again, the comments in the code already describe the
content and the purpose of each field. A simplified illustration is available
here http://www.openldap.org/conf/odd-sfo-2003/howard-dev.html although the
actual implementation has evolved from when that paper was written.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support