ArangoDB文档键长度最佳实践：键长度是否影响数据库大小？

结论：文档属性名的长度确实会影响数据库大小，但影响程度取决于是否启用属性压缩、文档数量等因素。

1. 基础存储机制的影响 #

ArangoDB使用VelocyPack（VPack）格式序列化并存储JSON文档。默认情况下，每个文档都会完整存储其所有属性名：

• 比如你给出的示例中，"username"（8个字符）比"u"（1个字符）每个文档多占用7字节的存储空间。
• 当集合中文档数量较多时（比如百万级），这种字节差会累积成明显的空间差距——百万个文档仅这一个属性就会多占用约7MB空间，属性越多、文档数量越大，差距越显著。

2. 属性压缩的抵消作用 #

ArangoDB提供属性压缩功能（创建集合时可通过attributeCompression: true开启），启用后：

• 集合中重复出现的属性名会被编码为短标识符，且该标识符仅在集合元数据中存储一次，后续所有文档都用这个短标识符引用属性。
• 这种情况下，长属性名和短属性名的空间差距几乎可以忽略——不管属性名多长，最终存储的都是固定长度的标识符，仅元数据中会多占用少量存储（可忽略不计）。

3. 其他影响因素 #

• 文档数量：文档越少，属性名长度的空间影响越不明显；文档越多，无压缩时的空间差距越突出。
• 属性重复度：文档中重复的属性名越多，无压缩时的空间累积差越大，有压缩时的优化效果也越显著。
• 索引影响：属性上的索引主要存储属性值，属性名仅在索引元数据中存在，因此对索引空间的影响极小，可忽略。

示例对比 #

• 未启用属性压缩：使用"u"、"p"这类短属性名的集合，总存储空间会明显小于用"username"、"password"的集合。
• 启用属性压缩：两个示例的集合存储空间差距几乎可以忽略，此时优先选择可读性强的属性名更利于代码维护。

建议 #

• 若文档数量少、集合规模小，无需为节省空间缩短属性名，优先保证代码可读性。
• 若文档数量极大且未启用属性压缩，短属性名能有效节省存储空间；但启用属性压缩后，完全可以兼顾可读性和存储效率。

内容的提问来源于stack exchange，提问作者Abhay Rawat