NoSQL、CouchDB 與 CouchBase，我該怎麼辦？
我開始在我的生產站點上遇到一些問題，當有一個網頁需要載入一個非常大的 ResultSet（目前來自關係數據庫，MySQL）時，它需要很長時間，而且這些結果集只會越來越大。
我開始尋求更好的解決方案，我想到的是將數據保存在 NoSQL 數據庫中的想法。（我已經在使用 Mongo，但由於我的環境中有大量 DML，Mongo 效率低下。）所以在搜尋網路時，我想到了以下 2 個選項：
- 沙發數據庫
- 沙發底座
當查看以上兩個時，我可以說兩者都是基於 JSON 文件的（好的，這是一個好的開始），但是當進入一些技術背景時，我確實在尋找更好的記憶體（我不想殺我的伺服器的 I/O）然後是 MongoDB 的主-主複製能力（我看到 CouchDB 可以基於源->目標/目標->源輕鬆複製）。
有人可以提供一些您的意見嗎？如果您嘗試了上述解決方案，我將很高興聽到您的經驗。
IMO 在涉及網頁時，您可能犯了一個非常常見的錯誤，即假設由於 MySQL 的初始結果大小而導致的性能問題的答案是跳轉到 NoSQL 解決方案，通常很少了解權衡是什麼或如何正確有效地使用它們。
如果一個經過良好調整的數據庫實際上是一個 Web 應用程序的問題，如果結果集的大小是問題所在，我會感到驚訝。一個簡單的事實是，結果集只能從磁碟中快速檢索（假設您沒有使用主記憶體數據庫，其中所有內容都強制在 RAM 中），然後您實際上必須花時間處理結果集以獲取您的網頁。在假設它是數據庫之前，您需要先全面分析所有內容。
您在 NoSQL 中最基本的權衡是數據輸入的靈活性和易於擴展與完整性保證和輸出數據處理。在 NoSQL 中對任何大小的結果集進行數據處理的唯一方法基本上是在輸入上進行，如果以犧牲傳統 RDBMS 為代價使用 NoSQL 解決方案，這將對產品的生命週期產生重大影響。另一方面，這些提供 RDBMS 的附件是否合適，這對預處理和後處理都有幫助。簡而言之，選擇 NoSQL 是有理由的，但大小確實不是其中之一。
現在，您在這裡提到這是一個正在載入“非常大的結果集”的“網頁”。現在，我有時會對網路應用程序做一些瘋狂的事情，我懷疑如果你真的將一個非常大的結果集直接載入到網頁中，那麼除了數據庫性能之外你還有很多問題。
例如，在 LedgerSMB 中，我知道我們會提取一千多個發票行來為某些使用者生成單個網頁（我們使用 PostgreSQL）。對我們來說，PostgreSQL 執行得非常好，即使在聚合從數百萬條記錄表中提取的數千條記錄時也是如此。我們在該級別上花費（分析）每個頁面載入的時間大約是 15 秒的 db 時間到最多 5 分鐘的 Web 應用程序時間來生成網頁。（這是可以接受的，因為它確實為該客戶全域優化了工作流程，請記住，網頁可能有多達 20k 個輸入元素，並且數據必須在 db 伺服器發送數據的位置和網頁已建立）。這可能與您的案例不完全匹配，但它可能讓您了解數據庫沒有
如果 db 實際上是問題所在，以下是故障排除的一些方面和您擁有的選項。
- 分析您的整個應用程序。實際花費了多少時間在 db 上？處理顯示頁面花費了多少？
- 分析您的數據庫查詢。可以做些什麼來提高他們的效率？
在斷定不同的數據庫將解決您的問題之前執行此操作。
現在，如果事實證明你真的把它推到了最大，那麼你需要看看你的選擇。這些包括：
- PostgreSQL（是的，一個關係數據庫）。這樣做的一件事是更普遍優化的表/索引結構（InnoDB 專門從事 pkey 查找，這意味著其他搜尋速度較慢）。
- VoltDB（另一個關係數據庫，但這個是高速 oltp 的主記憶體，速度非常快）
- 您可以使用與您的 rdbms 一起工作的 NoSQL 數據庫建構記憶體層。這是您可以使用 MongoDB 或 CouchDB 的地方。