|
MongoDB在OPPO互联网推广经验分享-如何把一个淘汰边缘的数据库逐步变为公司主流数据库 谈谈当前国内对MongoDB误解（丢数据、不安全、难维护）？ MongoDB跨机房多活方案-实现成本、性能、一致性"三丰收" MongoDB线程模型瓶颈及其优化方法 并行迁移：MongoDB内核扩容迁移速率数倍/数十倍提升优化实践 百万级高并发读写/千亿级数据量MongoDB集群性能数倍提升优化实践 万亿级数据量MongoDB集群性能数十倍提升优化实践 磁盘800%节省-记某服务接口网站交易千亿级数据迁移MongoDB，近百台SSD服务器节省原理 展望：借助MongoDB完善的分布式、高可用、机房多活等功能，如何实现NoSQL、NewSQL融合 其他-那些年我们踩过的坑 分享主题一：如何把mongodb从淘汰边缘变为公司主流数据库？ 背景： 入职前多个大数据量业务使用mongodb，使用中经常超时抖动 多个核心业务忍受不了抖动的痛苦，准备迁移回mysql。 mongodb口碑差，新业务想用不敢用。 入职1个月，业务迁移mongodb到公司其他数据库，mongodb总集群数减少15% 我做了啥？ 从服务层优化、存储引擎优化、部署方式优化等方面入手，逐一解决抖业务抖动问题 总结各个集群抖动原因及优化方法，公司内部分享。 收集公司所有mongodb集群对应用户，成立mongodb用户群 入职2月后，mongodb公司内部状态： 之前准备迁移到mysql的几个核心业务继续使用mongodb 对应业务负责人开始考虑把其他大数据量集群迁移到mongodb 越来越多的未使用过mongodb的部门开始使用mongodb 入职1年后，mongodb相关数据增长： 总集群数增长比例：> 700% 总数据量增长比例：> 2000% 读写流量增长比例：> 550% mongodb用户群用户数增长比例：> 800% 总结： mongodb赢得用户信任原因总结：口碑 分享主题二：当前国内对mongodb误解(丢数据、不安全、难维护)？ 业务接入过程中经常咨询的几个问题： 误解一. 丢数据 误解二. 不安全，网上一堆说mongodb被黑客攻击，截图一堆新闻 误解三. DBA吐槽mongodb太难维护 误解原因： mongodb本身很优秀，但是很多DBA和相应开发把控不住 国内系统性分析mongodb内核实现原理相关资料欠缺 网络社会以讹传讹，DBA或者相关开发自身把控不住演变为mongodb的锅 分享主题三：mongodb机房多活方案-实现成本、性能、一致性"三丰收" 传统社区mongodb双向同步方案(放弃该方案) 放弃该方案原因： 数据两份、集群两份、物理成本高。三机房、五机房等更多机房多活，成本及复杂性更高。 存在一致性问题，两地集群数据不一致，balance情况下尤为突出 由于人力原因，如果开源同步工具出现问题把控不在。 方案一：同城三机房多活方案(1mongod+1mongod+1mongod方式) 每个机房代理至少部署2个，保证业务访问代理高可用 如果某机房异常，并且该机房节点为主节点，借助mongodb天然的高可用机制，其他机房2个mongod实例会自动选举一个新节点为主节点。 客户端配置nearest就近访问，保证读走本机房节点。 弊端：如果是异地机房，B机房和C机房写存在跨机房写场景。如果A B C为同城机房，则没用该弊端，同城机房时延可以忽略。 方案二：同城两机房多活方案（2mongod+2mongod+1arbiter模式） 每个机房代理至少部署2个，保证业务访问代理高可用 如果机房A挂掉，则会在B机房mongod中重新选举一个新的主节点。arbiter选举节点不消耗资源 客户端配置nearest参数，保证读走本机房节点 弊端：如果是异地机房，B机房和C机房写存在跨机房写场景。如果A B 为同城机房，则没用该弊端，同城机房时延可以忽略。 方案三：异地三机房多活方案(1mongod+1mongod+1mongod方式)-解决跨机房写 每个机房代理通过打标签的方式，代理转发数据到主节点在本机房的分片上去。 A机房数据通过标签识别转发到分片shard-1，B机房数据转发到分片shard-2，C机房数据转发到分片shard-3。 分享主题四：mongodb线程模型瓶颈及其优化方法 mongodb默认线程模型(一个链接一个线程) 说明： listener线程负责接受所有的客户端链接 listener线程每接收到一个新的客户端链接就创建一个线程，该线程只负责处理该链接请求处理。 该网络线程模型缺陷： 一个链接创建一个线程，如果10万个链接，那么就需要10万个线程，系统负责、内存消耗也会很多 当链接关闭的时候，线程销毁，频繁的线程创建和消耗进一步增加系统负载 典型案例： mysql默认方式、mongodb同步线程模型配置，适用于请求处理比较耗时的场景，如数据库服务 mongodb默认线程模型(动态线程模型：单队列方式) 说明： 该模型把一次请求转换为多个任务：mongodb数据读操作(网络IO)、db层数据访问(磁盘IO)。 任务入队到全局队列，线程池中的线程从队列中获取任务执行。 同一个请求访问被拆分为多个任务，大部分情况下通过递归调用同一个请求的多个任务会由同一个线程处理；。 当任务太多，系统压力大的时候，线程池中线程数动态增加；当任务减少，系统压力减少的时候，线程池中线程数动态减少； 该网络线程模型缺陷： 线程池获取任务执行，有全局锁竞争，这里就会成为系统瓶颈 典型案例： mongodb动态adaptive线程模型，适用于请求处理比较耗时的场景，如数据库服务 mongodb优化后线程模型(动态线程模型-多队列方式) 说明： 把一个全局队列拆分为多个队列，任务入队的时候按照session链接hash散列到各自的队列，工作线程获取获取任务的时候，同理通过同样的hash算法去对应的队列获取任务，通过这种方式减少锁竞争，同时提升整体性能。 典型案例： mongodb内核多队列adaptive线程模型优化，特定场景性能有很好的提升，适用于请求处理比较耗时的场景，如数据库服务。 分享主题五：并行迁移-集群扩容速率N倍提升优化实践 并行迁移-集群扩容速率N倍提升优化实践(高版本) 并行迁移过程（假设需要迁移的表名为：test， 从3节点扩容到6节点）： 选取需要迁移的块，假设源集群有M分片，扩容新增N分片，则一般情况需要迁移的块=min(M,N) 迁移步骤：1. configServer-master选出需要迁移的块；2. config.locks表中id=test这条记录上锁；3.通知需要迁移的源分片开始迁移；4. 迁移完成后延时10s，重复1-4步骤实现持续性chunk数据迁移 并行迁移步骤： 说明：假设需要迁移的表名为test， 源分片数M，扩容后新增分片数N configServer-master选出需要迁移的块，一般S=min(M, N)，也就是M和N中的最小值； config.locks表中获取id=test这条记录对应的分布式锁； 异步通知需要迁移的S个源分片开始迁移； 等待S个chunk迁移完成 迁移完成后延时10秒 重复步骤1-5 并行迁移瓶颈： 获取分布式锁时间太长，原因：config.locks表中id=test表的分布式锁可能被其他操作锁住 configServer异步通知源分片中的S个分片同时开始迁移数据到目的分片，任一个chunk迁移慢会拖累整个迁移过程。 本批次确认迁移完成后，还需要延时10s；一般SSD服务器，一个chunk迁移都在几百ms内完成。 优化方法： 避免其他操作占用分布式锁，例如splite我们可以关闭autoSplite功能，或者调大chunksize configServer并行迁移不把多个分片的并行迁移放到同一个逻辑，而是放到各自的逻辑。 延时放到各自分片迁移逻辑里面控制，不受全局延时控制 分片延时可配置，支持实时动态命令行调整 |
|
|
