我有一个使用TWCS的Cassandra表，带有1天的时间窗口，这意味着将在1天的时间窗口后进行压缩。因此，现在我的疑问是Cassandra将如何决定何时首次进行压缩-
1）就像我在4月1日上午10:00（IST）创建表格一样，在创建表格的1天后，因此压缩将在4月2日上午10:00开始 2）从00:00小时开始，这意味着每天的00:00小时，将开始压实。
我需要理解这个概念，就像每当我对表跟踪日志进行读取查询时都会显示数据来自多个SSTables，我需要知道为什么吗？我的表分区键是SensorID和日期。因此，按照概念，整个分区键都存储在一个节点上。因此，理想情况下，完整的分区应来自单个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压缩如何工作以及如何对其进行调整？