[
https://issues.apache.org/jira/browse/CASSANDRA-10698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
C. Scott Andreas resolved CASSANDRA-10698.
------------------------------------------
Resolution: Cannot Reproduce
> Static column performance with DISTINCT
> ---------------------------------------
>
> Key: CASSANDRA-10698
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10698
> Project: Cassandra
> Issue Type: Bug
> Environment: Linux, cassandra 2.1.11
> Reporter: Brice Figureau
> Priority: Critical
> Labels: performance
> Attachments: bug-slow-distinct.tar.gz
>
>
> As described on the mailing list, with the following schema:
> {code:sql}
> CREATE TABLE akka.messages (
> persistence_id text,
> partition_nr bigint,
> sequence_nr bigint,
> message blob,
> used boolean static,
> PRIMARY KEY ((persistence_id, partition_nr), sequence_nr)
> ) WITH CLUSTERING ORDER BY (sequence_nr 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'}
> 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 = 216000
> 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';
> {code}
> The following query:
> {code:sql}
> SELECT used from akka.messages WHERE
> persistence_id = 'player-SW11f03e20b8802000' AND
> partition_nr = 0;
> {code}
> is quite slow, and as slow as the {{distinct}} version:
> {code:sql}
> SELECT DISTINCT used from akka.messages WHERE
> persistence_id = 'player-SW11f03e20b8802000' AND
> partition_nr = 0;
> {code}
> As shown with this tracing from a small unloaded 3 nodes cluster:
> {noformat}
> activity
> | timestamp | source |
> source_elapsed
> ---------------------------------------------------------------------------------------------------+----------------------------+----------------+----------------
>
> Execute CQL3 query | 2015-11-13 11:04:41.771000 | 192.168.168.12 |
> 0
> Parsing SELECT DISTINCT used ....
> [SharedPool-Worker-1] | 2015-11-13 11:04:41.771000 | 192.168.168.12 |
> 78
> READ message received from /192.168.168.12
> [MessagingService-Incoming-/192.168.168.12] | 2015-11-13 11:04:41.772000 |
> 192.168.168.29 | 22
> Preparing statement
> [SharedPool-Worker-1] | 2015-11-13 11:04:41.772000 | 192.168.168.12 |
> 271
> Executing single-partition query on messages
> [SharedPool-Worker-4] | 2015-11-13 11:04:41.772000 | 192.168.168.29 |
> 424
> reading data from /192.168.168.29
> [SharedPool-Worker-1] | 2015-11-13 11:04:41.772000 | 192.168.168.12 |
> 642
> Acquiring sstable references
> [SharedPool-Worker-4] | 2015-11-13 11:04:41.772000 | 192.168.168.29 |
> 445
> Sending READ message to /192.168.168.29
> [MessagingService-Outgoing-/192.168.168.29] | 2015-11-13 11:04:41.772000 |
> 192.168.168.12 | 738
> Merging memtable tombstones
> [SharedPool-Worker-4] | 2015-11-13 11:04:41.772000 | 192.168.168.29 |
> 476
> Key cache hit for sstable 1126
> [SharedPool-Worker-4] | 2015-11-13 11:04:41.773000 | 192.168.168.29 |
> 560
> Seeking to partition beginning in data file
> [SharedPool-Worker-4] | 2015-11-13 11:04:41.773000 | 192.168.168.29 |
> 592
> Skipped 0/1 non-slice-intersecting sstables, included 0 due to tombstones
> [SharedPool-Worker-4] | 2015-11-13 11:04:41.773000 | 192.168.168.29 |
> 960
> Merging data from memtables and 1 sstables
> [SharedPool-Worker-4] | 2015-11-13 11:04:41.774000 | 192.168.168.29 |
> 971
> Read 1 live and 0 tombstone cells
> [SharedPool-Worker-4] | 2015-11-13 11:04:47.301000 | 192.168.168.29 |
> 529270
> Enqueuing response to /192.168.168.12
> [SharedPool-Worker-4] | 2015-11-13 11:04:47.316000 | 192.168.168.29 |
> 544885
> Sending REQUEST_RESPONSE message to /192.168.168.12
> [MessagingService-Outgoing-/192.168.168.12] | 2015-11-13 11:04:47.317000 |
> 192.168.168.29 | 545042
> REQUEST_RESPONSE message received from /192.168.168.29
> [MessagingService-Incoming-/192.168.168.29] | 2015-11-13 11:04:47.429000 |
> 192.168.168.12 | 657918
> Processing response from /192.168.168.29
> [SharedPool-Worker-2] | 2015-11-13 11:04:47.429000 | 192.168.168.12 |
> 658224
>
> Request complete | 2015-11-13 11:04:47.525892 | 192.168.168.12 |
> 754892
> {noformat}
> As you can see, there's a 5 seconds delay between "Merging data" and "Read 1
> live and 0 tombstones" steps.
> Note that this row in particular is quite large, and has certainly a lots of
> tombstones. But I understood that when querying for a static column,
> cassandra shouldn't have to read everything, as the static column value
> exists in one place.
> Note that if the row cache is enabled, the row is then cached and it is very
> fast on subsequent request.
> I've attached the sstable in question, that exhibits the issue for this
> specific large row.
> Note that I didn't run any compaction on the sstable, because I'm not sure if
> the problem is coming from the tombstones on the said record.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
