我最近遇到了一個情況，我的CouchDB實例使用了20GB VM實例上的所有可用磁盤空間。 經過調查，我發現/ usr/local/var/lib/couchdb /中的一個目錄包含一堆.view文件，其中最大的是16GB。我能夠刪除* .view文件來恢復正常操作。我不確定爲什麼.view文件變得如此之大以及CouchDB如何管理.view文件。CouchDB .view文件越來越失控？
更多信息。我有一臺運行Ubuntu 9.10（karmic）的虛擬機，512MB和CouchDB 0.10。 VM有一個cron作業，它調用查詢視圖的Python腳本。 cron作業每五分鐘運行一次。每次查看視圖時，.view文件的大小都會增加。我已經寫了一份工作，每小時監測一次，幾天之後，我沒有看到文件翻滾或其他尺寸減小。
有沒有人對這個問題有任何見解？有沒有我錯過的文檔？我一直無法找到有關該主題的任何內容，但這可能是由於查找了錯誤的地方或搜索條件。
CouchDB非常餓，交易磁盤空間的性能。隨着項目添加到視圖中，視圖的大小會增加。您可以通過清理和壓縮來恢復不再需要的磁盤空間。
每次創建更新或刪除文檔時，視圖索引都會隨文檔的相關更改而更新。在查詢時會發生對視圖的更新。因此，如果您正在進行大量文檔更改，那麼您應該期望索引增長，並且需要通過壓縮和清理進行管理。
如果您的意見對於給定的文檔集非常大，那麼您的設計視圖可能會很差。或者，您的設計可能只需要較大的視圖，您需要像管理其他任何資源一樣管理它。
如果您可以描述正在發生的文檔更新（包括創建和刪除）以及您的視圖功能發出什麼，尤其是對於大視圖，那麼可以更容易地說出發生了什麼。
您的.view文件不斷增加，每次訪問視圖都是因爲CouchDB更新訪問視圖。 CouchDB視圖也需要像數據庫一樣的壓縮。如果您經常對文檔進行更改，導致視圖發生更改，則應不時運行視圖壓縮。請參閱http://wiki.apache.org/couchdb/HTTP_view_API#View_Compaction
要縮小視圖的大小，請查看所發佈的數據。當您發出（foo，doc）時，整個文檔將被複制到視圖中，以便在查詢視圖時立即可用。函數（doc）{emit（doc.title，doc）; }將導致與數據庫本身一樣大的視圖。你也可以發出（doc.title，nil）;並使用include_docs選項讓CouchDB在訪問視圖時從數據庫中提取文檔（這會導致性能降低）。見http://wiki.apache.org/couchdb/HTTP_view_API#Querying_Options
使用順序或單調的ID對文檔而不是隨機
是，CouchDB的很盤餓了，它需要定期compactions。但還有一件事可以幫助減少這種磁盤使用情況，特別是有時在沒有必要時。
Couchdb使用B +樹來存儲數據/文檔，這是非常好的數據結構，用於執行數據檢索。但是，在性能上使用B樹進行磁盤空間使用。隨着完全隨機的ID，B +樹扇子很快就會出來。由於每個內部節點的最小填充率爲1/2，所以節點大部分被填充到1/2（因爲數據因其隨機性而均勻分佈）產生更多的內部節點。另外新插入可能會導致完整樹的重寫。這就是隨機性的原因;）
相反，使用sequential or monotonic ID可以避免所有。
我也遇到過這個問題，試用一個基於瀏覽器的遊戲的CouchDB。
在網站發佈的第一天，我們有大約100.000個意外訪問者，並且在2天內，CouchDB數據庫在空間上佔用了大約40GB。這使得服務器崩潰，因爲HD完全滿了。
壓實帶來了回到約50MB。我還將_revs_limit（默認爲1000）設置爲10，因爲我們不關心修訂歷史記錄，並且從此開始運行得很完美。幾乎1M用戶後，數據庫的大小通常爲2-3GB左右。當我運行壓縮它大約500MB。
設置文件修改限制到10：
curl -X PUT -d "10" http://dbuser:[email protected]:5984/yourdb/_revs_limit
或不通過用戶名：密碼（不推薦）：
curl -X PUT -d "10" http://127.0.0.1:5984/yourdb/_revs_limit
文件都很大，對文檔的更改是顯著。這一切都有道理。謝謝您的回答。但是CouchDB本身沒有清理？或者這是留給管理員的？似乎破碎或我錯過了什麼？ – 2010-08-18 02:03:06
CouchDB要求您運行壓縮來恢復磁盤空間。什麼時候可以完成，高度依賴於你的環境。通常，當服務器上的負載較低時，您可以執行此操作，並使用cron作業觸發它。如果您有任何副本，您還應該瞭解它如何影響複製。 – Kerr 2010-08-18 09:42:00
我不同意「如果你的觀點對於一套給定的文件來說非常大，那麼你的設計意見可能會很差」。 「可能」在那裏，但作者應該強調，對於應用來說，一個小視角不一定是一個快速的。例如。像'？include_docs'這樣的op是非常激烈的，這使得在視圖中包含完整的文檔是必要的。這再次是CouchDB交易磁盤空間以提高性能的地方。 – Till 2011-05-08 19:02:54