在 Riak 中存储二进制数据的缺点？

Posted 2023-02-23

【中文标题】在 Riak 中存储二进制数据的缺点？

【英文标题】：Downsides of storing binary data in Riak?

【发布时间】：2011-08-31 11:16:42

【问题描述】：

在 Riak 中存储二进制数据有什么问题（如果有的话）？

它会影响集群的可维护性和性能吗？

为此使用 Riak 而不是分布式文件系统之间的性能差异是什么？

【参考方案1】：

除了@Oscar-Godson 的出色答案之外，您可能会遇到值远大于 50MB 的问题。 Bitcask 最适合高达几 KB 的值。如果您要存储较大的值，您可能需要考虑其他存储后端，例如 innostore。

我没有存储二进制值的经验，但我们有一个中等规模的生产集群（5 个节点，大约 100M 的值，10 个 TB），我们经常看到与插入相关的错误并检索大小为 100 KB 的值。在这种情况下，性能是不一致的 - 有时有效，有时无效 - 因此，如果您要进行测试，请进行大规模测试。

在运行 map-reduce 查询时，我们还发现大值存在问题 - 它们只是超时。然而，这可能与二进制值不太相关......（正如@Matt-Ranney 提到的）。

另见@Stephen-C 的回答here

【讨论】：

嗨，Ben - 对于大小小于 1MiB 的对象，您不应该遇到任何性能问题。如果您想在 riak-users 邮件列表中提供有关您的集群的信息，我们其中一位 Bashos 可以帮助诊断。确保您已根据文档中的建议调整系统。

【参考方案2】：

我能想到的唯一问题是存储大于 50MB 的二进制数据，他们建议不要这样做。 Riak 的重点在于：

人们可能会选择 Riak 的另一个原因是 为您的数据建模提供灵活性。 Riak 将存储您告诉它的任何数据 以与内容无关的方式——确实如此 不强制执行表、列或 参照完整性。这意味着你 可以在旁边存储二进制文件 更多程序员透明的格式 例如 JSON 或 XML。

来源：Schema Design in Riak - Introduction

【讨论】：

请注意，大约 50MB 的问题是由 Erlang 网络分发缓冲区的硬编码大小限制引起的，而不是 Riak 中的任何内容。

Erlang 的默认设置有什么原因吗？只是“最佳实践”，还是会导致性能问题？

【参考方案3】：

对于 Riak，建议的最大值为每个对象 2MB。除此之外，建议使用 Riak CS，它已经测试了高达 5TB 的对象（在 Riak 中存储为 1MB 对象），或者通过自然地将大对象分解为 2MB 块并通过键和后缀链接。

【参考方案4】：

我个人没有注意到将图像和文档（DOC 和 PDF）等数据存储到 Riak 中的任何问题。我没有性能数据，但如果我记得的话，也许可以收集一些。

需要注意的是，对于 Riak，您可以使用 Luwak，它提供了一个用于存储大文件的 api。这非常有用。

【讨论】：

luwak 是否与 Riak 中的其他数据一起分发？

另外，luwak 是否通过 HTTP API 公开？我所看到的只是一个 erlang API。

AFAIK Luwak 只是 Riak 之上的一个层，它为您处理数据分块。对于 Riak 来说，其他一切都是正常的事情。

我通过 RiakJS 使用 Luwak，仅通过 HTTP API 支持（至少在 RiakJS 中）。

Luwak 有一个 HTTP API，它在整个集群中分发数据。 wiki.basho.com/Luwak.html

【参考方案5】：

一个问题可能是很难（如果不是不可能的话）在您的二进制数据中使用 javascript map/reduce。为此，您可能需要 Erlang。

【讨论】：

在 CouchDB 中，有一个单独的 API 用于存储二进制数据（附件），专门用于处理这种情况。只有关于附件的元数据才能映射/减少。

查看 Riak 链接。您可以拥有一个适合 m/r 的元数据对象，然后添加指向可选二进制对象的链接。

链接如何将其他链接对象排除在 map/reduce 之外？

您可以根据标记过滤您包含的链接 - 请参阅http://wiki.basho.com/Links-and-Link-Walking.html