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. What is your motivation for BTree backed storage? Perhaps we could try to see if it can be provided in the exitsting model itself. Cheers Avinash On Sun, Mar 28, 2010 at 4:48 PM, Jonathan Ellis <jbel...@gmail.com> wrote: > It sounds like an interesting project but I don't think it would be a > good fit for GSoc because it's just too different to be a good > candidate to actually incorporate into Cassandra mainline. (The > consistency and availability models are completely different, assuming > your system ends up looking something like the one in the Aguilera > paper.) > > On Sun, Mar 28, 2010 at 4:11 PM, Primal Wijesekera > <primalwijesek...@yahoo.com> wrote: > > Hi All, > > > > I am a master student in UBC CS dept. I along with one of my lab mates > are trying to implement the Cassandra on top of a B-Tree implementation > rather than of DHT approach that we have right now. We hope to do > benchmarking the two approaches and really want to see which one scales > better. > > > > In the lab we already have a project (which is not yet completed) on > developing a Distributed B-Tree on top of a Sinfonia like system. We would > be trying to integrate the Cassandra source with the B-tree preserving the > rest of the Cassandra logic. > > > > Since we are still in its very early stage of this experiment, thought of > getting your expert thoughts and comments on this and we were wondering > whether this could be a potential GSoc project as well. > > Regards, > > Primal > > > > > > >
