背景
smart_gateway表是核心业务“网关表”，它支撑着新增或者重新配网的设备的核心数据。以下是，这张表各个区的数据统计。
| 区域 |
时间 |
|---|---|
| 上海 | 2015/5/26 20:43:19——2020/2/20 15:10:38 |
| 欧洲（法兰克福） | 2016/5/24 21:2:40——2020/2/20 17:21:29 |
| 印度（孟买） | 2019/3/19 20:3:40——2020/2/20 17:23:23 |
| 美西（俄勒冈） | 2015/7/7 16:9:17——2020/2/20 17:30:23 |
| 美东 | 2019/5/27 17:6:53——2020/2/20 17:34:46 |
| 西欧 | 2020/1/14 19:33:41——2020/2/20 17:35:46 |
| 合计 |
备注：统计数据，由于商业机密已删除。
分析
目前，有2100W左右为无效数据，可以将无效数据做一下归档，可以节省出近一半的资源（上海区域很夸张，1900W左右为无效数据）。
新增按照平均2秒新增1条数据（经过观察和对历史数据计算，估算出的新增频率），来计算一个月0.5*60*60*24*30=2,592,000≈130W，按照这样速度计算一年后这张表中就有5000W的数据（业务不增长过快的情况下），所以必须尽快做分库分表。
既然，做分库分表。那么，要分多少个库，多少张表呐？先按理想状态分析，一个database对应一台是数据库服务器，那么，我们假设用16个数据库存放，也就是16个数据库服务器来支撑，每个数据库存放16个smart_gateway的分表，那共有16*16=256张表存放数据，平均每张表存20W条数据，按照这个新增效率10年也无压力。这样，分法有一个好处，后期扩容，将数据库直接copy平滑迁移，理论最大可扩容16台服务器。
另外，这张表冗余了很多字段，有47个字段，属于一张大宽表，这也是另一个读写瓶颈所在，后续可以做调研，如果，改造成本不大可以把大宽表做拆分（表结构如下图）。
方案
具体方案如下（随时改进）：
- 新建一张smart_gateway_archive归档表，表结构和smart_gateway相同。
- 开发一个定时同步数据的工具，将status=0的数据进行归档并且删除smart_gateway中status=0的数据。
————————————————————————————————————————————
- 纵向拆分表结构（根据改造成本，系统依赖复杂度，待定）。
————————————————————————————————————————————
- 为了节省服务器资源，先用4台服务器，每台服务器创建4个database，每个database内创建16个smart_gateway表。
- 路由算法：对smart_gateway表选择分布式主键ID，库号 = ID%库数量，表号 = ID/库数量%表数量。用库号和表号来定位具体要同步的表。
- 改造依赖smart_gateway的应用，实现老新表双写。
- 需要开发一个导数据的中间件，中间件功能如下：
1.查询老smart_gateway表数据，根据路由算法同步到新smart_gateway表，同步前先查询新表中数据是否存在，不存在同步，存在判断是否有改动，有改动则更新。
2.compare功能，开发定时任务，定时从老smart_gateway表中查询数据和新smart_gateway进行比较，校准数据。
3.做好中间件同步数据的监控日志，记录下所有的同步和更新失败。
- 跑一段时间后，检查新（集群总的数据量）老表数据总数据量，是否相同，如果相同，可将中间件的同步老数据功能下掉，保留定时compare功能。
- 定时compare再跑一段时间后，可检查最新数据情况，没疑问，可以停掉中间件，修改代码将应用切到新数据库表上。
- 补充：路由中间件可选mycat、tddl、sharding-jdbc等等。
实施计划
后续补充
PS
smart_device_module表数据量比smart_gateway还有多一些，大概是smart_gateway的1.5倍，做smart_gateway策略时，应该把smart_device_module一起做掉。