Re: Using CQL to insert a column to a row dynamically

[Tristan Seligmann]

On Mon, May 27, 2013 at 11:38 PM, Matthew Hillsborough <
matthew.hillsboro...@gmail.com> wrote:

> Originally what I thought of doing was creating a column family in
> Cassandra named `ride_events`. Each row key would be a rideID that's simply
> an integer. I would then arbitrarily create columns with a name of the
> following format:
>
> "EventID_5/Day_2/User_6" with a value of null.
>

You can accomplish the same thing with a CQL 3 schema like this:

CREATE TABLE ride_events (
  rideID int,
  eventID int,
  day int,
  userID int,
  dummy text,
  PRIMARY KEY (rideID, eventID, day, userID));

(I'm not sure if the `dummy` column is still required, it was last time I
tried this).

rideID will then be used as the partition key (underlying row key), while
eventID / day / userID will be composited into the underlying storage
engine column names.

An example query against this schema might be:

SELECT userID FROM ride_events WHERE rideID in (...) AND eventID = 5 AND
day = 2;
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

Re: Running Cassandra with no open TCP ports

[Oleg Dulin]

Mark:

This begs a question -- why are you using Cassandra for this ? There 
are simpler noSQL stores than Cassandra that are better for embedding.


Oleg

On 2013-05-28 02:24:48 +, Mark Mccraw said:


Hi All,

I'm using Cassandra as an embedded datastore for a small service that 
doesn't need (or want) to act as a database service in any way.  
Moreover, we may want to start up multiple instances of the 
application, and right now whenever that happens, we get port conflicts 
on 7000 because Cassandra is listening for connections.  I couldn't 
find an obvious way to disable listening on any port.  Is there an easy 
way?


Thanks!
Mark



--
Regards,
Oleg Dulin
http://www.olegdulin.com

Re: Running Cassandra with no open TCP ports

[Edward Capriolo]

While not exactly optimized for embedded systems there is no reason it
could not be done. Today's super computer is tomorrows embedded watch
processor.


On Tue, May 28, 2013 at 9:11 AM, Oleg Dulin  wrote:

> Mark:
>
> This begs a question -- why are you using Cassandra for this ? There are
> simpler noSQL stores than Cassandra that are better for embedding.
>
> Oleg
>
> On 2013-05-28 02:24:48 +, Mark Mccraw said:
>
>  Hi All,
>>
>> I'm using Cassandra as an embedded datastore for a small service that
>> doesn't need (or want) to act as a database service in any way.  Moreover,
>> we may want to start up multiple instances of the application, and right
>> now whenever that happens, we get port conflicts on 7000 because Cassandra
>> is listening for connections.  I couldn't find an obvious way to disable
>> listening on any port.  Is there an easy way?
>>
>> Thanks!
>> Mark
>>
>
>
> --
> Regards,
> Oleg Dulin
> http://www.olegdulin.com
>
>
>

Re: Using CQL to insert a column to a row dynamically

[Edward Capriolo]

Or just:
cli >
create column family ride_events with
comparator(Int32Type,Int32Type,Int32Type);


On Tue, May 28, 2013 at 4:45 AM, Tristan Seligmann
wrote:

> On Mon, May 27, 2013 at 11:38 PM, Matthew Hillsborough <
> matthew.hillsboro...@gmail.com> wrote:
>
>> Originally what I thought of doing was creating a column family in
>> Cassandra named `ride_events`. Each row key would be a rideID that's simply
>> an integer. I would then arbitrarily create columns with a name of the
>> following format:
>>
>> "EventID_5/Day_2/User_6" with a value of null.
>>
>
> You can accomplish the same thing with a CQL 3 schema like this:
>
> CREATE TABLE ride_events (
>   rideID int,
>   eventID int,
>   day int,
>   userID int,
>   dummy text,
>   PRIMARY KEY (rideID, eventID, day, userID));
>
> (I'm not sure if the `dummy` column is still required, it was last time I
> tried this).
>
> rideID will then be used as the partition key (underlying row key), while
> eventID / day / userID will be composited into the underlying storage
> engine column names.
>
> An example query against this schema might be:
>
> SELECT userID FROM ride_events WHERE rideID in (...) AND eventID = 5 AND
> day = 2;
> --
> mithrandi, i Ainil en-Balandor, a faer Ambar
>

Cleanup understastanding

[Víctor Hugo Oliveira Molinar]

Hello everyone.
I have a daily maintenance task at c* which does:

-truncate cfs
-clearsnapshots
-repair
-cleanup

The reason I need to clean things is that I wont need most of my inserted
data on the next day. It's kind a business requirement.

Well,  the problem I'm running to, is the misunderstanding about cleanup
operation.
I have 2 nodes with lower than half usage of disk, which is moreless 13GB;

But, the last few days, arbitrarily each node have reported me a cleanup
error indicating that the disk was full. Which is not true.

*Error occured during cleanup*
*java.util.concurrent.ExecutionException: java.io.IOException: disk full*


So I'd like to know more about what does happens in a cleanup operation.
Appreciate any help.

Cassandra on a single (under-powered) instance?

[Daniel Morton]

Hello All.

I am new to Cassandra and I am evaluating it for a project I am working on.

This project has several distribution models, ranging from a cloud
distribution where we would be collecting hundreds of millions of rows per
day to a single box distribution where we could be collecting as few as 5
to 10 million rows per day.

Based on the experimentation and testing I have done so far, I believe that
Cassandra would be an excellent fit for our large scale cloud distribution,
but from a maintenance/support point of view, we would like to keep our
storage engine consistent across all distributions.

For our single box distribution, it could be running on a box as small as
an i3 processor with 4 GB of RAM and about 180 GB of disk base available
for use... A rough estimate would be that our storage engine could be
allowed to consume about half of the processor and RAM resources.

I know that running Cassandra on a single instance throws away the majority
of the benefits of using a distribution storage solution (distributed
writes and reads, fault tolerance, etc.), but it might be worth the trade
off if we don't have to support two completely different storage solutions,
even if they were hidden behind an abstraction layer from the application's
point of view.

My question is, are we completely out-to-lunch thinking that we might be
able to run Cassandra in a reasonable way on such an under-powered box?  I
believe I recall reading in the Datastax documentation that the minimum
recommended system requirements are 8 to 12 cores and 8 GB of RAM, which is
a far cry from the lowest-end machine I'm considering.

Any info or help anyone could provide would be most appreciated.

Regards,

Daniel Morton

weird token ownerships

[Hiller, Dean]

I was assuming my node a1 would always own token 0, but we just added 5 of 6 
more nodes and a1 no longer owns that token range.

I have a few questions on the table at the bottom

 1.  Is this supposed to happen where host a1 no longer owns token range 0(but 
that is in his cassandra.yaml file), but instead a2, a8, and a7 own the token 
range now?  (this happened after adding nodes)
 2.  If I run nodetool repair –pr on node a1, it is going to run repair for 
token range 0 on nodes a2, a7, and a8?  Is that correct?
 3.  I now need all 4 nodes up to run repair instead of just the three nodes, 
correct?  Since a1 owns token 0 in cassandra.yaml.

(Make your window wide enough so this table shows up properly)…

a1 UP Normal 292.24 GB 33.3% 00 NA 1733.92 7860.00 a2, a8, a7 1.2.2-SNAPSHOT
a7 UP Normal 196.76 GB 25.0% 14178431955039102644307275309657008810 0 NA 
4042.77 7860.00 a2, a3, a8 1.2.2-SNAPSHOT
a2 UP Normal 249.04 GB 25.0% 28356863910078205288614550619314017621 0 NA 
5690.07 7862.00 a3, a8, a9 1.2.2-SNAPSHOT
a8 UP Normal 114.54 GB 25.0% 42535295865117307932921825928971026432 0 NA 
4219.95 7860.00 a3, a4, a9 1.2.2-SNAPSHOT
a3 UP Normal 246.88 GB 25.0% 56713727820156410577229101238628035242 0 NA 
4175.78 7862.00 a4, a9, a10 1.2.2-SNAPSHOT
a9 UP Normal 119.94 GB 25.0% 70892159775195513221536376548285044053 0 NA 
2981.60 7860.00 a4, a5, a10 1.2.2-SNAPSHOT
a4 UP Normal 232.92 GB 25.0% 85070591730234615865843651857942052863 0 NA 
4840.72 7862.00 a5, a10, a6 1.2.2-SNAPSHOT
a10 UP Normal 114.3 GB 25.0% 99249023685273718510150927167599061674 00 NA 0 
3682.63 7860.00 a12, a5, a6 1.2.2-SNAPSHOT
a5 UP Normal 259.34 GB 25.0% 113427455640312821154458202477256070484 0 NA 
5258.74 7862.00 a12, a1, a6 1.2.2-SNAPSHOT
a6 DO Normal 248.36 GB 33.3% 141784319550391026443072753096570088105 0 NA 
4042.77 7860.00 a12, a1, a7 1.2.2-SNAPSHOT
a12 UP Normal 206.63 GB 33.3% 155962751505430129087380028406227096917 02 NA 2 
5112.88 7862.00 a2, a1, a7 1.2.2-SNAPSHOT

Re: Running Cassandra with no open TCP ports

[Mark Mccraw]

Oleg:  The simple answer for why I'm using Cassandra thusly is laziness/fear of 
uncertainty.  I'm using Cassandra indirectly as the back end data store for 
Titan(http://thinkaurelius.github.io/titan/), which is a graph interface.  
Titan does let you swap out the data store, and it gives you several "canned" 
choices, one of which is Cassandra.  BerkeleyDB might be a better choice for 
this project (and would address this issue), but it has licensing issues, so 
it's out, thus leaving me with using Cassandra or figuring out how to make 
Titan play with something like Derby.  That's a project I just don't have time 
for or interest in.  Apache HBase is another alternative, but that really seems 
like shooting a fly with an elephant gun...

Edward, I completely agree that it should be doable.  Is this something that 
you would advise a simple user to tackle (i.e. does it make any sense at all 
for me to pull down the Cassandra codebase and try to figure out where the 
relevant code lives and what to change), or is it something the maintainers are 
likely to be willing to slip in as a simple feature?  If the latter, do I just 
file a feature request somewhere?

Thanks!
Mark McCraw
mark.mcc...@sas.com



On May 28, 2013, at 9:51 AM, Edward Capriolo wrote:

While not exactly optimized for embedded systems there is no reason it could 
not be done. Today's super computer is tomorrows embedded watch processor.


On Tue, May 28, 2013 at 9:11 AM, Oleg Dulin 
mailto:oleg.du...@gmail.com>> wrote:
Mark:

This begs a question -- why are you using Cassandra for this ? There are 
simpler noSQL stores than Cassandra that are better for embedding.

Oleg

On 2013-05-28 02:24:48 +, Mark Mccraw said:

Hi All,

I'm using Cassandra as an embedded datastore for a small service that doesn't 
need (or want) to act as a database service in any way.  Moreover, we may want 
to start up multiple instances of the application, and right now whenever that 
happens, we get port conflicts on 7000 because Cassandra is listening for 
connections.  I couldn't find an obvious way to disable listening on any port.  
Is there an easy way?

Thanks!
Mark


--
Regards,
Oleg Dulin
http://www.olegdulin.com

Re: weird token ownerships

[Hiller, Dean]

Sorry, missed some info.  The table is sorted by token and the very first
column is the node with that token in the cassandra.yaml file.  The second
to last column of 3 hostnames is the nodes that ended up with that data
according to nodetool describering so taking the first row, a1 owns token
0 and the data exists on nodes a2, a3, and a4 but not on a1.

You can see us inserting node a7 between a1 and a2, and inserting node a8
between node a2 and a3, etc. etc.

Thanks,
Dean

On 5/28/13 8:46 AM, "Hiller, Dean"  wrote:

>I was assuming my node a1 would always own token 0, but we just added 5
>of 6 more nodes and a1 no longer owns that token range.
>
>I have a few questions on the table at the bottom
>
> 1.  Is this supposed to happen where host a1 no longer owns token range
>0(but that is in his cassandra.yaml file), but instead a2, a8, and a7 own
>the token range now?  (this happened after adding nodes)
> 2.  If I run nodetool repair ­pr on node a1, it is going to run repair
>for token range 0 on nodes a2, a7, and a8?  Is that correct?
> 3.  I now need all 4 nodes up to run repair instead of just the three
>nodes, correct?  Since a1 owns token 0 in cassandra.yaml.
>
>(Make your window wide enough so this table shows up properly)Š
>
>a1 UP Normal 292.24 GB 33.3% 00 NA 1733.92 7860.00 a2, a8, a7
>1.2.2-SNAPSHOT
>a7 UP Normal 196.76 GB 25.0% 14178431955039102644307275309657008810 0 NA
>4042.77 7860.00 a2, a3, a8 1.2.2-SNAPSHOT
>a2 UP Normal 249.04 GB 25.0% 28356863910078205288614550619314017621 0 NA
>5690.07 7862.00 a3, a8, a9 1.2.2-SNAPSHOT
>a8 UP Normal 114.54 GB 25.0% 42535295865117307932921825928971026432 0 NA
>4219.95 7860.00 a3, a4, a9 1.2.2-SNAPSHOT
>a3 UP Normal 246.88 GB 25.0% 56713727820156410577229101238628035242 0 NA
>4175.78 7862.00 a4, a9, a10 1.2.2-SNAPSHOT
>a9 UP Normal 119.94 GB 25.0% 70892159775195513221536376548285044053 0 NA
>2981.60 7860.00 a4, a5, a10 1.2.2-SNAPSHOT
>a4 UP Normal 232.92 GB 25.0% 85070591730234615865843651857942052863 0 NA
>4840.72 7862.00 a5, a10, a6 1.2.2-SNAPSHOT
>a10 UP Normal 114.3 GB 25.0% 99249023685273718510150927167599061674 00 NA
>0 3682.63 7860.00 a12, a5, a6 1.2.2-SNAPSHOT
>a5 UP Normal 259.34 GB 25.0% 113427455640312821154458202477256070484 0 NA
>5258.74 7862.00 a12, a1, a6 1.2.2-SNAPSHOT
>a6 DO Normal 248.36 GB 33.3% 141784319550391026443072753096570088105 0 NA
>4042.77 7860.00 a12, a1, a7 1.2.2-SNAPSHOT
>a12 UP Normal 206.63 GB 33.3% 155962751505430129087380028406227096917 02
>NA 2 5112.88 7862.00 a2, a1, a7 1.2.2-SNAPSHOT

Re: Running Cassandra with no open TCP ports

[Sam Overton]

You can configure cassandra to use an ephemeral port for the storage
endpoint by setting the following in cassandra.yaml:
storage_port: 0

or by setting the system property cassandra.storage_port=0

Similarly for the RPC (thrift) endpoint, using rpc_port in cassandra.yaml
or the system property cassandra.rpc_port

Regards,

Sam


On 28 May 2013 03:24, Mark Mccraw  wrote:

>  Hi All,
>
>  I'm using Cassandra as an embedded datastore for a small service that
> doesn't need (or want) to act as a database service in any way.  Moreover,
> we may want to start up multiple instances of the application, and right
> now whenever that happens, we get port conflicts on 7000 because Cassandra
> is listening for connections.  I couldn't find an obvious way to disable
> listening on any port.  Is there an easy way?
>
>  Thanks!
>  Mark
>
>
>
>


-- 
Sam Overton
Acunu | http://www.acunu.com | @acunu

Re: Cleanup understastanding

[Andrey Ilinykh]

cleanup removes data which doesn't belong to the current node. You have to
run it only if you move (or add new) nodes. In your case there is no any
reason to do it.


On Tue, May 28, 2013 at 7:39 AM, Víctor Hugo Oliveira Molinar <
vhmoli...@gmail.com> wrote:

> Hello everyone.
> I have a daily maintenance task at c* which does:
>
> -truncate cfs
> -clearsnapshots
> -repair
> -cleanup
>
> The reason I need to clean things is that I wont need most of my inserted
> data on the next day. It's kind a business requirement.
>
> Well,  the problem I'm running to, is the misunderstanding about cleanup
> operation.
> I have 2 nodes with lower than half usage of disk, which is moreless 13GB;
>
> But, the last few days, arbitrarily each node have reported me a cleanup
> error indicating that the disk was full. Which is not true.
>
> *Error occured during cleanup*
> *java.util.concurrent.ExecutionException: java.io.IOException: disk full*
>
>
> So I'd like to know more about what does happens in a cleanup operation.
> Appreciate any help.
>

Re: Cleanup understastanding

[Robert Coli]

On Tue, May 28, 2013 at 7:39 AM, Víctor Hugo Oliveira Molinar
 wrote:
> So I'd like to know more about what does happens in a cleanup operation.
> Appreciate any help.

./src/java/org/apache/cassandra/db/compaction/CompactionManager.java"
line 591 of 1175
"
logger.info("Cleaning up " + sstable);
// Calculate the expected compacted filesize
long expectedRangeFileSize =
cfs.getExpectedCompactedFileSize(Arrays.asList(sstable),
OperationType.CLEANUP);
File compactionFileLocation =
cfs.directories.getDirectoryForNewSSTables(expectedRangeFileSize);
if (compactionFileLocation == null)
throw new IOException("disk full");
"

It looks like it is actually saying your disk is "too full to complete
compaction", not actually full right now.

That said, a cleanup compaction does a 1:1 traversal of all SSTables,
writing out a new one without any data that no longer belongs on the
node due to range ownership changes. There is some lag in Cassandra
before the JVM is able to actually delete files from disk, perhaps you
are hitting this race condition?

=Rob

Re: Suggested Ruby client using Cassandra 1.2.5

[aaron morton]

Go with the twitter client that is more mature / under active development.

If you are just starting out / experimenting Thrift is fine to use, it's not 
going away. As you get more experience you may start to prefer CQL and by that 
time their may be a ruby/C driver.

Cheers
 
-
Aaron Morton
Freelance Cassandra Consultant
New Zealand

@aaronmorton
http://www.thelastpickle.com

On 27/05/2013, at 12:05 PM, Matthew Hillsborough 
 wrote:

> Hi all,
> 
> I am interested in using Cassandra in a Ruby on Rails project.
> 
> After a quick search on GitHub, there seems to be two clients that
> stick out for use with Ruby:
> 
> * https://github.com/twitter/cassandra
> * https://github.com/kreynolds/cassandra-cql
> 
> The documentation I've read suggested that users of 1.2.5 should use
> CQL vs Thrift in their client. That would point all signs to trying
> the cassandra-cql client first since the Twitter client is Thrift
> based.
> 
> My concern is that it seems the Twitter client has a larger community
> and has more recent commits made to it.
> 
> I'm not entirely sure where the best place to start is; but if anyone
> here works extensively with Ruby and/or Rails and can suggest a client
> that DataStax and/or the community suggests to use, that would be
> great.
> 
> Thank you for any and all recommendations.
> 
> Matthew.

Re: how to handle join properly in this case

[aaron morton]

A common pattern is to materialise views, that is store the join at the same 
time you are writing to CF's A and B. 

In this case it sounds like the two CF's are written to at different times. If 
that is the case you may need to do the join client side (do two reads).

Hope that helps. 
 
-
Aaron Morton
Freelance Cassandra Consultant
New Zealand

@aaronmorton
http://www.thelastpickle.com

On 27/05/2013, at 6:56 PM, Vegard Berget  wrote:

> Hi,
> 
> I am no expert, but a couple of suggestions:
> 1)  Remember that writes are very fast i Cassandra, so don't be afraid to 
> store more information than you would in an Sql-ish server. 
> 2)  It would be better with an example, but again - by storing more than you 
> would in an sql-schema, would you still need to compute a table C?  Is it 
> possible to have just the CF A, and have all data in that CF?  Would it be 
> possible/easier to have the rules applied on the client, so that you don't 
> have to change the schema/recalculate CF C?  
> 
> .vegard,
> 
> - Original Message -
> From:
> user@cassandra.apache.org
> 
> To:
> 
> Cc:
> 
> Sent:
> Sat, 25 May 2013 15:22:00 -0700
> Subject:
> how to handle join properly in this case
> 
> 
> Hi Experts,
> 
> We have tables (a.k.a. column family) A and B. The row of the table is
> simply a key value pair. Table A and B are written by clients all the
> time. We need to transform the row key of table A and B according to
> a set of rules, join these two tables and save the results to table C
> for read.
> 
> Questions
> 1) Schema like this is very close to a schema in SQL. We mainly want
> to separate read and write operations by different column families. Is
> this a correct way to model the join in Cassandra?
> 
> 2) If the rules change a little bit, which is quite possible, we will
> have to drop table C, and recompute the join result, which seems to be
> cumbersome because not all the join results need to be changed, just
> some of them. Are there any better ways to handle such change?
> 
> Thanks a lot.
> 
> 
> --
> Regards,
> Jiaan

Re: Cassandra read reapair

[aaron morton]

Start using QUOURM for reads and writes and then run a nodetool repair. 

That should get you back to the land of the consistent. 

Cheers

-
Aaron Morton
Freelance Cassandra Consultant
New Zealand

@aaronmorton
http://www.thelastpickle.com

On 27/05/2013, at 10:01 PM, Kais Ahmed  wrote:

> Hi aaron,
> 
> I was sure that  phpcassa use QUORUM for W and R by default, but you're 
> right, the default CL for R AND W is ONE.
> 
> We are in this configuration W + R < N, how can i do to repair some keys that 
> always return inconsistent data.
> 
> Thanks,
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 2013/5/24 Kais Ahmed 
> Hi aaron an thanks,
> 
> 
> > If you are reading and writing at CL QUOURM and getting inconsistent 
> > results that sounds like a bug. If you are mixing the CL levels such that R 
> > + W <= N then it's expected behaviour. 
> I think it's a bug, it concern only some keys (~200 over 120 000 keys) on one 
> column family, 
> 
> As I understand it, if  R+W <= N it's expected behaviour at a moment, but 
> read repair will correct the inconsistent data (related to read_repair_chance 
> value)
> and the next query will return a consistent data , right ?
> 
> Here is an exemple of a result that i have on a key (keyspace RF 3), 3 
> differents replicas :
> 
> [default@prod] ASSUME contacts_timeordered KEYS AS ascii;
> 
> [default@prod] get contacts_timeordered['1425185-IGNORED'];
> => (column=1a927740-97ec-11e2-ab16-a1afd66a735e, value=363838353936, 
> timestamp=1364505108842098)
> => (column=1a93d5b0-97ec-11e2-888c-2bf068e0f754, value=31373930303330, 
> timestamp=1364505108851088)
> => (column=b5c559c0-9d0f-11e2-8682-f7ecd4112689, value=32343130303930, 
> timestamp=1365070157421869)
> => (column=7ba22b90-b48b-11e2-a2c2-914573921d9f, value=32353031353039, 
> timestamp=1367652194221857)
> => (column=63ef5d80-b7e8-11e2-abf8-593c289227cd, value=32383435323830, 
> timestamp=1368021951146575)
> => (column=d6383fc0-b810-11e2-a880-bd2ecacbaee3, value=31363334363737, 
> timestamp=1368039322753824)
> => (column=f47d8e60-bd3f-11e2-88f4-533a93fe9432, value=32373938313038, 
> timestamp=1368609315699785)
> => (column=c5bfe060-bf8e-11e2-ab1f-07be407aff58, value=32333634353034, 
> timestamp=1368863069848610)
> => (column=f07ae4b0-c42f-11e2-8064-9794e872eb2b, value=363838353936, 
> timestamp=1369372095163129)
> Returned 9 results.
> Elapsed time: 10 msec(s).
> 
> [default@prod] get contacts_timeordered['1425185-IGNORED'];
> => (column=b5c559c0-9d0f-11e2-8682-f7ecd4112689, value=32343130303930, 
> timestamp=1365070157421869)
> => (column=7ba22b90-b48b-11e2-a2c2-914573921d9f, value=32353031353039, 
> timestamp=1367652194221857)
> => (column=63ef5d80-b7e8-11e2-abf8-593c289227cd, value=32383435323830, 
> timestamp=1368021951146575)
> => (column=d6383fc0-b810-11e2-a880-bd2ecacbaee3, value=31363334363737, 
> timestamp=1368039322753824)
> => (column=f47d8e60-bd3f-11e2-88f4-533a93fe9432, value=32373938313038, 
> timestamp=1368609315699785)
> => (column=c5bfe060-bf8e-11e2-ab1f-07be407aff58, value=32333634353034, 
> timestamp=1368863069848610)
> => (column=f07ae4b0-c42f-11e2-8064-9794e872eb2b, value=363838353936, 
> timestamp=1369372095163129)
> Returned 7 results.
> Elapsed time: 7.49 msec(s).
> 
> [default@prod] get contacts_timeordered['1425185-IGNORED'];
> => (column=1a93d5b0-97ec-11e2-888c-2bf068e0f754, value=31373930303330, 
> timestamp=1364505108851088)
> => (column=b5c559c0-9d0f-11e2-8682-f7ecd4112689, value=32343130303930, 
> timestamp=1365070157421869)
> => (column=7ba22b90-b48b-11e2-a2c2-914573921d9f, value=32353031353039, 
> timestamp=1367652194221857)
> => (column=63ef5d80-b7e8-11e2-abf8-593c289227cd, value=32383435323830, 
> timestamp=1368021951146575)
> => (column=d6383fc0-b810-11e2-a880-bd2ecacbaee3, value=31363334363737, 
> timestamp=1368039322753824)
> => (column=f47d8e60-bd3f-11e2-88f4-533a93fe9432, value=32373938313038, 
> timestamp=1368609315699785)
> => (column=c5bfe060-bf8e-11e2-ab1f-07be407aff58, value=32333634353034, 
> timestamp=1368863069848610)
> => (column=f07ae4b0-c42f-11e2-8064-9794e872eb2b, value=363838353936, 
> timestamp=1369372095163129)
> Returned 8 results.
> Elapsed time: 9.37 msec(s).
> 
> Do I have to change read_repair_chance to 1 to correct the inconsistency, 
> nodetool repair don't solve it.
> 
> Thanks a lot,
> 
> 
> 
> 
> 
> 2013/5/23 aaron morton 
> If you are reading and writing at CL QUOURM and getting inconsistent results 
> that sounds like a bug. If you are mixing the CL levels such that R + W <= N 
> then it's expected behaviour. 
> 
> 
> Can you reproduce the issue outside of your app ? 
> 
> Cheers
> 
> -
> Aaron Morton
> Freelance Cassandra Consultant
> New Zealand
> 
> @aaronmorton
> http://www.thelastpickle.com
> 
> On 21/05/2013, at 8:55 PM, Kais Ahmed  wrote:
> 
>> > Checking you do not mean the row key is corrupt and cannot be read. 
>> Yes, i can read it but all read don't return the same result except for CL 
>> ALL
>> 
>> > By default in 1.X and b

Re: how to handle join properly in this case

[Hiller, Dean]

Another option is joins on partitions to keep the number of stuff needing
to join relatively small.  PlayOrm actually supports joins of partition 1
of table A with partition X of table B.  You then just keep the number of
rows in each partition at less than millions and you can filter with the
where clause.  It is yet another option out there.  By doing so, you still
remain scalable as long as you design such that partitions don't grow to
large(you can have as many partitions as you want though).

Later,
Dean

On 5/28/13 12:33 PM, "aaron morton"  wrote:

>A common pattern is to materialise views, that is store the join at the
>same time you are writing to CF's A and B.
>
>In this case it sounds like the two CF's are written to at different
>times. If that is the case you may need to do the join client side (do
>two reads).
>
>Hope that helps. 
> 
>-
>Aaron Morton
>Freelance Cassandra Consultant
>New Zealand
>
>@aaronmorton
>http://www.thelastpickle.com
>
>On 27/05/2013, at 6:56 PM, Vegard Berget  wrote:
>
>> Hi,
>> 
>> I am no expert, but a couple of suggestions:
>> 1)  Remember that writes are very fast i Cassandra, so don't be afraid
>>to store more information than you would in an Sql-ish server.
>> 2)  It would be better with an example, but again - by storing more
>>than you would in an sql-schema, would you still need to compute a table
>>C?  Is it possible to have just the CF A, and have all data in that CF?
>>Would it be possible/easier to have the rules applied on the client, so
>>that you don't have to change the schema/recalculate CF C?
>> 
>> .vegard,
>> 
>> - Original Message -
>> From:
>> user@cassandra.apache.org
>> 
>> To:
>> 
>> Cc:
>> 
>> Sent:
>> Sat, 25 May 2013 15:22:00 -0700
>> Subject:
>> how to handle join properly in this case
>> 
>> 
>> Hi Experts,
>> 
>> We have tables (a.k.a. column family) A and B. The row of the table is
>> simply a key value pair. Table A and B are written by clients all the
>> time. We need to transform the row key of table A and B according to
>> a set of rules, join these two tables and save the results to table C
>> for read.
>> 
>> Questions
>> 1) Schema like this is very close to a schema in SQL. We mainly want
>> to separate read and write operations by different column families. Is
>> this a correct way to model the join in Cassandra?
>> 
>> 2) If the rules change a little bit, which is quite possible, we will
>> have to drop table C, and recompute the join result, which seems to be
>> cumbersome because not all the join results need to be changed, just
>> some of them. Are there any better ways to handle such change?
>> 
>> Thanks a lot.
>> 
>> 
>> --
>> Regards,
>> Jiaan
>

data clean up problem

[cem]

Hi Experts,

We have general problem about cleaning up data from the disk. I need to
free the disk space after retention period and the customer wants to
dimension the disk space base on that.

After running multiple performance tests with TTL of 1 day we saw that the
compaction couldn't keep up with the request rate. Disks were getting full
after 3 days. There were also a lot of sstables that are older than 1 day
after 3 days.

Things that we tried:

-Change the compaction strategy to leveled. (helped a bit but not much)

-Use big sstable size (10G) with leveled compaction to have more aggressive
compaction.(helped a bit but not much)

-Upgrade Cassandra from 1.0 to 1.2 to use TTL histograms (didn't help at
all since it has key overlapping estimation algorithm that generates %100
match. Although we don't have...)

Our column family structure is like this:

Event_data_cf: (we store event data. Event_id  is randomly generated and
each event has attributes like location=london)

row  data

event id  data blob

timeseries_cf: (key is the attribute that we want to index. It can be
location=london, we didnt use secondary indexes because the indexes are
dynamic.)

row  data

index key   time series of event id (event1_id, event2_id….)

timeseries_inv_cf: (this is used for removing event by event row key. )

row  data

event id  set of index keys

Candidate Solution: Implementing time range partitions.

Each partition will have column family set and will be managed by client.

Suppose that you want to have 7 days retention period. Then you can
configure the partition size as 1 day and have 7 active partitions at any
time. Then you can drop inactive partitions (older that 7 days). Dropping
will immediate remove the data from the disk. (With proper Cassandra.yaml
configuration)

Storing an event:

Find the current partition p1

store to event_data to Event_data_cf_p1

store to indexes to timeseries_cff_p1

store to inverted indexes to timeseries_inv_cf_p1


A time range query with an index:

Find the all partitions belongs to that time range

Do read starting from the first partition until you reach to limit

.

Could you please provide your comments and concerns ?

Is there any other option that we can try?

What do you think about the candidate solution?

Does anyone have the same issue? How would you solve it in another way?


Thanks in advance!

Cem

Re: data clean up problem

[Edward Capriolo]

You need to change the gc_grace time of the column family. It defaults to
10 days. By default the tombstones will not go away for 10 days.


On Tue, May 28, 2013 at 2:46 PM, cem  wrote:

> Hi Experts,
>
> We have general problem about cleaning up data from the disk. I need to
> free the disk space after retention period and the customer wants to
> dimension the disk space base on that.
>
> After running multiple performance tests with TTL of 1 day we saw that the
> compaction couldn't keep up with the request rate. Disks were getting full
> after 3 days. There were also a lot of sstables that are older than 1 day
> after 3 days.
>
> Things that we tried:
>
> -Change the compaction strategy to leveled. (helped a bit but not much)
>
> -Use big sstable size (10G) with leveled compaction to have more
> aggressive compaction.(helped a bit but not much)
>
> -Upgrade Cassandra from 1.0 to 1.2 to use TTL histograms (didn't help at
> all since it has key overlapping estimation algorithm that generates %100
> match. Although we don't have...)
>
> Our column family structure is like this:
>
> Event_data_cf: (we store event data. Event_id  is randomly generated and
> each event has attributes like location=london)
>
> row  data
>
> event id  data blob
>
> timeseries_cf: (key is the attribute that we want to index. It can be
> location=london, we didnt use secondary indexes because the indexes are
> dynamic.)
>
> row  data
>
> index key   time series of event id (event1_id, event2_id….)
>
> timeseries_inv_cf: (this is used for removing event by event row key. )
>
> row  data
>
> event id  set of index keys
>
> Candidate Solution: Implementing time range partitions.
>
> Each partition will have column family set and will be managed by client.
>
> Suppose that you want to have 7 days retention period. Then you can
> configure the partition size as 1 day and have 7 active partitions at any
> time. Then you can drop inactive partitions (older that 7 days). Dropping
> will immediate remove the data from the disk. (With proper Cassandra.yaml
> configuration)
>
> Storing an event:
>
> Find the current partition p1
>
> store to event_data to Event_data_cf_p1
>
> store to indexes to timeseries_cff_p1
>
> store to inverted indexes to timeseries_inv_cf_p1
>
>
> A time range query with an index:
>
> Find the all partitions belongs to that time range
>
> Do read starting from the first partition until you reach to limit
>
> .
>
> Could you please provide your comments and concerns ?
>
> Is there any other option that we can try?
>
> What do you think about the candidate solution?
>
> Does anyone have the same issue? How would you solve it in another way?
>
>
> Thanks in advance!
>
> Cem
>

Deadline Extension: 2013 Workshop on Middleware for HPC and Big Data Systems (MHPC'13)

[MHPC 2013]

we apologize if you receive multiple copies of this message

===

CALL FOR PAPERS

2013 Workshop on

Middleware for HPC and Big Data Systems

MHPC '13

as part of Euro-Par 2013, Aachen, Germany

===

Date: August 27, 2012

Workshop URL: http://m-hpc.org

Springer LNCS

SUBMISSION DEADLINE:

June 10, 2013 - LNCS Full paper submission (extended)
June 28, 2013 - Lightning Talk abstracts


SCOPE

Extremely large, diverse, and complex data sets are generated from
scientific applications, the Internet, social media and other applications.
Data may be physically distributed and shared by an ever larger community.
Collecting, aggregating, storing and analyzing large data volumes
presents major challenges. Processing such amounts of data efficiently
has been an issue to scientific discovery and technological
advancement. In addition, making the data accessible, understandable and
interoperable includes unsolved problems. Novel middleware architectures,
algorithms, and application development frameworks are required.

In this workshop we are particularly interested in original work at the
intersection of HPC and Big Data with regard to middleware handling
and optimizations. Scope is existing and proposed middleware for HPC
and big data, including analytics libraries and frameworks.

The goal of this workshop is to bring together software architects,
middleware and framework developers, data-intensive application developers
as well as users from the scientific and engineering community to exchange
their experience in processing large datasets and to report their scientific
achievement and innovative ideas. The workshop also offers a dedicated forum
for these researchers to access the state of the art, to discuss problems
and requirements, to identify gaps in current and planned designs, and to
collaborate in strategies for scalable data-intensive computing.

The workshop will be one day in length, composed of 20 min paper
presentations, each followed by 10 min discussion sections.
Presentations may be accompanied by interactive demonstrations.


TOPICS

Topics of interest include, but are not limited to:

- Middleware including: Hadoop, Apache Drill, YARN, Spark/Shark, Hive,
Pig, Sqoop,
HBase, HDFS, S4, CIEL, Oozie, Impala, Storm and Hyrack
- Data intensive middleware architecture
- Libraries/Frameworks including: Apache Mahout, Giraph, UIMA and GraphLab
- NG Databases including Apache Cassandra, MongoDB and CouchDB/Couchbase
- Schedulers including Cascading
- Middleware for optimized data locality/in-place data processing
- Data handling middleware for deployment in virtualized HPC environments
- Parallelization and distributed processing architectures at the
middleware level
- Integration with cloud middleware and application servers
- Runtime environments and system level support for data-intensive computing
- Skeletons and patterns
- Checkpointing
- Programming models and languages
- Big Data ETL
- Stream processing middleware
- In-memory databases for HPC
- Scalability and interoperability
- Large-scale data storage and distributed file systems
- Content-centric addressing and networking
- Execution engines, languages and environments including CIEL/Skywriting
- Performance analysis, evaluation of data-intensive middleware
- In-depth analysis and performance optimizations in existing data-handling
middleware, focusing on indexing/fast storing or retrieval between compute
and storage nodes
- Highly scalable middleware optimized for minimum communication
- Use cases and experience for popular Big Data middleware
- Middleware security, privacy and trust architectures

DATES

Papers:
Rolling abstract submission
June 10, 2013 - Full paper submission (extended)
July 8, 2013 - Acceptance notification
October 3, 2013 - Camera-ready version due

Lightning Talks:
June 28, 2013 - Deadline for lightning talk abstracts
July 15, 2013 - Lightning talk notification

August 27, 2013 - Workshop Date


TPC

CHAIR

Michael Alexander (chair), TU Wien, Austria
Anastassios Nanos (co-chair), NTUA, Greece
Jie Tao (co-chair), Karlsruhe Institut of Technology, Germany
Lizhe Wang (co-chair), Chinese Academy of Sciences, China
Gianluigi Zanetti (co-chair), CRS4, Italy

PROGRAM COMMITTEE

Amitanand Aiyer, Facebook, USA
Costas Bekas, IBM, Switzerland
Jakob Blomer, CERN, Switzerland
William Gardner, University of Guelph, Canada
José Gracia, HPC Center of the University of Stuttgart, Germany
Zhenghua Guom,  Indiana University, USA
Marcus Hardt,  Karlsruhe Institute of Technology, Germany
Sverre Jarp, CERN, Switzerland
Christopher Jung,  Karlsruhe Institute of Technology, Germany
Andreas Knüpfer - Technische Universität Dresden, Germany
Nectarios Koziris, National Technical University of Athens, Greece
Yan Ma, Chinese Academy of Sciences, China
Martin Schulz - Lawrence Livermore National Laboratory
V

Re: data clean up problem

[cem]

Thanks for the answer but it is already set to 0 since I don't do any
delete.

Cem


On Tue, May 28, 2013 at 9:03 PM, Edward Capriolo wrote:

> You need to change the gc_grace time of the column family. It defaults to
> 10 days. By default the tombstones will not go away for 10 days.
>
>
> On Tue, May 28, 2013 at 2:46 PM, cem  wrote:
>
>> Hi Experts,
>>
>> We have general problem about cleaning up data from the disk. I need to
>> free the disk space after retention period and the customer wants to
>> dimension the disk space base on that.
>>
>> After running multiple performance tests with TTL of 1 day we saw that
>> the compaction couldn't keep up with the request rate. Disks were getting
>> full after 3 days. There were also a lot of sstables that are older than 1
>> day after 3 days.
>>
>> Things that we tried:
>>
>> -Change the compaction strategy to leveled. (helped a bit but not much)
>>
>> -Use big sstable size (10G) with leveled compaction to have more
>> aggressive compaction.(helped a bit but not much)
>>
>> -Upgrade Cassandra from 1.0 to 1.2 to use TTL histograms (didn't help at
>> all since it has key overlapping estimation algorithm that generates %100
>> match. Although we don't have...)
>>
>> Our column family structure is like this:
>>
>> Event_data_cf: (we store event data. Event_id  is randomly generated and
>> each event has attributes like location=london)
>>
>> row  data
>>
>> event id  data blob
>>
>> timeseries_cf: (key is the attribute that we want to index. It can be
>> location=london, we didnt use secondary indexes because the indexes are
>> dynamic.)
>>
>> row  data
>>
>> index key   time series of event id (event1_id, event2_id….)
>>
>> timeseries_inv_cf: (this is used for removing event by event row key. )
>>
>> row  data
>>
>> event id  set of index keys
>>
>> Candidate Solution: Implementing time range partitions.
>>
>> Each partition will have column family set and will be managed by client.
>>
>> Suppose that you want to have 7 days retention period. Then you can
>> configure the partition size as 1 day and have 7 active partitions at any
>> time. Then you can drop inactive partitions (older that 7 days). Dropping
>> will immediate remove the data from the disk. (With proper Cassandra.yaml
>> configuration)
>>
>> Storing an event:
>>
>> Find the current partition p1
>>
>> store to event_data to Event_data_cf_p1
>>
>> store to indexes to timeseries_cff_p1
>>
>> store to inverted indexes to timeseries_inv_cf_p1
>>
>>
>> A time range query with an index:
>>
>> Find the all partitions belongs to that time range
>>
>> Do read starting from the first partition until you reach to limit
>>
>> .
>>
>> Could you please provide your comments and concerns ?
>>
>> Is there any other option that we can try?
>>
>> What do you think about the candidate solution?
>>
>> Does anyone have the same issue? How would you solve it in another way?
>>
>>
>> Thanks in advance!
>>
>> Cem
>>
>
>

Re: data clean up problem

[Hiller, Dean]

Don't do any delete != "need to free the disk space after retention period" 
which you have in both your emails.  My understanding is TTL is an expiry and 
just like tombstones will only be really deleted upon a compaction(ie. You do 
have deletes via TTL from the sound of it).  If you have TTL of 1 day, it does 
not immediately go away until the next compaction is run and then the 
compaction may not run on all rows???   I am not quite sure there except the 
data stays in the sstable until it is compacted into a new sstable and is 
thrown away then as long as TTL has passed.

Dean

From: cem mailto:cayiro...@gmail.com>>
Reply-To: "user@cassandra.apache.org" 
mailto:user@cassandra.apache.org>>
Date: Tuesday, May 28, 2013 1:17 PM
To: "user@cassandra.apache.org" 
mailto:user@cassandra.apache.org>>
Subject: Re: data clean up problem

Thanks for the answer but it is already set to 0 since I don't do any delete.

Cem


On Tue, May 28, 2013 at 9:03 PM, Edward Capriolo 
mailto:edlinuxg...@gmail.com>> wrote:
You need to change the gc_grace time of the column family. It defaults to 10 
days. By default the tombstones will not go away for 10 days.


On Tue, May 28, 2013 at 2:46 PM, cem 
mailto:cayiro...@gmail.com>> wrote:
Hi Experts,


We have general problem about cleaning up data from the disk. I need to free 
the disk space after retention period and the customer wants to dimension the 
disk space base on that.

After running multiple performance tests with TTL of 1 day we saw that the 
compaction couldn't keep up with the request rate. Disks were getting full 
after 3 days. There were also a lot of sstables that are older than 1 day after 
3 days.

Things that we tried:

-Change the compaction strategy to leveled. (helped a bit but not much)

-Use big sstable size (10G) with leveled compaction to have more aggressive 
compaction.(helped a bit but not much)

-Upgrade Cassandra from 1.0 to 1.2 to use TTL histograms (didn't help at all 
since it has key overlapping estimation algorithm that generates %100 match. 
Although we don't have...)

Our column family structure is like this:

Event_data_cf: (we store event data. Event_id  is randomly generated and each 
event has attributes like location=london)

row  data

event id  data blob

timeseries_cf: (key is the attribute that we want to index. It can be 
location=london, we didnt use secondary indexes because the indexes are 
dynamic.)

row  data

index key   time series of event id (event1_id, event2_id….)

timeseries_inv_cf: (this is used for removing event by event row key. )

row  data

event id  set of index keys

Candidate Solution: Implementing time range partitions.

Each partition will have column family set and will be managed by client.

Suppose that you want to have 7 days retention period. Then you can configure 
the partition size as 1 day and have 7 active partitions at any time. Then you 
can drop inactive partitions (older that 7 days). Dropping will immediate 
remove the data from the disk. (With proper Cassandra.yaml configuration)

Storing an event:

Find the current partition p1

store to event_data to Event_data_cf_p1

store to indexes to timeseries_cff_p1

store to inverted indexes to timeseries_inv_cf_p1


A time range query with an index:

Find the all partitions belongs to that time range

Do read starting from the first partition until you reach to limit

.

Could you please provide your comments and concerns ?

Is there any other option that we can try?

What do you think about the candidate solution?

Does anyone have the same issue? How would you solve it in another way?


Thanks in advance!

Cem

Re: data clean up problem

[Hiller, Dean]

You said compaction can't keep up.  Are you manually running compaction all the 
time or just letting cassandra kick off compactions when needed?  Is compaction 
always 100% running or are you saying your disk is growing faster than you like 
and would like compactions to be always 100% running?  (compactions in LCS can 
be kicked off manually and iyou may want to try that and then check your 
sstables again).

Dean

From: cem mailto:cayiro...@gmail.com>>
Reply-To: "user@cassandra.apache.org" 
mailto:user@cassandra.apache.org>>
Date: Tuesday, May 28, 2013 1:17 PM
To: "user@cassandra.apache.org" 
mailto:user@cassandra.apache.org>>
Subject: Re: data clean up problem

Thanks for the answer but it is already set to 0 since I don't do any delete.

Cem


On Tue, May 28, 2013 at 9:03 PM, Edward Capriolo 
mailto:edlinuxg...@gmail.com>> wrote:
You need to change the gc_grace time of the column family. It defaults to 10 
days. By default the tombstones will not go away for 10 days.


On Tue, May 28, 2013 at 2:46 PM, cem 
mailto:cayiro...@gmail.com>> wrote:
Hi Experts,


We have general problem about cleaning up data from the disk. I need to free 
the disk space after retention period and the customer wants to dimension the 
disk space base on that.

After running multiple performance tests with TTL of 1 day we saw that the 
compaction couldn't keep up with the request rate. Disks were getting full 
after 3 days. There were also a lot of sstables that are older than 1 day after 
3 days.

Things that we tried:

-Change the compaction strategy to leveled. (helped a bit but not much)

-Use big sstable size (10G) with leveled compaction to have more aggressive 
compaction.(helped a bit but not much)

-Upgrade Cassandra from 1.0 to 1.2 to use TTL histograms (didn't help at all 
since it has key overlapping estimation algorithm that generates %100 match. 
Although we don't have...)

Our column family structure is like this:

Event_data_cf: (we store event data. Event_id  is randomly generated and each 
event has attributes like location=london)

row  data

event id  data blob

timeseries_cf: (key is the attribute that we want to index. It can be 
location=london, we didnt use secondary indexes because the indexes are 
dynamic.)

row  data

index key   time series of event id (event1_id, event2_id….)

timeseries_inv_cf: (this is used for removing event by event row key. )

row  data

event id  set of index keys

Candidate Solution: Implementing time range partitions.

Each partition will have column family set and will be managed by client.

Suppose that you want to have 7 days retention period. Then you can configure 
the partition size as 1 day and have 7 active partitions at any time. Then you 
can drop inactive partitions (older that 7 days). Dropping will immediate 
remove the data from the disk. (With proper Cassandra.yaml configuration)

Storing an event:

Find the current partition p1

store to event_data to Event_data_cf_p1

store to indexes to timeseries_cff_p1

store to inverted indexes to timeseries_inv_cf_p1


A time range query with an index:

Find the all partitions belongs to that time range

Do read starting from the first partition until you reach to limit

.

Could you please provide your comments and concerns ?

Is there any other option that we can try?

What do you think about the candidate solution?

Does anyone have the same issue? How would you solve it in another way?


Thanks in advance!

Cem

Re: data clean up problem

[Hiller, Dean]

Also, how many nodes are you running?

From: cem mailto:cayiro...@gmail.com>>
Reply-To: "user@cassandra.apache.org" 
mailto:user@cassandra.apache.org>>
Date: Tuesday, May 28, 2013 1:17 PM
To: "user@cassandra.apache.org" 
mailto:user@cassandra.apache.org>>
Subject: Re: data clean up problem

Thanks for the answer but it is already set to 0 since I don't do any delete.

Cem


On Tue, May 28, 2013 at 9:03 PM, Edward Capriolo 
mailto:edlinuxg...@gmail.com>> wrote:
You need to change the gc_grace time of the column family. It defaults to 10 
days. By default the tombstones will not go away for 10 days.


On Tue, May 28, 2013 at 2:46 PM, cem 
mailto:cayiro...@gmail.com>> wrote:
Hi Experts,


We have general problem about cleaning up data from the disk. I need to free 
the disk space after retention period and the customer wants to dimension the 
disk space base on that.

After running multiple performance tests with TTL of 1 day we saw that the 
compaction couldn't keep up with the request rate. Disks were getting full 
after 3 days. There were also a lot of sstables that are older than 1 day after 
3 days.

Things that we tried:

-Change the compaction strategy to leveled. (helped a bit but not much)

-Use big sstable size (10G) with leveled compaction to have more aggressive 
compaction.(helped a bit but not much)

-Upgrade Cassandra from 1.0 to 1.2 to use TTL histograms (didn't help at all 
since it has key overlapping estimation algorithm that generates %100 match. 
Although we don't have...)

Our column family structure is like this:

Event_data_cf: (we store event data. Event_id  is randomly generated and each 
event has attributes like location=london)

row  data

event id  data blob

timeseries_cf: (key is the attribute that we want to index. It can be 
location=london, we didnt use secondary indexes because the indexes are 
dynamic.)

row  data

index key   time series of event id (event1_id, event2_id….)

timeseries_inv_cf: (this is used for removing event by event row key. )

row  data

event id  set of index keys

Candidate Solution: Implementing time range partitions.

Each partition will have column family set and will be managed by client.

Suppose that you want to have 7 days retention period. Then you can configure 
the partition size as 1 day and have 7 active partitions at any time. Then you 
can drop inactive partitions (older that 7 days). Dropping will immediate 
remove the data from the disk. (With proper Cassandra.yaml configuration)

Storing an event:

Find the current partition p1

store to event_data to Event_data_cf_p1

store to indexes to timeseries_cff_p1

store to inverted indexes to timeseries_inv_cf_p1


A time range query with an index:

Find the all partitions belongs to that time range

Do read starting from the first partition until you reach to limit

.

Could you please provide your comments and concerns ?

Is there any other option that we can try?

What do you think about the candidate solution?

Does anyone have the same issue? How would you solve it in another way?


Thanks in advance!

Cem

Re: data clean up problem

[cem]

Thanks for the answer.

Sorry for the misunderstanding. I tried to say I don't send delete request
from the client so it safe to set gc_grace to 0. TTL is used for data clean
up. I am not running a manual compaction. I tried that ones but it took a
lot of time finish and I will not have this amount of off-peek time in the
production to run this. I even set the compaction throughput to unlimited
and it didnt help that much.

Disk size just keeps on growing but I know that there is enough space to
store 1 day data.

What do you think about time rage partitioning? Creating new column family
for each partition and drop when you know that all records are expired.

I have 5 nodes.

Cem.




On Tue, May 28, 2013 at 9:37 PM, Hiller, Dean  wrote:

> Also, how many nodes are you running?
>
> From: cem mailto:cayiro...@gmail.com>>
> Reply-To: "user@cassandra.apache.org" <
> user@cassandra.apache.org>
> Date: Tuesday, May 28, 2013 1:17 PM
> To: "user@cassandra.apache.org" <
> user@cassandra.apache.org>
> Subject: Re: data clean up problem
>
> Thanks for the answer but it is already set to 0 since I don't do any
> delete.
>
> Cem
>
>
> On Tue, May 28, 2013 at 9:03 PM, Edward Capriolo  > wrote:
> You need to change the gc_grace time of the column family. It defaults to
> 10 days. By default the tombstones will not go away for 10 days.
>
>
> On Tue, May 28, 2013 at 2:46 PM, cem  cayiro...@gmail.com>> wrote:
> Hi Experts,
>
>
> We have general problem about cleaning up data from the disk. I need to
> free the disk space after retention period and the customer wants to
> dimension the disk space base on that.
>
> After running multiple performance tests with TTL of 1 day we saw that the
> compaction couldn't keep up with the request rate. Disks were getting full
> after 3 days. There were also a lot of sstables that are older than 1 day
> after 3 days.
>
> Things that we tried:
>
> -Change the compaction strategy to leveled. (helped a bit but not much)
>
> -Use big sstable size (10G) with leveled compaction to have more
> aggressive compaction.(helped a bit but not much)
>
> -Upgrade Cassandra from 1.0 to 1.2 to use TTL histograms (didn't help at
> all since it has key overlapping estimation algorithm that generates %100
> match. Although we don't have...)
>
> Our column family structure is like this:
>
> Event_data_cf: (we store event data. Event_id  is randomly generated and
> each event has attributes like location=london)
>
> row  data
>
> event id  data blob
>
> timeseries_cf: (key is the attribute that we want to index. It can be
> location=london, we didnt use secondary indexes because the indexes are
> dynamic.)
>
> row  data
>
> index key   time series of event id (event1_id, event2_id….)
>
> timeseries_inv_cf: (this is used for removing event by event row key. )
>
> row  data
>
> event id  set of index keys
>
> Candidate Solution: Implementing time range partitions.
>
> Each partition will have column family set and will be managed by client.
>
> Suppose that you want to have 7 days retention period. Then you can
> configure the partition size as 1 day and have 7 active partitions at any
> time. Then you can drop inactive partitions (older that 7 days). Dropping
> will immediate remove the data from the disk. (With proper Cassandra.yaml
> configuration)
>
> Storing an event:
>
> Find the current partition p1
>
> store to event_data to Event_data_cf_p1
>
> store to indexes to timeseries_cff_p1
>
> store to inverted indexes to timeseries_inv_cf_p1
>
>
> A time range query with an index:
>
> Find the all partitions belongs to that time range
>
> Do read starting from the first partition until you reach to limit
>
> .
>
> Could you please provide your comments and concerns ?
>
> Is there any other option that we can try?
>
> What do you think about the candidate solution?
>
> Does anyone have the same issue? How would you solve it in another way?
>
>
> Thanks in advance!
>
> Cem
>
>
>

Re: data clean up problem

[Hiller, Dean]

How much disk used on each node?  We run the suggested < 300G per node as above 
that compactions can have trouble keeping up.

Ps. We run compactions during peak hours just fine because our client reroutes 
to the 2 of 3 nodes not running compactions based on seeing the slow node so 
performance stays fast.

The easy route is to of course double your cluster and halve the data sizes per 
node so compaction can keep up.

Dean

From: cem mailto:cayiro...@gmail.com>>
Reply-To: "user@cassandra.apache.org" 
mailto:user@cassandra.apache.org>>
Date: Tuesday, May 28, 2013 1:45 PM
To: "user@cassandra.apache.org" 
mailto:user@cassandra.apache.org>>
Subject: Re: data clean up problem

Thanks for the answer.

Sorry for the misunderstanding. I tried to say I don't send delete request from 
the client so it safe to set gc_grace to 0. TTL is used for data clean up. I am 
not running a manual compaction. I tried that ones but it took a lot of time 
finish and I will not have this amount of off-peek time in the production to 
run this. I even set the compaction throughput to unlimited and it didnt help 
that much.

Disk size just keeps on growing but I know that there is enough space to store 
1 day data.

What do you think about time rage partitioning? Creating new column family for 
each partition and drop when you know that all records are expired.

I have 5 nodes.

Cem.




On Tue, May 28, 2013 at 9:37 PM, Hiller, Dean 
mailto:dean.hil...@nrel.gov>> wrote:
Also, how many nodes are you running?

From: cem 
mailto:cayiro...@gmail.com>>>
Reply-To: 
"user@cassandra.apache.org>"
 
mailto:user@cassandra.apache.org>>>
Date: Tuesday, May 28, 2013 1:17 PM
To: 
"user@cassandra.apache.org>"
 
mailto:user@cassandra.apache.org>>>
Subject: Re: data clean up problem

Thanks for the answer but it is already set to 0 since I don't do any delete.

Cem


On Tue, May 28, 2013 at 9:03 PM, Edward Capriolo 
mailto:edlinuxg...@gmail.com>>>
 wrote:
You need to change the gc_grace time of the column family. It defaults to 10 
days. By default the tombstones will not go away for 10 days.


On Tue, May 28, 2013 at 2:46 PM, cem 
mailto:cayiro...@gmail.com>>>
 wrote:
Hi Experts,


We have general problem about cleaning up data from the disk. I need to free 
the disk space after retention period and the customer wants to dimension the 
disk space base on that.

After running multiple performance tests with TTL of 1 day we saw that the 
compaction couldn't keep up with the request rate. Disks were getting full 
after 3 days. There were also a lot of sstables that are older than 1 day after 
3 days.

Things that we tried:

-Change the compaction strategy to leveled. (helped a bit but not much)

-Use big sstable size (10G) with leveled compaction to have more aggressive 
compaction.(helped a bit but not much)

-Upgrade Cassandra from 1.0 to 1.2 to use TTL histograms (didn't help at all 
since it has key overlapping estimation algorithm that generates %100 match. 
Although we don't have...)

Our column family structure is like this:

Event_data_cf: (we store event data. Event_id  is randomly generated and each 
event has attributes like location=london)

row  data

event id  data blob

timeseries_cf: (key is the attribute that we want to index. It can be 
location=london, we didnt use secondary indexes because the indexes are 
dynamic.)

row  data

index key   time series of event id (event1_id, event2_id….)

timeseries_inv_cf: (this is used for removing event by event row key. )

row  data

event id  set of index keys

Candidate Solution: Implementing time range partitions.

Each partition will have column family set and will be managed by client.

Suppose that you want to have 7 days retention period. Then you can configure 
the partition size as 1 day and have 7 active partitions at any time. Then you 
can drop inactive partitions (older that 7 days). Dropping will immediate 
remove the data from the disk. (With proper Cassandra.yaml configuration)

Storing an event:

Find the current partition p1

store to event_data to Event_data_cf_p1

store to indexes to timeseries_cff_p1

store to inverted indexes to timeseries_inv_cf_p1


A time range query with an index:

Find the all partitions belongs to that time range

Do read starting from the first partition until you reach to limit

.

Could you please provide your comm

RE: data clean up problem

[Dwight Smith]

How do you determine the slow node, client side response latency?

-Original Message-
From: Hiller, Dean [mailto:dean.hil...@nrel.gov] 
Sent: Tuesday, May 28, 2013 1:10 PM
To: user@cassandra.apache.org
Subject: Re: data clean up problem

How much disk used on each node?  We run the suggested < 300G per node as above 
that compactions can have trouble keeping up.

Ps. We run compactions during peak hours just fine because our client reroutes 
to the 2 of 3 nodes not running compactions based on seeing the slow node so 
performance stays fast.

The easy route is to of course double your cluster and halve the data sizes per 
node so compaction can keep up.

Dean

From: cem mailto:cayiro...@gmail.com>>
Reply-To: "user@cassandra.apache.org" 
mailto:user@cassandra.apache.org>>
Date: Tuesday, May 28, 2013 1:45 PM
To: "user@cassandra.apache.org" 
mailto:user@cassandra.apache.org>>
Subject: Re: data clean up problem

Thanks for the answer.

Sorry for the misunderstanding. I tried to say I don't send delete request from 
the client so it safe to set gc_grace to 0. TTL is used for data clean up. I am 
not running a manual compaction. I tried that ones but it took a lot of time 
finish and I will not have this amount of off-peek time in the production to 
run this. I even set the compaction throughput to unlimited and it didnt help 
that much.

Disk size just keeps on growing but I know that there is enough space to store 
1 day data.

What do you think about time rage partitioning? Creating new column family for 
each partition and drop when you know that all records are expired.

I have 5 nodes.

Cem.




On Tue, May 28, 2013 at 9:37 PM, Hiller, Dean 
mailto:dean.hil...@nrel.gov>> wrote:
Also, how many nodes are you running?

From: cem 
mailto:cayiro...@gmail.com>>>
Reply-To: 
"user@cassandra.apache.org>"
 
mailto:user@cassandra.apache.org>>>
Date: Tuesday, May 28, 2013 1:17 PM
To: 
"user@cassandra.apache.org>"
 
mailto:user@cassandra.apache.org>>>
Subject: Re: data clean up problem

Thanks for the answer but it is already set to 0 since I don't do any delete.

Cem


On Tue, May 28, 2013 at 9:03 PM, Edward Capriolo 
mailto:edlinuxg...@gmail.com>>>
 wrote:
You need to change the gc_grace time of the column family. It defaults to 10 
days. By default the tombstones will not go away for 10 days.


On Tue, May 28, 2013 at 2:46 PM, cem 
mailto:cayiro...@gmail.com>>>
 wrote:
Hi Experts,


We have general problem about cleaning up data from the disk. I need to free 
the disk space after retention period and the customer wants to dimension the 
disk space base on that.

After running multiple performance tests with TTL of 1 day we saw that the 
compaction couldn't keep up with the request rate. Disks were getting full 
after 3 days. There were also a lot of sstables that are older than 1 day after 
3 days.

Things that we tried:

-Change the compaction strategy to leveled. (helped a bit but not much)

-Use big sstable size (10G) with leveled compaction to have more aggressive 
compaction.(helped a bit but not much)

-Upgrade Cassandra from 1.0 to 1.2 to use TTL histograms (didn't help at all 
since it has key overlapping estimation algorithm that generates %100 match. 
Although we don't have...)

Our column family structure is like this:

Event_data_cf: (we store event data. Event_id  is randomly generated and each 
event has attributes like location=london)

row  data

event id  data blob

timeseries_cf: (key is the attribute that we want to index. It can be 
location=london, we didnt use secondary indexes because the indexes are 
dynamic.)

row  data

index key   time series of event id (event1_id, event2_id)

timeseries_inv_cf: (this is used for removing event by event row key. )

row  data

event id  set of index keys

Candidate Solution: Implementing time range partitions.

Each partition will have column family set and will be managed by client.

Suppose that you want to have 7 days retention period. Then you can configure 
the partition size as 1 day and have 7 active partitions at any time. Then you 
can drop inactive partitions (older that 7 days). Dropping will immediate 
remove the data from the disk. (With proper Cassandra.yaml configuration)

Storing an event:

Find the current partition p1

store to event_data to Event_data_cf_p1

store to indexes to timeseries_cff_p1

Re: data clean up problem

[Hiller, Dean]

Actually, we did a huge investigation into this on astyanax and cassandra.
 Astyanax if I remember worked if configured correctly but casasndra did
not so we patched cassandraŠfor some reason cassandra once on the
co-ordinator who had one copy fo the data would wait for both other nodes
to respond even though we are CL=QUOROM on RF=3Šwe put in patch for that
which my teammate is still supposed to submit.  Cassandra should only wait
for one nodeŠat least I think that is how I remember itŠ.We have it in our
backlog to get the patch into cassandra.

Previously one slow node would slow down our website but this no longer
happens to us such that when compaction kicks off on a single node, our
cluster keeps going strong.

Dean

On 5/28/13 2:12 PM, "Dwight Smith"  wrote:

>How do you determine the slow node, client side response latency?
>
>-Original Message-
>From: Hiller, Dean [mailto:dean.hil...@nrel.gov]
>Sent: Tuesday, May 28, 2013 1:10 PM
>To: user@cassandra.apache.org
>Subject: Re: data clean up problem
>
>How much disk used on each node?  We run the suggested < 300G per node as
>above that compactions can have trouble keeping up.
>
>Ps. We run compactions during peak hours just fine because our client
>reroutes to the 2 of 3 nodes not running compactions based on seeing the
>slow node so performance stays fast.
>
>The easy route is to of course double your cluster and halve the data
>sizes per node so compaction can keep up.
>
>Dean
>
>From: cem mailto:cayiro...@gmail.com>>
>Reply-To: "user@cassandra.apache.org"
>mailto:user@cassandra.apache.org>>
>Date: Tuesday, May 28, 2013 1:45 PM
>To: "user@cassandra.apache.org"
>mailto:user@cassandra.apache.org>>
>Subject: Re: data clean up problem
>
>Thanks for the answer.
>
>Sorry for the misunderstanding. I tried to say I don't send delete
>request from the client so it safe to set gc_grace to 0. TTL is used for
>data clean up. I am not running a manual compaction. I tried that ones
>but it took a lot of time finish and I will not have this amount of
>off-peek time in the production to run this. I even set the compaction
>throughput to unlimited and it didnt help that much.
>
>Disk size just keeps on growing but I know that there is enough space to
>store 1 day data.
>
>What do you think about time rage partitioning? Creating new column
>family for each partition and drop when you know that all records are
>expired.
>
>I have 5 nodes.
>
>Cem.
>
>
>
>
>On Tue, May 28, 2013 at 9:37 PM, Hiller, Dean
>mailto:dean.hil...@nrel.gov>> wrote:
>Also, how many nodes are you running?
>
>From: cem 
>mailto:cayiro...@gmail.com>m>>
>Reply-To: 
>"user@cassandra.apache.orgassandra.apache.org>"
>mailto:user@cassandra.apache.org>assandra.apache.org>>
>Date: Tuesday, May 28, 2013 1:17 PM
>To: 
>"user@cassandra.apache.orgassandra.apache.org>"
>mailto:user@cassandra.apache.org>assandra.apache.org>>
>Subject: Re: data clean up problem
>
>Thanks for the answer but it is already set to 0 since I don't do any
>delete.
>
>Cem
>
>
>On Tue, May 28, 2013 at 9:03 PM, Edward Capriolo
>mailto:edlinuxg...@gmail.com>ail.com>> wrote:
>You need to change the gc_grace time of the column family. It defaults to
>10 days. By default the tombstones will not go away for 10 days.
>
>
>On Tue, May 28, 2013 at 2:46 PM, cem
>mailto:cayiro...@gmail.com>m>> wrote:
>Hi Experts,
>
>
>We have general problem about cleaning up data from the disk. I need to
>free the disk space after retention period and the customer wants to
>dimension the disk space base on that.
>
>After running multiple performance tests with TTL of 1 day we saw that
>the compaction couldn't keep up with the request rate. Disks were getting
>full after 3 days. There were also a lot of sstables that are older than
>1 day after 3 days.
>
>Things that we tried:
>
>-Change the compaction strategy to leveled. (helped a bit but not much)
>
>-Use big sstable size (10G) with leveled compaction to have more
>aggressive compaction.(helped a bit but not much)
>
>-Upgrade Cassandra from 1.0 to 1.2 to use TTL histograms (didn't help at
>all since it has key overlapping estimation algorithm that generates %100
>match. Although we don't have...)
>
>Our column family structure is like this:
>
>Event_data_cf: (we store event data. Event_id  is randomly generated and
>each event has attributes like location=london)
>
>row  data
>
>event id  data blob
>
>timeseries_cf: (key is the attribute that we want to index. It can be
>location=london, 

Re: data clean up problem

[Hiller, Dean]

Oh and yes, astyanax uses client side response latency and cassandra does
the same as a client of the other nodes.

Dean

On 5/28/13 2:23 PM, "Hiller, Dean"  wrote:

>Actually, we did a huge investigation into this on astyanax and cassandra.
> Astyanax if I remember worked if configured correctly but casasndra did
>not so we patched cassandraŠfor some reason cassandra once on the
>co-ordinator who had one copy fo the data would wait for both other nodes
>to respond even though we are CL=QUOROM on RF=3Šwe put in patch for that
>which my teammate is still supposed to submit.  Cassandra should only wait
>for one nodeŠat least I think that is how I remember itŠ.We have it in our
>backlog to get the patch into cassandra.
>
>Previously one slow node would slow down our website but this no longer
>happens to us such that when compaction kicks off on a single node, our
>cluster keeps going strong.
>
>Dean
>
>On 5/28/13 2:12 PM, "Dwight Smith"  wrote:
>
>>How do you determine the slow node, client side response latency?
>>
>>-Original Message-
>>From: Hiller, Dean [mailto:dean.hil...@nrel.gov]
>>Sent: Tuesday, May 28, 2013 1:10 PM
>>To: user@cassandra.apache.org
>>Subject: Re: data clean up problem
>>
>>How much disk used on each node?  We run the suggested < 300G per node as
>>above that compactions can have trouble keeping up.
>>
>>Ps. We run compactions during peak hours just fine because our client
>>reroutes to the 2 of 3 nodes not running compactions based on seeing the
>>slow node so performance stays fast.
>>
>>The easy route is to of course double your cluster and halve the data
>>sizes per node so compaction can keep up.
>>
>>Dean
>>
>>From: cem mailto:cayiro...@gmail.com>>
>>Reply-To: "user@cassandra.apache.org"
>>mailto:user@cassandra.apache.org>>
>>Date: Tuesday, May 28, 2013 1:45 PM
>>To: "user@cassandra.apache.org"
>>mailto:user@cassandra.apache.org>>
>>Subject: Re: data clean up problem
>>
>>Thanks for the answer.
>>
>>Sorry for the misunderstanding. I tried to say I don't send delete
>>request from the client so it safe to set gc_grace to 0. TTL is used for
>>data clean up. I am not running a manual compaction. I tried that ones
>>but it took a lot of time finish and I will not have this amount of
>>off-peek time in the production to run this. I even set the compaction
>>throughput to unlimited and it didnt help that much.
>>
>>Disk size just keeps on growing but I know that there is enough space to
>>store 1 day data.
>>
>>What do you think about time rage partitioning? Creating new column
>>family for each partition and drop when you know that all records are
>>expired.
>>
>>I have 5 nodes.
>>
>>Cem.
>>
>>
>>
>>
>>On Tue, May 28, 2013 at 9:37 PM, Hiller, Dean
>>mailto:dean.hil...@nrel.gov>> wrote:
>>Also, how many nodes are you running?
>>
>>From: cem 
>>mailto:cayiro...@gmail.com>>o
>>m>>
>>Reply-To: 
>>"user@cassandra.apache.org>c
>>assandra.apache.org>"
>>mailto:user@cassandra.apache.org>>c
>>assandra.apache.org>>
>>Date: Tuesday, May 28, 2013 1:17 PM
>>To: 
>>"user@cassandra.apache.org>c
>>assandra.apache.org>"
>>mailto:user@cassandra.apache.org>>c
>>assandra.apache.org>>
>>Subject: Re: data clean up problem
>>
>>Thanks for the answer but it is already set to 0 since I don't do any
>>delete.
>>
>>Cem
>>
>>
>>On Tue, May 28, 2013 at 9:03 PM, Edward Capriolo
>>mailto:edlinuxg...@gmail.com>>m
>>ail.com>> wrote:
>>You need to change the gc_grace time of the column family. It defaults to
>>10 days. By default the tombstones will not go away for 10 days.
>>
>>
>>On Tue, May 28, 2013 at 2:46 PM, cem
>>mailto:cayiro...@gmail.com>>o
>>m>> wrote:
>>Hi Experts,
>>
>>
>>We have general problem about cleaning up data from the disk. I need to
>>free the disk space after retention period and the customer wants to
>>dimension the disk space base on that.
>>
>>After running multiple performance tests with TTL of 1 day we saw that
>>the compaction couldn't keep up with the request rate. Disks were getting
>>full after 3 days. There were also a lot of sstables that are older than
>>1 day after 3 days.
>>
>>Things that we tried:
>>
>>-Change the compaction strategy to leveled. (helped a bit but not much)
>>
>>-Use big sstable size (10G) with leveled compaction to have more
>>aggressive compaction.(helped a bit but not much)
>>
>>-Upgrade Cassandra from 1.0 to 1.2 to use TTL histograms (didn't help at
>>all since it has key overlapping estimation algorithm that generates %100
>>match. Although we don't have...)
>>
>>Our

Re: data clean up problem

[Bryan Talbot]

I think what you're asking for (efficient removal of TTL'd write-once data)
is already in the works but not until 2.0 it seems.

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

-Bryan



On Tue, May 28, 2013 at 1:26 PM, Hiller, Dean  wrote:

> Oh and yes, astyanax uses client side response latency and cassandra does
> the same as a client of the other nodes.
>
> Dean
>
> On 5/28/13 2:23 PM, "Hiller, Dean"  wrote:
>
> >Actually, we did a huge investigation into this on astyanax and cassandra.
> > Astyanax if I remember worked if configured correctly but casasndra did
> >not so we patched cassandraŠfor some reason cassandra once on the
> >co-ordinator who had one copy fo the data would wait for both other nodes
> >to respond even though we are CL=QUOROM on RF=3Šwe put in patch for that
> >which my teammate is still supposed to submit.  Cassandra should only wait
> >for one nodeŠat least I think that is how I remember itŠ.We have it in our
> >backlog to get the patch into cassandra.
> >
> >Previously one slow node would slow down our website but this no longer
> >happens to us such that when compaction kicks off on a single node, our
> >cluster keeps going strong.
> >
> >Dean
> >
> >On 5/28/13 2:12 PM, "Dwight Smith"  wrote:
> >
> >>How do you determine the slow node, client side response latency?
> >>
> >>-Original Message-
> >>From: Hiller, Dean [mailto:dean.hil...@nrel.gov]
> >>Sent: Tuesday, May 28, 2013 1:10 PM
> >>To: user@cassandra.apache.org
> >>Subject: Re: data clean up problem
> >>
> >>How much disk used on each node?  We run the suggested < 300G per node as
> >>above that compactions can have trouble keeping up.
> >>
> >>Ps. We run compactions during peak hours just fine because our client
> >>reroutes to the 2 of 3 nodes not running compactions based on seeing the
> >>slow node so performance stays fast.
> >>
> >>The easy route is to of course double your cluster and halve the data
> >>sizes per node so compaction can keep up.
> >>
> >>Dean
> >>
> >>From: cem mailto:cayiro...@gmail.com>>
> >>Reply-To: "user@cassandra.apache.org"
> >>mailto:user@cassandra.apache.org>>
> >>Date: Tuesday, May 28, 2013 1:45 PM
> >>To: "user@cassandra.apache.org"
> >>mailto:user@cassandra.apache.org>>
> >>Subject: Re: data clean up problem
> >>
> >>Thanks for the answer.
> >>
> >>Sorry for the misunderstanding. I tried to say I don't send delete
> >>request from the client so it safe to set gc_grace to 0. TTL is used for
> >>data clean up. I am not running a manual compaction. I tried that ones
> >>but it took a lot of time finish and I will not have this amount of
> >>off-peek time in the production to run this. I even set the compaction
> >>throughput to unlimited and it didnt help that much.
> >>
> >>Disk size just keeps on growing but I know that there is enough space to
> >>store 1 day data.
> >>
> >>What do you think about time rage partitioning? Creating new column
> >>family for each partition and drop when you know that all records are
> >>expired.
> >>
> >>I have 5 nodes.
> >>
> >>Cem.
> >>
> >>
> >>
> >>
> >>On Tue, May 28, 2013 at 9:37 PM, Hiller, Dean
> >>mailto:dean.hil...@nrel.gov>> wrote:
> >>Also, how many nodes are you running?
> >>
> >>From: cem
> >>mailto:cayiro...@gmail.com> cayiroglu@gmail.c
> >>o
> >>m>>
> >>Reply-To:
> >>"user@cassandra.apache.org user@
> >>c
> >>assandra.apache.org>"
> >>mailto:user@cassandra.apache.org> user@
> >>c
> >>assandra.apache.org>>
> >>Date: Tuesday, May 28, 2013 1:17 PM
> >>To:
> >>"user@cassandra.apache.org user@
> >>c
> >>assandra.apache.org>"
> >>mailto:user@cassandra.apache.org> user@
> >>c
> >>assandra.apache.org>>
> >>Subject: Re: data clean up problem
> >>
> >>Thanks for the answer but it is already set to 0 since I don't do any
> >>delete.
> >>
> >>Cem
> >>
> >>
> >>On Tue, May 28, 2013 at 9:03 PM, Edward Capriolo
> >>mailto:edlinuxg...@gmail.com> edlinuxguru@g
> >>m
> >>ail.com>> wrote:
> >>You need to change the gc_grace time of the column family. It defaults to
> >>10 days. By default the tombstones will not go away for 10 days.
> >>
> >>
> >>On Tue, May 28, 2013 at 2:46 PM, cem
> >>mailto:cayiro...@gmail.com> cayiroglu@gmail.c
> >>o
> >>m>> wrote:
> >>Hi Experts,
> >>
> >>
> >>We have general problem about cleaning up data from the disk. I need to
> >>free the disk space after retention period and the customer wants to
> >>dimension the disk space base on that.
> >>
> >>After running multiple performance tests with TTL of 1 day we saw that
> >>the compaction couldn't keep up with the request rate. Disks were getting
> >>full after 3 days. There were also a lot of sstables that are older th

Dynamic column family using CQL2, possible?

[Matthew Hillsborough]

Hi all,

I started building a schema using CQL3's interface following the
instructions here: http://www.datastax.com/dev/blog/thrift-to-cql3

In particular, the dynamic column family instructions did exactly what I
need to model my data on that blog post.

I created a schema that looks like the following:

CREATE TABLE user_games (
  g_sp_key text,
  user_id int,
  nickname text,
  PRIMARY KEY (g_sp_key, user_id)
) WITH COMPACT STORAGE;

Worked great. My problem is I tested everything in CQLsh. As soon as it
came time to implementing in my application (a Ruby on Rails app using the
cassandra-cql gem found at https://github.com/kreynolds/cassandra-cql), I
realized cassandra-cql does not support CQL3 and I have to stick to CQL2.

My question simply comes down to is it possible to do what I was attempting
to do above in CQL2? How would my schema above change? Do I have to go back
to using a Thrift based client?

Thanks all.

Re: data clean up problem

[Robert Coli]

On Tue, May 28, 2013 at 2:38 PM, Bryan Talbot  wrote:
> I think what you're asking for (efficient removal of TTL'd write-once data)
> is already in the works but not until 2.0 it seems.

If your entire dataset in a keyspace or column family is deleted every
[small time period], then maybe use TRUNCATE?

Two caveats :

1) https://issues.apache.org/jira/browse/CASSANDRA-4655 - TRUNCATE
will leave undelivered hints untouched until 1.2.6
2) TRUNCATE will create a snapshot unless you (unsafely!!!
danger) disable this feature [1]

Alternately, perhaps a datastore with immutable data files is not for you? :D

=Rob
[1] https://issues.apache.org/jira/browse/CASSANDRA-3710

Re: Cleanup understastanding

[Takenori Sato(Cloudian)]

Hi Victor,

As Andrey said, running cleanup doesn't work as you expect.

> The reason I need to clean things is that I wont need most of my 
inserted data on the next day.


Deleted objects(columns/records) become deletable from sstable file when 
they get expired(after gc_grace_seconds).


Such deletable objects are actually gotten rid of by compaction.

The tricky part is that a deletable object remains unless all of its old 
objects(the same row key) are contained in the set of sstable files 
involved in the compaction.


- Takenori

(2013/05/29 3:01), Andrey Ilinykh wrote:
cleanup removes data which doesn't belong to the current node. You 
have to run it only if you move (or add new) nodes. In your case there 
is no any reason to do it.



On Tue, May 28, 2013 at 7:39 AM, Víctor Hugo Oliveira Molinar 
mailto:vhmoli...@gmail.com>> wrote:


Hello everyone.
I have a daily maintenance task at c* which does:

-truncate cfs
-clearsnapshots
-repair
-cleanup

The reason I need to clean things is that I wont need most of my
inserted data on the next day. It's kind a business requirement.

Well,  the problem I'm running to, is the misunderstanding about
cleanup operation.
I have 2 nodes with lower than half usage of disk, which is
moreless 13GB;

But, the last few days, arbitrarily each node have reported me a
cleanup error indicating that the disk was full. Which is not true.

/Error occured during cleanup/
/java.util.concurrent.ExecutionException: java.io.IOException:
disk full/


So I'd like to know more about what does happens in a cleanup
operation.
Appreciate any help.

Cleanup cannot run before a node has joined the ring

[S C]

I have added two nodes to the cluster running on 1.1.9 and when I run a 
"nodetool cleanup" I see the following in the logs.
INFO [CompactionExecutor:7] 2013-05-28 22:41:58,480 CompactionManager.java 
(line 531) Cleanup cannot run before a node has joined the ring
However, "nodetool ring/gossip/info" on all the nodes show same info. "nodetool 
repair" just hangs there and there is nothing going on in the logs when repair 
is in progress.Note:  I use network topology for the ring. Logs suggest that 
the data was streamed from other nodes in the cluster during bootstrap.
Doing repair on the individual keyspace columnfamily works fine and so does the 
cleanup [Of course there is only one keyspace that is of interest for the 
application]. Did I miss something here? Posting it here as I could not get 
much info searching on the web. Appreciate your help.
Thanks,SC