You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Roland Hänel <ro...@haenel.me> on 2010/03/24 14:15:17 UTC
Which client API to choose?
Hi,
First of all, thanks all of you guys who are contributing to this amazing
project. I've been looking at Cassandra for a couple of days now, and I'm
still impressed by the whole thing.
However, it wasn't all that straight-forward getting my first "hello world"
programs to run with Cassandra. As a newbie I was (probably as many of those
who do their first steps with Cassandra) in doubt with API to choose, and
the Wiki and examples provided little help here. I have to add that I'm
playing with 0.6.0beta3, maybe that's the reason the Java Thrift API doesn't
work like in the Wiki examples (but I was able to adapt to make it working).
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.
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?
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"?
Maybe someone could give me a hint in which direction things should move.
Best regards,
Roland
Re: Which client API to choose?
Posted by Ned Wolpert <ne...@imemories.com>.
I recommend Hector myself. I've been using it inside a groovy plugin and it
works well. Also, it abstracts out the connection to Cassandra, gives you
the ability to pool resources, etc.
Think of thrift as JDBC, and Hector as PoolMan. (if anyone remembers that
wonderful project) You're still basically using thrift, just giving you some
nice wrappers and features not there normally.
Not sure the 'fat client' is the way to go... from what I read, doesn't
sound like it.
2010/3/24 Roland Hänel <ro...@haenel.me>
> Hi,
>
> First of all, thanks all of you guys who are contributing to this amazing
> project. I've been looking at Cassandra for a couple of days now, and I'm
> still impressed by the whole thing.
>
> However, it wasn't all that straight-forward getting my first "hello world"
> programs to run with Cassandra. As a newbie I was (probably as many of those
> who do their first steps with Cassandra) in doubt with API to choose, and
> the Wiki and examples provided little help here. I have to add that I'm
> playing with 0.6.0beta3, maybe that's the reason the Java Thrift API doesn't
> work like in the Wiki examples (but I was able to adapt to make it working).
>
> 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.
>
> 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?
>
> 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"?
>
> Maybe someone could give me a hint in which direction things should move.
>
> Best regards,
> Roland
>
>
--
Virtually, Ned Wolpert
"Settle thy studies, Faustus, and begin..." --Marlowe
Re: Which client API to choose?
Posted by Charlie Mason <ch...@gmail.com>.
On Wed, Mar 24, 2010 at 5:07 PM, Peter Chang <pe...@gmail.com> wrote:
> Hector is the way to go if you're using java. I'm using it right now and
> it's made things worlds easier.
> The reason why it wasn't bundled was because it's a separate and relatively
> new project. I think it's under a month old and it was done by a lone
> developer (Ran). Also, the Cassandra project wants to be able to give you
> options on which clients to use but (so far) hasn't sanctioned any as THE
> option which is fine.. it's just respecting the layers of abstraction.
> There was also another project here announced recently you can find
> at http://github.com/charliem/OCM which is basically object-cassandra
> mapping. I suggest you look into this for a more friendly user experience. I
> haven't used it personally for myself yet but I've personally implemented
> something similar along these lines to abstract my POJOs to Cassandra.
Full disclosure - I am the author of OCM :)
OCM is a more user friendly layer built on top of Hector. It designed
to make some common client use cases a lot simpler. If its a good fit
with what you are looking for then by all means use it. As far as I
know its about the highest level interface currently available for
Java. At its most basic level you use the generated classes like Java
Beans to read and write the objects' fields. Then use the Load and
Save methods to sync it with Cassandra. Its got a few more features
than that but you get the idea.
If you find it too high level then definitely go with Hector. You
loose so little over using the Thrift interface directly I can't
imagine a reason not to use it. Even if something you need is missing
it would be a lot better to add it to Hector than to use Thrift
directly.
Charlie M
Re: Which client API to choose?
Posted by Peter Chang <pe...@gmail.com>.
Hector is the way to go if you're using java. I'm using it right now and
it's made things worlds easier.
The reason why it wasn't bundled was because it's a separate and relatively
new project. I think it's under a month old and it was done by a lone
developer (Ran). Also, the Cassandra project wants to be able to give you
options on which clients to use but (so far) hasn't sanctioned any as THE
option which is fine.. it's just respecting the layers of abstraction.
There was also another project here announced recently you can find at
http://github.com/charliem/OCM which is basically object-cassandra mapping.
I suggest you look into this for a more friendly user experience. I haven't
used it personally for myself yet but I've personally implemented something
similar along these lines to abstract my POJOs to Cassandra.
On Wed, Mar 24, 2010 at 8:57 AM, Tatu Saloranta <ts...@gmail.com>wrote:
> On Wed, Mar 24, 2010 at 8:45 AM, Ran Tavory <ra...@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 <ee...@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
> >>
> >
> >
>
Re: Which client API to choose?
Posted by Tatu Saloranta <ts...@gmail.com>.
On Wed, Mar 24, 2010 at 8:45 AM, Ran Tavory <ra...@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 <ee...@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
>>
>
>
Re: Which client API to choose?
Posted by Ran Tavory <ra...@gmail.com>.
I concur with Eric, as hector developer it's easier to develop separately
(github) plus competition keeps us healthy ;)
On Wed, Mar 24, 2010 at 5:38 PM, Eric Evans <ee...@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
>
>
Re: Which client API to choose?
Posted by Jonathan Ellis <jb...@gmail.com>.
I went ahead and removed the SP example from that wiki page.
On Wed, Mar 24, 2010 at 1:22 PM, Jonathan Ellis <jb...@gmail.com> wrote:
> Should we just remove that from the wiki, seeing as how we have the
> same (?) sample in contrib/ where it is more likely to be kept up to
> date?
>
> 2010/3/24 Roland Hänel <ro...@haenel.me>:
>> Thanks a lot for these suggestions.
>>
>> My fat client issues came mainly from the fact that the Wiki example
>> (http://wiki.apache.org/cassandra/ClientExamples) just doesn't work with
>> 0.6.0beta3.
>>
>> - StorageService.instance()
>> does not work because instance is a static variable, not a method
>>
>> - new ColumnPatch("Standard1", null, ("colb").getBytes())
>> does not work because there is no such constructor signature defined;
>> use
>> new ColumnPath("Standard1").setColumn("colb".getBytes())
>> instead
>>
>> - StorageProxy.insert(change)
>> does not work, because there is no such method (static or dynamic) in
>> this
>> class, I started to look around and came up with something like
>> List<RowMutation> ml = new Stack<RowMutation>();
>> ml.add(change);
>> StorageProxy.mutate(ml);
>> but it doesn't quite work out until now (however, also doesn't throw
>> an exception).
>> Please don't shoot me, I came up with this code just grep'ing the
>> source and doing something that seemed to make a little sense... ;-)
>>
>> Greetings,
>> Roland
>>
>>
>> 2010/3/24 Eric Evans <ee...@rackspace.com>
>>>
>>> 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
>>>
>>
>>
>
Re: Which client API to choose?
Posted by Jonathan Ellis <jb...@gmail.com>.
Should we just remove that from the wiki, seeing as how we have the
same (?) sample in contrib/ where it is more likely to be kept up to
date?
2010/3/24 Roland Hänel <ro...@haenel.me>:
> Thanks a lot for these suggestions.
>
> My fat client issues came mainly from the fact that the Wiki example
> (http://wiki.apache.org/cassandra/ClientExamples) just doesn't work with
> 0.6.0beta3.
>
> - StorageService.instance()
> does not work because instance is a static variable, not a method
>
> - new ColumnPatch("Standard1", null, ("colb").getBytes())
> does not work because there is no such constructor signature defined;
> use
> new ColumnPath("Standard1").setColumn("colb".getBytes())
> instead
>
> - StorageProxy.insert(change)
> does not work, because there is no such method (static or dynamic) in
> this
> class, I started to look around and came up with something like
> List<RowMutation> ml = new Stack<RowMutation>();
> ml.add(change);
> StorageProxy.mutate(ml);
> but it doesn't quite work out until now (however, also doesn't throw
> an exception).
> Please don't shoot me, I came up with this code just grep'ing the
> source and doing something that seemed to make a little sense... ;-)
>
> Greetings,
> Roland
>
>
> 2010/3/24 Eric Evans <ee...@rackspace.com>
>>
>> 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
>>
>
>
Re: Which client API to choose?
Posted by Roland Hänel <ro...@haenel.me>.
Thanks a lot for these suggestions.
My fat client issues came mainly from the fact that the Wiki example (
http://wiki.apache.org/cassandra/ClientExamples) just doesn't work with
0.6.0beta3.
- StorageService.instance()
does not work because instance is a static variable, not a method
- new ColumnPatch("Standard1", null, ("colb").getBytes())
does not work because there is no such constructor signature defined;
use
new ColumnPath("Standard1").setColumn("colb".getBytes())
instead
- StorageProxy.insert(change)
does not work, because there is no such method (static or dynamic) in
this
class, I started to look around and came up with something like
List<RowMutation> ml = new Stack<RowMutation>();
ml.add(change);
StorageProxy.mutate(ml);
but it doesn't quite work out until now (however, also doesn't throw
an exception).
Please don't shoot me, I came up with this code just grep'ing the
source and doing something that seemed to make a little sense... ;-)
Greetings,
Roland
2010/3/24 Eric Evans <ee...@rackspace.com>
> 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
>
>
Re: Which client API to choose?
Posted by Eric Evans <ee...@rackspace.com>.
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