随着大数据时代的到来,数据的收集存储能力得到了大幅度。于此同时,企业数据库系统的存储压力和运算压力也越发严峻。在传统的RDBMS时代,针对这个问题,大多会进行纵向扩容,比如说购买存储、机器升级等。如果这个方案很多时候不仅造成资源和时间的浪费,而且在海量数据的碰撞下仅是杯水车薪。相对增加机器资源纵向扩容,横向扩容或者说分布式架构更能支撑大数据时代的存储和算例要求。
本文主要介绍一种基于MongoDB的分布式数据库架构(Sharding)。MongoDB Sharding是官方原生的分布式方案,它可以满足数据量快速增长下的无缝扩容,也可以存储多样化非结构数据,是互联网时代下一种成熟可靠的架构。
2015年
- 就用户基数而言,中国前三的互联网公司
- 中国最大的基于安卓的移动发布平台
- 中国最大的互联网及移动病毒软件防护产品及服务提供商
业务与应用: 基于位置的移动搜索应用,用户认证数据的缓存层,日志分析平台等
问题:用户基数大,数据量大。存数需要快速扩容,IO也需要相对均匀分布,避免热点问题。
方案效果:目前支撑100多个应用,1,500多个实例,每天200亿次查询。中国最大的MongoDB集群之一。
2016年
- 中国三大航空公司之一
- 年旅客运输量超过1亿人次,位列全球第七
- 航线网络通达全球177个国家、1062个目的地
业务与应用: 新一代旅客服务系统
问题: 由于客户个性化的航班查询需求出现,一次前端搜索,所带来的后端的库存和运价搜索复杂度是原来的几十倍或者上百倍。因此,该项目对系统的性能要求很高。
方案效果:系统支持了旅客的查询量每日600万次+,转换成数据库的查询量每日4500万次+。数据库数据总计720亿条,每日更新次数2600万次+,99%以上查询效率低于200ms。
2017年
- 全球最大的银行及金融服务机构之一
- 遍布在67个国家,约有3900个分支机构
业务与应用: 运营数据管理
问题:迭代速度要求越来越快。数据格式复杂,来自不同数据源。需要弹性扩展,对SLA要求高。
方案效果: MongoDB的schema-less特性支持了汇丰微服务的架构,可快速迭代。数据库分布式集群宕机可自动恢复,不影响服务,提供给全球用户。
问题:现代企业系统每日生产的数据量越发庞大,传统的单机大容量已无法支持。而专业级存储在海量的数据下,成本也相对高昂。
解决方案: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性能会存在瓶颈,无法提供满意的服务。
解决方案:MongoDB的分布式架构,在合理的片键选择和应用的代码下,可以有效的将IO和CPU分散至每个节点上,以此增加总体的性能。
问题:越来越多的系统引入了如Hadoop之类的大数据解决方案,但是每次从数据库抽取数据到HDFS中也需要耗费不少的代价和成本。
解决方案:MongoDB官方提供了hadoop、spark等连接件。通过该连接件,spark等可以直接将mongodb当hdfs使用,避免了资源的浪费,提高了整个系统的使用率。
在进行实施一个新的架构前,风控评估和控制是必不可少的。本章节将会梳理常见的问题,发生的条件和解决方案。
风险点:由于选择了错误了shard key,性能降低明显,数据和IO分布不均
解决方案:mongodb sharding的shard key好比分区表的分区条件,当常见查询中未包含分区条件,那么将会在所有的shard中进行查询,极大的增加查询代价,降低效率。而且不合适的shard key会导致数据和IO分布不均匀,导致热点问题。所以需要在表设计之初,就考虑好以后常见的查询条件并选择合适的shard key。此外,shard key一旦建立就不可修改。如果要修改,只能新建一个新的集合,重新导出导入。期间,该表的相关业务会中断。
风险点:当集群过大时,备份等操作难以进行
解决方案:建议控制shards在10个以内,可以按也许将shards拆分成多套,避免所有业务共用一套sharding
风险点:本方案将对较新,有一定概率遇到未知问题。
解决方案:优先使用最新的稳定版本或者上一个大版本最新的稳定版本。每次部署和升级时,做好充分的测试,避免因为各类问题导致的异常(如驱动和数据库版本不一致,加密方式不一致等)。购买官方的企业版,得到专业的售后服务。
风险点:老业务从原有架构迁移至MongoDB时。需要修改部分逻辑、数据同步等,导致项目延期。
解决方案:建议技术团队先将新项目在MongoDB上部署,熟悉相关的开发技术和运维技术,然后再进行老数据迁移。老数据迁移阶段,可以将应用程序进行双写,或者使用kettle或者自行开发程序进行新老架构的数据同步。
本章节将介绍实施该项目所需要的软件成本、硬件成本和人员成本
操作系统可以使用开源免费的Linux发行版,MongoDB数据库可以使用社区版。整体无软件成本,但可根据企业需求,购买相应的企业版。
一套基础mongodb sharding一般由3台mongos,3台config server和9台shards组成。
mongos和config server配置和一般应用服务器一样即可。
shards服务器建议最低CPU 32线程,内存64G,全SSD硬盘 1T,raid 10,具体报价请咨询硬件供应商。
MongoDB的应用开发语言非常直接明了,开发人员无需更多精力去学习,可以快速上手。由于MongoDB无模式的设计,反而可以降低开发的人力成本。
运维方面,只需要投入相关的DBA人力即可。
由于软件成本和额外人力成本几乎没有,在此介绍如何节约硬件成本。
mongos:本身无状态,也可以复用,或者通过虚拟化或者docker方式部署,或者和应用部署在同一台服务器。
config server:config server资源占用较少,可以在服务器上部署多套,不同的shard集群使用同批服务器部署config server,CPU和内存需求较少,硬盘可直接使用机械盘。
shards:shards自身的replication可以采用一主一从一仲裁的架构,仲裁的服务器可以复用,并且仲裁本身不占用计算和存储资源。简单理解为一主两从简洁至一主一从。本方法保留了高可用功能,只是当某主节点宕机后可能有长时间单点风险。
本方案是MongoDB唯一的官方支持的分布式方案,无需再进行其他的方案比较。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞5
添加新评论0 条评论