incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Poole <>
Subject Re: Cassandra on top of B-Tree
Date Mon, 29 Mar 2010 11:52:16 GMT
Avinash Lakshman writes:

> Here is why I think it is not a good fit for Cassandra (at least top 3
> reasons that come to mind):
> (1) Cassandra strives to make updates very very cheap. With BTree's every
> update is a read modify write.
> (2) BTree on rebalance tend to result in a lot of fragmentation leading to
> poorer performance over time.
> (3) Every write (update) is a random write while in Cassandra as it is today
> it will be a sequential one because of a log structured nature.

SSTables aren't written on every update.  Why would a B-Tree
implementation differ?  It seems like this could reduce the number of
seeks needed during reads (by having fewer B-Tree files than SSTables,
and possibly having a flatter index in each of those).

The compaction phase is used to reduce fragmentation already, right?

Michael Poole

View raw message