我很好奇Kyle Banker's MongoDB的这句话:
考虑关键名称的长度是很重要的，因为关键名字存储在文档本身中.这与RDBMS形成了对比，RDBMS总是将列名与其所指的行分开.因此，当使用BSON时，如果您可以使用dob代替date_of_birth作为密钥名，那么每个文档将节省10个字节.这听起来可能不算多，但一旦你有了10亿个这样的文档，只需使用一个较短的密钥名，你就可以节省近10GB的存储空间.这并不意味着你应该采取不合理的措施来确保小的键名；理智一点.但是，如果您希望获得大量数据，那么节省关键名称将节省空间.
我对数据库服务器端没有优化的原因很感兴趣.一个包含集合中所有键名的内存中查找表是否会对性能造成太大的损失，而不值得节省空间？
您所指的通常被称为"密钥压缩"*.它没有得到实施有几个原因:
和所有功能一样，实现它也有成本效益分析，而且(至少到目前为止)其他功能提供了更多的"划算".
对于future 的MongoDB版本，完整文档压缩正在考虑中 从3.0版开始提供(见下文)
*内存中的键名查找表基本上是LZW风格压缩的一种特殊情况——这或多或少是大多数压缩算法所做的.
**压缩提供了空间优势和性能优势.较小的文档意味着每个IO可以读取更多的文档，这意味着在具有固定IO的系统中，每秒可以读取更多的文档.
MongoDB 3.0及更高版本现在拥有WiredTiger存储引擎的完整文档压缩功能.
有两种压缩算法:snappy和zlib.其目的是让snappy成为全面性能的最佳 Select ，让zlib成为最大存储容量的最佳 Select .
在我个人(非科学，但与商业项目有关)的实验中，snappy compression(我们没有判断zlib)提供了显著提高的存储密度，但没有明显的净性能成本.事实上，在某些情况下表现稍好一些，与我之前的 comments /预测大致一致.