IoT设备表分库分表实战

背景

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一起做掉。