On Tuesday, November 27, 2018 5:13:41 PM CST Howard Chu wrote:
Derek Zhou wrote:
Karsten
Unfortunately, down time is even worse than slow.
I wish OpenLDAP has an integrated search and delete operation, like delete entries based on a search filter, all executed in the same transaction in the server. That should be more efficient than doing search and delete from the client side because the B+ trees are just traversed once. Also the server can impose size limit on how many entries can be deleted in one go, just like the search, to avoid someone hogging the server.
For the LDAP gurus here, the above idea should be technically possible, right?
In normal operation, as opposed to simple experimentation, why do you actually need to delete a large number of entries quickly? If you just need to make them unavailable to a bunch of clients, you can first do a subtree rename to move them out of the way, and then delete incrementally at whatever speed.
If the database is going to occupy significant amount of diskspace, the sys admin in me will feel safer if I can delete fast. A file system can do that, a SQL database can do that. Imagine a user application is running wild and injecting a lot of junk data, being able to delete fast is crucial to keep the system up til the culprit is identified and killed. This scenario has happened to me several times, just not with a LDAP database.
Derek