liucj2004
作者liucj20042018-05-09 13:13
其它, undefined

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

字数 4317阅读 5637评论 0赞 5

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唯一的官方支持的分布式方案,无需再进行其他的方案比较。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

5

添加新评论0 条评论

Ctrl+Enter 发表

本文隶属于专栏

最佳实践
不同的领域,都有先行者,实践者,用他们的最佳实践来加速更多企业的建设项目落地。

作者其他文章

相关文章

相关问题

相关资料

X社区推广