根据业务初步预估订单业务量，每天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分表数）取余。
整体架构
将订单请求分为查询和更新请求，更新请求比较简单，就是根据分库分表规则写入db即可。
对于查询请求，我们需要计算出查询的是热数据还是冷数据，根据查询的时间范围计算出查询的是热数据还是冷数据。或者无法确定热数据、冷数据，就都走ES 或TiDB。
另外架构图中的冷数据指的是近期1年的数据，如果是查询一年前的数据，建议直接离线查hive即可。
图中有一个定时Job，主要用来定时迁移订单数据，需要将冷数据分别迁移到ES和hive中。
