MongoDB與Cassandra是兩個(gè)最具人氣的NoSQL數(shù)據(jù)庫，MongoDB更是NoSQL領(lǐng)域當(dāng)之無愧的人氣王，而Cassandra則常年霸占著列存儲(chǔ)領(lǐng)域的首席，相比之下備受關(guān)注的HBase卻因眾多原因一直屈居次席。近日MyDrive Soulutions運(yùn)營和架構(gòu)總監(jiān)分享了這兩個(gè)人氣NoSQL數(shù)據(jù)庫在其公司的實(shí)踐，并給出了相關(guān)對比，以下為譯文：
使用Cassandra替換MongoDB來管理時(shí)間序列后的飛躍
使用場景
MyDrive擁有一個(gè)基于AWS托管的數(shù)據(jù)處理平臺(tái)，由Resque工作者負(fù)責(zé)。作為一個(gè)遠(yuǎn)程信息處理公司，我們需要處理非常多的時(shí)間序列數(shù)據(jù)，初始我們采用了MongoDB。作為初期方案，MongoDB最初定義就是臨時(shí)性的選擇。
MongoDB表現(xiàn)的也是相當(dāng)不錯(cuò)，然而不同大小負(fù)載處理時(shí)間的不可預(yù)測性帶來了很多困擾，同時(shí)也讓數(shù)據(jù)處理管道的優(yōu)化變得非常困難。基于MongoDB的設(shè)計(jì)（大部分的關(guān)系型數(shù)據(jù)庫同樣如此），返回30個(gè)文檔與返回300個(gè)文檔的作業(yè)將觸發(fā)不同的I/O負(fù)載，而返回30個(gè)文檔的作業(yè)肯定要比300個(gè)的快。當(dāng)然不管是30還300，處理的速度都不是很快，即使使用了非常好的索引及非常合適的實(shí)例。
此后，我們不得不對MongoDB實(shí)例進(jìn)行一定的縱向擴(kuò)展；當(dāng)然如果長期如此，將帶來非常多的額外開銷。
解決方案
從開始，目標(biāo)就被鎖定在Cassandra上，因?yàn)锳boutUs 5.0之后的版本都使用了Cassandra。它已經(jīng)向我們證明了強(qiáng)大的可靠性、可見性以及彈性。這些特色在整合了橫向擴(kuò)展之后，讓Cassandra成為一個(gè)當(dāng)之無愧的殺手級數(shù)據(jù)存儲(chǔ)。
一般情況的數(shù)據(jù)流為寫入數(shù)據(jù)>>讀回>>修改>>寫入>>再讀取，這些操作被不同用戶執(zhí)行。雖然這不是Cassandra的設(shè)計(jì)理念，但是Cassandra卻非常適合我們的查詢方式。
Cassandra確實(shí)非常適合時(shí)間序列數(shù)據(jù)，因?yàn)榭梢灾芷谛缘膶r(shí)間序列數(shù)據(jù)寫入1列，然后通過部分字符串對比來查詢一定時(shí)間范圍內(nèi)的數(shù)據(jù)。這樣的話使用列就比使用行更加的高效，而加載單行可以讓你獲得巨大的I/O性能。然后Cassandra必須至少讀取一個(gè)數(shù)據(jù)，而隨著數(shù)據(jù)持久化到磁盤的進(jìn)行，所有剩余的數(shù)據(jù)都將被讀取。
我們使用時(shí)間戳作為ID的前半部分，這樣的話就可以做任何時(shí)間段的范圍查詢——每行都體現(xiàn)出了一條數(shù)據(jù)，而列則體現(xiàn)了時(shí)間序列數(shù)據(jù)的一個(gè)周期。這樣所有數(shù)據(jù)都可以通過鍵及起止時(shí)間查詢。
鑒于我們工作負(fù)載的類型，使用MongoDB時(shí)，寫操作的數(shù)量會(huì)嚴(yán)重影響到讀的性能，而使用Cassandra就不會(huì)有這種情況發(fā)生。
前后對比
上面的突變顯示大半年的性能，藍(lán)線表示的是受數(shù)據(jù)存儲(chǔ)性能影響的部分。很明顯在做MongoDB優(yōu)化及橫向擴(kuò)展硬件時(shí)性能的落差很大，然而這些對Cassandra毫無影響。
我們階段化的關(guān)閉了MongoDB，開始是停止了對其寫入，最后停止了在MongoDB上的讀操作（在圖片上使用了紅色箭頭標(biāo)注），不過圖片上沒有顯示的是在過渡到Cassandra后加入了大量的批處理作業(yè)。