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