中文
首页/案例/F6 汽车科技基于 Apache ShardingSphere 的核心业务分库分表实践

F6 汽车科技基于 Apache ShardingSphere 的核心业务分库分表实践

汽车互联网平台领域技术实践
2023/03/21by SphereEx

业务背景

F6 汽车科技,是一家专注于汽车后市场信息化建设的互联网平台公司,为维修企业开发智慧管理平台。各个维修企业(后文简称商户)之间的数据是相互隔离的,不同商户之间的数据理论上可以存储在不同库不同表。随着公司业务发展迅速,有些表的数据量增长迅速,单表总的数据量达到千万甚至亿的级别,系统越来越难以满足业务的高速发展。另外随着业务发展公司也在对系统进行拆分,按照不同域不同业务拆分成许多微服务,随之也就垂直拆分成了不同的业务库。

业务挑战

关系型数据库由于单机存储容量、连接数、处理能力都有限,容易成为系统瓶颈。从性能上看,当单表的数据量达到千万以后,由于查询维度较多,即使添加从库、优化索引,做很多操作时性能仍下降严重。此时就要考虑对其进行切分了,切分的目的就在于减少数据库的负担,缩短查询时间。另外单库的连接数有限,如果数据库查询的 QPS 过高,那么就需要通过分库来分担单个数据库的连接压力。从可用性上看,单个数据库如果发生意外,很可能会丢失所有数据,影响所有业务,分库可以隔离故障,减少业务的影响范围。

总体方案

结合公司实际情况我们选择了 ShardingSphere 实现 Sharding。按照公司现有业务逻辑,因此采用商户 ID 作为分片键(ShardingKey),保证一个商户的工单数据,分配在同一个库同一个单表中,避免了多表查询关联的性能损耗,后期分片到多个库时,可以避免跨库事务及跨库 JOIN。 商户 ID 数据库中的类型为 BIGINT(20),为了保证后续分库扩容的需求,采用基因法,选取商户 ID 最后两位作为分库基因,按照双倍扩容的规则,可以最大扩展到 64 个库中。剩余位数的值用于分表,分片到 32 个分表中。

规则如下(10545055917999668983 为某商户 ID):

105450559179996689 83 分表基因值 % 32 分库基因值 % 1

最后两位 83 用于分库,暂时数据只分片到 f6xxx 一个库中,因此余数为 0,后期数据量增加,扩展至多个库。剩余数值 105450559179996689 用于分表,首次分为 32 个单表,取模余数对应具体的分表下标,为 0~31。

screenshot-20230321-153539.png 按照公司系统现状及开发功能能快速迭代分步上线的背景,因此我们制定了先分表再拆库的方案,考虑到分库分表改动影响比较大,因此需要灰度上线,一旦有问题需要快速回滚,不能影响正常业务。具体实施步骤如下:

分表

(1)工程从 JDBC 切到 Sharding-JDBC 数据源连接方式 (2)写库业务解耦和代码迁移 (3)历史数据和增量数据同步 (4)切分表

分库

(1)读库业务迁移 (2)数据迁移 (3)切读库 (4)切写库

选择 Apache ShardingSphere 的理由

  • 社区活跃,目前已经升级至 5.0 版本,仍处于快速迭代中;
  • 成功应用案例多,京东、当当等大公司广泛应用;
  • 使用简单,Sharding-JDBC 快速集成项目,不需要部署额外服务;
  • 兼容性好,路由至单数据节点,SQL 100% 支持;
  • 性能优异,损耗低,官网有测试结果;
分享文章
wechat qrcode

扫码关注
微信公众号

某银行的数据库网关实践
中商惠⺠交易中台架构演进:对 Apache ShardingSphere 的应⽤

推荐阅读

某零售电商|一键在线拆分数亿大表

某央企|打造新一代云上数据底座,助力业务推广

某银行的数据库网关实践

F6 汽车科技基于 Apache ShardingSphere 的核心业务分库分表实践

汽车互联网平台领域技术实践

中商惠⺠交易中台架构演进:对 Apache ShardingSphere 的应⽤

通过架构重构,有效控制单表数据量,⼤幅缩减慢 SQL,下降将近 50%
即刻免费体验新一代数据库增强引擎
400-900-2818 GitHub
合作伙伴:中国信通院重庆大学ShardingSphere
Privacy PolicyTerms Of UseDisclaimerCookie PolicyDo Not Sell My Personal Information
wechat qrcode

扫码关注
微信公众号