当数据无法容纳内存时，适合 Erlang 应用程序的数据存储后端

Question

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

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

Answer 1

特塞尔 摆脱了同样的尺寸限制。这些天我没有使用 Erlang，但它听起来像你正在寻找的。

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

我会推荐Apache CouchDB。

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

由于接口是REST，如果需要缓存，只需在其前面添加商品HTTP缓存即可。

CouchDB的文档质量非常高。

它还内置了Map-Reduce：）