Hacker News Reader

Comment by skybrian | Hacker News Reader

Seems like the root could be sharded if it's an issue?

Not really. But you could imagine hacks like forcing updates instead of logging to the first N-levels (N = 1 or 2) of the B-tree. I don't know how well that would work in practice.

I do know that B-tree block contention is a big problem for my $DAYJOB's use case for smaller B-trees.

Block contention? You mean contention on the locks for individual nodes?

Yes. You can grab the ancestors shared and the leaf or subtree you want to modify exclusive. If all of your writers land in the root of the tree because it's a small tree, they all contend on the same lock.

I'm no expert, but it seems like you need to guess at some key ranges and start the BTree at some minimum size even if most of the leaves start out empty. Either that, or don't write anything until the tree grows a bit and rely on a writeahead log for durability.

Hotspots could still show up further down, though, if writes aren't fairly random.

So it's only an issue with small trees? I'm not really seeing the issue then, use smaller btree nodes if it's really an issue...

The issue seems yo be that writes in Fractal trees always go through the root node. This would lead to a situation similar to small B-Trees where writes will most likely access the root node and contend.

How would you do that? You have to be able to do lookups on the root. You have to have something to shard /on/.

B+ trees shard the updates by splitting the keyspace up into different leaf nodes.

Reply on news.ycombinator.com