当前位置 : 主页 > 编程语言 > 其它开发 >

Cassandra的限制

来源:互联网 收集:自由互联 发布时间:2022-05-25
大家在使用Cassandra的时候,往往容易忽视Cassandra本身的限制。 在Wiki中,我们可以看到Cassandra的限制: CassandraLimitations Cassandra的设计限制 这一类限制是在当前的体系架构中无法改变的。

大家在使用Cassandra的时候,往往容易忽视Cassandra本身的限制。

在Wiki中,我们可以看到Cassandra的限制:CassandraLimitations

Cassandra的设计限制

这一类限制是在当前的体系架构中无法改变的。

每一个key对应的value不能超过磁盘本身的容量限制。

这是因为Cassandra是将每一个key对应的value存储在本地磁盘上面的,所以当某一个key对应的vaule的大小超过了本地磁盘的容量上限,那么当Cassandra记录commitlog的时候就会失败,写入到SSTable中同样会失败。

这一点与Hadoop中的DFS不同,DFS是将本机分块存储的,所以无所谓文件的最大上限。

Cassandra当前的版本限制

这一类限制是在可以通过修改代码和版本升级改变的。

key的长度大小限制在65535之内

这个限制是由于Cassandra内部在将key写入到磁盘的时候,采用的是java.io.DataOutputStream.writeUTF(String, DataOutput),这个方法内部对key的大小有一个65535的限制。

在Cassandra中,所有的添加和修改操作会经过一个org.apache.cassandra.thrift.ThriftValidation.validateKey(String)进行判断,如果key的长度超过65535将抛出异常。不过这个方法也不能保证不会出现问题:因为Cassandra最终写入磁盘时候的key是一个被包装后的key,会添加token的信息,所以即使key本身的长度没有超过65535,被包装后的key的长度也有可能超过65535。

不过这个不是一个大问题,即使是,也可以容易修改掉:)

执行SSTable压缩操作的时消耗大量内存

在Cassandra执行将多个SSTable合并为一个SSTable时候,会将需要合并的key对应的所有value合并到。

如果某一个key对应的value非常大,那么就需要大量的内存来保持value。同时在写入的时候,我们需要记录value的大小。如果value的长度超过了Integer的限制,也会出现问题。

我们在Cassandra的配置文件storage-conf.xml中可以看到这么一个配置选项:RowWarningThresholdInMB,它的作用就是设置一个阀值,当压缩时某一个key对应的value大小超过这个阀值的时候,在日志中记录一条WARN信息。

这个问题将会在0.7的版本中修复。

SupperColumn下的Column无索引

现在的SSTable格式由包括3种文件组成:data,index和filter。其中filter文件用于判断需要寻找的key是否在data中,index文件用于快速定位每一个key在data文件中的位置,data文件中不仅保持了key和该key对应的value(这些value就是一系列Column),同时还有对应value的filter和index。

同理,data文件中的filter用于判断某一个Column是否存在(根据Column的Name),index用于快速定位这个key下面的这个Column在文件中的位置。

但是这里存在一个问题:data文件中的index只有一级索引,即如果都是Column,那么可以很快定位到所有的Column的位置。但如果是SupperColumn,那么只能定位到某一个SupperColumn的位置,而无法定位到SupperColumn下面的某一个Column的位置。

这种SSTable的设计就造成了一个很严重的问题:如果我们读取某一个key下的SupperColumn下的某一个Column的数据,那么Cassandra会将该SupperColumn下的所有数据都读取出来,然后找到我们需要的Column数据。

这也就造成了如果某一个SupperColumn数据量非常大,那么读取的时间也会非常长的现象。

要解决这个问题,需要一种新的SSTable的格式。

这个问题暂时还没有指定修复的版本。

Client端一次性从Cassandra中无法获取大量的数据

由于Cassandra是使用Thrift提供外部接口,所以Client端和Cassandra交互的时候,所有的数据传输都要先放到机器的内存中,再进行传输。假设我们使用multiget接口(关于Cassandra的编程接口,可以参考:谈谈Cassandra的客户端)获取一些列key的值,并且这些key的值都比较大,超过了内存的限制,那么这种交互将永远不会成功。

所以我们应该做的就是避免出现这个大量的请求操作。如果交互的数据量非常大,可以考虑压缩或者是拆分的策略。

这个问题暂时还没有指定修复的版本。

Client端如果发送不符合要求的数据,会导致Cassandra运行出错

我们使用Cassandra的时候,都是使用Cassandra提供的一系列Thrift API来调用的,包括Java,PHP,Python等等。但是我们要是通过这些Thrift发送一些不符合要求的数据,就会导致Cassandra运行出错。这个问题是由于Thrift本身的原因造成的。

但是这个问题不是一个大问题:只要我们不要暴露Cassandra的Thrift端口给外部直接使用即可。

这个问题将会在0.7的版本中修复。

【转自:美国高防服务器 http://www.558idc.com/usa.html转载请说明出处】
上一篇:利用WCF的P2P共享剪贴板上的数据
下一篇:没有了
网友评论