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

请教个问题，类似温度，湿度硬件对接的时候，数据通过 websocket 获取，这些数据每隔几十秒就会传一组过来，咋处理这些数据？直接存数据库吗，这样数据库压力也太大了，通过 mq 的方式来存储，但是最终还是要插入数据库，还是会造成数据库压力

我的想法是 把数据直接放到 redis 里面，但是越到后期，数据也会很多，查询也不太好查吧？

没咋处理过这种场景，一时间没啥头绪，特来问问f友，有没有实际处理过类似问题的，求教

我怎么感觉不久前才看到过这个问题 https://fex.com/t/1093560#reply122 > 这种技术方案在遥测领域有很多 粗看下来我的直觉方案是： 缓冲（内存+本地），使用 WAL 批量填入 tsdb 甚至可以不写入 tsdb ，取决于你有多少传感器，如果是有限数量的话，可以直接写入文件，看使用数据的场景来决定是否需要 parquet+bloom filter 如果传感器数量很多又是动态的话，可以使用云对象存储来做 无论如何用关系型数据库来做这事情是非常不合适的，麻烦的还在后面呢

Are

得研究数据的特点和后续的需要，不同情况的处理方案不同；

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

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

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

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

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

原始数据不必存 MySQL ，可以按设备和日期存文件，可一次性分好类也可先顺序写入再择时归档。 当日数据存 redis ，一两天的量不至于大到存不下。按照时间粒度做聚合汇总，存入 MySQL 。 统一查询接口，查询条件必须带时间，由接口负责去不同的地方取数据拼装组合，如果取明细原始数据，那就读文件获取。 以上方案经过日请求 100 亿次的项目检验。 MySQL 写入性能其实也不低，高配机器每秒插入 10 万条也没啥压力，分库到 10 台就是 100 万/s 的性能。