您所指的通常称为“密钥压缩”*。没有实施的原因有几个:
- 如果你想完成它,你现在可以很容易地在 Application/ORM/ODM 级别上完成它。
- 在所有情况下,这不一定是性能**优势——想想具有很多键名的集合,和/或在文档之间有很大差异的键名。
- 在您拥有数百万个文档之前,它可能根本无法提供可衡量的性能**优势。
- 如果服务器这样做,则仍然必须通过网络传输完整的密钥名称。
- 如果通过网络传输压缩的密钥名称,那么使用 javascript 控制台的可读性确实会受到影响。
- 压缩整个 JSON 文档
可能会提供更好的性能优势。
像所有功能一样,实现它有一个成本效益分析,并且(至少到目前为止)其他功能提供了更多的“物有所值”。
完整的文档压缩正在[正在考虑][1] 用于未来的 MongoDB 版本。从 3.0 版开始可用(见下文)
* 用于键名的内存查找表基本上是 LZW 样式压缩的一种特殊情况——这或多或少是大多数压缩算法所做的。
** 压缩提供空间优势和性能优势。更小的文档意味着每个 IO 可以读取更多的文档,这意味着在一个固定 IO 的系统中,每秒可以读取更多的文档。
更新
MongoDB 3.0 及更高版本现在具有使用WiredTiger存储引擎的完整文档压缩功能。
有两种压缩算法可用:snappy和zlib。目的是让 snappy 成为全面性能的最佳选择,而 zlib 成为最大存储容量的最佳选择。
在我的个人(非科学,但与商业项目相关)实验中,快速压缩(我们没有评估 zlib)显着提高了存储密度,而没有明显的净性能成本。事实上,在某些情况下,性能稍好一些,大致符合我之前的评论/预测。