CouchDB可以處理數千個獨立的數據庫嗎？

Question

CouchDB可以在同一臺機器上處理數千個不同的數據庫嗎？

想象一下，你有一個集合BankTransaction s。有成千上萬的記錄。 （編輯：沒有實際存儲事務 - 只是想到了非常大量的非常小的，經常更新的記錄，它基本上是一個來自SQL-land的連接表。）

每天你想要發生的事務的摘要視圖只在您當地的銀行分行。如果所有記錄都在單個數據庫中，則重新生成視圖將處理全部的分支的全部。這是一個更大的工作，對於只關心他特定文檔子集的用戶來說是不必要的。

這使得每個銀行分支似乎都應該劃分到自己的數據庫中，以便以更小的塊生成視圖，並且彼此獨立。但是我從來沒有聽說過任何人這樣做，而且這看起來像是一種反模式（例如，在數千個不同的數據庫中複製相同的設計文檔）。

有沒有不同的方式來模擬這個問題？ （分區應該發生在不同的機器之間，而不是單獨的數據庫在同一臺機器上？）如果不是，CouchDB可以處理成千上萬的數據庫以保持分區的小型化嗎？

（謝謝！）

Answer 1

[警告，我假設你在某種生產環境中運行此。如果這是一個學校或寵物項目，請附簡答。]

簡短回答是「是」。

較長的答案是，有一些事情你需要提防...

• 你會被打捶一個痣有很多的系統設置，如最大文件描述。

• 你也會玩Erlang虛擬機設置的重擊。

• CouchDB有一個「max open databases」選項。增加這一點，或者你將有懸而未決的請求。

• 這將是一個PITA來聚合多個數據庫來生成報告。您可以通過輪詢每個數據庫的_changes提要，修改數據，然後將其返回到中央/彙總數據庫中來實現。使這個更容易的工具僅僅在CouchDB的API中還沒有。幾乎，但不完全。

但是，如果您嘗試這樣做，您將遇到的最大問題是CouchDB本身並不橫向擴展[好]。如果你添加更多的CouchDB服務器，它們將會有重複的數據。當然，你的最大開放數據庫數將隨着每個節點的增加而線性擴展，但其他的東西如視圖生成時間不會（例如，它們都需要自己構建視圖）。

雖然我在BigCouch羣集上看到了數千個開放數據庫。有趣的是，這是因爲發電機羣集：更多的節點並行執行不同的事情，而不是CouchDB服務器相互複製。

乾杯。

Answer 2

多個數據庫是可能的，但大多數情況下，我想聚合數據庫實際上將您的分支機構提供更好的性能。請記住，只有在文檔更新到視圖中時才進行優化;每個文檔只能在每個視圖中解析一次。

對於最終的天輪詢在聚合數據庫，所述第一分支將導致要處理的新文檔的100％，並支付延遲的100％。所有其他分支機構將支付0％。所以大多數分行都受益對於單獨數據庫中的結束時間輪詢，所有分支都支付與其數量成比例的部分罰款，因此大多數分數略微落後。

全天頻繁更新視圖，活躍的分支喜歡聚集和小批量分支喜歡獨立。如果10中的一個分支添加了99％的文檔，則大多數更新工作將在其他分支的投票中完成，因此10箇中的9個更喜歡單獨的dbs。

如果這種延遲的問題，並假設沙發上有一定的時鐘週期去未使用的，你可以寫一個3線環/視圖/睡眠shell腳本的任何用戶等待之前更新一些文件。

Answer 3

我想補充一點，有大量的數據庫創建繞壓實和複製問題。不僅做這樣的事情連續複製需要在每個數據庫的基礎觸發（這意味着你將不得不在所有的數據庫編寫自定義的邏輯迴路），但每個數據庫他們也產卵複製守護進程。這可能很快變得過於禁忌。