每個桶的最大couchbase視圖數

Question

假設桶中有大量數據（> 100GB，> 100M個文檔，> 12個文檔類型），並且假設每個視圖僅適用於一個視圖文件類型？或者以另一種方式問，在什麼時候應該將某些文檔類型拆分爲單獨的存儲區以節省處理所有文檔類型的所有視圖的開銷？

我很難決定如何將數據拆分成couchbase存儲桶，以及數據所需視圖的性能影響。我的數據由十幾個關係數據庫組成，其中至少有一半與數個表中的數億行相關聯。

的http://www.couchbase.com/docs/couchbase-manual-2.0/couchbase-views-writing-bestpractice.html文檔節「使用的文件類型」似乎暗示在同一個桶有多種文檔類型並不理想，因爲在特定的文件類型視圖的所有文件更新，即使是那些永遠比不上視圖。實際上，它建議將數據分成桶以避免這種開銷。

然而，由於性能原因，每個羣集有10個桶限制。因此，我唯一的結論是每個羣集可以有效地處理最多10個大型文檔集合。這是否準確？

Answer 1

拖輪的建議是正確的，並允許我增加一些觀點。

一個桶可以被認爲與RDMS世界中的「數據庫實例化」關係最密切（但並非完全）。在「數據庫」中將會有多個表/模式，並且這些都可以在一個桶中進行組合。

將存儲桶視爲所有共享一些常用配置參數（RAM配額，副本計數等）的數據的邏輯分組，並且只需要在需要控制某些數據集時將數據拆分爲多個存儲桶分別。其他原因與不同數據集的工作負載差異很大，或者需要分別跟蹤這些數據集的工作負載。

一些例子：

-I想控制緩存行爲的一組不同於其它數據。例如，許多客戶有一個「會話」存儲桶，他們總是想要RAM，而他們可能有一個更大的「用戶配置文件」存儲桶，它不需要RAM中緩存的所有數據。從技術上講，這兩個數據集可以駐留在一個存儲桶中，並允許Couchbase智能地將哪些數據保存在RAM中，但是您沒有太多保證或控制會話數據不會被推出......所以，它在自己的存儲桶中允許您執行該操作。它還使您能夠分別監控該流量的額外好處。

- 我想要一些數據被複制的次數比別人多。儘管我們通常在大多數羣集中只推薦一個副本，但有時我們的用戶會選擇某些他們想要額外複製的數據集。這可以通過單獨的桶進行控制。

- 同樣的問題，我只想將一些數據複製到另一個集羣/數據中心。這也是按照每個桶進行控制的，因此可以將數據拆分到單獨的存儲桶中。

- 當您在給定數據集的工作負載差異很大時（特別是在寫入數量上）差異很大時，從視圖/索引的角度來看，它確實有意義將數據分離到單獨的存儲桶中。我提到這是因爲這是真的，但我也想清楚，這不是常見的情況。在識別問題之後，您應該使用這種方法，而不是之前，因爲您認爲可能。

關於這最後一點，是的，每次寫入桶都會被索引引擎拾取，但通過使用JSON中的文檔類型，您可以非常快速地中止給定文檔的處理，而且它實際上不應該有對大量數據產生不利影響並不適用於某些觀點。如果你不介意的話，我特別好奇這些文檔的哪些部分是暗含的，因爲那肯定不是我們的意圖。

因此，一般來說，我們看到大多數部署的桶數很少（2-3），只有少數幾個5以上。我們的10個限制來自我們內部統計數據跟蹤的一些已知的CPU和磁盤IO開銷（負載或在桶中缺少這個無關緊要）。我們當然打算在未來的版本中減少這種開銷，但這仍然不會改變我們建議只有幾個桶的建議。無論如何，能夠將多個「模式」組合到單個邏輯分組中並應用視圖/索引的優勢仍然存在。

我們現在正在制定更具體的指導方針和尺寸建議（我寫這兩個博客作爲一個臨時差距，直到我們這樣做）。

作爲一種初始方法，您希望嘗試將設計文檔的數量保持在4左右，因爲默認情況下，我們最多並行處理4個。您可以增加此數字，但應該通過增加的CPU和磁盤IO容量來匹配。然後，您將希望保持每個文檔中的視圖數量相對較低，可能遠低於10，因爲它們都是以串行方式處理的。

我最近和一個擁有相當大的瀏覽量的用戶一起工作（大約有8個設計文檔和一些有近20個瀏覽量的dd），我們能夠通過將多個視圖組合成一個視圖來大幅降低這個問題。很明顯，這是非常依賴於應用程序的，但您應該嘗試從一個索引中生成多個不同的「查詢」。使用縮減，關鍵字前綴（視圖內）和排序規則，結合不同的範圍和分組查詢可以使單個索引開始擁擠，但實際上非常靈活。

您擁有的設計文檔和視圖越少，所需的磁盤空間，IO和CPU資源就越少。不幸的是，永遠不會有一個神奇的彈頭或難以對付的指引數字。最後，YMMV和測試您自己的數據集比我可以編寫的任何多頁響應更好;-)

希望有所幫助，請不要猶豫直接聯繫我們，如果您有特定的問題您不希望發佈的具體用例。

佩裏

Answer 2

正如您從Couchbase文檔中看到的那樣，提供一個「通用」規則並不能真正爲您提供準確的成員。

但基於您使用過的最佳實踐文檔和一些討論（這裏），您應該能夠正確地設計您的數據庫/視圖。

讓我們先從最後一個問題：

YES之所以Couchbase建議有鬥少數是性能 - 更重要的是資源消耗 - 原因。我想請你去閱讀這些博客文章，以幫助理解發生了什麼 「內部」 Couchbase：

• 選型1：http://blog.couchbase.com/how-many-nodes-part-1-introduction-sizing-couchbase-server-20-cluster
• 選型2：http://blog.couchbase.com/how-many-nodes-part-2-sizing-couchbase-server-20-cluster
• 壓實：http://blog.couchbase.com/compaction-magic-couchbase-server-20

所以你會看到大部分的「操作」都是由桶完成的。

現在讓我們來看看原題：

• 是大部分的時間你會按類型的文件組織設計文件/和看法。
• 在單個（少數）桶中擁有所有文檔「類型」並不是問題，這實際上是您使用Couchbase的方式的一種方式最重要的部分是查看文檔的大小（看看「long」將如何解析JSON）以及文檔將被創建/更新和刪除的頻率，因爲視圖的JS代碼僅在您創建/更改文檔時執行。

所以，你應該做的：

• 1單鬥
• 多少設計文件？ （你有幾種類型？）
• 你將在每個文件中有任何視圖？

其實最昂貴的部分索引過程中是不是還是quering它是當你不得不重新平衡數據越來越節點（添加，刪除節點的故障）之間的指數

最後，但它看起來你已經知道了，本章很好理解視圖是如何工作的（如何創建和使用索引）： http://www.couchbase.com/docs/couchbase-manual-2.0/couchbase-views-operation.html

如果需要，請隨時添加更多信息。