CouchDB：良好的文档 ID 以降低存储要求答案

【问题标题】：CouchDB: Good document ids to lower storage requirementsCouchDB：良好的文档 ID 以降低存储要求
【发布时间】：2012-07-01 21:22:00
【问题描述】：

所以我做了一些研究，显然存储需求会随着密钥大小而显着增加。

实际上我希望能够使用“long int”作为我的密钥，但这不可能，因为 couchdb 要求密钥是正确的字符串？有什么办法可以规避吗？

因为我的 id 看起来像：

{ "_id" : "10209939", ....data here ... }
{ "_id" : "10209940", ....data here ... }
{ "_id" : "10209941", ....data here ... }

我想让它们保持数字来进行范围查询。但是由于存储随着密钥长度的增加而增加，所以我的存储会爆炸。从某种意义上说，这些表示为字符串的 id 占用了更多的字节，如果它们被解释为长整数的话。

有没有人有使用“数字”整数作为 id 存储文档的经验？鉴于 couchdb 将“_id”理解为字符串，您如何获得良好的存储效率？我们可以告诉它，不，它是一个“long int”而不是一个字符串。

【问题讨论】：

【解决方案1】：

除非您的文档大小非常小，否则 id 不会很重要。我建议您进行一些测试并确认不同方法之间实际损失了多少空间。在进行测试之前不要忘记压缩，并记住使用 CouchDB 1.2.0 数据压缩也已启用，因此也会减少大 id 的影响。

严格的要求是 RFC http://www.ietf.org/rfc/rfc4627.txt 中的 JSON UTF-8 更多详细信息。您应该确保在可能的情况下插入具有顺序增加的 id 的文档，因为这减少了 b-tree 重新平衡的需要。当然，您也可以稍后通过使用压缩来解决这个问题。

在大多数情况下，对您的 id 使用最明智的方法是在您需要唯一性的情况下使用有意义的值。 CouchDB 只对 id 强制执行唯一性，因此您不妨考虑一下！

【讨论】：

【解决方案2】：

id 必须是字符串。别无选择。

您可以进行范围查询，但只能查询词法范围 - 而不是数字范围。

【讨论】：