棄用NoSQL數據庫 CouchDB再見了(2)

　　壓縮(Compaction)有時會沒有任何提示的終止，有時還不得不被刪除殘留的文件使其重新運行。 這在我們提高了磁盤容量報警上線之前導致了一些可怕的情況，因為我們發現這一點時，由于做壓縮，磁盤僅剩下非常小的空間。

　　在早期版本中，我們遇到了有關文件句柄使用的三、四個錯誤。 Bug reports快速修復了他們，并在1.0.2版本中更新了有關代碼。

　　性能：

　　真的還有一件事要在這里說，那個CouchDB的視圖查詢的性能問題，并沒有達到我們曾經期望的與MySQL索引查詢大致相等的性能級別。 這不是一個巨大的驚喜或者一個巨大的問題，但是哇塞(but wow)，現在很多事情更快了，我們的數據庫機器是負擔減少了許多。

　　維護問題：

　　當CouchDB出錯時，會使所有正在運行的查詢出錯。 其中包括復制和壓縮，所以我們需要腳本來檢查這些進程，并在必要時重新啟動它們。

　　視圖索引僅在查詢時才更新-插入操作不會更新索引。 這意味著你必須寫一個腳本來定期查看你的視圖，除非你想在一段時間無人問津時他們變的出奇的慢。 在實踐中，我們總是傾向于不通過插入操作更新索引來獲得提高性能的可能。但是寫一些可靠的腳本監控數據的索引是機警(tricky)的。

　　用于壓縮的簡單的復制收集器 可以花大量時間查看長期的文檔。當一個數據庫既有長期文件又有短期文件時這尤其是個壞消息：壓縮需要很長時間，但急需控制住磁盤使用率。 另外，你不得不自己運行壓縮和監測，以確保它的工作是有意義的。 壓縮應該是自動化和分代(generational)的。

　　未實現的諾言：

　　CouchDB的設計看起來對像自動分片等NoSQL的主要功能非常完美，但事實并不是這樣。

　　映射化簡(MapReduce)只能在一臺機器上運行有何意義? 我們原本以為這是為分布式查詢而設計的功能。

　　我們從來沒有清楚過CouchDB開發人員對其核心用途的考慮。 我們看到了發展的重點是集所有功能于一身的應用程序服務，然后是大規模多方向移動應用程序的復制。 兩個都是有趣的想法，但不是我們所需要的。

　　(我們被告知在最近發布的CouchDB 1.2，這些問題已經解決。)

　　我們能夠有效發揮CouchDB的性能，并隨著時間的推移，我們了解到各種的維修問題的腳本方式。 但我們擔心CouchDB好像被和我們不同的用法所吸引著，這是最終最終迫使我們做數據庫轉換的導火索。 我們談到了一些可能的選擇，和最終的一個典型解決方案。

　　MySQL，原始的NoSQL數據庫

　　那么，為什么不能切換到另一個像MongoDB面向文檔的數據庫或其他NoSQL數據庫呢? 我們曾經對MongoDB非常感興趣，但在做一些研究和聽到褒貶不一的評論后 ，我們得出結論：同CouchDB一樣，它也有很多相同的問題使我們的工作受到影響。其他NoSQL數據庫往往一樣不同的，像CouchDB與MySQL之間一樣區別很大。

　　) -因此很難選擇 -而且對我們還有很多不熟悉的事情。 鑒于對MySQL的經驗，我們知道這它能足夠滿足我們的需求，很難證明其他的選擇同樣適合。

　　我們很熟悉MySQL的缺點：別的咱不說，光它的配置就很麻煩(提示：優化性能中最重要的設置是innodb_buffer_pool_size)，存儲引擎的選擇，以及除了面向SQl,分析執行查詢SQL語句的時間花費。經驗豐富的MySQL用戶期望寫出很多強制索引子句。

　　另一方面，InnoDB存儲引擎整體來看還是非常強大的。在過去十年中，它已經在一些最大的互聯網公司大量使用，而且變得越來越強壯。幾乎所有的數據庫在底層是都建立在相同的基本B-樹算法、散列和類似InnoDB存儲引擎的緩存。在尊重基本原理的前提下，任何新的數據庫管理系統對在真實環境性能和和靠性的突破都是非常艱難的。 但也許未必一定這樣：Percona的前瞻性思維的鍵/值接口是一個可靠的InnoDB存儲引擎如何成為真正的NoSQL架構的很好的例子。

　　剛換到MySQL數據庫時，我們對它還像原始存儲引擎一樣?，F在我們將使用MySQL，開發出之前NoSQL全部功能的方法。

　　我們設法將CouchDB的模型層(model layer)移植到MySQL中且對代碼庫的影響最小。對 大多數使用模型的代碼(model-using code)，使用MySQL看起來和使用CouchDB的完全一樣。 除了它的速度更快，而且這樣的數據庫從未出錯。

　　我們不使用外鍵，或者多語句事務，到目前為止也未使用join。 一旦我們需時，我們已經準備好橫向擴展(horizontally scale)。 (不過，這將需要一段時間!自從分片被發明的時期過后，硬件已經發展的更加強大，而且那些日子你可以僅靠單一的寫主庫運行很長的時間。)

　　我們的所有表都含有一個TEXT的字段用以存儲JSON，我們的模型層為了大多數需求而悄悄將對待他們像真正的列一樣。這個主意就像Rails 的ActiveRecord ::商店 。雖不是和MySQL的功能設置非常完美融合， MySQL不能真正操作這些JSON列 - 但它仍然是一個偉大的想法，讓我們向無模式數據庫更加緊密。

　　這是一個已證明的可靠的數據庫存儲引擎和給我們很多NoSQL數據庫優點的架構的組合， 這種設置工作過去一兩個月了，我們發現它非常難于達到最好的兩個世界的途徑。

原文轉自：http://blogread.cn/it/article/5356