阿里云MongoDB战略合作介绍
——陆封
内容概要
一、阿里云MongoDB发展历史
二、阿里云&MongoDB公司战略合作
三、阿里云MongoDB概览
四、阿里云MongoDB部署结构
五、阿里云MongoDB优势亮点
好，非常高兴有这个机会来举办我们跟网购DB公司一起合作来举办啊阿里云游戏行业的MangoDB的一个思想会。我先做一个简单自我介绍啊，我是阿里云数据事业部陆丰华明陆丰，我现在来负责阿里云的诺c口的一些产品的工作。这里我先跟大家分享一下阿里云过去这么多年来在文档输出网购DB上的一些投入跟发展情况，以及我们跟网购DB公司的一些战略合作情况，包括我们的生态，还有一些研发社区上的一些合作情况。
一、阿里云MongoDB发展历史
随着阿里云在2010年初的开服，我们在16年推出了商业化的MongoDB，当时只是社区版本，但已经支持副本集形态。
17-18年，随着Mongo社区的发展，我们又继续推出新的版本，不断地完善不同的服务形态，包括管控、加密、cloudDBA的自动诊断、数据传输以及不同的分片布置形态。
2019年，我们跟MongoDB公司正式确立了官方战略合作伙伴关系，我们可以在全球首发MongoDB最新的版本。结合MongoDB自身内核能力，和我们国内合作伙伴的战略情况，以及整个步骤形态、管控以及对孵化的支持能力，我们推出了更强的MongoDB版本。同时，我们还支持了TDE的加密落盘——以便在公共云上提供更好的数据安全性，也支持只读节点——可以水平扩展读的能力，还包括备份加密以及VPC网络加密等等。
在20年和21年，我们都在阿里云上最早推出MongoDB最新版本的支持。20年推出了基于云盘存储形式的MongoDB版本，结合MongoDB原厂的内核能力和阿里云的研发投入，构建了serverless形态，能够极大地节省成本和简化应用性。我们也构建了DynamoDB的兼容形态，以及推出了提供更强管控能力的专属集群形态。
今年9月份，我们发布了MongoDB最新版本5.0。此外，还提供了DTS数据双向同步功能、备份等能力。
从16年MongoDB在国内刚刚开始社区构建的时候，我们就进行了深度参与。并且在后期跟DB公司战略合作，不断地加大投入，结合原厂的能力去推动MongoDB在国内的使用和生态发展。
二、阿里云&MongoDB公司战略合作
自19年跟MongoDB公司正式战略合作起，我们在19年和20年连续两年荣获MongoDB发布的全球最佳合作伙伴奖项。阿里云用户相较于其他云平台可以更优先使用到mobility的最新版本，同时既可以得到阿里云技术架构师的支持，也能直接获得MangoDB公司跟我们共建解决方案的架构师的支持。
同时阿里云也通过与社区和贸易基地、贸易公司合作，不断地推动DB内核的发展。比如在4.4版本，阿里云的工程师也开发了很多MangoDB的新特性。
三、阿里云MongoDB概览
简要介绍一下DB在阿里云上的产品形态。
首先我们提供了全系列版本的支持，支持多种部署形态，包括最入门级的单节点、高吞吐读写能力副本集的形态以及水平扩展，还有 Serverless形态等等。同时我们提供了 Vpc网络、安全审计、全员加密等安全的保证。
同时我们构建了数据管理、备份、传输等对DB的支持，还有监控报警，智能诊断的一整套能力，使得用户可以获得最高性价比和最好的云上一体化的服务能力，同时还可以享受MangoDB最新最强的内核特性。
四、阿里云MongoDB部署架构
阿里云MongoDB主要有4种形态，一种是最基本的三阶段形态、面向海量数据扩展的分片集群的形态、支持性能扩展的副本集形态，还有最新推出的Serverless形态——可以提供最佳性价比。
五、阿里云MongoDB优势亮点
总结来看，阿里云MongoDB的亮点颇多，包括提供了最佳性价比和运维效率以及提供一体化的生态工具等等。
以上就是阿里云和MongoDB过去几年的发展，期待未来能有更长足的合作。
X项目MongoDB实践
——王海波
内容概要：
一、为何选择MongoDB
二、MongoDB使用情况
三、遇到的挑战
近期我们游族网络百川工作室正在研发一款卡牌产品，在立项的时候决定把数据库层从MySQL迁移到MangoDB，本文主要分享一下这个项目在MongoDB的一些实践情况。
一、为何选择MongoDB
首先聊一下为何选择MangoDB。
第一个原因来自于关系型数据库的痛点——它的复杂度比较高，也会给开发效率带来一定的影响。
以游戏中的装备为例，每个装备的不同等级都会有不同的属性。使用关系型数据库来存储装备需要两张表，第一张是装备表，主键是装备ID，还有一列是装备的等级；第二张是装备的属性表，主键是装备ID和属性ID，它是一个联合主键，还需要一列装备的属性值。通过这个例子我们会发现，使用关系型数据库需要维护数据库的表结构，而且数据库的表结构往往跟业务实验的数据结构是有差异的，它的维护是需要一定成本的。
其次，在玩家登录的时候，需要把数据从数据库里加载到内存。但随着游戏复杂度的增加，表的个数也逐渐增加，就会导致加载速度减慢。为了保证玩家的登录速度，我们引入了异步加载机制，但同时这也会提高编码的复杂度。
第二个原因是文档的结构更适合游戏数据的建模。
还是以装备为例子，如果使用文档结构，在设计的时候可以直接将装备的属性作为子文档嵌到装备文档中，这个数据模型跟业务模块中使用的数据模型是一致的。文档结构的优势有以下几点：
l 嵌套的文档模型天然适合描述游戏数据。
l 使用嵌套的文档模型对游戏数据进行建模之后，我们发现，只需要少量的文档就可以去描述整个游戏数据，可以提高加载效率，还可以去掉异步加载机制，进而简化业务代码，提高开发效率。
l 文档模型非常灵活，能够支撑游戏高速迭代的需求。
第三个原因是MongoDB提供的Sharding模式。游戏是一个全区全服的分布式架构，玩家的数据在游戏的集群中也是分片的。这种架构能够和sharding模式非常完美地契合。Sharding模式主要有以下几个优点：
l 高可扩展。游戏公测初期会有大量玩家涌入到服务器，可以利用sharding模式多部署一些分片实例，来保证公测的顺利。
l 高可用。MongoDB的副本集模式，可以保证服务的高可用。
l 方便合服。游戏往往都有合服的需求，我们需要保证玩家的ID是唯一的。采用sharding模式合服的时候，只需要配置游戏区服之间的映射关系，不需要做任何物理层的数据迁移，使得够做到秒级的合服。
二、MongoDB使用情况
MongoDB的第一点应用就是关于数据建模。
我们将玩家的数据集中存储在有限的4个文档中，第一个存放角色数据，里面主要是玩家的头像、等级以及新手引导之等数据。第二个存放背包数据，比如玩家的道具、装备。第三个存放活动数据，比如各种运营活动，第四个存放社交数据，比如好友列表、聊天记录。
只需要几个有限的文档就可以描述整个游戏的数据，因此相比于关系件数据库，表结构的数量大大地减少了。
目前，数据落地主要采用了两种方式。
第一种是定时全量更新。它的实现逻辑是，按照固定的时间间隔去检测文档是否发生变化，如果有，则把整个文档入库。它的优势在于，实现起来很简单，并且它的数据很安全，不会丢失。它的劣势是QPS稳定低点，且文档越大QPS就会越低。
第二种是定时增量更新。它的实现逻辑是在更新子文档的时候，对子文档做标脏，然后定时把周期内所有标脏的子文档收集起来，一次性落地。它的优势是qps比较高且稳定，不会随着文档的大小发生变化。劣势在于数据不安全，因为子文档标脏是通过带有标脏功能的接口来实现的，如果业务代码中没有调用这些接口，就会调导致这部分数据没有被落地。
接下来分享一些压测数据。我们的压测主要在阿里云上面进行，部署了两个MongoDB和三个分片实例，主要进行了两方面的测试。
首先是测试单个文档的大小变化对qps的影响。我们把文档分为了50KB、100KB和200KB三个档次，测试结果显示文档越大qps越小，成反比关系。其次测试集群的qps和配置提升的关系。我们把分片从2C4G升级到4C8G，再升级到8C16G，测试结果是集群的qps呈现出线性增长。
在上线之前，我们根据这些压测数据提前规划好需要的实例个数，然后准备一些冗余，来保证公测的顺利稳定。
三、挑战
接下来分享一下我们在使用MongoDB过程中遇到的一些挑战。
第一点，使用定时全量更新方式的时候，文档越大QPS越低。除此之外，我们还担心会存在其他负面影响，比如文档越大会导致op_log越大，op_log过大会不会产生其他的负面影响？
第二点，sharding模式没办法做到单个区服的回档。但是实际运营的时候可能由于Bug或者其他的原因，会有单个区服回档的需求。
第三点，如果使用MongoDB数组，实现增量更新会比较复杂。我们现在的方案都是使用map方式，以子文档的形式来做增量更新。 但 map方式的缺陷在于做统计查询的时候不方便。
MongoDB助力游戏客户
全球部署与快速开发
——唐峰
内容概要：
一、MongoDB与游戏行业
二、MongoDB使游戏开发更高效
三、MongoDB使玩家体验更极致
四、MongoDB使架构伸缩更弹性
一、MongoDB与游戏行业
首先谈一谈MangoDB与游戏行业的渊源。
过去的两年受疫情的影响，游戏行业是为数不多的发展比较好行业。从全球来看，有非常多的游戏比如海外的堡垒之夜，还有比较经典的索尼克系列，以及在国内的游戏场上很受欢迎的阴阳师、梦幻西游等，它们的后端数据库都是使用了MongoDB。同时，在与游戏行业客户的沟通过程中，我们发现越来越多的游戏公司在开发新的游戏和构建新的游戏平台的时候，都会重点考虑使用MangoDB。为什么MangoDB在游戏行业中会如此受欢迎？
从我们的视角以及得到的反馈来看，主要得益于MongoDB的三个特点：
第一，MangoDB可以让游戏开发变得更加高效。
第二，MangoDB的高可用性可以保证玩家体验。
第三，MangoDB的分片架构可以让数据库集群在做弹性伸缩的时候更加高效。
二、MongoDB使游戏开发更高效
首先来看游戏行业中的开发效率问题。我们都知道游戏行业的竞争非常激烈，同一款类型的游戏可能有不同的游戏公司都在进行开发，那么越早将游戏推向市场就有越大的几率来赢得更多的玩家。游戏发布之后，开发团队也会根据玩家的反馈不断地进行游戏玩法的调整。
这就要求我们的数据模型要非常灵活，并且，做这些数据库结构变更的时候尽量要低代价甚至无代价。
在游戏的场景里面，玩家的属性非常多，并且是非常重要的一类数据。按照过去的做法，我们会选用关系型数据库来存储这些属性，把不同玩家的不同属性和装备，按照类别存放到不同数据库的表里面。在获取这些数据的时候，需要通过玩家ID来做join操作，把数据从数据库里加载出来。数据发生更新的时候，也需要保证数据同时写到多个表里面，全都写入成功之后再去提交。
这种关系型的数据库模型带来的问题是显而易见的。首先，随着玩家的增长和数据量的增多，数据库表的结构也会越来越多，这个时候做join操作是比较低效的，会导致数据库变得越来越慢。其次，表的数量过多不利于数据库的水平扩张的，可能需要采用一些分布式的中间件，或者在应用代码里写数据路由规则来实现数据库的水平扩张。
以上种种都会制约我们的开发效率。接下来看看MangoDB是如何帮助开发团队更高效地构建游戏。
而在MangoDB里面，玩家数据是存放在一个Jason文档模型中，可以通过嵌套数组或者嵌套子文档的方式，将一个玩家身上不同的属性以及属性与属性之间的关系，放到一个阶层的文档里面，写到数据库中，不再需要像关系数据库那样拆到多张表里面，大大提高了存取效率。
同时，面对游戏场景不断迭代以及玩法不断更新的需求，MongoDB的阶层文档模型做数据模型的变更也是非常方便的。
随着游戏的发展，我们会加入一些社交属性，比如就近玩家推荐。最开始玩家数据里面是不带地理位置信息的，如果现在需要在关系型数据库里面添加地理位置属性的字段，不仅仅是游戏的代码区发生变化，还要在数据库里面去做表结构的修改。如果再有一些数量非常大的历史表，这个操作可能需要非常大的代价，甚至需要申请停服来做这样的变更。
但是MongoDB不需要预先定义好表结构的，所有的数据都可以直接写入进来。也就意味着如果有一个新的游戏需求，我们只需要对代码进行相应的变更，MongoDB数据库不需要任何变更操作。可以保证游戏玩法变更不会对数据库产生额外开销，也不需要停服。
MangoDB里多文档事务的实现方法和使用原则跟关系数据库是保持一致的，所以游戏开发人员从关键数据库转到MangoDB就不需要太多的学习成本。
过去开发游戏的时候，有些涉及到支付、和金钱相关的场景是不会考虑用MangoDB的，因为过去的版本并没有提供相应的功能。但是MangoDB V4.0新增了多文档事务功能，已经有很多游戏公司在MangoDB上实现了支付等功能。
Change Stream也是MongoDB非常好用的一个功能。
有时候我们需要构建一些基于数据的改变，实时地做相应的业务逻辑处理的场景。比如玩家的等级发生了变化，就要实时计算他所在游戏服务所有玩家的排名情况。过去，我们的方式是在每天凌晨玩家比较少的时候批量地把所有玩家的排行重新计算一遍。
MangoDB的Change Stream功能解决了这个问题，它可以很方便地捕获玩家等级字段的变化，然后送到后端的处理逻辑里面，触发重新计算玩家排行榜。
三、MongoDB使玩家体验更极致
在游戏行业中玩家基本都要求7×24小时在线，这对游戏运营是一个比较大的挑战。比如日常数据库的升级，版本的变更，或者一些安全补丁的维护，要怎么样来进行？MongoDB的高可用复制集如何来帮助游戏的运维团队？
首先MongoDB在部署的时候，最小的部署单元是一组两重的复制集。里面的主节点是提供了同时读写的能力，从节点跟主节点保持数据的同步并对外去提供读的操作。玩家登录游戏以后，所有的数据变更都是写在主节点上面，然后MangoDB通过内部的op_log来把数据同步到从节点上。
这样的流程能够在单个节点发生故障的时候起到非常好的保护作用。因为MangoDB的复制集在主节点发生故障的时候，能以秒级的速度重新选举出新的主节点来对外提供服务。
同时在游戏应用侧，MongoDB也提供了相应的驱动，里面包含可从事的读写。也就是说在主节点发生故障需要做主从切换，或者由于网络抖动造成失败的读写操作的时候，这个驱动可以自动捕获到相应的信息，并且在集群选举出新的组件之后自动进行重试。这就解决了高可用的需求，并且解决了保证7×24小时在线的难题。
MangoDB的复制集可以不断地添加从节点来对集群读的能力进行扩展。它最多能支持一个复制集下面有50个节点，这些从节点用来做什么呢？
比较典型的一种用法，就是用它来做分析型的业务。比如我们要对游戏运营数据进行分析，过去可能需要将这些数据统一导到一个集中的数字仓或者数据分析平台，但在MongoDB里面可以直接在重建链上进行。
此外，MangoDB的charts可以很方便地接入数据库，去构建可视化报表，可以迅速对游戏运营提供数据决策的支持。
四、MongoDB使架构伸缩更弹性
游戏行业的一个特点就是在游戏的不同生命阶段，数据库的压力是不一样的。
在游戏发布的早期或者公测的时候，我们可以比较准确地预估数据库需要的配置，但正式发布之后，流量是很难准确预估的。这就要求我们能够迅速对突发流量做出数据库集群规模的调整。
随着时间的推移，到了后期可能游戏不再那么受欢迎，这时候我们需要对数据库集群的规模进行缩减，来达到投资和回报上的平衡。这在关系型数据库里是比较难实现的，但MangoDB的分片集群可以轻松实现。
首先，它可以通过向已有集群里面添加节点的方式，对数据库的容量和读写的负载进行横向扩展。并且添加节点和数据的自动均衡都是在MangoDB的后台自动完成，应用侧不需要编写任何路由规则，也不需要做任何代码的变更。所以对应用来讲，它是完全透明的。
其次，MongoDB可以在全球部署一个大的集群，然后在每个玩家比较多的区域放置一个或者多个分片，这样可以保证不同地区的玩家都有一个离自己比较近的分片，可以实现就近的读写。此外，还可以把从节点在不同的区域里做交叉部署，这样每个区域都有自己分片的主节点，可以就近进行数据更新。同时又有其他区域的从节点，能看到全球完整的数据，可以去做游戏运营的分析或者游戏的综合报表等。
最后，MongoDB分片可以帮助我们实现地区性法规的需求。比如欧洲玩家数据的不能出欧洲，我们可以在MangoDB里面通过zoom-sharding方式去指定规则，指定欧洲玩家的数据就落在欧洲数据中心这个片上，以此来满足数据合规性的需求。
在游戏里面还有一个比较常见概念就是滚服与合服。
使用关系型数据库的时候，游戏服务器和数据库服务器大约是1:1。当一个服的上线玩家数量达到了一定的数字，就需要去开一个新服，同时还要等比例配置一套相同的游戏服务器和数据库服务器。后续可能需要对一些不太活跃的游戏服的玩家进行合并，这就是合服。
在关系型数据库里面做合服是比较耗费成本和资源的，需要做数据的导入导出，要找一个停服维护的时间。如果不同服里的玩家 ID存在冲突，也需要处理数据冲突的问题。
但是有了MangoDB的分片，我们可以把所有不同服的玩家数据放在一个大的集群里，只需要在里面增加一个新的字段，标识出玩家来自于哪个区哪个服。将来做合并的时候只要在MangoDB里面做更新，这是一个完全在线的、很轻量级的操作，并且不会发生玩家数据冲突的问题。根据游戏的火爆程度，我们可以很方便的通过添加节点的方式去动态调整数据库侧MangoDB集群的规模。
最后总结一下，为什么MangoDB越来越受欢迎游戏公司的欢迎？因为它完美解决了三个挑战。
l MangoDB的敏捷性可以让开发更高效，将游戏更快推向市场。
l MangoDB的高可靠可以确保在极端苛刻的情况下，玩家的体验不会受到影响。
l MangoDB的分片扩展，可以完成全球通服，高效地对整个集群进行扩展，在全世界离玩家最近的地方部署数据库集群，为玩家提供最好的体验。
最后分享一条来自MangoDB的观点：希望游戏开发者更专注于构建游戏应用，我们负责把数据库的维护成本降到最低。
阿里云数据库MongoDB
在游戏行业的应用
——子兵
内容概要：
一、阿里云MongoDB简介
二、游戏MongoDB最佳实践
三、游戏MongoDB行业案例
一、阿里云MongoDB简介
阿里云MongoDB的部署形态分为单节点，副本集和分片集群，能够支持serverless和专属集群。serverless主要是在一些测试环境下可以做到按需收费。还提供安全把控措施，包括vpc、安全审计和全链路加密。运维方面能提供自动的弹性伸缩、高可用的能力以及备份和恢复，支持任意时间点恢复。还有监控告警和监控信息查看功能。
上图下方是一些工具平台，包括数据传输服务和开源的MongoShake。它们主要是为上云迁移、异地多活或者说不同版本数据之间迁移的场景提供DTS。数据管理服务（DMS）主要负责变更审批， 数据备份服务（DBS）主要负责数据备份恢复，包括异地备份和异地恢复。数据库自制服务（DAS）负责性能分析、绘画管理和索引推荐等，此外 ，阿里云MongoDB还提供7*24小时的专家服务。
接下来重点解析关于阿里云MongoDB的几个部署形态。
l serverless。它是一个比较常见的场景，提供计算资源按需计费能力，具有资源源用量低、简单易用、弹性灵活、价格低廉等优点，完美解决了 MongoDB 使用门槛高的问题，帮助中小客户轻松上云
l 单节点。它拥有超高的性价比，适用于开发、测试、学习培训及其他非企业核心数据存储的场景，可以根据各类场景的差异适配对应的规格配置，为企业降低更多的成本支出。但是它的高可用能力和SLA会弱一些，所以不建议在生产环境中使用。
l 副本集。它可以根据业务需要，例如阅读类网站、订单查询系统等读多写少场景或有临时活动的突发业务，按需增删Secondary 节点和 ReadOnly 节点，更好地实现读取性能扩展。
l 分片集群。它提供 Mongos、Shard、ConfigServer 三种组件，可自由地选择 Mongos 和 Shard 的配置和个数，无限扩展性能及存储空间，组建不同能力的分片集群实例，非常适合高并发读写的场景
阿里云MongoDB的核心价值特征有以下几个方面：
l 开箱即用，不需要运维、备份、恢复、监控告警等操作，免除运维烦恼。
l 根据业务请求量做弹性伸缩。
l 高可用多活以及业务持续和数据可靠。
l 定期做全量和增量的备份恢复，并且支持任意时间点。
l 安全加固，通过网络、IP白名单、SSL+Ted等全链路加密方式，来提升数据安全性，降低数据被泄露的风险。
l 提供审计日志，云上所有的操作变更、访问查询等都会存储到审计日志，遇到特殊情况需要审计或者回溯的时候，有据可查。
l 支持不同的监控维度，性能数据负载情况和风险情况一目了然。
l DAS自动诊断以及支持7×24小时的智能优化和护航。
阿里云MongoDB支持几种不同的备份方式。
l 自动备份和手动备份，可以在控制台设置对应的备份策略，包括保留时间等等。
l 物理备份、逻辑备份和快照备份，也可以设置备份周期、保留时间、备份的方式和异地备份等，
备份存储在 oss上，可以达到99999999999的高可靠能力，大大提升了数据的可靠性。
它的恢复是支持覆盖到原实例的，可以快速恢复到历史的任意时间点。还可以克隆新实例，然后在新实例上做一些变更操作。还支持全量恢复和任意时间点的恢复，以及单库恢复。
单库恢复可以显著降低恢复时间。比如有四五个数据库的情况下，整体需要的恢复时间就比较长。单库恢复只针对需要恢复的数据库进行操作，效率是可以达到一个成倍的提升。
同时它还可以定期做备份有效性的验证，防患于未然。定期把数据恢复出来，检查它的一致性、数据可用性等，来避免真正需要的时候备份不完整或者不可用的情况。
MangoDB的全量备份主要分为三个方式。
第一种是原生的Mangodump方式，也就是逻辑备份，是把所有数据通过dump这种方式导出来。
第二种是物理备份，通过rsync或者CP/tar的流的压缩的能力直接拷贝物理文件，来完成备份。但是物理备份的一个痛点在于，备份过程中需要进醒，这对在线业务是会有一定影响的。
第三种是快照备份，主要依赖一些云盘的能力，比如在云盘上做snashot。快照备份的速度很快，但它的空间占用会相对大一些。
接下来对三种备份方式各自的优缺点进行分析。
首先备份/恢复的成功率。因为逻辑备份过程中需要把所有数据导出来，它的时间、可控性和有效性比较低，遇到异常容易失败，所以它备份/恢复的成功率是比较低的。物理备份和快照备份的成功率比较高的。
快照备份的备份效率是最高的，因为它不需要做数据拷贝，所以它的耗时最低，物理备份次之，逻辑备份最低。
逻辑备份的恢复效率会也比较低，物理和快照备份相对比较高。
从灵活性上来看，逻辑备份有一个有点在于它可以跨平台或跨版本去做备份恢复，包括不同的版本、副本集合分片集都可以做恢复，不需要依赖特定的版本。但是物理备份和快照备份就需要强依赖对应的版本和存储引擎。
传统的CP和Rsync的方式在物理备份过程中对在线业务有一个锁表的过程，这个时候业务是无法写入的。所以我们在原生的重组引擎上做了内核层面的改造来支持热备份，使得阿里MongoDB在做物理备份过程中不需要锁表，也可以支持单库恢复。
阿里云对于以上三种备份方式都是支持的，但快照备份只支持云盘场景，因为它本身是依赖一个磁盘的特性。
接下来是关于弹性伸缩，包括它的scale up和 scale out能力。
scale up是纵向扩容的能力，这个过程中不需要做数据迁移，可以很好地避免数据迁移耗时久的问题。也可以做到自动弹性重组，无需提前做扩容，并且在扩容过程中能够做到滚动升级，保证对业务的影响降到最低。
scale out主要是在集群模式或复制集场景下，新增delete节点、readonly节点或者secondary节点做运营分析的场景。在集群场景下，可以做到多个分片的快速扩容，加入新的节点之后也可以做到自动负载均衡，能够尽量降低对在线业务的影响。
阿里云MangoDB端到端的安全解决方案，分为事前、事中和事后。
事前是防护，提前把管控措施做好，来降低外围对数据库的影响，包括一些角色、权限的访问，或者IP白名单、ssl加密等。
事中是加密，进行 TED加密即对数据整体完全加密，即使数据泄露，也能保证具体内容无法查看，并且过程中还可以对审计日志进行操作。
事后是审计，比如复盘的时候，需要了解谁在什么时间点操纵了什么事情，可以很快地通过审计日志获取到。
上图是MongoDB整体的监控情况。MongoDB依赖于云监控，它能够达到秒级监控，并且支持的监控指标有18个大项、40多个子项，包括一些MongoDB的基础指标、请求次数、磁盘负载、内存、CPU等。CloudDBA可以根据监控信息和会话信息情况做一些性能分析，包括慢日志分析和磁盘空间的分析等，来提前的预测并且说降低线上的安全风险。
接下来重点介绍MongoDB的DAS服务。
首先是自动索引推荐。如果存在一些线上运行时间比较长或者慢查询消耗CPU和内存的情况，service控制台会自动推荐相应的索引来降低运维人员分析问题的时间，然后添加相应的索引来降低比如SQL查询的时间，提升整体效率。阿里巴巴集团经过3年以上的内部生产环境验证，索引推荐的成功率高达98%。
另外还支持会话管理，它会关注执行时间特别长的操作以及没有索引的操作，针对这些特殊的会话进行一些定制化的操作，可以通过会话管理结合索引推荐，来很好地对线上的负载情况进行分析和排查。
阿里云的MongoDB支持DynamoDB版本。比如游戏用户从aws上迁移直接迁移到MongoDB的改造量是比较大的，对此，MangoDB提供了两种形态的支持。第一种是兼容MongoDB的协议，跟原生的MongoDB没什么大的区别，第二种是支持Mongo DynamoDB的协议，DynamoDB的接入层和查询层都不需要做太大的改造。数据迁移过程中依赖的NimoShake也已经开源，可以直接从 aws DynamoDB迁移到阿里云MongoDB的分片集群或者复制集，跨云迁移的便利性得到了大幅提升。
MongoDB在云端的部署是一些副本集和分片集群，阿里云的数据传输服务DTS或者MongoShake，可以保证数据在多云之间、上云或多活的场景下进行平滑的迁移，它同时支持全量迁移与增量迁移。全量迁移是从云上不断地查询对应的数据，写入目标端，增量迁移是依赖于op_log方式做实时的迁移。比如我们可以全量加增量迁移完之后再做一个快速切换，来保证数据的一致性以及降低切换过程对整体时间的影响。
二、游戏MongoDB最佳实践
游戏行业分为不同的区域服务，分区分服务和全区全服。分区分服大多使用副本集，全区全服使用分片集群，比如用户数比较多的情况下用分片集群会比较适合。
l 多变需求：MongoDB本身的文档模型能够很好地支撑玩家属性、背包、道具等非常复杂的属性信息的重组，能够轻松应对需求变更。
l 游戏回档:它可以做到任意时间点恢复和单库恢复。
l 游戏滚服:能够基于备份集或者时间点创建新的实例。
l 链路安全：通过vpc、SSL以及IP白名单等方式来数据安全。
l 运营分析：它是MongoDB原生的支持。Aggregation pipeline、spark connector以及只读节点，在运营分析场景下都是比较有用的。
MangoDB延时节点的主要能力，就是在需要快速回档的情况下比如服务器宕机，可以立即切换到延时节点。并且延时节点不需要承担线上业务，保证了回档的高效率、低成本。
在游戏里面经常会存在一些限时技能/道具，MangoDB的TTL索引非常适合于这种场景。它可以在创建技能属性的时候就指定一个TTL索引，比如多久以后自动失效，省去了开发层面的代码实现和应用层面的判断。
再比如，很多大型游戏是基于地图作战，在游戏过程中需要判断某个玩家与我的距离以及我附近有哪些玩家等，此外还有利用地理位置作为社交系统的需求比如附近的玩家功能。MangoDB原生支持了这些功能，可以通过near、geoWithin、geoNearnaer三中查询方式来实现，大大降低了开发难度和代码量。
游戏回档是游戏里非常常见的场景，它主要是做任意时间点的恢复，本质就是一个备份恢复的过程。原生的MongoDB在恢复过程中，增量阶段耗时会比较长，而且它是单线程复制的，效率也比较低。
我们在MangoDB内核层面做了改造，在增量恢复过程中可以做到并行复制，大大提升了增量恢复的效率，此外还可以做到暗库恢复，不需要对整个实例所有的数据库全部进行备份恢复，只恢复需要的一些数据就可以了。
只读节点的能力主要在一些大的分析场景下比较常见。比如某个分析场景需要消耗大量资源，但又不能影响在线业务，这时候可以单独新增一个只读节点用来做大的运营分析，来降低对在线业务的影响。
三、游戏MongoDB行业案例
MongoDB非常广泛地应用于国内外的游戏行业。它的分片集群和副本集能力，它在高可用、扩展性、弹性伸缩上的优势，易于部署的特性和文档模型都能很好地匹配游戏场景，大大提升开发效率，解决游戏行业需求变化快的问题。
MongoDB在游戏里面有几个比较常见的应用场景。
游戏开发，主要用于存储玩家的属性信息等；客户平台，即会员中心或用户中心，一款大的游戏可能有上千万用户，会需要进行一些大的存储和读写，MongoDB的分片集群能够很好地支撑这类需求；第三游戏社交，比如游戏内的地图；还有游戏商城和排行榜等。
最后介绍一个MangoDB的应用案例，阿里云的SLG游戏——三国志战略版。三国志战略版从19年推出至今，一直经久不衰。它的核心游戏服务全部都是基于阿里MongoDB实现的，它也在游戏内部的场景上应用了很多MangoDB原生的特性，而且达到了很好的的稳定性、安全性。
