mysql 数据库频繁插数据的处理方案讨论

时序数据库

influxdb 试试

只能换其他数据库进行处理吗，主要项目里面用的是 MySQL 现在换成其他的数据不太好吧
@lmaq
@AnroZ

要么时序窗口聚合，要么时序数据库，但其实还是看你具体需求：你对数据的需求节点，不一定是传感器传输数据的节点，比如你展示数据是看每小时温度，那你是不是数据只存每小时的那一组就行了。

@StoneHuLu #4 其次就是先存内存或者 redis ，然后定时批量插入数据库，减少写入次数，要么就分表、对数据归档，区分冷热数据。我觉得频繁插不是啥大问题，问题是频繁插完怎么查

@StoneHuLu 这种方案也可行，只是实时性上可能会差点，就是先把秒的数据放到 redis 里面，然后整点再把这些数据处理到数据库

@StoneHuLu 我开始打算把设备 id 和时间一起当个 key ，详细内容当做 value ，如果根据时间区间来查，这样勉强也可能处理，因为时间点都是有规律的，只是我担心全放在 redis 里面，后期数据量大了以后，速度可能会慢

@autumnhlf01 #6 实时性是看你业务需求的，你要考虑你业务对实时性的敏感度如何、对数据的精度要求如何，换言之就是问一下自己：需要这么精确和即时的数据吗，对温湿度传感要求这么高，只有温控场景吧，如果只是做统计和报表，应该是无所谓的。

@autumnhlf01 #7 你这杞人忧天了，为啥数据全放 redis 上会慢，你应该考虑的是你们有没有那么大内存，只要内存管够，你全丢 redis 上也不会慢，如果实在是怕数据量过大，那很简单，定期做数据归档就好了。

另外给点建议，websocket 在客户端通知这块没法在负载均衡环境下使用，因为本身是长链接，如果以后后端服务横向扩展，这里就会出问题。一般物联网的解决方式是 websocket 连 mqtt ，后端订阅 mqtt 发送通知。不过你这个场景只是传感器发送消息到服务器单向通信，应该没这个问题，所以其实我觉得也挺怪的，为啥传感器和服务器走的是 websocket ，而不是走 mqtt ？如果走 mqtt ，你们应该就没有目前这个问题了。

@StoneHuLu 内存管不够😂

@autumnhlf01 #11 云服务器的话内存不是挺便宜的吗？我觉得你们目前对于“数据量大导致数据库有压力”、“redis 内存不够”、“redis 数据大查询慢”，都是主观臆测，有做过具体实验测试过吗

@autumnhlf01 多大量啊，批量写 mysql 每秒写入也不小，想那么多干嘛每秒合并下写完了，如果数据量大肯定要换 kafka 加其他时序或者列存数据库，折腾什么 redis mq 的纯属多余

@StoneHuLu 项目以前就因为内存原因挂掉过，次数不多就是了

原始数据不必存 MySQL ，可以按设备和日期存文件，可一次性分好类也可先顺序写入再择时归档。

当日数据存 redis ，一两天的量不至于大到存不下。按照时间粒度做聚合汇总，存入 MySQL 。

统一查询接口，查询条件必须带时间，由接口负责去不同的地方取数据拼装组合，如果取明细原始数据，那就读文件获取。

以上方案经过日请求 100 亿次的项目检验。

MySQL 写入性能其实也不低，高配机器每秒插入 10 万条也没啥压力，分库到 10 台就是 100 万/s 的性能。

@sagaxu 我觉得你的这种方案挺不错

几十秒一组也还好。真的扛不住可以先放缓存里，然后定时刷入。MySQL 批量插入的时候速度会更快点。还可以考虑优化硬件，用 IO 性能好点的磁盘。最大的问题其实是后续取数据，量非常大的时候，复杂 SQL 会很慢，之前设计的时候除了 MySQL 存一份，还会同步到类似 ClickHouse 之类的 OLAP 数据库。
而且表太大，数据库维护也麻烦，导致出现问题的时候需要很长的停机时间。

直接存数据库的压力在哪里呢？我现在也在做差不多的项目，数据是通过 MQTT 传的。

是数据库压力真的大还是仅仅你觉得大？

这有啥压力？几十秒才一组，这一组有一千条吗？有的话一千个写一个 sql 插一次也是轻轻松松。