麓山馆藏 / 科技 / 亿级订单数据分库分表设计方案(含整体架...

分享

   

亿级订单数据分库分表设计方案(含整体架构图)

2019-08-03  麓山馆藏

根据业务初步预估订单业务量,每天5千万的数据。我们将订单数据划分为了2大类型:分别为热数据和冷数据。

  • 热数据:2个星期内的订单数据,查询实时性较高;
  • 冷数据:归档订单数据,查询频率不高;

根据实际业务场景,用户基本不会操作或查询2个星期以上的数据,如果这部分数据存储在DB中,那么成本会非常高,而且也不方便维护。另外,如果有特殊情况需要访问归档数据,可以走离线数据查看。

对于这2类数据,规划如下:

热数据:使用MySQL进行存储,分库分表;

冷数据:ES 或 TiDB或Hive存储;

MySQL 分库分表

1. 按业务拆分

在业务初始阶段,为了加快应用上线和快速迭代,很多应用都采用集中式的架构。但是随着业务系统的扩大,系统越来越复杂,越来越难以维护,开发效率变得越来越低,并且对资源的消耗也变得越来越大,通过硬件提高系统性能的成本会变得更高。

订单库也可以根据不同的业务场景,如大客户订单、散客订单等等,进行DB拆分。

亿级订单数据分库分表设计方案(含整体架构图)

将不同的业务放到不同的库中,将原来所有压力由同一个库中分散到不同的库中,提升了系统的吞吐量。

2. 分表策略

在订单表中,order_id 允许重复,可以将该字段作为sharding key。假设单个库需要分配 10 张表可以满足业务需要,可以简单地取模计算出订单分配到哪张表。

亿级订单数据分库分表设计方案(含整体架构图)

一旦确定sharding key,就只能根据sharding key定位到子表进而查询该子表下的数据;如果确实想根据user_id 去查询相关订单,那么需要先根据user_id 查询映射到的order_id list,然后再根据order_id list 再查询。

3. 分库策略

数据库分表能够解决单表数据量很大的时候数据查询的效率问题,但是无法给数据库的并发操作带来效率上的提高,因为分表的实质还是在同一个数据库Server上进行的操作,很容易受数据库Server IO 性能的限制。

因此, 可以将数据进行分库操作,可以解决单台数据库Server的性能瓶颈。

分库策略与分表策略的实现很相似,最简单的都是可以通过取模的方式进行路由。

如果order_id 不是整数类型,可以先hash 在进行取模,如 hash(order_id) % DB数量。

4. 分库分表结合使用策略

数据库分表可以解决单表海量数据的查询性能问题,分库可以解决单台数据库的并发访问压力问题。有时候,我们需要同时考虑这两个问题,因此,我们既需要对单表进行分表操作,还需要进行分库操作,以便同时扩展系统的并发处理能力和提升单表的查询性能,就是我们使用到的分库分表。

如果分库和分表都使用同一个拆分键进行 Sharding 时,根据拆分键的键值按总的分表数(分库数x分表数)取余。

例如,有 2 个分库,每个分库 4 张分表,那么 0 库上保存分表 0~3,1 库上保存分表 4~7。某个键值为 15,15 % (2 * 4) = 7,所以 15 被分到 1 库的表 7 上。

亿级订单数据分库分表设计方案(含整体架构图)

整体架构图

亿级订单数据分库分表设计方案(含整体架构图)

将订单请求分为查询和更新请求,更新请求比较简单,就是根据分库分表规则写入db即可。

对于查询请求,我们需要计算出查询的是热数据还是冷数据,根据查询的时间范围计算出查询的是热数据还是冷数据。或者无法确定热数据、冷数据,就都走ES 或TiDB。

另外架构图中的冷数据指的是近期1年的数据,如果是查询一年前的数据,建议直接离线查hive即可。

图中有一个定时Job,主要用来定时迁移订单数据,需要将冷数据分别迁移到ES和hive中。

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多