[Date Prev][Date Next]
Re: Write-intensive LDAP
On Tue, 17 Sep 2002, Rick van Rein wrote:
> Although it is common knowledge that LDAP is mainly used for applications
> that are almost read-only, I wonder if that is more than a cultural issue.
> I'm designing a directory holding certificates, but it would suit me rather
> well if I could put payment information and sales progress information in
> there as well. So that it could be accessed by resellers in a standard
> format, rather than through some crummy web interface that half of the
> resellers would parse with Perl.
> (Resellers are to act on behalf of OpenFortress in selling its digitally
> signed products, and would therefore have access to the LDAP directory,
> or a specific corner of it meant for resale. Orders, when they are not
> finalised yet, tend to go through phases, and would be changed by
> different parties while doing so. This is a specific example of a
> workflow application, I suppose.)
> As far as I can tell from the LDAP protocol spec and the C API spec, there
> is no technical hindrance that would stop apps like this, that write more
> often than a phone book changes. When I look at the OpenLDAP software
> though, and I bet other software behaves similarly, it is not very good at
> processing many writes. I am unsure, but this may be a backend issue, and
> it could perhaps be solved with a specific backend for the reseller corner
> of the directory, that welcomes writes and is less eager to build indices
> than OpenLDAP usually is.
- Read the protocol more closely. There is no support for transactions
or locking. You will have a hard time building a robust system with
lot's of writes without those primatives. Any system that writes
extensively to LDAP needs to support a complete rollback/queueing
implementation outside of the protocol. Speed is not the problem,
consistancy is what will bite you in the long run. LDAP works fine
for WIRM applications ( write infrequently read many), it breaks
horribly for write intensive applications.
- Booker C. Bense