2010-06-22 36 views
2

我不是指查看來源,存儲在_design文檔(這些複製,因爲他們只是文檔)。我的意思是做查看結果(計算的樹)複製,或者只做常規文檔複製(這是我現在的理解)。do couchdb查看複製?

有問題的情況是:
有一個流量高峯,我想調出一個臨時服務器,並將數據集的一部分複製到該新服務器上。那些(待複製的)文檔的視圖已經在舊服務器上計算出來了,因此不需要在新服務器上重新計算......所以我希望將這些舊的計算結果與文檔的部分一起傳輸。

另一種情況是使用後端羣集來計算複雜視圖,然後將這些結果複製到實際被用戶請求擊中的一堆前端服務器上。

回答

1

計算結果不會被複制。

這裏有一些額外的想法,但:

  • 分區時你的服務器和造就了第二個服務器用它,你如何分配讀/寫,並結合查看結果?這個設置需要一些想法的代理,我建議你看看CouchDB-Lounge

  • 如果您在做master-master,您可以使用DRDB使服務器保持同步。它已被證明與mysql master-master複製一起工作,我不明白爲什麼它不會在這裏工作。這也意味着計算結果在兩臺服務器上自動同步。

讓我知道這是否有幫助!

5

至於說,結果不復制。有關更多詳細信息,您實際上不希望它們被複制。您應該記住的一般CouchDB範例是每個安裝都被視爲獨立節點 - 這就是爲什麼_id,_rev和序列號非常重要。這使得每個節點都可以在不考慮任何其他節點的情況下工作:如果其中一個節點出現故障,其他所有節點都將繼續在世界上無所事事地搖擺。

當然,這引入了您可能不習慣的一致性的新考慮。例如,如果您有多個Web服務器,每個Web服務器上都有自己的CouchDB節點,並且這些節點之間運行復制以便每個實例保持最新狀態,則節點之間會存在延遲。下面是一個例子流程:

  1. 用戶寫入更改Web服務器A.
  2. 用戶發出讀取請求到web服務器B,因爲你的負載均衡決定,B爲更好的選擇。用戶獲得他們的結果。
  3. Web服務器A通過複製向Web服務器B發送更新的文檔。

正如您所看到的,用戶獲得了他們文檔的以前版本,因爲Web服務器B不知道有關更改。這可以被擊敗...

  • 堅持會議,以便他們所有的讀寫都去同一臺服務器。這可能最終會破壞你的負載平衡器。
  • 將CouchDB節點從Web服務器移到它們自己的盒子上。如果你這樣做,那麼你可能想看看couchdb-lounge項目(http://tilgovi.github.com/couchdb-lounge/)。
  • 您的用戶是否真的關心他們是否得到陳舊的結果?您的用例可能是您的用戶不會注意到他們的結果是否不反映他們剛纔所做的更改。確保你真的從這項工作中獲得了顯着的價值。

乾杯。