我正在使用Java客户端和sample code
的一些自定义版本在本地桌面上评估RIAK kV V2.1.1我担心的是我发现每KV需要花费近920bytes。
那太陡了。对于100kkvs,数据目录为93mb,并且在每100k Store操作之后保持线性增加。 这是预期的。
{{1}}
答案 0 :(得分:0)
riak用户邮件列表上有一个帖子,讨论了riak对象的开销,估计每个对象大约400字节。但是,这是在引入新对象格式之前,因此它已过时。这是一个新面貌。
首先我们需要一个本地客户端
(node1@127.0.0.1)1> {ok,C}=riak:local_client().
{ok,{riak_client,['node1@127.0.0.1',undefined]}}
创建一个具有0字节值的新riak对象
(node1@127.0.0.1)2> Obj = riak_object:new(<<"size">>,<<"key">>,<<>>).
#r_object{bucket = <<"size">>,key = <<"key">>,
contents = [#r_content{metadata = {dict,0,16,16,8,80,48,
{[],[],[],[],[],[],[],[],[],[],[],[],[],[],...},
{{[],[],[],[],[],[],[],[],[],[],[],[],...}}},
value = <<>>}],
vclock = [],
updatemetadata = {dict,1,16,16,8,80,48,
{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],...},
{{[],[],[],[],[],[],[],[],[],[],[],[],[],...}}},
updatevalue = undefined}
该对象实际上以简化的二进制格式存储:
(node1@127.0.0.1)3> byte_size(riak_object:to_binary(v1,Obj)).
36
这只是对象的36字节开销,但它不包括上次更新时间或版本向量等元数据,因此将其存储在Riak中并再次检查。
(node1@127.0.0.1)4> C:put(Obj).
ok
(node1@127.0.0.1)5> {ok,Obj1} = C:get(<<"size">>,<<"key">>).
{ok, #r_object{bucket = <<"size">>,key = <<"key">>,
contents = [#r_content{metadata = {dict,3,16,16,8,80,48,
{[],[],[],[],[],[],[],[],[],[],[],[],[],[],...},
{{[],[],[],[],[],[],[],[],[],[],[[...]],[...],...}}},
value = <<>>}],
vclock = [{<<204,153,66,25,119,94,124,200,0,0,156,65>>,
{3,63654324108}}],
updatemetadata = {dict,1,16,16,8,80,48,
{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],...},
{{[],[],[],[],[],[],[],[],[],[],[],[],[],...}}},
updatevalue = undefined}}
(node1@127.0.0.1)6> byte_size(riak_object:to_binary(v1,Obj)).
110
现在,对于在版本向量中具有单个条目的空对象,开销为110字节。如果对象的后续放置由不同的vnode协调,则它将添加另一个条目。我已经选择了存储桶和密钥名称,以便本地节点不是preflist的成员,因此第二个put具有由不同节点协调的合理概率。
(node1@127.0.0.1)7> C:put(Obj1).
ok
(node1@127.0.0.1)8> {ok,Obj2} = C:get(<<"size">>,<<"key">>).
{ok, #r_object{bucket = <<"size">>,key = <<"key">>,
contents = [#r_content{metadata = {dict,3,16,16,8,80,48,
{[],[],[],[],[],[],[],[],[],[],[],[],[],[],...},
{{[],[],[],[],[],[],[],[],[],[],[[...]],[...],...}}},
value = <<>>}],
vclock = [{<<204,153,66,25,119,94,124,200,0,0,156,65>>,
{3,63654324108}},
{<<85,123,36,24,254,22,162,159,0,0,78,33>>,{1,63654324651}}],
updatemetadata = {dict,1,16,16,8,80,48,
{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],...},
{{[],[],[],[],[],[],[],[],[],[],[],[],[],...}}},
updatevalue = undefined}}
(node1@127.0.0.1)9> byte_size(riak_object:to_binary(v1,Obj2)).
141
为版本向量中的其他条目添加了另外31个字节。
这些数字不包括使用值存储实际的存储桶和键名,或者Bitcask将它们再次存储在提示文件中,因此磁盘上的实际空间将为2x(bucketname size + keyname size) + value overhead + file structure overhead + checksum/hash size
如果你正在使用bitcask,文档中有一个计算器可以帮助你估算磁盘和内存要求:http://docs.basho.com/riak/kv/2.2.0/setup/planning/bitcask-capacity-calc/
如果您使用eLevelDB,您可以选择snappy压缩,这可能会减小磁盘上的大小。