MongoDB與Cassandra是兩個(gè)***人氣的NoSQL數(shù)據(jù)庫(kù)，MongoDB更是NoSQL領(lǐng)域當(dāng)之無(wú)愧的人氣王，而Cassandra則常年霸占著列存儲(chǔ)領(lǐng)域的***，相比之下備受關(guān)注的HBase卻因眾多原因一直屈居次席。近日MyDrive Soulutions運(yùn)營(yíng)和架構(gòu)總監(jiān)分享了這兩個(gè)人氣NoSQL數(shù)據(jù)庫(kù)在其公司的實(shí)踐，并給出了相關(guān)對(duì)比，以下為譯文：

使用Cassandra替換MongoDB來(lái)管理時(shí)間序列后的飛躍

使用場(chǎng)景

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ù)測(cè)性帶來(lái)了很多困擾，同時(shí)也讓數(shù)據(jù)處理管道的優(yōu)化變得非常困難?；贛ongoDB的設(shè)計(jì)(大部分的關(guān)系型數(shù)據(jù)庫(kù)同樣如此)，返回30個(gè)文檔與返回300個(gè)文檔的作業(yè)將觸發(fā)不同的I/O負(fù)載，而返回30個(gè)文檔的作業(yè)肯定要比300個(gè)的快。當(dāng)然不管是30還300，處理的速度都不是很快，即使使用了非常好的索引及非常合適的實(shí)例。

此后，我們不得不對(duì)MongoDB實(shí)例進(jìn)行一定的縱向擴(kuò)展;當(dāng)然如果長(zhǎng)期如此，將帶來(lái)非常多的額外開銷。

解決方案

從開始，目標(biāo)就被鎖定在Cassandra上，因?yàn)锳boutUs 5.0之后的版本都使用了Cassandra。它已經(jīng)向我們證明了強(qiáng)大的可靠性、可見性以及彈性。這些特色在整合了橫向擴(kuò)展之后，讓Cassandra成為一個(gè)當(dāng)之無(wú)愧的殺手級(jí)數(shù)據(jù)存儲(chǔ)。

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

Cassandra確實(shí)非常適合時(shí)間序列數(shù)據(jù)，因?yàn)榭梢灾芷谛缘膶r(shí)間序列數(shù)據(jù)寫入1列，然后通過(guò)部分字符串對(duì)比來(lái)查詢一定時(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ù)都可以通過(guò)鍵及起止時(shí)間查詢。

鑒于我們工作負(fù)載的類型，使用MongoDB時(shí)，寫操作的數(shù)量會(huì)嚴(yán)重影響到讀的性能，而使用Cassandra就不會(huì)有這種情況發(fā)生。

前后對(duì)比

上面的突變顯示大半年的性能，藍(lán)線表示的是受數(shù)據(jù)存儲(chǔ)性能影響的部分。很明顯在做MongoDB優(yōu)化及橫向擴(kuò)展硬件時(shí)性能的落差很大，然而這些對(duì)Cassandra毫無(wú)影響。

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