Cassandra: Fact vs fiction | Hacker News Reader

Cassandra: Fact vs fiction

spyced.blogspot.com

57 pointsropiku23 comments

Open articleView on HN

Based on our usage, I think Thrift is the Achilles' heel for Cassandra. Some of Trift problems that we've seen:

* simple port scan can crash Thrift.

* Malform data can crash Thrift.

* inserting data too fast can crash Thrift.

Any of the 3 above cause NoServersAvailable error.

That said, do you guys have road-map for replacing Thrift? Apache Avro perhaps? Are there anyone actually happy with Thrift (besides Facebook)?

This is in the Summer Of Code roadmap:

http://spyced.blogspot.com/2010/03/cassandra-in-google-summe...

Avro it is: https://issues.apache.org/jira/browse/CASSANDRA-926

Yeah I like this guy's tech-stuff-plus-marketing style, still it would be more honest to at least mention points where Cassandra has its rough edges (and it has quite amount of them)

This isn't "intro to cassandra 101," this is just fud busting.

Maybe off-topic but does anyone know of a Cassandra hosting service? I'd love to try out Cassandra and hopefully put it to production use but I'd rather not deal with managing the servers.

I don't know about putting into production, but it took me a couple minutes to get a 4-node cluster as virtual servers under Debian and OpenVZ. It's very, very easy.

Seems pretty biased. What about the flip side of this article?

Clever marketing: include the objections which are false, ignore those are true.

what objections are true?

(i've not seen them raised anywhere?)

I meant this comment in a positive way: I genuinely think this is smart marketing.

I think the real objections would be things like (and I'm not necessarily saying these are true/false, just that they're the ones that people should really be thinking about):

* Are NoSQL databases the object databases of the modern era?

* Is our pain big enough that we're willing to be a guinea pig for any new technology?

* How will making this technology choice impact our future ability to hire and to work with future technologies?

* Is this the right time to adopt a new database, or will the world be so different in 3 months that we should limp along until then?

From my viewpoint (@ FathomDB), that last point is the most interesting. We're seeing the start of NoSQL convergence; I expect both rapid development and serious teething issues. We see FathomDB & VoltDB announcing early availability of scalable relational databases. Rackspace hired the core of the Drizzle team, so this project will likely start to bear more fruit. To borrow from the wife-selection problem, it feels like immediately getting married to the first attractive person you meet on your first day at college, when there's a freshman mixer that evening.

None of these can be definitively affirmed or rejected by facts.

They're interesting questions but they're either unanswerable (time, oodb) or entirely application dependent (pain, hiring).

Perhaps not, but this doesn't make them unimportant, and again this is why it's clever marketing. Frame the discussion in terms of things that you do well, even if they're not the most important considerations (e.g. "one keyspace per install").

It's a good sales technique: "Do you like holidays?" "Yes" "Well, now that I know you can say yes, do you want to buy this product?"

Nor are they "objections".

They're certainly fairly big reasons not to use Cassandra, and as such I'd put them in the objections bucket. If you're objecting to the fact that I phrased them as questions, just pretend we're on Jeopardy :-)

No they're not, a "big reason not to use Cassandra" would be "it has critical bug X" or "it's missing critical feature Y".

I agree that evaluating whether to switch to a solution now, or wait for something even better, is always a question you should ask.

But the term "vaporware" exists for a reason. Waiting for something that may or may not be everything it's promised is risky too. The Maglev ruby VM is a good example; they were demo-ing close to 10x performance a couple years ago, but when they finished implementing the fully ruby spec it was something like... 20% faster.

A lot can change when you go from demo-ware to a real production ready product. Neither Fathom nor Volt is going to be at Cassandra levels of stability in 3 months. More like a year... if things go well.

It's you that pointed out that we're on the cusp on NoSQL convergence. I'm sure the end result of that will be better than NoSQL today, but any project merge or convergence of this kind is going to be pretty painful for those using the product along the way.

In the meantime, there's at least 3 promising projects that have announced (FathomDB, VoltDB, Drizzle), and I know of a few more as well that aren't public. My decision would be to wait, others may decide to place their bets now.

I meant it as a sincere complement - it's good marketing to draw attention to your strengths.

"any project merge or convergence of this kind is going to be pretty painful for those using the product along the way"

Only if you're using one of the non-viable products. So don't do that. :)

"there's at least 3 promising projects that have announced (FathomDB, VoltDB, Drizzle)"

Drizzle's idea of scale-out is writing a Cassandra backend, fwiw. http://drizzle.org/wiki/CassandraEngine

But last year, CouchDB was the future. Today it's Cassandra. In a few months, it could well be MongoDB or Redis. Even if Cassandra ends up the NoSQL winner, I'm pointing out that you'll have your hands full dealing with 'must have' feature contributions from the 'losing' NoSQL store users, and that this will be painful for existing Cassandra users.

As for the Drizzle thing, you've crossed the line into misleading marketing there. There is a plugin to integrate Cassandra as a Drizzle engine, just like there's a plug-in that logs MySQL error messages to Twitter. That doesn't make it the official strategy, nor does it automatically make it a good idea.

(Edit: fixed my MongoDB/CouchDB confusion!)

"But last year, CouchDB was the future. Today it's Cassandra. In a few months, it could well be MongoDB or Redis."

There's a reason you didn't see Twitter switching to CouchDB last year, and the reason is Cassandra is the only one of those four that does scale-out. So... no, "one of these things is not like the others."

"That doesn't make it the official strategy"

It makes it their only strategy at all to make it past the vapor stage. I'm not a Drizzle expert, but I do work with the core Drizzle team.

Reminder to downvoters: downvoting on HN is not intended to be used to express disagreement.

Those aren't criticisms, at least not in a technical sense, they're broad philosophical concerns that apply just about equally to any technology you want to adopt, ever.

Reply on news.ycombinator.com