Re: [boost] NuDB: A fast key/value insert-only database for SSD drives in C++11

Subject: Re: [boost] NuDB: A fast key/value insert-only database for SSD drives in C++11
From: Peter Dimov (lists_at_[hidden])
Date: 2017-03-29 15:06:26

Niall Douglas wrote:
> > No such thing.
>
> It sure is. For example,
> https://sqlperformance.com/2014/04/io-subsystem/delayed-durability-in-sql-server-2014.

"Delayed durability" is not what traditionally the letter D in ACID means. 
It means that if the insert call has returned, the insert is in the 
database, period. It makes no provisions for up to 5 minutes of inserts 
being lost. This is simply not durable by the standard definition.

> Consistency refers to the referential integrity of the database.
...
> So if transaction A updates references which are used by transaction B, 
> and if after power loss transaction A was damaged and transaction B was 
> not, if you are Consistent then you also need to throw away transaction B 
> during recovery. But if transaction B did not use any inputs from 
> modifications by transaction A, then if you are Durable you MUST recover 
> transaction B even though it occurred after the damaged transaction A 
> which is thrown away.

One definition of the letter C in ACID is that if you have issued 
transaction B after transaction A, the database is in one of three possible 
states: (none of A and B present), (A present), (both A and B present). It 
doesn't matter what references A or B update. You're absolutely not allowed 
to apply B without A on recovery.

It's true that this meaning of consistency is not universally accepted. If 
you interpret C loosely, you have no letter with which to describe the 
above, which would now fall somewhere between C and D. So it probably makes 
sense to call it "delayed durability" if you consider "consistency" not 
that.

As far as I can see, NuDB claims this exact property, subject to

"NuDB's database integrity guarantees are only valid if the implementation 
of sync assures that all data is fully written to the underlying file before 
the call returns."

"NuDB's database integrity guarantees are only valid if the implementation 
of trunc assures that subsequent calls to size will return o, even if the 
program is terminated or the device is taken offline before calling size."

so I'm not quite sure what your objections are. You insist on him not 
calling NuDB durable, which he never did.