Re: how to build a database from scratch

From: paul c <toledobythesea_at_oohay.ac>
Date: Thu, 07 Dec 2006 02:13:32 GMT
Message-ID: <gNKdh.436466$5R2.408980@pd7urf3no>

Sampo Syreeni wrote:
> On 2006-12-06, paul c wrote:
>

>> [...] rather he will choose to add a storage/lock et cetera component 
>> and force the btree code to operate under that component's 
>> constraints, eg., not allow it to be aware of disks, et cetera. the 
>> problems you mention go away [...]

>
>
> I don't think this is the case. Things like parallelism and recovery are
> orthogonal in the conceptual sense, but from the point of view of
> algorithms, data structures and system architecture they are heavily
> cross-cutting and interact with each other. Naïve B-trees plus
> indirection is just one example of a strategy that hasn't worked out in
> practice. Here the reason is mostly the need for fine grained write
> parallelism in OLTP environments. The tree will easily become a
> bottleneck because the interdependencies and interactions caused by page
> splits force you to lock too aggressively. When you hit that wall, you
> cannot circumvent it by adding levels of indirection because the problem
> is in the tree maintenance code, and layering will not remove that from
> the code paths that are being blocked.
> ...

Nonsense. A strict internal separation, eg., protocol will allow multiple NAIVE btree tasks to co-exist. All the rest is depends on the speed of hardware.

p Received on Wed Dec 06 2006 - 20:13:32 CST