所以我做了一些研究，显然存储要求会因密钥大小而显着增加。
实际上我希望能够使用＆＃34; long int＆＃34;作为我的密钥，但这不可能因为couchdb要求密钥是正确的字符串？有没有办法绕过这个？
因为我的ID看起来像：
{ "_id" : "10209939", ....data here ... }
{ "_id" : "10209940", ....data here ... }
{ "_id" : "10209941", ....data here ... }
我想让它们数字化以进行范围查询。但是由于存储随着密钥长度的增加而增加，我的存储空间将会爆炸。从某种意义上说，这些表示为字符串的ID需要更多的字节，它们应该被解释为长整数。
是否有任何人有使用＆＃34;数字＆＃34;存储文件的经验？整数为ids？鉴于couchdb了解＆＃34; _id＆＃34;你是如何获得良好的存储效率的？作为一个字符串？我们可以告诉它，不是它是一个＆＃34; long int＆＃34;不是一个字符串。
答案 0 :(得分：1)
id必须是一个字符串。别无选择。
您可以进行范围查询，但只能进行词汇范围 - 而不是数值范围。
答案 1 :(得分：1)
除非您的文档尺寸非常小，否则ID不会很大。我建议你做一些测试并确认不同方法之间实际丢失了多少空间。在进行测试之前不要忘记压缩，并且要记住使用CouchDB 1.2.0数据压缩也会启用，因此大ID的影响也会降低。
严格要求是RFC http://www.ietf.org/rfc/rfc4627.txt中的JSON UTF-8更多详细信息。您应该确保在可能的情况下插入具有顺序递增ID的文档，因为这会降低b树对重新平衡的需求。您也可以稍后使用压缩来解决此问题。
在大多数情况下，使用id最明智的事情是需要唯一性的有意义的值。 CouchDB只对id强制执行唯一性，所以你也可以计算它！