Generally, I see we can limit the select by select * from table where predicate = value limit by N Am currently in a situation where I have 200 records falling under a predicate, but I want to update the first 100 like update table set column = 1 where predicate = value limit...? and the second half by update table set column = 2 where predicate = value. I think it could be done by having ranges <=,>= in the predicate section, unfortunately, I have none of them.
Currently, I don't think we have this feature as WHERE clause must identify the row or rows to be updated by primary key as per. However, you could further limit the number of rows to be updated by using IF EXISTS condition. Details can be found here
Related
I know that it's possible to use conditional updates (lightweight transaction) in cassandra.
update myTable
set
col1 = 'abc',
where id = 1
IF priority < 2
This allows me to update only rows with a higher priority. Unfortunately when the row does not exists the statement returns false. Is it possible to combine "IF NOT EXISTS" and "IF" with an OR operation?
Otherwise i have to execute more queries to the cluster. In my use case this could be a big performance issue.
I figured it out - unfortunately it's not possible in cassandra. We have to separate the insert and update statement.
https://issues.apache.org/jira/browse/CASSANDRA-8335
insert ... if not exists
update ... if priority < 2
You can use the IN operator, assuming that "priority" has a finite (and possibly small) allowed set of values, such as 0 and 1. By adding the NULL value to the set, the query will succeed also if the row does not exist.
You're using a single query, but note that the performance implications are non-negligible, and could be the same or worse than using two.
update myTable
set
col1 = 'abc',
where id = 1
IF priority IN (0, 1, NULL)
I like to know the performance difference in executing the following two queries for a table cycling.cyclist_points containing 1000s of rows. :
SELECT sum(race_points)
FROM cycling.cyclist_points
WHERE id = e3b19ec4-774a-4d1c-9e5a-decec1e30aac;
select *
from cycling.cyclist_points
WHERE id = e3b19ec4-774a-4d1c-9e5a-decec1e30aac;
If sum(race_points) causes the query to be expensive, I will have to look for other solutions.
Performance Difference between your query :
Both of your query need to scan same number of row.(Number of row in that partition)
First query only selecting a single column, so it is little bit faster.
Instead of calculating the sum run time, try to preprocess the sum.
If race_points is int or bigint then use a counter table like below :
CREATE TABLE race_points_counter (
id uuid PRIMARY KEY,
sum counter
);
Whenever a new data inserted into cyclist_points also increment the sum with your current point.
UPDATE race_points_counter SET sum = sum + ? WHERE id = ?
Now you can just select the sum of that id
SELECT sum FROM race_points_counter WHERE id = ?
I'm trying to select everything where two columns contain equal values. Here is my CQL query:
select count(someColumn) from somekeySpace.sometable where columnX = columnY
This doesn't work. How can I do this?
You can't query like that, cassandra don't support it
You can do this in different way.
First you have to create a separate counter table.
CREATE TABLE match_counter(
partition int PRIMARY KEY,
count counter
);
At the time of insertion into your main table if columnX = columnY then increment the value here. Though you have only a single count, you can use a static value of partition
UPDATE match_counter SET count = count + 1 WHERE partition = 1;
Now you can get the count of match column
SELECT * FROM match_counter WHERE partition = 1;
I added a new boolean column called subscribe to my email_subscriptions table in Cassandra. I noticed that it returns false for all rows' subscribe field.
I wanted to default all rows in the table with the subscribe field as true, but this StackOverflow answer says:
there is no default value in Cassandra.
So my question is, how do I set all rows in my email_subscriptions table to have their subscribe field set to true? Do I need to backfill via a batch update?
There is two way you can do this.
You can create a program, which will select all record from email_subscriptions and insert back along with subscribe = true value.
Or
When selecting subscribe field value, check the value is null with isNull() method (which will return true if the column is null, false otherwise). If true return, it means that subscribe is null and this value not yet inserted, you can treat it as subscribe = true
The only way is to fill back your whole table. Depending on size of your table, you could have problems at querying your table with a simple
SELECT * FROM mytable;
due to timeouts. Since the partition key is mandatory in an UPDATE statement, you have to find a way to spill your partition keys out from that table.
This is the perfect scenario for using the TOKEN function. Assuming you did your homework and don't have any too-wide partitions, you can scan all your dataset by splitting it into ranges of partitions. How wide is your range is up to your data. From a general point of view, you need to:
SELECT __partition_key_columns__ FROM mytable WHERE
TOKEN(__partition_key_columns__) >= min_range AND
TOKEN(__partition_key_columns__) < max_range;
and min_range and max_range go from -2^63 to 2^64-1 (IIRC, using Murmur3) in steps of a guessed window size W:
SELECT __partition_key_columns__ FROM mytable WHERE TOKEN(__partition_key_columns__) >= -2^63 AND TOKEN(__partition_key_columns__) < -2^63 + W;
SELECT __partition_key_columns__ FROM mytable WHERE TOKEN(__partition_key_columns__) >= -2^63 + W AND TOKEN(__partition_key_columns__) < -2^63 + 2*W;
...
until you covered all the range up to 2^64-1. If you get a timeout make W smaller and try again. And if you don't, expand your window W so you'll speed up the process. You will be able to extract all the partitions to issue the updates for each range.
EDIT: This blog post explains exactly how to perform such task.
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.