针对目前业务的高并发高数据量需求解决方案

场景描述

• 5s 时间间隔推送坐标
• 在坐标序列中计算时间，轨迹

目前遇到的问题

• 数据量巨大，关系数据库不适用
• 并发量，需要上万并发支持
• 流量比较大

数据量估计

假设 100 在线，5s 推送一次，一天 10 小时预估，一个月数据量：
100 * 10 * 60 * 60 * 30 / 5 = 21600000
按照这个设计，一年达到 2.5 亿
如果终端并发量 1w，那么两天数据量达到亿级别

目前我的解决方法

• Mysql 分库分表
• 使用新数据库替代 Mysql
• 基于文件中间件开发
• 数据冷热分离

1. Mysql 分库分表

如果数据量还在我们的可控范围，那么数据库的分表分库是最为明显的，这里能否分表分库的一个关键是维度问题

• 以终端作为查询维度
• 以人员作为查询维度

不同的人员可以持有不同的终端，必要的时候，需要做数据 merge
即使如此，Mysql 单表也尽量控制在 1 亿级别

2. 新数据库支持

这里提供如下的几个存储组件：

• Pingcap 的 TiDB
• MongoDB
• ELK 家族的 Elasticsearch

我建议是在构建大量测试数据情况下，做一个 qps 测试

3. 基于文件的中间件开发

这个对技术要求比较高，在目前信息有限下的设想：

• 使用文件顺序写，记录终端坐标文件，Append 方式写
• 每一个已经产生的数据，都是不可修改
• 业务数据，比如操作者，作为 Meta 数据记录在数据库
• 使用 Merge 等方式，合并多个终端的数据输出

数据冷热分离

从目前的数据量来看，挑战在于行记录，和流量

• 在有限硬件下，及时查询，和报表式结果输出需要分开
• 把数据切分成冷热数据，尽量把好的硬件条件分配到热数据
• 离线生成报表，可以在低峰时期生成，比如凌晨 0-6 点间

我的建议

如果确实按照目前的数据量，关系数据库基本不可行
确定需求，以便决定分库分表，或者新数据库是否支持
生成大量数据测评，以便确定是否可行