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

[autumnhlf01]

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

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

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

[andytao]

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

[hgc81538]

Are

[csys]

我怎么感觉不久前才看到过这个问题

https://v2ex.com/t/1093560#reply122

> 这种技术方案在遥测领域有很多
粗看下来我的直觉方案是：
缓冲（内存+本地），使用 WAL
批量填入 tsdb
甚至可以不写入 tsdb ，取决于你有多少传感器，如果是有限数量的话，可以直接写入文件，看使用数据的场景来决定是否需要 parquet+bloom filter
如果传感器数量很多又是动态的话，可以使用云对象存储来做

无论如何用关系型数据库来做这事情是非常不合适的，麻烦的还在后面呢

[autumnhlf01]

@csys 他这个数据量太大，我还没达到那么恐怖的层级

[autumnhlf01]

@andytao 后续是有点不太好处理，MySQL 数据库我这边上百万的数据后，单纯查询数量都不快，也不知道是不是表的设计有啥问题

[sagaxu]

@autumnhlf01 百万慢一定是设计问题，实测单表 10 亿是不该慢的

[des]

@sagaxu @csys 我们也有这种需求，你要放两处的话查询又是个麻烦事情。比如说查询同时符合符合 A 、B 、C 条件的，AB 在关系型库里面，事先查出来符合 AB 的列表又比较大，AB 条件和 C 放到一起 AB 的更新又是个问题

[lqw3030]

可以从该批数据的末端使用业务反推，如果可以聚合就在边缘采集设备聚合

[adoal]

几十秒一组数据就怕普通的关系数据库压力太大，这是在侮辱谁呢

[wxiao333]

数据上千万之后，如果你的业务查询稍微复杂一点，mysql 速度不管怎么优化都跟不上了
时序历史数据放时序数据库，普通业务数据放关系数据库，这很正常的操作，就像热点数据要放 redis 一样，不也是引入一种新数据库吗？

[sagaxu]

@des 我们的方案是，约束查询条件，约束不了的时候使用从库使劲儿造，后来从库也满足不了，上了套 hadoop 集群，遍历个几十个 GB 的数据小意思

[bugu1986]

非得当民科，不用时序数据库？

[gainsurier]

单台 pc ，30 万点规模，测点 10%变化率，即时变化和 5 分钟定时存储，influxdb 轻轻松松。

[autumnhlf01]

@bugu1986 有一部分原因是都是一些老项目，数据库这种东西一般不会轻易改变，还有就是时序数据库很多人可能都没听过

[qping]

几十秒一组有什么压力，mysql 处理这点数据不轻轻松松？你有测试过吗

[autumnhlf01]

@qping 肯定不是只有这一个在操作数据库，如果只有它一个操作数据库，就不用纠结了，是在原有项目的基础上添加的功能

[huzhizhao]

长痛不如短痛，上时序

[netnr]

引入 DuckDB "组件"

[bruce0]

前两天刚和公司的一个同事讨论过这个问题,他们组的项目的上报比你们这更频繁,而且量级应该也比你们的大, 不同的是写入 MongoDB, 云 MongoDB 最大 2000 个链接, 有时候都能用完,导致链接超时. 我们也不想改现有的架构,更不想换数据库.

后来是引入 redis. 上报的先写入 redis, 相同的数据会被新的覆盖,不会无限叠加 然后起一个新的线程,定时消费 redis 的数据,写入 MongoDB, 因为这些数据没有实时的要求,也不是特别重要, redis 真崩了,丢了问题也不大

[opengps]

我的经典答复，那时候甚至没有这么流行用时序存储 https://www.opengps.cn/Blog/View.aspx?id=284