亿级订单数据分库分表设计方案(满足多维度查询:订单号、用户、商家、渠道)

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

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

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

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

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

按业务垂直拆分

按照订单使用者拆分为3个数据库,客户端、商家端、渠道端,目的是分散压力,提高吞吐量,互不影响


业务分库

有人会问,下单的时候该怎么办呢?
下单时只写客户库,写成功后,往消息队列里面发送两个消息,一个是写商家库、一个是写渠道库

分表策略

在订单表中,可以将uid(用户ID)字段作为sharding key。假设单个库需要分配 10 张表可以满足业务需要,可以简单地取模计算出订单分配到哪张表。

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

分库策略

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

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

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

uid % 数据库数量,如:109005 % 16 = 13,分配到第13个数据库

分库分表结合使用策略

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

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

分库分表

整体架构

图片发自App

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

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

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

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

你可能感兴趣的:(亿级订单数据分库分表设计方案(满足多维度查询:订单号、用户、商家、渠道))