不用MongoDB Compass，如果想了解数据的大致情况，就需要连接到MongoDB shell，并使用查询语句把文档结构、字段名、数据类型反馈给工程师。同样，需要进行自定义查询，就必须要理解MongoDB的查询语言。
MongoDB Compass会采样集合的子文档中的数据并以图形化的方式展现给用户。通过采样，MongoDB可以在最小化消耗数据库负载的情况下及时的把结果展现给用户。
文档验证可以让DBA对文档结构、数据类型、数据范围、必填字段进行强制性管理。具体的验证规则现在也可以在Compass的GUI中进行管理。通过点击几下鼠标就可以创建并修改验证规则，违反规则的文档也可以清晰的展示出来。DBA使用Compass的CRUD功能解决单个文档中的数据质量问题。
文档大小MongoDB中BSON文档最大支持16M，用户应该避免一些特定的应用程序无限制的使文档增大。例如，电商平台应用中，很难估算每个商品可能会收到多少用户评价，所以，通常的做法是只显示一部分商品评价，比如最近的以及最广泛的评价。相比把商品和评价放在一个文档中，把每个评价或者一组评价单独放在一个文档中会更方便，同时，在存放商品的文档中存放一些主要的评价以便快速访问即可。
GridFS大于16M的文件，MongoDB提供了GridFS这种功能，所有的驱动程序都支持这种功能。GridFS可以自动地把大的数据分成多个块，每个块256KB，同时维护这些块的元数据。GridFS能检索单个块也能检索整个文档。比如，应用可以快速的跳转到一段视频的具体某个时间戳的位置。GridFS通常用来存储照片以及视频这些比较大的二进制文件。
空间分配调整（仅与MMAPv1存储引擎相关）在MongoDB MMAPv1存储引擎中更新文档时，如果有足够的空间，数据就地更新。如果更新的文档比分配的空间大，那么文档就需要重新写在新的位置。迁移文档并更新相关索引的过程会消耗很大的I/O并引起一些本可避免的性能问题。
为了预测数据未来的数据量，默认情况下，每个集合的usePowerOf2Sizes属性是开启的。默认情况下（从MongoDB3.0开始），MongoDB会把分配空间四舍五入成2的幂（比如2,4,8,16,等等），这样会减少由于文档迁移造成I/O增大的几率，代价就是需要增加额外的存储。如果你明确数据添加后不会增加，那可以把noPadding设定为true来节省空间。
另外一种做法是设置noPadding为true，并手动为文档进行空间预留以保证文档有足够的空间。如果应用以可预测的方式把数据加入文档中，则可以先添加文档的键，再添键对应的值，这样可以在文档创建的过程中分配合理的空间。空间预留会最小化文档迁移带来的性能损耗，因此能最小化负载。
以上所涉及的内容仅限于MMAPv1存储引擎，不适用WiredTiger引擎以及以WiredTiger为基础的其他引擎，比如Encrypted引擎，它会为每个更新操作进行重写。
数据生命周期管理MongoDB可以管理数据的整个生命周期，包括TTL索引以及capped集合。除此之外，使用MongoDB Zones管理员可以创建高效的分层存储模型以管理数据生命周期。管理员把分片分配到Zones中，就通过存储密度来平衡潜在的查询压力，同时，基于时间戳这样的值，把数据集分片到指定的存储设备中可以平衡查询消耗：
l 最新的以及访问频率高的数据可以放在高性能的SSD硬盘中，并开启压缩机制。
l 旧数据访问频率低的数据可以放在性能低的硬盘中，并使用zlib压缩，这样达到最小的存储代价
l 当数据不断增加时，MongoDB会自动在存储层级之间迁移数据，不需要管理员创建工具或者ETL进程来管理数据迁移。
TTL如果集合中的文档只是在固定的时间段内有效，那么TTL特性可以用来自动删除过期文档也不用查看所有文档的日期并进行一系列的删除操作。比如，如果用户session只能在系统中存在一个小时，那么可以为文档中的lastActivity数据字段的TTL设置成3600秒。后台进程会自动检测所有文档并删除时间超过3600秒的文档。TTL最常见的一个例子就是在特定时间后就会过期的价格。
Capped CollectionsCapped Collections是固定大小的集合，支持高流量的数据读写。Capped Collections类似于循环缓冲区：数据按照插入的顺序依次插入文档中，当集合的大小达到设定的阈值后，最先插入的数据会被删除掉，为最新插入的数据腾出空间。例如，把日志信息存储在一个高容量的Capped Collections集合中，就可以快速的检索到最新的日志信息。
删除集合