incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stu Hood" <>
Subject Re: NoSQL, YesCQL?
Date Fri, 29 Oct 2010 15:07:43 GMT
Let me preface this by saying: the fact that it looks like SQL doesn't bother me. But: I think
this would be a terrible thing to _focus_ on. Something for contrib? Sure.

Most reasonable languages these days have a way to define what looks like a DSL: giving people
a text DSL which is subject to injection attacks and can't be type checked without support
from a client driver anyway is brain dead. There is a reason that 99% of clients that interact
with a SQL server do so programmatically via a library: because that is an easier way to interact
than via string concatenation. At least that way the library is performing the concatenation
for you.

Regarding performance: assuming optimized RPC libraries (which we do not yet have in Avro,
and which Thrift is getting better at), serializing to a string and back will never be as
performant as using a pre-parsed representation of the statement on both sides. "Oh but we
can add prepared statements!" Poppycock.


> Truth is we've seen quite a bit of proliferation, and very little critical mass.
> forced to move in lock-step with Cassandra releases, that are never backward compatible
Expecting stable libraries or API pre-1.0 is not reasonable: neither the devs nor the users
expect stability, and yet we are still able to guarantee compatibility within major versions.

The stated problem is that backwards compatibility is hard to provide: if that is the core
complaint, then changing to a text based serialization format with a sexy name in order to
add backwards compatibility is a severe overreaction to the problem. Instead, I would propose
evolving the API in a manner that simplifies it.


-----Original Message-----
From: "Eric Evans" <>
Sent: Thursday, October 28, 2010 4:56pm
Subject: Re: NoSQL, YesCQL?

On Thu, 2010-10-28 at 14:46 -0700, Chip Salzenberg wrote:
> Short answer: "YES Please, but we will still want a side channel for
> minimum overhead."

Ok.  Though I'm not sure I agree with the "minimum overhead" argument.

I've only done preliminary tests so far, but this seems on par (if not a
little faster) than Thrift is, and no effort to optimize has been made
(using a socket transport instead of HTTP for example would make a big

> Long answer: Query languages only work reliably when you have data
> binding assistance (insert "Bobby Tables" xkcd here).  However, they
> do
> have the wonderful property of evolving aggressively without requiring
> upgrades of the driver plumbing.  This is, of course, emphatically
> *not*
> true of anything like the current Thrift and Avro interfaces.  So
> that's
> why I say "Yes."  On the other hand, a very simple interface for very
> simple queries has a lot of value, too; see, for example,
> So that's why I think we will still want to bypass the full language
> for minimum latency in some circumstances. 

I'm also not sure I follow here either.  Do you mean simple for the
application developer?  CQL-using code should be considerably simpler
than the equivalent Thrift/Avro.

Thanks for the feedback!

Eric Evans

View raw message