我有一个Cassandra表使用twcs与1天的时间窗口，这意味着压缩将在1天的窗口后完成。所以，现在我的问题是，Cassandra将如何决定何时第一次进行压缩-
1） 恰好在创建表的1天之后，就像我在4月1日上午10:00（ist）创建表一样，因此压缩将在4月2日上午10:00开始2）它从00:00开始，这意味着每天的00:00开始压缩。
我需要理解这个概念，就像每当我对一个表进行read查询时，跟踪日志显示数据来自多个sstable，我需要知道为什么？我的表分区键是sensorid和date。因此，根据概念，整个分区密钥存储在一个节点上。因此，理想情况下，完整的分区应该来自单个sstable。我会和你分享追踪日志，让你更清楚。
Tracing session: 5ddecd60-546a-11e9-83a5-4bbd3b5675f1
activity | timestamp | source | source_elapsed | client
---------------------------------------------------------------------------------------------------------------------------------------+----------------------------+-------------+----------------+-------------
Execute CQL3 query | 2019-04-01 10:39:02.966000 | 192.168.0.2 | 0 | 192.168.0.2
READ message received from /192.168.0.2 [MessagingService-Incoming-/192.168.0.2] | 2019-04-01 10:39:01.915000 | 192.168.0.3 | 74 | 192.168.0.2
Executing single-partition query on locationinfohash [ReadStage-1] | 2019-04-01 10:39:01.916000 | 192.168.0.3 | 380 | 192.168.0.2
Acquiring sstable references [ReadStage-1] | 2019-04-01 10:39:01.916000 | 192.168.0.3 | 452 | 192.168.0.2
Partition index with 0 entries found for sstable 112 [ReadStage-1] | 2019-04-01 10:39:01.916000 | 192.168.0.3 | 588 | 192.168.0.2
Partition index with 0 entries found for sstable 111 [ReadStage-1] | 2019-04-01 10:39:01.916000 | 192.168.0.3 | 900 | 192.168.0.2
Partition index with 0 entries found for sstable 110 [ReadStage-1] | 2019-04-01 10:39:01.916000 | 192.168.0.3 | 1177 | 192.168.0.2
Partition index with 0 entries found for sstable 89 [ReadStage-1] | 2019-04-01 10:39:01.917000 | 192.168.0.3 | 1466 | 192.168.0.2
Key cache hit for sstable 52 [ReadStage-1] | 2019-04-01 10:39:01.917000 | 192.168.0.3 | 1673 | 192.168.0.2
Skipped 0/5 non-slice-intersecting sstables, included 0 due to tombstones [ReadStage-1] | 2019-04-01 10:39:01.917000 | 192.168.0.3 | 1726 | 192.168.0.2
Merged data from memtables and 5 sstables [ReadStage-1] | 2019-04-01 10:39:01.922000 | 192.168.0.3 | 6639 | 192.168.0.2
Read 100 live rows and 0 tombstone cells [ReadStage-1] | 2019-04-01 10:39:01.922000 | 192.168.0.3 | 6854 | 192.168.0.2
Enqueuing response to /192.168.0.2 [ReadStage-1] | 2019-04-01 10:39:01.922000 | 192.168.0.3 | 6926 | 192.168.0.2
Sending REQUEST_RESPONSE message to /192.168.0.2 [MessagingService-Outgoing-/192.168.0.2-Small] | 2019-04-01 10:39:01.922000 | 192.168.0.3 | 7181 | 192.168.0.2
READ message received from /192.168.0.2 [MessagingService-Incoming-/192.168.0.2] | 2019-04-01 10:39:02.186000 | 192.168.0.1 | 42 | 192.168.0.2
Executing single-partition query on locationinfohash [ReadStage-6] | 2019-04-01 10:39:02.187000 | 192.168.0.1 | 824 | 192.168.0.2
Acquiring sstable references [ReadStage-6] | 2019-04-01 10:39:02.187000 | 192.168.0.1 | 967 | 192.168.0.2
Partition index with 0 entries found for sstable 68 [ReadStage-6] | 2019-04-01 10:39:02.187000 | 192.168.0.1 | 1135 | 192.168.0.2
Partition index with 0 entries found for sstable 67 [ReadStage-6] | 2019-04-01 10:39:02.187001 | 192.168.0.1 | 1437 | 192.168.0.2
Partition index with 0 entries found for sstable 66 [ReadStage-6] | 2019-04-01 10:39:02.188000 | 192.168.0.1 | 1863 | 192.168.0.2
Key cache hit for sstable 45 [ReadStage-6] | 2019-04-01 10:39:02.188000 | 192.168.0.1 | 2277 | 192.168.0.2
Skipped 0/4 non-slice-intersecting sstables, included 0 due to tombstones [ReadStage-6] | 2019-04-01 10:39:02.188000 | 192.168.0.1 | 2354 | 192.168.0.2
Merged data from memtables and 4 sstables [ReadStage-6] | 2019-04-01 10:39:02.194000 | 192.168.0.1 | 8300 | 192.168.0.2
Read 100 live rows and 0 tombstone cells [ReadStage-6] | 2019-04-01 10:39:02.195000 | 192.168.0.1 | 8529 | 192.168.0.2
Enqueuing response to /192.168.0.2 [ReadStage-6] | 2019-04-01 10:39:02.195000 | 192.168.0.1 | 8599 | 192.168.0.2
Sending REQUEST_RESPONSE message to /192.168.0.2 [MessagingService-Outgoing-/192.168.0.2-Small] | 2019-04-01 10:39:02.195000 | 192.168.0.1 | 8908 | 192.168.0.2
Parsing select * from trackfleet_db.locationinfohash where pkhash = '34AAB6D5F1431151211AF721F951057F'; [Native-Transport-Requests-1] | 2019-04-01 10:39:02.966000 | 192.168.0.2 | 140 | 192.168.0.2
Preparing statement [Native-Transport-Requests-1] | 2019-04-01 10:39:02.966000 | 192.168.0.2 | 219 | 192.168.0.2
reading data from /192.168.0.1 [Native-Transport-Requests-1] | 2019-04-01 10:39:02.966000 | 192.168.0.2 | 401 | 192.168.0.2
speculating read retry on /192.168.0.3 [Native-Transport-Requests-1] | 2019-04-01 10:39:02.967000 | 192.168.0.2 | 462 | 192.168.0.2
Sending READ message to /192.168.0.1 [MessagingService-Outgoing-/192.168.0.1-Small] | 2019-04-01 10:39:02.967000 | 192.168.0.2 | 504 | 192.168.0.2
Sending READ message to /192.168.0.3 [MessagingService-Outgoing-/192.168.0.3-Small] | 2019-04-01 10:39:02.967000 | 192.168.0.2 | 558 | 192.168.0.2
REQUEST_RESPONSE message received from /192.168.0.3 [MessagingService-Incoming-/192.168.0.3] | 2019-04-01 10:39:02.976000 | 192.168.0.2 | 9643 | 192.168.0.2
Processing response from /192.168.0.3 [RequestResponseStage-16] | 2019-04-01 10:39:02.976000 | 192.168.0.2 | 9700 | 192.168.0.2
REQUEST_RESPONSE message received from /192.168.0.1 [MessagingService-Incoming-/192.168.0.1] | 2019-04-01 10:39:02.976000 | 192.168.0.2 | 10372 | 192.168.0.2
Processing response from /192.168.0.1 [RequestResponseStage-10] | 2019-04-01 10:39:02.977000 | 192.168.0.2 | 10447 | 192.168.0.2
Initiating read-repair [RequestResponseStage-10] | 2019-04-01 10:39:02.977000 | 192.168.0.2 | 10479 | 192.168.0.2
Request complete | 2019-04-01 10:39:02.976914 | 192.168.0.2 | 10914 | 192.168.0.2需要解释为什么它是从sstable读取的，twcs压缩是如何工作的，我们如何调整它？
暂无答案！
目前还没有任何答案，快来回答吧！