MongoDB與TokyoTyrant性能比較

1、.MongoDB與Tokyo Tyrant性能比較MongoDB與Tokyo Tyrant性能比較2020年11月15日星期一下午11：101：根底CRU操作以前的工程大都把數(shù)據(jù)存放在關(guān)系型數(shù)據(jù)庫中，關(guān)系型數(shù)據(jù)庫的優(yōu)勢(shì)在于使用普及，資料豐富，且有大量輔助類庫來簡化開發(fā)。當(dāng)然它們的問題比較明顯的，一是在數(shù)據(jù)量上升的情況下伸縮性比較差，且進(jìn)展構(gòu)造調(diào)整的代價(jià)比較高。因此如今有個(gè)所謂NoSQL的"運(yùn)動(dòng)"也逐漸普遍起來了，它便是借助一些非關(guān)系型存儲(chǔ)方式來開發(fā)工程個(gè)人認(rèn)為其實(shí)將它解釋為Not Only SQL更為適宜。因此在新工程里，我也想嘗試一下使用之前一直只是"聽說&qu

2、ot;的存儲(chǔ)方式。在和同事的交流過程中，我理解到他們的工程正在嘗試使用Tokyo Tyrant后稱TT進(jìn)展存儲(chǔ)，并且據(jù)說效果不錯(cuò)，因此我一開場也打算嘗試使用TT進(jìn)展主要存儲(chǔ)，為此也花了一定時(shí)間為其編寫.NET平臺(tái)下的驅(qū)動(dòng)程序。不過在驅(qū)動(dòng)程序的開發(fā)過程中，我逐漸意識(shí)到TT的功能有著嚴(yán)重的限制，似乎并不適宜作為接下來工程的主要存儲(chǔ)方式。因此，我又將目光轉(zhuǎn)向了之前關(guān)注過的MongoDB上。MongoDB也是NoSQL的代表之一，是一個(gè)面向文檔的，架構(gòu)靈敏Schema-less的存儲(chǔ)方式，在仔細(xì)閱讀相關(guān)資料之后，我發(fā)現(xiàn)它的功能與TT相比可謂天上地下，非常適宜許搭建各類工程關(guān)于這點(diǎn)以后有時(shí)機(jī)再談。不過，

3、既然選擇NoSQL的原因是性能，那么他們的性能表現(xiàn)終究如何呢?TT的性能表如今業(yè)界非常知名，而MongoDB的使用便相對(duì)較少了當(dāng)然，官網(wǎng)列舉了不少案例，最近著名的開源網(wǎng)站SourceForge也打算使用MongoDB重新設(shè)計(jì)他們的網(wǎng)站。為此，我決定親手比較一下兩者的性能表現(xiàn)。測(cè)試環(huán)境及數(shù)據(jù)由于缺乏適宜的環(huán)境，因此我不得不在我的MBP上進(jìn)展這次性能比較，參數(shù)如下：OS：Mac OS Xv 10.6.2Snow LeopardRAM：4GB/1067MHz/DDR 3CPU：2.53GHz Intel Core 2Duo64-bit Kernel and Extensions：YesTT在64 b

4、it環(huán)境下編譯，MongoDB使用64 bit版本。在測(cè)試執(zhí)行時(shí)，我盡量關(guān)閉多余的應(yīng)用程序，防止其它因素造成影響。同樣，由于條件限制，我只得把客戶端和效勞器跑在同一臺(tái)機(jī)器上。測(cè)試代碼使用Ruby編寫，這是由于兩者都有官方提供的驅(qū)動(dòng)程序。此外，由于我對(duì)于兩者的優(yōu)化都不太熟悉，因此它們都使用了默認(rèn)的配置。關(guān)于測(cè)試數(shù)據(jù)，我將存入110萬條"新聞"數(shù)據(jù)，包含以下字段：ID：標(biāo)識(shí)，32位整數(shù)，帶索引Title：標(biāo)題，字符串CategoryID：分類ID，32位整數(shù)，帶索引CreateTime：日期，保存為32位整數(shù)，帶索引UserID：用戶ID，32位整數(shù)，帶索引Tags：標(biāo)簽集合，

5、字符串?dāng)?shù)組，帶索引Source：來源，字符串SourceUrl：來源URL，字符串Status：狀態(tài)，32位整數(shù)為了相對(duì)接近真實(shí)的環(huán)境的數(shù)據(jù)分布特征便于以后進(jìn)展查詢操作比較，我設(shè)計(jì)了這樣的測(cè)試數(shù)據(jù)詳細(xì)可閱讀代碼：2萬個(gè)分類，分別擁有10個(gè)至100條新聞，總共110萬條記錄。1萬個(gè)用戶，根據(jù)分類id取模得到其歸屬。創(chuàng)立時(shí)間從2020年1月1日起遞增，每條記錄增加1秒。每條記錄擁有2到6個(gè)Tag，除了其中一個(gè)之外，都從一個(gè)1.7萬個(gè)Tag庫中獲取。每條記錄的字符串字段都不長20-30字符由于TT只支持字符串的值但可以建立數(shù)字索引，會(huì)將字符串當(dāng)作數(shù)字來識(shí)別，因此事實(shí)上所有的值都會(huì)轉(zhuǎn)化為字符串進(jìn)展保存

6、。此外，由于存在"根據(jù)Tag查找新聞"的業(yè)務(wù)，因此對(duì)于Tags字段也建立了索引，其中MongoDB直接支持對(duì)字符串?dāng)?shù)組的索引索引其中每個(gè)元素，而在存入TT時(shí)那么轉(zhuǎn)化為空格分隔的字符串，并為其建立倒排索引Token Inverted Index以便進(jìn)展全文查找。在存儲(chǔ)方式上，所有數(shù)據(jù)將放入MongoDB的同一個(gè)集合內(nèi)，而TT那么選用Table Database存儲(chǔ)構(gòu)造。在使用TT時(shí)，另一種做法是完全使用鍵值對(duì)來保存一條記錄的各個(gè)字段，不過這樣做會(huì)大大限制TT的功能，或是會(huì)為系統(tǒng)編寫帶來額外的復(fù)雜度，便不考慮Hash/B+Tree/Fixed-length等存儲(chǔ)方式了。插入操作

7、性能比較詳細(xì)代碼在tt-insert.rb及mdb-insert.rb文件中。兩段代碼均使用一個(gè)連接，使用循環(huán)每次插入一條：由于假設(shè)每次都建立連接，會(huì)在TCP/IP連接的翻開關(guān)閉上消耗大部分時(shí)間，由于實(shí)際工程中根本都會(huì)使用連接池等機(jī)制來復(fù)用連接，因此這方面便不多做考慮；再者，由于實(shí)際插入時(shí)幾乎不可能批量操作，因此這里并不使用兩者提供的批量插入功能。腳本每插入10萬條記錄便打印出所耗時(shí)間，結(jié)果如下：從結(jié)果上看，MongoDB大約有10%的領(lǐng)先，不過總體來說兩者的差距不大。值得一提的是，TT在數(shù)據(jù)量越大的情況下，每插入10萬條記錄的耗時(shí)越長也從同事的使用過程中確認(rèn)了這一點(diǎn)。因此，一開場兩者插入速度

8、幾乎沒有差距，但是漸漸地TT便落后于MongoDB了。目前推測(cè)這可能是TT的Table Database存儲(chǔ)構(gòu)造特有的問題，不知道隨著數(shù)據(jù)量的增長TT表現(xiàn)如何，因?yàn)閷?duì)于一個(gè)大型系統(tǒng)來說，100多萬條記錄實(shí)際上只是一個(gè)很小的數(shù)目。有同事推測(cè)，TT插入性能低是因?yàn)榻⒘薚ags字段的倒排索引，于是我也測(cè)試了不在Tags字段上建索引的情況。令人驚訝的是，同樣去除Tags字段的索引之后，MongoDB的性能提升超過20%，而TT的性能提升卻微乎其微。值得一提的是，放入一樣的記錄之后，TT的文件為400多M，但MongoDB那么為整整2G。因此推測(cè)這是MongoDB進(jìn)展空間預(yù)分配的結(jié)果，郵件列表上的這個(gè)

9、討論也證實(shí)了這一點(diǎn)。此外，上面每次測(cè)試都是從零開場的，經(jīng)測(cè)試假設(shè)在插入前為MongoDB預(yù)分配文件空間，那么性能還會(huì)有些許進(jìn)步。通過主鍵獲取記錄性能比較詳細(xì)代碼在tt-get-by-key.rb及mdb-get-by-key.rb文件中。兩段代碼同樣均使用一個(gè)連接，使用循環(huán)進(jìn)展100萬次Get操作，每次都隨機(jī)獲取一個(gè)110萬以內(nèi)的數(shù)字，并作為ID進(jìn)展Get操作。同樣，每10萬次Get操作后打印出所耗時(shí)間，結(jié)果如下：在Get操作方面，MongoDB有大約20%的領(lǐng)先。不過從實(shí)際情況分析，這方面的差距也不是太大，因?yàn)樵诠こ讨懈鶕?jù)主鍵獲取記錄的操作8成以上都是落在緩存上的，因此在這方面對(duì)存儲(chǔ)的要求并

10、不高。通過主鍵更新記錄性能比較詳細(xì)代碼在tt-update-by-key.rb及mdb-update-by-key.rb文件中。兩段代碼各自使用同一個(gè)連接，使用循環(huán)進(jìn)展大量的更新操作。每次隨機(jī)獲取一個(gè)110萬以內(nèi)的數(shù)字，并作為ID更新其CreateTime、Title、Source、SourceUrl、Status五個(gè)字段。結(jié)果如下：首先是MongoDB的三次測(cè)試結(jié)果，每次更新100萬條數(shù)據(jù)。從數(shù)據(jù)上看，三次查詢的性能越來越高，這個(gè)現(xiàn)象在重啟效勞器之后可以重現(xiàn)三次測(cè)試之間并沒有重啟效勞器。請(qǐng)注意，TT的三次測(cè)試均只更新了10萬條記錄因?yàn)?00萬條記錄耗時(shí)太長。和MongoDB類似，一開場查詢性

11、能較差，但是會(huì)漸漸進(jìn)步，這個(gè)現(xiàn)象在重啟效勞器后也能重現(xiàn)，于是猜測(cè)是緩存的結(jié)果。即便如此，TT的更新時(shí)的最高速度只有大約沒秒1500次，而MongoDB卻超過了每秒5000次。這是因?yàn)門T在功能上有硬傷：它無法像SQL的UPDATE語句那樣更新某條記錄的部分字段，因此必須全部取出，修改后再整體寫入。而MongoDB支持高效的直接修改-這也成為MongoDB放在首頁上的"招牌功能"。因此，TT對(duì)于"更新某個(gè)分類下所有新聞的狀態(tài)"這樣的操作會(huì)很不適應(yīng)，而它的這個(gè)限制導(dǎo)致我們很難實(shí)現(xiàn)如"樂觀并發(fā)控制"這樣的手段。此外，在實(shí)際應(yīng)用中客戶端與效勞

12、器不會(huì)使用本地連接，因此在消費(fèi)環(huán)境中TT和MongoDB在這方面的差距可能會(huì)更明顯一些?？偨Y(jié)到目前為止，我們測(cè)試了TT和MongoDB在CRU三種根本操作下的性能，似乎MongoDB全面勝過Tokyo Tyrant。不過需要強(qiáng)調(diào)的是，這個(gè)測(cè)試還很不全面：它沒有使用適宜的環(huán)境，也沒有對(duì)兩者進(jìn)展適當(dāng)?shù)膬?yōu)化。此外，兩者在并發(fā)情況下，或是同時(shí)讀寫下的表現(xiàn)如何也是值得進(jìn)一步考察的，我也會(huì)設(shè)計(jì)更多的測(cè)試用例。因此，這里的數(shù)據(jù)僅供參考，假設(shè)有適宜的環(huán)境我也會(huì)重新進(jìn)展測(cè)試。2：并發(fā)寫入操作在上一次的測(cè)試中我們比較了MongoDB與Tokyo Tyrant的Table Database兩種存儲(chǔ)方式的性能。不過由

13、于條件限制，我只能在自己的MBP上測(cè)試，而這至少會(huì)帶來兩個(gè)問題。首先，真實(shí)環(huán)境下客戶端和效勞器是通過內(nèi)網(wǎng)連接的，它的性能比本地回環(huán)要慢不少，一些和網(wǎng)絡(luò)傳輸性能有關(guān)的問題可能會(huì)表達(dá)不出。其次，由于無法進(jìn)展并發(fā)測(cè)試并發(fā)測(cè)試的客戶端資源占用較高，放在同一臺(tái)機(jī)器上準(zhǔn)確性較差，這又和消費(fèi)環(huán)境有很大區(qū)別了。因此，我前兩天向同事借了臺(tái)性能測(cè)試用的機(jī)器，希望可以得到更可靠的結(jié)果。測(cè)試環(huán)境與數(shù)據(jù)這次我使用了新的環(huán)境進(jìn)展性能測(cè)試：OS：CentOS release 5.3FinalRAM：4GBCPU：IntelRXeonRCPU E54052.00GHz64 bit,4 cores*2其他：SCSI硬盤，ext

14、3文件系統(tǒng)客戶端與效勞器端配置一樣，兩臺(tái)機(jī)器使用百兆網(wǎng)相連，測(cè)試時(shí)效勞器保持空閑。測(cè)試數(shù)據(jù)的構(gòu)造與之前一樣包括索引，數(shù)據(jù)分布同樣保持一致，每個(gè)線程插入的數(shù)量較少，但每次測(cè)試的總數(shù)均不低于上次110萬條。為了測(cè)試并發(fā)插入的性能，我略微改寫了測(cè)試腳本。首先，我為它增加init參數(shù)，它的作用是初始化存儲(chǔ)構(gòu)造去除數(shù)據(jù)，建立索引，拿MongoDB的測(cè)試腳本為例：#ruby mdb-insert.rb init index for CreateTime created.index for CategoryID created.index for UserID created.index for Tags

15、created.initialize completed.此外，腳本還支持"分類范圍"的指定，例如：#ruby mdb-insert.rb 101 200這表示我們將插入CategoryID為101至200的新聞，由于每個(gè)分類中均勻分布10至100條記錄，因此只要范圍的上下限保持10的倍數(shù)，這樣平均每個(gè)分類有55條新聞，于是新聞ID也可以此計(jì)算出來。例如分類101至200的新聞，其ID便為5501至11000。您可以通過閱讀代碼理解這些細(xì)節(jié)。為了并行測(cè)試，每次我就將同時(shí)執(zhí)行多個(gè)腳本進(jìn)展插入，每個(gè)腳本提供不同的參數(shù)。我使用類似這樣的shell腳本來啟動(dòng)并行任務(wù)：#！/bin/

16、bash#mdb-insert.sh echo"=initialize="ruby mdb-insert.rb init fori=1；i=5；i+do let begin=$4000*$i-1+1let end=$4000*$iecho=start task$i=ruby mdb-insert.rb$begin$end logs/mdb-insert-$begin-$end.log&done這段腳本將啟動(dòng)5個(gè)任務(wù)，每個(gè)任務(wù)將插入4000個(gè)分類，即22萬條記錄。5個(gè)任務(wù)總共插入110萬條記錄，與前次持平。接下來的測(cè)試中，我在增加任務(wù)數(shù)量的同時(shí)也會(huì)適當(dāng)降低每個(gè)任務(wù)插入

17、的記錄數(shù)目。最多我將啟用100個(gè)任務(wù)，每個(gè)任務(wù)插入1000個(gè)分類，即所有任務(wù)共計(jì)插入550萬條記錄，是之前的5倍。在所有的測(cè)試中，無論多少個(gè)任務(wù)都是同時(shí)啟動(dòng)，且?guī)缀跬瑫r(shí)完畢與總耗時(shí)相比很小。因此，在接下來的數(shù)據(jù)中我不會(huì)列出每個(gè)任務(wù)的開場及完畢時(shí)間，假設(shè)您關(guān)心這部分?jǐn)?shù)據(jù)，可以在文章結(jié)尾處可以獲得本次測(cè)試生成的所有記錄文件。Tokyo Tyrant性能測(cè)試第1次測(cè)試啟動(dòng)5個(gè)任務(wù)，每個(gè)任務(wù)4000個(gè)分類，共計(jì)插入110萬條記錄。結(jié)果如下第1行粗體表示"萬條記錄"，每個(gè)數(shù)字的單位為"秒"，下同：與之前的現(xiàn)象類似，當(dāng)數(shù)據(jù)庫中的數(shù)據(jù)越多時(shí)，插入速度也會(huì)隨之減慢：在每

18、個(gè)任務(wù)插入前1萬條記錄時(shí)，耗時(shí)大約為5、6秒。但是到了中后期，每插入1萬條數(shù)據(jù)那么需要等待15至20，甚至30秒的時(shí)間。值得注意的是，雖然使用了較好的效勞器，但是并行插入110萬條記錄的時(shí)間卻比上次要來的多這次耗時(shí)340秒，而之前是。原因可能是客戶端與效勞器端的別離導(dǎo)致網(wǎng)絡(luò)速度的下降。另一種可能我猜測(cè)是，根據(jù)Tokyo Cabinet的文檔中提到文件讀寫鎖的使用，因此每次只能插入一條記錄，且插入或更新時(shí)無法讀取數(shù)據(jù)，因此在并發(fā)環(huán)境下Tokyo Tyrant它其實(shí)是Tokyo Cabinet上層的TCP效勞器的表現(xiàn)并不會(huì)有所進(jìn)步。不過據(jù)讀過Tokyo Cabinet代碼的同事說，Tokyo Ca

19、bint在使用Table Database的時(shí)候鎖粒度不會(huì)那么大，因此關(guān)于這點(diǎn)還需要尋找進(jìn)一步的資料。第2次測(cè)試啟動(dòng)10個(gè)任務(wù)，每個(gè)任務(wù)還是4000個(gè)分類，因此共計(jì)插入220萬條記錄。結(jié)果如下：第2次測(cè)試的總數(shù)據(jù)量為第1次的2倍，而耗時(shí)卻是第1次的3.5倍，這應(yīng)該還是由于數(shù)據(jù)量增大而導(dǎo)致的插入性能降低。但是，我們目前還不能排除這和并發(fā)連接數(shù)有關(guān)的可能-雖然我們有理由相信這個(gè)性能問題只和數(shù)據(jù)量相關(guān)稍后再說。為了查明并發(fā)程度和性能是否有關(guān)系，我們?cè)龠M(jìn)展第3次測(cè)試。第3次測(cè)試啟動(dòng)20個(gè)任務(wù)，每個(gè)任務(wù)2000個(gè)分類，因此共計(jì)仍舊是220萬條記錄。結(jié)果如下：這個(gè)結(jié)果實(shí)在是非?？梢哉f明問題：第3次的耗時(shí)與

20、上一次幾乎完全一樣，這意味著加大并發(fā)量并不會(huì)影響TT的性能。這是因?yàn)門T在效勞器端維護(hù)了一個(gè)線程池如今的測(cè)試，也是默認(rèn)情況下為8個(gè)線程，因此懇求再多，同時(shí)進(jìn)展的任務(wù)也是有限的，而累積的任務(wù)會(huì)排在隊(duì)列中。這也是使用隊(duì)列和固定數(shù)量工作線程的好處：即使壓力再大，效勞器端的吞吐量也可以一直保持較高水準(zhǔn)，而客戶端懇求的響應(yīng)時(shí)間隨著懇求數(shù)量增大而線性增長。假設(shè)沒有隊(duì)列，隨著壓力增大，效勞器端吞吐量會(huì)劇烈下降一般至少也是線性的，而客戶端懇求的響應(yīng)時(shí)間增長更快，直至超時(shí)。為此，我們也沒有必要繼續(xù)測(cè)試更多的并發(fā)數(shù)量了，因?yàn)榧幢闶窃俣嗖l(fā)，TT的吞吐量即插入記錄的數(shù)目也只是和數(shù)據(jù)庫中記錄數(shù)量相關(guān)。根據(jù)測(cè)試，我們可

21、以總結(jié)出：插入110萬條記錄的平均吞吐量為：大約3225條/秒插入220萬條記錄的平均吞吐量為：大約1833條/秒當(dāng)數(shù)據(jù)庫包含100萬條數(shù)據(jù)時(shí)吞吐量為：17001800條/秒當(dāng)數(shù)據(jù)庫包含200萬條數(shù)據(jù)時(shí)吞吐量為：150160條/秒似乎隨著數(shù)據(jù)量的增加，TT的吞吐量下降得也非常明顯。這其中可能有索引的因素在里面，因此假設(shè)您想要得到適宜自己的結(jié)果，最好可以親自進(jìn)展試驗(yàn)。MongoDB性能測(cè)試與TT一樣，第1次測(cè)試啟動(dòng)5個(gè)任務(wù)，每個(gè)任務(wù)4000個(gè)分類，共計(jì)插入110萬條記錄。結(jié)果如下：在5個(gè)并發(fā)任務(wù)的情況下，MongoDB的表現(xiàn)較TT要出彩不少。首先，隨著數(shù)據(jù)庫中已有記錄的增加，插入速度并沒有降低的

22、跡象，可以說非常平穩(wěn)。此外，在同樣的客戶端和效勞器環(huán)境下，MongoDB插入110萬條數(shù)據(jù)的耗時(shí)比TT的一半還要略少一些。而且，雖然網(wǎng)速帶來的一定負(fù)面影響，但可能是由于效勞器配置的進(jìn)步，再加上并發(fā)寫入的性能優(yōu)勢(shì)，此次測(cè)試比上次單機(jī)環(huán)境下的表現(xiàn)也要好上許多。那么在數(shù)據(jù)量和并發(fā)繼續(xù)增大的情況下MongoDB表現(xiàn)如何呢?于是第2次測(cè)試啟動(dòng)10個(gè)任務(wù)，每個(gè)任務(wù)還是4000個(gè)分類，共計(jì)插入220萬條記錄。結(jié)果如下：第2次的數(shù)據(jù)量為第1次的2倍，而耗時(shí)那么大約為2.08倍，兩者根本保持一致，這說明了MongoDB在數(shù)據(jù)量和并發(fā)量增加的情況下，吞吐量幾乎沒有改變。第3次測(cè)試照舊與TT一樣，啟用20個(gè)任務(wù)，每

23、個(gè)任務(wù)2000個(gè)分類，共計(jì)插入220萬條記錄。結(jié)果如下：在總數(shù)據(jù)量不變的情況下，我們又將并發(fā)量進(jìn)步了一倍，但是MongoDB照舊表現(xiàn)出的穩(wěn)定的吞吐量，總耗時(shí)與第2次測(cè)試幾乎完全一樣。這樣看來，似乎在MongoDB在內(nèi)部也有個(gè)類似于TT的隊(duì)列機(jī)制以保證一定的吞吐量。為了驗(yàn)證這個(gè)看法，我再次加大了數(shù)據(jù)量和并發(fā)量。在第4次測(cè)試中我啟用了50個(gè)任務(wù)，每個(gè)任務(wù)還是2000個(gè)分類，這樣插入的記錄數(shù)據(jù)那么到達(dá)了550萬。結(jié)果如下：在50個(gè)并發(fā)任務(wù)下，MongoDB終于略顯疲態(tài)。第4次測(cè)試的數(shù)據(jù)量為第3次的2.5倍，但耗時(shí)卻接近3.5倍。為了驗(yàn)證這是由于數(shù)據(jù)量增加，還是并發(fā)量進(jìn)步引起的問題，我又進(jìn)展了第最后一

24、次測(cè)試。第5個(gè)測(cè)試中啟用了100個(gè)任務(wù)，但每個(gè)任務(wù)只寫入1000個(gè)分類，那么總條目數(shù)還是和第4次一樣，為550萬。結(jié)果如下：請(qǐng)注意，由于每個(gè)任務(wù)插入1000個(gè)分類，即5.5萬條記錄，因此上表中最后一欄為5.5而不是6。隨著并發(fā)量的增大，MongoDB的耗時(shí)繼續(xù)增加了。由于這個(gè)表現(xiàn)和之前的預(yù)測(cè)不同，我又把第4次和第5次測(cè)試各執(zhí)行了一遍，結(jié)果并沒有太大區(qū)別，根本可以排除"環(huán)境異常"這樣的可能。經(jīng)過5次測(cè)試的結(jié)果，我們可以得出MongoDB的性能指標(biāo)：5個(gè)并發(fā)，插入110萬條記錄的平均吞吐量：大約6600條/秒10個(gè)并發(fā)，插入220萬條記錄的平均吞吐量：大約6300條/秒20個(gè)并發(fā)