Couchbase滯後和意見

我認爲Couchbase也許能解決很多問題，在我目前的項目，但也有我需要確保第一的一些基本的東西：Couchbase滯後和意見

1）說我有一個具有10個節點的集羣，我向節點A添加一個文檔。然後向節點B請求該文檔，我是否肯定會將文檔返回？是否存在我請求節點B並認爲文檔不存在的風險？

2）現在說我寫了一個視圖，以便我可以查看某個作者的所有文檔。我向節點A添加一個文檔。我知道，在文檔被索引時，這個文檔會出現在視圖中有一定的滯後時間。我想知道的是，由於我只是索引1文件，所以這個滯後時間會非常小嗎？

基本上我有一個網站，管理的東西在1億文件的順序。一次有成千上萬的用戶，因此大約有10到20臺服務器在運行。在當前的體系結構下，如果我將文檔插入到節點A中，那麼當我查找該文檔時，我可能正在訪問節點B以獲取它。所以我的總體問題是：

用戶將文檔插入到節點A中，然後向他們顯示其所有文檔的屏幕。如果我使用的是Couchbase，則此屏幕將是查詢以Author爲關鍵字的視圖的結果。用戶很可能無法看到他們剛發佈的文檔？

2013-02-01 shmish111

無論您問什麼節點，您都將始終能夠取回文檔。如果您使用其中一個Couchbase SDK，那麼他們將始終確保他們詢問擁有該文檔的節點。如果你使用moxi，那麼它會做同樣的事情，所以你不應該擔心這一點。
這取決於您的寫入工作量有多大。在當前的體系結構（2.0）中，文檔在索引之前必須打開磁盤。如果您的寫入工作量很大，那麼滯後將會增加，因爲需要將更長的項目寫入磁盤。我建議您根據您的特定應用程序需求進行基準測試，並在Couchbase論壇上發佈您遇到的任何問題或問題。

此外，您還需要查看具有持久性要求的命令，並將陳舊查詢參數設置爲false進行查詢。持久性命令將允許你讓應用程序阻塞，直到一個項目命中磁盤，並且將陳舊設置爲false的查詢將確保你的視圖與放入Couchbase的最新項目保持同步。這個過程將確保你的用戶總是看到你的最新結果

編輯：Couchbase 3.0不再需要項目被保存到磁盤之前，他們可以被查詢。

2013-02-02 20:11:27 mikewied

謝謝，我想我只能完全的負載測試解決問題的第二部分，雖然我不知道是否有人曾與類似負載的經驗嗎？ – shmish111

在我看來，這裏的關鍵信息是你的寫入吞吐量。服務器平均每秒處理多少個項目。我不認爲你將這些信息作爲問題的一部分。 – mikewied

所以我剛剛發現，我們正在研究大約每秒10個文檔的寫法，也許在將來我可以看到，但我不會想到超過一個數量級...... – shmish111

查看更新是可調參數。默認情況下，線程每5秒喚醒一次，檢查更改並在找到它們時更新索引。調整這些參數或使用查看參數stale=false進行查詢。

從文檔下的「自動更新索引」：

除了配置的更新間隔，也可以在後臺自動更新所有索引。您可以通過兩個參數配置自動更新，更新時間間隔（以秒爲單位）以及在視圖引擎更新索引之前發生的文檔更改次數。這兩個參數是updateInterval和updateMinChanges：

updateInterval：以毫秒爲單位的時間間隔，默認爲5000毫秒。在每個updateInterval視圖引擎檢查磁盤上的文檔突變數量是否大於updateMinChanges。如果爲true，則觸發視圖更新。存儲在磁盤上的文檔可能會滯後數十秒鐘的文檔。
updateMinChanges：發生重新索引之前發生的文檔更改次數，默認值爲5000次更改。

2015-01-20 21:01:34 elwarren

回答