Re: Java cient

2011-01-22 Thread Alois Bělaška
Agree about the Spring dependency. Cleaner solution is to extract Spring
support into separate module. It may be the next thing to do.

2011/1/22 Noble Paul നോബിള്‍ नोब्ळ् noble.p...@gmail.com

 I looked at pelops and found the API clean, but didn't like the spring
 dependency. Hector API's could have been simpler but I plan to
 abstract the most commonly used functionality in a simpler set of APIs

 On Thu, Jan 20, 2011 at 11:06 AM, Dan Washusen d...@reactive.org wrote:
  Pelops is pretty thin wrapper for the Thrift API.  It's thinness has both
 up
  and down sides; on the up side it's very easy to map functionality
 mentioned
  on the Cassandra API wiki page to functionality provided by Pelops, it is
  also relatively simple to add features (thanks to Alois^^ for indexing
  support).  The down side is you often have to deal with the Cassandra
 Thrift
  classes like ColumnOrSuperColumn...
  On 20 January 2011 15:58, Dan Retzlaff dretzl...@gmail.com wrote:
 
  My team switched our production stack from Hector to Pelops a while
 back,
  based largely on this admittedly subjective programmer experience bit.
  I've found Pelops' code and abstractions significantly easier to follow
 and
  integrate with, plus Pelops has had feature-parity with Hector for all
 of
  our use cases. It's quite possible that we just caught Hector during its
  transition to what Nate calls v2 but for our part, with no disrespect
 to
  the Hector community intended, we've been quite happy with the
 transition.
  Dan
  On Wed, Jan 19, 2011 at 3:30 PM, Jonathan Shook jsh...@gmail.com
 wrote:
 
  Perhaps. I use hector. I have an bit of rework to do moving from .6 to
  .7. This is something I wasn't anticipating in my earlier planning.
  Had Pelops been around when I started using Hector, I would have
  probably chosen it over Hector. The Pelops client seemed to be better
  conceived as far as programmer experience and simplicity went. Since
  then, Hector has had a v2 upgrade to their API which breaks much of
  the things that you would have done in version .6 and before.
  Conceptually speaking, they appear more similar now than before the
  Hector changes.
 
  I'm dreading having to do a significant amount of work on my client
  interface because of the incompatible API changes.. but I will have to
  in order to get my client/server caught up to the currently supported
  branch. That is just part of the cost of doing business with Cassandra
  at the moment. Hopefully after 1.0 on the server and some of the
  clients, this type of thing will be more unusual.
 
 
  2011/1/19 Noble Paul നോബിള്‍  नोब्ळ् noble.p...@gmail.com:
   Thanks everyone. I guess, I should go with hector
  
   On 18 Jan 2011 17:41, Alois Bělaška alois.bela...@gmail.com
 wrote:
   Definitelly Pelops https://github.com/s7/scale7-pelops
  
   2011/1/18 Noble Paul നോബിള്‍ नोब्ळ् noble.p...@gmail.com
  
   What is the most commonly used java client library? Which is the
 the
   most
   mature/feature complete?
   Noble
  
  
 
 
 



 --
 -
 Noble Paul | Systems Architect| AOL | http://aol.com



Re: Cassandra on iSCSI?

2011-01-22 Thread Mick Semb Wever
 So if one is forced to use a SAN, how should you set up Cassandra is
 the interesting question - to me! Here are some thoughts:- 
 1. Ensure that each node gets dedicated - not shared - LUNs 
 2. Ensure that these LUNs do share spindles, or nodes will seize to be
 isolatable (this will be tough to get, given how SAN administrators
 think about this) 
 3. Most SANs deliver performance by striping (RAID 0) - sacrifice
 striping for isolation if push comes to shove 
 4. Do not share data directories from multiple nodes onto a single
 location via NFS or CFS for example. They are cool in shared resource
 environments, but breaks the premise behind Cassandra. All data
 storage should be private to the cassandra node, even when on shared
 storage 
 5. Do not change any assumption around Replication Factor (RF) or
 Consistency Level (CL) due to the shared storage - in fact if
 anything, increase your replication factor because you now have
 potential SPOF storage.  

That was gold, and lead to a direct conversation between provider and
developer. Various tests showed IOPS will often be at 5k per node.
Therefore the iSCSI solution would need to be tailored to handle it.

Just like mentioned above our provider simply couldn't provide us so much
disk per server. But after a good discussion it became obvious (doh!)
that the application can actually save a lot of disk by using different
keyspaces with different RF. We have raw data that needs to be
collected, but can be temporarily unavailable for reading, hence RF=1
makes sense. This raw data is the vast bulk of the data so this saves
lots of disk space. The aggregated data, which is relatively small in
comparison, is critical for the application to read so we can keep in a
separate keyspace with higher RF...

~mck

-- 
“Anyone who lives within their means suffers from a lack of
imagination.” - Oscar Wilde 
| http://semb.wever.org | http://sesat.no
| http://finn.no   | Java XSS Filter



signature.asc
Description: This is a digitally signed message part