为什么要分库分表,如何选择合适的方案

/ 0评 / 0

为什么要分库分表,如何选择合适的方案

背景

  由于业务量突增,加上过亿的表数据查询日渐顶不住业务访问,我们想到的第一个办法就是分库分表,而分库分表的方案五花八门,尤其是经典Sharding JDBC对代码的入侵很是严重,我们迫切需要分表的方案,所以在此背景下我们开始了一系列的调研。

方案调研

Apache ShardingSphere(JDBC-Proxy)

简介:
GitHub:https://github.com/apache/incubator-shardingsphere
官方文档:https://shardingsphere.apache.org/document/current/cn/overview/

  作为Apache基金会的分布式数据库中间件项目-ShardingSphere将针对数据水平&垂直拆分、分布式事务、数据服务治理、数据安全等需求提供一套适用于互联网应用架构、云服务架构的多解决方案生态圈。
  Apache ShardingSphere是一款开源的分布式数据库中间件组成的生态圈。自从2016年开源以来,不断升级开发新功能、重构稳定微内核,并于2018年11月进入Apache基金会孵化器。
  它由京东集团主导,并由多家公司以及整个ShardingSphere社区共同运营参与贡献。其主要的功能模块为:数据分片(分库分表)、分布式事务、数据库治理三大块内容。

使用

这里我不多粘了,文档很棒很清晰,GitHub Issue回复及时可以直接参考
https://shardingsphere.apache.org/document/current/cn/features

优缺点总结

优点:
1. 文档完整,有大厂背书,开源氛围良好
2. 分布式解决方案完整

缺点:(JDBC-Proxy的共同缺点)
1. DB 不透明(BI头大)
2. 分表本质影响写入性能
3. 代码入侵性高,原先写的都需要兼容

MyCat(DB-Proxy)

简介:
官网:http://www.mycat.org.cn/ (这官网是认真的吗?一股浓浓的A货风范...天桥500拍黄片建个站吗?好了我们就事论事)

Github:https://github.com/MyCATApache/Mycat-Server (issue怎么感觉15年是刷的...5000亿数据都来了,我要是选技术框架肯定不选这个...看着就很不对劲)

Mycat是基于开源cobar演变而来,对cobar的代码进行了彻底的重构,使用NIO重构了网络模块,并且优化了Buffer内核,增强了聚合,Join等基本特性,同时兼容绝大多数数据库成为通用的数据库中间件。1.4 版本以后 完全的脱离基本cobar内核,结合Mycat集群管理、自动扩容、智能优化,成为高性能的中间件。致力于开发高性能数据库中间而努力。永不收费,永不闭源,持续推动开源社区的发展。
Mycat吸引和聚集了一大批业内大数据和云计算方面的资深工程师,Mycat的发展壮大基于开源社区志愿者的持续努力,感谢社区志愿者的努力让Mycat更加强大,同时也欢迎社区更多的志愿者,特别是公司能够参与进来,参与Mycat的开发,一起推动社区的发展,为社区提供更好的开源中间件。

看完人家的Readme.md我不想探究了,这个模块我要CV了...上下都透露着他们对于这个浓浓的自豪和自信...我一直认为靠谱的中间件从来都是解决问题出发,而非使用了的“高大上”的技术和方案。吐槽归吐槽,该粘贴的咱继续粘贴。

使用:

在认真阅读了README.md了之后我觉得这个肯定不适合大部分靠谱的Spring项目。不是偏见,而是因为复杂,前面也已经写了两篇了,但是这个从简介来看他们连门面示意图都画的那么粗糙,我觉得问题不只是复杂,还有使用传统xml且无法和配置中心结合(将DB配置塞明文塞到server.xml 2020我干不出这么不优雅的事情,虽然提供了Zk的管理方案但是为啥要用Zk呢?为啥呢为啥呢为啥呢?)。可能这些都是第一印象的偏见,我在文档有附上他们的指引文档(扫了一部分很完整但是却很混乱),其实还是做的一款比较完整的中间件,但是对于我们用处不大(我们很着急)

优缺点总结:
优点:
我没细心钻研,没发现他能在我列的这几个里面突显的优点。

缺点:
1. 接入繁琐
2. 落地大厂少,出事可能除了他们的PDF真就没办法了
3. 链路过长,好好的非得Proxy,把简单是干复杂了,每层都是在增加响应时间好不

PolarDB(DB-Based)

简介:

  PolarDB是阿里云自研的下一代关系型云数据库,兼容MySQL、PostgreSQL、Oracle引擎,存储容量最高可达100TB,单库最多可扩展到16个节点,适用于企业多样化的数据库应用场景。
  PolarDB采用存储和计算分离的架构,所有计算节点共享一份数据,提供分钟级的配置升降级、秒级的故障恢复、全局数据一致性和免费的数据备份容灾服务。PolarDB既融合了商业数据库稳定可靠、高性能、可扩展的特征,又具有开源云数据库简单开放、自我迭代的优势。
  PolarDB兼容Oracle数据库提供公共云和专有云形态,其中专有云形态支持CentOS、UOS、麒麟等操作系统,支持X86架构CPU以及ARM架构CPU(飞腾等)。 

使用:

PolarDB本质上是数据源的切换,相当于从原先的RDS切换到了PolarDB,所以在项目配置当中只需要像正常配置JDBC连接一样即可,对于线上的一键切换方案可以利用Spring动态数据源的做这件事,其实相对是比较简单的,我们需要的就是买买买和改改DB连接。其中有些部分概念如下表:

集群 Cluster PolarDB采用集群架构,一个集群包含一个主节点和多个读节点。集群可以跨可用区(AZ),不能跨地域(Region)。 集群 Cluster
节点 Node PolarDB集群由多个物理的节点构成,目前每个集群中的所有节点可分为两类,分别为主节点(Writer)和只读节点(Reader)。每类节点关系对等,规格相同。 节点 Node
主节点 Writer 主节点,也叫读写节点,一个集群有一个主节点,可读可写。 主节点 Writer
读节点 Reader 只读节点,一个集群最多15个。 读节点 Reader
故障切换(主备切换) Failover 提升一个只读节点为主节点。 故障切换(主备切换) Failover
规格 Class 每个节点的资源配置,例如2核4GB。 规格 Class
访问点 Endpoint 访问点(Endpoint)定义了数据库的访问入口,也可以称之为接入点。一个集群提供多个Endpoint,每个Endpoint后面接一个或多个节点。例如,主访问点永远指向主节点,集群Endpoint提供了读写分离能力,后挂主节点和只读节点。Endpoint中主要包含的是数据库链路属性,例如读写状态、节点列表、负载均衡、一致性级别等配置信息。 访问点 Endpoint
访问地址 Address 访问地址是访问点在不同网络平面中的载体,一个Endpoint可能包含私网和公网两种访问地址。访问地址中包含了一些网络属性,例如,域(Domain)、IP地址、专有网络 (VPC)、交换机(VSwitch)等。 访问地址 Address
主访问点(主地址) Primary Endpoint 主节点(Writer)的访问点,当发生故障切换(Failover)后,会自动指向到新的主节点。 主访问点(主地址) Primary Endpoint
集群访问点(集群地址) Cluster Endpoint 整合集群下所有节点,对外提供一个统一的访问入口,可以设置为只读或可读可写(自动读写分离),具有自动弹性、读写分离、负载均衡、一致性协调等能力。 集群访问点(集群地址) Cluster Endpoint
地域 Region 地域是指物理的数据中心。一般情况下,PolarDB集群应该和ECS实例位于同一地域,以实现最高的访问性能。 地域 Region
可用区 Availability Zone(AZ) 可用区是指在同一地域内,电力和网络互相独立的物理区域。在同一地域内可用区与可用区之间内网互通,可用区之间能做到故障隔离。 可用区 Availability Zone(AZ)
主可用区 Primary AZ PolarDB主节点所在可用区。 主可用区 Primary AZ
集群可用区 Cluster AZ 集群数据分布的可用区。一个集群的数据会自动在两个可用区间做冗余,用于灾难恢复。只支持在这些可用区间进行节点迁移。 集群可用区 Cluster AZ
集群 Cluster PolarDB采用集群架构,一个集群包含一个主节点和多个读节点。集群可以跨可用区(AZ),不能跨地域(Region)。 集群 Cluster

其大致结构如图:
UTOOLS1593353447660.png
更多详细的情况可以直接去阿里云的官网查看,文章末尾也写了连接,可以直接点

优缺点总结:

优点:
1. 容量大,Parallel-Raft协议
2. 读一致性,读写分离
3. 多可读节点,一写多读
4. 项目切换简单,语言兼容性相较于前面几款要好的多

缺点:
1. 贵
2. 同步数据也花钱
3. 大厂落地经验少,不像开源软件文档多Issue有人理,一出事除了找阿里云客服之外叫天天不应叫地地不灵

最终选定

  在最后的关头我们当然是选择PolarDB了....也就是约等于没敢分。为什么?因为需要重写查询,对应的重构成本较高,而使用PolarDB我们则可以利用读写分离来减轻一部分压力,但是慢查依旧存在怎么办?当然是能优化索引就优化索引,无法优化索引的话我们自然也有办法:通过ElasticSearch的引入来解决查询慢的情况,将繁重的查询转移到Es上面,这一样一来PolarDB的节点压力就更小了。显然这次的方案选择并不是很多,只是有几个比较有代表性的,其实有更多(TDDL/Zebra/Vitess/Atlas...等等),多的原因是我们需要在十五天之内上线,其实打心底我是比较支持Sharding-JDBC的,总体上如果时间比较充裕,我肯定会选择Sharding-JDBC。

参考文档

  1. Sharding-JDBC 使用入门和基本配置
  2. 分布式数据库中间件Apache ShardingSphere京东落地实战
  3. Mycat权威指南
  4. 云数据库 PolarDB

发表评论

电子邮件地址不会被公开。 必填项已用*标注