隨機操作的低CouchDB性能

Question

我使用YCSB基準測試工具對Couchdb和Mongodb的性能進行基準測試。不幸的是，似乎我做錯了什麼，因爲在單一的，隨機操作的性能差異是巨大的：

工作量（50/50讀/更新），16個線程的查詢，120秒的運行時間（結果非常相似與20分鐘運行時）：

CouchDB的1.6.1：總體吞吐量：1076操作/秒，的13毫秒第99百分位的讀延遲，13毫秒

的MongoDB 3.0.6的第99百分位的更新等待時間：總體吞吐量： 11203 ops/sec，第99百分位讀取延遲1ms，第99百分位更新延遲爲1ms

正如您所看到的，CouchDB對於隨機讀取和更新非常緩慢。文檔建議使用批量操作，對於插入操作可能沒問題，但是我沒有看到我如何實現批量讀取，因爲YCSB正在逐一請求讀取。

測試環境：

• Ubuntu的14.04 64位上的虛框與VT-d的i7的主機上啓用，2個核心，2GB RAM（雖然我得到與專用機相似的結果）
• 工作組/ DB容易在RAM適合
• 本地主機服務器，沒有硬件的網絡等待時間（結果是一個硬件羣集上類似）是應該改善的CouchDB文件中所提及的性能
• 一切，尤其是針對simplejson的HTTPD選項和C-extensions已正確設置
• couchdb驅動程序由我使用CouchDB網站上推薦的Ektorp持久性API編寫。代碼很簡單，我爲其他數據庫系統編寫的驅動程序可以正常工作。

我試圖提高吞吐量：

• 使用批量插入用於裝載階段。這使得CouchDB快了很多，但仍然比MongoDB慢7倍，這與使用相同CouchDB版本的發佈的here基準一致。

對CouchDB的緩慢可能的解釋：

• 更新必須通過請求文件，修改並重新提交它的數據庫，這是造成高延遲來完成。然而，這並不能解釋低讀取吞吐量

問題：您是否看到任何其他改進CouchDB性能的方法？

編輯：在couchdb中Delayed_commit設置爲true，所以我開始懷疑強制fsync是原因。

Answer 1

這裏的答案很簡單：CouchDB的確保所有寫操作都是與命中的fsync（）調用磁盤時，MongoDB中允許保留在內存中了一會兒，告訴你，一切都很好。直到下一次意外關機時丟失數據。 RAM-vs-disk是它們之間的主要性能因素。

下一頁進入協議：HTTP是文本，而MongoDB使用自己的二進制之一。無需告知，二進制協議更加緊湊和高效。

但這裏的主要問題是，你的基準是合成的。您假設您的數據庫用於傻讀寫，就像數據提包一樣，而數據庫則用於更復雜的操作，如查詢，索引查找，連接，數據驗證等。這裏的業務邏輯很重要。

爲了更真實的標杆，你應該採取一些應用程序，並使其與這兩個數據庫，並與他們的基準業務流程的工作，而不是盲目的讀/寫。很確定，你的數字將被平衡，因爲業務邏輯比任何數據庫都慢得多。

所以我說你浪費在這個時候後悔。