incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Salzenberg <>
Subject Re: NoSQL, YesCQL?
Date Thu, 28 Oct 2010 21:46:15 GMT
Short answer: "YES Please, but we will still want a side channel for
minimum overhead."

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.

On 10/28/2010 1:40 PM, Eric Evans wrote:
> I don't know about everyone else, but I've been pretty dissatisfied with
> our API situation for some time.
> I used to be of the opinion that The Problem was Thrift and The Answer
> was Avro.  I do still prefer Avro over Thrift as dependencies go, but
> I've come to the conclusion that the real problem has more to do with
> the object-oriented RPC pattern that both share in common.
> I used to think this was a necessary burden in order to expose the full
> power of our query API in a client agnostic manner, and that it was the
> job of third-party libraries to wrap this layer to create stable
> idiomatic interfaces.
> And, I used to think a vibrant ecosystem of these idiomatic libraries
> would emerge, but it hasn't.  Truth is we've seen quite a bit of
> proliferation, and very little critical mass. 
> This shouldn't be construed as criticism levied against library
> maintainers, on the contrary, I think they've done an amazing job all
> things considered.  But in my opinion, our RPC interfaces push way too
> many implementation details client-side, making them brittle and
> unstable.  This results in unnecessarily complex libraries that are
> forced to move in lock-step with Cassandra releases, that are never
> backward compatible, and which are consistently broken during our
> development cycle.  I think we can provide client maintainers and users
> with a better experience than this.
> One solution to this is to implement a server-side query language, with
> simple language drivers that manage all of the common functionality in a
> consistent way (statement preparation, connection pooling, etc).
> Library maintainers would then build their idiomatic interfaces on top
> of these, (and I imagine, remove a metric crap-ton of code in the
> process).
> To this end I've been playing with exactly that.  I have enough to do
> simple reads and writes, and I have stubbed out drivers for Java and
> Python.  I'm seeking community feedback to gauge interest, and to
> satisfy the much needed desire to bike-shed. :)
> You need to be sure you're checking out the "CQL" branch.
> This is implemented in the Avro interface so you'll need to pass the -a
> flag when launching the daemon.
> It is far from complete, and is surely quite buggy at this stage, take
> it as a preview or demonstration; it's meant to be a starting point for
> discussion. 
> There is a bit of documentation on the syntax, you can see that here:
> There are some system tests in test/system/ that should give
> you the basic idea, but assuming you have the Avro Python module
> installed you should be able to just...
> $ cd drivers/py
> $ python
>>>> import cql
>>>> conn = cql.Connection('Keyspace1', 'localhost', 9160)
>>>> conn.execute('UPDATE Standard1 WITH ROW("k", COL("c", "hello!"));')
>>>> print conn.execute('SELECT FROM Standard1 WHERE KEY = "k"')
> [{u'columns': [{u'timestamp': 1288297508761L, u'name': 'c', u'value':
> 'hello!', u'ttl': None}], u'key': 'k'}]
> I've been chewing on all of this for a while so I'm brimming with ideas,
> but I'll let the dust settle on this email before going any further. :)
> Thoughts?
> P.S. Dear Cliff Moon, I apologize.  You were right.

View raw message