incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tatu Saloranta <tsalora...@gmail.com>
Subject Re: Which client API to choose?
Date Wed, 24 Mar 2010 15:57:14 GMT
On Wed, Mar 24, 2010 at 8:45 AM, Ran Tavory <rantav@gmail.com> wrote:
> I concur with Eric, as hector developer it's easier to develop separately
> (github) plus competition keeps us healthy ;)

Enthusiastic +1 for this :)
(both for proper layering to allow different levels of abstraction,
and for goodness of some competition to keep everyone honest &
hard-working)

-+ Tatu +-

>
> On Wed, Mar 24, 2010 at 5:38 PM, Eric Evans <eevans@rackspace.com> wrote:
>>
>> 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
>> (https://issues.apache.org/jira/browse/CASSANDRA).
>>
>>
>> --
>> Eric Evans
>> eevans@rackspace.com
>>
>
>

Mime
View raw message