incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <...@holsman.net>
Subject Re: Alternative wire protocols
Date Wed, 24 Jun 2009 22:35:55 GMT

not everything is about speed. it really isn't.

It's about cost (or if your google, power usage). and ease of use as  
well.

claiming a interface is 10% faster is not going to help if it takes  
100 times longer to develop with, or you can't wake someone up at 2am  
to quickly fix some data that is crashing your middleware.
Also if the rest of your infrastructure is using some other protocol  
it makes more sense to use it than a custom one in this part of your  
architecture.

no one is saying to ditch thrift. It's about supporting extra ones.  
and like I said in my previous email.
If someone is prepared to write it and support it themselves, then it  
shouldn't bother anyone.



On 25/06/2009, at 8:23 AM, Michael Greene wrote:

> The author of those blog posts has cheated by using the C versions of
> JSON serializers while using the naive Python implementation of the
> Thrift serializer.  If he used the 'accelerated' version, Thrift would
> be much faster.
>
> See http://jnb.ociweb.com/jnb/jnbJun2009.html#compare for a more
> accurate, though perhaps no less biased, comparison.
>
> Besides the general 'Thrift is a pain' clamor, what improvements are
> needed from Thrift for Cassandra?
>
> It seems like at the moment it's
> * TFramedTransport in more languages
> * TCompactProtocol in more languages
> * Better documentation
> * Released / packaged binaries
>
> With regards to the first two, that just takes time and would need to
> be rectified for any replacement as well.  The third one is something
> that Cassandra could help with even, through usage examples.  The
> fourth one is something that the Thrift project is voting on at the
> moment and will happen really soon now...
>
> That said, I would be casually interested in HTTP+JSON and Thrift both
> being supported.  Everyone understands HTTP+JSON these days.
>
> Michael
>
> On Wed, Jun 24, 2009 at 5:17 PM, Alexander
> Staubo<madevilgenius@gmail.com> wrote:
>> On Wed, Jun 24, 2009 at 11:03 PM, Jonathan Ellis<jbellis@gmail.com>  
>> wrote:
>>> I'm not really interested in stuff that's going to be Much Slower  
>>> like
>>> anything over http (Jay from Voldemort said that's basically a waste
>>> of time and I believe him)
>>
>> Not sure I believe that. There's nothing *inherently* slow about HTTP
>> as a protocol, despite its stateless nature. The current Thrift
>> implementation is not known to be a speed demon, though; neither is
>> Protocol Buffers, for all its binary compactness.
>>
>> Personally I prefer JSON + HTTP. Anything that lets me debug an API
>> using Curl makes me a lot more excited than a bloated library that  
>> has
>> to be bundled with every client and application. (Why doesn't Thrift
>> generate complete, dependency-free stubs? It seems like such a missed
>> opportunity.)
>>
>> Could be worth investigating whether some moderately fast HTTP layer
>> such as Jetty could beat Thrift. This blog post claims (and backs up
>> with some hard numbers) that JSON can beat both in performance as  
>> well
>> as bandwidth:
>>
>>  http://www.bouncybouncy.net/ramblings/posts/json_vs_thrift_and_protocol_buffers_round_2/
>>
>> It should also be noted that Cassandra's API is particularly suited  
>> to
>> the simplicity of a pure HTTP API.
>>
>>> anything that requires hand-writing clients for each language
>>
>> Doesn't that depend on the complexity of the protocol? The hugely
>> popular Memcached server uses a *very* simple line-based protocol  
>> [2],
>> and while you would still want a client library for most apps,  
>> writing
>> one is usually so trivial you could do it from scratch as part of  
>> your
>> app and it still wouldn't feel like a complete waste of time.
>>
>> A.
>>

--
Ian Holsman
Ian@Holsman.net




Mime
View raw message