棄用NoSQL數據庫 CouchDB再見了

　　【導讀】

　　2012年5月10日，Sauce Labs公司的首席架構師Steven Hazel，寫了一篇關于棄用NoSQL數據庫CouchDB產品，介紹他們將Couch數據庫的數據遷移到MySQL數據庫平臺中。

　　在Sauce Lab(醬油實驗室)里，我們剛剛慶祝完成一個重大項目—將最后的CouchDB數據庫轉變為MySQL數據庫，以提高服務正常運行時間和可靠性。 由于大部分無故停機的是由于CouchDB數據庫宕機引起的，因此完成這種遷移是我們一個重要的里程碑。

　　CouchDB數據庫開始時，是一個非常寶貴的經驗，在1.2版本時它的可靠性還是可以的。 但我們的服務對可靠性要求非常高，于是最終決定：這種轉變是前進中最有效的方式。

　　一旦決使用MySQL(具體而言，是Percona的基于InnoDB存儲引擎的XtraDB存儲引擎，)，我們就重構了數據庫抽象層，并遷移了所有各種類型的數據庫。 在過去幾個月，遷移完成后，我們的服務正常運行時間大大提高了。

　　這篇文章介紹了我們使用CouchDB數據庫的經驗，以及在哪里遇到了麻煩。我也談了這方面的經驗，如何影響了我們對NoSQL數據庫的整體觀點，以及在熟悉了NoSQL數據庫后，如何積極權衡對MySQL數據庫的安裝配置。

　　首先，我們是如何陷入困境?

　　所有的事情都在變的偉大。

　　自2008年開始我們第一次啟動Sauce Lab，我們認為我們正在建立與當今運行的服務非常不同的東西。我們高興地嘗試NoSQL數據庫，使用MySQL關系數據庫的設計者多年來從來沒有想過的方式。CouchDB的似乎很適合我們的需要。

　　我們原來的產品為客戶的利益著想而設計了一個有特色的用于存儲數據的REST API，該計劃徹底廢棄了曾有的CouchDB的RESTful API。 這讓我們得到了一個原型并匆忙的運行。 CouchDB是新鮮事物且尚未有過什么實際使用，但這并不重要，因為我們數據庫I / O需求很少，應用程序自然具有水平擴展性，且產品是容錯的。只要保持復制正常且在出錯時重試就可以很容易地彌補穩定性的鴻溝。這樣難道會出問題嗎?

　　可能出錯的地方

　　隨著這家小公司的成長，我們逐漸了解到客戶所面臨的問題，我們的產品也經歷了幾個重大變化.隨著時間的推移嚴格按照用戶對數據進行分區意義不大。我們變得越來越依靠數據庫的I/O性能。通常，我們覺得自己使用CouchDB與最初設想非常不同，更與大多數web應用程序使用數據庫的方式不同。雖然這仍是一種合理的使用方式，但我們曾經相信的附加安全性正隨著產品的升級而慢慢消失，而那恰恰是我們所需要的。

　　Sauce Lab比一般web應用程序對可靠性要求更高。 如果我們對一個單一請求處理失敗，就代表了對一個客戶檢驗的失敗，并影響他們的整個架構。 隨著時間的推移，CouchDB數據庫的可靠性越來越糟糕。 我們不停的更換硬件設備，改變使用CouchDB數據庫的方式。 我們改變了軟件架構，使其對數據庫和數據庫I / O操作減少。不過， 最后我們決定，最好的方法還是更換數據庫產品。

　　到此為止我都沒有講CouchDB的具體缺點， 這是一個年輕的數據庫，可靠性和性能問題是可以預期的。 因為我們對傳統的關系型數據庫沒有偏愛，但在某種程度上，CouchDB數據庫還是太糟糕了。 我們深信，NoSQL數據庫是未來。 只是我們不相信NoSQL數據庫是現在。

　　我們真心喜歡CouchDB數據庫的一些事

　　無模式。 這是美妙的 。，模式甚至有何用? 他們只是毫無理由的把事情變復雜。 有時你需要對數據增加約束，數據庫模式改變非常難。 然后CouchDB數據庫對文檔，增加新的字段非常簡單。

　　非關系型。 關系型數據庫發展出解決問題的原則是：數據的完整性是至關重要的，而可用性則無關緊要。 在很多在現代Web應用程序數據庫層中毫無意義的功能。有6種連接方式的事務查詢起初是很吸引人的，但是當你需要擴展(scale)時就會令你陷入困境。從一開始阻止這些發生通常是很容易的。

　　No SQL。 這是2012年，大多數查詢從代碼運行，而不是由坐在控制臺的人類。為什么我們仍在用非常接近奇怪的COBOL語言構建的代碼查詢我們的數據庫呢?且這些被組建的代碼不得不在每一次查詢時重新解析。像SQL注入攻擊這樣的東西根本不應該存在。 他們是將你的數據庫API看作編程語言而不是一個協議的后果，它是這個自20世紀70年代起經深思熟慮設計的漏洞的核心;

　　HTTP API。 無論在任何地方，只要符合HTTP(或者run curl)協議，就可以方便的查詢數據庫;

　　始終一致性，只追加文件格式。 這樣做數據庫備份僅作文件復制，簡單且無后顧之憂;

　　JavaScript是作為一個視圖/查詢語言，被人熟知且廣泛使用;

　　任意計算出的值上的索引似乎是一個有巨大潛能的功能。 我們從來沒有找到一個真正智慧的方式使用它們，雖然它只是簡單的通過電子郵件的域名做用戶索引。

　　最后值得指出，即使在挑戰其查詢和維護索引能力的壓力之下，CouchDB數據庫從未丟失任何數據。

　　使用CouchDB時我們遇到的問題

　　可用性：

　　在我們最初的設置中，磁盤緩慢的性能使CouchDB正在運行的查詢周期性的失敗。 后來用更快的RAID配置后性能會有所改善，但隨著負荷的增加，問題回來了。 相比而言，Percona在這一負荷水平完全勝任：mysqld使用CPU資源非常少，幾乎沒有任何慢查詢，cache使用效率足夠高以至于幾乎沒有磁盤讀寫，在RAID 10下我們的寫負載是一個非常舒適的小百分比。

　　視圖有時會丟失索引，而且在正常工作前還有幾次重加索引失敗的情況。 偶爾他們會進入一種無休止重加索引的狀態，直到我們徹底刪除視圖文件并重新啟動CouchDB。 而對此我們非常痛苦。 最后一件事重新編制索引的驚喜是，我們作為一個小團隊已經采取一個巨大的任務列表和戰斗力，以打動潛在的大客戶的需要。Surprise reindexing exercises were the last thing we needed as a small team already taking on a giant task list and fighting to impress potential big customers.

　　損壞的視圖(Views)有時會阻止所有工作的視圖，直到這個視圖文件已被刪除，在這個時候，視圖索引消耗時間做重啟和一些不可靠的工作。 不知道多少次我們中的一員在凌晨4點被監控系統喚醒，因為數據庫未經許可因突然變成一個簡單的鍵/值存儲而當掉。

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