1 壓縮
壓縮操作是通過從數據庫或者視圖索引文件中移除無用的和老的數據減少硬盤使用空間.操作非常簡單類似於其他數據庫(SQLite等)管理系統。
在壓縮目標期間，CouchDB將創建擴展名為.compact的新文件，並將僅實際數據傳輸到該文件中。 因此，CouchDB首先檢查可用磁盤空間-它應比壓縮文件的數據大兩倍。
當所有實際數據都成功傳輸到壓縮文件后，CouchDB用目標文件替換目標文件。
1.1 數據庫壓縮
數據庫壓縮通過刪除更新期間創建的未使用的文件部分來壓縮數據庫文件。 舊文檔修訂版被少量稱為tombstone的元數據代替，該元數據用於復制期間的沖突解決。 可以使用_revs_limitURL配置存儲的修訂版本（以及tombstone）的數量。
壓縮是每個數據庫手動觸發的操作，並作為后台任務運行。要針對特定的數據庫啟動它，需要發送目標數據庫的HTTP POST/{db}/_compact子資源：
curl -H "Content-Type: application/json" -X POST http://localhost:5984/my_db/_compact
成功的話，將立即返回HTTP 狀態碼202 Accepted。
HTTP/1.1 202 Accepted
Cache-Control: must-revalidate Content-Length: 12
Content-Type: text/plain; charset=utf-8 Date: Wed, 19 Jun 2013 09:43:52 GMT Server: CouchDB (Erlang/OTP)
{"ok":true}
盡管未使用請求主體，但仍必須為請求指定帶有application/json值的Content-Type標頭。否則，您會知道HTTP狀態415不支持的媒體類型響應：
HTTP/1.1 415 Unsupported Media Type
Cache-Control: must-revalidate
Content-Length: 78
Content-Type: application/json
Date: Wed, 19 Jun 2013 09:43:44 GMT
Server: CouchDB (Erlang/OTP)
{"error":"bad_content_type","reason":"Content-Type must be application/json"}
當壓縮成功啟動並運行時，可以通過數據庫信息資源獲取有關壓縮的信息：
curl http://localhost:5984/my_db
HTTP/1.1 200 OK
Cache-Control: must-revalidate
Content-Length: 246
Content-Type: application/json
Date: Wed, 19 Jun 2013 16:51:20 GMT
Server: CouchDB (Erlang/OTP)
{
"committed_update_seq": 76215,
"compact_running": true,
"data_size": 3787996,
"db_name": "my_db",
"disk_format_version": 6,
"disk_size": 17703025,
"doc_count": 5091,
"doc_del_count": 0,
"instance_start_time": "0",
"purge_seq": 0,
"update_seq": 76215
}
請注意，compaction_running字段為true，指示壓縮實際上正在運行。 要跟蹤壓縮進度，可以查詢_active_tasks資源：
curl http://localhost:5984/_active_tasks
HTTP/1.1 200 OK
Cache-Control: must-revalidate
Content-Length: 175
Content-Type: application/json
Date: Wed, 19 Jun 2013 16:27:23 GMT
Server: CouchDB (Erlang/OTP)
[
{
"changes_done": 44461,
"database": "my_db",
"pid": "<0.218.0>",
"progress": 58,
"started_on": 1371659228,
"total_changes": 76215,
"type": "database_compaction",
"updated_on": 1371659241
}
]
1.2 視圖壓縮
與數據庫視圖不同，視圖也需要像數據庫一樣進行壓縮，這與按每個設計文檔按組對數據庫視圖進行壓縮不同。要啟動其壓縮，需要發送HTTP POST/{db}/_compact/{ddoc}請求：
curl -H "Content-Type: application/json" -X POST http://localhost:5984/dbname/_compact/designname
{"ok":true}
這將從指定設計文檔的當前版本壓縮視圖索引。 HTTP響應代碼202 Accepted(類似於數據庫的壓縮)，並且將創建壓縮后台任務。
1.2.1視圖清理
磁盤上的視圖索引以視圖定義的MD5哈希命名。更改視圖時，舊索引仍保留在磁盤上。要清除所有過時的視圖索引（以視圖的MD5表示形式命名的文件，該文件不再存在），可以觸發視圖清除：
curl -H "Content-Type: application/json" -X POST http://localhost:5984/dbname/_view_cleanup
{"ok":true}
1.3 自動壓縮
雖然需要手動觸發數據庫和視圖的壓縮，但也可以配置自動壓縮，以便基於各種條件自動觸發數據庫和視圖的壓縮。 在CouchDB的配置文件中配置了自動壓縮。
守護程序/compaction_daemon負責觸發壓縮。 默認情況下啟用它並自動啟動。在壓縮部分中配置了觸發壓縮的條件。
2 性能
無論您如何編寫代碼，即使有了成千上萬的文檔，通常都會發現CouchDB可以很好地執行。但是一旦開始閱讀數百萬個文檔，您需要更加小心。
2.1 硬盤IO
2.1.1 文件大小
文件大小越小，I/O操作將越少，CouchDB和操作系統可以緩存的文件越多，復制，備份等的速度就越快。因此，您應該仔細檢查所要存儲的數據儲存。例如，使用長度為數百個字符的鍵會很愚蠢，但是如果僅使用單個字符鍵，則程序將很難維護。通過將其放在視圖中來仔細考慮重復的數據。
2.1.2 硬盤和文件系統性能
使用更快的磁盤，條帶化RAID陣列和現代文件系統都可以加快CouchDB部署。但是，當磁盤性能成為瓶頸時，有一種方法可以提高CouchDB服務器的響應速度。 從文件模塊的Erlang文檔中：
在具有線程支持的操作系統上，可以讓文件操作在其自己的線程中執行，從而允許其他Erlang進程繼續與文件操作並行執行。 請參閱erl(1)中的命令行標志+A。
將此參數設置為大於零的數字可以使您的CouchDB安裝保持響應狀態，即使在磁盤使用率很高的時期也是如此。設置此選項的最簡單方法是通過ERL_FLAGS環境變量。例如，要為Erlang提供執行I/O操作的四個線程，請將以下內容添加到(prefix)/etc/defaults/couchdb（或等效項）中：
export ERL_FLAGS="+A 4"
2.2 系統資源限制
管理員在其部署變大時會遇到的問題之一是系統和應用程序配置施加的資源限制。 提高這些限制可以使您的部署超出默認配置所支持的范圍。
2.2.1 CouchDB配置選項
delayed_commits
延遲的提交允許在某些工作負載下實現更好的寫入性能，同時犧牲少量的持久性。 該設置使CouchDB在更新后提交新數據之前要等待一整秒。如果服務器在寫入標頭之前崩潰，則自上次提交以來的所有寫入都將丟失。 啟用此選項需要您自擔風險。
max_dbs_open
在配置(local.ini或類似版本)中,或者地址couchdb/max_dbs_open：
[couchdb]
max_dbs_open = 100
此選項將一次可以打開的數據庫數量設置為上限。CouchDB引用對內部數據庫訪問進行計數，並在必要時關閉空閑數據庫。有時有必要一次保持超過默認值的速度，例如在許多數據庫將被連續復制的部署中。
Erlang
即使增加了CouchDB允許的最大連接數，默認情況下，Erlang運行時系統也將不允許超過1024個連接。 將以下指令添加到(prefix)/etc/default/couchdb(或等效文件)將增加此限制(在這種情況下，增加到4096)：
export ERL_MAX_PORTS=4096
高達1.1.x的CouchDB版本還會為每個復制創建Erlang Term Storage(ETS)表。如果您使用的CouchDB版本早於1.2，並且必須支持許多復制，則還應設置ERL_MAX_ETS_TABLES變量。 默認值是大約1400表。
請注意，在Mac OS X上，Erlang實際上不會將文件描述符限制增加到超過1024（即系統標頭定義的FD_SETSIZE值）。
打開文件描述的最大數量(無限制)
大多數*nix操作系統在每個進程上都有各種資源限制。增加這些限制的方法因初始化系統和特定的OS版本而異。許多操作系統的默認值為1024或4096。在具有許多數據庫或視圖的系統上，CouchDB可以非常迅速地達到此限制。
如果您的系統設置為使用可插拔身份驗證模塊(PAM)系統（幾乎所有現代Linux都是這種情況），則增加此限制很簡單。例如，創建具有以下內容的名為/etc/security/limits.d/100-couchdb.conf的文件將確保CouchDB可以一次打開多達10000個文件描述符：
#<domain> <type> <item> <value>
couchdb hard nofile 10000
couchdb soft nofile 10000
如果使用的是Debian/Ubuntu sysvinit腳本(/etc/init.d/couchdb，則還需要提高root用戶的限制：
#<domain> <type> <item> <value>
root hard nofile 10000
root soft nofile 10000
您可能還需要編輯/etc/pam.d/common-session和/etc/pam.d/common-session-noninteractive文件以添加以下行：
session required pam_limits.so
如果還不存在。
對於基於系統的Linux（例如CentOS/RHEL 7，Ubuntu 16.04 +，Debian 8或更高版本）,假設您要從systemd啟動CouchDB，則還必須通過創建文件/etc/systemd/system/<servicename>.d/override.conf添加以下內容：
[Service]
LimitNOFILE=#######
並將#######替換為文件描述符的上限CouchDB允許立即保持打開狀態。
如果您的系統不使用PAM，通常可以在自定義腳本中使用ulimit命令來啟動
CouchDB具有增加的資源限制。 典型的語法類似於ulimit -n 10000。
通常，類似UNIX的現代系統每個進程可以處理大量文件句柄（例如100000）
沒有問題。 不要害怕增加系統限制。
2.3 網絡
產生和接收每個請求/響應都有延遲開銷。通常，您應該分批執行請求。大多數API具有某種批處理機制，通常是通過在請求正文中提供文檔或鍵的列表來進行的。請注意為批次選擇的大小。較大的批處理需要更多的時間來使客戶將項目編碼為 JSON，並將更多的時間用於解碼該數量的響應。使用您自己的配置和典型數據進行一些基准測試，以找到最佳位置。 它可能在一到一萬個文檔之間。
如果您擁有快速的I/O系統，那么您也可以使用並發-同時具有多個請求/響應。這減輕了組裝JSON，進行網絡連接和解碼JSON所涉及的延遲。
從CouchDB 1.1.0開始，與舊版本相比，用戶經常報告文檔的寫入性能較低。主要原因是此版本隨附HTTP服務器庫MochiWeb的最新版本，該庫默認情況下將TCP套接字選項SO_NODELAY設置為false。這意味着發送到TCP套接字的小數據（例如對文檔寫請求的答復（或讀取非常小的文檔）的答復）不會立即發送到網絡TCP將對其緩沖一會兒，希望它會被詢問通過同一套接字發送更多數據，然后一次發送所有數據以提高性能。 可以通過httpd/socket_options禁用此TCP緩沖行為：
[httpd]
socket_options = [{nodelay, true}]
2.3.1 連接限制
MochiWeb處理CouchDB請求。默認最大連接數為2048。要更改此限制，請使用server_options配置變量。 max表示最大連接數。
[chttpd]
server_options = [{backlog, 128}, {acceptor_pool_size, 16}, {max, 4096}]
2.4 CouchDB
2.4.1 刪除操作
當您刪除文檔時，數據庫將創建一個新的修訂版，其中包含_id和_rev字段以及_deleted標志。即使在數據庫壓縮后，此修訂版仍將保留，以便可以復制刪除內容。像未刪除的文檔一樣，已刪除的文檔可能會影響視圖生成時間，PUT和DELETE請求時間以及數據庫的大小，因為它們會增加B+Tree的大小。您可以在數據庫信息中看到已刪除文檔的數量。如果您的用例創建了許多已刪除的文檔（例如，如果您存儲日志條目，消息隊列等短期數據），則可能需要定期切換到新數據庫並刪除已過期的舊數據庫）。
2.4.2 文檔ID
數據庫文件的大小源自您的文檔和視圖大小，但也取決於您的_id大小的倍數。_id不僅存在於文檔中，而且它及其部分內容在CouchDB用來導航文件以首先找到文檔的二叉樹結構中也是重復的。作為一個現實世界的例子，一個用戶從16個字節的ID切換到4個字節的ID，使數據庫從21GB變為4GB，包含1000萬個文檔（從2.5GB到2GB的原始JSON文本）。
插入具有順序（至少已排序）的ID的速度要比隨機ID快。 因此，您應該考慮自己生成id，按順序分配它們，並使用消耗更少字節的編碼方案。例如，可以用4個基數62個數字（用10個數字，26個小寫字母，26個大寫字母）來完成需要16個十六進制數字表示的內容。
2.5 視圖
2.5.1 視圖生成
當要處理的文檔數量非常少時，使用JavaScript查詢服務器生成的視圖非常慢。生成過程甚至不會使單個CPU飽和，更不用說您的I/O了。原因是CouchDB服務器和單獨的couchjs查詢服務器中涉及的延遲，這顯着表明了從實施中消除延遲的重要性。
您可以讓視圖訪問權限“過時”，但要確定何時發生會給您帶來快速響應以及何時更新視圖會花費很長時間，這是不切實際的。(一個擁有1000萬個文檔的數據庫大約需要10分鍾才能加載到CouchDB中，而生成視圖需要大約4個小時)。
在集群中，“陳舊的”請求由一組固定的分片服務，以便為用戶提供請求之間的一致結果。這需要進行可用性權衡-固定的分片集可能不是集群中響應最快的/可用的。如果不需要這種一致性(例如，索引相對靜態)，則可以通過指定stable = false＆update = false代替stale = ok或stable = false＆update = lazy代替stale = update_after。
視圖信息不會被復制-它會在每個數據庫上重建，因此您無法在單獨的服務器上生成視圖。
2.5.2 內置縮小功能
如果您使用的是非常簡單的視圖函數，僅執行求和或計數減少，則可以通過簡單地編寫_sum或_count代替函數聲明來調用它們的本機Erlang實現。 這將大大加快速度，因為它減少了CouchDB和JavaScript查詢服務器之間的IO。 例如，如郵件列表中所述，用於輸出（已索引和緩存的）視圖的時間大約為78,000個項目，時間從60秒減少到4秒。
之前：
{
"_id": "_design/foo",
"views": {
"bar": {
"map": "function (doc) { emit(doc.author, 1); }",
"reduce": "function (keys, values, rereduce) { return sum(values); }"
}
}
}
之后：
{
"_id": "_design/foo",
"views": {
"bar": {
"map": "function (doc) { emit(doc.author, 1); }",
"reduce": "_sum"
}
}
}
3 CouchDB備份
CouchDB在運行時可以創建三種不同類型的文件：
- 數據庫文件（包括二級索引）
- 配置文件(
* .ini) - 日志文件（如果配置為記錄到磁盤）
以下是確保所有這些文件的備份一致的策略。
3.1 數據庫備份
CouchDB備份的最簡單，最簡單的方法是使用CouchDB復制到另一個CouchDB安裝。您可以根據需要在普通（單次）復制或連續復制之間進行選擇。
但是，您也可以隨時從CouchDB數據目錄(默認為data/)中復制實際的.couch文件，而不會出現問題。 CouchDB的數據庫和二級索引的僅追加存儲格式可確保這種方法可以正常工作。
為了確保備份的可靠性，建議先備份二級索引(存儲在data/.shards下)，然后再備份主數據庫文件(存儲在data/ shards以及父級data/下的系統級數據庫)目錄)。這是因為CouchDB將在下一次讀取訪問時通過更新視圖/二級索引來自動處理稍微過時的視圖/二級索引，但是比其關聯數據庫新的視圖或二級索引將觸發索引的完全重建。這可能是一項非常昂貴且耗時的操作，並且會影響您在災難情況下快速恢復的能力。
在受支持的操作系統/存儲環境上，您還可以使用存儲快照。這些優點是在使用塊存儲系統(例如ZFS或LVM或Amazon EBS)時幾乎是即時的。在塊存儲級別使用快照時，請確保在必要時使用OS級實用程序(例如Linux的fsfreeze)使文件系統停頓。如果不確定，請查閱操作系統或雲提供商的文檔以獲取更多詳細信息。
3.2 配置備份
CouchDB的配置系統將數據存儲在配置目錄(默認為etc/)下的.ini文件中。 如果在運行時對配置進行了更改，則配置鏈中的最后一個文件將使用更改進行更新。
從備份還原后，簡單地備份整個etc/目錄，以確保配置一致。
如果在運行時未通過HTTP API對配置進行任何更改，並且所有配置文件都由配置管理系統(例如Ansible或Chef)管理，則無需備份配置目錄。
3.3 日志備份
如果配置為記錄到文件，則可能要備份CouchDB編寫的日志文件。這些文件的任何備份解決方案都可以使用。
在類似UNIX的系統上，如果使用日志輪換軟件，則必須采用“復制然后截斷”的方法。創建副本后，這會將原始日志文件截斷為零。CouchDB無法識別要關閉其日志文件並創建一個新信號的任何信號。因此，並且由於文件處理功能的差異，除了定期重新啟動CouchDB進程外，在Microsoft Windows下沒有簡單的日志輪換解決方案。