5.1. 压实¶

这个 compaction operation is a way to reduce disk space usage by removing unused and old data from database or view index files. This operation is very similar to the vacuum (SQLite 例如)可用于其他数据库管理系统的操作。

在压缩过程中，CouchDB在新文件中重新创建数据库或视图 .compact 分机。因为这需要大约两倍的磁盘存储，所以CouchDB在继续之前首先检查可用的磁盘空间。

当所有实际数据都成功传输到新压缩的文件时，CouchDB透明地将压缩的文件交换到服务中，并删除旧的数据库或视图文件。

从CouchDB 2.1.1开始，自动压缩在默认情况下处于启用状态，下一节将对此进行介绍。如果需要或必要，仍然可以触发手动压实。这将在后续各节中介绍。

5.1.1. 自动压实¶

CouchDB的自动压缩守护进程（内部称为“smoosh”）将根据文件稀疏性和可恢复空间总量的可配置阈值触发数据库和视图的压缩作业。

5.1.1.1. 渠道¶

Smoosh使用通道的概念。通道本质上是一个等待压缩的队列。数据库和视图有单独的活动通道集。每个通道都分配了一个配置，该配置定义了压缩是否结束于通道的队列中，以及如何在该队列中对压缩进行优先级排序。

Smoosh获取每个通道，并按优先级顺序处理排队的压缩。每个通道都是并行处理的，因此优先级只在给定的通道中起作用。每个通道都有一个指定的活动压缩数，这定义了该通道并行发生的压缩数。例如，一个有大量数据库混乱但视图很少的集群可能需要在数据库通道中进行更活跃的压缩。

必须记住，通道是CouchDB节点的本地通道；也就是说，每个节点维护和处理一组独立的压缩。信道被定义为“比率”信道或“空闲”信道，这取决于用于优先级划分的算法类型：

比率：使用size.file文件/ 大小。活动作为驱动计算。结果X必须大于某个可配置值Y，才能将压缩添加到队列中。然后，对于更高的X值，对压缩进行优先排序。
Slack：使用size.file文件- 大小。活动作为驱动计算。结果X必须大于某个可配置值Y，才能将压缩添加到队列中。压缩优先考虑X的较高值。

在这两种情况下，Y都是使用 min_priority 配置变量。CouchDB附带了四个预先配置的通道：每种类型的一个通道用于数据库，另一个通道用于视图。

5.1.1.2. 信道配置¶

通道使用以下方式定义 [smoosh.<channel_name>] 配置块，并通过在 db_channels 或 view_channels 中的配置设置 [smoosh] 挡路。默认配置为

[smoosh]
db_channels = upgrade_dbs,ratio_dbs,slack_dbs
view_channels = upgrade_views,ratio_views,slack_views

[smoosh.ratio_dbs]
priority = ratio
min_priority = 2.0

[smoosh.ratio_views]
priority = ratio
min_priority = 2.0

[smoosh.slack_dbs]
priority = slack
min_priority = 536870912

[smoosh.slack_views]
priority = slack
min_priority = 536870912

“升级”通道是一对特殊通道，只检查 disk_format_version 因为文件与当前版本匹配，如果不是这样的话，请将文件排队进行压缩（这有升级文件格式的副作用）。可以为每个通道配置多个附加属性；这些属性记录在 configuration API

5.1.1.3. 计划窗口¶

只能在每天特定的压缩时间内配置通道运行。特定于频道 from ， to 和 strict_window 配置设置控制此行为。例如

[smoosh.overnight_channel]
from = 20:00
to = 06:00
strict_window = true

在哪里？ overnight_channel 要配置的频道的名称。

注意：CouchDB通过UTC（GMT）时区确定时间，因此这些设置必须表示为UTC（GMT）。

这个 strict_window 设置将导致压缩守护程序在退出窗口时挂起此通道中的所有活动压缩，并在重新进入时恢复它们。如果 strict_window 保留其缺省值False，则将允许完成活动压缩，但不会启动新的压缩。

5.1.1.4. 迁徙指南¶

CouchDB的早期版本附带了一个更简单的压缩守护进程。新守护进程的配置系统与旧守护进程不向后兼容，因此具有自定义压缩配置的用户需要将它们移植到新的设置中。旧守护进程的压缩规则配置如下所示

[compaction_daemon]
min_file_size = 131072
check_interval = 3600
snooze_period_ms = 3000

[compactions]
mydb = [{db_fragmentation, "70%"}, {view_fragmentation, "60%"}, {parallel_view_compaction, true}]
_default = [{db_fragmentation, "50%"}, {view_fragmentation, "55%"}, {from, "20:00"}, {to, "06:00"}, {strict_window, true}]

这种配置的许多元素可以移植到新系统中。详细检查：

min_file_size 现在使用最小大小配置设置按每个通道配置。
db_fragmentation 相当于配置priority=ratio通道，将min_priority设置为1.0/（1-db_fragmentation/100），然后在 [烟雾] 数据库通道配置设置。
view_fragmention 同样相当于配置priority=ratio通道，将min_priority设置为1.0/（1-view_fragmentation/100），然后在 [烟雾] 查看频道配置设置。
from / to / strict_window ：这些设置中的每个设置都可以在新守护程序中按每个通道应用。一个行为变化是，新的守护进程将在退出允许的窗口时暂停压缩，而不是直接取消它们，并在重新进入时恢复它们。
parallel_view_compaction ：每个压缩通道都有一个并发设置，用于控制在该通道中并行执行的压缩数。总并行度是所有活动通道的并发设置之和。这与以前的行为不同，在以前的行为中，守护进程一次只关注一个数据库和/或它的视图（取决于此标志的值）。

这个 check_interval 和 snooze_period_ms 在新守护程序的事件驱动设计中，设置已过时。新的守护程序不支持设置特定于数据库的阈值 mydb 设置在上面。相反，可以将通道配置为关注特定的文件类：大型数据库、小型视图索引等。命名数据库压缩规则的大多数情况都可以使用这些数据库的属性和/或它们的关联视图来表示。

5.1.2. 手动数据库压缩¶

数据库压缩通过删除更新期间创建的未使用的文件节来压缩数据库文件。旧文档修订被称为 tombstone which are used for conflicts resolution during replication. The number of stored revisions (and their tombstones) can be configured by using the :get:`_ Revs_Limit</{db}/_Revs_Limit>`URL端点。

压缩可以为每个数据库手动触发，并作为后台任务运行。要为特定的数据库启动它，需要发送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}

虽然未使用请求正文，但仍必须指定 Content-Type 标题与 application/json 请求的值。如果您没有，您将知道HTTP状态 415 Unsupported Media Type 回应：

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"}

当压缩成功启动并运行时，可以通过 database information resource ：：

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,
    "db_name": "my_db",
    "disk_format_version": 6,
    "doc_count": 5091,
    "doc_del_count": 0,
    "instance_start_time": "0",
    "purge_seq": 0,
    "sizes": {
      "active": 3787996,
      "disk": 17703025,
      "external": 4763321
    },
    "update_seq": 76215
}

请注意， compact_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
    }
]

5.1.3. 手动视图压缩¶

Views 也需要压实。与数据库不同，视图是按每个组进行压缩的 design document 。要开始压缩，请发送HTTP :post:`/{{db}}/_compact/{{ddoc}}` 请求：：

curl -H "Content-Type: application/json" -X POST http://localhost:5984/dbname/_compact/designname

{"ok":true}

这将压缩指定设计文档的当前版本中的视图索引。HTTP响应代码是 202 Accepted （像 compaction for databases )并创建压缩后台任务。

5.1.3.1. 视图清理¶

磁盘上的视图索引以 MD5 哈希的定义。更改视图时，旧索引仍保留在磁盘上。要清除所有过时的视图索引（以视图的MD5表示形式命名的文件，该文件已不存在），可以触发 view cleanup ：：

curl -H "Content-Type: application/json" -X POST http://localhost:5984/dbname/_view_cleanup

{"ok":true}