Max*_*Max 16 performance nosql riak
在最后几天,我和riak玩了一下.我认为初始设置比较容易.现在我有一个3节点集群,所有节点都在同一个vm上运行,以便进行测试.
我承认,我的虚拟机的硬件设置非常降级(1个CPU,512 MB RAM),但我仍然对riak的缓慢性能感到非常惊讶.
地图减少
玩一点地图减少我在一个桶中有大约2000个对象,每个大约1k - 2k的大小为json.我使用了这个地图功能:
function(value, keyData, arg) {
var data = Riak.mapValuesJson(value)[0];
if (data.displayname.indexOf("max") !== -1) return [data];
return [];
}
仅执行http请求返回其结果花了2秒多,不计算我的客户端代码从json反序列化结果所花费的时间.删除3个节点中的2个似乎稍微将性能提升到略低于2秒,但这对我来说似乎仍然很慢.
这是预期的吗？对象的字节大小并不大,一个桶中的2000个对象也不是那么多.
插入
批量插入大约60,000个与上面相同大小的对象花了相当长的时间,实际上并没有真正起作用.
我在riak中插入对象的脚本在大约40.000左右死亡,并说它无法连接到riak节点.在riak日志中,我发现了一条错误消息,表明该节点内存耗尽而死亡.
题
这真是我在riak的第一枪,所以我肯定有机会搞砸了.
如果有更多riak经验的人可以帮我解决其中的一些问题,那对我来说真的会有很大的帮助.
Ale*_*ubo 31
这个答案有点晚了,但我想指出Riak的mapreduce实现主要是为了处理链接,而不是整个桶.
了Riak的内部设计实际上是非常优化的对抗与整个水桶的工作.这是因为存储桶不被视为顺序表,而是一个分布在节点集群上的密钥空间.这意味着随机访问非常快 - 可能是O(log n),但不要引用我 - 而串行访问非常非常非常慢.串行访问,就像Riak目前的设计方式,必然意味着要求所有节点提供数据.
顺便说一句,Riak术语中的"桶"令人困惑和令人失望,并没有像你想象的那样实现.Riak称之为桶的实际上只是命名空间.在内部,只有一个存储桶,密钥以存储桶名称作为前缀存储.这意味着无论您的存储桶有多小或多大,在一个大小为n的存储桶中枚举密钥都需要m次,其中m是所有存储桶中的密钥总数.
这些限制是Basho的实施选择,不一定是设计缺陷.Cassandra实现了与Riak完全相同的分区模型,但支持高效的顺序范围扫描和跨大量键的mapreduce.Cassandra也实现了真正的桶.
我没有直接使用 Riak 的经验，但使用过一点 Cassandra，这是相似的。
首先，性能可能在很大程度上取决于可用内核的数量和内存。这些系统通常具有大量流水线和并发性，并受益于大量内核。4+ 核心和 4GB+ 内存将是一个很好的起点。
其次，MapReduce 是为批处理而不是实时查询而设计的。
Riak 和所有类似的键值存储都是为简单查找的高写入性能和高读取性能而设计的，根本不需要复杂的查询。
仅供比较，单个节点（6 核，6GB）上的 Cassandra 每秒可以执行 20,000 次单独插入。