面对每天5千万的订单数据，文章提出了热数据和冷数据的划分策略。热数据存储在MySQL中进行分库分表，冷数据则使用ES、TiDB或Hive存储。分库分表策略包括按业务拆分、分表策略（如使用order_id作为sharding key）、分库策略（通过取模进行数据路由）以及结合分库分表的策略。整体架构图中，查询请求会根据数据热度走向不同存储系统，而冷数据的迁移由定时Job完成。
根据业务初步预估订单业务量，每天5千万的数据。我们将订单数据划分为了2大类型：分别为热数据和冷数据。热数据：2个星期内的订单数据，查询实时性较高;
冷数据：归档订单数据，查询频率不高;
根据实际业务场景，用户基本不会操作或查询2个星期以上的数据，如果这部分数据存储在DB中，那么成本会非常高，而且也不方便维护。另外，如果有特殊情况需要访问归档数据，可以走离线数据查看。
对于这2类数据，规划如下：
热数据：使用MySQL进行存储，分库分表；
冷数据：ES 或 TiDB或Hive存储；
MySQL 分库分表
1. 按业务拆分
在业务初始阶段，为了加快应用上线和快速迭代，很多应用都采用集中式的架构。但是随着业务系统的扩大，系统越来越复杂，越来越难以维护，开发效率变得越来越低，并且对资源的消耗也变得越来越大，通过硬件提高系统性能的成本会变得更高。
订单库也可以根据不同的业务场景，如大客户订单、散客订单等等，进行DB拆分。
将不同的业务放到不同的库中，将原来所有压力由同一个库中分散到不同的库中，提升了系统的吞吐量。
2. 分表策略
在订单表中，order_id 允许
最低0.47元/天 解锁文章
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
