cql - cassandra read performance is bad -
i have 1 table contains 8 millions rows data in cassandra3.10. when did query follow : select max(glass_id) poc.dream time < '2017-04-01 00:00:00+0000' allow filtering
; time property partition key of table , data size selected 70 millions. bad performance reading, took 2mins result.
the primary key pk(time,glass_id);
the part of tracing log showed follow:
preparing statement [native-transport-requests-1] | 2017-04-07 14:58:55.598000 | 172.19.16.44 | 247 | 127.0.0.1 computing ranges query [native-transport-requests-1] | 2017-04-07 14:58:55.599000 | 172.19.16.44 | 771 | 127.0.0.1 range_slice message received /172.19.16.44 [messagingservice-incoming-/172.19.16.44] | 2017-04-07 14:58:55.599000 | 172.19.20.89 | 40 | 127.0.0.1 submitting range requests on 769 ranges concurrency of 1 (0.0 rows per range expected) [native-transport-requests-1] | 2017-04-07 14:58:55.599000 | 172.19.16.44 | 862 | 127.0.0.1 enqueuing request /172.19.20.89 [native-transport-requests-1] | 2017-04-07 14:58:55.599000 | 172.19.16.44 | 881 | 127.0.0.1 submitted 1 concurrent range requests [native-transport-requests-1] | 2017-04-07 14:58:55.599000 | 172.19.16.44 | 899 | 127.0.0.1 sending range_slice message /172.19.20.89 [messagingservice-outgoing-/172.19.20.89-small] | 2017-04-07 14:58:55.599000 | 172.19.16.44 | 937 | 127.0.0.1 executing seq scan across 0 sstables (min(-9223372036854775808), max(-9222003595370030342)] [readstage-1] | 2017-04-07 14:58:55.600000 | 172.19.20.89 | 369 | 127.0.0.1 read 0 live , 0 tombstone cells [readstage-1] | 2017-04-07 14:58:55.600000 | 172.19.20.89 | 517 | 127.0.0.1 enqueuing response /172.19.16.44 [readstage-1] | 2017-04-07 14:58:55.600000 | 172.19.20.89 | 575 | 127.0.0.1 sending request_response message /172.19.16.44 [messagingservice-outgoing-/172.19.16.44-small] | 2017-04-07 14:58:55.600000 | 172.19.20.89 | 977 | 127.0.0.1 request_response message received /172.19.20.89 [messagingservice-incoming-/172.19.20.89] | 2017-04-07 14:58:55.601000 | 172.19.16.44 | 3018 | 127.0.0.1 processing response /172.19.20.89 [requestresponsestage-2] | 2017-04-07 14:58:55.601000 | 172.19.16.44 | 3090 | 127.0.0.1 enqueuing request /172.19.20.5 [native-transport-requests-1] | 2017-04-07 14:58:55.601000 | 172.19.16.44 | 3168 | 127.0.0.1 enqueuing request /172.19.20.5 [native-transport-requests-1] | 2017-04-07 14:58:55.601000 | 172.19.16.44 | 3198 | 127.0.0.1 enqueuing request /172.19.20.89 [native-transport-requests-1] | 2017-04-07 14:58:55.601000 | 172.19.16.44 | 3210 | 127.0.0.1 sending range_slice message /172.19.20.5 [messagingservice-outgoing-/172.19.20.5-small] | 2017-04-07 14:58:55.601000 | 172.19.16.44 | 3210 | 127.0.0.1 enqueuing request /172.19.20.5 [native-transport-requests-1] | 2017-04-07 14:58:55.601001 | 172.19.16.44 | 3222 | 127.0.0.1 enqueuing request /172.19.20.89 [native-transport-requests-1] | 2017-04-07 14:58:55.601001 | 172.19.16.44 | 3230 | 127.0.0.1 sending range_slice message /172.19.20.89 [messagingservice-outgoing-/172.19.20.89-small] | 2017-04-07 14:58:55.601001 | 172.19.16.44 | 3232 | 127.0.0.1 enqueuing request /172.19.20.89 [native-transport-requests-1] | 2017-04-07 14:58:55.601001 | 172.19.16.44 | 3240 | 127.0.0.1 sending range_slice message /172.19.20.5 [messagingservice-outgoing-/172.19.20.5-small] | 2017-04-07 14:58:55.601001 | 172.19.16.44 | 3247 | 127.0.0.1 enqueuing request /172.19.20.5 [native-transport-requests-1] | 2017-04-07 14:58:55.601001 | 172.19.16.44 | 3249 | 127.0.0.1 enqueuing request /172.19.20.89 [native-transport-requests-1] | 2017-04-07 14:58:55.601001 | 172.19.16.44 | 3257 | 127.0.0.1 enqueuing request /172.19.20.5 [native-transport-requests-1] | 2017-04-07 14:58:55.601001 | 172.19.16.44 | 3264 | 127.0.0.1 sending range_slice message /172.19.20.5 [messagingservice-outgoing-/172.19.20.5-small] | 2017-04-07 14:58:55.601002 | 172.19.16.44 | 3267 | 127.0.0.1 executing seq scan across 0 sstables (max(-9153807552532774465), max(-9087147317664915466)] [readstage-2] | 2017-04-07 14:58:55.601002 | 172.19.16.44 | 3273 | 127.0.0.1 enqueuing request /172.19.20.89 [native-transport-requests-1] | 2017-04-07 14:58:55.601002 | 172.19.16.44 | 3273 | 127.0.0.1 sending range_slice message /172.19.20.89 [messagingservice-outgoing-/172.19.20.89-small] | 2017-04-07 14:58:55.601002 | 172.19.16.44 | 3274 | 127.0.0.1 enqueuing request /172.19.20.89 [native-transport-requests-1] | 2017-04-07 14:58:55.601002 | 172.19.16.44 | 3285 | 127.0.0.1 executing seq scan across 0 sstables (max(-9072913252686483927), max(-9071905664525634895)] [readstage-4] | 2017-04-07 14:58:55.601002 | 172.19.16.44 | 3284 | 127.0.0.1 sending range_slice message /172.19.20.5 [messagingservice-outgoing-/172.19.20.5-small] | 2017-04-07 14:58:55.601002 | 172.19.16.44 | 3290 | 127.0.0.1 enqueuing request /172.19.20.89 [native-transport-requests-1] | 2017-04-07 14:58:55.601002 | 172.19.16.44 | 3294 | 127.0.0.1 sending range_slice message /172.19.20.89 [messagingservice-outgoing-/172.19.20.89-small] | 2017-04-07 14:58:55.601002 | 172.19.16.44 | 3296 | 127.0.0.1 enqueuing request /172.19.20.89 [native-transport-requests-1] | 2017-04-07 14:58:55.601002 | 172.19.16.44 | 3304 | 127.0.0.1 sending range_slice message /172.19.20.5 [messagingservice-outgoing-/172.19.20.5-small] | 2017-04-07 14:58:55.601002 | 172.19.16.44 | 3307 | 127.0.0.1 enqueuing request /172.19.20.89 [native-transport-requests-1] | 2017-04-07 14:58:55.601002 | 172.19.16.44 | 3313 | 127.0.0.1 sending range_slice message /172.19.20.89 [messagingservice-outgoing-/172.19.20.89-small] | 2017-04-07 14:58:55.601003 | 172.19.16.44 | 3319 | 127.0.0.1 enqueuing request /172.19.20.5 [native-transport-requests-1] | 2017-04-07 14:58:55.601003 | 172.19.16.44 | 3321 | 127.0.0.1 read 0 live , 0 tombstone cells [readstage-4] | 2017-04-07 14:58:55.601003 | 172.19.16.44 | 3323 | 127.0.0.1 read 0 live , 0 tombstone cells [readstage-2] | 2017-04-07 14:58:55.601003 | 172.19.16.44 | 3323 | 127.0.0.1
you doing 2 things wrong in single query.
first : have not specified partition key cassandra needs execute query on each , every node
second : using aggregate method max()
, scan row (for case 70 millions row) give max number.
instead of using such query, change data model can specify partition key , specify glass_id
clustering key order desc.
Comments
Post a Comment