es数据迁移_亿级订单数据分库分表如何设计（中）

  点击上方“Java半颗糖”，关注公众号

设为“星标”，好文章不错过！

背景介绍

---

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

• 热数据：2个星期内的订单数据，查询实时性较高

• 冷数据：归档订单数据，查询频率不高

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

知识补充

• 离线数据：该数据流日常周期性的(每周执行一次/每日执行一次/每小时执行一次)。

  大致分析流程：从不同数据源获取数据、Hadoop集群数据、计算(Hive、Spark、MapReduce)、数据展示(T+1计算)

• 实时数据：该数据流一直保持运行状态实时的抽取(pull/push方式)数据源的数据，并在毫秒/秒级别写入存储引擎，在数据使用以及传输上达到实时效果。

  大致分析流程：业务数据、消息队列、Storm实时编程、Redis、数据展示(秒级计算)

对于热点数据和冷数据，规划如下：

• 热数据：使用MySQL进行存储，分库分表

• 冷数据：ES(存储量可达到PB级)或者Hive存储

MySQL分库分表

---

一、按业务拆分

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

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

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

二、分表策略

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

一旦确定sharding key，就只能根据sharding key 定位到子表下的数据，如果确实想根据user_id查询相关订单，那么需要先根据user_id查询映射到的order_id集合，再根据对应的order_id再查询。

 三、分库策略

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

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

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

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

四、分库分表结合使用策略

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

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

案例分析

---

假如有2个分库，每个分库4张分表，那么

• 0库上保存分表0~3

• 1库上保存分表4~7

某个键值为15，则拆分键为 15%(2*7)= 7,所以15被分配到了1库的表7上。

分库分表整体流程架构

---

流程将订单请求分为查询和更新请求：

• 更新请求：比较简单，就是根据分库分表规则写入DB即可。

• 查询请求：我们需求计算出查询的是热数据还是冷数据，根据查询的时间范围计算出查询的是热数据还是冷数据，或者无法确定的热数据、冷数据就都走ES.

一般情况下，冷数据指的是近期一年的数据，如果查询一年前的数据，建议直接离线查询Hive即可。

同时，我们可以通过定时任务来定时的迁移订单数据，需要将冷数据分别迁移到ES和Hive中。

看完之后觉得有帮助的还请不吝转发分享。

欢迎关注公众号一起交流：