炼数成金 门户 大数据 Nosql 查看内容

基于 MongoDB 的分布式数据库架构 Sharding

2018-5-16 16:37| 发布者: 炼数成金_小数| 查看: 17639| 评论: 0|原作者: 刘诚杰|来自: talkwithtrend

摘要: 随着大数据时代的到来,数据的收集存储能力得到了大幅度。与此同时,企业数据库系统的存储压力和运算压力也越发严峻。在传统的RDBMS时代,针对这个问题,大多会进行纵向扩容,比如说购买存储、机器升级等。但这种方 ...

数据库 服务器 架构 分布式 MongoDB

1. 背景
随着大数据时代的到来,数据的收集存储能力得到了大幅度。与此同时,企业数据库系统的存储压力和运算压力也越发严峻。在传统的RDBMS时代,针对这个问题,大多会进行纵向扩容,比如说购买存储、机器升级等。但这种方案很多时候不仅造成资源和时间的浪费,而且在海量数据的碰撞下仅是杯水车薪。而增加机器资源纵向扩容,横向扩容或者说分布式架构,更能支撑大数据时代的存储和算例要求。

本文主要介绍一种基于MongoDB的分布式数据库架构(Sharding)。MongoDB Sharding是官方原生的分布式方案,它可以满足数据量快速增长下的无缝扩容,也可以存储多样化非结构数据,是互联网时代下一种成熟可靠的架构。

2. Sharding架构介绍
1、MongoDB Sharding是MongoDB数据库一种水平扩展的分布式架构。由shards(存取数据,计算),config server(数据元信息、控制节点),mongos(路由,分发请求和汇聚结果)三个组件构成。


2、MongoDB Sharding架构通过添加shards节点可以平滑水平扩展,以解决单机存储、IO、计算资源不足的问题。此外可以和Hadoop生态进行对接,对大数据进行处理。其本身的replica set是基于raft协议的高可用架构,无论升级还是单机器宕机,皆可稳定提供服务。

3. 成功案例
· 奇虎360 2015年

就用户基数而言,中国前三的互联网公司

中国较大的基于安卓的移动发布平台

中国较大的互联网及移动病毒软件防护产品及服务提供商

业务与应用: 基于位置的移动搜索应用,用户认证数据的缓存层,日志分析平台等

问题:用户基数大,数据量大。存数需要快速扩容,IO也需要相对均匀分布,避免热点问题。

方案效果:目前支撑100多个应用,1,500多个实例,每天200亿次查询。中国较大的MongoDB集群之一。

· 东方航空 2016年
中国三大航空公司之一

年旅客运输量超过1亿人次,位列全球第七

航线网络通达全球177个国家、1062个目的地

业务与应用: 新一代旅客服务系统
问题: 由于客户个性化的航班查询需求出现,一次前端搜索,所带来的后端的库存和运价搜索复杂度是原来的几十倍或者上百倍。因此,该项目对系统的性能要求很高。

方案效果:系统支持了旅客的查询量每日600万次+,转换成数据库的查询量每日4500万次+。数据库数据总计720亿条,每日更新次数2600万次+,99%以上查询效率低于200ms。

· 汇丰银行 2017年
全球较大的银行及金融服务机构之一

遍布在67个国家,约有3900个分支机构

业务与应用: 运营数据管理
问题:迭代速度要求越来越快。数据格式复杂,来自不同数据源。需要弹性扩展,对SLA要求高。

方案效果: MongoDB的schema-less特性支持了汇丰微服务的架构,可快速迭代。数据库分布式集群宕机可自动恢复,不影响服务,提供给全球用户。

4.现有问题与解决方案
数据量日益增大
问题:现代企业系统每日生产的数据量越发庞大,传统的单机大容量已无法支持。而专业级存储在海量的数据下,成本也相对高昂。

解决方案:MongoDB的Sharding架构,可以直接基于x86服务器进行横向扩容。每次需要扩容时,额外增加2至3台同配置的服务器,即可简单完成扩容操作。其中1台是扩容用的服务器,另外一或两台做冗余和高可用,故只增加一台硬盘大小的容量。

系统高可用要求
问题:由于软件或者硬件问题,任何IT系统中某一节点的宕机无可避免,若业务中断,往往会带来较大的损失。因此更看重系统的高可用,自动恢复时间,系统整体运行率等参数。

解决方案:MongoDB的Sharding架构中,Mongos自身无状态,进行多点部署,程序端配置多个地址即可。也可以使用Peacemaker+Corosync进行动态vip切换。config节点基于MongoDB原生的Replication高可用架构(1主2从),该架构基于raft协议,当主节点发生宕机或者网络不可达等意外情况时,可以自动选择一台正常的节点升级为主节点继续提供服务,整个切换时间在10秒以内。shards节点也使用Replicatoin方案,根据项目高可用程度和成本考量,可以选择一主两从或者一主一从一仲裁节点的架构。

在线扩容
问题:许多IT系统在扩容时,往往需要暂停相关服务,进行配置修改和数据的迁移,但是很多业务不允许那么长的停机时间。

解决方案:MongoDB的Sharding架构由于是官方原生的架构,所以扩容时,只需要准备好服务器,安装MongoDB服务,在原来的节点上输入添加的命令即可完成整个扩容操作。整个过程无需停机,没有繁琐的配置修改和数据迁移步骤。

单机IO/CPU发生瓶颈
问题:在高并发的场景下,数据库的IO和CPU的压力会集中在单台服务器上,拖慢整个系统的速度。而由于物理设备的限制,IO和CPU性能会存在瓶颈,无法提供满意的服务。

解决方案:MongoDB的分布式架构,在合理的片键选择和应用的代码下,可以有效的将IO和CPU分散至每个节点上,以此增加总体的性能。

与大数据对接
问题:越来越多的系统引入了如Hadoop之类的大数据解决方案,但是每次从数据库抽取数据到HDFS中也需要耗费不少的代价和成本。

解决方案:MongoDB官方提供了hadoop、spark等连接件。通过该连接件,spark等可以直接将mongodb当hdfs使用,避免了资源的浪费,提高了整个系统的使用率。

5.项目实施的价值
1.企业价值
基于开源,成本较低

整套架构使用开源软件,避免相关授权等费用。有人才储备的企业,也可以自行研读源码,进行定制化修改。

方案成熟
本方案所有组件都由官方原生提供,已在各行业的生产环境中使用多年,是一个可靠成熟的架构。

可靠性高
方案中已包含高可用设计,发生异常后可以在极短时间内恢复服务

专业服务团队
很多开源软件解决方案没有官方支持,在遇到问题后容易束手无策。本方案除了使用开源软件外,可以向官方采购企业版,官方提供相关的售后支持。

对接大数据灵活
原生可以对接多种大数据处理系统,可以方便的和其他系统对接。

易建多活
Sharding中有zone的特性,此特性易于进行地区划分等多活架构设计。

2.IT人员价值
扩容便捷
shard节点的的横向扩容可以在线进行,不用额外的配置修改。数据rebalance自动进行,无需人工干预,可以快速响应业务的需求。

开发效率提升
整个mongodb是schema-less的设计,应用开发和迭代时,可以较少考虑schema带来的限制,提高开发效率。此外,本分布式架构对应用是透明的,应用只需要完成业务逻辑,存储时无需考虑具体数据的分布。

掌握最成熟的非关系型数据库技术
MongoDB在各大排行中,是全球排名第一的NoSQL数据库,遥遥领先于其他各类NoSQL数据库,是一个值得去学习和掌握的非关系型数据库技术。

生态活跃
MongoDB在全世界有着众多的社区,可以在大多数社区网站上进行问题讨论与研究。有相当多的资料可以在网上阅读,积累相关经验。

6.风险控制
在进行实施一个新的架构前,风控评估和控制是必不可少的。本章节将会梳理常见的问题,发生的条件和解决方案。

1.性能风险(shardkey)
风险点:由于选择了错误了shard key,性能降低明显,数据和IO分布不均

解决方案:mongodb sharding的shard key好比分区表的分区条件,当常见查询中未包含分区条件,那么将会在所有的shard中进行查询,极大的增加查询代价,降低效率。而且不合适的shard key会导致数据和IO分布不均匀,导致热点问题。所以需要在表设计之初,就考虑好以后常见的查询条件并选择合适的shard key。此外,shard key一旦建立就不可修改。如果要修改,只能新建一个新的集合,重新导出导入。期间,该表的相关业务会中断。

2.运维风险
风险点:当集群过大时,备份等操作难以进行

解决方案:建议控制shards在10个以内,可以按也许将shards拆分成多套,避免所有业务共用一套sharding。

3.技术风险
风险点:本方案将对较新,有一定概率遇到未知问题。

解决方案:优先使用的稳定版本或者上一个大版本的稳定版本。每次部署和升级时,做好充分的测试,避免因为各类问题导致的异常(如驱动和数据库版本不一致,加密方式不一致等)。购买官方的企业版,得到专业的售后服务。

4.项目风险
风险点:老业务从原有架构迁移至MongoDB时。需要修改部分逻辑、数据同步等,导致项目延期。

解决方案:建议技术团队先将新项目在MongoDB上部署,熟悉相关的开发技术和运维技术,然后再进行老数据迁移。老数据迁移阶段,可以将应用程序进行双写,或者使用kettle或者自行开发程序进行新老架构的数据同步。

7.成本管理
本章节将介绍实施该项目所需要的软件成本、硬件成本和人员成本

1.软件成本
操作系统可以使用开源免费的Linux发行版,MongoDB数据库可以使用社区版。整体无软件成本,但可根据企业需求,购买相应的企业版。

2.硬件成本
一套基础mongodb sharding一般由3台mongos,3台config server和9台shards组成。

mongos和config server配置和一般应用服务器一样即可。

shards服务器建议较低CPU 32线程,内存64G,全SSD硬盘 1T,raid 10,具体报价请咨询硬件供应商。

3.人员成本
MongoDB的应用开发语言非常直接明了,开发人员无需更多精力去学习,可以快速上手。由于MongoDB无模式的设计,反而可以降低开发的人力成本。

运维方面,只需要投入相关的DBA人力即可。

4.成本优化
由于软件成本和额外人力成本几乎没有,在此介绍如何节约硬件成本。

mongos:本身无状态,也可以复用,或者通过虚拟化或者docker方式部署,或者和应用部署在同一台服务器。

config server:config server资源占用较少,可以在服务器上部署多套,不同的shard集群使用同批服务器部署config server,CPU和内存需求较少,硬盘可直接使用机械盘。

shards:shards自身的replication可以采用一主一从一仲裁的架构,仲裁的服务器可以复用,并且仲裁本身不占用计算和存储资源。简单理解为一主两从简洁至一主一从。本方法保留了高可用功能,只是当某主节点宕机后可能有长时间单点风险。

8.技术选型
本方案是MongoDB的官方支持的分布式方案,无需再进行其他的方案比较。

本文作者:刘诚杰,平安好房DBA负责人。MongoDB中文社区联席主席,上海用户组主席。专注MongoDB,MySQL等开源数据库使用和研究。

欢迎加入本站公开兴趣群
软件开发技术群
兴趣范围包括:Java,C/C++,Python,PHP,Ruby,shell等各种语言开发经验交流,各种框架使用,外包项目机会,学习、培训、跳槽等交流
QQ群:26931708

Hadoop源代码研究群
兴趣范围包括:Hadoop源代码解读,改进,优化,分布式系统场景定制,与Hadoop有关的各种开源项目,总之就是玩转Hadoop
QQ群:288410967 

鲜花

握手

雷人

路过

鸡蛋

最新评论

热门频道

  • 大数据
  • 商业智能
  • 量化投资
  • 科学探索
  • 创业

即将开课

 

GMT+8, 2018-7-23 17:21 , Processed in 0.168056 second(s), 24 queries .