MongoDB CouchDB CouchBase效能評測報告
阿新 • • 發佈：2019-01-25
一.功能特性比對
1.資料查詢操作
這個區別在使用者介面上了，MongoDB 與傳統的資料庫系統類似，支援動態查詢，即使在沒有建立索引的行上，也能進行任意的查詢。而 CouchDB 不同，CouchDB 不支援動態查詢，你必須為你的每一個查詢模式建立相應的view，並在此view的基礎上進行查詢。
2.REST
CouchDB 是一個RESTFul 的資料庫，其操作完全走HTTP協議，而MongoDB是走的自己的二進位制協議。MongoDB Server在啟動時可以開放一個HTTP 的介面供狀態監控。
如圖為CouchDB特性，提前建立好的一個view，統計某key的對應value總值，查詢走HTTP協議。
3.MVCC（Multiversion concurrency control） MongoDB 與 CouchDB 的一大區別就是CouchDB 是一個MVCC的系統，而MongoDB是一個update-in-place 的系統。這二者的區別就是，MongoDB 進行寫操作時都是即時完成寫操作，寫操作成功則資料就寫成功了，而CouchDB 一個支援多版本控制的系統，此類系統通常支援多個結點寫，而系統會檢測到多個系統的寫操作之間的衝突並以一定的演算法規則予以解決。 如圖為CouchDB一個文件示例：
4.原子性 這一點上兩者比較一致，都支援針對行的原子性修改（concurrent modifications of single documents），但不支援更多的複雜事務操作。 5.與Java的結合 二.適用場景
三.寫入效率、統計效率 1.環境： WIN10_64位、Inter(R) Core(TM) i5-5200U CPU記憶體、8G、MongoDB v3.4.1、CouchDB v2.0.0 2.效率比對圖表（單位毫秒）： 2.1 1672074條資料，統計各PID欄位總條數
2.2 迴圈插入1000條資料
2.3 插入1條資料
3.具體資料：
3.1 資料量1672074
MONGO GROUP cost time 6661
{_id=7015, count=12004}
{_id=7010, count=4077}
{_id=7014, count=20404}
{_id=7031, count=53442}
{_id=7029, count=39453}
{_id=7016, count=43708}
{_id=7002, count=78437}
{_id=7009, count=51115}
{_id=7022, count=75554}
{_id=7032, count=23804}
{_id=7017, count=24791}
{_id=7011, count=79232}
{_id=7026, count=49568}
{_id=7001, count=74835}
{_id=7006, count=79027}
{_id=7013, count=22861}
{_id=7019, count=69726}
{_id=7020, count=34524}
{_id=7004, count=79534}
{_id=7025, count=75704}
{_id=7018, count=78738}
{_id=7005, count=58337}
{_id=7008, count=28611}
{_id=7023, count=75753}
{_id=7027, count=24222}
{_id=7012, count=48597}
{_id=7007, count=66951}
{_id=7024, count=74812}
{_id=7003, count=72993}
{_id=7021, count=78363}
{_id=7028, count=72897}
COUCHDB GROUP cost time 669
{"rows":[
{"key":7001,"value":74835},
{"key":7002,"value":78437},
{"key":7003,"value":72993},
{"key":7004,"value":79534},
{"key":7005,"value":58337},
{"key":7006,"value":79027},
{"key":7007,"value":66951},
{"key":7008,"value":28611},
{"key":7009,"value":51115},
{"key":7010,"value":4077},
{"key":7011,"value":79232},
{"key":7012,"value":48597},
{"key":7013,"value":22861},
{"key":7014,"value":20404},
{"key":7015,"value":12004},
{"key":7016,"value":43708},
{"key":7017,"value":24791},
{"key":7018,"value":78738},
{"key":7019,"value":69726},
{"key":7020,"value":34524},
{"key":7021,"value":78363},
{"key":7022,"value":75554},
{"key":7023,"value":75753},
{"key":7024,"value":74812},
{"key":7025,"value":75704},
{"key":7026,"value":49568},
{"key":7027,"value":24222},
{"key":7028,"value":72897},
{"key":7029,"value":39453},
{"key":7031,"value":53442},
{"key":7032,"value":23804}
]}
3.2 插入1000條資料
MONGO LOOP INSERT ONE DATA cost time 699
COUCHDB LOOP INSERT ONE DATA cost time 41452
3.3 插入1條資料 MONGO INSERT ONE DATA cost time 118
COUCHDB INSERT ONE DATA cost time 385 四.關於另一個NOSQL——CouchBase 我在win10上安裝CouchBase無法成功，在CentOS安裝成功，版本4.5.0-2601 Community Edition (build-2601) 以下列出我近期對CouchBase的一些學習內容：
1.CouchBase與CouchDB一樣，也可在WEB端管控資料。 2.CouchBase支援N1QL (一種類似SQL的用於JSON的查詢語言) 3.簡而言之，CouchBase = CouchDB + MemBase 但是，CouchBase並非CouchDB的新版本，相反，它實際上是MemBase的新版本。CouchBase Server實際上是MemBase Server的新名字 4.與CouchDB類似，使用MapReduce功能，要先建立view，在view裡寫MapReduce。我建立的查詢pid出現次數的view結果如下(查詢速度很快)：
我在bucket(CouchBase中的“庫”概念)已匯入了167W多的資料，但圖中的values值偏差很大，查資料猜測可能是“延後寫入”功能，我至今還不知道怎麼解決。 5.Java對其的支援有com.couchbase.client-java-client，用它呼叫CouchBase進行資料插入，迴圈單插1000條資料，花費2215毫秒，插入1條花費169毫秒。 五.其它 1.從這幾天研究來看，在CentOS系統上安裝MongoDB較容易，但CouchDB安裝時較多坑，CouchDB依賴於ErLang語言，我編譯安裝時遇到Erlang的crypto模組與openssl動態連結庫不相容的問題，至今還未解決，所以轉而到WIN上進行學習、測試。 2.批量匯入資料 2.1 MongoDB匯入批量資料很方便 使用命令mongoimport -d 資料庫名 -c 文件名 檔案路徑/檔名json.txt json.txt內容形如： {"c1":"v1","c2":"v2"} {"c1":"v11","c2":"v22"} 2.2 CouchDB匯入批量資料，我還沒搞清楚怎麼操作，上文中的170W條資料，我用自己寫的Java程式碼，從MongoDB源取出批量資料的list，再遍歷list，一次次傳送POST請求，迴圈匯入到CouchDB，耗時15小時。 2.3 CouchBase有官方提供的批量匯入Json檔案工具，需將每個Json存成單獨的一個檔案，將這些批量檔案按規範壓縮。170W個Json檔案，我的機器沒法跑出來，於是我採用的方式是將MongoDB裡查出的170W的list，迴圈遍歷存入CouchBase，使用com.couchbase.client-java-client，耗時20分鐘。 3.上文中的Group測試，對於MongoDB，我使用的是aggregate，指令碼即 db.playerData.aggregate([{$group:{_id:"$pid",num:{$sum:1}}}]);
耗時6661毫秒，小於使用MapReduce的情景，MapReduce的效果如圖：
4.關於MongoDB的group與MapReduce的一些整理如下： 4.1 不要用 group是因為它返回的list記憶體值,在查詢結果條數大 10000 keys 的情況下會爆出異常。 4.2 據我周圍用過MongoDB的朋友說，其MapReduce效能並不是十分顯著，但用得好的話，有可提升的空間。 4.3 近期發生MongoDB黑客贖金事件，原因是MongoDB在訪問控制方面無強性要求，一些公司部署產品時採取較低訪問控制權限。 5.以上三款NOSQL均還有很多引數設定、效能調優方面的技術，因時間有限，我也只是簡單的接觸瞭解了一下它們。 參考文章：
如圖為CouchDB特性，提前建立好的一個view，統計某key的對應value總值，查詢走HTTP協議。
3.MVCC（Multiversion concurrency control） MongoDB 與 CouchDB 的一大區別就是CouchDB 是一個MVCC的系統，而MongoDB是一個update-in-place 的系統。這二者的區別就是，MongoDB 進行寫操作時都是即時完成寫操作，寫操作成功則資料就寫成功了，而CouchDB 一個支援多版本控制的系統，此類系統通常支援多個結點寫，而系統會檢測到多個系統的寫操作之間的衝突並以一定的演算法規則予以解決。 如圖為CouchDB一個文件示例：
4.原子性 這一點上兩者比較一致，都支援針對行的原子性修改（concurrent modifications of single documents），但不支援更多的複雜事務操作。 5.與Java的結合 二.適用場景
三.寫入效率、統計效率 1.環境： WIN10_64位、Inter(R) Core(TM) i5-5200U CPU記憶體、8G、MongoDB v3.4.1、CouchDB v2.0.0 2.效率比對圖表（單位毫秒）： 2.1 1672074條資料，統計各PID欄位總條數
2.2 迴圈插入1000條資料
2.3 插入1條資料
3.具體資料：
3.1 資料量1672074
MONGO GROUP cost time 6661
{_id=7015, count=12004}
{_id=7010, count=4077}
{_id=7014, count=20404}
{_id=7031, count=53442}
{_id=7029, count=39453}
{_id=7016, count=43708}
{_id=7002, count=78437}
{_id=7009, count=51115}
{_id=7022, count=75554}
{_id=7032, count=23804}
{_id=7017, count=24791}
{_id=7011, count=79232}
{_id=7026, count=49568}
{_id=7001, count=74835}
{_id=7006, count=79027}
{_id=7013, count=22861}
{_id=7019, count=69726}
{_id=7020, count=34524}
{_id=7004, count=79534}
{_id=7025, count=75704}
{_id=7018, count=78738}
{_id=7005, count=58337}
{_id=7008, count=28611}
{_id=7023, count=75753}
{_id=7027, count=24222}
{_id=7012, count=48597}
{_id=7007, count=66951}
{_id=7024, count=74812}
{_id=7003, count=72993}
{_id=7021, count=78363}
{_id=7028, count=72897}
COUCHDB GROUP cost time 669
{"rows":[
{"key":7001,"value":74835},
{"key":7002,"value":78437},
{"key":7003,"value":72993},
{"key":7004,"value":79534},
{"key":7005,"value":58337},
{"key":7006,"value":79027},
{"key":7007,"value":66951},
{"key":7008,"value":28611},
{"key":7009,"value":51115},
{"key":7010,"value":4077},
{"key":7011,"value":79232},
{"key":7012,"value":48597},
{"key":7013,"value":22861},
{"key":7014,"value":20404},
{"key":7015,"value":12004},
{"key":7016,"value":43708},
{"key":7017,"value":24791},
{"key":7018,"value":78738},
{"key":7019,"value":69726},
{"key":7020,"value":34524},
{"key":7021,"value":78363},
{"key":7022,"value":75554},
{"key":7023,"value":75753},
{"key":7024,"value":74812},
{"key":7025,"value":75704},
{"key":7026,"value":49568},
{"key":7027,"value":24222},
{"key":7028,"value":72897},
{"key":7029,"value":39453},
{"key":7031,"value":53442},
{"key":7032,"value":23804}
]}
3.2 插入1000條資料
MONGO LOOP INSERT ONE DATA cost time 699
COUCHDB LOOP INSERT ONE DATA cost time 414523.3 插入1條資料 MONGO INSERT ONE DATA cost time 118
COUCHDB INSERT ONE DATA cost time 385 四.關於另一個NOSQL——CouchBase 我在win10上安裝CouchBase無法成功，在CentOS安裝成功，版本4.5.0-2601 Community Edition (build-2601) 以下列出我近期對CouchBase的一些學習內容：
1.CouchBase與CouchDB一樣，也可在WEB端管控資料。 2.CouchBase支援N1QL (一種類似SQL的用於JSON的查詢語言) 3.簡而言之，CouchBase = CouchDB + MemBase 但是，CouchBase並非CouchDB的新版本，相反，它實際上是MemBase的新版本。CouchBase Server實際上是MemBase Server的新名字 4.與CouchDB類似，使用MapReduce功能，要先建立view，在view裡寫MapReduce。我建立的查詢pid出現次數的view結果如下(查詢速度很快)：
我在bucket(CouchBase中的“庫”概念)已匯入了167W多的資料，但圖中的values值偏差很大，查資料猜測可能是“延後寫入”功能，我至今還不知道怎麼解決。 5.Java對其的支援有com.couchbase.client-java-client，用它呼叫CouchBase進行資料插入，迴圈單插1000條資料，花費2215毫秒，插入1條花費169毫秒。 五.其它 1.從這幾天研究來看，在CentOS系統上安裝MongoDB較容易，但CouchDB安裝時較多坑，CouchDB依賴於ErLang語言，我編譯安裝時遇到Erlang的crypto模組與openssl動態連結庫不相容的問題，至今還未解決，所以轉而到WIN上進行學習、測試。 2.批量匯入資料 2.1 MongoDB匯入批量資料很方便 使用命令mongoimport -d 資料庫名 -c 文件名 檔案路徑/檔名json.txt json.txt內容形如： {"c1":"v1","c2":"v2"} {"c1":"v11","c2":"v22"} 2.2 CouchDB匯入批量資料，我還沒搞清楚怎麼操作，上文中的170W條資料，我用自己寫的Java程式碼，從MongoDB源取出批量資料的list，再遍歷list，一次次傳送POST請求，迴圈匯入到CouchDB，耗時15小時。 2.3 CouchBase有官方提供的批量匯入Json檔案工具，需將每個Json存成單獨的一個檔案，將這些批量檔案按規範壓縮。170W個Json檔案，我的機器沒法跑出來，於是我採用的方式是將MongoDB裡查出的170W的list，迴圈遍歷存入CouchBase，使用com.couchbase.client-java-client，耗時20分鐘。 3.上文中的Group測試，對於MongoDB，我使用的是aggregate，指令碼即 db.playerData.aggregate([{$group:{_id:"$pid",num:{$sum:1}}}]);
耗時6661毫秒，小於使用MapReduce的情景，MapReduce的效果如圖：
4.關於MongoDB的group與MapReduce的一些整理如下： 4.1 不要用 group是因為它返回的list記憶體值,在查詢結果條數大 10000 keys 的情況下會爆出異常。 4.2 據我周圍用過MongoDB的朋友說，其MapReduce效能並不是十分顯著，但用得好的話，有可提升的空間。 4.3 近期發生MongoDB黑客贖金事件，原因是MongoDB在訪問控制方面無強性要求，一些公司部署產品時採取較低訪問控制權限。 5.以上三款NOSQL均還有很多引數設定、效能調優方面的技術，因時間有限，我也只是簡單的接觸瞭解了一下它們。 參考文章：