On Wed, 2011-03-30 at 02:11 +0200, Gregori Schmidt wrote: > - The API is horrible and it produces pointlessly verbose code in > addition to being utterly confusing. EVERYTHING takes a lot of > time to implement with Cassandra, and to be frank, it is incredibly > tiring. For this reason alone I no longer recommend Cassandra. If > you want an example, pick up the O'Reilly book on Cassandra and look > through the examples. Such MASSIVE amounts of code for doing nearly > NOTHING. This is ridiculous. Didn't this strike anyone else as > ridiculous? It should have!
Yes, it did, which is why for 0.8 we have CQL (https://svn.apache.org/viewvc/cassandra/trunk/doc/cql/CQL.html?view=co). > - You need to have official client libraries and they need to be > programmer friendly. Yes, I know there are nice people maintaining > a plethora of different libraries, but you need to man up and face > reality: the chaos that is the Cassandra client space is a horrible > mess. The client space as a whole *is* a mess, despite heroic efforts on the part of our third-party API maintainers, but forcing them in-tree is not going to solve anything. In fact, it would very likely make it worse by adding unnecessary overhead to contribution, and discouraging innovation. The root cause goes back to your first point, the RPC interface is baroque, and too tightly coupled to Cassandra's internals. The third-party library maintainers can only do so much to paper over that; The Fail shines through. The solution here is the same as for point #1 above, CQL. And, the idea is to include in-tree "drivers", basically, the minimum amount of common code that all third-party libs would need to implement (think connection pooling, parameter substitution, etc). We already have drivers for Java, Python, and Twisted, and folks are working PHP and Perl (that I'm aware of). > - It is buggy and the solution seems to be to just go to the next > release. And the next. And the next. Which would be okay if you > could upgrade all the time, but what to do once you hit production? 0.7 has been a rough ride, no doubt. We spent too much time pushing in too many features, and didn't do a good job of drawing a line in the sand when it came time to release. Our track record prior to 0.7 was Not Horrible, and trending toward Better And Better, and we've made some adjustment to the release process, so I'm hopeful we'll get back on track. Also, new for 0.8 is backward compatible messaging, which will allow you to smoothly perform rolling (non-disruptive) upgrades. That, combined with a stable query interface (CQL), will really reduce the barrier to upgrades. > I would recommend that everyone interested in improving Cassandra take > the day off, download MongoDB and read > https://github.com/karlseguin/the-little-mongodb-book . Then, while > you are downloading, unpacking, looking at what was in the JAR, > reading the book and pawing through the examples: _pay attention_ to > the neatness and the effortlessness the ease with which you can use > MongoDB. Then spend the rest of the day implementing something on top > of it to gain some hacking experience. > > No, really. Do it. This is important. You need to connect with the > user and you need to understand what you ought to be aspiring to. > > In any case, thanks for all the effort that went into Cassandra. I > will check back from time to time and perhaps in a year or so it'll be > time to re-evaluate Cassandra. In a year we'll have achieved Total World Domination. :) > PS: one last thing. It took us less time to rewrite the DB-interface > for our system to MongoDB AND port over our data than it took to write > the Cassandra implementation. -- Eric Evans eev...@rackspace.com
