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分钟

《 MongoDB 第一期 :集群搭建 》 《 MongoDB 第三期:托管 MongoDB 存储服务 》

原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏杨建荣的学习笔记

性能下降的不定时炸弹_过旧的sql_profile(r3笔记第9天)

最近这一周以来,生产环境像是得了重病的病人一样,小问题没有修好,大问题不断。IO的等待极为严重。数据库的负载达到了几十倍,上百倍。 weblogic和tuxed...

3187
来自专栏MYSQL轻松学

Percona XtraDB Cluster

image.png 1、什么是Percona XtraDB Cluster Percona XtraDB Cluster是一个开源,免费的MySQL高可用工具....

29510
来自专栏瓜大三哥

Sdram控制器(一)

2163
来自专栏王亮的专栏

存储总量达 20T 的 MySQL 实例,如何完成迁移?

为保证业务迁移顺利进行,对迁移流程,工具进行了前期的调查研究,并对过程中发现的 4 大问题进行及时解决,本文为实际迁移经验分享。

31.4K11
来自专栏程序你好

无服务器架构中的十大安全风险

无服务器架构(作为服务或FaaS的功能)是应用程序在其上构建和部署后,可以根据云工作负载流自伸缩的架构。从开发的角度来看,无服务器架构主要关注核心功能,而忽略所...

583
来自专栏恰同学骚年

操作系统核心原理-7.设备管理:I/O原理

  前面阐述了操作系统具有进程管理、内存管理、外存管理三大核心功能,但是计算机归根是为人类服务的,这就要求计算机必须提供某种机制使得人们可以向计算机发出命令或操...

715
来自专栏about云

kafka sql入门

问题导读 1.kafka sql与数据库sql有哪些区别? 2.KSQL有什么作用? 3.KSQL流和表分别什么情况下使用?

752
来自专栏程序猿DD

Spring Cloud构建微服务架构:分布式服务跟踪(抽样收集)【Dalston版】

通过 TraceID和 SpanID已经实现了对分布式系统中的请求跟踪,而这些记录的跟踪信息最终会被分析系统收集起来,并用来实现对分布式系统的监控和分析功能,比...

3276
来自专栏乐沙弥的世界

MySQL MHA 典型使用场景

Since MHA Manager uses very little CPU/Memory resources, you can manage lots of ...

640
来自专栏杨建荣的学习笔记

海量数据迁移之通过rowid切分大表(r2笔记62天)

在之前的章节中,讨论过了通过 分区+并行等方式来进行超大的表的切分,通过这种方式能够极大的提高数据的平均分布,但是不是最完美的。 比如在数据量再提高几个层次,我...

2928

扫码关注云+社区