couchdb 不断增长（文件大小）
couchdb keeps growing (filesize)
我对 CouchDB 在磁盘上的数据库文件大小方面的行为感到非常困惑。似乎我做什么并不重要，数据库文件只会变得越来越大（即使在 deleting/purging 文档或整个数据库上）。
我查看了我的 /var/lib/couchdb/_dbs.couch 文件，它的大小从未减小过。简单示例：
curl -X PUT http://admin:secretpassword@localhost:5984/testdb
_dbs.couch 文件大小增加了 5kb。
curl -X DELETE http://admin:secretpassword@localhost:5984/testdb
文件大小没有变化。即使我对数据库进行过滤复制（过滤掉已删除的文档）或手动触发压缩，磁盘文件大小也不会减少。
现在真正令人困惑的是，Fauxton 实际上显示了这些操作后数据库大小减小，但它从未反映在所使用的物理磁盘空间中。
全新安装后，我使用的几乎是标准配置。
这是"working like intended"还是这里有什么问题？
更重要的是：我能做些什么吗？
它按预期工作，您只是没有查看正确的文件。
每个数据库都有对应的同名文件。
例如：
curl -X PUT http://admin:secretpassword@localhost:5984/testdb
curl -X PUT http://admin:secretpassword@localhost:5984/emaildb
- 由于您有一个 _dbs.couch 文件，您可能正在使用具有分片功能的 CouchDB 2.X.X。
它将在 "shards" 文件夹的子文件夹中创建多个文件。
data/
+-- shards/
| +-- 00000000-7fffffff/
| | -- emaildb.124456678.couch
| | -- testdb.647948447.couch
| +-- 80000000-ffffffff/
| | -- emaildb.124456678.couch
|___|____-- testdb.647948447.couch
更多信息：http://docs.couchdb.org/en/latest/cluster/sharding.html
简而言之，分片和集群功能允许您拥有一个具有分布式 map/reduce 计算的分布式数据库。在上面的示例中，每个 dbs 有 2 个分片，这意味着每个数据库跨越两个文件。创建的每个新文档最终都可能出现在这两个文档之一中。但是磁盘使用不会均匀分布。例如，如果每个文档都是一个小 json 文档，但其中一个文档有 1GB 的附件 (http://docs.couchdb.org/en/latest/intro/api.html#attachments), only one shard will get a 1GB bump. The sharding is doc based. You can have 2 shards, you can have 20, and they don't all have to be on the same server (http://docs.couchdb.org/en/latest/cluster/theory.html)。如果您知道一台服务器没有足够的磁盘 space 来保存您的所有数据，您可以设置 20 个 couchdb 服务器，每个服务器将保存 1 个分片（大约所有文档的 1/20）。无论是地下室的单个节点，还是遍布全球的couchdb服务器集群，对于客户端应用程序（curl、pouchdb、firefox等）来说，都是一样的api.
_dbs 数据库 (_dbs.couch) 记录了每个 dbs 的信息，用于集群和分片管理。它的大小会增加，因为每次您创建和删除数据库时，它都会更新（写时复制）。从 CouchDB 2.1.0 及更高版本开始，它将自动压缩。您可以检查服务器配置中的自动压缩设置。（在浏览器中：http://localhost:5984/_utils/#/_config/, compactions sections). Admin panel is on a different port: http://localhost:5986/_utils
Fauxton 报告的尺码是 "active size"。不计算仍在磁盘上的已删除文档，这些文档将在压缩后删除。 curl http://localhost:5984/testdb 将提供其他信息，例如磁盘大小 (http://docs.couchdb.org/en/latest/api/database/common.html#get--db)。
我对 CouchDB 在磁盘上的数据库文件大小方面的行为感到非常困惑。似乎我做什么并不重要，数据库文件只会变得越来越大（即使在 deleting/purging 文档或整个数据库上）。
我查看了我的 /var/lib/couchdb/_dbs.couch 文件，它的大小从未减小过。简单示例：
curl -X PUT http://admin:secretpassword@localhost:5984/testdb
_dbs.couch 文件大小增加了 5kb。
curl -X DELETE http://admin:secretpassword@localhost:5984/testdb
文件大小没有变化。即使我对数据库进行过滤复制（过滤掉已删除的文档）或手动触发压缩，磁盘文件大小也不会减少。 现在真正令人困惑的是，Fauxton 实际上显示了这些操作后数据库大小减小，但它从未反映在所使用的物理磁盘空间中。
全新安装后，我使用的几乎是标准配置。
这是"working like intended"还是这里有什么问题？
更重要的是：我能做些什么吗？
它按预期工作，您只是没有查看正确的文件。
每个数据库都有对应的同名文件。
例如：
curl -X PUT http://admin:secretpassword@localhost:5984/testdb
curl -X PUT http://admin:secretpassword@localhost:5984/emaildb
- 由于您有一个 _dbs.couch 文件，您可能正在使用具有分片功能的 CouchDB 2.X.X。 它将在 "shards" 文件夹的子文件夹中创建多个文件。
data/
+-- shards/
| +-- 00000000-7fffffff/
| | -- emaildb.124456678.couch
| | -- testdb.647948447.couch
| +-- 80000000-ffffffff/
| | -- emaildb.124456678.couch
|___|____-- testdb.647948447.couch
更多信息：http://docs.couchdb.org/en/latest/cluster/sharding.html
简而言之，分片和集群功能允许您拥有一个具有分布式 map/reduce 计算的分布式数据库。在上面的示例中，每个 dbs 有 2 个分片，这意味着每个数据库跨越两个文件。创建的每个新文档最终都可能出现在这两个文档之一中。但是磁盘使用不会均匀分布。例如，如果每个文档都是一个小 json 文档，但其中一个文档有 1GB 的附件 (http://docs.couchdb.org/en/latest/intro/api.html#attachments), only one shard will get a 1GB bump. The sharding is doc based. You can have 2 shards, you can have 20, and they don't all have to be on the same server (http://docs.couchdb.org/en/latest/cluster/theory.html)。如果您知道一台服务器没有足够的磁盘 space 来保存您的所有数据，您可以设置 20 个 couchdb 服务器，每个服务器将保存 1 个分片（大约所有文档的 1/20）。无论是地下室的单个节点，还是遍布全球的couchdb服务器集群，对于客户端应用程序（curl、pouchdb、firefox等）来说，都是一样的api.
_dbs 数据库 (
_dbs.couch) 记录了每个 dbs 的信息，用于集群和分片管理。它的大小会增加，因为每次您创建和删除数据库时，它都会更新（写时复制）。从 CouchDB 2.1.0 及更高版本开始，它将自动压缩。您可以检查服务器配置中的自动压缩设置。（在浏览器中：http://localhost:5984/_utils/#/_config/,compactionssections). Admin panel is on a different port: http://localhost:5986/_utilsFauxton 报告的尺码是 "active size"。不计算仍在磁盘上的已删除文档，这些文档将在压缩后删除。
curl http://localhost:5984/testdb将提供其他信息，例如磁盘大小 (http://docs.couchdb.org/en/latest/api/database/common.html#get--db)。