Re: [boost] [btree] Status report

Subject: Re: [boost] [btree] Status report
From: Rutger ter Borg (rutger_at_[hidden])
Date: 2011-05-20 04:46:09

On 2011-05-19 20:07, Beman Dawes wrote:
>
> Yes, agreed. But the assumption is that it is very, very, fast
> compared to an implementation that must translate between different
> external and internal representations.

I always assumed that file-access is orders of magnitude slower than 
DMA. Especially when the file isn't local. Another case might be 
convincing here: Keys that don't require translation, Mapped that 
requires it.

>> 2) using a "path" argument to having a file open presumes a real underlying
>> file. Although this is fine, maybe I would like to use an fstream?
>
> What would a real-world use case be?

See below.

>> 3) It would be nice if it would work with an asynchronous file-like
>> services, like, e.g., Asio's RandomAccessHandleService, see
>> http://www.boost.org/doc/libs/1_46_0/doc/html/boost_asio/reference/RandomAccessHandleService.html
>
> I'd need stronger motivation that "it would be nice"! What would the benefit be?

There's an increased availability of network-based storage mechanisms, 
like, e.g., Amazon's S3. The combination of (such a) storage backend 
with a B-tree container delivers a NoSQL-stack, which I think is a 
considerable benefit.

To name a concrete example, using a distributed object store like Ceph's 
underlying RADOS, see http://ceph.newdream.net/wiki/Librados , as a 
storage-backend. Operations at this level don't require  "expensive" 
file-system semantics.

Cheers,

Rutger