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

[autumnhlf01]

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

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

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

[lmaq]

时序数据库

[AnroZ]

influxdb 试试

[autumnhlf01]

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

[StoneHuLu]

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

[StoneHuLu]

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

[autumnhlf01]

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

[autumnhlf01]

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

[StoneHuLu]

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

[StoneHuLu]

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

[StoneHuLu]

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

[autumnhlf01]

@StoneHuLu 内存管不够😂

[StoneHuLu]

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

[sujin190]

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

[autumnhlf01]

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

[sagaxu]

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

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

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

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

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

[autumnhlf01]

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

[shiny]

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

[Greendays]

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

[dcsuibian]

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

[IvanLi127]

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

[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

[highkay]

老项目的话，建议额外引入单独的“IOT 服务”组件，使用时序数据库存储，这么做就是最佳实践，系统也是相对隔离来维护的，降低总体的复杂度，然后通过批的方式把业务需要用的（主要是联查）数据插入到 mysql 里面

[OliverDD]

这种海量终端机器生成的结构化/半结构化监控数据，就是 OLAP 使用场景啊，建议上 OLAP 数据库，比如单机 duckdb 、独立数据库就 clickhouse ；也可以时序数据库。