从零开始搭建MongoDB数据库即服务_光环大数据培训
- 格式：pdf
- 大小：670.85 KB
- 文档页数：17
从零开始搭建MongoDB数据库即服务_光环大数据培训光环大数据培训机构，一、什么是数据库即服务（DBaaS）首先介绍一下『数据库即服务』。
『数据库即服务』其实是『Database-as-a-service』的中文翻译，我们看看它在维基百科中的定义：我们知道，现在有很多的as-a-service，比如Infrastructure as a Service （IaaS）、Platform as a Service（Paas）还有Software as a Service（Saas）。
他们到底都是什么呢？有什么区别？这张图应该可以很好地解释这些X-aaS。
最左边是传统企业的IT，所有的活都要自己干，从数据中心服务器到操作系统数据库再到上层业务系统。
IaaS开始就进入云计算的范畴了，最基础的是云服务器，不需要再关心机房啊硬件拉，直接就可以用。
然后再往右客户需要关注的越来越少，脏活累活都交给服务提供商来干。
那么『数据库即服务』的情况是怎么样呢？数据库即服务的优势『数据库即服务』其实可以认为是PaaS的一种变种，主要关注点在数据库上，客户不再需要去自己部署数据库，而是只需要按需使用由服务提供商提供的数据库即可，数据库的维护都交给服务提供商来完成，这样客户只需关注应用本身即可。
我们来具体看一下使用『数据库即服务』和原来有什么不同，这里除了列举传统全部DIY的方式之外，还对比了一种利用IaaS来自建数据库的方式，这也是现在比较常见的一种做法。
我们看到传统方式，需要做很多事情，这当中还需要涉及多个团队来协作，非常不容易。
然后看看第二种方式，利用IaaS来自建，这里以阿里云的云服务器ECS为例，这种方式和刚刚相比，省了不少事，但是仍然是比较麻烦的，也可能还需要涉及跨团队协作。
我们再来看看如果是使用『数据库即服务』呢？只需要点下页面上的部署按钮，就可以等着用了，已经进化为完全自助服务了。
从时间上来看，第一种方式可能需要花费数月，第二种可能需要花费数天，第三种则只需要数小时即可。
可见『数据库即服务』的优势还是很明显的。
所以说为什么要『即服务』，其实是一个进化的趋势。
我们经常说人不能太懒，但是懒这个字用在程序猿身上可能并不是不好的东西，因为懒，促使我们会去自动化。
最早我们通过人肉操作，下载软件，编译部署，然后配置。
有一天我们发现经常需要这么干很累很浪费时间，就开始写脚本来完成这些操作，生产力开始提高。
等到规模更大的时候，比如要同时管理数十台数百台机器，这时候可能分发脚本也嫌麻烦了，开始写一些自动化的工具来做这个事情。
到最高级阶段，就是完全实现自助服务，这是懒的最高境界。
二、MongoDB简介说完了『即服务』以及其重要性，接下来我们看一下今天的另一个主角：MongoDB，因为有些同学可能对这个不了解，所以还是简单介绍一下。
首先，MongoDB是什么呢，它是一个Document Store，文档型数据库，也是我们经常说的NoSQL。
根据DB-Engines的数据库排名，MongoDB长期霸占着NoSQL老大的地位，现在是数据库界一位重量级选手。
事实上，MongoDB可以称为是一种NewSQL，它融合了传统关系型数据库和NoSQL 的一些优点。
最左边的3个能力是来自于关系型数据库：∙首先，它具备丰富的查询语句和二级索引。
通过这点，用户可以以足够复杂的方式来访问和组织数据。
∙第二点，强一致性。
MongoDB支持一个灵活的一致性模型。
你可以选择使用强一致性，或最终一致性，取决于你的业务场景。
∙第三点，MongoDB能很好的集成到多企业现有技术架构中。
右边3个能力来自NoSQL：∙首先是灵活的数据模型，MongoDB的文档模型允许动态修改schema，不用担心有任何的性能影响。
∙其次是高性能和高可扩展性，MongoDB可以轻松进行水平扩展，从而带来更高的吞吐和更低的延迟。
∙最后，是全球部署，也就是高可用。
接下来我们就来具体讲下MongoDB 的几个关键特性。
MongoDB的关键特性MongoDB的关键特性主要是3个，第一个就是灵活动态的文档模型，第二个是高可用副本集，第三个是MongoDB的水平扩展，也就是sharding。
1、灵活动态的文档模型MongoDB以一种叫做BSON（二进制JSON）的存储形式将数据作为文档存储。
具有相似结构的文档通常被组织成集合。
可以把集合看成类似于关系数据库中的的表：文档对应的是行，字段对应的是列。
MongoDB将一条记录的所有数据聚合在一个文档中，而在关系数据库中则倾向于将数据分布在多个表中。
这样做有几个好处，一是由于数据聚集，减少了多表JOIN的需求，这样只需要读一次就可以读到所有数据，在性能上会有很大优势。
另外，这种模型更加接近我们平时编程语言中的对象结构，可以方便开发者进行数据映射。
最后就是这种模型是schema-less的，也就是在MongoDB中不需要像关系数据库一样去事先定义每个表的schema。
MongoDB一个集合内的文档之间可以拥有不同的结构，可以轻松为一个新的文档添加和减少字段，不会有任何的性能影响。
这个特性非常适合开发一些新产品，可以快速迭代。
当然，过于灵活就可能导致混乱。
有时候我们想要求文档必须要有某些字段，某些字段必须要有固定的类型。
为此，MongoDB提供了一个文档验证功能来对文档的格式进行约束。
2、高可用副本集接下来说MongoDB的第二个关键特性，高可用副本集（也可以翻译成复制集）。
MongoDB副本集由一组Mongo实例（进程）组成，包含一个Primary节点和多个Secondary节点，Mongodb Driver（客户端）的所有数据都写入Primary，Secondary 从Primary同步写入的数据，以保持副本集内所有成员存储相同的数据集，提供数据的高可用。
上图是一个典型的MongDB副本集，包含一个Primary节点和2个Secondary节点。
副本集通过replSetInitiate命令（或mongo shell的rs.initiate()）进行初始化，初始化后各个成员间开始发送心跳消息，并发起Primary选举操作，获得『大多数』成员投票支持的节点，会成为Primary，其余节点成为Secondary。
这里『大多数』的定义是副本集内可投票成员的一半以上，当副本集内存活成员数量不足大多数时，整个副本集将无法选举出Primary，此时副本集将无法提供写服务，处于只读状态。
通常建议将副本集成员数量设置为奇数，因为偶数个节点能容忍的节点失效和比它少1个节点的奇数个节点是一样的，但是可以节省一个节点的数据存储成本。
除了初始化的时候会进行选举，MongoDB副本集的高可用服务体现在，当副本集中没有Primary节点时，选举都会进行。
比如当Primary节点宕机时，剩下的Secondary节点中会选举出新的Primary（只需要满足大多数成员存活的条件）。
选举使用的算法是基于Raft协议，但是可以通过为节点配置选举优先级对选举结果进行控制。
此外需要提一下，有一些比较常见的特殊的Secondary。
一个是Hidden，Hidden 节点和普通的Secondary的区别是它是对Driver隐藏的节点，也就是客户端无法访问到Hidden，另外就是它的选举优先级是0，也就是它不能被选举为Primary。
Hidden节点上拥有数据，因此通常会用来作一些运维任务，如数据备份、计算分析等。
另外还有一个是Arbiter，Arbiter是只参与投票，但是不存储数据的节点，这可以用在对可用性有要求，又要严格控制成本的场景。
此外还有如Priority0节点、Delayed节点等。
3、MongoDB的水平扩展MongoDB提供了一种水平扩展的方式，叫做sharding，通过这种方式对数据库进行扩容，对应用是透明的。
通过sharding，可以将一个集合的数据散到多个shard 节点上。
这里每个shard都可以是一组副本集。
应用程序通过一个路由节点（mongos）来访问sharding集群的数据。
有了sharding，MongoDB就可以突破单机的限制，比如磁盘、内存和IOPS等，从而提供更强大的服务能力。
Sharded cluster由Shard、Mongos和Config server 3个组件构成。
Mongos本身并不持久化数据，Sharded cluster所有的元数据都会存储到Config Server，而用户的数据则会分散存储到各个shard。
Mongos启动后，会从config server 加载元数据，开始提供服务，将用户的请求正确路由到对应的Shard。
Sharded cluster支持将单个集合的数据分散存储在多个shard上，用户可以指定根据集合内文档的某个字段即shard key来分布数据，目前主要支持2种数据分布的策略，范围分片（Range based sharding）或hash分片（Hash based sharding）。
范围分片下，文档是根据其shard key的值进行分片。
shard key的值相邻近的文档比较有可能会被放在同一个shard上，这种方式适用于需要使用范围查询的业务。
哈希分片下，文档根据其shard key的hash值进行分片。
这会保证数据分布比较均匀，但是不利于范围查询。
随着数据量的增多，MongoDB也会自动在后台对数据以chunk为单位进行负载均衡。
三、如何搭建MongoDB数据库即服务接下来介绍一下今天的重点内容，如何搭建一个MongoDB数据库即服务。
首先，在我看来，数据库即服务，应该具备这些特性：自动化、按需服务、弹性、安全、高可用和可量化：∙第一个，自动化，这是非常关键的，是实现自助服务的基础，所有可以被自动化操作的流程都应该被自动化，不需要人工干预。
∙第二个，按需服务，数据库即服务应该是由用户驱动的，后台应该要有一个工作流的机制来对需求进行响应。
∙第三个，弹性，可以按需动态扩缩容。
∙第四个，安全，这是毋庸置疑的。
∙第五个，高可用，宕机自动切换。
∙第六个，可量化，服务的使用量可以被衡量、报告并且是可控的。
此图为数据库即服务应具备的功能大图。
主要包括生命周期管理、容灾体系、监控报警、数据管理和增值服务：∙生命周期管理包括数据库实例的新建、释放、扩缩容等，这是数据库即服务最基础的功能。
∙容灾体系包括高可用、备份恢复，甚至更高级的如异地容灾/多活等等。
∙监控报警一方面就是服务使用量的监控，另一方面则是报警，包括服务不可用的报警，以及一些监控数据异常的报警。
∙数据管理指的就是可以方便的对数据进行管理，如可以提供一些图形化界面等。
∙增值服务包括审计、诊断服务等。
其中审计是数据库的一个非常重要的功能，一方面可以帮助查证问题，另一方面可以为一些数据分析或诊断提供数据源。
