Re: Datastax java driver
Ok, thanks for clearing that up. On 23 Nov 2012 07:18, "Sylvain Lebresne" wrote: > Currently, I'm not sure you can really reduce those dependencies. But we > do plan on reducing that ultimately. Basically the reason we have anything > thrift related in there is that so far we depends on the full Cassandra > jar. However, we'll pull out the classes uses by the native transport in > their own jar and once that's done those thrift dependencies will be > removed. > > As for netty and guava, they are really used by the driver so they are > here to stay. > > > On Thu, Nov 22, 2012 at 10:23 PM, Jabbar wrote: > >> Hello, >> >> First of all thanks for the driver. It made my day yesterday :) >> I downloaded the source code and built the driver. I have used the driver >> on a virtual two node cassandra (1.2.0-beta2) cluster. My test application >> is written in scala 2.1.0 rc2, spray 1.1 m5 and has the following >> dependencies for the driver >> >> "org.apache.cassandra"% "cassandra-thrift" % "1.2.0-beta2", >> "org.apache.cassandra"% "cassandra-clientutil" % "1.2.0-beta2", >> "org.apache.cassandra"% "apache-cassandra" % "1.2.0-beta2", >> "org.apache.cassandra"% "cassandra-all" % "1.2.0-beta2", >> "io.netty" %"netty"% "3.5.9.Final", >> "com.google.guava"%"guava"% "12.0", >> "org.apache.thrift"%"libthrift"% "0.7.0" >> >> Can I reduce these dependencies? >> >> >> -- >> Thanks >> >> A Jabbar Azam >> >> >
RE: Concurrency and secondary indexes
Aaron, Nodetool reports: 1.1.6-dse-p1 What about inserted data using Hadoop? Will the secondary index execute concurrently or will this also be single threaded (on the same machine I mean)? From: aaron morton [mailto:aa...@thelastpickle.com] Sent: November-22-12 8:04 PM To: user@cassandra.apache.org Subject: Re: Concurrency and secondary indexes What version are you on ? but we are finding a secondary index is performing slow Not sure what you mean here. Are secondary indexes concurrent or single threaded? Rebuilding a secondary index (via node tool) is a single threaded operation, but *all* indexes specified on the command line are built at the same time. Rebuilding any one index requires reading all the rows in the CF. Cheers - Aaron Morton Freelance Cassandra Developer New Zealand @aaronmorton http://www.thelastpickle.com On 23/11/2012, at 8:20 AM, Simon Guindon mailto:simon.guin...@jsitelecom.com>> wrote: We are importing data from one column family into a second column family via "nodetool refresh" but we are finding a secondary index is performing slow and the machine CPU is pretty much idle. We are trying to bulk load data as fast as possible. Are secondary indexes concurrent or single threaded?
Re: Booting up a Datacenter replication
On Fri, Nov 23, 2012 at 11:33 AM, Darvin Denmian wrote: > But right now I need to increased the level of data redundancy ... and > to accomplish that I'll configure 3 > new Cassandra nodes in other Data Center. https://issues.apache.org/jira/browse/CASSANDRA-3483 =Rob -- =Robert Coli AIM>ALK - rc...@palominodb.com YAHOO - rcoli.palominob SKYPE - rcoli_palominodb
Re: Changing placement stratgy?
On Fri, Nov 23, 2012 at 3:33 AM, Thomas Stets wrote: > Is there any advantage in using a different placement strategy, consigering > that each node has all of the data anyway? No. In your case there is no advantage to NetworkTopologyStrategy. It is somewhat odd that you have one logical cluster in two physical datacenters, however. That's not usually the way people do it. Of course people don't often do RF=N either. :) > If so, it is possible to change the placement strategy in an existing cluster? Yes. The only practical way is to change it such that it is a NOOP. In your case (RF=N), all changes will be a NOOP. Once changed, however, you can use the features of the new Strategy to your advantage. Although in your case it doesn't matter.. If you decide to try to change your Strategy in general, be sure to design a test that uses "nodetool getendpoints" to verify that replica sets say the same. =Rob -- =Robert Coli AIM>ALK - rc...@palominodb.com YAHOO - rcoli.palominob SKYPE - rcoli_palominodb
