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在新增節點的負載平衡上有它自己的問題.

到目前為止,它的運行還非常平穩.開發人員與資料庫管理員的工作也因此減輕了很多.