Couch DB擴展和性能

Question

我正在考慮實現一個CouchDB服務器來提供我們爲內部業務操作而存儲的一些元數據的臨時搜索。

我們在內部流程中存儲了大量「屬性」，如大小，來源，提交日期和「職位」的URL。

這對我們的關係數據庫來說非常好，但我們的用戶希望通過提供類似於搜索的「搜索條件」來建立類似的工作列表。因此，用戶可以說「向我展示所有大於XXX並且在YYY之後提交的作業」並獲取描述和URL列表。

這聽起來非常適合沙發，從我研究過的東西看起來它會很好用。

我的問題是如何適當的硬件擴展？我們有1.5億到2億個這樣的文檔，每個文檔有11到30個屬性。元數據最多隻有幾千字節。我最初看着有一個四核服務器（VM）爲測試服務，但我需要它擴展到同時支持100到250個用戶。我知道我可以用大多數數據庫服務器做到這一點，但我正在尋找一些能夠提供臨時查詢方面的東西（通過REST或HTTP很好，我們有我們自己的搜索工具）。

有沒有人有過設置沙發的經驗，並將其用於此級別的生產負載？

Answer 1

併發連接不是問題，erlang和CouchDB是爲併發性能而構建的。

你是否認爲你將不得不動態地生成新的地圖函數，導致它有點像它？

每當你添加一個新的視圖映射函數，你將會在初始視圖生成中遇到一個很大的瓶頸。

如果您使用erlang視圖，它們會生成比javascript視圖更快的視圖，因爲它們不會執行JSON序列化步驟，這可顯着加快視圖生成性能。

一旦生成視圖，即使您正在談論的大小也會很快。