nosql – Cassandra SSTables和Compaction

Firstly,how expensive is this operation?

压缩必须复制它正在压缩的SSTable中的所有内容(减去来自墓碑或覆盖的任何湮灭).然而,这比起初看起来要便宜,因为压缩使用纯粹的顺序IO,这在旋转磁盘上是好的和快速的.

If I demanded a compaction whenever we have two SSTables on disc,would this be prohibitive,or would I be better served waiting until the middle of the night when usage is down?

这意味着您的写入会变得更加昂贵;想象每次写入都会导致新的SSTable;因此,每次写入都必须压缩所有写入之前的写入.编写N项的成本为N ^ 2.

更好的想法是采用类似Acunu的双倍数组使用的压缩策略：将每个SSTable(aka数组)存储在“级别”中,并在级别中有两个数组时压缩它们,将输出数组提升到下一级别.这可以显示为每次写入分摊到O((log N)/ B)顺序IO,同时将阵列数限制为O(log N).

该方案在Castle,Cassandra的(开源)存储引擎中实现.有关更多信息,请参阅此处：

> http://skillsmatter.com/podcast/nosql/castle-big-data
> http://www.acunu.com/blogs/tom-wilkie/castle-storage-engine-oscon/

NB我为Acunu工作

Is compaction any better if I have multiple (but small) SSTables vs having a few but very large SSTables?

使用较小的SSTable进行压缩将花费更少的时间,但您必须完成更多的操作.真的是它的马匹课程. SSTable计数&但是,尺寸会影响读取性能(参见下一个问题)

Does having a lot of non-compacted SSTables affect read performance?

对于点读取,不是很多：Cassandra(和Castle)有Bloom过滤器,以避免在知道密钥不存在时查看SSTables,并且当它找到正确的值时可以提前终止(通过对值使用时间戳)和SSTables).

但是,使用get_slice查询时,您无法提前终止,因此您必须访问可能包含行中值的每个SSTable – 因此,如果您有很多,则get_slices将会更慢.

get_range_slices的情况更糟,你不能使用bloom过滤器,每次调用都必须访问每个SSTable.这些调用的性能将与您拥有的SSTable数量成反比.

更重要的是,有数千个SSTables,布隆过滤器误报率(~1％)将开始受到伤害,因为每次查找都需要查看10个不包含该值的SSTable！

How does concurrency work with this: what if I’m reading from these SSTables,then someone does an insert which flushes a new Memtable to disk,which in turn causes a compaction?

在Cassandra中,一旦在内存中没有对它的引用(由垃圾收集器决定),SSTable就会被删除.所以读取不需要担心,旧的SSTables会被懒散地清理掉.

谢谢

汤姆