本次直播视频精彩回顾，戳这里！
直播涉及到的PPT，戳这里！
分享嘉宾：阿里云高级产品经理 许鸿斌（花名：落宵）
本篇文章来自于阿里云高级产品经理许鸿斌（落宵）在2018年《Redis、MongoDB、HBase大咖直播大讲堂》技术直播峰会中的分享，该分享整体由三个部分构成：
1、云数据库MongoDB概述
2、云数据库MongoDB产品特性
3、典型场景
小荷才露尖尖角——初识MongoDB数据库
在了解MongoDB数据库之前首先介绍与MongoDB强相关的三个关键词：Humongos、Scale Out和Document。
作为MongoDB名称的由来，Humongos中文意思为极大的、巨大的，MongoDB从创办的第一天起就是围绕着对大数据量存储支撑的愿景来展开代码开发的。
在数据库产品的升级当中一般有两个维度：第一个维度为Scale up向上升级，即随着硬件的能力从两核升级到四核再升级到八核向上升级的过程，但是机器终究是有上限的，此时数据库很难突破物理机性能的瓶颈；第二个维度为MongoDB天然支持的Scale Out横向扩展能力，当一台机器的性能达到上限时，可以加入一台机器组成一个新的集群。这种横向扩展的能力使得MongoDB的集群可以不断地去提升自身的性能和存储能力，从而达到大数据量所需要的性能要求，也成为了MongoDB对大数据量支撑的佐证。
MongoDB是一个文档型的数据库，以文档为存储单元，而传统的MySQL等关系型数据库是以行存为单位的，相比行存的数据库文档型数据库在存储上更为灵活，这也是在很多业务场景选择使用文档型数据库来存储业务数据的的重要原因之一。
如上图所示，假设我们要存储一辆汽车的数据，其中包括所有的部件信息。由于每种部件所需要的信息不同，传统的行存数据库需要先将汽车所有的部件都拆开，分别存储在不同的数据表中，例如发动机需要存储的信息包括是否为燃油机、柴油机、吸气方式、燃油效率等字段，轮胎需要存储的信息包括轮毂高度、胎压范围等字段。行存数据库的数据结构需要多张表的支撑才能完整地组成一个所需要的部件信息。
文档型数据库不需要事先完全设计好表一样的结构来一一映射到每个部件上，它支持动态结构，可以把每一个存储项的项目名和值直接存储在一个文档当中，在数据结构上只需要简单的几行就可以把多张数据表的信息汇总起来，文档型数据库天然支持的一些数据的聚合、嵌套和数组结构的特性，提供了一个更为简练的存储结构、更为灵活的存储优势。
阿里云数据库MongoDB的产品架构
首先介绍的是MongoDB最为基础最为常见的一个三副本架构，一旦创建三副本的实例，云数据库MongoDB会自动将三个节点部署在三台不同的机器上，同时对外提供主节点写入的支持以及其中一个备节点读取的支持，两个备节点自动从主节点获取日志进行数据同步。三副本架构的优势在于，当其中某个节点出现故障时，另外一个备节点直接进行替换，系统会将之前的读取流量切换到另外一个正在运行的备节点上，从而保证当单点出现故障时整个应用的读写不会受到任何影响。但这样的架构同时会暴露出一个问题，当每台机器上的节点性能达到物理机的上限时，很难再去扩展能力，不论是在存储能力，或者是处理能力包括在CPU、内存这些性能指标上都很难再去达到一个突破，所以阿里云也支持了如下的MongoDB集群架构。
在MongoDB集群架构模式中，每一个集群下都由多个三副本节点构成，每个Shard的节点依旧采用三副本来保障Shard节点的高可用，一个集群可以通过横向扩展不断地把Shard节点加入进来，目前最多支持32个Shard节点的添加。当一个Shard节点上面的机器性能达到上限时可以不断地添加新的Shard节点以达到一个横向的扩展能力，也是MongoDB作为水平横向扩展一个非常重要的特性。不论是MongoDB三副本的架构保证一个高可用，还是是集群架构在高可用的基础上兼容了横向扩展的能力，由于数据库本身对于高可用、扩展性的考虑每一个架构所对应到后端的数据库硬件成本都有非常多个节点。
然而在一些实际的应用场景当中，很多用户在一些开发、测试的日常场景使用MongoDB时，发现没有必要使用那么多的节点数去存储，对于一些测试环境，我们可以容忍一定时间内的数据库宕机，或者数据并不需要非常强的扩展性来进行支撑。阿里云会在近期发布一个MongoDB更为基础的架构，即MongoDB的单节点架构，这个架构完全是针对整个MongoDB在测试、开发环境上的支撑所去构建的，它只有一个节点，一旦挂掉之后并不会有切换，而需要等待修复的过程。推荐用户在一些微核性的场景，类似于测试、开发这样的场景去使用，从而更好地显示单节点架构高性价比的特性。
阿里云数据库MongoDB的售卖形态
阿里云所有的MongoDB都是基于实例规格和存储空间两个定价因子进行收费的，在包年包月的模式上有更为折扣的价格，而按量付费更为灵活，支持随时启动和释放。在二月份到三月份，阿里云将会提供支持用户从按量付费的方式进行测试之后直接转到包年包月的方式，无需重新开启一个新的实例去修改应用的连接方式。同时在阿里云目前所支持的包括三副本、集群和单节点的多种架构中，例如购买了三副本模式，购买页面中直接把三个节点的价格形成一个汇总显示在页面上而不需要用户再去自己买多个节点。
精益求精——云数据库MongoDB产品优势
阿里云上的MongoDB相比于一些用户在机房自建部署的MongoDB上会有哪些方面的区别？
安全性：访问控制和日志审计
首先从安全性上看，从2016年底到2017年中期这段时间，全球爆发了非常严重的MongoDB配置的漏洞问题，据不完全统计，全球大概有数十万台MongoDB，包括很多用户在机房自己搭建的、在其它云厂商上搭建的数据库，都受到了不同程度的黑客攻击，这些MongoDB集群在被黑客攻击之后，完全地被黑客所控制，数据库中的数据全部被黑客所加密，黑客在控制了这些集群之后同时向这些MongoDB的用户发起了勒索，在数据作为安身立命重要支柱的企业当中，一旦被黑客所控制将产生严重的后果。在这样一场非常严重的浩劫当中，阿里云数据库MongoDB上所有的实体都没有被黑客所攻破。阿里云在云数据库MongoDB上面对安全做了哪些方面的加持呢？
首先，在访问控制方面，阿里云上天然所支持的VPC专有网络架构能够很好地将用户所部署的一些应用、数据库以及其它的一些云产品全部放到一个隔离的网络环境内部，这个网络环境内部就相当于我们自己在机房内所建的一个私有网络，完全隔离于外部，在此之上云数据库MongoDB支持IP白名单的功能，例如可以在MongoDB的实例上去设置哪些服务器是可以连接到MongoDB上的，而当机器的IP地址不在设置列表当中时，这台机器是完全无法连通MongoDB实体的。即使整个账号密码完全被窃取，也无法将不在白名单内的机器连接到MongoDB这个实体上。
其次，作为对MongoDB目前所支持的一个非常重要的功能，即日志审计的模式，可以做到完全地记录用户对于某一个MongoDB实例所做的一些更新、插入操作以及一些查询时间超过100毫秒的慢查询操作，这样的一些操作范围会有怎样的作用呢？
一些企业在发生被外界所攻击或者内部人员的数据窃取等安全事件之后，可以在日志审计中查找完整的操作记录，包括操作的用户是谁、操作时间是什么以及对MongoDB的实例做了哪些破坏性窃取性操作，使得用户有据可查、有证可依，同时在很多的金融领域尤其是在金融监管需求下，日志审计成为一种必要的功能。
可用性：同城容灾和异地容灾
云数据库在MongoDB可用性上所做的一些突破，如一开始所介绍的，MongoDB目前最为典型的三副本架构可以比较好地避免单点故障问题，可以保障有99.95%的SOA承诺，但是对于一些比较核心甚至敏感的业务场景还是远远不够的，如果整个部署三节点的机房完全挂掉，例如出现一些断电断网的行为时，整个三节点会在同一时间完全地不可用，这个时间段内整个应用还是会受到影响，所以目前阿里云正在部署一套新的架构，很快将会在页面上显示，即支持将每一个MongoDB的三副本实例的三个节点部署在同一个城市内的三个机房里，三个节点之间通过网络连接进行内网的通讯，还是和之前单机房的三副本架构一样，另外两个备节点依然从主节点上去同步数据，跟之前所不同的是一旦三个机房的其中一个出现了非常严重的自然灾害导致整个机房挂掉之后，MongoDB目前所支持的一个HA高可用系统会直接将应用流量从挂掉的实例切换到另外两个依旧正常运行的实例上，即使是整个机房受到自然灾害的影响，整个业务依然没有任何影响。
在同城容灾的基础上，很多的如一些证监会、银监会对一些比较敏感的金融业务场景提出两地三中心部署的架构需求，这样的需求目前MongoDB已经支持上线，例如用户在杭州的地域买到一个MongoDB的实例之后，可以在北京也开启一个这样的实例，而阿里云目前所支持的数据通道工具会将杭州的实例数据准实时地通过通道同步到北京这边，一旦整个杭州地区出现比较严重的故障，整个业务流量可以整体地从杭州切换到北京，避免业务流量受到城市级自然灾害的影响，从而去确保整个应用的高可用保障。
轻运维：备份和恢复
在日常的一些运维操作当中，数据库主要的一些故障会来自于两个方面的原因，第一种是硬件或自然灾害的影响，我们之前所介绍的三节点的高可用保障、同城容灾、异地容灾这些架构已经能够很好地规避这样的硬件故障级别的一些问题，但与此同时数据库容易遭受第二种更为严重的影响，即人为的一些操作失误，其最根本最有效的解决方法是做一个数据的归档、数据的恢复，所有的云数据和MongoDB实例目前已经在备份和恢复上面做了很大的改进，一方面在备份上所有的云数据库、MongoDB实例都会支持每天定时定点地进行自动备份的操作，完全不需要人为的介入。
此外相比于传统的用户通过开源版本自建的数据库，云数据库MongoDB通过对内核的深度优化改良，做出一些非常重要的提升。第一点是流式备份，所有的备份直接通过网络传输到云存储OSS上，而不在本地的机器上落地，这样可以避免在整个备份过程当中对机器所在的IO产生影响，整个备份的速度会有10%左右的提升。第二点是物理备份，相比于官方的备份模式有更大的改进，官方目前支持的逻辑备份方式，在备份和恢复速度方面都比较慢，而在经过内核的改造之后目前已经在云数据库MongoDB上实现了物理备份方式的支持，效率上大致有10倍左右的性能提升。
在恢复方式上，目前所支持的在控制台上的一个恢复方式称之为克隆实例，即将用户在设置好的备份时间点内所备份的数据文件和日志文件自动地存储到一个云存储OSS上。当用户需要做一些恢复操作时，并不是单纯地直接把之前的一个数据库备份文件直接恢复成我们所需要的数据，由于一些时间点并没有产生数据备份，MongoDB支持当用户指定一个存储周期内的时间点后，系统会自动地寻找离这个时间点最近的一个备份文件，先将备份恢复出来，然后再通过这份备份文件所存储的一些日志文件将整个用户所需要的数据追溯到用户所指定的时间点，这个时间点目前可以支持到7天之内的任意秒级别。同时数据备份并不单单直接将恢复做到原来的实际上面，因为一旦恢复之后发现整个恢复的过程、恢复的选项是错误的时，数据备份将会受到非常大的影响，所以克隆实例会先将数据恢复到一个全新的实例上面，在恢复完成之后用户可以登到全新的实例上去做一些数据的仿真校验，确认无误之后，再将我们需要恢复的部分或全部的数据直接导入到原来的数据库实例上面，在这个数据恢复的过程当中，既可以确保整个系统恢复安全性的保障，同时整个恢复的过程又不会影响原来数据库的正常运行。
在监控方面的改良上，数据监控是数据库运维非常核心的一个功能，目前在云数据库MongoDB上的控制台会支持用户查看非常多的包括机器本身的、引擎本身的一些监控数据，同时这些监控数据也会汇总一份到云监控的产品上，去做一个数据更长期的存储以及用户针对这些数据去做一个像报警的预值设置。
同时，阿里云将会在近期支持一个非常独家的功能，云数据库MongoDB版将会支持到整个监控数据的采集力度，从现有的5分钟级别直接优化到秒级别，即每一秒都会有一个点，这样采集力度的优化，在平时的运维当中会产生哪些比较大的影响呢？
以上两张图都是对同一个实例在同一个时间段内的采集，上面的图是分钟级的采集，下面的图是秒级别的采集，从中我们可以看出，在秒级别中每一个数据每一个时间段内都有波峰波谷，而在分钟级的监控图中，整个监控过程非常的平滑，很难去发现一些问题。在平常的一些运维管理当中会发现，某一段时间内的数据库或者是整个应用出现的一些比较大的例如应用卡顿等一些方面的影响，但是从监控数据上看整个过程又非常的平滑，很难去发现问题的所在，当切换到秒级别的监控力度上去之后，是可以很清楚很浓密地看到，在哪个时间段内性能出现了抖动，哪一个监控下出现了问题。基于这样的数据才能够更快地去定位到问题所产生的一些原因，更深一步地去优化这个问题对应用和整个架构所带来的一些影响，例如一些慢查询的优化、建立新的索引之类的优化操作。
索引推荐：多存储引擎
最后是对整个云数据库MongoDB上所支持的一个比较独家特性的介绍，即多存储引擎的功能，MongoDB官方目前支持的默认存储引擎是WiredTiger，它的综合性能非常稳定，一旦用户使用MongoDB开源的版本去生成数据库时，默认采用这样的存储引擎去支持整个数据的存储过程，而阿里云数据库MongoDB在WiredTiger的基础上又独家支持了TerarkDB和RocksDB这两款存储引擎，很多用户根据业务的特性去选择存储引擎来达到性能优化、成本缩减的目的。
TerarkDB是非支持全局高压缩技术的存储引擎，能够大幅度地提高一些随机查询的性能，在一些大数据存储的场景中能够有效地减少整个存储的成本。而RocksDB存储引擎支持大数据量持续写入的场景，在一些官方的文档上会有比较详细的介绍。在相同的一些持续大数据写入的场景测试下，通过第三方的测试工具会发现，RocksDB在该条件下依旧能够保持长时间的非常高的稳定性写入，推荐用户如果有大数据量写入或者大数据量存储场景可以通过我们官方的文档去了解一下我们目前所支持的这两款存储引擎。
通过上述的一些介绍，我们可以发现相比于用户自建的MongoDB实例，云数据库MongoDB无论是在可用性、扩展性、整个安全上的如访问控制、审计日志这样一些独家的功能、自动备份、克隆恢复、以及即将独家支持的秒级监控、索引推荐优化等功能上都存在非常大的优势，如果用户自建数据库的话将会投入非常大的开发力量。
实践是检验真理的唯一标准——MongoDB的典型场景
物联网行业中，由于许多物联网设备每时每刻都在通过传感器向服务端写入一些数据，所以物联网第一个特性就是整体的数据量非常大，在这种情况下MongoDB的集群版所支持的横向扩展的能力能够很好地支撑数据量不断地写入，而不必像一些单机的数据库那样一旦达到整个机器上限时还需要另外做连接地址、数据库更换性能的优化操作，Sharding模式可以持续地实现一个水平能力的扩展。物联网第二个特性就是数据结构非常灵活，例如可穿戴设备，它所采集的一些数据的特征都是各不相同的，在这种情况下我们一开始所介绍的MongoDB很灵活的文档型结构就可以很好地去支撑这种丰富的结构数据扩展。整个物联网最终诉求就是基于如此大量的数据存储之后，还需要在这些存储的数据上面做一个分析最后汇总成一个结果反馈到每一个客户端或服务端上形成一些结果的展示和数据的决策，在这种情况下MongoDB自身所支持的一些低压条件可以很好地去做大数据分析的支持，所以在物联网这个行业上面不论是从数据的存储、大数据的支撑以及数据分析的支持上MongoDB各方面的特性都可以得到非常淋漓尽致的展示。
游戏行业中，首先MongoDB Document这样一个非常灵活的架构支持，可以支撑游戏应用上非常多的功能扩展，其次一旦整个游戏开始进入推广期之后，它需要不断地去做一些开服的操作来支撑大量的用户量，这些开服操作在之前很多的运维的顺序是，需要先去建一个服务器，再去建一个同样的MongoDB数据库，再通过数据拉取导入等方式将本来数据库里的数据转移到新的数据库当中，因为游戏开服以后两边的数据库结构差别不是很大，这样的一套操作需要消耗运维非常多的时间和精力，所以在这样的场景之下克隆实例能够很好地发挥这样的功能，当用户需要做一个开服操作时，只需要在原先的数据库实例（称为母实例）上面直接通过克隆实例的功能选择它所需要克隆实例的数量以及它克隆的整个数据需要基于哪个备份文件和指定一个克隆时间点可以是当前的时间点，在做完这几步操作之后，系统会自动根据用户的诉求生成多个一模一样的数据库实例，这些数据库实例不仅可以在规格和性能上保持一致，同时在里面的数据上也可以跟用户之前的数据库保持一致，可以帮助游戏行业在开服这个操作上提高效率。
地理信息行业中，首先MongoDB自身天然地支持像地理信息数据索引的一些操作，可以很方便地应用于一些应用场景，如经纬度的查询、坐标的精确查询等数据操作的支持，这是MongoDB本身就支持的一些特性。同时地理信息的行业会经常需要从各地采集数据汇总到某个中心库上形成一个信息的汇总，目前云数据库MongoDB已经支持了这样一个数据通道的功能，可以帮助用户很轻松地构建这样一个数据汇总操作，帮助用户将各地分布的分布节点上所存储的数据自动同步到一个中心库上，从而永久性地确保中心库上的数据永远是最全面的，同时可以帮助用户节省很多像数据同步、数据更新的一些自动同步操作。