I am trying to update a record in a test keyspace and table. When I upsert a record, one column value change is accepted, while the other doesn't take. (Note: I'm also not able to delete the record, despite no error message)
Observe how middle_initial does not update, while title does... What gives?
//Before
cqlsh:my_keyspace> SELECT * FROM user;
last_name | first_name | middle_initial | title
-----------+------------+----------------+-------
Rodriguez | Mary | Q | null
Rodriquez | Mary | Q | O
Nguyen | Bill | null | Mr.
Nguyen | Wanda | null | Mrs.
//Command
cqlsh:my_keyspace> UPDATE user SET middle_initial = 'F', title = 'U' WHERE last_name = 'Rodriquez' AND first_name = 'Mary';
//After
cqlsh:my_keyspace> SELECT * FROM user;
last_name | first_name | middle_initial | title
-----------+------------+----------------+-------
Rodriguez | Mary | Q | null
Rodriquez | Mary | Q | U
Nguyen | Bill | null | Mr.
Nguyen | Wanda | null | Mrs.
//Additional Info
CREATE KEYSPACE my_keyspace WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '1'} AND durable_writes = true;
CREATE TABLE my_keyspace.user (
last_name text,
first_name text,
middle_initial text,
title text,
PRIMARY KEY (last_name, first_name)
) WITH CLUSTERING ORDER BY (first_name ASC)
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment = ''
AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
Manish was correct. My timestamp for middle_initial was set to a future date of 1623699999999999
To Delete the record (which was actually my goal) I did:
cqlsh:my_keyspace> DELETE FROM user USING timestamp 1623699999999999 WHERE first_name = 'Mary' AND last_name = 'Rodriquez';
This happens generally when your column writetime is in future. You can check writetime of your column
SELECT WRITETIME (middle_initial) FROM my_keyspace.user WHERE last_name = 'Rodriquez' AND first_name = 'Mary';
Related
I have below table structure which houses failed records.
CREATE TABLE if not exists dummy_plan (
id uuid,
payload varchar,
status varchar,
bucket text,
create_date timestamp,
modified_date timestamp,
primary key ((bucket), create_date, id))
WITH CLUSTERING ORDER BY (create_date ASC)
AND COMPACTION = {'class': 'TimeWindowCompactionStrategy',
'compaction_window_unit': 'DAYS',
'compaction_window_size': 1};
My table looks like below
| id | payload | status | bucket | create_date | modified_date |
| abc| text1 | Start | 2021-02-15 | 2021-02-15 08:07:50+0000 | |
Table and records are created and inserted successfully. However after processing, we want to update (if failed) and delete (if successful) record based on Id.
But am facing problem with timestamp where I tried giving same value but it still doesn't deletes/updates.
Seems Cassandra doesn't works with EQ with timestamp.
Please guide.
Thank you in advance.
Cassandra works just fine with the timestamp columns - you can use equality operation on that. But you need to make sure that you include milliseconds into the value, otherwise it won't match:
cqlsh> insert into test.dummy_service_plan_contract (id, create_date, bucket)
values (1, '2021-02-15T11:00:00.123Z', '123');
cqlsh> select * from test.dummy_service_plan_contract;
bucket | create_date | id | modified_date | payload | status
--------+---------------------------------+----+---------------+---------+--------
123 | 2021-02-15 11:00:00.123000+0000 | 1 | null | null | null
(1 rows)
cqlsh> delete from test.dummy_service_plan_contract where bucket = '123' and
id = 1 and create_date = '2021-02-15T11:00:00Z';
cqlsh> select * from test.dummy_service_plan_contract;
bucket | create_date | id | modified_date | payload | status
--------+---------------------------------+----+---------------+---------+--------
123 | 2021-02-15 11:00:00.123000+0000 | 1 | null | null | null
(1 rows)
cqlsh> delete from test.dummy_service_plan_contract where bucket = '123' and
id = 1 and create_date = '2021-02-15T11:00:00.123Z';
cqlsh> select * from test.dummy_service_plan_contract;
bucket | create_date | id | modified_date | payload | status
--------+-------------+----+---------------+---------+--------
(0 rows)
If you don't see the milliseconds in your output in the cqlsh, then you need to configure datetimeformat setting in the .cqlshrc
I have a question about Cassandra. At present, "entities_by_time" is ok on the 18-bit uuid through column1 sorting, but there is something wrong with uuid ascending to the 19-bit sorting. Please help me.
cqlsh:minds> select * from entities_by_time where key='activity:user:990192934408163330' order by column1 desc limit 10;
key | column1 | value
----------------------------------+--------------------+--------------------
activity:user:990192934408163330 | 999979571363188746 | 999979571363188746
activity:user:990192934408163330 | 999979567064027139 | 999979567064027139
activity:user:990192934408163330 | 999979562764865555 | 999979562764865555
activity:user:990192934408163330 | 999979558465703953 | 999979558465703953
activity:user:990192934408163330 | 999979554170736649 | 999979554170736649
activity:user:990192934408163330 | 999979549871575047 | 999979549871575047
activity:user:990192934408163330 | 999979545576607752 | 999979545576607752
activity:user:990192934408163330 | 999979541290029073 | 999979541290029073
activity:user:990192934408163330 | 999979536990867461 | 999979536990867461
activity:user:990192934408163330 | 999979532700094475 | 999979532700094475
cqlsh:minds> select * from entities_by_time where key='activity:user:990192934408163330' order by column1 asc limit 10;
key | column1 | value
----------------------------------+---------------------+---------------------
activity:user:990192934408163330 | 1000054880351555598 | 1000054880351555598
activity:user:990192934408163330 | 1000054884671688706 | 1000054884671688706
activity:user:990192934408163330 | 1000054888966656017 | 1000054888966656017
activity:user:990192934408163330 | 1000054893257429005 | 1000054893257429005
activity:user:990192934408163330 | 1000054897552396308 | 1000054897552396308
activity:user:990192934408163330 | 1000054901843169290 | 1000054901843169290
activity:user:990192934408163330 | 1000054906138136577 | 1000054906138136577
activity:user:990192934408163330 | 1000054910433103883 | 1000054910433103883
activity:user:990192934408163330 | 1000054914723876869 | 1000054914723876869
activity:user:990192934408163330 | 1000054919010455568 | 1000054919010455568
CREATE TABLE minds.entities_by_time (
key text,
column1 text,
value text,
PRIMARY KEY (key, column1)
) WITH COMPACT STORAGE
AND CLUSTERING ORDER BY (column1 ASC)
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment = ''
AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'enabled': 'false'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.0
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.1
AND speculative_retry = '99PERCENTILE';
Through inquiry, it is found that in Cassandra, 1007227353832624141 is less than 963426376394739730. Why?
Good call Chris! The table definition tells it all! I recreated your table and ran queries sorting in both directions:
flynn#cqlsh:stackoverflow> SELECT * FROM entities_by_time
WHERE key='activity:user:990192934408163330' ORDER BY column1 DESC;
key | column1 | value
----------------------------------+---------------------+---------------------
activity:user:990192934408163330 | 999979571363188746 | 999979571363188746
activity:user:990192934408163330 | 999979567064027139 | 999979567064027139
activity:user:990192934408163330 | 963426376394739730 | 963426376394739730
activity:user:990192934408163330 | 1007227353832624141 | 1007227353832624141
activity:user:990192934408163330 | 1000054884671688706 | 1000054884671688706
activity:user:990192934408163330 | 1000054880351555598 | 1000054880351555598
(6 rows)
flynn#cqlsh:stackoverflow> SELECT * FROM entities_by_time
WHERE key='activity:user:990192934408163330' ORDER BY column1 ASC;
key | column1 | value
----------------------------------+---------------------+---------------------
activity:user:990192934408163330 | 1000054880351555598 | 1000054880351555598
activity:user:990192934408163330 | 1000054884671688706 | 1000054884671688706
activity:user:990192934408163330 | 1007227353832624141 | 1007227353832624141
activity:user:990192934408163330 | 963426376394739730 | 963426376394739730
activity:user:990192934408163330 | 999979567064027139 | 999979567064027139
activity:user:990192934408163330 | 999979571363188746 | 999979571363188746
(6 rows)
So to your question...
in Cassandra, 1007227353832624141 is less than 963426376394739730. Why?
Simply put, because 9 > 1, that's why.
Your table definition clusters on column1, which is a TEXT/UTF8 string and not a numeric. Essentially, Cassandra is sorting strings the only way it knows how - in ASCII-betical order, which is not alpha-numeric order.
Store your numerics as numerics, and sorting will behave in ways that are more predictable.
i developed a table as shown as below with primary key as id which is a uuid type
id | date | eventtype | log | password | priority | sessionid | sourceip | user | useragent
--------------------------------------+--------------------------+--------------+----------+----------+----------+-----------+--------------+------------+------------
6b47e9b0-d11a-11e8-883c-5153f134200b | null | LoginSuccess | demolog | 1234 | 10 | Demo_1 | 123.12.11.11 | Aqib | demoagent
819a58d0-cd3f-11e8-883c-5153f134200b | null | LoginSuccess | demolog | 1234 | 10 | Demo_1 | 123.12.11.11 | Aqib | demoagent
f4fae220-d133-11e8-883c-5153f134200b | 2018-10-01 04:01:00+0000 | LoginSuccess | demolog | 1234 | 10 | Demo_1 | 123.12.11.11 | Aqib | demoagent
But when i try to query some thing like below
select * from loginevents where eventtype='LoginSuccess';
i get an error like below
InvalidRequest: Error from server: code=2200 [Invalid query] message="Predicates on non-primary-key columns (eventtype) are not yet supported for non secondary index queries"
This is my table
cqlsh:events> describe loginevents;
CREATE TABLE events.loginevents (
id uuid PRIMARY KEY,
date timestamp,
eventtype text,
log text,
password text,
priority int,
sessionid text,
sourceip text,
user text,
useragent text
) WITH bloom_filter_fp_chance = 0.01
AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
AND comment = ''
AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'}
AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'}
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99.0PERCENTILE';
How can i solve this
An immediate answer to your question would be to create a secondary index on the column eventtype like this:
CREATE INDEX my_index ON events.loginevents (eventtype);
Then you can filter on this particular column :
SELECT * FROM loginevents WHERE eventtype='LoginSuccess';
However this solution can badly impact the performances of your cluster.
If you come from the SQL world and are new to Cassandra, go read an introduction on cassandra modeling, like this one.
The first thing is to identify the query, then create the table according to.
In Cassandra, data are distributed in the cluster according to the partition key, so reading records that belong to the same partition is very fast.
In your case, maybe a good start would be to group your records based on the eventtype :
CREATE TABLE events.loginevents (
id uuid,
date timestamp,
eventtype text,
log text,
password text,
priority int,
sessionid text,
sourceip text,
user text,
useragent text,
PRIMARY KEY (eventtype, id)
)
Then you can do select like this :
SELECT * FROM loginevents WHERE eventtype='LoginSuccess';
or even :
SELECT * FROM loginevents WHERE eventtype in ('LoginSuccess', 'LoginFailure');
(It's not a perfect model, it definitely needs to be improved before production.)
In Cassandra, you can only query on the PRIMARY key and some of the clustering columns and it's not possible to query on all of the fields.
if you want to query on "eventtype" you should use secondary indexes in the definition of table or index table by Apache Solr and query using Solr.Some things like below:
CREATE INDEX loginevents_type
ON events.loginevents (eventtype);
I have following model in Cassandra:
CREATE TABLE segment (
organizationid varchar,
segmentid int,
lengthmm int,
optimal_speed int,
speed_limit int,
wkt varchar,
road_class int,
PRIMARY KEY (organizationid, segmentid)
);
Here the description of:
CREATE TABLE tkm_fcd_cassandra.segment (
organizationid text,
segmentid int,
lengthmm int,
optimal_speed int,
road_class int,
speed_limit int,
wkt text,
PRIMARY KEY (organizationid, segmentid)
) WITH CLUSTERING ORDER BY (segmentid ASC)
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment = ''
AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
When I run the following query:
select * from segment;
It gives me following result:
organizationid | segmentid | lengthmm | optimal_speed | road_class | speed_limit | wkt
----------------------------+-----------+----------+---------------+------------+-------------+---------------------------------------------------------
'57ecdd14766299a02213c463' | 122406 | 49239 | 20 | 5 | 90 | 'LINESTRING (32.813454 39.918419,32.813469 39.917976)'
'57ecdd14766299a02213c463' | 122407 | 49239 | 20 | 5 | 90 | 'LINESTRING (32.813469 39.917976,32.813501 39.917533)'
'57ecdd14766299a02213c463' | 122408 | 49239 | 20 | 5 | 90 | 'LINESTRING (32.813501 39.917533,32.813532 39.917091)'
'57ecdd14766299a02213c463' | 122409 | 49239 | 20 | 5 | 90 | 'LINESTRING (32.813532 39.917091,32.813542 39.91665)'
'57ecdd14766299a02213c463' | 122410 | 49239 | 20 | 5 | 90 | 'LINESTRING (32.813542 39.91665,32.813112 39.916359)'
But when I run the following query:
select * from segment where organizationid = '57ecdd14766299a02213c463';
I have the following result:
organizationid | segmentid | lengthmm | optimal_speed | road_class | speed_limit | wkt
----------------+-----------+----------+---------------+------------+-------------+-----
(0 rows)
Here is the my the nodetool status:
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN 192.168.1.101 5.16 MiB 256 100.0% 249c522d-ead0-4370-ac1b-4ad446d4948b rack1
Other info:
[cqlsh 5.0.1 | Cassandra 3.11.1 | CQL spec 3.4.4 | Native protocol v4]
I can't understand why Cassandra gives me empty result when I run where clause?
I looks like you have inserted your ID's with quotes around them. Try the following:
select * from segment where organizationid = '\'57ecdd14766299a02213c463\'';
Normally the output doesn't show ' around text values.
Want to know, how to apply TTL in column level.
below query set the TTL at record level
INSERT INTO excelsior.clicks (
userid, url, date, name)
VALUES
(
3715e600-2eb0-11e2-81c1-0800200c9a66,
'http://apache.org',
'2013-10-09', 'Mary'
)
USING TTL 86400;
whereas my requirement is setting TTL for a particular column. Is there any way to achieve this
You can do an INSERT with partial data:
cqlsh> create KEYSPACE test WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 1};
cqlsh> use test;
cqlsh:test> create table test(userid uuid, url text, date text, name text, primary key(userid));
cqlsh:test>
cqlsh:test> insert into test(userid, url, date, name) VALUES
... (
... 3715e600-2eb0-11e2-81c1-0800200c9a66,
... 'http://apache.org',
... '2013-10-09', 'Mary'
... )
... USING TTL 86400;
cqlsh:test>
cqlsh:test> select userid, url, TTL(url), date, TTL(date), name, TTL(name) from test;
userid | url | ttl(url) | date | ttl(date) | name | ttl(name)
--------------------------------------+-------------------+----------+------------+-----------+------+-----------
3715e600-2eb0-11e2-81c1-0800200c9a66 | http://apache.org | 86342 | 2013-10-09 | 86342 | Mary | 86342
(1 rows)
cqlsh:test> insert into test(userid, url ) VALUES (3715e600-2eb0-11e2-81c1-0800200c9a66, 'http://apache.org' ) USING TTL 864000;
cqlsh:test>
cqlsh:test> select userid, url, TTL(url), date, TTL(date), name, TTL(name) from test;
userid | url | ttl(url) | date | ttl(date) | name | ttl(name)
--------------------------------------+-------------------+----------+------------+-----------+------+-----------
3715e600-2eb0-11e2-81c1-0800200c9a66 | http://apache.org | 863992 | 2013-10-09 | 86109 | Mary | 86109
(1 rows)
cqlsh:test>
If you do an insert statement per column, you can set a TTL on each column individually.