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
