Time to move away from Berkeley DB

[Howard Chu]

Ondřej Surý wrote:
> Bron,
>
> would it be possible to release twoskip as a library with stable API and ABI
> (and proper SONAME), that might help other projects that need reliable K/V
> storage, but don't need a superfast operations.
>
> I agree that sasldb2 propably don't need a support for storing zillions of
> records, so twoskip might be a good choice.

The question isn't whether you need to support zillions of records. The 
question is what is most efficient. LMDB's footprint is tiny and its 
efficiency is unrivalled. If twoskip is smaller codewise (I haven't seen it) 
then it may be a good choice. Otherwise, ignoring LMDB when the work for 
sasldb2 has already been done, to choose a bulkier solution, sounds like 
deliberate bloat to me.

People see the numbers we release and get mislead; perhaps a particular 
application doesn't need the reported raw performance. The issue isn't 
performance, it's efficiency - getting the most useful work done while 
consuming the minimum resources.

You live on a planet with finite resources. You live a finite lifetime. Every 
milliwatt of power you chose not to save has a cost. Every millisecond of time 
you chose not to save, multiplied across millions of users, adds up to 
multiple lifetimes wasted. Efficiency *always* matters.

> Ondrej
>
>
> On Wed, Jul 3, 2013 at 6:29 AM, Bron Gondwana <brong at fastmail.fm
> <mailto:brong at fastmail.fm>> wrote:
>
>     On Tue, Jul 2, 2013, at 11:37 PM, Howard Chu wrote:
>      > Dan White wrote:
>      > > On 07/02/13 09:58 +0200, Ondřej Surý wrote:
>      > >> Hi,
>      > >>
>      > >> you might have noticed that Oracle has released Berkeley DB 6.0, and in
>      > >> unfortunate move they relicensed the BDB to AGPLv3 which makes it
>      > >> incompatible with anything else than AGPLv3 or GPLv3.
>      > >>
>      > >> E.g. this makes cyrus licensing incompatible with Berkeley DB 6.0
>     since it
>      > >> would require dual licensing which I hardly think makes sense.
>      > >>
>      > >> Thus I think it's time to kill the Berkeley DB support in
>     cyrus-imapd-2.5,
>      > >> and start thinking about the replacement for cyrus-sasl sasldb (would
>      > >> skiplist work here? or should we use sqlite3, kyotocabinet or anything
>      > >> else?).
>
>     We could also look at porting twoskip across from cyrus-imapd.  it's not as
>     fast, but it's super-safe.  64 bit.  Checksums.  Fast crash recovery and
>     total data integrity against any possible crash scenario.

We considered adding checksums to LMDB, but I didn't want to sacrifice the 8 
bytes per page that would be consumed. LMDB "crash recovery" is instant, there 
is nothing to recover.

>     Not safe against random disk corruption, but it will tell you about it!

LMDB is not safe against users overwriting its filesystem data, accidentally 
or maliciously. Aside from that it is safe from all hardware crash scenarios.

>     http://opera.brong.fastmail.fm/talks/twoskip/

I'll take a look, but there's already a lot of research that shows that skip 
lists are CPU-cache unfriendly. B+tree efficiency is still the best.

http://web.archive.org/web/20120204233345/http://resnet.uoregon.edu/~gurney_j/jmpc/skiplist.html

Seems the original page at UOregon is gone now.

>      > > With regards to cyrus-sasl, Lightining DB is another option:
>
>     I'm also very interested in Lightning.  The only issue is that it has
>     multiple files per DB by my last reading.

I think you mean the opposite - it can store multiple databases in a single file.

There is a persistent data file and an ephemeral lock file. On a read-only 
filesystem there is no lock file. (E.g., for so-called constant databases, 
CD-ROM distributions, etc.)

>      > > http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2012-March/002479.html
>      > >
>      > > It's released under the OpenLDAP Public License, which I assume is
>      > > compatible since ldapdb is released under the same license.
>      >
>      > Updated patch posted last October.
>      >
>      > http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2012-October/002541.html
>      >
>      > Sorry, I wasn't aware of this mailing list until today.
>      >
>      > SQLite is horrible, has no multi-process support. Even with LMDB underneath
>      > it's far from tolerable. Kyoto Cabinet leaks like a sieve.
>      > http://www.anchor.com.au/blog/2013/05/second-strike-with-lightning/
>
>     Thanks for the link.  I'll have a look :)

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/