On Thu, 28 Oct 2010 14:46:15 -0700 Chip Salzenberg <c...@pobox.com> wrote:
CS> Short answer: "YES Please, but we will still want a side channel for CS> minimum overhead." 100% agreed on both counts. But IIRC the fastest side channel is to become a Cassandra node. Is that an option? CS> Long answer: Query languages only work reliably when you have data CS> binding assistance (insert "Bobby Tables" xkcd here). However, they do CS> have the wonderful property of evolving aggressively without requiring CS> upgrades of the driver plumbing. This is, of course, emphatically *not* CS> true of anything like the current Thrift and Avro interfaces. So that's CS> why I say "Yes." On the other hand, a very simple interface for very CS> simple queries has a lot of value, too; see, for example, CS> http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for.html CS> So that's why I think we will still want to bypass the full language for CS> minimum latency in some circumstances. I think the sane, reasonable, simple path is to make the query language as similar to SQL as possible (which EricQL seems to aim for). Just making the queries pure text would be terrific, in any case. Then a JDBC driver or a Perl DBD driver (and their parallels in Ruby, Python, etc.) would be so much easier to write and Cassandra clients wouldn't have to be so damn complicated. So I'd rather see specialized tools for minimum latency and overhead, especially for inserts and dumps (like MySQL provides mysqlinsert and mysqldump). Ted
