Bringing together the Apache Cassandra experts from the community and DataStax.

Want to learn? Have a question? Want to share your expertise? You are in the right place!

Not sure where to begin? Getting Started

 

question

HDC avatar image
HDC asked HDC commented

Cassandra 的查询会扫描老旧的SSTable吗?

我从机器上发现,使用getSSTable的命令获取到分区键所在的SSTable。其中共有6个SSTable。

然后用SSTable2Json打开,最旧的SSTable发现有超过4个月的墓碑。我没改过gc_grace_seconds,应该默认是10天。

我理解老的SSTable应该在新的SSTable生成后就删除了。

如果老的SSTable存在了,我只带分区键的查询会扫描老的SSTable吗?

如果会的话,这可能就是导致我查询超时的根因。

如果不会扫描老的SSTable, nodetool getSSTable的命令又把老旧的SSTable显示出来了。

cassandra
10 |1000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 1.0 MiB each and 10.0 MiB total.

1 Answer

wdeng avatar image
wdeng answered HDC commented

需要说明的一点是:gc_grace_seconds并不是一个从系统里删除tombstone的保证,它只会告诉Storage Engine在10天过了以后 *并且* 如果这个tombstone没有shadow其他的数据,那在下一次compaction发生的时候就可以安全的让这个tombstone消失了,但是它不会约束下一次compaction什么时候发生,也不保证发生了compaction会不会一定触及这个SSTable。所以你提到的这个老SSTable里面有超过4个月的墓碑的情况是有可能发生的。

这样的老墓碑和SSTable如果量比较大的话,确实会对读查询的性能造成一定的影响,因为读的时候很可能会扫描到。

另外,你提到“我理解老的SSTable应该在新的SSTable生成后就删除了“,这个是成立的,但是不能由此推论旧墓碑也会删除。每一个compaction发生的时候,确实是会把一个或多个老SSTable删除,生成一个或多个新SSTable。但是在新SSTable里,不是说compaction就一定不会把老SSTable里的旧墓碑再次写入到新SSTable里面去(即使旧墓碑的时间戳已经超过了十天)。发生这种情况的原因很多,一个比较常见的是,旧墓碑shadow了其他SSTable里的非墓碑数据(比如两个都是针对同一个partition的,但是旧墓碑的时间戳比其他SSTable里的非墓碑数据的时间戳 新一些),但是其他的SSTable因为各种原因还不能被compaction合并,这样的话,为了不发生zombie resurrection的情况,这个旧墓碑还得被带到新生成的SSTable里去。

3 comments Share
10 |1000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 1.0 MiB each and 10.0 MiB total.

有时间的话,可以再读一下这篇文章:https://thelastpickle.com/blog/2016/07/27/about-deletes-and-tombstones.html,特别是这一段“Mitigating the problems generated by tombstones”。

文章后面讨论区里的问答可能也会对你的深入理解有一定的启发,比如这个文后问题:http://disq.us/p/1rovz82

0 Likes 0 ·

有什么可能原因导致SSTable没法合并?

手动触发compaction,目前也没看到合并。

0 Likes 0 ·

从你提供的文章讨论中得到解答。

谢谢。

0 Likes 0 ·