云时代下的数据库存储——指挥若定的阿里云数据库MongoDB

本次直播视频精彩回顾，戳这里！

 

直播涉及到的PPT，戳这里！

 

分享嘉宾：阿里云高级产品经理 许鸿斌（花名：落宵）

           

本篇文章来自于阿里云高级产品经理许鸿斌（落宵）在2018年《Redis、MongoDB、HBase大咖直播大讲堂》技术直播峰会中的分享，该分享总体由三个部分构成：

 

一、云数据库MongoDB概述

 

二、云数据库MongoDB产品特性

 

三、典型场景

 

小荷才露尖尖角——初识MongoDB数据库

 

 

在了解MongoDB数据库以前首先介绍与MongoDB强相关的三个关键词：Humongos、Scale Out和Document。

 

做为MongoDB名称的由来，Humongos中文意思为极大的、巨大的，MongoDB从创办的第一天起就是围绕着对大数据量存储支撑的愿景来展开代码开发的。

 

在数据库产品的升级当中通常有两个维度：第一个维度为Scale Out向上升级，即随着硬件的能力从两核升级到四核再升级到八核向上升级的过程，可是机器终究是有上限的，此时数据库很难突破物理机性能的瓶颈；第二个维度为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已经支持了这样一个数据通道的功能，能够帮助用户很轻松地构建这样一个数据汇总操做，帮助用户将各地分布的分布节点上所存储的数据自动同步到一个中心库上，从而永久性地确保中心库上的数据永远是最全面的，同时能够帮助用户节省不少像数据同步、数据更新的一些自动同步操做。

阅读原文http://click.aliyun.com/m/41119/