在cqlsh中，cassandra表看起来是空的，但nodetool cfstats认为不是这样

使用nodetoolcfstats，我可以看到一个特定的表（表1）使用59mb，有545597个键。另一个相关表（表2）使用568mb，有2506141个键

使用cqlsh，当我从表1中选择count（*）时，它会暂停约7秒，然后返回0的计数。但是，如果我从表2中选择计数（*），它会暂停更长的时间，然后返回2481669的计数

我还尝试了从表1中选择*和从表2中选择*。第一个需要7秒，然后什么也不返回。第二个命令立即开始分页搜索结果

我很清楚这些都是昂贵的操作，但是这是在一台只有一个Cassandra实例的dev服务器上进行的。这是一个1的集群，不用于生产。我只是想弄明白为什么表1中的值是不可见的

表1是否可能实际上没有值？这不可能，因为我只是运行了一个作业来为它添加一些值。我还运行了“nodetool compact”，所以应该已经消除了所有的墓碑，cfstats应该显示实际存在的内容，对吗？下面是我运行了nodetool compact之后表1的cfstats：

            SSTable count: 1
            Space used (live): 59424392
            Space used (total): 59424392
            Space used by snapshots (total): 73951087
            Off heap memory used (total): 806762
            SSTable Compression Ratio: 0.28514022725059224
            Number of keys (estimate): 545597
            Memtable cell count: 393204
            Memtable data size: 17877650
            Memtable off heap memory used: 0
            Memtable switch count: 3
            Local read count: 5
            Local read latency: 0.252 ms
            Local write count: 545804
            Local write latency: 0.013 ms
            Pending flushes: 0
            Bloom filter false positives: 0
            Bloom filter false ratio: 0.00000
            Bloom filter space used: 611792
            Bloom filter off heap memory used: 611784
            Index summary off heap memory used: 180202
            Compression metadata off heap memory used: 14776
            Compacted partition minimum bytes: 216
            Compacted partition maximum bytes: 310
            Compacted partition mean bytes: 264
            Average live cells per slice (last five minutes): 1.0
            Maximum live cells per slice (last five minutes): 1
            Average tombstones per slice (last five minutes): 6.0
            Maximum tombstones per slice (last five minutes): 7

---

如果有帮助的话，我正在linux服务器上使用apache cassandra 2.2.0。

cassandra将所有数据保存在文件（sstables）中。对于速度，在文件末尾写入附加数据（索引的工作方式当然不同，但它们没有描述这些功能的工作方式…）

删除数据（或者在您的情况下是过期）不会从文件中删除数据，因为这将意味着大量的移动和大量的I/O。因此，它们只是将条目标记为“死”（因此称为墓碑）

每隔一段时间，压缩系统就会进来（假设您没有对该表关闭它）并压缩表。这意味着它从文件的开头读取，并将活动条目移到死条目上。或多或少，假设B在某个点被删除（从左到右的列表示不同的时间点），类似于这样的情况：

如果您的表有太多的墓碑，压缩可能会失败（我不明白为什么会失败，但这就是我读到的）。压缩失败的表被标记为“永远不要压缩”，这是一个大问题，如果你问我的话。而一个有50万个键的表很可能会失败

当表处于“删除”状态（包括墓碑）时，一个经过墓碑的

SELECT

仍然会创建一个

tombstone

内存对象（不要问我为什么，我不知道，否则Cassandra看起来不会正常工作…），因此，读取所有墓碑并为每个墓碑创建Java对象的时间为7秒

CQL接口包括一个功能，可用于查看表中的墓碑数量。它打印出一大堆你想知道的事情

TRACE ON;
SELECT COUNT( * ) FROM table1;

---

我发现这些值实际上已经过期了。异步插入失败，错误消息没有传播出去，因为未来被忽略。（愚蠢的错误）。我假设所有记录都已过期（它们都有ttl）。然而，我仍然想理解这些日志的含义，以便将来能够认识到这一点。这些日志如何以任何方式表示空表？

TRACE ON;
SELECT COUNT( * ) FROM table1;