可擴展的 CouchDB 設置
我想遷移一個現有的應用程序，它大約有。1000 萬條記錄儲存在 CouchDB 的關係數據庫中。我喜歡 CouchDB 的一點是易於複製和快速記憶體視圖。我不喜歡的是寫入和查看創建速度對於 1000 萬個文件來說會非常慢。
我必須解決這些潛在瓶頸的一個想法是擁有三個 CouchDB 實例：
- 只寫實例：這是主實例。我們的單點真理。這裡只允許更新、插入和刪除。此實例沒有讀取和視圖。
- View creation only instance：僅用於創建和記憶體視圖。此實例上沒有讀取或寫入。
- 只讀實例：通過複製視圖進行讀取訪問。
實例 2 從實例 1 複製而來。由於不會有任何應用程序使用實例 2，因此可以在不影響生產應用程序的情況下創建新視圖。
實例 3 從包含所有記憶體視圖的實例 2 複製而來。
這是一個可行的解決方案嗎？
我相當確定 CouchDB 不會複製視圖記憶體（畢竟它們是記憶體），所以你必須複製那些帶外的（這有點錯過了，IMO）。
CouchDB 可能不適合寫入繁重的負載。如果您的負載畢竟是讀取繁重的，我想您可以在每次插入/更新後呼叫視圖，以便視圖始終完全支持記憶體。
免責聲明：我在幾個站點中使用 CouchDB，但遠不及您所說的大小。
我從未執行過 CouchDB，只是對其進行了研究，所以不要在沒有驗證的情況下將我的建議視為真實……
首先，我強烈推薦閱讀 John P. Wood 的系列文章，了解他在生產環境中使用 CouchDB 的經驗：http: //johnpwood.net/2009/06/15/couchdb-a-case-study/
接下來，當您說實例時，它是具有單個 CouchDB 實例的物理伺服器嗎？如果我們只談論 3 台伺服器，我認為通過分配不同的角色來分割容量並不是最優的。我的直覺是保持所有 3 台伺服器相同並載入完整的數據集，以允許並行讀取查詢……？
如果只有 3 台伺服器，我會考慮傳統的 RDBMS 和傳統的複制設置。我懷疑 CouchDB 是否會以相對較少的計算能力為您帶來如此大的改變？
另一件事，好好看看 HBase，它建立在 Hadoop 之上。Hadoop 框架現在得到了很好的企業贊助，雅虎和 Facebook 都是大使用者。鑑於此，HBase 可能會比某些競爭對手發展得更快並且經過更好的測試。
高溫高壓