2012-03-15 213 views
2

我處理一些輸入文件和插入獲得記錄作爲 CouchDB的文件。 我注意到插入速度正在遞減,數據庫大小增加了 。迅速減少插入速度CouchDB中

我要做的就是:從輸入文件

  • 處理數據

    1. 讀取數據,以獲得結構化文檔
    2. 把文件在本地緩存
    3. 只要緩衝區有1000文件,執行couchdb批量插入
    4. 重複輸入數據已完全處理

    在這裏,你有我當前運行的日誌:

    2012-03-15 10:15:58,716 - docs= 10000 rate=2282.38 entries/s 
    2012-03-15 10:16:46,748 - docs=100000 rate=1822.76 entries/s 
    2012-03-15 10:17:47,433 - docs=200000 rate=1592.01 entries/s 
    2012-03-15 10:18:48,566 - docs=300000 rate=1358.32 entries/s 
    2012-03-15 10:19:54,637 - docs=400000 rate=1572.55 entries/s 
    2012-03-15 10:21:01,690 - docs=500000 rate=1560.41 entries/s 
    2012-03-15 10:22:09,400 - docs=600000 rate=1556.22 entries/s 
    2012-03-15 10:23:16,153 - docs=700000 rate=1550.21 entries/s 
    2012-03-15 10:24:30,850 - docs=800000 rate=1393.61 entries/s 
    2012-03-15 10:25:46,099 - docs=900000 rate=1336.83 entries/s 
    2012-03-15 10:27:09,290 - docs=1000000 rate= 871.37 entries/s 
    2012-03-15 10:28:31,745 - docs=1100000 rate=1256.36 entries/s 
    2012-03-15 10:29:53,313 - docs=1200000 rate=1140.49 entries/s 
    2012-03-15 10:31:29,207 - docs=1300000 rate=1080.79 entries/s 
    2012-03-15 10:33:23,917 - docs=1400000 rate= 741.65 entries/s 
    2012-03-15 10:35:45,475 - docs=1500000 rate= 567.96 entries/s 
    2012-03-15 10:39:04,293 - docs=1600000 rate= 564.01 entries/s 
    2012-03-15 10:42:20,160 - docs=1700000 rate= 499.29 entries/s 
    2012-03-15 10:46:06,270 - docs=1800000 rate= 505.04 entries/s 
    2012-03-15 10:50:24,745 - docs=1900000 rate= 402.14 entries/s 
    2012-03-15 10:55:23,800 - docs=2000000 rate= 346.19 entries/s 
    2012-03-15 11:02:03,217 - docs=2100000 rate= 274.59 entries/s 
    2012-03-15 11:08:21,690 - docs=2200000 rate= 269.57 entries/s 
    

    的「速度」顯示上次萬份文件,其中 正如你所看到的降解速度非常快的插入速率。

    • 這是正常的嗎?
    • 我可以做一些事情來保持高插入率嗎?
    • 你有大的CouchDB數據庫的經驗。
    • 任何你想分享的建議?
  • 回答

    4

    高插入率是反常,造成的一切整齊地安裝到您的磁盤緩存。隨着數據庫大小的增加,您最終需要從磁盤讀取數據以更新btree。將插入測試延長一段時間並繪製圖形會更好,然後您應該看到,前端的巨大峯值是奇怪的,而不是較低的,但幾乎是恆定的速率。

    從其他線程你問的這個問題,另一個顯著的因素是,你使用完全隨機UUID的。由於CouchDB基於b +樹,因此插入完全隨機的id是更新中最糟糕的情況。 CouchDB提供了許多uuid算法,默認情況下,稱爲'順序'的返回值的碰撞機率很低,仍然足夠順序以提供更好的插入性能。

    +0

    其實,這是更關係到DOC_ID比其訂購的*尺寸*。我已經通過使用非常小的(幾個字符)doc_id解決了這個問題,實際上是一個base64編碼的單調遞增的doc_id。我也使用Erlang有序字典來執行編碼,但這是一個小問題。 – dangonfast 2012-03-19 14:28:19