MongoDB第二期：压缩与索引
原创
一、写在前面的话
1、关注的问题
（1）大数据时代的冲击，导致各种业务的对数据的依赖不断加大，要求存储的数据格式更加复杂和趋于个性化，而要求保留的时间也越来越长，对数据库存储的压力随之不断提升。
（2）由于数据的重要性和价值不断提升，对历史数据的利用率也愈发提高，冷热数据的界定也逐渐模糊，对于全量数据的查询处理速度的要求也越来越高。
2、MongoDB怎样应对
（1）数据量大？格式复杂？
MongoDB自身的文档型NoSQL特性很好的解决了格式灵活设置，在同一个库中支持不同格式的求，而在MongoDB-3.2中WiredTiger存储引擎引入了压缩功能，出色的压缩了海量数据的存储空间。
（2）快速查询大量数据，开销如何？
建立索引将大量提高数据的查找和处理效率（本文着重关注索引的开销，关于索引的效率将在性能分析中呈现），但在海量数据中建立索引的开销过大（时间、空间）一直是一个棘手的问题。MongoDB很好的优化了建立索引的机制，对于海量数据，能够很好的缩短建立时间和压缩占用空间。
二、压缩
1、概念
（1）压缩原理
MongoDB-3.2使用 WiredTiger存储引擎，支持压缩一个新的存储引擎。 WiredTiger使用页面管理磁盘I / O。每个页面都包含很多BSON文件。页面被写入磁盘时就被默认压缩，当在磁盘中被读入高速缓存时它们就被解压。
WiredTiger支持对所有集合和索引进行Block压缩和前缀压缩（如果数据库启用了journal，journal文件一样会压缩）。这为广大MongoDB使用者们带来了又一福音，因为之前版本的MongoDB都是因为MMAP存储引擎消耗了过多的磁盘空间而不得已进行扩容。其中Snappy压缩为数据库的默认压缩方式，用户可以根据业务需求选择适合的压缩方式。理论上来说，Snappy压缩速度快，压缩率OK，而Zlib压缩率高，CPU消耗多且速度稍慢。当然，只要选择使用压缩，MongoDB肯定会占用更多的CPU使用率，但是考虑到MongoDB本身并不是十分耗CPU，所以启用压缩完全是值得的。
（2）集合压缩
①无压缩
②Snappy（默认启用）
③zlib
（3）索引压缩
①无压缩
②前缀（默认启用）
2、使用
（1）适用/不适用的场景
①随机数据不能压缩；
②已经压缩过的数据（可能是二进制数据）不能压缩；
③文本压缩效果特别好；
④对于文件中的字段名压缩效果特别好（尤其是短字段名）。
（2）如何开启
MongoDB中3.2的默认是WiredTiger存储引擎，故其默认对集合和索引启用压缩。在使用之前版本的MongoDB（3.0~3.2）时，你还需要指定–storageEngine选择使用WiredTiger再利用压缩功能。为了在启动时明确设置副本的压缩，可以在配置文件中的进行相应设置。使用命令行选项–wiredTigerCollectionBlockCompressor。
要指定压缩特定的集合，你需要使用db.createCollection() 命令中的并传入相应参数项来覆盖默认值。例如，使用zlib压缩库创建一个名为email的集合：
db . createCollection ( “email” , { storageEngine : {wiredTiger : { configString : ‘block_compressor=zlib’ } } } )
3、实战
（1）场景介绍
① 数据结构
②集合大小
Colletion_1: 3000万
Colletion_2: 8500万
Colletion_3: 1亿
Colletion_4: 1.2亿
Colletion_5: 1.5亿
（2）测试结果
- MongoDB的Wired Tiger存储引擎在数据压缩（主要是文本数据）的能力出色，基本上能达到压缩55%左右的存储空间，极大程度上提升了磁盘空间的使用率。
- MongoDB的Wired Tiger存储引擎压缩从小规模数据的压缩到海量数据的压缩其性能保持稳定，压缩率均在54%~55%。可以说明数据量的增大不会成为其压缩功能的瓶颈。
- 三、索引
1、概念
MongoDB 提供了多样性的索引支持，索引信息被保存在system.indexes 中，且默认总是为_id创建索引，它的索引使用基本和MySQL 等关系型数据库一样。其实可以这样说说，索引是凌驾于数据存储系统之上的另一层系统，所以各种结构迥异的存储都有相同或相似的索引实现及使用接口并不足为奇。
2、使用
（1）创建索引
①普通索引
> db.test.ensureIndex({"username":1},{"name":"testindex"},{"background":true})
注意：将username键的索引命名为"testindex"，默认情况下建立的单个索引均为普通索引（非唯一索引），且在后台进行创建，不会阻塞其他操作。
②复合索引
> db.test.ensureIndex({"username":1, "age":-1})
注意：数字1表示username键的索引按升序存储，-1表示age键的索引按照降序方式存储。
③唯一索引
> db.test.ensureIndex({"userid":1},{"unique":true})
> db.test.ensureIndex({"userid":1,"age":1},{"unique":true})
注意：单个索引和复合索引均可设置为唯一索引，只需保证插入数据的唯一性即可。
（2）查看索引
> db.test.getIndexes()
（3）删除索引
> db.test.dropIndex({"username":1})
3、实战
（1） 场景介绍
① 唯一索引
② 普通索引
③ 复合索引
（2）测试结果
①空间开销
- 测试集合为Colletion_5（1.5亿数据，压缩后存储空间约为44GB），其中索引（唯一索引、普通索引、复合索引）所占空间约为2.5GB，占存储总空间的5.7%。
- 在三种不同的索引中，
唯一索引（_ id） 占 58%，
复合索引（ialgVersion_ftime）占24%，
普通索引（sSysver）占18%。
说明建立唯一索引是主要是影响索引空间开销的主要因素，而复合索引所占空间小于其分别建立单个普通索引。
②时间开销
- 随着数据量的增大，建立索引的时间开销将不断增大，故数据集合最初的设计极为重要，在海量数据生成后中建立索引，有一定的时间开销。
- 在建立索引的时间开销上：普通索引 < 复合索引（2个）< 唯一索引。
在一亿数据的集合中，
普通索引（时间开销）：约5分钟
复合索引（时间开销）：约5.5分钟
唯一索引（时间开销）：约7分钟
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。