Using Java, can I scan a Cassandra table and just update the TTL of a row? I don't want to change any data. I just want to scan Cassandra table and set TTL of a few rows.
Also, using java, can I set TTL which is absolute. for example (2016-11-22 00:00:00). so I don't want to specify the TTL in seconds, but specify the absolute value in time.
Cassandra doesn't allow to set the TTL value for a row, it allows to set TTLs for columns values only.
In the case you're wondering why you are experiencing rows expiration, this is because if all the values of all the columns of a record are TTLed then the row disappears when you try to SELECT it.
However, this is only true if you perform an INSERT with the USING TTL. If you INSERT without TTL and then do an UPDATE with TTL you'll still see the row, but with null values. Here's a few examples and some gotchas:
Example with a TTLed INSERT only:
CREATE TABLE test (
k text PRIMARY KEY,
v int,
);
INSERT INTO test (k,v) VALUES ('test', 1) USING TTL 10;
... 10 seconds after...
SELECT * FROM test ;
k | v
---------------+---------------
Example with a TTLed INSERT and a TTLed UPDATE:
INSERT INTO test (k,v) VALUES ('test', 1) USING TTL 10;
UPDATE test USING TTL 10 SET v=0 WHERE k='test';
... 10 seconds after...
SELECT * FROM test;
k | v
---------------+---------------
Example with a non-TTLed INSERT with a TTLed UPDATE
INSERT INTO test (k,v) VALUES ('test', 1);
UPDATE test USING TTL 10 SET v=0 WHERE k='test';
... 10 seconds after...
SELECT * FROM test;
k | v
---------------+---------------
test | null
Now you can see that the only way to solve you problem is to rewrite all the values of all the columns of your row with a new TTL.
In addition, there's no way to specify an explicit expiration date, but you can get a simple TTL value in seconds with simple math (as other suggested).
Have a look at the official documentation about data expiration. And don't forget to have a look at the DELETE section for updating TTLs.
HTH.
You can't only update TTL of a row. You have to update or re-insert all the column.
You can select all the regular column and the primary keys column then update the regular columns with primary keys or re-insert using TTL in second
In Java you can calculate TTL in second from a date using below method.
public static long ttlFromDate(Date ttlDate) throws Exception {
long ttl = (ttlDate.getTime() - System.currentTimeMillis()) / 1000;
if (ttl < 1) {
throw new Exception("Invalid ttl date");
}
return ttl;
}
Alternatively, you can set a TTL value on the entire table while creating it.
CREATE TABLE test (
k text PRIMARY KEY,
v int,
) WITH default_time_to_live = 63113904;
Above example will create a table whose rows will disappear after 2 years.
Related
I am having a column family in cassandra with default ttl as 3024000(35 days),compaction strategy is LCS and table structure is something like this
CREATE TABLE xyz (
logdate text,
cookieid text,
count1 int,
count2 int,
count3 int,
PRIMARY KEY (logdate, cookieid)
) WITH CLUSTERING ORDER BY (cookieid ASC)
but when i am checking the ttl of 35 old days data it is still showing 20 days i am not getting why this is happening. Do anybody have idea about this? Is this because of compaction ?
This could happen if you have reinserted the same row.
For example
INSERT INTO XYZ VALUES(100,..........some value) -- lets say inserted 10 days back.
If the row is not inserted again the TTl could have shown 25 days, but what might had happend is the row gets inserted again.
INSERT INTO XYZ VALUES(100,..........some other value ) -- lets say inserted 5 days back.
The TTL will be 30 days.
TTL value gets reset at every insert of the row (same row key).
select count (*) from my_table gives me OperationTimedOut: errors={}, last_host=127.0.0.1
I have already tried to change the values in request_timeout_in_ms in cassandra.yaml and request_timeout in cqlshrc.sample. (Both are in C:\Programs\DataStax-DDC\apache-cassandra\conf) But without success.
How can I increse timeout?
select count (*) is not doing what you think. It is actually expensive as it counts the rows one by one. You can track number of records using a separate column family with a counter, which you will need to increment for every insert you do into your table. For example
CREATE TABLE IF NOT EXISTS my_table_counter (
mykey text,
count counter,
PRIMARY KEY (mykey)
);
Then for every insert into your table, do counter update:
INSERT into my_table (mykey, mydata) VALUES (?, ?);
UPDATE my_table_counter SET count = count + 1 WHERE mykey = ?;
To get the count:
SELECT count FROM my_table_counter WHERE mykey = ?
Note that counters are not idempotent, so in a rare event of a failure your data might be under or over-counted. Also the code above assumes that you only insert with a new key.
If you need a precise counting, Cassandra may be not a good fit for that. Also if you are not inserting with unique keys you may need to consider using light weight transaction with insert (IF NOT EXISTS) and update a counter only if transaction was applied.
I create a table with counter column in Cassandra, just like :
create table test_count(
pk int,
count counter,
primary key (pk)
);
And after that I update some record like:
update test_count set count = count + 1 where pk = 1;
Then I want to reset the count to 0, but there's no reset command in cql, so I delete the record:
delete from test_count where pk = 1;
And then I re-execute the update CQL, but when I select * from test_count, there's no record with pk = 1, so is it a bug of Cassandra? When you delete the record with counter column, it disappears forever? How can I reset the count column to 0? How can I re-insert a record with counter column?
You can first query the counter for its current value and then issue an update to subtract that amount.
You can delete the counter, and then start a new counter using a different row key. You would no longer try to use the original counter. With this approach you might want to partition your counters by day or by week, so that when a new day started, you'd start with a fresh set of zeroed out counters.
Using Cassandra 2.0.9 CQL, how does one query for rows that don't have a particular column defined? For example:
create table testtable ( id int primary key, thing int );
create index on testtable ( thing );
# can now select rows by thing
insert into testtable( id, thing ) values ( 100, 100 );
# row values will be persistent
update testtable using TTL 30 set thing=1 where id=100;
# wait 30 seconds, thing column will go away for the row
select * from testtable;
Ideally I'd like to be able to do something like this:
select * from testtable where NOT DEFINED thing;
or some such and have the row with the id==1 returned. Is there any way to search for rows that do not have a particular column value assigned?
I'm afraid I've been through the Datastax 2.0 manual, as well as the CQLSH help with no luck trying to find an operator or syntax for this. Thanks.
Doesn't appear to be available yet
https://issues.apache.org/jira/browse/CASSANDRA-3783
For Cassandra, do UPDATEs become an implied INSERT if the selected row does not exist? That is, if I say
UPDATE users SET name = "Raedwald" WHERE id = 545127
and id is the PRIMARY KEY of the users table, and the table has no row with a key of 545127, will that be equivalent to
INSERT INTO users (id, name) VALUES (545127, "Raedwald")
I know that the opposite is true: an INSERT for an id that already exists becomes an UPDATE of the row with that id. Older Cassandra documentation talked about inserts actually being "upserts" for that reason.
I'm interested in the case for CQL3, Cassandra version 1.2+.
Yes, for Cassandra UPDATE is synonymous with INSERT, as explained in the CQL documentation where it says the following about UPDATE:
Note that unlike in SQL, UPDATE does not check the prior existence of the row: the row is created if none existed before, and updated otherwise. Furthermore, there is no mean to know which of creation or update happened. In fact, the semantic of INSERT and UPDATE are identical.
For the semantics to be different, Cassandra would need to do a read to know if the row already exists. Cassandra is write optimized, so you can always assume it doesn't do a read before write on any write operation. The only exception is counters (unless replicate_on_write = false), in which case replication on increment involves a read.
Unfortunately the accepted answer is not 100% accurate. inserts are different than updates:
cqlsh> create table ks.t (pk int, ck int, v int, primary key (pk, ck));
cqlsh> update ks.t set v = null where pk = 0 and ck = 0;
cqlsh> select * from ks.t where pk = 0 and ck = 0;
pk | ck | v
----+----+---
(0 rows)
cqlsh> insert into ks.t (pk,ck,v) values (0,0,null);
cqlsh> select * from ks.t where pk = 0 and ck = 0;
pk | ck | v
----+----+------
0 | 0 | null
(1 rows)
Scylla does the same thing.
In Scylla and Cassandra rows are sequences of cells. Each column gets a corresponding cell (or a set of cells in the case of non-frozen collections or UDTs). But there is one additional, invisible cell - the row marker (in Scylla at least; I suspect Cassandra has something similar).
The row marker makes a difference for rows in which all other cells are dead: a row shows up in a query if and only if there's at least one alive cell. Thus, if the row marker is alive, the row will show up, even if all other columns were previously set to null using e.g. updates.
inserts create a live row marker, while updates don't touch the row marker, so clearly they are different. The example above illustrates that.
One could argue that row markers are "internal" to Cassandra/Scylla, but as you can see, their effects are visible. Row markers affect your life whether you like it or not, so it may be useful to remember about them.
It's sad that no documentation mentions row markers (well, I found this: https://docs.scylladb.com/architecture/sstable/sstable2/sstable-data-file/#cql-row-marker but it's in the context of explaining SSTable internals, which is probably dedicated to Scylla developers more than to users).
Bonus: a cell delete:
delete v from ks.t where pk = 0 and ck = 0
is the same as a null update:
update ks.t set v = null where pk = 0 and ck = 0
indeed, a cell delete also doesn't touch the row marker. It only sets the specified cell to null.
This is different from a row delete:
delete from ks.t where pk = 0 and ck = 0
because row deletes insert a row tombstone, which kills all cells in the row (including the row marker). You could say that row deletes are the opposite of an insert. Updates and cell deletes are somewhere in between.
What one can do is this however:
UPDATE table_name SET field = false WHERE key = 55 IF EXISTS;
This will ensure that your update is a true update and not an upsert.