performance - Riak 性能 - 意想不到的结果

Question

在过去的几天里，我玩了一会儿 riak。最初的设置比我想象的要容易。现在我有一个 3 节点集群，为了测试，所有节点都在同一个虚拟机上运行。

我承认，我的虚拟机的硬件设置降级了很多(1 个 CPU，512 MB 内存)，但我仍然对 riak 的缓慢性能感到非常惊讶。

map 缩小

使用 map reduce 我在一个桶中有大约 2000 个对象，每个对象的大小约为 1k - 2k 作为 json。我使用了这个 map 功能:

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 交互的 PHP 客户端库是这里的限制因素？

在同一台物理机器上运行所有节点是相当愚蠢的，但如果这是一个问题 - 我怎样才能更好地测试 riak 的性能？

map reduce 真的那么慢吗？我在 riak 邮件列表上读到了 map reduce 对性能的影响，但是如果 Map Reduce 速度很慢，您应该如何对几乎实时所需的数据执行“查询”？我知道 riak 没有 redis 快。

如果在 riak 方面有更多经验的人可以帮助我解决其中的一些问题，那真的会对我有很大帮助。

Answer 1

这个答案有点晚了，但我想指出 Riak 的 mapreduce 实现主要设计用于处理链接，而不是整个存储桶。

Riak 的内部设计实际上针对使用整个存储桶进行了优化。这是因为桶不被认为是顺序表，而是分布在节点集群中的键空间。这意味着随机访问非常快——可能是 O(log n)，但不要引用我的话——而串行访问非常、非常、非常慢。串行访问，Riak 当前的设计方式，必然意味着向所有节点询问他们的数据。

顺便说一句，Riak 术语中的“桶”令人困惑和失望，并没有按照您可能认为的方式实现。 Riak 所说的桶实际上只是一个命名空间。内部只有一个bucket，key以bucket名称为前缀存储。这意味着无论您的桶有多大或多小，枚举单个大小为 n 的桶中的键都需要 m 时间，其中 m 是所有桶中的键总数。

这些限制是 Basho 的实现选择，不一定是设计缺陷。 Cassandra 实现了与 Riak 完全相同的分区模型，但支持跨大量键的高效顺序范围扫描和 mapreduce。 Cassandra 还实现了真正的桶。