This should be straight forward, but I would like to have a confirmation from
the experts. I have the following 2 tables,
CREATE TABLE event (
event_id uuid,
... 38 attributes ...
PRIMARY KEY (event_id)
)
CREATE TABLE event_index (
index_key text,
time_token timeuuid,
event_id uuid,
PRIMARY KEY (index_key, time_token)
)
First I query the event_index table.
SELECT event_id FROM event_index WHERE index_key in ('key1', 'key2', ...
'key12') AND time_token > e1e0ede4-131e-11e6-aa76-7ff6a12535da AND time_token
<= 077b0930-133f-11e6-8080-808080808080 ORDER BY time_token ASC LIMIT 2000
Let's say we start from scratch, and let's say I do get 2000 rows for the 12
keys in 100ms (an arbitrary easy number), what would the Read Latency from
"noodtool cfstats keyspace.event_index" say? Is it 100/2000 = 0.05 ms (by 2000
CQL rows), or 100/12 = 8.33 ms (by 12 C* partition rows), or 100 ms determined
by 1 query?
Then I used "event_id" from the above query and construct a new query.
SELECT * FROM event where event_id in ('event_id1', 'event_id2', ...
'event_id2000')
If it takes 2 secs to return, would the Read Latency from "noodtool cfstats
keyspace.event" be 2000ms/2000 = 1 ms (2000 CQL rows = 2000 C* partition rows)?
What I have in my production looks like this
$ nodetool cfstats keyspace.event_index
Keyspace: keyspace
Read Latency: 3.3920196591165936 ms.
Write Latency: 0.01604441562534844 ms.
Table: event_index
Local read latency: 6.270 ms
Local write latency: 0.021 ms
----------------
$ nodetool cfstats keyspace.event
Keyspace: keyspace
Read Latency: 1.2564584604030888 ms.
Write Latency: 0.06379633105369285 ms.
Table: event
Local read latency: 1.056 ms
Local write latency: 0.084 ms
----------------
It looks to me that Read Latency is determined by C* partition rows since the
latency for "event_index" is larger than for "event" table. Could C* guru
confirm, or correct me if I am wrong?
Thanks,Dongfeng
