Re: Cassandra token range support for Hadoop (ColumnFamilyInputFormat)

[Aaron Morton]

>> “between 1.2.6 and 2.0.6 the setInputRange(startToken, endToken) is not 
>> working”
> Can you confirm or disprove?


My reading of the code is that it will consider the part of a token range (from 
vnodes or initial tokens) that overlap with the provided token range. 

> I’ve already got one confirmation that in C* version I use (1.2.15) setting 
> limits with setInputRange(startToken, endToken) doesn’t work.
Can you be more specific ?

> work only for ordered partitioners (in 1.2.15).

it will work with ordered and unordered partitioners equally. The difference is 
probably what you consider to “working” to mean.  The token ranges are handled 
the same, it’s the row in them that changes. 

Cheers
Aaron

-
Aaron Morton
New Zealand
@aaronmorton

Co-Founder & Principal Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com

On 20/05/2014, at 11:37 am, Anton Brazhnyk  wrote:

> Hi Aaron,
>  
> I’ve seen the code which you describe (working with splits and intersections) 
> but that range is derived from keys and work only for ordered partitioners 
> (in 1.2.15).
> I’ve already got one confirmation that in C* version I use (1.2.15) setting 
> limits with setInputRange(startToken, endToken) doesn’t work.
> “between 1.2.6 and 2.0.6 the setInputRange(startToken, endToken) is not 
> working”
> Can you confirm or disprove?
>  
> WBR,
> Anton
>  
> From: Aaron Morton [mailto:aa...@thelastpickle.com] 
> Sent: Monday, May 19, 2014 1:58 AM
> To: Cassandra User
> Subject: Re: Cassandra token range support for Hadoop 
> (ColumnFamilyInputFormat)
>  
> The limit is just ignored and the entire column family is scanned.
> Which limit ? 
> 
> 
> 1. Am I right that there is no way to get some data limited by token range 
> with ColumnFamilyInputFormat?
> From what I understand setting the input range is used when calculating the 
> splits. The token ranges in the cluster are iterated and if they intersect 
> with the supplied range the overlapping range is used to calculate the split. 
> Rather than the full token range. 
>  
> 2. Is there other way to limit the amount of data read from Cassandra with 
> Spark and ColumnFamilyInputFormat,
> so that this amount is predictable (like 5% of entire dataset)?
> if you suppled a token range is that is 5% of the possible range of values 
> for the token that should be close to a random 5% sample. 
>  
>  
> Hope that helps. 
> Aaron
>  
> -
> Aaron Morton
> New Zealand
> @aaronmorton
>  
> Co-Founder & Principal Consultant
> Apache Cassandra Consulting
> http://www.thelastpickle.com
>  
> On 14/05/2014, at 10:46 am, Anton Brazhnyk  wrote:
> 
> 
> Greetings,
> 
> I'm reading data from C* with Spark (via ColumnFamilyInputFormat) and I'd 
> like to read just part of it - something like Spark's sample() function.
> Cassandra's API seems allow to do it with its 
> ConfigHelper.setInputRange(jobConfiguration, startToken, endToken) method, 
> but it doesn't work.
> The limit is just ignored and the entire column family is scanned. It seems 
> this kind of feature is just not supported 
> and sources of AbstractColumnFamilyInputFormat.getSplits confirm that (IMO).
> Questions:
> 1. Am I right that there is no way to get some data limited by token range 
> with ColumnFamilyInputFormat?
> 2. Is there other way to limit the amount of data read from Cassandra with 
> Spark and ColumnFamilyInputFormat,
> so that this amount is predictable (like 5% of entire dataset)?
> 
> 
> WBR,
> Anton
> 

RE: Cassandra token range support for Hadoop (ColumnFamilyInputFormat)

[Anton Brazhnyk]

Hi Aaron,

I've seen the code which you describe (working with splits and intersections) 
but that range is derived from keys and work only for ordered partitioners (in 
1.2.15).
I've already got one confirmation that in C* version I use (1.2.15) setting 
limits with setInputRange(startToken, endToken) doesn't work.
"between 1.2.6 and 2.0.6 the setInputRange(startToken, endToken) is not working"
Can you confirm or disprove?

WBR,
Anton

From: Aaron Morton [mailto:aa...@thelastpickle.com]
Sent: Monday, May 19, 2014 1:58 AM
To: Cassandra User
Subject: Re: Cassandra token range support for Hadoop (ColumnFamilyInputFormat)

The limit is just ignored and the entire column family is scanned.
Which limit ?


1. Am I right that there is no way to get some data limited by token range with 
ColumnFamilyInputFormat?
>From what I understand setting the input range is used when calculating the 
>splits. The token ranges in the cluster are iterated and if they intersect 
>with the supplied range the overlapping range is used to calculate the split. 
>Rather than the full token range.

2. Is there other way to limit the amount of data read from Cassandra with 
Spark and ColumnFamilyInputFormat,
so that this amount is predictable (like 5% of entire dataset)?
if you suppled a token range is that is 5% of the possible range of values for 
the token that should be close to a random 5% sample.


Hope that helps.
Aaron

-
Aaron Morton
New Zealand
@aaronmorton

Co-Founder & Principal Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com

On 14/05/2014, at 10:46 am, Anton Brazhnyk 
mailto:anton.brazh...@genesys.com>> wrote:


Greetings,

I'm reading data from C* with Spark (via ColumnFamilyInputFormat) and I'd like 
to read just part of it - something like Spark's sample() function.
Cassandra's API seems allow to do it with its 
ConfigHelper.setInputRange(jobConfiguration, startToken, endToken) method, but 
it doesn't work.
The limit is just ignored and the entire column family is scanned. It seems 
this kind of feature is just not supported
and sources of AbstractColumnFamilyInputFormat.getSplits confirm that (IMO).
Questions:
1. Am I right that there is no way to get some data limited by token range with 
ColumnFamilyInputFormat?
2. Is there other way to limit the amount of data read from Cassandra with 
Spark and ColumnFamilyInputFormat,
so that this amount is predictable (like 5% of entire dataset)?


WBR,
Anton

Re: Multi-dc cassandra keyspace

[Nate McCall]

We did something similar with a split cloud/physical hardware deployment.
There was a weird requirement that app authentication data (fortunately in
it's own keyspace already) could not "live on the cloud" (shrug).

This ended up being a simple configuration change in the schema just like
your example and has, TMK, worked fine since.


On Fri, May 16, 2014 at 7:37 PM, Tupshin Harper  wrote:

> It's often an excellent strategy.  No known issues.
>
> -Tupshin
> On May 16, 2014 4:13 PM, "Anand Somani"  wrote:
>
>> Hi,
>>
>> It seems like it should be possible to have a keyspace replicated only to
>> a subset of DC's on a given cluster spanning across multiple DCs? Is there
>> anything bad about this approach?
>>
>> Scenario
>> Cluster spanning 4 DC's => CA, TX, NY, UT
>> Has multiple keyspaces such that
>> * "keyspace_CA_TX" - replication_strategy = {CA = 3, TX = 3}
>> * "keyspace_UT_NY" - replication_strategy = {UT = 3, NY = 3}
>> * "keyspace_CA_UT" - replication_strategy = {UT = 3, CA = 3}
>>
>> I am going to try this out, but was curious if anybody out there has
>> tried it.
>>
>> Thanks
>> Anand
>>
>


-- 
-
Nate McCall
Austin, TX
@zznate

Co-Founder & Sr. Technical Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com

Re: CQL 3 and wide rows

[Maciej Miklas]

Hi James,

Clustering is based on rows. I think that you meant not clustering columns, but 
compound columns. Still all columns belong to single table and are stored 
within single folder on one computer. And it looks to me (but I’am not sure) 
that CQL 3 driver loads all column names into memory - which is confusing to 
me. From one side we have wide row, but we load whole into ram…..

My understanding of wide row is a row that supports millions of columns, or 
similar things like map or set. In CLI you would generate column names (or use 
compound columns) to simulate set or map,  in CQL 3 you would use some static 
names plus Map or Set structures, or you could still alter table and have large 
number of columns. But still - I do not see Iteration, so it looks to me that 
CQL 3 is limited when compared to CLI/Hector.


Regards,
Maciej

On 19 May 2014, at 17:30, James Campbell  wrote:

> Maciej,
> 
> In CQL3 "wide rows" are expected to be created using clustering columns.  So 
> while the schema will have a relatively smaller number of named columns, the 
> effect is a wide row.  For example:
> 
> CREATE TABLE keyspace.widerow (
> row_key text,
> wide_row_column text,
> data_column text,
> PRIMARY KEY (row_key, wide_row_column));
> 
> Check out, for example, 
> http://www.datastax.com/dev/blog/schema-in-cassandra-1-1.​
> 
> James
> From: Maciej Miklas 
> Sent: Monday, May 19, 2014 11:20 AM
> To: user@cassandra.apache.org
> Subject: CQL 3 and wide rows
>  
> Hi *,
> 
> I’ve checked DataStax driver code for CQL 3, and it looks like the column 
> names for particular table are fully loaded into memory, it this true?
> 
> Cassandra should support wide rows, meaning tables with millions of columns. 
> Knowing that, I would expect kind of iterator for column names. Am I missing 
> something here? 
> 
> 
> Regards,
> Maciej Miklas

Re: CQL 3 and wide rows

[Maciej Miklas]

Hallo Jack,

You have given a perfect example for wide row.  Each reading from sensor 
creates new column within a row. It was also possible with Hector/CLI to have 
millions of columns within a single row. According to this page 
http://wiki.apache.org/cassandra/CassandraLimitations single row can have 2 
billions columns.

How does this relate to CQL 3 and tables? 

I still do not understand it because:
- it looks like driver loads all column names into memory - it looks to me that 
the 2 billions limitation from CLI is not valid anymore
- Map and Set values do not support iterator 


Regards,
Maciej


On 19 May 2014, at 17:31, Jack Krupansky  wrote:

> You might want to review this blog post on supporting dynamic columns in 
> CQL3, which points out that “the way to model dynamic cells in CQL is with a 
> compound primary key.”
>  
> See:
> http://www.datastax.com/dev/blog/does-cql-support-dynamic-columns-wide-rows
>  
> -- Jack Krupansky
>  
> From: Maciej Miklas
> Sent: Monday, May 19, 2014 11:20 AM
> To: user@cassandra.apache.org
> Subject: CQL 3 and wide rows
>  
> Hi *,
>  
> I’ve checked DataStax driver code for CQL 3, and it looks like the column 
> names for particular table are fully loaded into memory, it this true?
>  
> Cassandra should support wide rows, meaning tables with millions of columns. 
> Knowing that, I would expect kind of iterator for column names. Am I missing 
> something here?
>  
>  
> Regards,
> Maciej Miklas

Re: Ec2 Network I/O

[Nate McCall]

It's a good idea to increase phi_convict_threshold to at least 12 on EC2.
Using placement groups and single-tenant systems will certainly help.

Another optimization would be dedicating an Enhanced Network Interface (
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html)
specifically for gossip traffic.


On Mon, May 19, 2014 at 1:36 PM, Phil Burress wrote:

> Has anyone experienced network i/o issues with ec2? We are seeing a lot of
> these in our logs:
>
> HintedHandOffManager.java (line 477) Timed out replaying hints to
> /10.0.x.xxx; aborting (15 delivered)
>
> and these...
>
> Cannot handshake version with /10.0.x.xxx
>
> and these...
>
> java.io.IOException: Cannot proceed on repair because a neighbor
> (/10.0.x.xxx) is dead: session failed
>
> Occurs on all of our nodes. Even though in all cases, the host that is
> being reported as down or unavailable is up and readily 'pingable'.
>
> We are using shared tenancy on all our nodes (instance type m1.xlarge)
> with cassandra 2.0.7. Any suggestions on how to debug these errors?
>
> Is there a recommendation to move to Placement Groups for Cassandra?
>
> Thanks!
>
> Phil
>



-- 
-
Nate McCall
Austin, TX
@zznate

Co-Founder & Sr. Technical Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com

Re: Filtering on Collections

[Patricia Gorla]

I'm not sure about that — allowing collections as a primary key would be a
much different implementation than setting up a secondary index.

The primary key in CQL3 is actually the partition key which determines
which token the row is assigned, so you would still need to have one
partition key. Also, I don't see a use case for collections as a primary
key that you couldn't achieve with a composite key.


On Mon, May 19, 2014 at 1:35 PM, Eric Plowe  wrote:

> Ah, that is interesting, Patricia. Since they can be a secondary index,
> it's not too far off for them being able to be a primary key, no?
>
>
> On Mon, May 19, 2014 at 1:54 PM, Patricia Gorla <
> patri...@thelastpickle.com> wrote:
>
>> Raj,
>>
>> Secondary indexes across CQL3 collections were introduced into 2.1 beta1,
>> so will be available in future versions. See
>> https://issues.apache.org/jira/browse/CASSANDRA-4511
>>
>> If your main concern is performance then you should find another way to
>> model the data: each collection is read entirely into memory to access a
>> single item.
>>
>>
>>
>> On Mon, May 19, 2014 at 11:03 AM, Eric Plowe wrote:
>>
>>> Collection types cannot be used for filtering (as part of the where
>>> statement).
>>> They cannot be used as a primary key or part of a primary key.
>>> Secondary indexes are not supported as well.
>>>
>>>
>>> On Mon, May 19, 2014 at 12:50 PM, Raj Janakarajan <
>>> r...@zephyrhealthinc.com> wrote:
>>>
 Hello all,

 I am using Cassandra version 2.0.7.  I am wondering if "collections" is
 efficient for filtering.  We are thinking of using "collections" to
 maintain a list for a customer row but we have to be able to filter on the
 collection values.

 Select UUID from customer where eligibility_state IN (CA, NC)

 Eligibility_state being a collection.  The above query would be used
 frequently.
 Would you recommend collections for modeling from a performance
 perspective?

 Raj
 --

  Data Architect ❘ Zephyr Health
  589 Howard St. ❘ San Francisco, CA 94105
 m: +1 9176477433 ❘ f: +1 415 520-9288
  o: +1 415 529-7649 | s: raj.janakarajan

 http://www.zephyrhealth.com


>>>
>>
>>
>> --
>> Patricia Gorla
>> @patriciagorla
>>
>> Consultant
>> Apache Cassandra Consulting
>> http://www.thelastpickle.com 
>>
>
>


-- 
Patricia Gorla
@patriciagorla

Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com 

Re: Filtering on Collections

[Eric Plowe]

Ah, that is interesting, Patricia. Since they can be a secondary index,
it's not too far off for them being able to be a primary key, no?


On Mon, May 19, 2014 at 1:54 PM, Patricia Gorla
wrote:

> Raj,
>
> Secondary indexes across CQL3 collections were introduced into 2.1 beta1,
> so will be available in future versions. See
> https://issues.apache.org/jira/browse/CASSANDRA-4511
>
> If your main concern is performance then you should find another way to
> model the data: each collection is read entirely into memory to access a
> single item.
>
>
>
> On Mon, May 19, 2014 at 11:03 AM, Eric Plowe  wrote:
>
>> Collection types cannot be used for filtering (as part of the where
>> statement).
>> They cannot be used as a primary key or part of a primary key.
>> Secondary indexes are not supported as well.
>>
>>
>> On Mon, May 19, 2014 at 12:50 PM, Raj Janakarajan <
>> r...@zephyrhealthinc.com> wrote:
>>
>>> Hello all,
>>>
>>> I am using Cassandra version 2.0.7.  I am wondering if "collections" is
>>> efficient for filtering.  We are thinking of using "collections" to
>>> maintain a list for a customer row but we have to be able to filter on the
>>> collection values.
>>>
>>> Select UUID from customer where eligibility_state IN (CA, NC)
>>>
>>> Eligibility_state being a collection.  The above query would be used
>>> frequently.
>>> Would you recommend collections for modeling from a performance
>>> perspective?
>>>
>>> Raj
>>> --
>>>
>>>  Data Architect ❘ Zephyr Health
>>>  589 Howard St. ❘ San Francisco, CA 94105
>>> m: +1 9176477433 ❘ f: +1 415 520-9288
>>>  o: +1 415 529-7649 | s: raj.janakarajan
>>>
>>> http://www.zephyrhealth.com
>>>
>>>
>>
>
>
> --
> Patricia Gorla
> @patriciagorla
>
> Consultant
> Apache Cassandra Consulting
> http://www.thelastpickle.com 
>

Re: Index with same Name but different keyspace

[Bryan Talbot]

On Mon, May 19, 2014 at 6:39 AM, mahesh rajamani
wrote:

> Sorry I just realized the table name in 2 schema are slightly different,
> but still i am not sure why i should not use same index name across
> different schema. Below is the instruction to reproduce.
>
>
> Created 2 keyspace using cassandra-cli
>
>
> [default@unknown] create keyspace keyspace1 with placement_strategy =
> 'org.apache.cassandra.locator.SimpleStrategy' and
> strategy_options={replication_factor:1};
>
> [default@unknown] create keyspace keyspace2 with placement_strategy =
> 'org.apache.cassandra.locator.SimpleStrategy' and
> strategy_options={replication_factor:1};
>
>
> Create table index using cqlsh as below:
>
>
> cqlsh> use keyspace1;
>
> cqlsh:keyspace1> CREATE TABLE table1 (version text, flag boolean, primary
> key (version));
>
> cqlsh:keyspace1> create index sversionindex on table1(flag);
>
> cqlsh:keyspace1> use keyspace2;
>
> cqlsh:keyspace2> CREATE TABLE table2 (version text, flag boolean, primary
> key (version));
>
> cqlsh:keyspace2> create index sversionindex on table2(flag);
>
> *Bad Request: Duplicate index name sversionindex*
>
>

Since index name is optional in the create index statement, you could just
omit it and let the system give it a unique name for you.

-Bryan

Re: Best partition type for Cassandra with JBOD

[Bryan Talbot]

For XFS, using noatime and nodirtime isn't really useful either.

http://xfs.org/index.php/XFS_FAQ#Q:_Is_using_noatime_or.2Fand_nodiratime_at_mount_time_giving_any_performance_benefits_in_xfs_.28or_not_using_them_performance_decrease.29.3F




On Sat, May 17, 2014 at 7:52 AM, James Campbell <
ja...@breachintelligence.com> wrote:

>  Thanks for the thoughts!
> On May 16, 2014 4:23 PM, Ariel Weisberg  wrote:
>  Hi,
>
> Recommending nobarrier (mount option barrier=0) when you don't know if a
> non-volatile cache in play is probably not the way to go. A non-volatile
> cache will typically ignore write barriers if a given block device is
> configured to cache writes anyways.
>
> I am also skeptical you will see a boost in performance. Applications that
> want to defer and batch writes won't emit write barriers frequently and
> when they do it's because the data has to be there. Filesystems depend on
> write barriers although it is surprisingly hard to get a reordering that is
> really bad because of the way journals are managed.
>
> Cassandra uses log structured storage and supports asynchronous periodic
> group commit so it doesn't need to emit write barriers frequently.
>
> Setting read ahead to zero on an SSD is necessary to get the maximum
> number of random reads, but will also disable prefetching for sequential
> reads. You need a lot less prefetching with an SSD due to the much faster
> response time, but it's still many microseconds.
>
> Someone with more Cassandra specific knowledge can probably give better
> advice as to when a non-zero read ahead make sense with Cassandra. This is
> something may be workload specific as well.
>
> Regards,
>  Ariel
>
> On Fri, May 16, 2014, at 01:55 PM, Kevin Burton wrote:
>
> That and nobarrier… and probably noop for the scheduler if using SSD and
> setting readahead to zero...
>
>
>  On Fri, May 16, 2014 at 10:29 AM, James Campbell <
> ja...@breachintelligence.com> wrote:
>
>  Hi all—
>
>
>
> What partition type is best/most commonly used for a multi-disk JBOD setup
> running Cassandra on CentOS 64bit?
>
>
>
> The datastax production server guidelines recommend XFS for data
> partitions, saying, “Because Cassandra can use almost half your disk space
> for a single file, use XFS when using large disks, particularly if using a
> 32-bit kernel. XFS file size limits are 16TB max on a 32-bit kernel, and
> essentially unlimited on 64-bit.”
>
>
>
> However, the same document also notes that “Maximum recommended capacity
> for Cassandra 1.2 and later is 3 to 5TB per node,” which makes me think
> >16TB file sizes would be irrelevant (especially when not using RAID to
> create a single large volume).  What has been the experience of this group?
>
>
>
> I also noted that the guidelines don’t mention setting noatime and
> nodiratime flags in the fstab for data volumes, but I wonder if that’s a
> common practice.
>
> James
>
>
>
>
> --
>
>
>  Founder/CEO Spinn3r.com
>  Location: *San Francisco, CA*
>  Skype: *burtonator*
>  blog: http://burtonator.wordpress.com
>  … or check out my Google+ 
> profile
>  
>  War is peace. Freedom is slavery. Ignorance is strength. Corporations
> are people.
>
>
>


-- 
Bryan Talbot
Architect / Platform team lead, Aeria Games and Entertainment
Silicon Valley | Berlin | Tokyo | Sao Paulo

Re: Query first 1 columns for each partitioning keys in CQL?

[Bryan Talbot]

I think there are several issues in your schema and queries.

First, the schema can't efficiently return the single newest post for every
author. It can efficiently return the newest N posts for a particular
author.

On Fri, May 16, 2014 at 11:53 PM, 後藤 泰陽  wrote:

>
> But I consider LIMIT to be a keyword to limits result numbers from WHOLE
> results retrieved by the SELECT statement.
>


This is happening due to the incorrect use of minTimeuuid() function. All
of your created_at values are equal so you're essentially getting 2 (order
not defined) values that have the lowest created_at value.

The minTimeuuid() function is mean to be used in the WHERE clause of a
SELECT statement often with maxTimeuuid() to do BETWEEN sort of queries on
timeuuid values.




> The result with SELECT.. LIMIT is below. Unfortunately, This is not what I
> wanted.
> I wante latest posts of each authors. (Now I doubt if CQL3 can't represent
> it)
>
> cqlsh:blog_test> create table posts(
>  ... author ascii,
>  ... created_at timeuuid,
>  ... entry text,
>  ... primary key(author,created_at)
>  ... )WITH CLUSTERING ORDER BY (created_at DESC);
> cqlsh:blog_test>
> cqlsh:blog_test> insert into posts(author,created_at,entry) values
> ('john',minTimeuuid('2013-02-02 10:00+'),'This is an old entry by
> john');
> cqlsh:blog_test> insert into posts(author,created_at,entry) values
> ('john',minTimeuuid('2013-03-03 10:00+'),'This is a new entry by
> john');
> cqlsh:blog_test> insert into posts(author,created_at,entry) values
> ('mike',minTimeuuid('2013-02-02 10:00+'),'This is an old entry by
> mike');
> cqlsh:blog_test> insert into posts(author,created_at,entry) values
> ('mike',minTimeuuid('2013-03-03 10:00+'),'This is a new entry by
> mike');
> cqlsh:blog_test> select * from posts limit 2;
>
>  author | created_at   | entry
>
> +--+--
>mike | 1c4d9000-83e9-11e2-8080-808080808080 |  This is a new entry by
> mike
>mike | 4e52d000-6d1f-11e2-8080-808080808080 | This is an old entry by
> mike
>
>
>
>


To get most recent posts by a particular author, you'll need statements
more like this:

cqlsh:test> insert into posts(author,created_at,entry) values
('john',now(),'This is an old entry by john'); cqlsh:test> insert into
posts(author,created_at,entry) values ('john',now(),'This is a new entry by
john'); cqlsh:test> insert into posts(author,created_at,entry) values
('mike',now(),'This is an old entry by mike'); cqlsh:test> insert into
posts(author,created_at,entry) values ('mike',now(),'This is a new entry by
mike');

and then you can get posts by 'john' ordered by newest to oldest as:

cqlsh:test> select author, created_at, dateOf(created_at), entry from posts
where author = 'john' limit 2 ;

 author | created_at   | dateOf(created_at)   |
entry
+--+--+--
   john | 7cb1ac30-df85-11e3-bb46-4d2d68f17aa6 | 2014-05-19 11:43:36-0700 |
 This is a new entry by john
   john | 74bb6750-df85-11e3-bb46-4d2d68f17aa6 | 2014-05-19 11:43:23-0700 |
This is an old entry by john


-Bryan

Ec2 Network I/O

[Phil Burress]

Has anyone experienced network i/o issues with ec2? We are seeing a lot of
these in our logs:

HintedHandOffManager.java (line 477) Timed out replaying hints to
/10.0.x.xxx; aborting (15 delivered)

and these...

Cannot handshake version with /10.0.x.xxx

and these...

java.io.IOException: Cannot proceed on repair because a neighbor
(/10.0.x.xxx) is dead: session failed

Occurs on all of our nodes. Even though in all cases, the host that is
being reported as down or unavailable is up and readily 'pingable'.

We are using shared tenancy on all our nodes (instance type m1.xlarge) with
cassandra 2.0.7. Any suggestions on how to debug these errors?

Is there a recommendation to move to Placement Groups for Cassandra?

Thanks!

Phil

Re: Filtering on Collections

[Raj Janakarajan]

Thanks Eric for the information.  It looks like it will be supported in
future versions.

Raj


On Mon, May 19, 2014 at 10:03 AM, Eric Plowe  wrote:

> Collection types cannot be used for filtering (as part of the where
> statement).
> They cannot be used as a primary key or part of a primary key.
> Secondary indexes are not supported as well.
>
>
> On Mon, May 19, 2014 at 12:50 PM, Raj Janakarajan  > wrote:
>
>> Hello all,
>>
>> I am using Cassandra version 2.0.7.  I am wondering if "collections" is
>> efficient for filtering.  We are thinking of using "collections" to
>> maintain a list for a customer row but we have to be able to filter on the
>> collection values.
>>
>> Select UUID from customer where eligibility_state IN (CA, NC)
>>
>> Eligibility_state being a collection.  The above query would be used
>> frequently.
>> Would you recommend collections for modeling from a performance
>> perspective?
>>
>> Raj
>> --
>>
>>  Data Architect ❘ Zephyr Health
>>  589 Howard St. ❘ San Francisco, CA 94105
>> m: +1 9176477433 ❘ f: +1 415 520-9288
>>  o: +1 415 529-7649 | s: raj.janakarajan
>>
>> http://www.zephyrhealth.com
>>
>>
>


-- 

Data Architect ❘ Zephyr Health
589 Howard St. ❘ San Francisco, CA 94105
m: +1 9176477433 ❘ f: +1 415 520-9288
o: +1 415 529-7649 | s: raj.janakarajan

http://www.zephyrhealth.com

Re: Filtering on Collections

[Raj Janakarajan]

Thank you Patricia.  This is helpful.

Raj


On Mon, May 19, 2014 at 10:54 AM, Patricia Gorla  wrote:

> Raj,
>
> Secondary indexes across CQL3 collections were introduced into 2.1 beta1,
> so will be available in future versions. See
> https://issues.apache.org/jira/browse/CASSANDRA-4511
>
> If your main concern is performance then you should find another way to
> model the data: each collection is read entirely into memory to access a
> single item.
>
>
>
> On Mon, May 19, 2014 at 11:03 AM, Eric Plowe  wrote:
>
>> Collection types cannot be used for filtering (as part of the where
>> statement).
>> They cannot be used as a primary key or part of a primary key.
>> Secondary indexes are not supported as well.
>>
>>
>> On Mon, May 19, 2014 at 12:50 PM, Raj Janakarajan <
>> r...@zephyrhealthinc.com> wrote:
>>
>>> Hello all,
>>>
>>> I am using Cassandra version 2.0.7.  I am wondering if "collections" is
>>> efficient for filtering.  We are thinking of using "collections" to
>>> maintain a list for a customer row but we have to be able to filter on the
>>> collection values.
>>>
>>> Select UUID from customer where eligibility_state IN (CA, NC)
>>>
>>> Eligibility_state being a collection.  The above query would be used
>>> frequently.
>>> Would you recommend collections for modeling from a performance
>>> perspective?
>>>
>>> Raj
>>> --
>>>
>>>  Data Architect ❘ Zephyr Health
>>>  589 Howard St. ❘ San Francisco, CA 94105
>>> m: +1 9176477433 ❘ f: +1 415 520-9288
>>>  o: +1 415 529-7649 | s: raj.janakarajan
>>>
>>> http://www.zephyrhealth.com
>>>
>>>
>>
>
>
> --
> Patricia Gorla
> @patriciagorla
>
> Consultant
> Apache Cassandra Consulting
> http://www.thelastpickle.com 
>



-- 

Data Architect ❘ Zephyr Health
589 Howard St. ❘ San Francisco, CA 94105
m: +1 9176477433 ❘ f: +1 415 520-9288
o: +1 415 529-7649 | s: raj.janakarajan

http://www.zephyrhealth.com

Re: Filtering on Collections

[Patricia Gorla]

Raj,

Secondary indexes across CQL3 collections were introduced into 2.1 beta1,
so will be available in future versions. See
https://issues.apache.org/jira/browse/CASSANDRA-4511

If your main concern is performance then you should find another way to
model the data: each collection is read entirely into memory to access a
single item.



On Mon, May 19, 2014 at 11:03 AM, Eric Plowe  wrote:

> Collection types cannot be used for filtering (as part of the where
> statement).
> They cannot be used as a primary key or part of a primary key.
> Secondary indexes are not supported as well.
>
>
> On Mon, May 19, 2014 at 12:50 PM, Raj Janakarajan  > wrote:
>
>> Hello all,
>>
>> I am using Cassandra version 2.0.7.  I am wondering if "collections" is
>> efficient for filtering.  We are thinking of using "collections" to
>> maintain a list for a customer row but we have to be able to filter on the
>> collection values.
>>
>> Select UUID from customer where eligibility_state IN (CA, NC)
>>
>> Eligibility_state being a collection.  The above query would be used
>> frequently.
>> Would you recommend collections for modeling from a performance
>> perspective?
>>
>> Raj
>> --
>>
>>  Data Architect ❘ Zephyr Health
>>  589 Howard St. ❘ San Francisco, CA 94105
>> m: +1 9176477433 ❘ f: +1 415 520-9288
>>  o: +1 415 529-7649 | s: raj.janakarajan
>>
>> http://www.zephyrhealth.com
>>
>>
>


-- 
Patricia Gorla
@patriciagorla

Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com 

Re: Filtering on Collections

[Eric Plowe]

Collection types cannot be used for filtering (as part of the where
statement).
They cannot be used as a primary key or part of a primary key.
Secondary indexes are not supported as well.


On Mon, May 19, 2014 at 12:50 PM, Raj Janakarajan
wrote:

> Hello all,
>
> I am using Cassandra version 2.0.7.  I am wondering if "collections" is
> efficient for filtering.  We are thinking of using "collections" to
> maintain a list for a customer row but we have to be able to filter on the
> collection values.
>
> Select UUID from customer where eligibility_state IN (CA, NC)
>
> Eligibility_state being a collection.  The above query would be used
> frequently.
> Would you recommend collections for modeling from a performance
> perspective?
>
> Raj
> --
>
> Data Architect ❘ Zephyr Health
>  589 Howard St. ❘ San Francisco, CA 94105
> m: +1 9176477433 ❘ f: +1 415 520-9288
> o: +1 415 529-7649 | s: raj.janakarajan
>
> http://www.zephyrhealth.com
>
>

Filtering on Collections

[Raj Janakarajan]

Hello all,

I am using Cassandra version 2.0.7.  I am wondering if "collections" is
efficient for filtering.  We are thinking of using "collections" to
maintain a list for a customer row but we have to be able to filter on the
collection values.

Select UUID from customer where eligibility_state IN (CA, NC)

Eligibility_state being a collection.  The above query would be used
frequently.
Would you recommend collections for modeling from a performance perspective?

Raj
-- 

Data Architect ❘ Zephyr Health
589 Howard St. ❘ San Francisco, CA 94105
m: +1 9176477433 ❘ f: +1 415 520-9288
o: +1 415 529-7649 | s: raj.janakarajan

http://www.zephyrhealth.com

Re: CQL 3 and wide rows

[Jack Krupansky]

You might want to review this blog post on supporting dynamic columns in CQL3, 
which points out that “the way to model dynamic cells in CQL is with a compound 
primary key.”

See:
http://www.datastax.com/dev/blog/does-cql-support-dynamic-columns-wide-rows

-- Jack Krupansky

From: Maciej Miklas 
Sent: Monday, May 19, 2014 11:20 AM
To: user@cassandra.apache.org 
Subject: CQL 3 and wide rows

Hi *, 

I’ve checked DataStax driver code for CQL 3, and it looks like the column names 
for particular table are fully loaded into memory, it this true?

Cassandra should support wide rows, meaning tables with millions of columns. 
Knowing that, I would expect kind of iterator for column names. Am I missing 
something here? 


Regards,
Maciej Miklas

RE: CQL 3 and wide rows

[James Campbell]

Maciej,


In CQL3 "wide rows" are expected to be created using clustering columns.  So 
while the schema will have a relatively smaller number of named columns, the 
effect is a wide row.  For example:


CREATE TABLE keyspace.widerow (

row_key text,

wide_row_column text,

data_column text,

PRIMARY KEY (row_key, wide_row_column));


Check out, for example, 
http://www.datastax.com/dev/blog/schema-in-cassandra-1-1.?


James


From: Maciej Miklas 
Sent: Monday, May 19, 2014 11:20 AM
To: user@cassandra.apache.org
Subject: CQL 3 and wide rows

Hi *,

I've checked DataStax driver code for CQL 3, and it looks like the column names 
for particular table are fully loaded into memory, it this true?

Cassandra should support wide rows, meaning tables with millions of columns. 
Knowing that, I would expect kind of iterator for column names. Am I missing 
something here?


Regards,
Maciej Miklas

CQL 3 and wide rows

[Maciej Miklas]

Hi *,

I’ve checked DataStax driver code for CQL 3, and it looks like the column
names for particular table are fully loaded into memory, it this true?

Cassandra should support wide rows, meaning tables with millions of
columns. Knowing that, I would expect kind of iterator for column names. Am
I missing something here?


Regards,
Maciej Miklas

Re: Cyclop - CQL web based editor has been released!

[Maciej Miklas]

thanks - I've fixed it.

Regards,
Maciej


On Mon, May 12, 2014 at 2:50 AM, graham sanderson  wrote:

> Looks cool - giving it a try now (note FYI when building,
> TestDataConverter.java line 46 assumes a specific time zone)
>
> On May 11, 2014, at 12:41 AM, Maciej Miklas  wrote:
>
> Hi everybody,
>
> I am aware that this mailing list is meant for Cassandra users, but I’ve
> developed something that is strictly related to Cassandra, so I tough that
> it might be interesting for some of you.
> I’ve already sent one email several months ago, but since then a lot of
> things has changed!
>
> Cyclop is web based CQL editor - you can deploy it in web container and
> use it’s web interface to execute CQL queries or to import/export data.
> There is also live deployment, so you can try it out immediately. Of
> course the whole thing is open source.
>
> Hier is the project link containing all details:
> https://github.com/maciejmiklas/cyclop
>
> Regards,
> Maciej
>
>
>

Re: Index with same Name but different keyspace

[mahesh rajamani]

Sorry I just realized the table name in 2 schema are slightly different,
but still i am not sure why i should not use same index name across
different schema. Below is the instruction to reproduce.


Created 2 keyspace using cassandra-cli


[default@unknown] create keyspace keyspace1 with placement_strategy =
'org.apache.cassandra.locator.SimpleStrategy' and
strategy_options={replication_factor:1};

[default@unknown] create keyspace keyspace2 with placement_strategy =
'org.apache.cassandra.locator.SimpleStrategy' and
strategy_options={replication_factor:1};


Create table index using cqlsh as below:


cqlsh> use keyspace1;

cqlsh:keyspace1> CREATE TABLE table1 (version text, flag boolean, primary
key (version));

cqlsh:keyspace1> create index sversionindex on table1(flag);

cqlsh:keyspace1> use keyspace2;

cqlsh:keyspace2> CREATE TABLE table2 (version text, flag boolean, primary
key (version));

cqlsh:keyspace2> create index sversionindex on table2(flag);

*Bad Request: Duplicate index name sversionindex*

*Thanks*
*Mahesh*





On Sat, May 17, 2014 at 3:11 AM, Mark Reddy  wrote:

> Can you share your schema and the commands you are running?
>
>
> On Thu, May 15, 2014 at 7:54 PM, mahesh rajamani <
> rajamani.mah...@gmail.com> wrote:
>
>> Hi,
>>
>> I am using Cassandra 2.0.5 version. I trying to setup 2 keyspace with
>> same tables for different testing. While creating index on the tables, I
>> realized I am not able to use the same index name  though the tables are in
>> different keyspaces. Is maintaining unique index name across keyspace is
>> must/feature?
>>
>> --
>> Regards,
>> Mahesh Rajamani
>>
>
>


-- 
Regards,
Mahesh Rajamani

Can SSTables overlap with SizeTieredCompactionStrategy?

[Phil Luckhurst]

We have a table defined using SizeTieredCompactionStrategy that is used to
store time series data. Over a period of a few days we wrote approximately
200,000 unique time based entries for each of 700 identifiers, i.e. 700 wide
rows with 200,000 entries in each.  The table was empty when we started and
and there were no updates to any entries, no deletions, and no tombstones
were created.

Our estimates suggested that this should have required about 7GB of disk
space but when we looked on disk there were 8 sstables taking up 11GB of
space.

Running nodetool compact on the column family reduced it to a single sstable
that does match our 7GB estimate.

I'd like to understand what accounts for the other 4GB when it was stored as
multiple sstables? Is it because the individual sstables overlap?

Thanks
Phil



--
View this message in context: 
http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Can-SSTables-overlap-with-SizeTieredCompactionStrategy-tp7594574.html
Sent from the cassandra-u...@incubator.apache.org mailing list archive at 
Nabble.com.

Changing default_time_to_live

[Keith Wright]

Hi all, we are using C* 2.0.6 and have set the default_time_to_live parameter 
on a number of our LCS column families.  I was wondering what would happen if 
we were to decrease this value via a table alter.  Would subsequent compactions 
of data written before that alter honor the new value and remove the data?  Or 
is the purpose of this setting just to supply a TTL to be written on update 
should one not be provided?

I ask because I’m hoping to free up a bunch of space by tightening the TTL 
value and I would prefer not to have to either insert all of the existing data 
to a new table or update the existing one.

Thanks!

Re: idempotent counters

[Jabbar Azam]

Thanks Aaron. I've mitigated this by removing the dependency on idempotent
counters. But its good to know the limitations of counters.

Thanks

Jabbar Azam
On 19 May 2014 08:36, "Aaron Morton"  wrote:

> Does anybody else use another technique for achieving this idempotency
> with counters?
>
>
> The idempotency problem with counters has to do with what will happen when
> you get a timeout. If you reply the write there is a chance of the
> increment been applied twice. This is inherent in the current design.
>
> Cheers
> Aaron
>
>
> -
> Aaron Morton
> New Zealand
> @aaronmorton
>
> Co-Founder & Principal Consultant
> Apache Cassandra Consulting
> http://www.thelastpickle.com
>
> On 9/05/2014, at 1:07 am, Jabbar Azam  wrote:
>
> Hello,
>
> Do people use counters when they want to have idempotent operations in
> cassandra?
>
> I have a use case for using a counter to check for a count of objects in a
> partition. If the counter is more than some value then the data in the
> partition is moved into two different partitions. I can't work out how to
> do this splitting and recover if a problem happens during modification of
> the counter.
>
>
> http://www.ebaytechblog.com/2012/08/14/cassandra-data-modeling-best-practices-part-2explains
>  that counters shouldn't be used if you want idempotency. I would
> agree, but the alternative  is not very elegant. I would have to manully
> count the objects in a partition and then move the data and repeat the
> operation if something went wrong.
>
> It is less resource intensive to read a counter value to see if a
> partition needs splitting then to read all the objects in a partition. The
> counter value can be stored in its own table sorting in descending order of
> the counter value.
>
> Does anybody else use another technique for achieving this idempotency
> with counters?
>
> I'm using cassandra 2.0.7.
>
>
>
> Thanks
>
> Jabbar Azam
>
>
>

Re: Effect of number of keyspaces on write-throughput....

[Krishna Chaitanya]

Thankyou for making these issues clear. Currently, in my datamodel, I have
the current second( seconds-from-epoch) as the row key and micro second
with the client number as the column key.
 Hence, all the packets received during a particular second
on all the clients are stored in the same row. I did this because of the
ease in measuring the write throughput every second.
  So, according to you, this isn't a good data model since it
leads to a hot spot wherein all the packets received in a particular second
are stored to the same row? Since, the clients are all synchronized using
NTP, all the packets received by all the clients in a particular second,
are stored in the same row. I would assume now that, changing the data
model such that multiple rows are updated every second is a better idea
wherein client side logging can be used to measure the write throughput. In
this way write throughput can be increased by adding more nodes to the
cluster since now there are no hotspots as multiple rows are being updated
every second.
Is this true?

Thank you.
On May 19, 2014 1:19 PM, "Aaron Morton"  wrote:

> Each client is writing to a separate keyspace simultaneously. Hence, is
> there a lot of switching of keyspaces?
>
> I would think not. If the client app is using one keyspace per connection
> there should be no reason for the driver to change keyspaces.
>
>
>
>  But, I observed that when using a single keyspace, the write throughout
> reduced slightly to 1800pkts/sec while I actually expected it to increase
> since there is no switching of contexts now. Why is this so?
>
>
> That’s a 5% change which is close enough to be ignored.
>
> I would guess that the clients are not doing anything that requires the
> driver to change the keyspace for the connection.
>
>  Can you also kindly explain how factors like using a single
> v/s multiple keyspaces, distributing write requests to a single cassandra
> node v/s multiple cassandra nodes, etc. affect the write throughput?
>
> Normally you have one keyspace per application. And the best data models
> are ones where the throughput improves as the number of nodes increases.
> This happens when there are no “hot spots” where every / most web requests
> need to read or write to a particular row.
>
> In general you can improve throughput by having more client threads
> hitting more machines. You can expect 3,000 to 4,000 non counter writes per
> code per node.
>
> Hope that helps.
> Aaron
>
> -
> Aaron Morton
> New Zealand
> @aaronmorton
>
> Co-Founder & Principal Consultant
> Apache Cassandra Consulting
> http://www.thelastpickle.com
>
> On 13/05/2014, at 1:02 am, Krishna Chaitanya 
> wrote:
>
> Hello,
> Thanks for the reply. Currently, each client is writing about 470 packets
> per second where each packet is 1500 bytes. I have four clients writing
> simultaneously to the cluster. Each client is writing to a separate
> keyspace simultaneously. Hence, is there a lot of switching of keyspaces?
>
> The total throughput is coming to around 1900 packets per second
> when using multiple keyspaces. This is because there are 4 clients and each
> one is writing around 470 pkts/sec. But, I observed that when using a
> single keyspace, the write throughout reduced slightly to 1800pkts/sec
> while I actually expected it to increase since there is no switching of
> contexts now. Why is this so?  470 packets is the maximum I can write from
> each client currently, since it is the limitation of my client program.
> I should also mention that these tests are being run on a
> single and double node clusters with all  the write requests going only to
> a single cassandra server.
>
>  Can you also kindly explain how factors like using a single
> v/s multiple keyspaces, distributing write requests to a single cassandra
> node v/s multiple cassandra nodes, etc. affect the write throughput?  Are
> there any other factors that affect write throughput other than these?
> Because, a single cassandra node seems to be able to handle all these write
> requests as I am not able to see any significant improvement by
> distributing write requests among multiple nodes.
>
> Thanking you.
>
> On May 12, 2014 2:39 PM, "Aaron Morton"  wrote:
>
>> On the homepage of libQtCassandra, its mentioned that switching between
>> keyspaces is costly when storing into Cassandra thereby affecting the write
>> throughput. Is this necessarily true for other libraries like pycassa and
>> hector as well?
>>
>> When using the thrift connection the keyspace is a part of the connection
>> state, so changing keyspaces requires a round trip to the server. Not
>> hugely expensive, but it adds up if you do it a lot.
>>
>> Can I increase the write throughput by configuring all
>> the clients to store in a single keyspace instead of multiple keyspaces to
>> increase the write throughput?
>>
>> You should exp

Re: Cassandra token range support for Hadoop (ColumnFamilyInputFormat)

[Aaron Morton]

> The limit is just ignored and the entire column family is scanned.
Which limit ? 

> 1. Am I right that there is no way to get some data limited by token range 
> with ColumnFamilyInputFormat?
From what I understand setting the input range is used when calculating the 
splits. The token ranges in the cluster are iterated and if they intersect with 
the supplied range the overlapping range is used to calculate the split. Rather 
than the full token range. 

> 2. Is there other way to limit the amount of data read from Cassandra with 
> Spark and ColumnFamilyInputFormat,
> so that this amount is predictable (like 5% of entire dataset)?
if you suppled a token range is that is 5% of the possible range of values for 
the token that should be close to a random 5% sample. 


Hope that helps. 
Aaron

-
Aaron Morton
New Zealand
@aaronmorton

Co-Founder & Principal Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com

On 14/05/2014, at 10:46 am, Anton Brazhnyk  wrote:

> Greetings,
> 
> I'm reading data from C* with Spark (via ColumnFamilyInputFormat) and I'd 
> like to read just part of it - something like Spark's sample() function.
> Cassandra's API seems allow to do it with its 
> ConfigHelper.setInputRange(jobConfiguration, startToken, endToken) method, 
> but it doesn't work.
> The limit is just ignored and the entire column family is scanned. It seems 
> this kind of feature is just not supported 
> and sources of AbstractColumnFamilyInputFormat.getSplits confirm that (IMO).
> Questions:
> 1. Am I right that there is no way to get some data limited by token range 
> with ColumnFamilyInputFormat?
> 2. Is there other way to limit the amount of data read from Cassandra with 
> Spark and ColumnFamilyInputFormat,
> so that this amount is predictable (like 5% of entire dataset)?
> 
> 
> WBR,
> Anton
> 
> 

Re: Question about READS in a multi DC environment.

[Aaron Morton]

In this case I was not thinking about what was happening synchronous to client 
request, only that the request was hitting all nodes. 

You are right, when reading at LOCAL_ONE the coordinator will only be blocking 
for one response (the data response). 

Cheers
Aaron
-
Aaron Morton
New Zealand
@aaronmorton

Co-Founder & Principal Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com

On 14/05/2014, at 11:36 am, graham sanderson  wrote:

> Yeah, but all the requests for data/digest are sent at the same time… 
> responses that aren’t “needed” to complete the request are dealt with 
> asynchronously (possibly causing repair). 
> 
> In the original trace (which is confusing because I don’t think the clocks 
> are in sync)… I don’t see anything that makes me believe it is blocking for 
> all 3 responses - It actually does reads on all 3 nodes even if only digests 
> are required
> 
> On May 12, 2014, at 12:37 AM, DuyHai Doan  wrote:
> 
>> Ins't read repair supposed to be done asynchronously in background ?
>> 
>> 
>> On Mon, May 12, 2014 at 2:07 AM, graham sanderson  wrote:
>> You have a read_repair_chance of 1.0 which is probably why your query is 
>> hitting all data centers.
>> 
>> On May 11, 2014, at 3:44 PM, Mark Farnan  wrote:
>> 
>> > Im trying to understand READ load in Cassandra across a multi-datacenter 
>> > cluster.   (Specifically why it seems to be hitting more than one DC) and 
>> > hope someone can help.
>> >
>> > From what Iím seeing here, a READ, with Consistency LOCAL_ONE,   seems to 
>> > be hitting All 3 datacenters, rather than just the one Iím connected to.   
>> > I see  'Read 101 live and 0 tombstoned cells'  from EACH of the 3 DC"s in 
>> > the trace, which seems, wrong.
>> > I have tried every  Consistency level, same result.   This also is same 
>> > from my C# code via the DataStax driver, (where I first noticed the issue).
>> >
>> > Can someone please shed some light on what is occurring ?  Specifically I 
>> > dont' want a query on one DC, going anywhere near the other 2 as a rule, 
>> > as in production,  these DC's will be accross slower links.
>> >
>> >
>> > Query:  (NOTE:  Whilst this uses a kairosdb table,  i'm just playing with 
>> > queries against it as it has 100k columns in this key for testing).
>> >
>> > cqlsh:kairosdb> consistency local_one
>> > Consistency level set to LOCAL_ONE.
>> >
>> > cqlsh:kairosdb> select * from data_points where key = 
>> > 0x6d61726c796e2e746573742e74656d7034000145b514a400726f6f6d3d6f6963653a
>> >  limit 1000;
>> >
>> > ... Some return data  rows listed here which I've removed 
>> >
>> > 
>> > Query Respose Trace:
>> >
>> > activity   
>> >   | timestamp  
>> >   | source | source_elapsed
>> > --+--++
>> >
>> >execute_cql3_query | 
>> > 07:18:12,692 | 192.168.25.111 |  0
>> >
>> > Message received from /192.168.25.111 | 
>> > 07:18:00,706 | 192.168.25.131 | 50
>> >
>> >   Executing single-partition query on data_points | 
>> > 07:18:00,707 | 192.168.25.131 |760
>> >
>> >  Acquiring sstable references | 
>> > 07:18:00,707 | 192.168.25.131 |814
>> >
>> >   Merging memtable tombstones | 
>> > 07:18:00,707 | 192.168.25.131 |924
>> >
>> >  Bloom filter allows skipping sstable 191 | 
>> > 07:18:00,707 | 192.168.25.131 |   1050
>> >
>> >  Bloom filter allows skipping sstable 190 | 
>> > 07:18:00,707 | 192.168.25.131 |   1166
>> >
>> > Key cache hit for sstable 189 | 
>> > 07:18:00,707 | 192.168.25.131 |   1275
>> >
>> >   Seeking to partition beginning in data file | 
>> > 07:18:00,707 | 192.168.25.131 |   1293
>> >Skipped 0/3 
>> > non-slice-inters

Re: Cassandra counter column family performance

[Aaron Morton]

> I get a lot of TExceptions
What are the exceptions ?

In general counters are slower than writes, but that does not lead them to fail 
like that. 

Check the logs for errors and/or messages from the GCInspector saying the 
garbage collection is going on. 

Cheers
A

-
Aaron Morton
New Zealand
@aaronmorton

Co-Founder & Principal Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com

On 13/05/2014, at 9:51 pm, Batranut Bogdan  wrote:

> Hello all,
> 
> I have a counter CF defined as pk text PRIMARY KEY, a counter, b counter, c 
> counter, d counter
> After inserting a few million keys... 55 mil, the performance goes down the 
> drain, 2-3 nodes in the cluster are on medium load, and when inserting 
> batches of same lengths writes take longer and longer until the whole cluster 
> becomes loaded and I get a lot of TExceptions... and the cluster becomes 
> unresponsive.
> 
> Did anyone have the same problem?
> Feel free to comment and share experiences about counter CF performance.
> 

Re: Datacenter understanding question

[Aaron Morton]

Depends on how you have setup the replication. 

If you are using SimpleStrategy with RF 1, then there will be a single copy of 
each row in the cluster. 

If you are using the NetworkTopologyStrategy with RF 1 in each DC then there 
will be two copies of each row in the cluster. One in each DC. 

Hope that helps. 
Aaron

-
Aaron Morton
New Zealand
@aaronmorton

Co-Founder & Principal Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com

On 15/05/2014, at 3:55 am, Mark Farnan  wrote:

> Yes they will
>  
> From: ng [mailto:pipeli...@gmail.com] 
> Sent: Tuesday, May 13, 2014 11:07 PM
> To: user@cassandra.apache.org
> Subject: Datacenter understanding question
>  
> If I have configuration of two data center with one node each.
> Replication factor is also 1.
> Will these 2 nodes going to be mirrored/replicated?

Re: Query returns incomplete result

[Aaron Morton]

Calling execute the second time runs the query a second time, and it looks like 
the query mutates instance state during the pagination. 

What happens if you only call execute() once ? 

Cheers
Aaron

-
Aaron Morton
New Zealand
@aaronmorton

Co-Founder & Principal Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com

On 8/05/2014, at 8:03 pm, Lu, Boying  wrote:

> Hi, All,
>  
> I use the astyanax 1.56.48 + Cassandra 2.0.6 in my test codes and do some 
> query like this:
>  
> query = keyspace.prepareQuery(..).getKey(…)
> .autoPaginate(true)
> .withColumnRange(new RangeBuilder().setLimit(pageSize).build());
>  
> ColumnList result;
> result= query.execute().getResult();
> while (!result.isEmpty()) {
> //handle result here
> result= query.execute().getResult();
> }
>  
> There are 2003 records in the DB, if the pageSize is set to 1100, I get only 
> 2002 records back.
> and if the pageSize is set to 3000, I can get the all 2003 records back.
>  
> Does anyone know why? Is it a bug?
>  
> Thanks
>  
> Boying

Re: Schema errors when bootstrapping / restarting node

[Aaron Morton]

> I am able to fix this error by clearing out the schema_columns system table 
> on disk.  After that, a node can boot successfully.
> 
> Does anyone have a clue what's going on here?

Something has come corrupted in the system tables as you say. 

A less aggressive way to reset the local schema is to use nodetool 
resetlocalschema on the nodes that you suspect as having problems. 

> ERROR [InternalResponseStage:5] 2014-05-05 23:56:03,786 CassandraDaemon.java 
> (line 191) Exception in thread Thread[InternalResponseStage:5,5,main]
> org.apache.cassandra.db.marshal.MarshalException: cannot parse 'column1' as 
> hex bytes
> at 
> org.apache.cassandra.db.marshal.BytesType.fromString(BytesType.java:69)
> at 
> org.apache.cassandra.config.ColumnDefinition.fromSchema(ColumnDefinition.java:231)
> at 
> org.apache.cassandra.config.CFMetaData.addColumnDefinitionSchema(CFMetaData.java:1524)
> at 
> org.apache.cassandra.config.CFMetaData.fromSchema(CFMetaData.java:1456)

This looks like a secondary index has been incorrectly defined via thrift. I 
would guess the comparator for the CF is BytesType and you have defined an 
index on a column and specified the column name as “column1” which is not a 
valid hex value. 

You should be able to fix this by dropping the index or dropping the CF. 

Hope that helps. 
Aaron



-
Aaron Morton
New Zealand
@aaronmorton

Co-Founder & Principal Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com

On 14/05/2014, at 2:18 am, Adam Cramer  wrote:

> Hi All,
> 
> I'm having some major issues bootstrapping a new node to my cluster.  We are 
> running 1.2.16, with vnodes enabled.
> 
> When a new node starts up (with auto_bootstrap), it selects a host ID and 
> finds the ring successfully:
> 
> INFO 18:42:29,559 JOINING: waiting for ring information
> 
> It successfully selects a set of tokens.  Then the weird stuff begins.  I get 
> this error once, while the node is reading the system keyspace:
> 
> ERROR 18:42:32,921 Exception in thread Thread[InternalResponseStage:1,5,main]
> java.lang.NullPointerException
>   at 
> org.apache.cassandra.utils.ByteBufferUtil.toLong(ByteBufferUtil.java:421)
>   at org.apache.cassandra.cql.jdbc.JdbcLong.compose(JdbcLong.java:94)
>   at org.apache.cassandra.db.marshal.LongType.compose(LongType.java:34)
>   at 
> org.apache.cassandra.cql3.UntypedResultSet$Row.getLong(UntypedResultSet.java:138)
>   at 
> org.apache.cassandra.db.SystemTable.migrateKeyAlias(SystemTable.java:199)
>   at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:346)
>   at 
> org.apache.cassandra.service.MigrationTask$1.response(MigrationTask.java:66)
>   at 
> org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:47)
>   at 
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:56)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at java.lang.Thread.run(Thread.java:745)
> 
> 
> But it doesn't stop the bootstrap process.  The node successfully handshakes 
> versions, and pauses before bootstrapping:
> 
> 
>  INFO 18:42:59,564 JOINING: schema complete, ready to bootstrap
>  INFO 18:42:59,565 JOINING: waiting for pending range calculation
>  INFO 18:42:59,565 JOINING: calculation complete, ready to bootstrap
>  INFO 18:42:59,565 JOINING: getting bootstrap token
>  INFO 18:42:59,705 JOINING: sleeping 3 ms for pending range setup
> 
> 
> After 30 seconds, I get a flood of endless 
> org.apache.cassandra.db.UnknownColumnFamilyException errors, and all other 
> nodes in the cluster log the following endlessly:
> 
> INFO [HANDSHAKE-/x.x.x.x] 2014-05-09 18:44:36,289 OutboundTcpConnection.java 
> (line 418) Handshaking version with /x.x.x.x
> 
> 
> I suspect there may be something wrong with my schemas.  Sometimes while 
> restarting an existing node, the node will fail to restart, with the 
> following error, again while reading the system keyspace:
> 
> ERROR [InternalResponseStage:5] 2014-05-05 23:56:03,786 CassandraDaemon.java 
> (line 191) Exception in thread Thread[InternalResponseStage:5,5,main]
> org.apache.cassandra.db.marshal.MarshalException: cannot parse 'column1' as 
> hex bytes
> at 
> org.apache.cassandra.db.marshal.BytesType.fromString(BytesType.java:69)
> at 
> org.apache.cassandra.config.ColumnDefinition.fromSchema(ColumnDefinition.java:231)
> at 
> org.apache.cassandra.config.CFMetaData.addColumnDefinitionSchema(CFMetaData.java:1524)
> at 
> org.apache.cassandra.config.CFMetaData.fromSchema(CFMetaData.java:1456)
> at 
> org.apache.cassandra.config.KSMetaData.deserializeColumnFamilies(KSMetaData.java:306)
> at 
> org.apache.cassandra.db.DefsTable.mergeColumnFamilies(DefsTable.java:444)
> at org.apache.cassandra.db.DefsTab

Re: Effect of number of keyspaces on write-throughput....

[Aaron Morton]

> Each client is writing to a separate keyspace simultaneously. Hence, is there 
> a lot of switching of keyspaces?
> 
> 
I would think not. If the client app is using one keyspace per connection there 
should be no reason for the driver to change keyspaces. 

 
>  But, I observed that when using a single keyspace, the write throughout 
> reduced slightly to 1800pkts/sec while I actually expected it to increase 
> since there is no switching of contexts now. Why is this so? 
> 
> 

That’s a 5% change which is close enough to be ignored. 

I would guess that the clients are not doing anything that requires the driver 
to change the keyspace for the connection. 

>  Can you also kindly explain how factors like using a single v/s 
> multiple keyspaces, distributing write requests to a single cassandra node 
> v/s multiple cassandra nodes, etc. affect the write throughput? 
> 
> 
Normally you have one keyspace per application. And the best data models are 
ones where the throughput improves as the number of nodes increases. This 
happens when there are no “hot spots” where every / most web requests need to 
read or write to a particular row. 

In general you can improve throughput by having more client threads hitting 
more machines. You can expect 3,000 to 4,000 non counter writes per code per 
node. 

Hope that helps. 
Aaron

-
Aaron Morton
New Zealand
@aaronmorton

Co-Founder & Principal Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com

On 13/05/2014, at 1:02 am, Krishna Chaitanya  wrote:

> Hello,
> Thanks for the reply. Currently, each client is writing about 470 packets per 
> second where each packet is 1500 bytes. I have four clients writing 
> simultaneously to the cluster. Each client is writing to a separate keyspace 
> simultaneously. Hence, is there a lot of switching of keyspaces?
> 
> The total throughput is coming to around 1900 packets per second when 
> using multiple keyspaces. This is because there are 4 clients and each one is 
> writing around 470 pkts/sec. But, I observed that when using a single 
> keyspace, the write throughout reduced slightly to 1800pkts/sec while I 
> actually expected it to increase since there is no switching of contexts now. 
> Why is this so?  470 packets is the maximum I can write from each client 
> currently, since it is the limitation of my client program.
> I should also mention that these tests are being run on a 
> single and double node clusters with all  the write requests going only to a 
> single cassandra server.
> 
>  Can you also kindly explain how factors like using a single v/s 
> multiple keyspaces, distributing write requests to a single cassandra node 
> v/s multiple cassandra nodes, etc. affect the write throughput?  Are there 
> any other factors that affect write throughput other than these?  Because, a 
> single cassandra node seems to be able to handle all these write requests as 
> I am not able to see any significant improvement by distributing write 
> requests among multiple nodes.
> 
> Thanking you.
> 
> 
> On May 12, 2014 2:39 PM, "Aaron Morton"  wrote:
>> On the homepage of libQtCassandra, its mentioned that switching between 
>> keyspaces is costly when storing into Cassandra thereby affecting the write 
>> throughput. Is this necessarily true for other libraries like pycassa and 
>> hector as well?
>> 
>> 
> When using the thrift connection the keyspace is a part of the connection 
> state, so changing keyspaces requires a round trip to the server. Not hugely 
> expensive, but it adds up if you do it a lot. 
> 
>> Can I increase the write throughput by configuring all the 
>> clients to store in a single keyspace instead of multiple keyspaces to 
>> increase the write throughput?
>> 
>> 
> You should expect to get 3,000 to 4,000 writes per core per node. 
> 
> What are you getting now?
> 
> Cheers
> A
> 
> -
> Aaron Morton
> New Zealand
> @aaronmorton
> 
> Co-Founder & Principal Consultant
> Apache Cassandra Consulting
> http://www.thelastpickle.com
> 
> On 11/05/2014, at 4:06 pm, Krishna Chaitanya  wrote:
> 
>> Hello,
>> I have an application that writes network packets to a Cassandra cluster 
>> from a number of client nodes. It uses the libQtCassandra library to access 
>> Cassandra. On the homepage of libQtCassandra, its mentioned that switching 
>> between keyspaces is costly when storing into Cassandra thereby affecting 
>> the write throughput. Is this necessarily true for other libraries like 
>> pycassa and hector as well?
>> Can I increase the write throughput by configuring all the 
>> clients to store in a single keyspace instead of multiple keyspaces to 
>> increase the write throughput?
>> 
>> Thankyou.
>> 
> 

Re: idempotent counters

[Aaron Morton]

> Does anybody else use another technique for achieving this idempotency with 
> counters?

The idempotency problem with counters has to do with what will happen when you 
get a timeout. If you reply the write there is a chance of the increment been 
applied twice. This is inherent in the current design. 

Cheers
Aaron 

  
-
Aaron Morton
New Zealand
@aaronmorton

Co-Founder & Principal Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com

On 9/05/2014, at 1:07 am, Jabbar Azam  wrote:

> Hello,
> 
> Do people use counters when they want to have idempotent operations in 
> cassandra?
> 
> I have a use case for using a counter to check for a count of objects in a 
> partition. If the counter is more than some value then the data in the 
> partition is moved into two different partitions. I can't work out how to do 
> this splitting and recover if a problem happens during modification of the 
> counter.
> 
> http://www.ebaytechblog.com/2012/08/14/cassandra-data-modeling-best-practices-part-2
>  explains that counters shouldn't be used if you want idempotency. I would 
> agree, but the alternative  is not very elegant. I would have to manully 
> count the objects in a partition and then move the data and repeat the 
> operation if something went wrong.
> 
> It is less resource intensive to read a counter value to see if a partition 
> needs splitting then to read all the objects in a partition. The counter 
> value can be stored in its own table sorting in descending order of the 
> counter value.
> 
> Does anybody else use another technique for achieving this idempotency with 
> counters?
> 
> I'm using cassandra 2.0.7.
> 
> 
> 
> Thanks
> 
> Jabbar Azam