MongoDB與Cassandra是兩個***人氣的NoSQL數據庫，MongoDB更是NoSQL領域當之無愧的人氣王，而Cassandra則常年霸占著列存儲領域的***，相比之下備受關注的HBase卻因眾多原因一直屈居次席。近日MyDrive Soulutions運營和架構總監分享了這兩個人氣NoSQL數據庫在其公司的實踐，并給出了相關對比，以下為譯文：

使用Cassandra替換MongoDB來管理時間序列后的飛躍

使用場景

MyDrive擁有一個基于AWS托管的數據處理平臺，由Resque工作者負責。作為一個遠程信息處理公司，我們需要處理非常多的時間序列數據，初始我們采用了MongoDB。作為初期方案，MongoDB最初定義就是臨時性的選擇。

MongoDB表現的也是相當不錯，然而不同大小負載處理時間的不可預測性帶來了很多困擾，同時也讓數據處理管道的優化變得非常困難?；贛ongoDB的設計(大部分的關系型數據庫同樣如此)，返回30個文檔與返回300個文檔的作業將觸發不同的I/O負載，而返回30個文檔的作業肯定要比300個的快。當然不管是30還300，處理的速度都不是很快，即使使用了非常好的索引及非常合適的實例。

此后，我們不得不對MongoDB實例進行一定的縱向擴展;當然如果長期如此，將帶來非常多的額外開銷。

解決方案

從開始，目標就被鎖定在Cassandra上，因為AboutUs 5.0之后的版本都使用了Cassandra。它已經向我們證明了強大的可靠性、可見性以及彈性。這些特色在整合了橫向擴展之后，讓Cassandra成為一個當之無愧的殺手級數據存儲。

一般情況的數據流為寫入數據>>讀回>>修改>>寫入>>再讀取，這些操作被不同用戶執行。雖然這不是Cassandra的設計理念，但是Cassandra卻非常適合我們的查詢方式。

Cassandra確實非常適合時間序列數據，因為可以周期性的將時間序列數據寫入1列，然后通過部分字符串對比來查詢一定時間范圍內的數據。這樣的話使用列就比使用行更加的高效，而加載單行可以讓你獲得巨大的I/O性能。然后Cassandra必須至少讀取一個數據，而隨著數據持久化到磁盤的進行，所有剩余的數據都將被讀取。

我們使用時間戳作為ID的前半部分，這樣的話就可以做任何時間段的范圍查詢——每行都體現出了一條數據，而列則體現了時間序列數據的一個周期。這樣所有數據都可以通過鍵及起止時間查詢。

鑒于我們工作負載的類型，使用MongoDB時，寫操作的數量會嚴重影響到讀的性能，而使用Cassandra就不會有這種情況發生。

前后對比

上面的突變顯示大半年的性能，藍線表示的是受數據存儲性能影響的部分。很明顯在做MongoDB優化及橫向擴展硬件時性能的落差很大，然而這些對Cassandra毫無影響。

我們階段化的關閉了MongoDB，開始是停止了對其寫入，***停止了在MongoDB上的讀操作(在圖片上使用了紅色箭頭標注)，不過圖片上沒有顯示的是在過渡到Cassandra后加入了大量的批處理作業。