軟件公司為何要放棄MongoDB？
Olery成立于2010年，總部位于阿姆斯特丹。該初創(chuàng)公司為酒店行業(yè)提供聲譽(yù)管理與媒體監(jiān)控工具，幫助酒店將網(wǎng)絡(luò)評論和社交媒體反饋轉(zhuǎn)化成可執(zhí)行的商業(yè)智能分析。
Olery成立最初是使用MySQL來存儲(chǔ)(用戶、合同等等)核心數(shù)據(jù)，用MongoDB來存儲(chǔ)評論及其類似的數(shù)據(jù)(即哪些在數(shù)據(jù)丟失的情況下很容易恢復(fù)的數(shù)據(jù))。一開始，這樣的安裝運(yùn)行的非常好，然而，隨著公司的成長，開始遇到了各種各樣的問題，尤其是MongoDB的問題居多。其中一些問題是由于應(yīng)用與數(shù)據(jù)庫的交互方式而引起的，一些則是由數(shù)據(jù)庫本身而產(chǎn)生的。
例如，某個(gè)時(shí)刻，Olery需要從MongoDB中刪除一百萬個(gè)文檔，以后再把這些數(shù)據(jù)重新插入到MongoDB里。這樣的處理方法使得整個(gè)數(shù)據(jù)庫幾乎要被鎖定數(shù)個(gè)小時(shí)，自然服務(wù)性能就會(huì)降低。而且直到對數(shù)據(jù)庫執(zhí)行修復(fù)(即在 MongoDB上執(zhí)行repairDatabase命令)后才會(huì)解鎖。而且完成修復(fù)還要花費(fèi)數(shù)個(gè)小時(shí)，修復(fù)所花的小時(shí)數(shù)要根據(jù)數(shù)據(jù)庫的大小來確定。
在另一實(shí)例中Olery注意到應(yīng)用程序的性能降低和設(shè)法跟蹤到的 MongoDB 集群。然而，經(jīng)過進(jìn)一步檢查，無法找到問題的真正原因。無論怎么安裝，或使用什么工具敲了什么命令都找不到原因。直到Olery更換了集群的初選，性能才恢復(fù)正常。
這只是兩個(gè)例子，Olery已經(jīng)有過許多這樣的情況。這個(gè)問題的核心是，這不只數(shù)據(jù)庫在運(yùn)行，而且無論何時(shí)察看它都沒有絕對的跡象表明是什么原因?qū)е碌膯栴}。
無模式的問題
另外，Olery面對的核心問題是mongoDB的重要特征之一：模式的缺乏。模式的缺乏可能聽起來是有趣的，并且在一些情況下是有好處的。然而，對于許多無模式存儲(chǔ)引擎的用法，其導(dǎo)致了一些模式之間的內(nèi)部問題。這些模式?jīng)]有通過存儲(chǔ)引擎定義而是通過應(yīng)用的行為及其可能的需要而定義的。
例如：你可能有一頁存儲(chǔ)你的應(yīng)用需要的字符串類型的title字段的集合。這兒這個(gè)模式是非常符合當(dāng)前情形的，即使它沒有被明確的定義。但如果這個(gè)數(shù)據(jù)結(jié)果改變超時(shí)，尤其是如果原來的數(shù)據(jù)沒有被遷移到新的數(shù)據(jù)結(jié)構(gòu)，這就成了問題(在一些無模式的存儲(chǔ)引擎上是相當(dāng)有問題的)。例如，你可能有下面這樣的 Ruby代碼：
- post_slug = post.title.downcase.gsub(/\W+/, '-')
這樣，針對每一個(gè)有“title”字段并返回一個(gè)String的文檔，它都能正常工作。然而，對于那些使用不同字段名字(例如：post_title)或者根本沒有標(biāo)題字段的文檔來說，它將不能正常工作。為了處理這種情況，你需要將代碼調(diào)整為下面內(nèi)容：
- if post.title
- post_slug = post.title.downcase.gsub(/\W+/, '-')
- else
- # ...
- end
另一種處理方法是，在你的模型中定義一個(gè)模式。例如 Mongoid，一個(gè)流行的針對Ruby的MongoDB ODM，就能讓你做到這一點(diǎn)。然而，當(dāng)使用這些工具定義一個(gè)模式時(shí)，你可能會(huì)好奇為什么它們不在數(shù)據(jù)庫內(nèi)定義該模式。實(shí)際上，這樣做可以解決另一個(gè)問題：可重用性。如果你只有一個(gè)應(yīng)用程序，那么在代碼中定義模式并不是什么大問題。然而，如果你有許多應(yīng)用程序的話，這將很快會(huì)成為一個(gè)大麻煩。
無模式存儲(chǔ)引擎希望通過刪除對模式的限制的方式，讓你的工作變得更簡單。但現(xiàn)實(shí)的情況是，確保數(shù)據(jù)一致性的責(zé)任推到了用戶自己的身上。有時(shí)候無模式引擎可以工作，但我打賭，更多的時(shí)候是事與愿違。
好數(shù)據(jù)庫的需求
有了更多的特殊需求后，迫使Olery尋求一款更好的數(shù)據(jù)庫來解決問題。對于系統(tǒng)，特別是數(shù)據(jù)庫，Olery非常注重以下幾點(diǎn):
- 一致性
- 數(shù)據(jù)和系統(tǒng)行為的可視化
- 正確性和明確性
- 可拓展
一致性是重要的在于它有助于幫助Olery對系統(tǒng)設(shè)定明確的期望。如果數(shù)據(jù)總是按照同樣的方式存儲(chǔ)，那么系統(tǒng)可以很方便的使用這些數(shù)據(jù)。如果在數(shù)據(jù)庫層面要求表的莫一列必須存在，那么在應(yīng)用層面就不用檢查這列數(shù)據(jù)是否存在。數(shù)據(jù)庫即使實(shí)在高壓情況下，也必須保證每一次操作的完整性。沒有什么事情比單純的插入數(shù)據(jù)，過了幾分鐘后卻找不到數(shù)據(jù)的事更讓人沮喪了。
可見性包含了兩點(diǎn)：系統(tǒng)本身以及從中獲取數(shù)據(jù)的容易程度。如果一個(gè)系統(tǒng)出錯(cuò)那么應(yīng)該易于調(diào)試。反過來，用戶應(yīng)很容易查到想要查詢的數(shù)據(jù)。
正確性是指系統(tǒng)的行為如Olery所期望的那樣。如果某個(gè)字段定義為一個(gè)數(shù)值型，沒有人可以像其中插入文本。這方面MySQL是臭名昭著，一旦你這樣做你將得到偽結(jié)果。
可擴(kuò)展性不僅針對性能而言，而且也涉及財(cái)務(wù)方面和系統(tǒng)能夠多么好地應(yīng)對不斷變化的需求。一個(gè)系統(tǒng)在沒有大量資金成本或減緩系統(tǒng)所依賴的開發(fā)周期情況下，很難表現(xiàn)得非常好。
#p#
放棄MongoDB
上面的需求牢記于心后，Olery就開始尋找一個(gè)取代MongoDB的數(shù)據(jù)庫。上面提到的特性通常是傳統(tǒng)RDBM特征的一組核心集，所以O(shè)lery鎖定了兩個(gè)候選者：MySQL和PostgreSQL。
本來，MySQL是第一候選，因?yàn)镺lery的一些關(guān)鍵數(shù)據(jù)已經(jīng)在使用它存儲(chǔ)。然而，MySQL也有一些問題。例如，當(dāng)將一個(gè)字段定義為int(11)時(shí)，你卻可以輕松地向該字段插入文本數(shù)據(jù)，因?yàn)镸ySQL會(huì)試圖對它進(jìn)行轉(zhuǎn)換。下面是一些例子：
- mysql> create table example ( `number` int(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)
值得注意的是，MySQL在這些情況下會(huì)發(fā)出警告。但是，僅僅是警告而已，它們通常(若非總是)會(huì)被忽略。
此外，MySQL的另一個(gè)問題是，任何表的修改操作(例如：添加一列)都會(huì)導(dǎo)致表被鎖，此時(shí)將無法進(jìn)行讀或?qū)懖僮?。這就意味著，使用這種表的任何操作都不得不等待修改完成之后才能進(jìn)行。對于包含有大量數(shù)據(jù)的表，這可能會(huì)花費(fèi)幾個(gè)小時(shí)才能完成，很可能會(huì)導(dǎo)致應(yīng)用程序宕機(jī)。這已經(jīng)導(dǎo)致一些公司(例如 SoundCloud)不得不自己開發(fā)工具(例如lhm)來解決該問題。
了解到上面的問題后，Olery開始考察PostgreSQL。PostgreSQL可以解決很多MySQL不能解決的問題。例如，PostgreSQL中你不能將文本數(shù)據(jù)插入一個(gè)數(shù)字字段：
- olery_development=# create table example ( number int not null );
- CREATE TABLE
- olery_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');
PostgreSQL 還具有在許多方式中不需要每一個(gè)操作都上鎖就可以改寫表的能力。例如，添加一列沒有默認(rèn)值卻可以設(shè)置為null的列并能夠快速完成無需鎖定整個(gè)表。
還有其他各種有趣的功能，如在 PostgreSQL 可以：trigram 為基礎(chǔ)的索引和檢索，全文檢索，支持JSON查詢，支持查詢/存儲(chǔ)鍵-值對，支持發(fā)布/訂閱等更多。
最重要的是PostgreSQL在性能，可靠性，正確性和一致性之間能夠權(quán)衡。
#p#
遷移到PostgreSQL
最后，為了在所關(guān)心的各種項(xiàng)目之中達(dá)到平衡，Olery決定使用PostgreSQL。但是，將整個(gè)平臺(tái)從MongoDB遷移到一個(gè)截然不同的數(shù)據(jù)庫并不是很容易的事。為了使轉(zhuǎn)移工作簡單化，Olery將此過程分成了3個(gè)步驟：
- 搭建一個(gè)PostgreSQL數(shù)據(jù)庫，并遷移數(shù)據(jù)的一個(gè)小子集。
- 更新所有依賴于MongoDB的應(yīng)用程序，連同任何需要的重構(gòu)，都用依賴于PostgreSQL的程序替代。
- 將產(chǎn)品數(shù)據(jù)遷移到新數(shù)據(jù)庫上，然后部署新平臺(tái)。
部分?jǐn)?shù)據(jù)遷移
在考慮把所有數(shù)據(jù)遷移到新數(shù)據(jù)庫之前，Olery先遷移了一小部分?jǐn)?shù)據(jù)來做測試。如果僅僅是遷移一小部分?jǐn)?shù)據(jù)，就有非常多的麻煩的話，那么數(shù)據(jù)庫遷移也就沒什么意義了。
盡管有現(xiàn)成的工具可以利用，但還是有些數(shù)據(jù)(比如，列重命名，數(shù)據(jù)類型不一致)要做轉(zhuǎn)換，對于這些數(shù)據(jù)Olery自己開發(fā)了些工具。這些工具中，大部分都是Ruby寫的一次性腳步，用于刪除一些評論，整理數(shù)據(jù)編碼，修正主鍵發(fā)生序列等等。
在測試開始階段盡管有些數(shù)據(jù)上的問題，并沒有出現(xiàn)大的會(huì)阻礙遷移的問題。例如，有些用戶提交的數(shù)據(jù)沒有完全按格式編碼，導(dǎo)致這些數(shù)據(jù)被重新編碼之前，不能被導(dǎo)入到新數(shù)據(jù)庫。例外一個(gè)有意思的改變是，之前評論的數(shù)據(jù)存的是評論用的語言的名稱(如“荷蘭語”，“英語”等)，現(xiàn)在改了存語言的編碼，因?yàn)?Olery新的語義分析系統(tǒng)使用的是語言編碼，而不再是語言名稱。
更新應(yīng)用
目前為止，花費(fèi)時(shí)間最多的就是更新應(yīng)用，尤其是那些嚴(yán)重依賴MongoDB聚合框架的應(yīng)用。扔掉那少數(shù)幾個(gè)遺留的Rails應(yīng)用吧，光是測試就會(huì)花掉你幾個(gè)星期的時(shí)間。更新應(yīng)用的過程大致如下：
- 用PostgreSQL的相關(guān)代碼來替換掉MongoDB的驅(qū)動(dòng)/設(shè)置模塊的代碼
- 運(yùn)行測試
- 修復(fù)Bugs
- 反復(fù)運(yùn)行測試，直到所有測試通過
對于非Rails應(yīng)用，Olery推薦使用 Sequel，對于Rails應(yīng)用，Olery現(xiàn)在還無法擺脫ActiveRecord(至少是現(xiàn)在)。Sequel是一個(gè)非常好的數(shù)據(jù)庫工具集，它支持絕大多數(shù)(如果不是全部)我們想使用的PostgreSQL特性。相較于ActiveRecord，它基于DSL的query要強(qiáng)大的多，盡管可能耗時(shí)會(huì)有點(diǎn)長。
舉個(gè)例子，假設(shè)你想計(jì)算有多少用戶使用某種語言，并計(jì)算每種語言所占的比例(相對于整個(gè)集合)。純粹的SQL查詢語句如下所示：
- SELECT locale,count(*) AS amount,
- (count(*) / sum(count(*)) OVER ()) * 100.0 AS percentageFROM users
- GROUP BY localeORDER BY percentage DESC;
- 在我們的例子中，將會(huì)產(chǎn)生以下輸出(當(dāng)使用PostgreSQL命令行界面時(shí))：
- 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經(jīng)常需要)：
- 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))
雖然這可能有些冗長，但是上面的兩種查詢都使得它們更易于重用，而無需進(jìn)行字符串連接。
未來可能也會(huì)將Olery的Rails應(yīng)用程序遷移到Sequel，但是考慮到Rails與ActiveRecord耦合得如此緊密，所以O(shè)lery還不完全確定這是否值得花費(fèi)時(shí)間和精力。
#p#
遷移生產(chǎn)數(shù)據(jù)
最終Olery來到遷移生產(chǎn)數(shù)據(jù)的過程。一般有兩種方法來做這件事：
- 關(guān)掉整個(gè)平臺(tái)，直到所有數(shù)據(jù)都已遷移完成。
- 遷移數(shù)據(jù)的同時(shí)保持系統(tǒng)運(yùn)行。
第一個(gè)選項(xiàng)具有一個(gè)明顯的缺點(diǎn)：停機(jī)時(shí)間。第二個(gè)選項(xiàng)不需要停機(jī)但是很難處理。例如，在這個(gè)方案中，當(dāng)你遷移數(shù)據(jù)的同時(shí)，你必須要考慮所有將要添加的數(shù)據(jù)，否則你就會(huì)損失數(shù)據(jù)。
幸運(yùn)的是，Olery有一個(gè)獨(dú)特的方案就是Olery的數(shù)據(jù)庫的絕大多數(shù)寫操作都是相當(dāng)定期的，經(jīng)常變化的數(shù)據(jù)(例如用戶通訊錄信息)只占總數(shù)據(jù)量的一小部分，相比起Olery檢查數(shù)據(jù)，遷移它們花費(fèi)的時(shí)間相當(dāng)?shù)男 ?/p>
這部分的基本流程是：
- 遷移關(guān)鍵數(shù)據(jù)，例如用戶、合同和那些無論如何都無法承擔(dān)損失的數(shù)據(jù)。
- 遷移不那么關(guān)鍵的數(shù)據(jù)(我們可以重新收集，重新計(jì)算等的數(shù)據(jù))
- 測試是否所有事情都已完成，并運(yùn)行在一組分離的服務(wù)器上。
- 將生產(chǎn)環(huán)境轉(zhuǎn)換到新的服務(wù)器上。
- 重新遷移第一步的數(shù)據(jù)，確保在遷移過程中產(chǎn)生的數(shù)據(jù)沒有丟失。
到目前為止，第二步花費(fèi)的時(shí)間最長，大約為24小時(shí)。另一方面，遷移步驟1和5中提到的數(shù)據(jù)只花了45分鐘。
結(jié)論
Olery遷移完成并且直到非常滿意大概過去了一個(gè)月。到現(xiàn)在為止除了那些積極的影響，還曾在各種情況中讓應(yīng)用的性能大幅提高。舉例來說，Olery的 酒店評論數(shù)據(jù)API(Hotel Review Data API)(在Sinatra運(yùn)行)相比遷移之前交互延遲變低了許多：
遷移是在1月21日開始的，高峰表示應(yīng)用性能的硬重啟(在處理期間導(dǎo)致交互時(shí)間輕微變慢)。在21日之后交互的平均時(shí)間大致是原來的一半。
在另外一種被Olery稱作“評論持久化”(譯者注：即存儲(chǔ)評論)的過程中，Olery發(fā)現(xiàn)了性能上巨大的提升。后臺(tái)程序目標(biāo)很簡單：保存評論數(shù)據(jù)(評論內(nèi)容，評論分?jǐn)?shù)等等)。當(dāng)最終完成了為遷移工作做的很多大的更改后，結(jié)果令人振奮：
抓取器也變的更快了：
抓取器性能提升沒有評論存儲(chǔ)的過程那樣大，因?yàn)樽ト∑髦挥脭?shù)據(jù)庫來查詢某個(gè)評論是否存在(一個(gè)相對很快的操作)，所以這樣的結(jié)果并不很令人吃驚。
最后來到程序里用來調(diào)度抓取過程的進(jìn)程(簡單稱之為“調(diào)度器”)：
因?yàn)檎{(diào)度器只是以固定頻度運(yùn)行，這個(gè)圖可能有點(diǎn)難以理解，但是不管怎樣，在遷移之后有一個(gè)很清晰的平均處理時(shí)間的下降。
