从零开始搭建MongoDB数据库即服务

发表于:2017-9-15 09:51

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:郑涔    来源:36大数据

  
   一、什么是数据库即服务(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数据库即服务。
  首先,在我看来,数据库即服务,应该具备这些特性:自动化、按需服务、弹性、安全、高可用和可量化:
  第一个,自动化,这是非常关键的,是实现自助服务的基础,所有可以被自动化操作的流程都应该被自动化,不需要人工干预。
  第二个,按需服务,数据库即服务应该是由用户驱动的,后台应该要有一个工作流的机制来对需求进行响应。
  第三个,弹性,可以按需动态扩缩容。
  第四个,安全,这是毋庸置疑的。
  第五个,高可用,宕机自动切换。
  第六个,可量化,服务的使用量可以被衡量、报告并且是可控的。
  此图为数据库即服务应具备的功能大图。主要包括生命周期管理、容灾体系、监控报警、数据管理和增值服务:
  ●生命周期管理包括数据库实例的新建、释放、扩缩容等,这是数据库即服务最基础的功能。
  ●容灾体系包括高可用、备份恢复,甚至更高级的如异地容灾/多活等等。
  ●监控报警一方面就是服务使用量的监控,另一方面则是报警,包括服务不可用的报警,以及一些监控数据异常的报警。
  ●数据管理指的就是可以方便的对数据进行管理,如可以提供一些图形化界面等。
  ●增值服务包括审计、诊断服务等。其中审计是数据库的一个非常重要的功能,一方面可以帮助查证问题,另一方面可以为一些数据分析或诊断提供数据源。诊断服务一方面跟踪服务的资源使用量,为是否需要扩缩容提供决策依据,另一方面主要为慢查询提供优化建议。
  
  数据库即服务的核心架构就是工作流引擎,这是实现自动化及按需服务的基础。

21/212>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号