On Thu, 2010-11-04 at 09:30 -0700, Dave Viner wrote: > 1. How does replacing thrift/avro with a SQL-inspired query language make > the server more stable? As a client, I still need to connect via something, > and that something will make something like an RPC call to the server. In > traditional rdbms-es, this is wrapped into the connection library itself > (e.g., odbc, perl dbi, etc). But, just by having a query language, I don't > think that makes the interface more "stable". It certainly might make the > internal code structure more stable inside Cassandra - since the "core" > would implement the query language parser & execution engine. Then you can > abstract the "connection listener" into a separate piece of code entirely. > But, that seems like the goal/idea behind Thrift & Avro. (Note that I am > neither a thrift nor avro expert - so this comment is more from a basic > concept understanding of how those libs work.)
Simply introducing a query language doesn't, but decomposing the query server-side as opposed to forcing the client to piece together structures and records with typed attributes allows us to shield the client from a whole class of changes. And, a query language like this isn't the *only* way to accomplish that of course, it's just the way that seemed most appealing to me overall. [ ... ] > 3. Both Avro and Thrift have graduated to top-level apache projects. Thrift > did so in just the past month or two. I'm not sure exactly when Avro did, > but it's a top-level project now for sure. Although this provides no > absolute guarantees, both are more likely to have longer-lived support than > previous non-TLP since the apache foundation is meant to stand behind such > projects. As a practical matter, this might be little consolation for > previous difficulties of working with those projects/libraries, but it > should provide some comfort for the future. I don't see how this has any effect one way or another, but I might be missing something > I don't think I have a strong opinion one way or the other. But, I do think > that RPC interfaces are hard, but query language interfaces aren't much > simpler. Just look at SQL. It took years for that to coalesce around > common idioms and still there are incompatibilities across platforms. > That's not to say SQL was a bad idea or isn't useful. Just that it's not > clear that creating a new QL isn't a recipe for solving all > connection/interface challenges. I take your point, and I don't see it as a silver bullet, but this is going to be *much* less complex than SQL. -- Eric Evans eev...@rackspace.com
