再見 MongoDB，你好 PostgreSQL
Olery 差不多成立于5年前。始于Ruby代理開發的單一產品(Olery Reputation)，隨著時間的推移，我們開始致力于一系列不同的產品和應用程序。當今，我們的產品不僅有(Olery) Reputation，還有Olery Feedback, Hotel Review Data API,widgets ，在不久的將來它可以嵌入到網站和更多產品/服務中。
我們增加了很多應用程序的數量。當今，我們部署了超過25個不同的應用程序(全為Ruby)，它們中的一些是web應用程序(Rails或者Sinatra)，但大多數的是后臺運行程序。
我們最引以為豪的是迄今為止我們所取得的成就，不過在這些成就的背后總閃現著一樣東西,即基礎數據庫。從Olery成立之日起，我們就安裝了數據庫，它用MySQL來存儲（用戶、合同等等）核心數據，用MongoDB來存儲評論及其類似的數據（即哪些在數據丟失的情況下很容易恢復的數據）。一開始，這樣的安裝運行的非常好，然而，隨著公司的成長，我們開始遇到了各種各樣的問題，尤其是MongoDB的問題居多。其中一些問題是由于應用與數據庫的交互方式而引起的，一些則是由數據庫本身而產生的。
例如，某個時刻，我們需要從MongoDB中刪除一百萬個文檔，以后再把這些數據重新插入到MongoDB里。這樣的處理方法使得整個數據庫幾乎要被鎖定數個小時，自然服務性能就會降低。而且直到對數據庫執行修復（即在MongoDB上執行repairDatabase命令）后才會解鎖。而且完成修復還要花費數個小時，修復所花的小時數要根據數據庫的大小來確定。
在另一實例中我們注意到我們的應用程序的性能降低和設法跟蹤到的 MongoDB 集群。然而，經過進一步檢查，我們無法找到問題的真正原因。無論我們怎么安裝，或使用什么工具敲了什么命令我們都找不到原因。直到我們更換了集群的初選，性能才恢復正常。
這只是兩個例子，我們已經有過許多這樣的情況。這個問題的核心是，這不只數據庫在運行，而且無論我們何時察看它都沒有絕對的跡象表明是什么原因導致的問題。
無模式的問題
另外，我們面對的核心問題是mongoDB的重要特征之一：模式的缺乏。模式的缺乏可能聽起來是有趣的，并且在一些情況下是有好處的。然而，對于許多無模式存儲引擎的用法，其導致了一些模式之間的內部問題。這些模式沒有通過你的存儲引擎定義而是通過你的應用的行為及其可能的需要而定義的。
例如：你可能有一頁存儲你的應用需要的字符串類型的title字段的集合。這兒這個模式是非常符合當前情形的，即使它沒有被明確的定義。但如果這個數據結果改變超時，尤其是如果原來的數據沒有被遷移到新的數據結構，這就成了問題（在一些無模式的存儲引擎上是相當有問題的）。例如，你可能有下面這樣的Ruby代碼：
post_slug = post.title.downcase.gsub(/\W+/, '-')
這樣，針對每一個有“title”字段并返回一個String的文檔，它都能正常工作。然而，對于那些使用不同字段名字（例如：post_title）或者根本沒有標題字段的文檔來說，它將不能正常工作。為了處理這種情況，你需要將代碼調整為下面內容：
if post.title post_slug = post.title.downcase.gsub(/\W+/, '-') else # ... end
另一種處理方法是，在你的模型中定義一個模式。例如 Mongoid，一個流行的針對Ruby的MongoDB ODM，就能讓你做到這一點。然而，當使用這些工具定義一個模式時，你可能會好奇為什么它們不在數據庫內定義該模式。實際上，這樣做可以解決另一個問題：可重用性。如果你只有一個應用程序，那么在代碼中定義模式并不是什么大問題。然而，如果你有許多應用程序的話，這將很快會成為一個大麻煩。
無模式存儲引擎希望通過刪除對模式的限制的方式，讓你的工作變得更簡單。但現實的情況是，確保數據一致性的責任推到了用戶自己的身上。有時候無模式引擎可以工作，但我打賭，更多的時候是事與愿違。
好數據庫的需求
Olery有了更多的特殊需求后，迫使我尋求一款更好的數據庫來解決問題。對于系統，特別是數據庫，我們非常注重以下幾點:
-
一致性
-
數據和系統行為的可視化
-
正確性和明確性
-
可拓展
一致性是重要的在于它有助于幫助我們對系統設定明確的期望。如果數據總是按照同樣的方式存儲，那么系統可以很方便的使用這些數據。如果在數據庫層面要求表的莫一列必須存在，那么在應用層面就不用檢查這列數據是否存在。數據庫即使實在高壓情況下，也必須保證每一次操作的完整性。沒有什么事情比單純的插入數據，過了幾分鐘后卻找不到數據的事更讓人沮喪了。
可見性包含了兩點：系統本身以及從中獲取數據的容易程度。如果一個系統出錯那么應該易于調試。反過來，用戶應很容易查到想要查詢的數據。
正確性是指系統的行為如我們所期望的那樣。如果某個字段定義為一個數值型，沒有人可以像其中插入文本。這方面MySQL是臭名昭著，一旦你這樣做你將得到偽結果。
可擴展性不僅針對性能而言，而且也涉及金融方面和系統能夠多么好地應對不斷變化的需求。一個系統在沒有大量資金成本或減緩系統所依賴的開發周期情況下，很難表現得非常好。
搬離MongoDB
上面的需求牢記于心后，我們就開始尋找一個取代MongoDB的數據庫。上面提到的特性通常是傳統RDBM特征的一組核心集，所以我們鎖定了兩個候選者：MySQL和PostgreSQL。
本來，MySQL是第一候選，因為我們的一些關鍵數據已經在使用它存儲。然而，MySQL也有一些問題。例如，當將一個字段定義為int(11)時，你卻可以輕松地向該字段插入文本數據，因為MySQL會試圖對它進行轉換。下面是一些例子：
mysql> create table example (numberint(11) not null ); Query OK, 0 rows affected (0.08 sec)mysql> insert into example (number) values (10); Query OK, 1 row affected (0.08 sec)
mysql> insert into example (number) values ('wat'); Query OK, 1 row affected, 1 warning (0.10 sec)
mysql> insert into example (number) values ('what is this 10 nonsense'); Query OK, 1 row affected, 1 warning (0.14 sec)
mysql> insert into example (number) values ('10 a'); Query OK, 1 row affected, 1 warning (0.09 sec)
mysql> select * from example; +--------+ | number | +--------+ | 10 | | 0 | | 0 | | 10 | +--------+ 4 rows in set (0.00 sec)</pre>
值得注意的是，MySQL在這些情況下會發出警告。但是，僅僅是警告而已，它們通常（若非總是）會被忽略。
此外，MySQL的另一個問題是，任何表的修改操作（例如：添加一列）都會導致表被鎖，此時將無法進行讀或寫操作。這就意味著，使用這種表的任何操作都不得不等待修改完成之后才能進行。對于包含有大量數據的表，這可能會花費幾個小時才能完成，很可能會導致應用程序宕機。這已經導致一些公司（例如SoundCloud）不得不自己開發工具（例如lhm）來解決該問題。
了解到上面的問題后，我們開始調查PostgreSQL。PostgreSQL可以解決很多MySQL不能解決的問題。例如，PostgreSQL中你不能將文本數據插入一個數字字段：
olery_development=# create table example ( number int not null ); CREATE TABLEolery_development=# insert into example (number) values (10); INSERT 0 1
olery_development=# insert into example (number) values ('wat'); ERROR: invalid input syntax for integer: "wat" LINE 1: insert into example (number) values ('wat'); ^ olery_development=# insert into example (number) values ('what is this 10 nonsense'); ERROR: invalid input syntax for integer: "what is this 10 nonsense" LINE 1: insert into example (number) values ('what is this 10 nonsen... ^ olery_development=# insert into example (number) values ('10 a'); ERROR: invalid input syntax for integer: "10 a" LINE 1: insert into example (number) values ('10 a');</pre>
PostgreSQL 還具有在許多方式中不需要每一個操作都上鎖就可以改寫表的能力。例如，添加一列沒有默認值卻可以設置為null的列并能夠快速完成無需鎖定整個表。
還有其他各種有趣的功能，如在 PostgreSQL 可以：trigram 為基礎的索引和檢索，全文檢索，支持JSON查詢，支持查詢/存儲鍵-值對，支持發布/訂閱等更多。
最重要的是PostgreSQL在性能，可靠性，正確性和一致性之間能夠權衡。
遷移到PostgreSQL
最后，為了在所關心的各種項目之中達到平衡，我們決定使用PostgreSQL。但是，將整個平臺從MongoDB遷移到一個截然不同的數據庫并不是很容易的事。為了使轉移工作簡單化，我們將此過程分成了3個步驟：
搭建一個PostgreSQL數據庫，并遷移數據的一個小子集。
更新所有依賴于MongoDB的應用程序，連同任何需要的重構，都用依賴于PostgreSQL的程序替代。
將產品數據遷移到新數據庫上，然后部署新平臺。
部分數據遷移
在考慮把所有數據遷移到新數據庫之前，我們先遷移了一小部分數據來做測試。如果僅僅是遷移一小部分數據，就有非常多的麻煩的話，那么數據庫遷移也就沒什么意義了。
盡管有現成的工具可以利用，但還是有些數據(比如，列重命名，數據類型不一致)要做轉換，對于這些數據我們自己開發了些工具。這些工具中，大部分都是Ruby寫的一次性腳步，用于刪除一些評論，整理數據編碼，修正主鍵發生序列等等。
在測試開始階段盡管有些數據上的問題，并沒有出現大的會阻礙遷移的問題。例如，有些用戶提交的數據沒有完全按格式編碼，導致這些數據被重新編碼之前，不能被導入到新數據庫。例外一個有意思的改變是，之前評論的數據存的是評論用的語言的名稱(如“荷蘭語”，“英語”等)，現在改了存語言的編碼，因為我們新的語義分析系統使用的是語言編碼，而不再是語言名稱。
更新應用
目前為止，花費時間最多的就是更新應用，尤其是那些嚴重依賴MongoDB聚合框架的應用。扔掉那少數幾個遺留的Rails應用吧，光是測試就會花掉你幾個星期的時間。更新應用的過程大致如下：
用PostgreSQL的相關代碼來替換掉MongoDB的驅動/設置模塊的代碼
運行測試
修復Bugs
反復運行測試，直到所有測試通過
對于非Rails應用，我們推薦使用 Sequel，對于Rails應用，我們現在還無法擺脫ActiveRecord（至少是現在）。Sequel是一個非常好的數據庫工具集，它支持絕大多數（如果不是全部）我們想使用的PostgreSQL特性。相較于ActiveRecord，它基于DSL的query要強大的多，盡管可能耗時會有點長。
舉個例子，假設你想計算有多少用戶使用某種語言，并計算每種語言所占的比例（相對于整個集合）。純粹的SQL查詢語句如下所示：
SELECT locale,count(*) AS amount, (count(*) / sum(count(*)) OVER ()) * 100.0 AS percentageFROM users GROUP BY localeORDER BY percentage DESC;在我們的例子中，將會產生以下輸出（當使用PostgreSQL命令行界面時）：
locale | amount | percentage --------+--------+-------------------------- en | 2779 | 85.193133047210300429000 nl | 386 | 11.833231146535867566000 it | 40 | 1.226241569589209074000 de | 25 | 0.766400980993255671000 ru | 17 | 0.521152667075413857000 | 7 | 0.214592274678111588000 fr | 4 | 0.122624156958920907000 ja | 1 | 0.030656039239730227000 ar-AE | 1 | 0.030656039239730227000 eng | 1 | 0.030656039239730227000 zh-CN | 1 | 0.030656039239730227000 (11 rows)Sequel允許你使用純Ruby編寫上面的查詢，而不需要字符串分段（ActiveRecord經常需要）：
star = Sequel.lit('*')User.select(:locale) .select_append { count(star).as(:amount) } .select_append { ((count(star) / sum(count(star)).over) * 100.0).as(:percentage) } .group(:locale) .order(Sequel.desc(:percentage))如果你不喜歡使用“Sequel.lit(“*”)”，你也可以使用下面的語法：
User.select(:locale) .select_append { count(users.*).as(:amount) } .select_append { ((count(users.*) / sum(count(users.*)).over) * 100.0).as(:percentage) } .group(:locale) .order(Sequel.desc(:percentage))雖然這可能有些冗長，但是上面的兩種查詢都使得它們更易于重用，而無需進行字符串連接。
未來可能也會將我們的Rails應用程序遷移到Sequel，但是考慮到Rails與ActiveRecord耦合得如此緊密，所以我們還不完全確定這是否值得花費時間和精力。
遷移生產數據
最終我們來到遷移生產數據的過程。一般有兩種方法來做這件事：
關掉整個平臺，直到所有數據都已遷移完成。
遷移數據的同時保持系統運行。
第一個選項具有一個明顯的缺點：停機時間。第二個選項不需要停機但是很難處理。例如，在這個方案中，當你遷移數據的同時，你必須要考慮所有將要添加的數據，否則你就會損失數據。
幸運的是，Olery有一個獨特的方案就是我們的數據庫的絕大多數寫操作都是相當定期的，經常變化的數據（例如用戶通訊錄信息）只占總數據量的一小部分，相比起我們檢查數據，遷移它們花費的時間相當的小。
該部分的基礎工作流是:
-
遷移諸如用戶、聯系人之類的關鍵數據，基本上所有我們無論如何都無法賠償損失的數據。
-
遷移不太重要的數據（如我們可以再抓取、再計算獲得的數據等）。
-
測試正常運行在一組獨立服務器的一切
-
切換產品環境到新的服務器。
再遷移步驟1的數據，確保在平均故障時間內創建數據不會丟失。
第2步是目前最耗時的，大約需要24小時。相反的是，步驟1和5中提到的數據遷移只需要45分鐘。
結論
我們遷移完成并且直到非常滿意大概過去了一個月。到現在為止除了那些積極的影響，還曾在各種情況中讓應用的性能大幅提高。舉例來說，我們的 酒店評論數據API（Hotel Review Data API）（在Sinatra運行）相比遷移之前交互延遲變低了許多：
遷移是在1月21日開始的，高峰表示應用性能的硬重啟（在處理期間導致交互時間輕微變慢）。在21日之后交互的平均時間大致是原來的一半。
在另外一種被我們稱作“評論持久化”（譯者注：即存儲評論）的過程中，我們發現了性能上巨大的提升。后臺程序目標很簡單：保存評論數據（評論內容，評論分數等等）。當我們最終完成了為遷移工作做的很多大的更改后，結果令人振奮：
抓取器也變的更快了：
抓取器性能提升沒有評論存儲的過程那樣大，因為抓取器只用數據庫來查詢某個評論是否存在（一個相對很快的操作），所以這樣的結果并不很令人吃驚。
最后來到程序里用來調度抓取過程的進程（簡單稱之為“調度器”）：
因為調度器只是以固定頻度運行，這個圖可能有點難以理解，但是不管怎樣，在遷移之后有一個很清晰的平均處理時間的下降。
最后，我們已經對現在的結果非常的滿意，而且我們肯定不會懷念MongoDB了。它的性能非常好，它的處理方案使其它數據庫相比之下黯然失色，并且查詢數據的過程與MongoDB相比實在太令人滿意了（尤其是對于non開發者而言）。盡管我們仍然還有一個服務（Olery Feedback)仍舊使用MongoDB（盡管這運行在一個獨立的，相對小的集群上），我們仍然打算將來把它移植到PostgreSQL上。
本文地址：http://www.oschina.net/translate/goodbye-mongodb-hello-postgresql
原文地址：http://developer.olery.com/blog/goodbye-mongodb-hello-postgresql/