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

Posted 2021-05-01 twt企业IT社区

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了基于 MongoDB 的分布式数据库架构 Sharding相关的知识，希望对你有一定的参考价值。

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系统中某一节点的宕机无可避免，若业务中断，往往会带来较大的损失。因此更看重系统的高可用，自动恢复时间，系统整体运行率等参数。

在线扩容

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