MongoDB运维实战lsm降低Disk Lantency

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了MongoDB运维实战lsm降低Disk Lantency，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含5439字，纯文字阅读大概需要8分钟。

内容图文

MongoDB运维实战lsm降低Disk Lantancy

背景

Part1:写在最前

在副本集架构中，当我们面临写多读少，且大多数写为update操作时，WT引擎的瓶颈初显。这直接导致业务反馈写入操作耗时较久等异常。为此，Percona版本的MongoDB里支持rocksDB存储引擎，应对写比较多的时候会显得更加从容。

Part2:背景

在业务大量更新的场景中我们发现WT存储引擎的disk lantency会比较高，在尝试调大cache_size和并发数、eviction后效果不佳，因此我们尝试使用rocksDB引擎代替。

实战

Part1:整体架构

原有集群为3节点副本集架构，均使用WT存储引擎。我们将其中一台从库换为rocksDB存储引擎，观察disk lantancy情况。

如上图所示，可以看出主节点的QPS情况。

Part2:rocksDB引擎从库

我们将其中一台从库配置为rocksDB引擎，RocksDB相对WT一大改进是采用LSM树存储引擎。Wiredtiger 基于 btree 结构组织数据，在一些极端场景下，因为 Cache eviction 及写入放大的问题，可能导致 Write hang，细节可以到 MongoDB jira 上了解相关的issue，针对这些问题 MongoDB 官方团队一直在优化，我们也看到 Wiredtiger 稳定性在不断提升；而 RocksDB 是基于 LSM tree 结构组织数据，其针对写入做了优化，将随机写入转换成了顺序写入，能保证持续高效的数据写入。在替换其中一台从库为rocksDB引擎后，我们将其与另外一台WT引擎的从库进行disk lantency的对比。

下图为使用lsm Tree 结构的rocksDB存储引擎从库的disk lantency，可以看出都在1ms内。

其qps如下图所示，repl_delete在3k左右且连续稳定。

Part3:WT引擎从库

下图为使用WT存储引擎从库，其disk lantency和主库一样，写入的lantency达到了8ms，读也有4ms

其qps在2.3k左右，且监控出现断点，从库出现因压力大登录超时的情况。

Part4:RocksDB引擎配置参数

storage:
  engine: rocksdb
  useDeprecatedMongoRocks: true
  dbPath: /home/work/mongodb/mongo_28000/data/db_28000
  indexBuildRetry: true
  journal:
    enabled: true
    commitIntervalMs: 100
  rocksdb:
    cacheSizeGB: 10
    compression: snappy
    maxWriteMBPerSec: 1024
    configString: write_buffer_size=512M;level0_slowdown_writes_trigger=12;min_write_buffer_number_to_merge=2;
    crashSafeCounters: false
    counters: true
    singleDeleteIndex: false

注释1

#storage Options

storage:

  engine: "rocksdb"

  useDeprecatedMongoRocks: true   ##percona 3.6版本需要加

  dbPath: /home/work/mongodb/mongo_10001/data

  rocksdb:

    cacheSizeGB: 10  # 默认是30% of physical memory

    compression: snappy

    maxWriteMBPerSec: 1024 #单位MB，rocks writes to storage 的速度，降低这个值可以减少读延迟刺尖，但该值太低会降低写入速度

    configString: write_buffer_size=512M;level0_slowdown_writes_trigger=12;min_write_buffer_number_to_merge=2;   

   crashSafeCounters: false  #指定crash之后是否正确计数，开启这个选项可能影响性能

    counters: true   #（默认开）指定是否使用advanced counters，关闭它可以提高写性能

    singleDeleteIndex: false

在添加 configString: write_buffer_size=512M;level0_slowdown_writes_trigger=12;min_write_buffer_number_to_merge=2;    参数后，磁盘延迟进一步降低，iops也进一步降低

这里需要注意的是，percona从3.6版本起不建议使用rocksdb，可能在下一个大版本移除，至于是否选用，要根据实际情况出发，最好能够拉上业务一起进行一个压测，满足业务需求的，就是最好的。

https://www.percona.com/doc/percona-server-for-mongodb/LATEST/mongorocks.html

注释2

rocksdb参数的调节一般是在三个因素之间做平衡：写放大、读放大、空间放大

1.flush选项：

    write_buffer_size:

        memtable 的最大 size，如果超过了这个值，RocksDB 就会将其变成 immutable memtable，并在使用另一个新的 memtable

    max_write_buffer_number:

        最大 memtable 的个数，如果 active memtable full 了，并且 active memtable 加上 immutable memtable 的个数已经到

        了这个阀值，RocksDB 就会停止后续的写入。通常这都是写入太快但是 flush 不及时造成的。

    min_write_buffer_number_to_merge:

        在 flush 到 level 0 之前，最少需要被 merge 的 memtable 个数。如果这个值是 2，那么当至少有两个 immutable 的

        memtable 的时候，RocksDB 会将这两个 immutable memtable 先 merge，再 flush 到 level 0。预先 merge 能减小需要

        写入的 key 的数据，譬如一个 key 在不同的 memtable 里面都有修改，那么我们可以 merge 成一次修改。但这个值太大

        了会影响读取性能，因为 Get 会遍历所有的 memtable 来看这个 key 是否存在。

    举例：write_buffer_size = 512MB;max_write_buffer_number = 5;min_write_buffer_number_to_merge = 2;

    假设写入速率是16MB/s，那么每32s的时间都会有一个新的memtable生成，每64s的时间就会有两个memtable开始

    merge。取决于实际的数据，需要 flush 到 level0的大小可能在512MB和1024MB之间，一次flush也可能需要几秒的时间

    （取决于盘的顺序写入速度）。最多有5个memtable，当达到这个阀值，RocksDB就会组织后续的写入了。

2.Level Style Compaction：

    level0_slowdown_writes_trigger:

        当 level 0 的文件数据达到这个值的时候，就开始进行 level 0 到 level 1 的 compaction。所以通常 level 0 的大小就

        是 write_buffer_size * min_write_buffer_number_to_merge * level0_file_num_compaction_trigger。

    max_background_compactions:

        是指后台压缩的最大并发线程数，默认为1，但为了充分利用你的CPU和存储，可以将该值配置为机器核数

    max_background_flushes:

        并发执行flush操作的最大线程数，通常设置为1已经是足够了。

——总结——

通过本文，我们了解到RocksDB引擎的特点和与WT存储引擎的disk lantency对比，不同的业务场景不同，因此具体使用什么存储引擎，还需要结合具体业务来进行评估。由于笔者的水平有限，编写时间也很仓促，文中难免会出现一些错误或者不准确的地方，不妥之处恳请读者批评指正。喜欢笔者的文章，右上角点一波关注，谢谢~

彩蛋

历经1年时间，和我的挚友张甦先生合著了这本《MongoDB运维实战》，感谢电子工业出版社，感谢张甦先生让我圆了出书梦！感谢友东哥、李丹哥、李彬哥、张良哥的书评！感谢友飞哥、汝林哥在我入职小米以来工作上的指导和帮助！感谢我的爱人李爱璇女士，没有你在背后支持，我不可能完成这项庞大的工程。京东自营下周上货，喜欢MongoDB的同学欢迎支持！

内容总结

以上是互联网集市为您收集整理的MongoDB运维实战lsm降低Disk Lantency全部内容，希望文章能够帮你解决MongoDB运维实战lsm降低Disk Lantency所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端