vanrein
commented
5 years ago What we use of BerkeleyDB is:
- rock-solid reliability and recovery
- efficiency in looking up data
- uses: cert with p11 ref ; trust ; privacy disclosure settings
- binary keys, binary values
- multiple mappings (same key, more than one outcome)
- references from one table to another (simply two lookups)
- transactionality
- many threads reading the database at the same time
- occassional updates from the side-line, by the operator
- perhaps one day: replication with majority voting
The current knowledge about the database choice is hard-coded as it was not considered a variable in the beginning. The closer the databases are, the easier it will be to make a simple abstraction. Maybe such an abstraction actually exists in C, haven't looked yet. It'd have to be very simple and light-weight to be attractive.
We use BerkeleyDB as our database. Some might argue that LMDB is a faster choice. Note that this is not the ancient LDBM backend!
This mostly depends on the read/write balance. LMDB is heavily geared towards systems that are mostly being read (such as most LDAP usage scenarios). This idea may or may not be kind on the TLS Pool patterns. LMDB appears to have a very impressive design, and does not appear to be a step down in quality from BerkeleyDB. The lack of synchronisation with majority voting may not be a problem in rarely written scenarios.
BerkeleyDB has recovery functions, but they are not necessarily heavenly. LMDB uses copy-on-write semantics, meaning that data is not overwritten and so it cannot be invalidated by crashes halfway a distributed write. This smells just like many really reliable pieces of software.
LMDB is also interesting to consider from the perspective of MIT licensing and non-giant-ownership. And it is used widely in the field as a key2value database.