incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Evans <>
Subject Re: Which client API to choose?
Date Wed, 24 Mar 2010 15:38:40 GMT
On Wed, 2010-03-24 at 14:15 +0100, Roland Hänel wrote:
> Still, I'm somewhat confused which API to choose if I was heading for
> a
> bigger project
> 1. plain Thrift (for Java)?
> Seems the major advantage is that Thrift is available in many
> languages, but
> if I'm only interested in Java that doesn't give me much. The Java
> code on
> the native Thrift interface looks quite awful. It also seems to me as
> if it
> would result in many lines of code even for quite trivial jobs.

Right, using raw Thrift means that you're interacting with the system by
calling the RPC methods directly. You've got maximum flexibility but
you're quickly going to notice a lot of boiler plate accumulating.

> 2. a higher level Java Client?
> I didn't look at Hector right now, however it confused me somewhat
> that if
> something like Hector was the "best choice", why isn't this then
> bundled
> with Cassandra?

The "best choice" is always going to be subjective, but Hector has
developed a lot of momentum in a short period of time. It would not be
at all unreasonable to call it the de facto Java library for Cassandra.

As for why it's not bundled, that is a feature and not a bug. As
separate projects the two can move at their own pace, use the work-flow
of their own choosing, pick the tools right for them, and add committers
without the unwanted additional oversight.

IMO, bundling Hector wouldn't enhance it's development, (if anything, it
would inhibit it), and by sending the message that it was the One True
Library it would unnecessarily close the door on competition.

> 3. the "native Java fat Client"
> I started some experiments with it, however couldn't get it completely
> working, documentation in the Wiki is not really usuable at all.
> Question
> would be if this is something that you (the developers) consider as
> the "big
> thing for the future" or is this some niche for lets say high
> performance
> bulk jobs but not for the "everyday Java client program"? 

The fat client is different from Thrift in that it obtains a sort of
limited membership in the cluster and is able to route requests directly
to nodes, as opposed to the proxying that can occur when you make a
Thrift call to a random node.

The fat client is not as well tested, and it's true that we usually
steer people toward Thrift unless they have specific requirements. If
you're having problems though, we'd love to hear about them, either
here, or in a bug report

Eric Evans

View raw message