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: Dominique Devienne (ddevienne_at_[hidden])
Date: 2017-03-27 14:05:12

On Mon, Mar 27, 2017 at 3:42 PM, Niall Douglas via Boost <
boost_at_[hidden]> wrote:

> >> The issue I am taking here is the claim of durability
> >
> > This is the first I'm hearing that the "Durability" in ACID implies
> > protection from data corruption after the fact - please provide a
> > source.
>
> It doesn't imply that.
>
> Durability means that corruption to the database will not cause further
> data loss during subsequent use. For example, if you use a single bit to
> indicate that a record is deleted, and corruption flips that bit to
> deleted, and your implementation has no way of noticing the corruption,
> you have lost data after the corruption. Ideally when a user next
> accesses that record, they should see an error like "Record corrupt".
>
> There is a fun history of corruption and SQLite at
> https://www.sqlite.org/howtocorrupt.html. Last time I looked, there was
> a popular fork of SQLite which implements per-row checksumming, but the
> default build does not (the canonical advice is: "use a proper filing
> system like ZFS if you don't want bit errors"). But SQLite is very
> carefully written to check consistency during modifications, and where
> it can it will refuse to modify data when the metadata doesn't match up.
>
> So, a database can be durable and not detect arbitrary damage to user
> data. It just cannot lose further user data due to corruption of its own
> structures.
>

Given that SQLite doesn't do any checksum'ing of its data (i.e. its pages),
I don't see how it could be durable in the way you seem to imply Niall. --DD