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