Re: [boost] [btree] Status report

Subject: Re: [boost] [btree] Status report
From: Beman Dawes (bdawes_at_[hidden])
Date: 2011-05-20 09:25:44

On Fri, May 20, 2011 at 4:46 AM, Rutger ter Borg <rutger_at_[hidden]> wrote:
>
> 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.

Yes, of course. And such a stack might want to provide async
operational functions. But they would be provided by a level above the
basic B-tree package.

Chris Kohlhoff and I discussed this yesterday. Neither of us can see
any way for Boost B-tree to benefit from async approaches.

A UB-tree (i.e. a B-tree that does multi-dimentional searches) might
well benefit. But that isn't what is on the table at the moment.
>
> 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.

I'll take a look.

--Beman