我们创建一个表“bidresponses”，架构如下。 CREATE TABLE yp_rtb_new.bidresponses（ time_id bigint， campaignid int， bidid文字， adid int， 广告文字， appname文字， ...
PRIMARY KEY (time_id, campaignid, bidid)
） 并将此表的TTL设置为3天。我们通常每天插入20M记录。我们注意到一件奇怪的事情。 在前3天，我们可以运行“select * from bidresponses limit 10”。由于TTL发生第3次质量删除后，当我们运行“select * from bidresponses limit 10”时，我们得到了超时错误;运行“select * from bidresponses where time_id =？”，没有问题。我们试图强制紧凑，它没有帮助。 重新启动群集后，我们可以再次运行“select * from bidresposnse limit 10”。 任何的想法？
答案 0 :(得分：2)
我猜Cassandra必须阅读很多墓碑（标记为删除的数据）才能找到数据。那，和“SELECT * FROM table;”是一个完整的表/多分区扫描，它将导致超时，具体取决于许多因素（逻辑删除，节点数，分区数等）。
当你指定'time_id =？'时，你告诉Cassandra你想要什么分区，这意味着更少/没有网络跃点并寻求找到数据。
我发现这些文章特别有用和相关： http://www.datastax.com/dev/blog/basic-rules-of-cassandra-data-modeling https://lostechies.com/ryansvihla/2014/10/20/domain-modeling-around-deletes-or-using-cassandra-as-a-queue-even-when-you-know-better/
现在Cassandra有一个基于日期的压缩策略（日期分层压缩策略） - 你也可以使用它来做一些关于删除的智能建模。 http://www.datastax.com/dev/blog/datetieredcompactionstrategy
答案 1 :(得分：0)
Force compact会工作，之前我曾认为nodetool compact会对集群的所有主机产生影响。所以有些主机没有被压缩。在每个主机上压缩表之后。它有效。