Warning: file_get_contents(/data/phpspider/zhask/data//catemap/1/cassandra/3.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Nosql 卡桑德拉表和压实_Nosql_Cassandra - Fatal编程技术网

Nosql 卡桑德拉表和压实

Nosql 卡桑德拉表和压实,nosql,cassandra,Nosql,Cassandra,因此,我在研究卡桑德拉,试图了解该体系结构,并在维基上阅读以下页面: 因此,为了遵循这里的工作流程,您发送了一个更新表的请求,该请求被写入一个CommitLog,然后被写入一个名为Memtable的内存表(在系统发生故障时可以从CommitLog重建)。一旦Memtable达到一定大小,它会将整个Memtable刷新到磁盘上的SSTable,该SSTable不能再修改,只能在压缩过程中合并。当达到可配置数量的SSTable时,进行压缩,这基本上会合并结果,释放磁盘空间并创建一个新的、改进的最新

因此,我在研究卡桑德拉,试图了解该体系结构,并在维基上阅读以下页面:

因此,为了遵循这里的工作流程,您发送了一个更新表的请求,该请求被写入一个CommitLog,然后被写入一个名为Memtable的内存表(在系统发生故障时可以从CommitLog重建)。一旦Memtable达到一定大小,它会将整个Memtable刷新到磁盘上的SSTable,该SSTable不能再修改,只能在压缩过程中合并。当达到可配置数量的SSTable时,进行压缩,这基本上会合并结果,释放磁盘空间并创建一个新的、改进的最新SSTable。如果我理解这里有什么错误,请纠正我

现在我有几个关于压缩的问题。首先,这个手术有多贵?如果我要求在光盘上有两个SSTABLE时进行压缩,这是禁止的,还是最好等到半夜使用率下降时再进行压缩? 如果我有多个(但很小)SSTABLE,与有几个但非常大的SSTABLE相比,压缩是否更好?有很多未压缩的SSTables会影响读取性能吗?并发是如何工作的:如果我从这些SSTABLE中读取数据,然后有人执行一个insert,将一个新的Memtable刷新到磁盘,从而导致压缩,该怎么办


任何信息和经验,你可以提供这将是伟大的

尝试回答每个问题:

首先,这个手术有多贵

压缩必须复制它正在压缩的SSTables中的所有内容(减去从墓碑或覆盖中删除的内容)。然而,这比一开始看起来要便宜,因为压缩使用纯顺序IO,这在旋转的磁盘上又好又快

如果我要求在光盘上有两个SSTABLE时进行压缩,这是禁止的,还是最好等到半夜使用率下降时再进行压缩

这意味着你的写作成本将大大增加;假设每次写入都会导致一个新的SSTable;因此,每次写入都必须压缩之前的所有写入。写入N项的成本为N^2

更好的方法是采用压缩策略,如Acunu的Double Array所使用的策略:将每个SSTable(也称为数组)存储在一个“级别”中,并在一个级别中有两个数组时进行压缩,将输出数组提升到下一个级别。这可以显示为将每次写入的顺序IO摊销为O((logn)/B),同时将阵列数量限制为O(logn)

该方案在Castle中实现,Castle是Cassandra的一个(开源)存储引擎。有关更多信息,请参见此处:

注意:我在阿库努工作

如果我有多个(但很小)SSTABLE,与有几个但非常大的SSTABLE相比,压缩是否更好

使用较小的SSTABLE进行压缩将花费较少的时间,但您将不得不进行更多的压缩。真的,这是赛马场。但是,SSTable count和size确实会影响读取性能(请参阅下一个问题)

有很多未压缩的SSTables会影响读取性能吗

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

但是,使用get_切片查询时,您不能提前终止,因此您必须访问每一个可能在您的行中包含值的SSTable-因此,如果您有很多,那么get_切片的速度将较慢

对于get_range_切片,情况更糟,在这里您不能使用bloomfilter,每次调用都必须访问每个SSTable。这些调用的性能将与您拥有的SSTABLE的数量成反比

此外,对于数千个SSTable,bloom filter误报率(~1%)将开始受到影响,因为每次查找都必须查找10个不包含该值的SSTable

并发是如何工作的:如果我从这些SSTABLE中读取数据,然后有人执行一个insert,将一个新的Memtable刷新到磁盘,从而导致压缩,该怎么办

在Cassandra中,一旦内存中不再有对磁盘的引用,就会删除磁盘的SSTables(由垃圾收集器决定)。所以reads不需要担心,旧的SSTables会被懒散地清理掉

谢谢


Tom

我在这里写到了Cassandra 1.0支持的不同压缩策略:


tldr:分级压缩在压缩方面更具攻击性,因此建议用于具有大量读取的工作负载。

谢谢!只有几个澄清问题:当你说“想象每一次写操作都会创建一个新的SSTable”时,你的意思是在假设的情况下,你有一个非常大的写操作,对吗?第二,你能澄清为什么reads不需要担心SSTables消失吗?我的意思是,如果我必须读N个SSTable,我已经读了其中的一半,然后在我完成之前删除剩下的部分,这不是一个问题吗?>当你说“想象每一次写入都会创建一个新的SSTable”时,你的意思是在假设的情况下,你有一个非常大的写入,对吗?我这样做只是为了简化数学。实际上,您可能会有一些批(B)写入创建一个新的SSTable,但我认为对于N次写入,这只是O(N^2/B),或者每次写入都是O(N/B)(与O((logn)/B)相比,这确实是相当大的)>其次,您能否澄清为什么读取不需要担心SSTables消失?在Castle中,我们对每个SSTable进行引用计数;在读取操作开始时,我们对每个SSTable上的引用计数进行计数,以阻止它们消失。当引用计数为零时(由于合并或读取完成)这张桌子真的很好