Re: Cassandra data model right definition

[Russell Bradberry]

"X-store" refers to how data is stored, in almost every case it refers to
what logical constructs are grouped together physically on disk.  It has
nothing to do with whether a database is relational or not.

Cassandra does, in fact meet the definition of row-store, however, I would
like to re-iterate that it goes beyond that and stores all rows for a
single partition together on disk as well.  Therefore row-store does not do
it justice, which is why I like the term "Partitioned row-store"

On Mon, Oct 3, 2016 at 12:37 PM, Benedict Elliott Smith  wrote:

> ... and my response can be summed up as "you are not parsing English
> correctly."  The word "like" does not mean what you think it means in this
> context.  It does not mean "close relative."  It is constrained to the
> similarities expressed, and no others.  You don't seem to be reading any of
> my responses about this, though, so I'm not sure parsing is your issue.
>
> Postgresql has had arrays for years, and all RDBMS (pretty much) avoid
> persisting nulls in exactly the same way C* does - encoding their absence
> in the row header.
>
> I empathise with the recent unsubscriber.
>
>
>
> On 3 October 2016 at 15:53, Edward Capriolo  wrote:
>
>> My original point can be summed up as:
>>
>> Do not define cassandra in terms SMILES & METAPHORS. Such words include
>> "like" and "close relative".
>>
>> For the specifics:
>>
>> Any relational db could (and I'm sure one does!) allow for sparse fields
>> as well. MySQL can be backed by rocksdb now, does that make it not a row
>> store?
>>
>> Lets draw some lines, a relational database is clearly defined.
>>
>> https://en.wikipedia.org/wiki/Edgar_F._Codd
>>
>> Codd's theorem , a
>> result proven in his seminal work on the relational model, equates the
>> expressive power of relational algebra
>>  and relational
>> calculus  (both of
>> which, lacking recursion, are strictly less powerful thanfirst-order
>> logic ).[*citation
>> needed *]
>>
>> As the relational model started to become fashionable in the early 1980s,
>> Codd fought a sometimes bitter campaign to prevent the term being misused
>> by database vendors who had merely added a relational veneer to older
>> technology. As part of this campaign, he published his 12 rules
>>  to define what
>> constituted a relational database. This made his position in IBM
>> increasingly difficult, so he left to form his own consulting company with
>> Chris Date and others.
>>
>> Cassandra is not a relational database.
>>
>> I am have attempted to illustrate that a "row store" is defined as well.
>> I do not believe Cassandra is a "row store".
>>
>> "Just because it uses log structured storage, sparse fields, and
>> semi-flexible collections doesn't disqualify it from calling it a "row
>> store""
>>
>> What is the definition of "row store". Is it a logical construct or a
>> physical one?
>>
>> Why isn't mongo DB a "row store"? I can drop a schema on top of mongo and
>> present it as rows and columns. It seems to pass the litmus test being
>> presented.
>>
>> https://github.com/mongodb/mongo-hadoop/wiki/Hive-Usage
>>
>>
>>
>>
>>
>> On Mon, Oct 3, 2016 at 10:02 AM, Jonathan Haddad 
>> wrote:
>>
>>> Sorry Ed, but you're really stretching here. A table in Cassandra is
>>> structured by a schema with the data for each row stored together in each
>>> data file. Just because it uses log structured storage, sparse fields, and
>>> semi-flexible collections doesn't disqualify it from calling it a "row
>>> store"
>>>
>>> Postgres added flexible storage through hstore, I don't hear anyone
>>> arguing that it needs to be renamed.
>>>
>>> Any relational db could (and I'm sure one does!) allow for sparse fields
>>> as well. MySQL can be backed by rocksdb now, does that make it not a row
>>> store?
>>>
>>> You're arguing that everything is wrong but you're not proposing an
>>> alternative, which is not productive.
>>> On Mon, Oct 3, 2016 at 9:40 AM Edward Capriolo 
>>> wrote:
>>>
 Also every piece of techincal information that describes a rowstore

 http://cs-www.cs.yale.edu/homes/dna/talks/abadi-sigmod08-slides.pdf
 https://en.wikipedia.org/wiki/Column-oriented_DBMS#Row-oriented_systems

 Does it like this:

 001:10,Smith,Joe,4;
 002:12,Jones,Mary,5;
 003:11,Johnson,Cathy,44000;
 004:22,Jones,Bob,55000;



 The never depict a scenario where a the data looks like this on disk:

 001:10,Smith

 001:10,4;

 Which is much closer to how Cassandra *stores* it's data.



 On Fri, Sep 30, 2016 at 

Re: Cassandra data model right definition

[Russell Bradberry]

A couple things I would like to note:

1. Cassandra does not determine how data is stored on disk, the compaction
strategy does.  One could, in theory, (and I believe some are trying) could
create a column-store compaction strategy.  There is a large effort in the
database community overall to separate the query execution from the storage
engine, it is becoming increasingly more incorrect to say a database is an
"X store" database.

2. "X-store" is not used, and never has been, to describe how data is
represented or queried.  When most database storage engines describe their
storage as "X-store" they are referring to contiguous bytes on disk.  In
traditional rows-store engines, on a single node, the definition is as
follows: "All data for a row is stored as a single block of contiguous
bytes on disk".  Traditional column-stores are also defined as "All data
for a column is stored contiguously on disk".  Old-style Cassandra was a
key-value column-family store in that "all data for a family of columns
belonging to a given key were stored contiguously on disk"

So when talking about Cassandra and all currently merged compaction
strategies, yes, it fits the definition of a row-store in that "All data
for a row is stored as contiguous bytes on disk", however, it goes further
because "All data for all rows in a given partition are stored as
contiguous bytes on disk".  So at the highest level one could say it is a
"Partition-store" but that is pretty vague.   I think it is deserving of a
different naming definition which is why I like the term
"Partitioned-row-store"  which gives insight into the fact that it is rows
being stored on disk, in a partitioned format.

PS.
To address the pedants, yes, by these definitions you would have to assume
that a partition resides in a single SSTable. While most compaction
strategies try hard to achieve this it currently only exists in one that I
know. You could call it a
"Partitioned-row-depenendent-upon-compaction-strategy-store" but that is
just terrible.



On Mon, Oct 3, 2016 at 10:02 AM, Jonathan Haddad  wrote:

> Sorry Ed, but you're really stretching here. A table in Cassandra is
> structured by a schema with the data for each row stored together in each
> data file. Just because it uses log structured storage, sparse fields, and
> semi-flexible collections doesn't disqualify it from calling it a "row
> store"
>
> Postgres added flexible storage through hstore, I don't hear anyone
> arguing that it needs to be renamed.
>
> Any relational db could (and I'm sure one does!) allow for sparse fields
> as well. MySQL can be backed by rocksdb now, does that make it not a row
> store?
>
> You're arguing that everything is wrong but you're not proposing an
> alternative, which is not productive.
>
> On Mon, Oct 3, 2016 at 9:40 AM Edward Capriolo 
> wrote:
>
>> Also every piece of techincal information that describes a rowstore
>>
>> http://cs-www.cs.yale.edu/homes/dna/talks/abadi-sigmod08-slides.pdf
>> https://en.wikipedia.org/wiki/Column-oriented_DBMS#Row-oriented_systems
>>
>> Does it like this:
>>
>> 001:10,Smith,Joe,4;
>> 002:12,Jones,Mary,5;
>> 003:11,Johnson,Cathy,44000;
>> 004:22,Jones,Bob,55000;
>>
>>
>>
>> The never depict a scenario where a the data looks like this on disk:
>>
>> 001:10,Smith
>>
>> 001:10,4;
>>
>> Which is much closer to how Cassandra *stores* it's data.
>>
>>
>>
>> On Fri, Sep 30, 2016 at 5:12 PM, Benedict Elliott Smith <
>> bened...@apache.org> wrote:
>>
>> Absolutely.  A "partitioned row store" is exactly what I would call it.
>> As it happens, our README thinks the same, which is fantastic.
>>
>> I thought I'd take a look at the rest of our cohort, and didn't get far
>> before disappointment.  HBase literally calls itself a "*column-oriented* 
>> store"
>> - which is so totally wrong it's simultaneously hilarious and tragic.
>>
>> I guess we can't blame the wider internet for misunderstanding/misnaming
>> us poor "wide column stores" if even one of the major examples doesn't know
>> what it, itself, is!
>>
>>
>>
>>
>> On 30 September 2016 at 21:47, Jonathan Haddad  wrote:
>>
>> +1000 to what Benedict says. I usually call it a "partitioned row store"
>> which usually needs some extra explanation but is more accurate than
>> "column family" or whatever other thrift era terminology people still use.
>> On Fri, Sep 30, 2016 at 1:53 PM DuyHai Doan  wrote:
>>
>> I used to present Cassandra as a NoSQL datastore with "distributed"
>> table. This definition is closer to CQL and has some academic background
>> (distributed hash table).
>>
>>
>> On Fri, Sep 30, 2016 at 7:43 PM, Benedict Elliott Smith <
>> bened...@apache.org> wrote:
>>
>> Cassandra is not a "wide column store" anymore.  It has a schema.  Only
>> thrift users no longer think they have a schema (though they do), and
>> thrift is being deprecated.
>>
>> I really wish everyone would kill the term 

Re: Cassandra data model right definition

[Russell Bradberry]

I agree 100%, this misunderstanding really bothers me as well.  I like the term 
“Partitioned Row Store” even though I am guilty of using the legacy 
“Column-Family Store” from darker times.  Even databases like Scylla which is 
supposed to be an Apache Cassandra clone tout themselves as a column-store, 
which is just utterly backwards as you mentioned.

 

From: Benedict Elliott Smith 
Reply-To: 
Date: Friday, September 30, 2016 at 5:12 PM
To: 
Subject: Re: Cassandra data model right definition

 

Absolutely.  A "partitioned row store" is exactly what I would call it.  As it 
happens, our README thinks the same, which is fantastic.  

 

I thought I'd take a look at the rest of our cohort, and didn't get far before 
disappointment.  HBase literally calls itself a "column-oriented store" - which 
is so totally wrong it's simultaneously hilarious and tragic.  

 

I guess we can't blame the wider internet for misunderstanding/misnaming us 
poor "wide column stores" if even one of the major examples doesn't know what 
it, itself, is!

 

 

 

 

On 30 September 2016 at 21:47, Jonathan Haddad  wrote:

+1000 to what Benedict says. I usually call it a "partitioned row store" which 
usually needs some extra explanation but is more accurate than "column family" 
or whatever other thrift era terminology people still use. 

On Fri, Sep 30, 2016 at 1:53 PM DuyHai Doan  wrote:

I used to present Cassandra as a NoSQL datastore with "distributed" table. This 
definition is closer to CQL and has some academic background (distributed hash 
table).

 

 

On Fri, Sep 30, 2016 at 7:43 PM, Benedict Elliott Smith  
wrote:

Cassandra is not a "wide column store" anymore.  It has a schema.  Only thrift 
users no longer think they have a schema (though they do), and thrift is being 
deprecated.

 

I really wish everyone would kill the term "wide column store" with fire.  It 
seems to have never meant anything beyond "schema-less, row-oriented", and a 
"column store" means literally the opposite of this.

 

Not only that, but people don't even seem to realise the term "column store" 
existed long before "wide column store" and the latter is often abbreviated to 
the former, as here: http://www.planetcassandra.org/what-is-nosql/ 

 

Since it no longer applies, let's all agree as a community to forget this awful 
nomenclature ever existed.

 

 

 

On 30 September 2016 at 18:09, Joaquin Casares  
wrote:

Hi Mehdi,

 

I can help clarify a few things.

 

As Carlos said, Cassandra is a Wide Column Store. Theoretically a row can have 
2 billion columns, but in practice it shouldn't have more than 100 million 
columns.

 

Cassandra partitions data to certain nodes based on the partition key(s), but 
does provide the option of setting zero or more clustering keys. Together, the 
partition key(s) and clustering key(s) form the primary key.

 

When writing to Cassandra, you will need to provide the full primary key, 
however, when reading from Cassandra, you only need to provide the full 
partition key.

 

When you only provide the partition key for a read operation, you're able to 
return all columns that exist on that partition with low latency. These columns 
are displayed as "CQL rows" to make it easier to reason about.

 

Consider the schema:

 

CREATE TABLE foo (

  bar uuid,

  boz uuid,

  baz timeuuid,

  data1 text,

  data2 text,

  PRIMARY KEY ((bar, boz), baz)

);

 

When you write to Cassandra you will need to send bar, boz, and baz and 
optionally data*, if it's relevant for that CQL row. If you chose not to define 
a data* field for a particular CQL row, then nothing is stored nor allocated on 
disk. But I wouldn't consider that caveat to be "schema-less".

 

However, all writes to the same bar/boz will end up on the same Cassandra 
replica set (a configurable number of nodes) and be stored on the same place(s) 
on disk within the SSTable(s). And on disk, each field that's not a partition 
key is stored as a column, including clustering keys (this is optimized in 
Cassandra 3+, but now we're getting deep into internals).

 

In this way you can get fast responses for all activity for bar/boz either over 
time, or for a specific time, with roughly the same number of disk seeks, with 
varying lengths on the disk scans.

 

Hope that helps!


Joaquin Casares

Consultant

Austin, TX

 

Apache Cassandra Consulting

http://www.thelastpickle.com

 

On Fri, Sep 30, 2016 at 11:40 AM, Carlos Alonso  wrote:

Cassandra is a Wide Column Store http://db-engines.com/en/system/Cassandra


Carlos Alonso | Software Engineer | @calonso

 

On 30 September 2016 at 18:24, Mehdi Bada  wrote:

Hi all, 

 

I have a theoritical question: 

- Is Apache Cassandra really a column store?

Column store mean storing the data 

Re: unsubscibe

[Russell Bradberry]

While there is an informative email when you sign up, there are a couple issues 
with it. First, as you said, people don't read instructions. Second, people 
forget. I would have to search back to when I signed up for the list in order 
to find how to unsubscribe. Lastly, gmail and many other apps provide a button 
that says "unsubscribe" which does little more than send an email to the list. 
The latter is the reason I am suggesting that this be worked in as an 
additional way to unsubscribe from the list.





On Sat, Aug 13, 2016 at 8:39 PM -0400, "James Carman" 
<ja...@carmanconsulting.com> wrote:










I see the confusion on quite a few lists around the organization.  It's not 
rampant, but it does happen.  Perhaps it would be a good idea to improve the 
communication somehow.  When you first subscribe, you get a pretty informative 
email describing all of the things you can do via email, but who reads 
instructions?!?! :). I wonder if infra could force a footer on the emails or 
something.  
On Sat, Aug 13, 2016 at 8:35 PM Russell Bradberry <rbradbe...@gmail.com> wrote:

I think the overall issue here is that there are many apps that 
provide an "unsubscribe" button that automagically sends these emails.
I think the best course of action would be to bring this up to the powers that 
be to possibly decide on supporting this functionality as a feature. This, of 
course, because this method of unsubscribing from lists is pretty much standard 
now.
Im not sure the patronizing responses with Google links help at all.



_
From: James Carman <ja...@carmanconsulting.com>
Sent: Saturday, August 13, 2016 8:24 PM
Subject: Re: unsubscibe
To:  <user@cassandra.apache.org>


Was the Google stuff really necessary? Couldn't you have just nicely told them 
how to unsubscribe?
On Sat, Aug 13, 2016 at 7:52 PM Alain RODRIGUEZ <arodr...@gmail.com> wrote:
Hi,

You did not unsubscribe yet.
'unsubscribe cassandra' in google search:

Result 1: http://www.planetcassandra.org/apache-cassandra-mailing-lists/Result 
2: http://mail-archives.apache.org/mod_mbox/cassandra-user/Result 3: 
http://cassandra.apache.org/
Sending a message to user-unsubscr...@cassandra.apache.org, as mentioned 
everywhere, should work better and spam less people.
Alain
2016-08-13 23:32 GMT+02:00 Lawrence Turcotte <lawrence.turco...@gmail.com>:

Re: unsubscibe

[Russell Bradberry]

I think the overall issue here is that there are many apps that provide an 
"unsubscribe" button that automagically sends these emails.
I think the best course of action would be to bring this up to the powers that 
be to possibly decide on supporting this functionality as a feature. This, of 
course, because this method of unsubscribing from lists is pretty much standard 
now.
Im not sure the patronizing responses with Google links help at all.



_
From: James Carman 
Sent: Saturday, August 13, 2016 8:24 PM
Subject: Re: unsubscibe
To:  


Was the Google stuff really necessary? Couldn't you have just nicely told them 
how to unsubscribe?
On Sat, Aug 13, 2016 at 7:52 PM Alain RODRIGUEZ  wrote:
Hi,

You did not unsubscribe yet.
'unsubscribe cassandra' in google search:

Result 1: http://www.planetcassandra.org/apache-cassandra-mailing-lists/Result 
2: http://mail-archives.apache.org/mod_mbox/cassandra-user/Result 3: 
http://cassandra.apache.org/
Sending a message to user-unsubscr...@cassandra.apache.org, as mentioned 
everywhere, should work better and spam less people.
Alain
2016-08-13 23:32 GMT+02:00 Lawrence Turcotte :

Re: Decommissioned node shows up in the gossip log

[Russell Bradberry]

The impact is that it is still in gossip and may still be in your peers.  Node 
tool status pulls from the snitch, not gossip, so since it was decommissioned 
it will not show up there.  The only way to remove it from gossip would be to 
unsafeAssasinate the endpoint.

From:  "Zhang, Charles" 
Reply-To:  
Date:  Tuesday, May 3, 2016 at 1:09 PM
To:  "user@cassandra.apache.org" 
Subject:  Decommissioned node shows up in the gossip log

I decommissioned a seed node from the cluster but now it still shows up in the 
log files but does not show up in “nodetool status”. The steps I took to 
decommission this seed node was first I added another node to the seed node 
list and remove this node from the seed node list and then restarted all nodes, 
and then I used “nodetool decommission” to remove the seed node (which is 
already not a seed node anymore by this time because I have deleted it from the 
seed node list). Now when I add a node to the cluster, I can see things like 
this in the log file:

 

INFO  [GossipStage:1] 2016-05-03 12:47:11,010 Gossiper.java:1010 - InetAddress 
/10.240.131.52 is now DOWN

INFO  [GossipStage:1] 2016-05-03 12:47:11,013 StorageService.java:2207 - 
Removing tokens [-1022524973634126820, -1080110197540691971, 
-1091685779109535219, -1215861550002479909, -1230125663037298110, 
-1276347863826680388, -1277321492456111075, -1301927496688170836, 
-1318545134739242389, -1322771136875660408, -1378340458058304278, 
-1408100110415631237, -1530631940375897404, -1535071782926085329, 
-1582947345179885144, -16012799486150337, -1696192817763838199, 
-1728191989986713155, -1745583338734596530, -1826663257009694585, 
-1851642471126916817, -1857538886064358546, -1901715377875763790, 
-1932177981591882421, -199072269576364247, -207608666599084705, 
-2184481684522309754, -2204020999427045206, -2205085893777233579, 
-2270561486823228034, -2308298192046286704, -235429323779874179, 
-2463024446587312335, -2495920187667193798, -2500756743826875052, 
-2506627651269234078, -2514401267607374003, -2545039589436377179, 
-2634503648039799520, -2646537028163124225, -2683738978574645155, 
-2807184187110003759, -2867402698030280784, -3114050892122318894, 
-3206044372292017688, -3281321558107483648, -3385749857713245200, 
-3416161302882661647, -3506129882816214786, -3513065641380195991, 
-3535041040510847711, -3613958158418786329, -3648155032806486758, 
-3665748511643959214, -381185030151387503, -3897484925082811126, 
-3938608392271975389, -3941659677176701884, -3947462638823321096, 
-4000556449482859203, -4110196499985462141, -4158458444329621178, 
-4227086524280114158, -4243909747517318822, -4280784900694217230, 
-4404716672756332652, -4455430621398252312, -4538061491874241556, 
-4572589909790935797, -4850346756544186378, -4952456886854152424, 
-5084536945116622949, -5326752651357993429, -5349130774372022115, 
-5460653359296793773, -5620302193040734534, -5623709120594154839, 
-5885389525591890638, -5949589155008107907, -5966013525235445845, 
-6026141079407570616, -6058868359575464435, -6077630467595631247, 
-6077845078374374077, -6138431646664499820, -6180882520195395456, 
-6243210077810081945, -6370284996672456580, -6415049304495129802, 
-6502707320839506073, -6803145485914681660, -6805877741054487708, 
-6926104547940671062, -6951403149841557452, -6953035076415327031, 
-6967464526766340870, -7011060314535843861, -7064863849614017322, 
-714981435304170064, -7157502981616220702, -7258779025703812914, 
-7360270914479075946, -73610861802671316, -7563240572942157514, 
-7635081293483408701, -7798006211363305085, -7813955538719900941, 
-786373677098356483, -8145051135140174940, -8176945151026682869, 
-8190382813904504028, -8272254174290282022, -8326684320313230680, 
-8481234483187517136, -8482289498657787899, -8565844176707815996, 
-8569487821947184157, -8798368038472556220, -8809438431651729380, 
-8813359577419549606, -8869977551074344265, -8895973234315752820, 
-8907908280791280135, -8908127052185996645, -8935928854496370061, 
-9015683177087077934, -9048056285157467189, -9110697723266307118, 
-981226497198399669, 1193342841401851448, 1230054248428394457, 
1502987728312107227, 1637579501555626797, 1662468220619718905, 
1679119062145242310, 1716958612112885132, 174640545268100, 
1831765078257867905, 1837630369692254413, 1866757535234365933, 
1980430493801992453, 2162782596967223630, 2267937126038851741, 
2380570386757196663, 2445644030436787439, 2470624736744405884, 
2535946784572437079, 2586884334596326732, 261609565442228971, 
2807653039695258495, 2820914298989266652, 2850900328012773185, 
2856965311103931071, 2878299073894089909, 293663570529846026, 
2956982251255851218, 3004636240207923383, 3101507369252962007, 
3127101442974941655, 3158812977721178300, 3171231578612039887, 
3195192564355682313, 3336607934515052432, 3343357098855461268, 
3353820331372189514, 34251354331737275, 3436913366576384630, 
3548175524364212676, 

Re: apache cassandra for trading system

[Russell Bradberry]

One option could be to set up two data centers and have two separate keyspaces, 
one for today data and the other for historical data.

You can write to the today_data keyspace with a TTL of 24 hours then write the 
same data to the historical_data keyspace. You then set up your replication to 
have the today_data keyspace only replicate to the host with the trading 
application then have the historical_data only replicate to the two node 
cluster.

From:  Vero Kato 
Reply-To:  
Date:  Friday, March 25, 2016 at 2:09 PM
To:  
Subject:  apache cassandra for trading system

hi, we are building trading system and we want to use cassandra as our 
database. 
we want this set-up: 
one node which stored one day set of data which will be running on the same 
host as trading application
two nodes which store all data (for the current date and historical) which will 
be running on other boxes. 

can you please suggest how easily it will be to have this set-up? i.e. we have 
three nodes, but one of them (on the same box where our app located) will be 
discarding all historical data which are older than one day?


thanks

Re: Cassandra DSE Solr - search JSON content in column

[Russell Bradberry]

You can use the full text wildcard search as mentioned. However, if you need 
something more specific like certain fields in the JSON indexed, you can use 
DSE SOLR field transformers.  
http://www.datastax.com/dev/blog/dse-field-transformers

From:  DuyHai Doan 
Reply-To:  
Date:  Wednesday, January 13, 2016 at 9:10 AM
To:  
Subject:  Re: Cassandra DSE Solr - search JSON content in column

Try

SELECT * FROM your_table WHERE solr_query='json:"*100 ABC Street*"'; 

Warning: since you're storing in JSON format, searching data inside a JSON is 
equivalent to a wildcard seach *xxx* and it is quite expensive, even for full 
text search engines like Solr

On Wed, Jan 13, 2016 at 2:50 PM, Joseph Tech  wrote:
Hi,

Is it possible in DSE Cassandra Solr to search for JSON content within a 
column? 
We store a complex JSON in a column of type "text", very simplified version 
below.

{
"userId": "user100",
"addressList": [{
"addressId": "100",
"address": "100 ABC Street"
}],
"userName": "user11"
}

In this, can search return all records that have address="100 ABC Street" ? 

Thanks,
Joseph

Re: INSERT JSON TimeStamp

[Russell Bradberry]

That is not a valid date in CQL, and JSON does not enforce a specific date 
format.  A correctly formatted date would look something like “2015-01-01 
00:00:00”. 

From:  Ashish Soni
Reply-To:  
Date:  Monday, September 28, 2015 at 3:51 PM
To:  
Subject:  INSERT JSON TimeStamp

If Anyone can help for below as i am getting the error

effectiveStartDate and effectiveEndDate are TimeStamp

INSERT INTO model.RuleSetSchedule JSON ' {
"ruleSetName": "BOSTONRATES",
"ruleSetId": "829aa84a-4bba-411f-a4fb-38167a987cda",
"scheduleId":1,
"effectiveStartDate": "01/01/2015",
"effectiveEndDate": "12/31/2015",
"rules": {
"1": {
"condition": "BoardStation",
"action": "FareAmount=9.25",
"ruleOrder": "1"
}
}

message="Error decoding JSON value for effectivestartdate: Unable to coerce 
'01/01/2015' to a formatted date (long)"

Re: INSERT JSON TimeStamp

[Russell Bradberry]

You escape single quotes by doubling them. 

Eg:

  "condition": "BoardStation ==''Lowell'' ",

That is not double quotes arounf ‘lowel’ but in-fact 4 single-quotes, 2 before 
and 2 after


From:  Ashish Soni
Reply-To:  <user@cassandra.apache.org>
Date:  Monday, September 28, 2015 at 4:32 PM
To:  <user@cassandra.apache.org>
Subject:  Re: INSERT JSON TimeStamp

Thanks a Lot , Also i have single quote in JSON but CQL Doesnt Like it even 
when i escape it 
  "condition": "BoardStation =='Lowell' ",

i tried 

  "condition": "BoardStation ==\'Lowell\' ",

INSERT INTO model.RuleSetSchedule JSON ' {
"ruleSetName": "BOSTONRATES",
"ruleSetId": "829aa84b-4bba-411f-a4fb-38167a987cda",
"scheduleId":1,
"effectiveStartDate": "2015-02-01 00:00:00",
"effectiveEndDate": "2015-03-01 00:00:00",
"rules": {
"1": {
"condition": "BoardStation =='Lowell' ",
"action": "FareAmount=9.25",
"ruleOrder": "1"
}

}
}';

On Mon, Sep 28, 2015 at 4:11 PM, Steve Robenalt <sroben...@highwire.org> wrote:
Hi Ashish,

Most Json parsers expect either a raw long integer value or some version of an 
iso-8601 date or timestamp.

See https://en.wikipedia.org/wiki/ISO_8601 for a good reference.

Steve


On Mon, Sep 28, 2015 at 1:08 PM, Russell Bradberry <rbradbe...@gmail.com> wrote:
That is not a valid date in CQL, and JSON does not enforce a specific date 
format.  A correctly formatted date would look something like “2015-01-01 
00:00:00”. 

From:  Ashish Soni
Reply-To:  <user@cassandra.apache.org>
Date:  Monday, September 28, 2015 at 3:51 PM
To:  <user@cassandra.apache.org>
Subject:  INSERT JSON TimeStamp

If Anyone can help for below as i am getting the error

effectiveStartDate and effectiveEndDate are TimeStamp

INSERT INTO model.RuleSetSchedule JSON ' {
"ruleSetName": "BOSTONRATES",
"ruleSetId": "829aa84a-4bba-411f-a4fb-38167a987cda",
"scheduleId":1,
"effectiveStartDate": "01/01/2015",
"effectiveEndDate": "12/31/2015",
"rules": {
"1": {
"condition": "BoardStation",
"action": "FareAmount=9.25",
"ruleOrder": "1"
}
}

message="Error decoding JSON value for effectivestartdate: Unable to coerce 
'01/01/2015' to a formatted date (long)"



-- 
Steve Robenalt 
Software Architect
sroben...@highwire.org 
(office/cell): 916-505-1785

HighWire Press, Inc.
425 Broadway St, Redwood City, CA 94063
www.highwire.org

Technology for Scholarly Communication

Re: Cassandra Summit 2015 Roll Call!

[Russell Bradberry]

I will be wearing a red t-shirt that says SimpleReach and I will be at the
reception tonight, the MVP dinner and the summit both days.  I'm about
5'11" and probably going to be the best looking person there. ;)

See you all at the summit.

On Tue, Sep 22, 2015 at 11:27 AM, Robert Coli  wrote:

> Cassandra Summit 2015 is upon us!
>
> Every year, the conference gets bigger and bigger, and the chance of IRL
> meeting people you've "met" online gets smaller and smaller.
>
> To improve everyone's chances, if you are attending the summit :
>
> 1) respond on-thread with a brief introduction (and physical description
> of yourself if you want others to be able to spot you!)
> 2) join #cassandra on freenode IRC (irc.freenode.org) to chat and connect
> with other attendees!
>
> MY CONTRIBUTION :
> --
> I will be at the summit on Wednesday and Thursday. I am 5'8" or so, and
> will be wearing glasses and either a red or blue "Eventbrite Engineering"
> t-shirt with a graphic logo of gears on it. Come say hello! :D
>
> =Rob
>
>

Re: Configuring Cassandra to limit number of columns to read

[Russell Bradberry]

The idea that you have 250k columns is somewhat of an anti-pattern.  In this 
case you would typically have a few columns and many rows, then just run a 
select with a limit clause in your partition.

From:  Jonathan Haddad
Reply-To:  user@cassandra.apache.org
Date:  Friday, August 14, 2015 at 2:16 PM
To:  user@cassandra.apache.org
Subject:  Re: Configuring Cassandra to limit number of columns to read

250k columns?As in, you have a CREATE TABLE statement that would have over 
250K separate, typed fields?

On Fri, Aug 14, 2015 at 11:07 AM Ahmed  Ferdous ahmed.ferd...@ze.com wrote:
Hi Guys,

 

We have designed a table to have rows with large number of columns (more than 
250k). One of my colleagues, mistakenly ran a select on the  and that caused 
the nodes to go out of memory. I was just wondering if there are ways to 
configure Cassandra 1. To limit number of columns that can be read 2. To 
gracefully reject a read request if it appears to be consuming a lot of memory. 
Otherwise, we are leaving too much open to human mistakes.

 

Cheers,

 

Ahmed

 

Ahmed Ferdous
Systems Architect
Corporate: 604-244-1469 Email: ahmed.ferd...@ze.com


ZE PowerGroup Inc.
130 - 5920 No. Two Road, Richmond, BC, Canada V7C 4R9 Web: www.ze.com
North America: 1-866-944-1469  Europe: 0-800-520-0193   Singapore: 
800-130-1609

ZE PowerGroup Inc. Confidentiality Notice: This e-mail and any attachments are 
for the exclusive and confidential use of the intended recipient and contain 
confidential and proprietary information. If you are not the intended 
recipient, be aware that any reading, distribution, disclosure, copying, 
printing or taking action in reliance upon this e-mail is prohibited. If you 
have received this in error, please notify us immediately by replying to this 
e-mail and promptly delete this e-mail and its attachments from your computer 
system.

Re: only grant select , but still can modify data

[Russell Bradberry]

Did you set your authorizer correctly?

http://docs.datastax.com/en/cassandra/1.2/cassandra/security/secure_config_native_authorize_t.html

-Russ

From:  Dan Jatnieks
Reply-To:  user@cassandra.apache.org
Date:  Wednesday, August 5, 2015 at 5:03 PM
To:  user@cassandra.apache.org
Subject:  Re: only grant select , but still can modify data

Hi Rock,

I was not able to reproduce this problem using C* 2.2 and DevCenter 1.4. What 
versions are you using? Did you check that the DevCenter connection properties 
are using the readonly account and that any existing connection was closed 
and re-opened? Did you get the expected result with cqlsh?

dan


On Mon, Aug 3, 2015 at 7:12 PM, rock zhang r...@alohar.com wrote:
Hi All,

I want to create a readonly account, so i run the following command following: 
http://docs.datastax.com/en/cassandra/1.2/cassandra/security/security_config_native_authenticate_t.html

CREATE USER readonly WITH PASSWORD ''  ;

GRANT SELECT ON ALL KEYSPACES TO readonly;

Then I login DevCenter  with readonly account , i still can modify the data, 
anyone knows why ?  Many thanks.

I set keyspace system_auth replica as 6 since i have 6 nodes. 


Thanks
Rock 



-- 
Dan Jatnieks
Software Engineer | d...@datastax.com


 

Re: Regarding JIRA

[Russell Bradberry]

Also, feel free to use any of the many other resources available.

The Documentation
Planet Cassandra
Stack Overflow
#cassandra on irc.freenode.net



From:  Daniel Compton
Reply-To:  user@cassandra.apache.org
Date:  Monday, June 1, 2015 at 3:37 PM
To:  user@cassandra.apache.org
Subject:  Re: Regarding JIRA

Hi Kiran

There's no charges for raising issues in the Apache Cassandra JIRA or emailing 
the list. However as I'm sure you're aware, members of this list and on JIRA 
are mostly volunteers, so there's also no guarantee of support or response time.

--
Daniel.

On Tue, Jun 2, 2015 at 7:32 AM Kiran mk coolkiran2...@gmail.com wrote:
Hi ,

I am using Apache Cassandra Community Edition for my learning and practicing, 
can I raise the doubts,issues and clarifications using JIRA ticket against 
Cassandra. 

Will there be any charges for that.  As I know we can create free JIRA account, 
 

Can anyone suggest me on this.


-- 
Best Regards,
Kiran.M.K.

Re: Can a Cassandra node accept writes while being repaired

[Russell Bradberry]

Yes






On Thu, May 7, 2015 at 9:53 AM -0700, Khaja, Raziuddin (NIH/NLM/NCBI) [C] 
raziuddin.kh...@nih.gov wrote:










I was not able to find a conclusive answer to this question on the internet so 
I am asking this question here.
Is a Cassandra node able to accept insert or delete operations while the node 
is being repaired?
Thanks
-Razi

Re: Connecting to Cassandra cluster in AWS from local network

[Russell Bradberry]

I would like to note that this will require all clients connect over the 
external IP address. If you have clients within Amazon that need to connect 
over the private IP address, this would not be possible.  If you have a mix of 
clients that need to connect over private IP address and public, then one of 
the solutions outlined in https://datastax-oss.atlassian.net/browse/JAVA-145 
may be more appropriate.

-Russ

From:  Alex Popescu
Reply-To:  user@cassandra.apache.org
Date:  Monday, April 20, 2015 at 2:00 PM
To:  user
Subject:  Re: Connecting to Cassandra cluster in AWS from local network

You'll have to configure your nodes to:

1. use AWS internal IPs for inter-node connection (check listen_address) and 
2. use the AWS public IP for client-to-node connections (check rpc_address)

Depending on the setup, there might be other interesting conf options in 
cassandra.yaml (broadcast_address, listen_interface, rpc_interface).

[1]: 
http://docs.datastax.com/en/cassandra/2.1/cassandra/configuration/configCassandra_yaml_r.html

On Mon, Apr 20, 2015 at 9:50 AM, Jonathan Haddad j...@jonhaddad.com wrote:
Ideally you'll be on the same network, but if you can't be, you'll need to use 
the public ip in listen_address.

On Mon, Apr 20, 2015 at 9:47 AM Matthew Johnson matt.john...@algomi.com wrote:
Hi all,

 

I have set up a Cassandra cluster with 2.1.4 on some existing AWS boxes, just 
as a POC. Cassandra servers connect to each other over their internal AWS IP 
addresses (172.x.x.x) aliased in /etc/hosts as sales1, sales2 and sales3.

 

I connect to it from my local dev environment using the seed’s external NAT 
address (54.x.x.x) aliases in my Windows hosts file as sales3 (my seed).

 

When I try to connect, it connects fine, and can retrieve some data (I have 
very limited amounts of data in there, but it seems to retrieve ok), but I also 
get lots of stacktraces in my log where my dev environment is trying to connect 
to Cassandra on the internal IP (presumably the Cassandra seed node tells my 
dev env where to look):

 

 

INFO  2015-04-20 16:34:14,808 [CASSANDRA-CLIENT] {main} Cluster - New Cassandra 
host sales3/54.x.x.142:9042 added

INFO  2015-04-20 16:34:14,808 [CASSANDRA-CLIENT] {main} Cluster - New Cassandra 
host /172.x.x.237:9042 added

INFO  2015-04-20 16:34:14,808 [CASSANDRA-CLIENT] {main} Cluster - New Cassandra 
host /172.x.x.170:9042 added

Connected to cluster: Test Cluster

Datatacenter: datacenter1; Host: /172.x.x.170; Rack: rack1

Datatacenter: datacenter1; Host: sales3/54.x.x.142; Rack: rack1

Datatacenter: datacenter1; Host: /172.x.x.237; Rack: rack1

DEBUG 2015-04-20 16:34:14,901 [CASSANDRA-CLIENT] {Cassandra Java Driver 
worker-0} Connection - Connection[sales3/54.x.x.142:9042-2, inFlight=0, 
closed=false] Transport initialized and ready

DEBUG 2015-04-20 16:34:14,901 [CASSANDRA-CLIENT] {Cassandra Java Driver 
worker-0} Session - Added connection pool for sales3/54.x.x.142:9042

DEBUG 2015-04-20 16:34:19,850 [CASSANDRA-CLIENT] {Cassandra Java Driver 
worker-1} Connection - Connection[/172.x.x.237:9042-1, inFlight=0, 
closed=false] Error connecting to /172.x.x.237:9042 (connection timed out: 
/172.x.x.237:9042)

DEBUG 2015-04-20 16:34:19,850 [CASSANDRA-CLIENT] {Cassandra Java Driver 
worker-1} Connection - Defuncting connection to /172.x.x.237:9042

com.datastax.driver.core.TransportException: [/172.x.x.237:9042] Cannot connect

 

 

Does anyone have any experience with connecting to AWS clusters from dev 
machines? How have you set up your aliases to get around this issue?

 

Current setup in sales3 (seed node) cassandra.yaml:

 

- seeds: sales3

listen_address: sales3

rpc_address: sales3

 

Current setup in other nodes (eg sales2) cassandra.yaml:

 

- seeds: sales3

listen_address: sales2

rpc_address: sales2

 

 

Thanks!

Matt

 



-- 
Bests,

Alex Popescu | @al3xandru
Sen. Product Manager @ DataStax

Re: Connecting to Cassandra cluster in AWS from local network

[Russell Bradberry]

There are a couple options here. You can use the built in address translator, 
or, write a new load balancing policy.  See 
https://datastax-oss.atlassian.net/browse/JAVA-145 for more information.

From:  Jonathan Haddad
Reply-To:  user@cassandra.apache.org
Date:  Monday, April 20, 2015 at 12:50 PM
To:  user@cassandra.apache.org
Subject:  Re: Connecting to Cassandra cluster in AWS from local network

Ideally you'll be on the same network, but if you can't be, you'll need to use 
the public ip in listen_address.

On Mon, Apr 20, 2015 at 9:47 AM Matthew Johnson matt.john...@algomi.com wrote:
Hi all,

 

I have set up a Cassandra cluster with 2.1.4 on some existing AWS boxes, just 
as a POC. Cassandra servers connect to each other over their internal AWS IP 
addresses (172.x.x.x) aliased in /etc/hosts as sales1, sales2 and sales3.

 

I connect to it from my local dev environment using the seed’s external NAT 
address (54.x.x.x) aliases in my Windows hosts file as sales3 (my seed).

 

When I try to connect, it connects fine, and can retrieve some data (I have 
very limited amounts of data in there, but it seems to retrieve ok), but I also 
get lots of stacktraces in my log where my dev environment is trying to connect 
to Cassandra on the internal IP (presumably the Cassandra seed node tells my 
dev env where to look):

 

 

INFO  2015-04-20 16:34:14,808 [CASSANDRA-CLIENT] {main} Cluster - New Cassandra 
host sales3/54.x.x.142:9042 added

INFO  2015-04-20 16:34:14,808 [CASSANDRA-CLIENT] {main} Cluster - New Cassandra 
host /172.x.x.237:9042 added

INFO  2015-04-20 16:34:14,808 [CASSANDRA-CLIENT] {main} Cluster - New Cassandra 
host /172.x.x.170:9042 added

Connected to cluster: Test Cluster

Datatacenter: datacenter1; Host: /172.x.x.170; Rack: rack1

Datatacenter: datacenter1; Host: sales3/54.x.x.142; Rack: rack1

Datatacenter: datacenter1; Host: /172.x.x.237; Rack: rack1

DEBUG 2015-04-20 16:34:14,901 [CASSANDRA-CLIENT] {Cassandra Java Driver 
worker-0} Connection - Connection[sales3/54.x.x.142:9042-2, inFlight=0, 
closed=false] Transport initialized and ready

DEBUG 2015-04-20 16:34:14,901 [CASSANDRA-CLIENT] {Cassandra Java Driver 
worker-0} Session - Added connection pool for sales3/54.x.x.142:9042

DEBUG 2015-04-20 16:34:19,850 [CASSANDRA-CLIENT] {Cassandra Java Driver 
worker-1} Connection - Connection[/172.x.x.237:9042-1, inFlight=0, 
closed=false] Error connecting to /172.x.x.237:9042 (connection timed out: 
/172.x.x.237:9042)

DEBUG 2015-04-20 16:34:19,850 [CASSANDRA-CLIENT] {Cassandra Java Driver 
worker-1} Connection - Defuncting connection to /172.x.x.237:9042

com.datastax.driver.core.TransportException: [/172.x.x.237:9042] Cannot connect

 

 

Does anyone have any experience with connecting to AWS clusters from dev 
machines? How have you set up your aliases to get around this issue?

 

Current setup in sales3 (seed node) cassandra.yaml:

 

- seeds: sales3

listen_address: sales3

rpc_address: sales3

 

Current setup in other nodes (eg sales2) cassandra.yaml:

 

- seeds: sales3

listen_address: sales2

rpc_address: sales2

 

 

Thanks!

Matt

 

Re: Bitmaps

[Russell Bradberry]

I highly recommend against storing data structures like this in C*. That
really isn't it's sweet spot.  For instance, if you were to use the blob
type which will give you the smallest size, you are still looking at a cell
size of (90,000,000/8/1024) = 10,986 or over 10MB in size, which is
prohibitively large.

Additionally, there is no way to modify the bitmap in place, you would have
to read the entire structure out and write it back in.

You could store one bit per cell, but that would essentially defeat the
purpose of the bitmap's compact size.

On Mon, Oct 6, 2014 at 4:46 PM, Eduardo Cusa 
eduardo.c...@usmediaconsulting.com wrote:

 Hi Guys, what data type recommend to store bitmaps?
 I am planning to store maps of 90,000,000 length and then query by key.

 Example:

 key : 22_ES
 bitmap : 10101101010111010101011



 Thanks
 Eduardo

Re: hardware sizing for cassandra

[Russell Bradberry]

*TL;DR*

There is no one recommended setup for Cassandra, everyone's use-case is
different and it is up to you to figure out the best setup for your
use-case. There are a lot of questions that need to be asked before making
a decision on hardware layout.



There is just so much wrong with this, it's hard to find where to begin. It
seems you are giving advice based on a specific use-case and not even one
that would necessarily match the case of the original poster.


Every node should have at least 4 cores


While more cores the better, there is no minimum recommended number of
cores. It depends solely on your use-case. We ran dual core machines in
production successfully for over a year.

with a maximum of 8


No. The more cores the better, period.  Especially if you are running SSD.
 I have yet to see a machine max out IOPS on an SSD drive, the context
switches end up becoming the bottleneck here.

Memory shouldn't be higher than 32g


I have no idea where you are getting this.  I have seen people running
nodes with 256GB of ram, simply because they want as much or all of their
data to be memory resident.  If you are running spindles you are lucky to
get 50ms response times on average, if it is memory resident you can get as
low as 2-5ms response times.

16gb is good for a start


16GB is recommended simply because the max JVM heap you want to run is 8GB
and this leaves 8GB for other system and Cassandra related things.  You
could go as low as 12 if you have a low workload and nothing else on the
machine.

Every node should be a phisical machine, not a virtual one, or at least a
 virtual machine with an ssd hd subsystem.


I have no idea where you are getting this. Cassandra has no problem running
on VM's as long as the disks aren't shared.  Many, people including
Netflix, which has one of the largest Cassandra deployments, are running in
Amazon which is VM.

The disk subsystem should be directly connected to the machine, no sans or
 fiber channel between.


Again, this is highly dependent on hardware. If you are running iSCSI and
your disks are dedicated and you have enough available IOPS to spare, you
will be fine.  I recently benchmarked 1TB EBS SSD drives in Amazon against
Ephemeral SSD drives with little noticeable difference.

 Cassandra is cpu and io bounded, so you should get the maximum io speed
 and a reasonable number of cores.


Cassandra is I/O bound only when running spindle disks, it becomes
context-switch bound when running SSD drives. I have tried many times to
max out the SSD IOPS without ever becoming able to.

Number of nodes should be 3 at least with replication factor of 2.


The recommended setup is 3 nodes and an RF of 3 to be able to make quorum
reads/writes and survive an outage. But again, this is completely use-case
dependent.

 You should prefer more less powerful nodes then fewer more powerful nodes.


Finally, something we can agree on

 Disk size depends on your workload, although you should always keep 50% of
 the disk free in the case repair sessions requires space, or perform sub
 range repairs.


Only if you are running STCS, if your are running LCS you can use much more
than 50% of your available space.



On Tue, Sep 9, 2014 at 12:52 PM, Paolo Crosato 
paolo.cros...@targaubiest.com wrote:

 Every node should have at least 4 cores, with a maximum of 8. Memory
 shouldn't be higher than 32g, 16gb is good for a start. Every node should
 be a phisical machine, not a virtual one, or at least a virtual machine
 with an ssd hd subsystem. The disk subsystem should be directly connected
 to the machine, no sans or fiber channel between. Cassandra is cpu and io
 bounded, so you should get the maximum io speed and a reasonable number of
 cores.

 Number of nodes should be 3 at least with replication factor of 2. You
 should prefer more less powerful nodes then fewer more powerful nodes.

 Disk size depends on your workload, although you should always keep 50% of
 the disk free in the case repair sessions requires space, or perform sub
 range repairs.

 In my experience a 1GB link between nodes is ok, but the less lag the
 better.

 Summing up if you need to save some money, get 4 cores and 16 gb or ram,
 32 is rarely needed and 64 a waste. 8 cores would probably be too much with
 1000 writes a second.

 Paolo



 
 Paolo Crosato
 Software engineer/Custom Solutions


 
 Da: Chris Lohfink clohf...@blackbirdit.com
 Inviato: martedì 9 settembre 2014 21.26
 A: user@cassandra.apache.org
 Oggetto: Re: hardware sizing for cassandra

 It depends.  Ultimately your load is low enough a single node can probably
 handle it so you kinda want a minimum cluster.  Different people have
 different thoughts on what this means - I would recommend 5-6 nodes with a
 3 replication factor.  (say m1.xlarge, or c3.2xlarge striped ephemerals, I
 like i2's 

Re: hardware sizing for cassandra

[Russell Bradberry]

 Because RAM is expensive and the JVM heap is limited to 8gb. While you do
 get benefit out of using extra RAM as page cache, it's often not cost
 efficient to do so


Again, this is so use-case dependent. I have met several people that run
small nodes with fat ram to get it all in memory to serve things in as few
milliseconds as possible.  This is a very common pattern in ad-tech where
every millisecond counts.  The tunable consistency and cross-datacenter
replication make Cassandra very appealing as it is difficult to set this up
with other DBs.

On Tue, Sep 9, 2014 at 2:12 PM, Robert Coli rc...@eventbrite.com wrote:

 On Tue, Sep 9, 2014 at 1:07 PM, Rahul Neelakantan ra...@rahul.be wrote:

 Why not more than 32gb of RAM/node?


 Because RAM is expensive and the JVM heap is limited to 8gb. While you do
 get benefit out of using extra RAM as page cache, it's often not cost
 efficient to do so.

 =Rob

Re: MapReduce Integration?

[Russell Bradberry]

If you want true integration of Cassandra and Hadoop and Spark then you will 
need to use Datastax Enterprise (DSE).  There are connectors that will allow 
MapReduce over vanilla Cassandra, however, they are just making requests to 
Cassandra under the covers while DSE uses CFS which is similar to HDFS.



On August 26, 2014 at 9:23:38 AM, Oliver Ruebenacker (cur...@gmail.com) wrote:


 Hello,

  I read that Cassandra has had MapReduce integration since early on. There are 
instructions on how to use Hadoop or Spark. However, it appears to me that 
according to these instructions, Hadoop and Spark just submit requests to 
Cassandra just like any other client would. So, I'm not sure what is meant by 
integration.

  Any pointers? Thanks!

 Best,
 Oliver

--
Oliver Ruebenacker
Solutions Architect at Altisource Labs
Be always grateful, but never satisfied.

Re: Options for expanding Cassandra cluster on AWS

[Russell Bradberry]

I’m not sure about Datastax’s official stance but using the SSD backed 
instances (ed. i2.2xl, c3.4xl etc) outperform the m2.2xl greatly. Also, since 
Datastax is pro-ssd, I doubt they would still recommend to stay on magnetic 
disks.

That said, I have benchmarked all the way up to the c3.8xl instances.  The most 
IOPS I could get out of each node was around 4000-5000.  This seemed to be 
because the context switching was preventing Cassandra from stressing the SSD 
drives to their maximum of 40,000 IOPS.

Since the SSD backed EBS volumes offer up to 4000 IOPS, the speed of the disk 
would not be an issue.  You would, however, still be sharing network resources, 
so without a proper benchmark you would still be rolling the dice.

The best bang for the buck I’ve seen is the i2 instances.  They offer more 
ephemeral disk space at less of a cost than the c3, albeit less cpu. We 
currently use the i2.xlrg and they are working out great.  



On August 19, 2014 at 10:09:26 AM, Brian Tarbox (briantar...@gmail.com) wrote:

The last guidance I heard from DataStax was to use m2.2xlarge's on AWS and put 
data on the ephemeral drivehave they changed this guidance?

Brian


On Tue, Aug 19, 2014 at 9:41 AM, Oleg Dulin oleg.du...@gmail.com wrote:
Distinguished Colleagues:

Our current Cassandra cluster on AWS looks like this:

3 nodes in N. Virginia, one per zone.
RF=3

Each node is a c3.4xlarge with 2x160G SSDs in RAID-0 (~300 Gig SSD on each 
node). Works great, I find it the most optimal configuration for a Cassandra 
node.

But the time is coming soon when I need to expand storage capacity.

I have the following options in front of me:

1) Add 3 more c3.4xlarge nodes. This keeps the amount of data on each node 
reasonable, and all repairs and other tasks can complete in a reasonable amount 
of time. The downside is that c3.4xlarge are pricey.

2) Add provisioned EBS volumes. These days I can get SSD-backed EBS with up to 
4000 IOPS provisioned. I can add those volumes to data_directories list in 
Yaml, and I expect Cassandra can deal with that JBOD-style The upside is 
that it is much cheaper than option #1 above; the downside is that it is a much 
slower configuration and repairs can take longer.

I'd appreciate any input on this topic.

Thanks in advance,
Oleg





--
http://about.me/BrianTarbox

Re: EC2 SSD cluster costs

[Russell Bradberry]

Short answer, it depends on your use-case.

We migrated to i2.xlarge nodes and saw an immediate increase in performance.  
If you just need plain ole raw disk space and don’t have a performance 
requirement to meet then the m1 machines would work, or hell even SSD EBS 
volumes may work for you.  The problem we were having is that we couldn’t fill 
the m1 machines because we needed to add more nodes for performance.  Now we 
have much more power and just the right amount of disk space.

Basically saying, these are not apples-to-apples comparisons



On August 19, 2014 at 11:57:10 AM, Jeremy Jongsma (jer...@barchart.com) wrote:

The latest consensus around the web for running Cassandra on EC2 seems to be 
use new SSD instances. I've not seen any mention of the elephant in the room 
- using the new SSD instances significantly raises the cluster cost per TB. 
With Cassandra's strength being linear scalability to many terabytes of data, 
it strikes me as odd that everyone is recommending such a large storage cost 
hike almost without reservation.

Monthly cost comparison for a 100TB cluster (non-reserved instances):

m1.xlarge (2x420 non-SSD): $30,000 (120 nodes)
m3.xlarge (2x40 SSD): $250,000 (1250 nodes! Clearly not an option)
i2.xlarge (1x800 SSD): $76,000 (125 nodes)

Best case, the cost goes up 150%. How are others approaching these new 
instances? Have you migrated and eaten the costs, or are you staying on 
previous generation until prices come down?

Re: Cassandra select results differs

[Russell Bradberry]

sounds like you may need to run a repair



On July 23, 2014 at 12:50:23 PM, Batranut Bogdan (batra...@yahoo.com) wrote:

Hello all,

I have a CF 


CREATE TABLE cf (
  a text,
  b int,
  c int,
  d int,
  e int,
  PRIMARY KEY (a)
)  WITH
  bloom_filter_fp_chance=0.01 AND
  caching='KEYS_ONLY' AND
  comment='' AND
  dclocal_read_repair_chance=0.00 AND
  gc_grace_seconds=864000 AND
  index_interval=128 AND
  read_repair_chance=0.10 AND
  replicate_on_write='true' AND
  populate_io_cache_on_flush='false' AND
  default_time_to_live=0 AND
  speculative_retry='99.0PERCENTILE' AND
  memtable_flush_period_in_ms=0 AND
  compaction={'class': 'SizeTieredCompactionStrategy'} AND
  compression={'sstable_compression': 'LZ4Compressor'};
 

there are 3 rows there 

when I do select * from cf;

I get random number of rows in results... like 0 , 2, or 3 rows. 

What is the problem?

Re: Cassandra select results differs

[Russell Bradberry]

try running at CL QUORUM and see if the problem goes away, if it does then it 
might be a consistency issue.

also, what version of C*, how many nodes, what is your RF and what CL do you 
normally read?



On July 23, 2014 at 12:55:32 PM, Batranut Bogdan (batra...@yahoo.com) wrote:

I have cron jobs that repair every week. node 1 - monday , node 2 tuesday .


On Wednesday, July 23, 2014 7:52 PM, Russell Bradberry rbradbe...@gmail.com 
wrote:


sounds like you may need to run a repair



On July 23, 2014 at 12:50:23 PM, Batranut Bogdan (batra...@yahoo.com) wrote:
Hello all,

I have a CF 


CREATE TABLE cf (
  a text,
  b int,
  c int,
  d int,
  e int,
  PRIMARY KEY (a)
)  WITH
  bloom_filter_fp_chance=0.01 AND
  caching='KEYS_ONLY' AND
  comment='' AND
  dclocal_read_repair_chance=0.00 AND
  gc_grace_seconds=864000 AND
  index_interval=128 AND
  read_repair_chance=0.10 AND
  replicate_on_write='true' AND
  populate_io_cache_on_flush='false' AND
  default_time_to_live=0 AND
  speculative_retry='99.0PERCENTILE' AND
  memtable_flush_period_in_ms=0 AND
  compaction={'class': 'SizeTieredCompactionStrategy'} AND
  compression={'sstable_compression': 'LZ4Compressor'};
 

there are 3 rows there 

when I do select * from cf;

I get random number of rows in results... like 0 , 2, or 3 rows. 

What is the problem?

Re: Which way to Cassandraville?

[Russell Bradberry]

Having an ORM says nothing about the maturity of a database, it says more about 
the community and their willingness to create one.  The database itself has 
nothing to do with the creation of the ORM.  Atop everything else, as was 
stated, knowing how to model your queries is the most important thing, more 
than knowing how to use the driver.  Cassandra has a very specific way that it 
stores data, if you attempt to store data the way you do in any other RDBMS 
there is a good chance you will have a very hard time.  

Also, this: http://my.safaribooksonline.com/book/databases/9780133440195

We wrote it for 1.2 but most all of the information still applies.

The performance gains you get from Cassandra come at a cost, that cost being 
that you need to know what you are doing.


On July 22, 2014 at 4:01:21 PM, jcllings (jclli...@gmail.com) wrote:

OK to clarify, I don't mean as an Administrator but an application developer.  
If you use an ORM how important is CQL3?  The object being to eliminate any *QL 
from Java code.
Perhaps this technology isn't as mature as I thought.

Jim C.

On 07/22/2014 12:42 PM, DuyHai Doan wrote:
What kinds of things would it be good to know for an interview?

 The underlying storage engine and how CQL3 maps to it. It's more than 
important, it's crucial. Knowing what you do and what you can't with CQL3 is 
not sufficient.




On Tue, Jul 22, 2014 at 9:20 PM, jcllings jclli...@gmail.com wrote:
So It seems that:

1. There are indeed a few (3-4) mapping schemes.
2. CQL isn't very hard and represents a subset of  (ANSI?) SQ92.

Both of these are validated based on further research and list guidance.

It appears that learning Cassandra from an application developers
perspective essentially means learning what you can't do at all and
learning what you can't do directly that you could do with an RDMBS.
This and keys and maybe a thing or two about replication strategies and
you should be good to go.  Does this seem accurate?

What kinds of things would it be good to know for an interview?

Jim C.

Re: EBS SSD - Cassandra ?

[Russell Bradberry]

does an elastic network interface really use a different physical network 
interface? or is it just to give the ability for multiple ip addresses?



On June 19, 2014 at 3:56:34 PM, Nate McCall (n...@thelastpickle.com) wrote:

If someone really wanted to try this it, I recommend adding an Elastic Network 
Interface or two for gossip and client/API traffic. This lets EBS and 
management traffic have the pre-configured network. 


On Thu, Jun 19, 2014 at 6:54 AM, Benedict Elliott Smith 
belliottsm...@datastax.com wrote:
I would say this is worth benchmarking before jumping to conclusions. The 
network being a bottleneck (or latency causing) for EBS is, to my knowledge, 
supposition, and instances can be started with direct connections to EBS if 
this is a concern. The blog post below shows that even without SSDs the 
EBS-optimised provisioned-IOPS instances show pretty consistent latency 
numbers, although those latencies are higher than you would typically expect 
from locally attached storage.

http://blog.parse.com/2012/09/17/parse-databases-upgraded-to-amazon-provisioned-iops/

Note, I'm not endorsing the use of EBS. Cassandra is designed to scale up with 
number of nodes, not with depth of nodes (as Ben mentions, saturating a single 
node's data capacity is pretty easy these days. CPUs rapidly become the 
bottleneck as you try to go deep). However the argument that EBS cannot provide 
consistent performance seems overly pessimistic, and should probably be 
empirically determined for your use case.


On Thu, Jun 19, 2014 at 9:50 AM, Alain RODRIGUEZ arodr...@gmail.com wrote:
Ok, looks fair enough.

Thanks guys. I would be great to be able to add disks when amount of data 
raises and add nodes when throughput increases... :)


2014-06-19 5:27 GMT+02:00 Ben Bromhead b...@instaclustr.com:

http://www.datastax.com/documentation/cassandra/1.2/cassandra/architecture/architecturePlanningEC2_c.html

From the link:

EBS volumes are not recommended for Cassandra data volumes for the following 
reasons:

• EBS volumes contend directly for network throughput with standard packets. 
This means that EBS throughput is likely to fail if you saturate a network link.
• EBS volumes have unreliable performance. I/O performance can be exceptionally 
slow, causing the system to back load reads and writes until the entire cluster 
becomes unresponsive.
• Adding capacity by increasing the number of EBS volumes per host does not 
scale. You can easily surpass the ability of the system to keep effective 
buffer caches and concurrently serve requests for all of the data it is 
responsible for managing.

Still applies, especially the network contention and latency issues. 

Ben Bromhead
Instaclustr | www.instaclustr.com | @instaclustr | +61 415 936 359

On 18 Jun 2014, at 7:18 pm, Daniel Chia danc...@coursera.org wrote:

While they guarantee IOPS, they don't really make any guarantees about latency. 
Since EBS goes over the network, there's so many things in the path of getting 
at your data, I would be concerned with random latency spikes, unless proven 
otherwise.

Thanks,
Daniel


On Wed, Jun 18, 2014 at 1:58 AM, Alain RODRIGUEZ arodr...@gmail.com wrote:
In this document it is said :

Provisioned IOPS (SSD) - Volumes of this type are ideal for the most demanding 
I/O intensive, transactional workloads and large relational or NoSQL databases. 
This volume type provides the most consistent performance and allows you to 
provision the exact level of performance you need with the most predictable and 
consistent performance. With this type of volume you provision exactly what you 
need, and pay for what you provision. Once again, you can achieve up to 48,000 
IOPS by connecting multiple volumes together using RAID.


2014-06-18 10:57 GMT+02:00 Alain RODRIGUEZ arodr...@gmail.com:

Hi,

I just saw this : 
http://aws.amazon.com/fr/blogs/aws/new-ssd-backed-elastic-block-storage/

Since the problem with EBS was the network, there is no chance that this 
hardware architecture might be useful alongside Cassandra, right ?

Alain








--
-
Nate McCall
Austin, TX
@zznate

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

Re: running out of diskspace during maintenance tasks

[Russell Bradberry]

repair only creates snapshots if you use the “-snapshot” option.



On June 18, 2014 at 12:28:58 PM, Marcelo Elias Del Valle 
(marc...@s1mbi0se.com.br) wrote:

AFAIK, when you run a repair a snapshot is created.
After the repair, I run nodetool clearsnapshot to save disk space.
Not sure it's you case or not.
[]s


2014-06-18 13:10 GMT-03:00 Brian Tarbox tar...@cabotresearch.com:
We do a repair -pr on each node once a week on a rolling basis.
Should we be running cleanup as well?  My understanding that was only used 
after adding/removing nodes?

We'd like to avoid adding nodes if possible (which might not be).   Still 
curious if we can get C* to do the maintenance task on a separate volume.

Thanks.


On Wed, Jun 18, 2014 at 12:03 PM, Jeremy Jongsma jer...@barchart.com wrote:
One option is to add new nodes, and do a node repair/cleanup on everything. 
That will at least reduce your per-node data size.


On Wed, Jun 18, 2014 at 11:01 AM, Brian Tarbox tar...@cabotresearch.com wrote:
I'm running on AWS m2.2xlarge instances using the ~800 gig ephemeral/attached 
disk for my data directory.  My data size per node is nearing 400 gig.

Sometimes during maintenance operations (repairs mostly I think) I run out of 
disk space as my understanding is that some of these operations require double 
the space of one's data.

Since I can't change the size of attached storage for my instance type my 
question is can I somehow get these maintenance operations to use other volumes?

Failing that, what are my options?  Thanks.

Brian Tarbox

Re: Customized Compaction Strategy: Dev Questions

[Russell Bradberry]

You mean this:

https://issues.apache.org/jira/browse/CASSANDRA-5228

?



On June 4, 2014 at 12:42:33 PM, Redmumba (redmu...@gmail.com) wrote:

Good morning!

I've asked (and seen other people ask) about the ability to drop old sstables, 
basically creating a FIFO-like clean-up process.  Since we're using Cassandra 
as an auditing system, this is particularly appealing to us because it means we 
can maximize the amount of auditing data we can keep while still allowing 
Cassandra to clear old data automatically.

My idea is this: perform compaction based on the range of dates available in 
the sstable (or just metadata about when it was created).  For example, a major 
compaction could create a combined sstable per day--so that, say, 60 days of 
data after a major compaction would contain 60 sstables.

My question then is, will this be possible by simply implementing a separate 
AbstractCompactionStrategy?  Does this sound feasilble at all?  Based on the 
implementation of Size and Leveled strategies, it looks like I would have the 
ability to control what and how things get compacted, but I wanted to verify 
before putting time into it.

Thank you so much for your time!

Andrew

Re: Customized Compaction Strategy: Dev Questions

[Russell Bradberry]

hmm, I see. So something similar to Capped Collections in MongoDB.



On June 4, 2014 at 1:03:46 PM, Redmumba (redmu...@gmail.com) wrote:

Not quite; if I'm at say 90% disk usage, I'd like to drop the oldest sstable 
rather than simply run out of space.

The problem with using TTLs is that I have to try and guess how much data is 
being put in--since this is auditing data, the usage can vary wildly depending 
on time of year, verbosity of auditing, etc..  I'd like to maximize the disk 
space--not optimize the cleanup process.

Andrew


On Wed, Jun 4, 2014 at 9:47 AM, Russell Bradberry rbradbe...@gmail.com wrote:
You mean this:

https://issues.apache.org/jira/browse/CASSANDRA-5228

?



On June 4, 2014 at 12:42:33 PM, Redmumba (redmu...@gmail.com) wrote:

Good morning!

I've asked (and seen other people ask) about the ability to drop old sstables, 
basically creating a FIFO-like clean-up process.  Since we're using Cassandra 
as an auditing system, this is particularly appealing to us because it means we 
can maximize the amount of auditing data we can keep while still allowing 
Cassandra to clear old data automatically.

My idea is this: perform compaction based on the range of dates available in 
the sstable (or just metadata about when it was created).  For example, a major 
compaction could create a combined sstable per day--so that, say, 60 days of 
data after a major compaction would contain 60 sstables.

My question then is, will this be possible by simply implementing a separate 
AbstractCompactionStrategy?  Does this sound feasilble at all?  Based on the 
implementation of Size and Leveled strategies, it looks like I would have the 
ability to control what and how things get compacted, but I wanted to verify 
before putting time into it.

Thank you so much for your time!

Andrew

Re: Customized Compaction Strategy: Dev Questions

[Russell Bradberry]

I’m not sure what you want to do is feasible.  At a high level I can see you 
running into issues with RF etc.  The SSTables node to node are not identical, 
so if you drop a full SSTable on one node there is no one corresponding SSTable 
on the adjacent nodes to drop.    You would need to choose data to compact out, 
and ensure it is removed on all replicas as well.  But if your problem is that 
you’re low on disk space then you probably won’t be able to write out a new 
SSTable with the older information compacted out. Also, there is more to an 
SSTable than just data, the SSTable could have tombstones and other relics that 
haven’t been cleaned up from nodes coming or going. 




On June 4, 2014 at 1:10:58 PM, Redmumba (redmu...@gmail.com) wrote:

Thanks, Russell--yes, a similar concept, just applied to sstables.  I'm 
assuming this would require changes to both major compactions, and probably GC 
(to remove the old tables), but since I'm not super-familiar with the C* 
internals, I wanted to make sure it was feasible with the current toolset 
before I actually dived in and started tinkering.

Andrew


On Wed, Jun 4, 2014 at 10:04 AM, Russell Bradberry rbradbe...@gmail.com wrote:
hmm, I see. So something similar to Capped Collections in MongoDB.



On June 4, 2014 at 1:03:46 PM, Redmumba (redmu...@gmail.com) wrote:

Not quite; if I'm at say 90% disk usage, I'd like to drop the oldest sstable 
rather than simply run out of space.

The problem with using TTLs is that I have to try and guess how much data is 
being put in--since this is auditing data, the usage can vary wildly depending 
on time of year, verbosity of auditing, etc..  I'd like to maximize the disk 
space--not optimize the cleanup process.

Andrew


On Wed, Jun 4, 2014 at 9:47 AM, Russell Bradberry rbradbe...@gmail.com wrote:
You mean this:

https://issues.apache.org/jira/browse/CASSANDRA-5228

?



On June 4, 2014 at 12:42:33 PM, Redmumba (redmu...@gmail.com) wrote:

Good morning!

I've asked (and seen other people ask) about the ability to drop old sstables, 
basically creating a FIFO-like clean-up process.  Since we're using Cassandra 
as an auditing system, this is particularly appealing to us because it means we 
can maximize the amount of auditing data we can keep while still allowing 
Cassandra to clear old data automatically.

My idea is this: perform compaction based on the range of dates available in 
the sstable (or just metadata about when it was created).  For example, a major 
compaction could create a combined sstable per day--so that, say, 60 days of 
data after a major compaction would contain 60 sstables.

My question then is, will this be possible by simply implementing a separate 
AbstractCompactionStrategy?  Does this sound feasilble at all?  Based on the 
implementation of Size and Leveled strategies, it looks like I would have the 
ability to control what and how things get compacted, but I wanted to verify 
before putting time into it.

Thank you so much for your time!

Andrew

Re: Customized Compaction Strategy: Dev Questions

[Russell Bradberry]

Maybe I’m misunderstanding something, but what makes you think that running a 
major compaction every day will cause they data from January 1st to exist in 
only one SSTable and not have data from other days in the SSTable as well? Are 
you talking about making a new compaction strategy that creates SSTables by day?



On June 4, 2014 at 1:36:10 PM, Redmumba (redmu...@gmail.com) wrote:

Let's say I run a major compaction every day, so that the oldest sstable 
contains only the data for January 1st.  Assuming all the nodes are in-sync and 
have had at least one repair run before the table is dropped (so that all 
information for that time period is the same), wouldn't it be safe to assume 
that the same data would be dropped on all nodes?  There might be a period when 
the compaction is running where different nodes might have an inconsistent view 
of just that days' data (in that some would have it and others would not), but 
the cluster would still function and become eventually consistent, correct?

Also, if the entirety of the sstable is being dropped, wouldn't the tombstones 
be removed with it?  I wouldn't be concerned with individual rows and columns, 
and this is a write-only table, more or less--the only deletes that occur in 
the current system are to delete the old data.


On Wed, Jun 4, 2014 at 10:24 AM, Russell Bradberry rbradbe...@gmail.com wrote:
I’m not sure what you want to do is feasible.  At a high level I can see you 
running into issues with RF etc.  The SSTables node to node are not identical, 
so if you drop a full SSTable on one node there is no one corresponding SSTable 
on the adjacent nodes to drop.    You would need to choose data to compact out, 
and ensure it is removed on all replicas as well.  But if your problem is that 
you’re low on disk space then you probably won’t be able to write out a new 
SSTable with the older information compacted out. Also, there is more to an 
SSTable than just data, the SSTable could have tombstones and other relics that 
haven’t been cleaned up from nodes coming or going. 




On June 4, 2014 at 1:10:58 PM, Redmumba (redmu...@gmail.com) wrote:

Thanks, Russell--yes, a similar concept, just applied to sstables.  I'm 
assuming this would require changes to both major compactions, and probably GC 
(to remove the old tables), but since I'm not super-familiar with the C* 
internals, I wanted to make sure it was feasible with the current toolset 
before I actually dived in and started tinkering.

Andrew


On Wed, Jun 4, 2014 at 10:04 AM, Russell Bradberry rbradbe...@gmail.com wrote:
hmm, I see. So something similar to Capped Collections in MongoDB.



On June 4, 2014 at 1:03:46 PM, Redmumba (redmu...@gmail.com) wrote:

Not quite; if I'm at say 90% disk usage, I'd like to drop the oldest sstable 
rather than simply run out of space.

The problem with using TTLs is that I have to try and guess how much data is 
being put in--since this is auditing data, the usage can vary wildly depending 
on time of year, verbosity of auditing, etc..  I'd like to maximize the disk 
space--not optimize the cleanup process.

Andrew


On Wed, Jun 4, 2014 at 9:47 AM, Russell Bradberry rbradbe...@gmail.com wrote:
You mean this:

https://issues.apache.org/jira/browse/CASSANDRA-5228

?



On June 4, 2014 at 12:42:33 PM, Redmumba (redmu...@gmail.com) wrote:

Good morning!

I've asked (and seen other people ask) about the ability to drop old sstables, 
basically creating a FIFO-like clean-up process.  Since we're using Cassandra 
as an auditing system, this is particularly appealing to us because it means we 
can maximize the amount of auditing data we can keep while still allowing 
Cassandra to clear old data automatically.

My idea is this: perform compaction based on the range of dates available in 
the sstable (or just metadata about when it was created).  For example, a major 
compaction could create a combined sstable per day--so that, say, 60 days of 
data after a major compaction would contain 60 sstables.

My question then is, will this be possible by simply implementing a separate 
AbstractCompactionStrategy?  Does this sound feasilble at all?  Based on the 
implementation of Size and Leveled strategies, it looks like I would have the 
ability to control what and how things get compacted, but I wanted to verify 
before putting time into it.

Thank you so much for your time!

Andrew

Re: Customized Compaction Strategy: Dev Questions

[Russell Bradberry]

Well, DELETE will not free up disk space until after GC grace has passed and 
the next major compaction has run. So in essence, if you need to free up space 
right away, then creating daily/monthly tables would be one way to go.  Just 
remember to clear your snapshots after dropping though.



On June 4, 2014 at 1:54:05 PM, Redmumba (redmu...@gmail.com) wrote:

That still involves quite a bit of infrastructure work--it also means that to 
query the data, I would have to make N queries, one per table, to query for 
audit information (audit information is sorted by a key identifying the item, 
and then the date).  I don't think this would yield any benefit (to me) over 
simply tombstoning the values or creating a secondary index on date and simply 
doing a DELETE, right?

Is there something internally preventing me from implementing this as a 
separate Strategy?


On Wed, Jun 4, 2014 at 10:47 AM, Jonathan Haddad j...@jonhaddad.com wrote:
I'd suggest creating 1 table per day, and dropping the tables you don't need 
once you're done.


On Wed, Jun 4, 2014 at 10:44 AM, Redmumba redmu...@gmail.com wrote:
Sorry, yes, that is what I was looking to do--i.e., create a 
TopologicalCompactionStrategy or similar.


On Wed, Jun 4, 2014 at 10:40 AM, Russell Bradberry rbradbe...@gmail.com wrote:
Maybe I’m misunderstanding something, but what makes you think that running a 
major compaction every day will cause they data from January 1st to exist in 
only one SSTable and not have data from other days in the SSTable as well? Are 
you talking about making a new compaction strategy that creates SSTables by day?



On June 4, 2014 at 1:36:10 PM, Redmumba (redmu...@gmail.com) wrote:

Let's say I run a major compaction every day, so that the oldest sstable 
contains only the data for January 1st.  Assuming all the nodes are in-sync and 
have had at least one repair run before the table is dropped (so that all 
information for that time period is the same), wouldn't it be safe to assume 
that the same data would be dropped on all nodes?  There might be a period when 
the compaction is running where different nodes might have an inconsistent view 
of just that days' data (in that some would have it and others would not), but 
the cluster would still function and become eventually consistent, correct?

Also, if the entirety of the sstable is being dropped, wouldn't the tombstones 
be removed with it?  I wouldn't be concerned with individual rows and columns, 
and this is a write-only table, more or less--the only deletes that occur in 
the current system are to delete the old data.


On Wed, Jun 4, 2014 at 10:24 AM, Russell Bradberry rbradbe...@gmail.com wrote:
I’m not sure what you want to do is feasible.  At a high level I can see you 
running into issues with RF etc.  The SSTables node to node are not identical, 
so if you drop a full SSTable on one node there is no one corresponding SSTable 
on the adjacent nodes to drop.    You would need to choose data to compact out, 
and ensure it is removed on all replicas as well.  But if your problem is that 
you’re low on disk space then you probably won’t be able to write out a new 
SSTable with the older information compacted out. Also, there is more to an 
SSTable than just data, the SSTable could have tombstones and other relics that 
haven’t been cleaned up from nodes coming or going. 




On June 4, 2014 at 1:10:58 PM, Redmumba (redmu...@gmail.com) wrote:

Thanks, Russell--yes, a similar concept, just applied to sstables.  I'm 
assuming this would require changes to both major compactions, and probably GC 
(to remove the old tables), but since I'm not super-familiar with the C* 
internals, I wanted to make sure it was feasible with the current toolset 
before I actually dived in and started tinkering.

Andrew


On Wed, Jun 4, 2014 at 10:04 AM, Russell Bradberry rbradbe...@gmail.com wrote:
hmm, I see. So something similar to Capped Collections in MongoDB.



On June 4, 2014 at 1:03:46 PM, Redmumba (redmu...@gmail.com) wrote:

Not quite; if I'm at say 90% disk usage, I'd like to drop the oldest sstable 
rather than simply run out of space.

The problem with using TTLs is that I have to try and guess how much data is 
being put in--since this is auditing data, the usage can vary wildly depending 
on time of year, verbosity of auditing, etc..  I'd like to maximize the disk 
space--not optimize the cleanup process.

Andrew


On Wed, Jun 4, 2014 at 9:47 AM, Russell Bradberry rbradbe...@gmail.com wrote:
You mean this:

https://issues.apache.org/jira/browse/CASSANDRA-5228

?



On June 4, 2014 at 12:42:33 PM, Redmumba (redmu...@gmail.com) wrote:

Good morning!

I've asked (and seen other people ask) about the ability to drop old sstables, 
basically creating a FIFO-like clean-up process.  Since we're using Cassandra 
as an auditing system, this is particularly appealing to us because it means we 
can maximize the amount of auditing data we can keep while still allowing 
Cassandra

Re: I don't understand paging through a table by primary key.

[Russell Bradberry]

I think what you want is a clustering column”.  When you model your data, you 
specify “partition columns” which are synonymous with the old thrift style 
“keys” and clustering columns.  When creating your PRIMARY KEY, you specify the 
partition column first then each subsequent column in the primary key is is the 
clustering columns. These columns determine how the data in that partition is 
stored on disk. 

For instance if i was storing time series events for URLs I might do something 
like this:

PRIMARY KEY(url, event_time)

This means that all events for a given URL will be stored contiguously in order 
on the same node.

This allows the following type of query:

SELECT * FROM events WHERE url = 'http://devdazed.com' and event_time  
‘2014-01-01’ AND event_time  ‘2014-01-07’;

Make sense?



On May 30, 2014 at 1:10:51 AM, Kevin Burton (bur...@spinn3r.com) wrote:

I'm trying to grok this but I can't figure it out in CQL world.

I'd like to efficiently page through a table via primary key.

This way I only involve one node at a time and the reads on disk are 
contiguous.  

I would have assumed it was a combination of  pk and order by but that doesn't 
seem to work.

--
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.

Re: I don't understand paging through a table by primary key.

[Russell Bradberry]

Then the data model you chose is incorrect.  As Rob Coli mentioned, you can not 
page through partitions that are ordered unless you are using an ordered 
partitioner.  Your only option is to store the data differently.  When using 
Cassandra you have to remember to “model your queries, not your data”.  You can 
only page the entire table by using the TOKEN keyword, and this is not 
efficient.



On May 30, 2014 at 1:17:37 PM, Kevin Burton (bur...@spinn3r.com) wrote:

The specific issue is I have a fairly large table, which is immutable, and I 
need to get it in a form where it can be downloaded, page by page, via an API.

This would involve reading the whole table.  

I'd like to page through it by key order to efficiently read the rows to 
minimize random reads.

It's slightly more complicated then that in that it's a log structured table… 
basically holding the equivalent of apache logs..  I need to read these out by 
time and give them to API callers.


On Fri, May 30, 2014 at 12:21 AM, DuyHai Doan doanduy...@gmail.com wrote:
Hello Kevin

 Can you be more specific on the issue you're facing ? What is the table design 
? What kind of query are you doing ?

 Regards


On Fri, May 30, 2014 at 7:10 AM, Kevin Burton bur...@spinn3r.com wrote:
I'm trying to grok this but I can't figure it out in CQL world.

I'd like to efficiently page through a table via primary key.

This way I only involve one node at a time and the reads on disk are 
contiguous.  

I would have assumed it was a combination of  pk and order by but that doesn't 
seem to work.

--
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.




--
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.

Re: Shouldn't cqlsh have an option for no formatting and no headers?

[Russell Bradberry]

cqlsh isn’t designed for dumping data. I think you want COPY 
http://www.datastax.com/documentation/cql/3.0/cql/cql_reference/copy_r.html



On May 30, 2014 at 2:32:24 PM, Kevin Burton (bur...@spinn3r.com) wrote:

I do this all the time with mysql… dump some database table to an output file 
so that I can use it in a script.

but cqlsh insists on formatting the output.

there should be an option for no headers and no whitespace formatting of the 
results.

I mean I can work around it for now… but it's not going to be fun to always 
post process the output.

--
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.

Re: which replica has your data?

[Russell Bradberry]

nodetool getendpoints keyspace cf key



On April 22, 2014 at 4:52:08 PM, Han,Meng (meng...@ufl.edu) wrote:

Hi all,  

I have a data item whose row key is  
7573657238353137303937323637363334393636363230  
and I have a five node Cassandra cluster with replication factor set to  
3. Each replica's token is listed below  

TOK: 0  
TOK: 34028236692093846346337460743176821145  
TOK: 68056473384187692692674921486353642291  
TOK: 68056473384187692692674921486353642291  
TOK: 102084710076281539039012382229530463436  
TOK: 136112946768375385385349842972707284582  

All the five nodes are on the same rack and I am using SimpleSnitch.  
Could someone tell me how can I know which replica has/stores that  
particular row above?  

Is there any client side command that can query which replica has a  
certain row?  

Thank loads!  


Cheers,  
Meng  

C* 1.2.15 Decommission issues

[Russell Bradberry]

We have about a 30 node cluster running the latest C* 1.2 series DSE.  One 
datacenter uses VNodes and the other datacenter has VNodes Disabled (because it 
is running DSE-Seearch)

We have been replacing nodes in the VNode datacenter with faster ones and we 
have yet to have a successful decommission.  Every time we attempt to 
decommission a node we get an “Operation Timed Out” error and the decommission 
fails.  We keep retrying it and sometimes it will work and other times we will 
just give up and force the node removal.  It seems though, that all the data 
has streamed out of the node before the decommission fails.

What exactly does it need to read before leaving that would cause this?  We 
also have noticed that in several nodes after the removal that there are ghost 
entries for the removed node in the system.peers table and this doesn’t get 
removed until we restart Cassandra on that node.

Also, we have noticed that running repairs with VNodes is considerably slower. 
Is this a misconfiguration? Or is it expected that VNodes repairs will be slow?


Here is the stack trace from the decommission failure:

Exception in thread main java.lang.RuntimeException: 
org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - 
received only 0 responses.
        at 
org.apache.cassandra.db.HintedHandOffManager.getHintsSlice(HintedHandOffManager.java:578)
        at 
org.apache.cassandra.db.HintedHandOffManager.listEndpointsPendingHints(HintedHandOffManager.java:528)
        at 
org.apache.cassandra.service.StorageService.streamHints(StorageService.java:2925)
        at 
org.apache.cassandra.service.StorageService.unbootstrap(StorageService.java:2905)
        at 
org.apache.cassandra.service.StorageService.decommission(StorageService.java:2866)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)
        at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
        at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)
        at 
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
        at 
com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
        at 
com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
        at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
        at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
        at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
        at 
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
        at 
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487)
        at 
javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
        at 
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
        at 
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420)
        at 
javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848)
        at sun.reflect.GeneratedMethodAccessor26.invoke(Unknown Source)
        at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
        at sun.rmi.transport.Transport$1.run(Transport.java:177)
        at sun.rmi.transport.Transport$1.run(Transport.java:174)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
        at 
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556)
        at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
        at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
        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:744)
Caused by: org.apache.cassandra.exceptions.ReadTimeoutException: Operation 
timed out - received only 0 responses.
        at org.apache.cassandra.service.ReadCallback.get(ReadCallback.java:105)
        at 

Re: Proposal: freeze Thrift starting with 2.1.0

[Russell Bradberry]

I would love to help with the REST interface, however my point was not to add 
REST into Cassandra.  My point was that if we had an abstract interface that 
even CQL used to access data, and this interface was made available for other 
drop in modules to access, then the project becomes extensible as a whole.  You 
get CQL out of the box, but it allows others to create interface projects of 
their own and keep them up without putting the burden of that maintenance on 
the core developers.

It could also mean that down the line, say if CQL stops working out like Avro 
and Thrift before it, then pulling it out would be less of a problem.  We can 
even get all cowboy up in here and put CQL in its own project that can grow by 
itself, as long as an interface in the Cassandra project is made available.


On March 12, 2014 at 10:13:34 AM, Brian O'Neill (b...@alumni.brown.edu) wrote:


just when you thought the thread died…


First, let me say we are *WAY* off topic.  But that is a good thing.  
I love this community because there are a ton of passionate, smart people. 
(often with differing perspectives ;)

RE: Reporting against C* (@Peter Lin)
We’ve had the same experience.  Pig + Hadoop is painful.  We are experimenting 
with Spark/Shark, operating directly against the data.
http://brianoneill.blogspot.com/2014/03/spark-on-cassandra-w-calliope.html

The Shark layer gives you SQL and caching capabilities that make it easy to use 
and fast (for smaller data sets).  In front of this, we are going to add 
dimensional aggregations so we can operate at larger scales.  (then the Hive 
reports will run against the aggregations)

RE: REST Server (@Russel Bradbury)
We had moderate success with Virgil, which was a REST server built directly on 
Thrift.  We built it directly on top of Thrift, so one day it could be easily 
embedded in the C* server itself.   It could be deployed separately, or run an 
embedded C*.  More often than not, we ended up running it separately to 
separate the layers.  (just like Titan and Rexster)  I’ve started on a rewrite 
of Virgil called Memnon that rides on top of CQL. (I’d love some help)
https://github.com/boneill42/memnon

RE: CQL vs. Thrift
We’ve hitched our wagons to CQL.  CQL != Relational.  
We’ve had success translating our “native” schemas into CQL, including all the 
NoSQL goodness of wide-rows, etc.  You just need a good understanding of how 
things translate into storage and underlying CFs.  If anything, I think we 
could add some DESCRIBE information, which would help users with this, along 
the lines of:
(https://issues.apache.org/jira/browse/CASSANDRA-6676)

CQL does open up the *opportunity* for users to articulate more complex queries 
using more familiar syntax.  (including future things such as joins, grouping, 
etc.)   To me, that is exciting, and again — one of the reasons we are leaning 
on it.

my two cents,
brian

---
Brian O'Neill
Chief Technology Officer

Health Market Science
The Science of Better Results
2700 Horizon Drive • King of Prussia, PA • 19406
M: 215.588.6024 • @boneill42  •  
healthmarketscience.com

This information transmitted in this email message is for the intended 
recipient only and may contain confidential and/or privileged material. If you 
received this email in error and are not the intended recipient, or the person 
responsible to deliver it to the intended recipient, please contact the sender 
at the email above and delete this email and any attachments and destroy any 
copies thereof. Any review, retransmission, dissemination, copying or other use 
of, or taking any action in reliance upon, this information by persons or 
entities other than the intended recipient is strictly prohibited.
 

From: Peter Lin wool...@gmail.com
Reply-To: user@cassandra.apache.org
Date: Wednesday, March 12, 2014 at 8:44 AM
To: user@cassandra.apache.org user@cassandra.apache.org
Subject: Re: Proposal: freeze Thrift starting with 2.1.0


yes, I was looking at intravert last nite.

For the kinds of reports my customers ask us to do, joins and subqueries are 
important. Having tried to do a simple join in PIG, the level of pain is  high. 
I'm a masochist, so I don't mind breaking a simple join into multiple MR tasks, 
though I do find myself asking why the hell does it need to be so painful in 
PIG? Many of my friends say what is this crap! or this is better than 
writing sql queries to run reports?

Plus, using ETL techniques to extract summaries only works for cases where the 
data is small enough. Once it gets beyond a certain size, it's not practical, 
which means we're back to crappy reporting languages that make life painful. 
Lots of big healthcare companies have thousands of MOLAP cubes on dozens of 
mainframes. The old OLTP - DW/OLAP creates it's own set of management 
headaches.

being able to report directly on the raw data avoids many of the issues, but 
that's my bias perspective.




On Wed, Mar 12, 2014 at 8:15 AM, DuyHai Doan doanduy...@gmail.com 

Re: Proposal: freeze Thrift starting with 2.1.0

[Russell Bradberry]

@Nate, @Tupshin, this is pretty close to what I had in mind. I would be open to 
helping out with a formal proposal.



On March 12, 2014 at 12:11:41 PM, Tupshin Harper (tups...@tupshin.com) wrote:

I agree that we are way off the initial topic, but I think we are spot on the 
most important topic. As seen in various tickets, including #6704 (wide row 
scanners), #6167 (end-slice termination predicate), the existence of 
intravert-ug (Cassandra interface to intravert), and a number of others, there 
is an increasing desire to do more complicated processing, server-side, on a 
Cassandra cluster.

I very much share those goals, and would like to propose the following only 
partially hand-wavey path forward.

Instead of creating a pluggable interface for Thrift, I'd like to create a 
pluggable interface for arbitrary app-server deep integration.

Inspired by both the existence of intravert-ug, as well as there being a long 
history of various parties embedding tomcat or jetty servlet engines inside 
Cassandra, I'd like to propose the creation an internal somewhat stable 
(versioned?) interface that could allow any app server to achieve deep 
integration with Cassandra, and as a result, these servers could 
1) host their own apis (REST, for example
2) extend core functionality by having limited (see triggers and wide row 
scanners) access to the internals of cassandra

The hand wavey part comes because while I have been mulling this about for a 
while, I have not spent any significant time into looking at the actual surface 
area of intravert-ug's integration. But, using it as a model, and also keeping 
in minds the general needs of your more traditional servlet/j2ee containers, I 
believe we could come up with a reasonable interface to allow any jvm app 
server to be integrated and maintained in or out of the Cassandra tree.

This would satisfy the needs that many of us (Both Ed and I, for example) to 
have a much greater degree of control over server side execution, and to be 
able to start building much more interestingly (and simply) tiered applications.

Anybody interested in working on a coherent proposal with me?

-Tupshin


On Wed, Mar 12, 2014 at 10:12 AM, Brian O'Neill b...@alumni.brown.edu wrote:

just when you thought the thread died…


First, let me say we are *WAY* off topic.  But that is a good thing.  
I love this community because there are a ton of passionate, smart people. 
(often with differing perspectives ;)

RE: Reporting against C* (@Peter Lin)
We’ve had the same experience.  Pig + Hadoop is painful.  We are experimenting 
with Spark/Shark, operating directly against the data.
http://brianoneill.blogspot.com/2014/03/spark-on-cassandra-w-calliope.html

The Shark layer gives you SQL and caching capabilities that make it easy to use 
and fast (for smaller data sets).  In front of this, we are going to add 
dimensional aggregations so we can operate at larger scales.  (then the Hive 
reports will run against the aggregations)

RE: REST Server (@Russel Bradbury)
We had moderate success with Virgil, which was a REST server built directly on 
Thrift.  We built it directly on top of Thrift, so one day it could be easily 
embedded in the C* server itself.   It could be deployed separately, or run an 
embedded C*.  More often than not, we ended up running it separately to 
separate the layers.  (just like Titan and Rexster)  I’ve started on a rewrite 
of Virgil called Memnon that rides on top of CQL. (I’d love some help)
https://github.com/boneill42/memnon

RE: CQL vs. Thrift
We’ve hitched our wagons to CQL.  CQL != Relational.  
We’ve had success translating our “native” schemas into CQL, including all the 
NoSQL goodness of wide-rows, etc.  You just need a good understanding of how 
things translate into storage and underlying CFs.  If anything, I think we 
could add some DESCRIBE information, which would help users with this, along 
the lines of:
(https://issues.apache.org/jira/browse/CASSANDRA-6676)

CQL does open up the *opportunity* for users to articulate more complex queries 
using more familiar syntax.  (including future things such as joins, grouping, 
etc.)   To me, that is exciting, and again — one of the reasons we are leaning 
on it.

my two cents,
brian

---
Brian O'Neill
Chief Technology Officer

Health Market Science
The Science of Better Results
2700 Horizon Drive • King of Prussia, PA • 19406
M: 215.588.6024 • @boneill42  •  
healthmarketscience.com

This information transmitted in this email message is for the intended 
recipient only and may contain confidential and/or privileged material. If you 
received this email in error and are not the intended recipient, or the person 
responsible to deliver it to the intended recipient, please contact the sender 
at the email above and delete this email and any attachments and destroy any 
copies thereof. Any review, retransmission, dissemination, copying or other use 
of, or taking any action in reliance upon, this information by 

Re: mixed nodes, some SSD some HD

[Russell Bradberry]

Are you using the dynamic snitch? Because the SimpleSnitch is the default.



On March 5, 2014 at 5:27:03 PM, Elliot Finley (efinley.li...@gmail.com) wrote:

Keep in mind, for this 3 node cluster, N = 3.

I did a bit more digging and I found this (for future searches on this topic):

http://www.datastax.com/documentation/cassandra/2.0/cassandra/architecture/architectureSnitchDynamic_c.html

http://www.datastax.com/dev/blog/dynamic-snitching-in-cassandra-past-present-and-future

So, according to this, if I'm reading it right, the SSD node WILL take the 
majority of reads.

Any comments welcome.



On Wed, Mar 5, 2014 at 10:04 AM, Chris Burroughs chris.burrou...@gmail.com 
wrote:
No.  If you have a heterogeneous clusters you should consider adjusting the 
number of vnodes per physical node.


On 03/04/2014 10:47 PM, Elliot Finley wrote:
Using Cassandra 2.0.x

If I have a 3 node cluster and 2 of the nodes use spinning drives and 1 of
them uses SSD,  will the majority of the reads be routed to the SSD node
automatically because it has faster responses?

TIA,
Elliot

Re: in AWS is it worth trying to talk to a server in the same zone as your client?

[Russell Bradberry]

Cross zone data transfer does not cost any extra money. 

LOCAL_QUORUM = QUORUM if all 6 servers are located in the same logical 
datacenter.  

Ensure your clients are connecting to either the local IP or the AWS hostname 
that is a CNAME to the local ip from within AWS.  If you connect to the public 
IP you will get charged for outbound data transfer.



On February 12, 2014 at 2:58:07 PM, Yogi Nerella (ynerella...@gmail.com) wrote:

Also, may be you need to check the read consistency to local_quorum, otherwise 
the servers still try to read the data from all other data centers.

I can understand the latency, but I cant understand how it would save money?   
The amount of data transferred from the AWS server to the client should be same 
no matter where the client is connected?
   


On Wed, Feb 12, 2014 at 10:33 AM, Andrey Ilinykh ailin...@gmail.com wrote:
yes, sure. Taking data from the same zone will reduce latency and save you some 
money.


On Wed, Feb 12, 2014 at 10:13 AM, Brian Tarbox tar...@cabotresearch.com wrote:
We're running a C* cluster with 6 servers spread across the four us-east1 zones.

We also spread our clients (hundreds of them) across the four zones.

Currently we give our clients a connection string listing all six servers and 
let C* do its thing.

This is all working just fine...and we're paying a fair bit in AWS transfer 
costs.  There is a suspicion that this transfer cost is driven by us passing 
data around between our C* servers and clients.

Would there be any value to trying to get a client to talk to one of the C* 
servers in its own zone?

I understand (at least partially!) about coordinator nodes and replication and 
know that no matter which server is the coordinator for an operation 
replication may cause bits to get transferred to/from servers in other zones.  
Having said that...is there a chance that trying to encourage a client to 
initially contact a server in its own zone would help?

Thank you,

Brian Tarbox

Re: in AWS is it worth trying to talk to a server in the same zone as your client?

[Russell Bradberry]

Not when using private IP addresses.  That pricing ONLY applies if you are 
using the public interface or EIP/ENI.  If you use the private IP addresses 
there is no cost associated.



On February 12, 2014 at 3:13:58 PM, William Oberman (ober...@civicscience.com) 
wrote:

Same region, cross zone transfer is $0.01 / GB (see 
http://aws.amazon.com/ec2/pricing/, Data Transfer section).


On Wed, Feb 12, 2014 at 3:04 PM, Russell Bradberry rbradbe...@gmail.com wrote:
Cross zone data transfer does not cost any extra money. 

LOCAL_QUORUM = QUORUM if all 6 servers are located in the same logical 
datacenter.  

Ensure your clients are connecting to either the local IP or the AWS hostname 
that is a CNAME to the local ip from within AWS.  If you connect to the public 
IP you will get charged for outbound data transfer.



On February 12, 2014 at 2:58:07 PM, Yogi Nerella (ynerella...@gmail.com) wrote:

Also, may be you need to check the read consistency to local_quorum, otherwise 
the servers still try to read the data from all other data centers.

I can understand the latency, but I cant understand how it would save money?   
The amount of data transferred from the AWS server to the client should be same 
no matter where the client is connected?
   


On Wed, Feb 12, 2014 at 10:33 AM, Andrey Ilinykh ailin...@gmail.com wrote:
yes, sure. Taking data from the same zone will reduce latency and save you some 
money.


On Wed, Feb 12, 2014 at 10:13 AM, Brian Tarbox tar...@cabotresearch.com wrote:
We're running a C* cluster with 6 servers spread across the four us-east1 zones.

We also spread our clients (hundreds of them) across the four zones.

Currently we give our clients a connection string listing all six servers and 
let C* do its thing.

This is all working just fine...and we're paying a fair bit in AWS transfer 
costs.  There is a suspicion that this transfer cost is driven by us passing 
data around between our C* servers and clients.

Would there be any value to trying to get a client to talk to one of the C* 
servers in its own zone?

I understand (at least partially!) about coordinator nodes and replication and 
know that no matter which server is the coordinator for an operation 
replication may cause bits to get transferred to/from servers in other zones.  
Having said that...is there a chance that trying to encourage a client to 
initially contact a server in its own zone would help?

Thank you,

Brian Tarbox

Re: non-vnodes own 0.0% of the ring on nodetool status

[Russell Bradberry]

This is normal as nodetool without specifying a keyspace outputs information 
for the ring as if it is SimpleStrategy with RF=1.  Try specifying a keyspace.



On February 12, 2014 at 4:35:31 PM, Paulo Ricardo Motta Gomes 
(paulo.mo...@chaordicsystems.com) wrote:

Hello,

After adding a new datacenter with virtual nodes enabled, the output of 
nodetool status shows that nodes from the non-vnodes datacenter owns 0.0% of 
the data, as shown below:

Datacenter: NonVnodesDC
=
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address         Load       Tokens  Owns   Host ID                           
    Rack
UN  XX.XXX.XX.XX    many GB      1      0.1%   
  myrack
UN  YY.YYY.YY.YY    many GB      1      0.0%   
  myrack
UN  ZZ.ZZZ.ZZ.ZZ    many GB      1      0.0%   
  myrack
 
Datacenter: VnodesDC
==
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address         Load       Tokens  Owns   Host ID                           
    Rack
UN  AA.AAA.AA.AA    few KB      256     5.8%   
  myrack
UN  BB.BBB.BB.BB    few KB      256     6.6%   
  myrack
UN  CC.CCC.CC.CC    few KB      256     6.9%   
  myrack


Is this a presentation issue on nodetool, or could mean a more serious thing? I 
did exactly the procedure described below to add a new DC: in 
http://www.datastax.com/documentation/cassandra/1.2/webhelp/cassandra/operations/ops_add_dc_to_cluster_t.html
 .

Thank you,

--
Paulo Motta

Chaordic | Platform
www.chaordic.com.br
+55 48 3232.3200
+55 83 9690-1314

Re: CQL list command

[Russell Bradberry]

try SELECT * FROM my_table LIMIT 100;



On February 6, 2014 at 4:02:26 PM, Andrew Cobley (a.e.cob...@dundee.ac.uk) 
wrote:

TL;DR  

Is there a CQL equivalent of the CLI List command ? yes or No?  

Long version  

I often use the CLI command LIST for debugging or when teaching students 
showing them what’s going on under the hood of CQL. I see that CLI swill be 
removed in Cassandra 3 and we will lose this ability. It would be nice if CQL 
retained it, or something like it for debugging and etching purposes.  

Any ideas ?  
Andy  



The University of Dundee is a registered Scottish Charity, No: SC015096  

Re: vnode in production

[Russell Bradberry]

VNodes in production are pretty stable. That being said, I have never heard of 
anyone doing a successful nodetool shuffle”.  A few people have skirted the 
issue by creating a new data center with VNodes enabled and replicating the 
data over.



On January 2, 2014 at 1:52:20 PM, Arindam Barua (aba...@247-inc.com) wrote:

 

Hello all,

 

Just wanted to check if anyone has any experiences to share regarding

1.   the stability of vnodes in production

2.   upgrading to vnodes in production

 

We recently upgraded to 1.2.12 in production and were planning to turn on 
vnodes using the “adding a new datacenter” method vs using shuffle which seems 
to be not recommended. It helps that we were planning to add capacity to our 
Cassandra ring anyway. Our tests in QA so far have been good. If we do not 
upgrade now however, we will have to add the new hosts normally to the ring, 
and may not be able to add a new data center at a later point of time.

 

Thanks,

Arindam