為什么Flowdock從Cassandra遷移到MongoDB
by Otto Hilska @mutru Translated by Jametong
Flowdock是一個(gè)基于Web的團(tuán)隊(duì)通訊工具.所有的軟件開發(fā)人員都應(yīng)該使用它進(jìn)行溝通,而不是使用Campfires、Skype Chats或IRC等工具.因?yàn)樗梢愿玫牡闹С炙麄兊恼鎸?shí)工作流.
上周,我們對(duì)Flowdock的數(shù)據(jù)庫(kù)服務(wù)做了一次切換,聰從Cassandra遷移到了另一種NoSQL工具-MongoDB.由于我們的技術(shù)選擇已經(jīng)引起了大家的部分興趣,我將在此向公眾說明下我們的決策理由.
我們的部分客戶一定對(duì)下面這個(gè)圖片記憶猶新:
從一定程度上講,我們?cè)庥龅搅薈assandra的穩(wěn)定性問題.所有的節(jié)點(diǎn)都陷入無(wú)線無(wú)限循環(huán)(infinite loop),運(yùn)行垃圾回收工作(GC, Garbage Collection)并嘗試壓縮數(shù)據(jù)文件-并偶爾導(dǎo)致集群癱瘓.除了對(duì)集群進(jìn)行重啟并經(jīng)常性的手工對(duì)節(jié)點(diǎn)做壓縮工作以讓其穩(wěn)定一會(huì)外,我們無(wú)計(jì)可施.其他人也報(bào)告過類似的問題.在前面幾周的時(shí)間里,我們的Cassandra節(jié)點(diǎn)總是會(huì)吃掉給他分配的所有資源,而導(dǎo)致Flowdock運(yùn)行緩慢.
由于我們刀口嗜血式的數(shù)據(jù)庫(kù)選擇(James注: 這是我不認(rèn)同的地方,可能對(duì)于一些Startup的公司來講,這是一種不得已的選擇.),這已經(jīng)不是我們第一次遇到此類問題了.從Cassandra 0.4升級(jí)到0.5的時(shí)候,我們被迫關(guān)閉了整個(gè)集群,僅僅是為了將所有的數(shù)據(jù)刷新到磁盤上(雖然,我們已經(jīng)按照文檔進(jìn)行了手工刷新的操作).這個(gè)操作導(dǎo)致我們丟失了幾分鐘的討論內(nèi)容,以及我們手工創(chuàng)建的索引出現(xiàn)嚴(yán)重的不一致,以致于需要做完全的重建.我想,我們最后離開辦公室的時(shí)間已經(jīng)是凌晨4點(diǎn)了.
從我們最初選擇Cassandra到現(xiàn)在,NoSQL社區(qū)已經(jīng)出現(xiàn)了很大的變化.MongoDB已經(jīng)發(fā)生了很大的改變,最近新增的自動(dòng)分片(auto-
sharding)與副本集(replica set)使得它可以作為Cassandra的有力的替代品.因此,我們決定試試MongoDB.
寫從Cassandra往MongoDB的數(shù)據(jù)遷移的腳本耗費(fèi)我一天的時(shí)間.在一周左右的時(shí)間內(nèi),我們已經(jīng)可以完全在MongoDB上運(yùn)行Flowdock了.在生產(chǎn)環(huán)境部署MongoDB之前,內(nèi)部測(cè)試持續(xù)進(jìn)行了好幾個(gè)星期.
目前,我們已經(jīng)完成這個(gè)調(diào)整,
- 1. 智能(多鍵)索引. 手工維護(hù)的索引令人生厭,MongoDB可以自動(dòng)幫我們維護(hù)所需的索引.例如,我們的消息包含標(biāo)簽(tag),例如下面這個(gè)格式的document:
{ content: "Write a blog post about #mongodb.",
workspace: 'myflow',
tags: ["mongodb", "todo", "@Otto"] }
這樣,如果僅檢索自己的任務(wù),Flowdock的后臺(tái)只需要做下面這個(gè)查詢:
db.messages.find({
workspace: 'myflow',
tags: { $all: ["todo", "@Otto"] }
})
- 2. 查詢.無(wú)論數(shù)據(jù)模型多么簡(jiǎn)單,每當(dāng)需要執(zhí)行一個(gè)查詢的時(shí)候,你都不需要提前規(guī)劃此事.在MongoDB中,你可以直接在控制臺(tái)定制復(fù)雜的查詢,這一點(diǎn)非常類似于SQL數(shù)據(jù)庫(kù).它會(huì)據(jù)此執(zhí)行一次順序掃描,這比在客戶端手工處理上百萬(wàn)的記錄要更快捷也更便利.
- 3. Map-Reduce. 這是分析人員的利器啊.MongoDB的Map-Reduce功能支持雖然不是非常完美,但它起碼很易用.
- 4. GridFS讓我們的文件存儲(chǔ)操作變得非常容易.它的存儲(chǔ)能力可以隨著我們的MongoDB集群的擴(kuò)展一起增長(zhǎng).
我們也遭遇到部分輕微的限制:
- 1. 我們發(fā)現(xiàn)了一個(gè)JSON解析的bug,不過我們?cè)?0分鐘內(nèi)就解決了此bug.
- 2. BSON的Document鍵中不支持點(diǎn)(dot).通常,這或許不是個(gè)問題,但是我們必須在數(shù)據(jù)遷移中解決此問題.
- 3. Document有4MB的大小限制.這對(duì)于我們的數(shù)據(jù)模型來講不是問題,由于MongoDB對(duì)在位的原子更新(atomic in-place updates)有非常好的支持,所以,你需要關(guān)注,Document不要超過4MB的限制.
- 4. 增加新的節(jié)點(diǎn)沒有在Cassandra中那么容易.然而,Cassandra在新增節(jié)點(diǎn)的負(fù)載均衡上有它自己的問題.
到目前為止,它的運(yùn)行還非常平穩(wěn).開發(fā)人員與數(shù)據(jù)庫(kù)管理員的工作也因此減輕了很多.
|
