未加星标

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

字体大小 | |
[大数据技术 所属分类 大数据技术 | 发布者 店小二04 | 时间 | 作者 红领巾 ] 0人收藏点击收藏

基于 MongoDB 的分布式数据库架构 ShardingNosql
数据库
基于 MongoDB 的分布式数据库架构 ShardingNosql
服务器
基于 MongoDB 的分布式数据库架构 ShardingNosql
架构
基于 MongoDB 的分布式数据库架构 ShardingNosql
分布式
基于 MongoDB 的分布式数据库架构 ShardingNosql
MongoDB

1. 背景

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


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


2. Sharding架构介绍

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



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

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++,pythonphp,Ruby,shell等各种语言开发经验交流,各种框架使用,外包项目机会,学习、培训、跳槽等交流

QQ群:204132433


Hadoop源代码研究群

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

QQ群:204050420

主题: MongoDB服务器数据Nosql开源HadoopCPU硬盘SQLC++
tags: MongoDB,架构,方案,数据,数据库,Sharding,shards,节点,分布式,shard,IO,扩容,成本
分页:12
转载请注明
本文标题:基于 MongoDB 的分布式数据库架构 ShardingNosql
本站链接:https://www.codesec.net/view/576520.html


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 大数据技术 | 评论(0) | 阅读(421)