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

我正在研究如何为Erlang应用程序组织数据存储的可能选项。它应该使用的数据基本上是由短字符串ID索引的大量二进制blob集合。每个blob都在10Kb以下，但其中有很多。我预计总共它们的尺寸可能高达200GB，所以显然它不能适应内存。对这些数据的典型操作是通过其id读取blob或通过id更新blob或添加一个新的blob。在每天的特定时间段内，只有一部分ID正在使用，因此数据存储访问性能可能受益于内存中缓存。谈到性能 - 这是非常关键的。目标是在商品硬件上每秒钟有500次读取和500次更新（例如在EC2 VM上）。当数据不适合内存时适用于Erlang应用程序的数据存储后端

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

来源

2008-11-13 Ilya Martynov

tcerl出来面临相同的大小限制。我现在没有使用Erlang，但它听起来像你在找什么。

来源

2008-11-25 17:22:00

这是为了答复，但它有点太晚了 - 我已经在我的应用程序中玩tcerl :) – 2008-11-28 19:54:40

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

来源

2008-11-17 18:34:57 a2800276

DETS是在我的项目不可用 - 引自文档“的DETS文件大小不能超过2 GB”。 Mnesia也基于dets，所以它继承了它的限制。作为一种解决方法，可以进行分区，但我怀疑性能会受到影响。从我有限的测试dets是相当缓慢。 – 2008-11-18 08:54:46

我猜想2GB的dets限制只存在于32位的arch上......不管怎样，在erlang邮件列表中，可能比erlang更好。 – a2800276 2008-11-18 14:32:23

你看过CouchDB在做什么了吗？它可能并不完全符合你在产品下降后的情况，但是存在很多用于存储数据的erlang代码。还有一些关于提供本地erlang接口而不是REST API的讨论。

来源

2008-11-25 16:58:57 Kerr

是否有任何理由不使用文件系统，将文件名作为字符串ID和文件内容作为二进制blob处理？你可以选择一个适合你的性能要求的文件系统，你应该基本上免费提供缓存，由你的操作系统提供。

来源

2008-11-25 20:31:49

我会推荐Apache CouchDB。

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

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

CouchDB的文档质量很高。

它还具有内置的地图，减少:)

来源

2009-01-07 16:42:55 bjnortier

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

回答

相关问题