On 10/28/2010 2:56 PM, Eric Evans wrote: > 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 > difference).
I didn't mean to imply that Thrift is fast enough. (Hehe, that would be funny.) Rather, I meant to suggest that any parsed language will inevitably be slower than a direct API for simple queries, so we should also provide such a simple API. If the question is, can the language completely and effectively replace Thrift for Cassandra, the answer is Yes. AFAICT, anyway. >> 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, >> http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for.html >> >> 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. I'm not concerned about application-coding complexity problems with a language, only about performance in the lowest of low-latency use cases. > Thanks for the feedback! >
