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<[email protected]> wrote:
On Wed, Jun 24, 2009 at 11:03 PM, Jonathan Ellis<[email protected]>
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
[email protected]
