incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Evans <eev...@rackspace.com>
Subject Re: Ditching Cassandra
Date Wed, 30 Mar 2011 01:15:18 GMT
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
eevans@rackspace.com


Mime
View raw message