大数据表优化处理
随着业务的发展，应用系统要提前做好数据存储规划，及时应对海量数据创建和访问压力。这篇文章根据工作中的业务场景总结了如何实现大数据表优化方案。下面先列出应用场景：
- 数据库：mysql
- 应用服务：订单服务
- 业务要求：依赖订单的其它服务不做调整，不影响线上订单交易
读写分离
实际业务中，围绕着订单的服务非常多：营销，售后，清结算等等，订单查询请求占比远大于并发写的请求。因此数据库采用主从复制架构，查询请求通过从库获取数据。在应用层面，订单查询作为一个单独的系统对外提供查询服务，具体到编码层面使用开源的sharding-jdbc作为主从数据库访问分离。
读写分离方案，减少主库访问压力。但是数据库主从复制保证最终一致性，存在延迟的问题。因此针对实时性要求较高的查询，需要从主库获取数据。
订单迁移
实际业务中，订单单表已经接近亿级。对表进行DDL操作影响在线交易，增加主从复制延迟等。由于订单交易生命周期较短，这里交易生命周期指的是状态的变化，如下图：
订单生命周期.png
普通订单3天结束，如果参与预售，拼团等营销活动，最长不超过2个月。超过订单交易生命周期的订单不会进行写操作。因此定义60天前的订单作为历史订单，并通过定时任务迁移历史订单到历史数据库。
通过迁移数据，保证主库（活动库）订单表的数据级在千万左右。
历史订单水平分表
虽然经过数据迁移，保证了主库（活动库）单表数据量减少的问题，但是历吏订单表数据仍然接近亿级。这时采用水平分表方案，具体规则如下：
- 根据订单号所在区间，存储到指定的数据库的指定表
- 订单相关的子表，存储到与订单主表有相同的表后缀的子表
- 启动定时任务，根据上面的规则把主库中的历史订单迁移到历史库中对应的子表。
通过水平分表，减少单表数据量
搜索引擎
由于历史订单采用了水平分表方案，并且仅按照订单号进行路由，对于非订单号的查询请求（例如用户名，商品名称等，下单时间等）必须便利所有的子表，影响查询性能。因此引入搜索引擎ElstaticSearch，它提供非订单号的查询请求，返回订单号，然后再根据订单号从相应的表中查询需要的详情信息。具体实施步骤如下：
- 统计查询订单的所有接口使用的查询条件
- 整理成Json结构（尽量采用扁平结构）
- 提供订单全量查询接口，返回第2步整理的json数据，此接口用于全量创建ES订单索引。（索引重建时也会用到）
- 启动定时任务，把动态迁移的历史订单同步创建ES订单索引。
- 创建ES索引成功后记录此订单号（在查询时使用）
- 删除主库中相应的订单记录。
引入搜索引擎，解决非订单号查询问题
分页查询
分页需求通常包下面几个数据：每页个数，总条数，总页数，当前页。经过上面的改造，订单数据已经拆分到3个地方：活动库，历史库和搜索引擎（对历史库创建的索引）。具体查询规则如下：
- 根据查询条件，查询活动库满足条件的总数
- 根据查询条件，查询搜索引擎满足查询条件的总数
- 根据当前请求页码及每页请求数量，计算需要返回的条数。
- 根据上面3步判断请求数据是在全部在活动库或者历史库，还是部分在活动库部分在历史库。此步操作可以抽象为两个有序集合分页算法。
- 根据第4步的结果从相应的地方获取需要的订单数据返回。
由于迁移的订单并没有及时从数据库删除，也没有及时创建ES索引，因此在1，2步查询时需要把最后一次在ES中创建索引的订单号做为查询活动库和历史库的临界值
全量备份
在实际业务中，有些部门会直接依赖订单数据库，订单数据迁移影响很大。因此提出全量备份方案，利用开源框架otter进行订单数据的准实时备份。由于历史订单会从活动库中删除，需要修改otter框架，过滤删除操作。
通过此方案，保证有全量数据库的存在，即作为一个备份，也可给其它部门直接使用。
检查任务
在数据的迁移过程中，难免会出现数据不一致的问题，比如活动库与历史库数据不一致，历史库与ES数据不一致。因此部署对应的检查任务，定时检查数据一致性。
整个解决方案，仅需要修改订单查询服务。依赖订单服务的其它服务不需要改动，同时对产线交易系统没有影响。
