Hi folks!
I wonder if, with the increased interest on mdb, the support for bdb will be removed in a near future.
Thanks a lot.
--On Wednesday, March 19, 2014 9:16 AM -0300 Friedrich Locke friedrich.locke@gmail.com wrote:
Hi folks!
I wonder if, with the increased interest on mdb, the support for bdb will be removed in a near future.
Thanks a lot.
Hi Friedrich,
bdb and hdb will still exist, but be disabled by default in configure, with OpenLDAP 2.5. Removal would be slated for OpenLDAP 2.6.
--Quanah
--
Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Wednesday, March 19, 2014 9:16 AM -0300 Friedrich Locke friedrich.locke@gmail.com wrote:
Hi folks!
I wonder if, with the increased interest on mdb, the support for bdb will be removed in a near future.
Thanks a lot.
See the slides from LDAPCon 2013. http://lanyrd.com/2013/ldapcon/sckyhk/
Since Oracle has changed the license of BDB 6 to AGPLv3, most network services that used BDB will be required to migrate away from it. (This also affects Cyrus SASL and Heimdal Kerberos, but we already wrote LMDB drivers for them 3 years ago.) And since BDB is now technologically obsolete anyway, there's no reason to continue to support it.
Hi Friedrich,
bdb and hdb will still exist, but be disabled by default in configure, with OpenLDAP 2.5. Removal would be slated for OpenLDAP 2.6.
Howard Chu hyc@symas.com schrieb am 19.03.2014 um 18:29 in Nachricht
Quanah Gibson-Mount wrote:
--On Wednesday, March 19, 2014 9:16 AM -0300 Friedrich Locke friedrich.locke@gmail.com wrote:
Hi folks!
I wonder if, with the increased interest on mdb, the support for bdb will be removed in a near future.
Thanks a lot.
See the slides from LDAPCon 2013. http://lanyrd.com/2013/ldapcon/sckyhk/
Since Oracle has changed the license of BDB 6 to AGPLv3, most network services that used BDB will be required to migrate away from it. (This also affects Cyrus SASL and Heimdal Kerberos, but we already wrote LMDB drivers for them 3 years ago.) And since BDB is now technologically obsolete anyway, there's no reason to continue to support it.
Hi!
Why is BDB technologically obsolete? Can you elabporate?
Regards, Ulrich
Hi Friedrich,
bdb and hdb will still exist, but be disabled by default in configure, with OpenLDAP 2.5. Removal would be slated for OpenLDAP 2.6.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Ulrich Windl wrote:
Howard Chu hyc@symas.com schrieb am 19.03.2014 um 18:29 in Nachricht
Quanah Gibson-Mount wrote:
--On Wednesday, March 19, 2014 9:16 AM -0300 Friedrich Locke friedrich.locke@gmail.com wrote:
Hi folks!
I wonder if, with the increased interest on mdb, the support for bdb will be removed in a near future.
Thanks a lot.
See the slides from LDAPCon 2013. http://lanyrd.com/2013/ldapcon/sckyhk/
Since Oracle has changed the license of BDB 6 to AGPLv3, most network services that used BDB will be required to migrate away from it. (This also affects Cyrus SASL and Heimdal Kerberos, but we already wrote LMDB drivers for them 3 years ago.) And since BDB is now technologically obsolete anyway, there's no reason to continue to support it.
Hi!
Why is BDB technologically obsolete? Can you elabporate?
I've been doing so for at least the past 3 years. Read http://symas.com/mdb/
Regards, Ulrich
Hi Friedrich,
bdb and hdb will still exist, but be disabled by default in configure, with OpenLDAP 2.5. Removal would be slated for OpenLDAP 2.6.
Howard Chu hyc@symas.com schrieb am 20.03.2014 um 08:14 in Nachricht
Ulrich Windl wrote:
Howard Chu hyc@symas.com schrieb am 19.03.2014 um 18:29 in Nachricht
Quanah Gibson-Mount wrote:
--On Wednesday, March 19, 2014 9:16 AM -0300 Friedrich Locke friedrich.locke@gmail.com wrote:
Hi folks!
I wonder if, with the increased interest on mdb, the support for bdb will be removed in a near future.
Thanks a lot.
See the slides from LDAPCon 2013. http://lanyrd.com/2013/ldapcon/sckyhk/
Since Oracle has changed the license of BDB 6 to AGPLv3, most network services that used BDB will be required to migrate away from it. (This also affects Cyrus SASL and Heimdal Kerberos, but we already wrote LMDB drivers for them 3 years ago.) And since BDB is now technologically obsolete anyway, there's no reason to continue to support it.
Hi!
Why is BDB technologically obsolete? Can you elabporate?
I've been doing so for at least the past 3 years. Read http://symas.com/mdb/
Hi!
When reading, you just say that MDB has some features BDB does not have. Does that make BDB obsolete technology? I think it depends on the user's demands.
Regards, Ulrich
Regards, Ulrich
Hi Friedrich,
bdb and hdb will still exist, but be disabled by default in configure, with OpenLDAP 2.5. Removal would be slated for OpenLDAP 2.6.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Ulrich Windl wrote:
Howard Chu hyc@symas.com schrieb am 20.03.2014 um 08:14 in Nachricht
Ulrich Windl wrote:
Howard Chu hyc@symas.com schrieb am 19.03.2014 um 18:29 in Nachricht
Quanah Gibson-Mount wrote:
--On Wednesday, March 19, 2014 9:16 AM -0300 Friedrich Locke friedrich.locke@gmail.com wrote:
Hi folks!
I wonder if, with the increased interest on mdb, the support for bdb will be removed in a near future.
Thanks a lot.
See the slides from LDAPCon 2013. http://lanyrd.com/2013/ldapcon/sckyhk/
Since Oracle has changed the license of BDB 6 to AGPLv3, most network services that used BDB will be required to migrate away from it. (This also affects Cyrus SASL and Heimdal Kerberos, but we already wrote LMDB drivers for them 3 years ago.) And since BDB is now technologically obsolete anyway, there's no reason to continue to support it.
Hi!
Why is BDB technologically obsolete? Can you elabporate?
I've been doing so for at least the past 3 years. Read http://symas.com/mdb/
Hi!
When reading, you just say that MDB has some features BDB does not have. Does that make BDB obsolete technology? I think it depends on the user's demands.
Your reading skills need work. BDB is big, slow, prone to deadlock and corruption, and complex to configure and tune. It has only gotten moreso in each subsequent release.
Considering that the purpose of a database is to safely, reliably, and efficiently store and retrieve data, BDB is by every measure obsolete.
Ulrich Windl wrote:
When reading, you just say that MDB has some features BDB does not have. Does that make BDB obsolete technology? I think it depends on the user's demands.
IMO today MDB meets user's demands much better than BDB for various reasons already mentioned here. No need to discuss that further since time will tell.
So, many thanks to Howard for releasing it as real open source software.
Ciao, Michael.
* Ulrich Windl:
When reading, you just say that MDB has some features BDB does not have. Does that make BDB obsolete technology? I think it depends on the user's demands.
Berkeley DB supports arbitrary key sizes. For some use cases, this is quite handy, but it's apparently not relevant to OpenLDAP.
Multiple concurrent writers are nice on paper, but probably are not worth the complexity for an in-process database.
Florian Weimer wrote:
Multiple concurrent writers are nice on paper, but probably are not worth the complexity for an in-process database.
Your statement sounds a bit like "640 kByte RAM is enough for everybody" or similar famous misunderstandings in the IT history already proven to be false.
E.g. my Seamonkey and LibreOffice use the same cert/key database concurrently without accessing a separate service.
IMO a lot of DBUS service stuff or similar cruft could be avoided by using concurrent writing of different processes to a single embedded DB.
Ciao, Michael.
* Michael Ströder:
Florian Weimer wrote:
Multiple concurrent writers are nice on paper, but probably are not worth the complexity for an in-process database.
Your statement sounds a bit like "640 kByte RAM is enough for everybody" or similar famous misunderstandings in the IT history already proven to be false.
E.g. my Seamonkey and LibreOffice use the same cert/key database concurrently without accessing a separate service.
I think there is a misunderstanding what I meant with "concurrent". What I wanted to say is that Berkeley DB supports (in some cases at least) that process 1 updates the values at keys A1, A2, A3, while, at the same time, process 2 updates the values at keys B1, B2, B3. That is, both transactions make progress at the same time, executing in a interleaved manner (even physically, on multi-processor machines). This is different from multiple processes opening the database for writing, and obtaining an exclusive lock before updating it, although observable behavior will not differ much if the transactions are short, the working set fits into memory etc.
But the sad truth is that you cannot avoid in all cases that writers block writers. Two transactions might update the same values. Or there are secondary indexes that need updating. Or you have page-level locking (like the B-trees in Berkeley DB) and the keys all happen to be on the same page. You even have to write your application code such that it retries transactions in case of deadlocks (IIRC, this is necessary with Berkeley DB even in the case of one writer and multiple readers). And concurrent, interleaved execution is particularly interesting if the transactions execute for some time, but this makes it all the more likely that anything triggers a conflict. Berkeley DB does not offer row-level locking for B-trees, and the transaction size is limited by the lock space by page-level locks, so it is particularly prone to aborting transactions once they grow larger. And yet Berkeley DB's transactional data store is tremendously complex and difficult to package in a friendly way for end users, with automated recovery and upgrades across major Berkeley DB versions.
This is why I think the Berkeley DB approach is a poor trade-off.
IMO a lot of DBUS service stuff or similar cruft could be avoided by using concurrent writing of different processes to a single embedded DB.
IPC has the advantage that it isolates the database from application crashes.
Florian Weimer wrote:
- Michael Ströder:
Florian Weimer wrote:
Multiple concurrent writers are nice on paper, but probably are not worth the complexity for an in-process database.
Your statement sounds a bit like "640 kByte RAM is enough for everybody" or similar famous misunderstandings in the IT history already proven to be false.
E.g. my Seamonkey and LibreOffice use the same cert/key database concurrently without accessing a separate service.
I think there is a misunderstanding what I meant with "concurrent". What I wanted to say is that Berkeley DB supports (in some cases at least) that process 1 updates the values at keys A1, A2, A3, while, at the same time, process 2 updates the values at keys B1, B2, B3. That is, both transactions make progress at the same time, executing in a interleaved manner (even physically, on multi-processor machines). This is different from multiple processes opening the database for writing, and obtaining an exclusive lock before updating it, although observable behavior will not differ much if the transactions are short, the working set fits into memory etc.
But the sad truth is that you cannot avoid in all cases that writers block writers. Two transactions might update the same values. Or there are secondary indexes that need updating. Or you have page-level locking (like the B-trees in Berkeley DB) and the keys all happen to be on the same page. You even have to write your application code such that it retries transactions in case of deadlocks (IIRC, this is necessary with Berkeley DB even in the case of one writer and multiple readers). And concurrent, interleaved execution is particularly interesting if the transactions execute for some time, but this makes it all the more likely that anything triggers a conflict. Berkeley DB does not offer row-level locking for B-trees, and the transaction size is limited by the lock space by page-level locks, so it is particularly prone to aborting transactions once they grow larger. And yet Berkeley DB's transactional data store is tremendously complex and difficult to package in a friendly way for end users, with automated recovery and upgrades across major Berkeley DB versions.
This is why I think the Berkeley DB approach is a poor trade-off.
Totally agreed. In practice, concurrent writers in BDB were always deadlocking and needing to abort/retry.
IMO a lot of DBUS service stuff or similar cruft could be avoided by using concurrent writing of different processes to a single embedded DB.
IPC has the advantage that it isolates the database from application crashes.
If you have a robust DB design, application crashes won't have any impact on other users of the DB.
Florian Weimer wrote:
- Ulrich Windl:
When reading, you just say that MDB has some features BDB does not have. Does that make BDB obsolete technology? I think it depends on the user's demands.
Berkeley DB supports arbitrary key sizes. For some use cases, this is quite handy, but it's apparently not relevant to OpenLDAP.
True, not relevant. BDB supports keys of up to 2^32 bytes, as well as values up to 2^32 bytes. It costs quite a great deal of complexity to support such large keys, and there are very few cases that will ever use keys of such size.
For any DB library to perform well, keys must be small enough to fit entirely in RAM and be compared quickly. Keys only need to be large enough to uniquely distinguish one value from another. For any data set that can be calculated by today's technology, this means keys need no more than 64 unique bits. Very large keys implies a bad data model design.
Multiple concurrent writers are nice on paper, but probably are not worth the complexity for an in-process database.
On the other hand, there's not much complexity to support this, and it saves the hassle of users complaining that their DBs corrupted when they accidentally opened the same DB from multiple programs at once.
openldap-technical@openldap.org
-
Florian Weimer -
Friedrich Locke -
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount -
Ulrich Windl