当数据不适合内存时，适合 Erlang 应用程序的数据存储后端答案

【问题标题】：Suitable data storage backend for Erlang application when data doesn't fit memory当数据不适合内存时，适合 Erlang 应用程序的数据存储后端
【发布时间】：2010-09-22 04:21:36
【问题描述】：

我正在研究如何为 Erlang 应用程序组织数据存储的可能选项。它应该使用的数据基本上是由短字符串 id 索引的大量二进制 blob 集合。每个 blob 小于 10 Kb，但其中有很多。我希望它们的总大小可达 200 Gb，因此显然它无法装入内存。对该数据的典型操作是通过其 id 读取 blob 或通过其 id 更新 blob 或添加新的 blob。在一天中的每个给定时间段，只有一个 id 子集被使用，因此数据存储访问性能可能会受益于内存缓存。谈到性能 - 这是非常关键的。目标是在商用硬件（比如 EC2 VM）上每秒进行大约 500 次读取和 500 次更新。

有什么建议在这里使用吗？据我了解，dets 是毫无疑问的，因为它仅限于 2G（或者是 4G？）。 Mnesia 也可能没有问题；我的印象是它主要是为数据适合内存的情况设计的。我正在考虑尝试 EDTK 的 Berkeley DB 驱动程序来完成这项任务。它会在上述情况下工作吗？有没有人在类似条件下在生产中使用过它？

【问题讨论】：

标签： erlang mnesia data-storage dets

【解决方案1】：

tcerl 面临相同的大小限制。这些天我没有使用 Erlang，但这听起来像你在寻找的东西。

【讨论】：

这是为了回复，只是有点太晚了——我已经在我的应用程序中使用了 tcerl :)

【解决方案2】：

你看过 CouchDB 在做什么吗？它可能不是您所追求的产品，但其中有很多用于存储数据的 erlang 代码。还有一些关于提供本机 erlang 接口而不是 REST api 的讨论。

【讨论】：

【解决方案3】：

有什么理由不能只使用文件系统，将文件名视为字符串 id，将文件内容视为二进制 blob？您可以选择一个适合您的性能要求的（文件系统），并且您应该基本上免费获得由您的操作系统提供的缓存。

【讨论】：

实际上尝试了这个，发现这比基于 tcerl 的实现要慢一些。虽然我没有费心调整文件系统，而且虽然它比 tcerl 慢，但至少在基本基准测试中，它的速度足以满足我的要求。

【解决方案4】：

Mnesia 可以很好地将数据存储在磁盘上。还有大致类似于 Berkeley DB 的 dets（基于磁盘的术语存储）。它在标准库中：http://www.erlang.org/doc/apps/stdlib/index.html

【讨论】：

Dets 在我的项目中无法使用 - 引用文档：“Dets 文件的大小不能超过 2 GB”。 Mnesia 也是基于 dets 的，所以它继承了它的限制。作为一种解决方法，可以进行分区，但我怀疑性能会受到影响。从我有限的测试来看，速度相当慢。
我猜 2GB 的 dets 限制只存在于 32 位架构上...询问 erlang 邮件列表，无论如何可能比这里的 erlang 更好。

【解决方案5】：

我会推荐 Apache CouchDB。

它非常适合 Erlang，从它的声音（您提到基于 ID 的 blob 并没有提及任何关系要求）来看，您正在寻找面向文档的数据库。

由于接口是 REST，如果需要缓存，您可以非常简单地在其前面添加商品 HTTP 缓存。

CouchDB 的文档质量非常高。

它还内置了 Map-Reduce :)

【讨论】：