Does the scan speed with CL.ALL is faster than CL.QUORUM and CL.ONE?

Hi all, I ran my benchmark(OPP via get_range_slices) and found the following: Why does the scan speed with CL.ALL is faster than CL.QUORUM and CL.ONE? CL.ONE (1k per row, Count:5) scan :11095 ms scan per:0.2219 ms scan thput:4506.5347 ops/sec CL.QUORUM scan :11072 ms scan per:0.22144 ms scan

Re: get_slice slow

Todd, This is a really bad idea. What you are likely doing is spreading that single row across a large number of sstables. The more columns you insert, the more sstables you are likely inspecting, the longer the get_slice operations will take. You can test whether this is so by running nodetool

Re: get_slice slow

thx artie, i haven't used a super CF because i thought it has more trouble doing slices because the entire row must be deserialized to get to the subcolumn you want? iostat is nothing, 0.0. i have plenty of RAM and the OS is I/O caching nicely i haven't used the key cache, because i only

Re: get_slice slow

Have you tried using a super column, it seems that having a row with over 100K columns and growing would be alot for cassandra to deserialize? what is iostat and jmeter telling you? it would be interesting to see that data. also what are you using for you key or row caching? do you need to use a

get_slice slow

i am using get_slice to pull columns from a row to emulate a queue. column names are TimeUUID and the values are small, < 32 bytes. simple ColumnFamily. i am using SlicePredicate like this to pull the first ("oldest") column in the row: SlicePredicate predicate = new SlicePredicate

Re: KeyRange.token in 0.7.0

kew .. hadoop is on my list, has been on my list, will probably still be on the list tomorrow ;) On Tue, 2010-08-24 at 11:53 -0700, Jonathan Ellis wrote: > in other words you're reinventing hadoop. not really recommended, but > knock yourself out if that's what you want to do. :) > > On Tue, Aug

Re: KeyRange.token in 0.7.0

in other words you're reinventing hadoop. not really recommended, but knock yourself out if that's what you want to do. :) On Tue, Aug 24, 2010 at 1:28 PM, B. Todd Burruss wrote: > i just came across this and i use tokens in range queries because it is > an easy straightforward way to divide the

Re: linux flavor?

This isn't directly related to Cassandra, but we did a bunch of I/O and disk load testing about 2 years ago when we started migrating to a new MTA platform looking specifically at filesystem performance. We compared EXT2, EXT3, GFS2, XFS and EXT4 under RHEL5/CentOS5 on a commodity box using 6 in

Re: KeyRange.token in 0.7.0

i just came across this and i use tokens in range queries because it is an easy straightforward way to divide the keyspace and operate on it using multiple threads and throttle the processing. maybe this is what hadoop does, i don't know much about hadoop. so i don't really agree that i'm doing i

Re: linux flavor?

CentOS works fine for me. straight out-o-the box. i also use ubuntu 10.04 w/o any troubles. make sure to jave jdk 1.6.0_20 or better. there was a bug that affects cassandra somewhere around 1.6.0_18 i think. On Tue, 2010-08-24 at 08:58 -0700, S Ahmed wrote: > Is there a particular linux flavor

linux flavor?

Is there a particular linux flavor that plays best with Cassandra? I believe the file system plays big role also, any comments in this regard? thanks.

Follow-up post on cassandra configuration with some experiments on GC tuning

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear all, thanks again for all the comments I got on my last post. I've played a bit with different GC settings and got my Cassandra instance to run very nicely with 8GB of heap. I summarized my experiences with GC tuning in this follow-up post: htt

RE: Index feature in 0.7

See the cassandra.yaml in TRUNK, but the syntax is: - name: Indexed1 column_metadata: - name: birthdate validator_class: LongType index_type: KEYS -Original Message- From: Peter Harrison [mailto:cheetah...@gmail.com] Sent: Monday,