我正在研究如何爲Erlang應用程序組織數據存儲的可能選項。它應該使用的數據基本上是由短字符串ID索引的大量二進制blob集合。每個blob都在10Kb以下，但其中有很多。我預計總共它們的尺寸可能高達200GB，所以顯然它不能適應內存。對這些數據的典型操作是通過其id讀取blob或通過id更新blob或添加一個新的blob。在每天的特定時間段內，只有一部分ID正在使用，因此數據存儲訪問性能可能受益於內存中緩存。談到性能 - 這是非常關鍵的。目標是在商品硬件上每秒鐘有500次讀取和500次更新（例如在EC2 VM上）。當數據不適合內存時適用於Erlang應用程序的數據存儲後端
有什麼建議在這裏使用什麼？據我瞭解，dets是無可爭議的，因爲它限於2G（或者是4G嗎？）。 Mnesia可能也沒有問題;我的印象是它主要是爲數據適合內存的情況設計的。我正在考慮嘗試使用EDTK的Berkeley DB驅動程序。它會在上述情況下工作嗎？有沒有人在類似條件下的生產中使用它？
tcerl出來面臨相同的大小限制。我現在沒有使用Erlang，但它聽起來像你在找什麼。
Mnesia可以將數據存儲在磁盤上。還有dets（基於磁盤的術語存儲），它大致類似於Berkeley DB。它在標準庫中：http://www.erlang.org/doc/apps/stdlib/index.html
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的討論。
是否有任何理由不使用文件系統，將文件名作爲字符串ID和文件內容作爲二進制blob處理？你可以選擇一個適合你的性能要求的文件系統，你應該基本上免費提供緩存，由你的操作系統提供。
我會推薦Apache CouchDB。
這很適合Erlang，從它的聲音（你提到基於ID的blob並且沒有提及任何關係需求），你正在尋找一個面向文檔的數據庫。
由於界面是REST，如果需要緩存，您可以非常簡單地在它前面添加商品HTTP緩存。
CouchDB的文檔質量很高。
它還具有內置的地圖，減少:)
這是爲了答覆，但它有點太晚了 - 我已經在我的應用程序中玩tcerl :) – 2008-11-28 19:54:40