初创公司MongoDB最佳实践策略和躲坑秘笈

极牛技术实践分享活动
极牛技术实践分享系列活动是极联合顶级VC、技术专家，为企业、技术人提供的一种系统的线上技术分享活动。
每期不一样的技术主题，和行业专家深度探讨，专一解决技术实践难点，推进技术创新，每两周的周三20点正式开课。欢迎各个机构、企业、行业专家、技术人报名参加。

本期大纲
MongoDB是啥？特色及适用场合？
高可用如何作？
性能调优？
监控与排错？

嘉宾介绍
魏佳，前后就任于IBM创新技术研究院、新浪微博平台架构部及新浪微博技术评审委员会、Mico联合创始人及CTO，现任LinkedIn中国技术主管。对企业级应用技术、虚拟化技术以及分布式消息中间件有深刻的研究。对大规模分布式系统、高并发Web系统，主流通讯系统的技术栈和协议有丰富的工程经验。 同时具有扎实的计算机科研技能，著有多篇中外技术专利。从技术架构层面支撑其从0到千万级注册用户，日均百万级活跃用户，日均千万级消息量的发展和演进。

MongoDB的话题
今天的话题主要围绕如下几个方面吧：1. What? 2. Why? 3. How?

首先MongoDB做为NoSQL兴起时的一个表明，最近这些年发展很是迅速，同时使用也很普遍。一两句来讲MongoDB是什么？有10gen公司来开发和维护，由C++开发，支持众多的语言。feature层面，它是document-based，同时是DDL free的，不说schema free是由于不少场景中仍是须要schema的。重要的是它easy tounderstand/learn and use，同时支持server-side script。此外，spatial index，GridFS以及有限度的MR的支持，也拓宽了它的使用场景。

为何选择MongoDB呢？
首先说到选型问题，我认为技术决策和选型的过程首先要抛弃先入为主的狭隘思惟。没有万能的工具，只有最合适的工具。“不考虑场景的惟XX论”的观点我我的很不认同。

具体到几方面：
社区活跃和支持程度。MongoDB的mailing list和community很是得活跃，同时响应很迅速。
生态完善程度，包括文档、辅助工具，以及是否方便得与既有基础设施或工具集成。
这些方面使得学习和掌握的过程变得容易。

场景方面：
对于大部分startup，须要的是快速的业务迭代，这每每意味着需求的不稳定性，映射到产品和技术层面，可能就是模型的频繁变化，因此DDL(schema)-free是个诱人的优点。
非强事务的场景，对于ACID要求严格的场景那确定是传统的RDBMS更为合适。
对spatialindex的支持很好，适合如今不少流行的空间查询场景，好比相似“周围的XX”，“多边形关系”等。

开箱即用的一些分布式能力支持，这个对于startup初期，尽可能减小devops的时间和精力仍是颇有必要的。

高可用如何作？
MongoDB具有开箱即用的复制集能力，经过典型的Primary＋Secondary＋Arbiter拓扑来构建复制集。
基本的结构就如这幅图：

搭建很是容易，参考官方的手册便可。复制集经过preference的设置，便可以达到读写分离的要求。MongoDB的选举依赖bully算法，相似其余分布式算法，这方面须要注意的是“奇数实例数”、复制集最多12节点，其中7节点参与选举在3.x版本变化比较大，后面讲到。复制过程依赖oplog，相似MySQL里的binlog，因此设置大小合适的oplog很重要，特别是在复制延迟比较高的场景里。容易产生复制失败而不得不进行全量的resync。

性能调优方面

先来讲index相关的。
由于MongoDB查询时先扫index再扫数据，因此查询时若是只要个别字段，而字段又偏偏有index的话，那就能够直接返回这些字段，而省去扫数据的过程。

复合索引的次序问题，这个问题相似用多个漏斗筛东西，尽量将小漏斗放在前面（左侧），极大地减小后续扫索引的量，能够提升查询的效率。除此以外，插入数据时，也可减小去更新索引树的变化程度。
生产环境建议不要使用sparse index，浪费空间。

对已有数据作建立索引操做，若是是复制集环境，建议离线来作，避免因为建索引的长耗时致使追不上而产生resync过程。

对于索引字段的数据类型的选择，string类型的>>int类型的，因此尽量减少index的size，确保尽量将index都放入内存，应该选择合适的索引数据类型。

对于document层面：在知足业务场景的状况下，尽可能使用nested document，也就是说建模时尽量的反范式。一方面减小doc的总数量，同时减小查询时磁盘IO的次数。

此外，doc中field的名字用尽量短的，这也是为了减少doc的size大小若是业务场景中，doc内有不少text内容同时不会作文本内容的检索，那建议都使用bindata来存。
对于statement方面：用好explain很重要，它是作进一步优化的指导数据。
好比这样的事例：

这部分能够进一步参考官方手册，系统层面，因为是per connection的粒度来建立线程，因此也要关注连接数，和对应操做系统的stacksize。

监控和排错

监控和排错监控的重要性不言而喻，若是已有各种监控基础设施，那集成很是简单。若是暂时没有，推荐munin，或者也可以使用官方的mms服务（须要部署agent）。

MongoDB自带的一些监控命令很是有用，好比mongostat和mongoshell中的db.stats。这里须要重点关注pagefault %和lock %，这两者，若是page率高，那须要关注读场景的效率以及数据量和内存的状况。若是lock率高，则要关注写场景。好比合并写，或者异步写的方式。

IO繁忙的时候，数据文件（xyz.n）预分配会堵塞其余操做，这种状况下很是容易形成雪崩效应，因此能够pretouch的方式去建立数据文件。

对于数据碎片化的状况，建议离线的去repair database。经过profile，须要重点关注运行时full scan和update的场景，进而进行进一步的优化，特别是update，若是大部分状况产生了moved，则须要经过填充占位数据的方式去避免。经过explain，须要关注covered indexes和index usage的状况，有针对性的建立或修改索引。

3.x版本是MongoDB很是重要的里程碑，其中有些feature很是有价值。好比提供更高压缩率的压缩方式，zlib和snappy，能有30%～50%的提升，至关于用压榨cpu来换取内存中数据的使用率。

此外，是复制集的改进，明显缩短选举的过程。同时对于心跳检测的过程复用复制的通道，并且能够单独控制选取的超时，这个有利于网络环境差时的选举过程。

对index的改进主要时支持partial index，特别适合索引中目标数据的值在所有数据中占比很小的状况，能极大的减少index的size。

最前面说到有些场景须要schema，因此3.x中支持schemavalidator能够增强schema校验拒绝无效数据。

Q&A
Q1：MongoDB如今的存储引擎是否还存在断电等极端状况的数据安全性没法保障问题 ？
A1：若是是复制集的环境，当前primarycrash了写请求会路由到新的primary上，若是是shard的环境，影响得是局部shard，可是没shard也应是HA的结构。除此以外，对于这种极端状况，应用层也是须要作容错，换作其余组件这种场景也同样。
Q2：创业初期业务多变，选型了MongoDB，随着公司发展，业务也渐趋稳定，也在考虑从MongoDB迁往MySQL，什么阶段迁移比较合适，再者迁移的过程有什么坑没？
A2：首先迁移数据是折腾人的事儿，先想清楚迁移的目的和收益。从性价比角度来讲是伪命题，从运维经验掌控程度角度说，也是事在人为的。最后回答你的问题，一般就是应用层双写，以后异步迁老数据，数据对其后，tcpcopy重放的方式来校验数据，都没问题了，就完事儿了。

＊此分享由LinkedIn中国技术主管魏佳在极牛线上技术分享群里所分享

【下期重磅预告】<主题>【如何守护企业核心数据安全】<讲师>陈宇森，北京长亭科技有限公司联合创始人、总裁。<大纲>1.介绍黑客入侵的常见思路、手段、目的。2.经过大量案例分析企业是在哪些关键环节出了疏漏致使发生了入侵事件。<时间>下周三（10月26日）晚8:00有意加入的技术朋友，请在极牛公众号(ji-niu)里回复“技术分享”