Question

使用nodetool cfstats我可以看到一个特定的表（table1）正在使用59mb并且有545597个键。另一个相关表（table2）使用568mb并且有2,506,141个键。

使用cqlsh，当我执行select count( * ) from table1时，它会暂停约7秒，然后返回0的计数。但是，如果我执行select count( * ) from table2它会暂停更长时间，然后返回2,481,669的计数。

我还尝试了select * from table1和select * from table2。第一个需要7秒然后什么也不返回。第二个立即开始分页结果。

我很清楚这些是昂贵的操作，但是这是在单个开发服务器上，只有一个Cassandra实例。它是1的集群，不适合生产。我只是想弄清楚为什么table1中的值是不可见的。

table1可能实际上没有值吗？这应该是不可能的，因为我只是运行一个工作来添加一堆值。我还运行了“nodetool compact”，所以应该已经删除了所有的墓碑，而cfstats应该显示实际存在的内容，对吧？在我运行nodetool compact之后，以下是table1的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。

Answer 1

Cassandra将所有数据保存在文件中（sstables）。对于速度，写入会在文件末尾附加数据（索引的工作方式肯定不同，但它们没有描述这些函数的用途......）

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

有一段时间，压缩系统进来（假设你没有关闭该表）并压缩表。这意味着它从文件的开头读取并将实时条目移动到死文件上。或多或少，这样的假设B在某些时候被删除（从左到右的列代表不同的时间点）：

Creation    Deletion       Compaction

A           A              A
B           B-tombstone    C
C           C

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

当表处于“删除”状态（包括墓碑）时，遍历墓碑的SELECT仍会创建一个TombStone内存对象（不要问我为什么，我不知道，看起来像Cassandra不会正常工作......）因此，7秒钟读取所有墓碑并为每个墓碑创建Java对象。

CQL界面包含TRACE功能，可用于查看表格中的逻辑删除数。它会打印出一些你想知道的东西。

TRACE ON;
SELECT COUNT( * ) FROM table1;

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

1 个答案: