为何MongoDB数据库总存储大小小于文档总大小？

嘿，这个问题其实挺典型的，我来给你唠明白～首先得先把你提到的两个术语的准确含义搞清楚，不然容易越绕越晕：

先明确两个核心术语 #

• Total Document Size：指的是你数据库里所有集合中，所有BSON文档的原始未压缩大小总和。简单说就是你插入的那些数据本身的字节数，没算任何MongoDB存储层面的额外处理。
• Storage Size：这是MongoDB在磁盘上实际占用的空间大小，对于默认的WiredTiger存储引擎来说，这个值是压缩后的数据+索引在磁盘上的实际占用量。

核心原因拆解 #

出现Storage Size小于Total Document Size的情况，最常见的就是下面这几个原因：

• WiredTiger的默认压缩机制：这是最主要的原因！WiredTiger从MongoDB 3.2开始就是默认引擎，它默认会用Snappy算法压缩数据，用前缀压缩处理索引。压缩后的内容在磁盘上的占用量会比原始文档小很多——比如你存了一堆带重复描述的商品文档、或者大量文本内容，压缩率能轻松达到30%-70%，甚至更高。
• 索引的高效存储：Total Document Size只算文档本身，不包含索引，但Storage Size是包含索引的。WiredTiger对索引的压缩和存储优化做得很到位，比如前缀压缩会把索引键中重复的前缀部分合并存储，就算不算数据压缩，高效的索引存储也可能让整体磁盘占用比原始文档总大小小。
• 文档的结构化/重复特性：如果你的文档有很多重复字段值、空字段，或者是高度结构化的数据，压缩算法能更高效地压缩这些内容，进一步缩小磁盘存储和原始文档大小的差距。

举个直观的例子：假设你有10GB的原始文档数据，经过Snappy压缩后，数据部分可能只占3GB，加上压缩后的索引1GB，那整个数据库的Storage Size就是4GB，明显小于10GB的Total Document Size。

内容的提问来源于stack exchange，提问作者Amio.io