请教个问题，类似温度，湿度硬件对接的时候，数据通过 websocket 获取，这些数据每隔几十秒就会传一组过来，咋处理这些数据？直接存数据库吗，这样数据库压力也太大了，通过 mq 的方式来存储，但是最终还是要插入数据库，还是会造成数据库压力
我的想法是 把数据直接放到 redis 里面，但是越到后期，数据也会很多，查询也不太好查吧？
没咋处理过这种场景，一时间没啥头绪，特来问问 v 友，有没有实际处理过类似问题的，求教
 |
1
lmaq 14 天前
时序数据库
|
 |
2
AnroZ 14 天前
influxdb 试试
|
 |
3
autumnhlf01 OP |
 |
4
StoneHuLu 14 天前
要么时序窗口聚合，要么时序数据库，但其实还是看你具体需求：你对数据的需求节点，不一定是传感器传输数据的节点，比如你展示数据是看每小时温度，那你是不是数据只存每小时的那一组就行了。
|
|
5
StoneHuLu 14 天前  1
@StoneHuLu #4 其次就是先存内存或者 redis ，然后定时批量插入数据库，减少写入次数，要么就分表、对数据归档，区分冷热数据。我觉得频繁插不是啥大问题，问题是频繁插完怎么查
|
|
6
autumnhlf01 OP @StoneHuLu 这种方案也可行，只是实时性上可能会差点，就是先把秒的数据放到 redis 里面，然后整点再把这些数据处理到数据库
|
|
7
autumnhlf01 OP @StoneHuLu 我开始打算把设备 id 和时间一起当个 key ，详细内容当做 value ，如果根据时间区间来查，这样勉强也可能处理，因为时间点都是有规律的，只是我担心全放在 redis 里面，后期数据量大了以后，速度可能会慢
|
|
8
StoneHuLu 14 天前
@autumnhlf01 #6 实时性是看你业务需求的，你要考虑你业务对实时性的敏感度如何、对数据的精度要求如何，换言之就是问一下自己：需要这么精确和即时的数据吗，对温湿度传感要求这么高，只有温控场景吧，如果只是做统计和报表，应该是无所谓的。
|
|
9
StoneHuLu 14 天前
@autumnhlf01 #7 你这杞人忧天了，为啥数据全放 redis 上会慢，你应该考虑的是你们有没有那么大内存，只要内存管够，你全丢 redis 上也不会慢，如果实在是怕数据量过大，那很简单，定期做数据归档就好了。
|
|
10
StoneHuLu 14 天前
另外给点建议，websocket 在客户端通知这块没法在负载均衡环境下使用，因为本身是长链接，如果以后后端服务横向扩展，这里就会出问题。一般物联网的解决方式是 websocket 连 mqtt ，后端订阅 mqtt 发送通知。不过你这个场景只是传感器发送消息到服务器单向通信，应该没这个问题，所以其实我觉得也挺怪的，为啥传感器和服务器走的是 websocket ，而不是走 mqtt ？如果走 mqtt ，你们应该就没有目前这个问题了。
|
|
11
autumnhlf01 OP @StoneHuLu 内存管不够😂
|
|
12
StoneHuLu 14 天前
@autumnhlf01 #11 云服务器的话内存不是挺便宜的吗？我觉得你们目前对于“数据量大导致数据库有压力”、“redis 内存不够”、“redis 数据大查询慢”，都是主观臆测，有做过具体实验测试过吗
|
 |
13
sujin190 14 天前 via Android
@autumnhlf01 多大量啊，批量写 mysql 每秒写入也不小，想那么多干嘛每秒合并下写完了，如果数据量大肯定要换 kafka 加其他时序或者列存数据库，折腾什么 redis mq 的纯属多余
|
|
14
autumnhlf01 OP @StoneHuLu 项目以前就因为内存原因挂掉过，次数不多就是了
|
 |
15
sagaxu 14 天前
原始数据不必存 MySQL ，可以按设备和日期存文件，可一次性分好类也可先顺序写入再择时归档。
当日数据存 redis ，一两天的量不至于大到存不下。按照时间粒度做聚合汇总，存入 MySQL 。 统一查询接口，查询条件必须带时间，由接口负责去不同的地方取数据拼装组合，如果取明细原始数据，那就读文件获取。 以上方案经过日请求 100 亿次的项目检验。 MySQL 写入性能其实也不低，高配机器每秒插入 10 万条也没啥压力，分库到 10 台就是 100 万/s 的性能。 |
|
16
autumnhlf01 OP @sagaxu 我觉得你的这种方案挺不错
|
 |
17
shiny 13 天前
几十秒一组也还好。真的扛不住可以先放缓存里，然后定时刷入。MySQL 批量插入的时候速度会更快点。还可以考虑优化硬件，用 IO 性能好点的磁盘。最大的问题其实是后续取数据，量非常大的时候，复杂 SQL 会很慢，之前设计的时候除了 MySQL 存一份，还会同步到类似 ClickHouse 之类的 OLAP 数据库。
而且表太大，数据库维护也麻烦，导致出现问题的时候需要很长的停机时间。 |
 |
18
Greendays 13 天前
直接存数据库的压力在哪里呢？我现在也在做差不多的项目，数据是通过 MQTT 传的。
|
 |
19
dcsuibian 13 天前
是数据库压力真的大还是仅仅你觉得大？
|
 |
20
IvanLi127 13 天前
这有啥压力？几十秒才一组，这一组有一千条吗？有的话一千个写一个 sql 插一次也是轻轻松松。
|
 |
21
andytao 13 天前
得研究数据的特点和后续的需要，不同情况的处理方案不同；
|
 |
22
hgc81538 13 天前 via iPhone
Are
|
 |
23
csys 13 天前
我怎么感觉不久前才看到过这个问题
https://v2ex.com/t/1093560#reply122 > 这种技术方案在遥测领域有很多 粗看下来我的直觉方案是： 缓冲（内存+本地），使用 WAL 批量填入 tsdb 甚至可以不写入 tsdb ，取决于你有多少传感器，如果是有限数量的话，可以直接写入文件，看使用数据的场景来决定是否需要 parquet+bloom filter 如果传感器数量很多又是动态的话，可以使用云对象存储来做 无论如何用关系型数据库来做这事情是非常不合适的，麻烦的还在后面呢 |
|
24
autumnhlf01 OP @csys 他这个数据量太大，我还没达到那么恐怖的层级
|
|
25
autumnhlf01 OP @andytao 后续是有点不太好处理，MySQL 数据库我这边上百万的数据后，单纯查询数量都不快，也不知道是不是表的设计有啥问题
|
|
26
sagaxu 13 天前
@autumnhlf01 百万慢一定是设计问题，实测单表 10 亿是不该慢的
|
 |
27
des 13 天前 via iPhone
|
 |
28
lqw3030 13 天前
可以从该批数据的末端使用业务反推，如果可以聚合就在边缘采集设备聚合
|
 |
29
adoal 13 天前
几十秒一组数据就怕普通的关系数据库压力太大，这是在侮辱谁呢
|
 |
30
wxiao333 13 天前
数据上千万之后，如果你的业务查询稍微复杂一点，mysql 速度不管怎么优化都跟不上了
时序历史数据放时序数据库，普通业务数据放关系数据库，这很正常的操作，就像热点数据要放 redis 一样，不也是引入一种新数据库吗？ |
 |
32
bugu1986 13 天前 via iPhone
非得当民科，不用时序数据库？
|
 |
33
gainsurier 13 天前 via iPhone
单台 pc ，30 万点规模，测点 10%变化率，即时变化和 5 分钟定时存储，influxdb 轻轻松松。
|
|
34
autumnhlf01 OP @bugu1986 有一部分原因是都是一些老项目，数据库这种东西一般不会轻易改变，还有就是时序数据库很多人可能都没听过
|
 |
35
qping 13 天前
几十秒一组有什么压力，mysql 处理这点数据不轻轻松松？你有测试过吗
|
|
36
autumnhlf01 OP @qping 肯定不是只有这一个在操作数据库，如果只有它一个操作数据库，就不用纠结了，是在原有项目的基础上添加的功能
|
 |
37
huzhizhao 13 天前
长痛不如短痛，上时序
|
 |
38
netnr 13 天前
引入 DuckDB "组件"
|
 |
39
bruce0 13 天前
前两天刚和公司的一个同事讨论过这个问题,他们组的项目的上报比你们这更频繁,而且量级应该也比你们的大, 不同的是写入 MongoDB, 云 MongoDB 最大 2000 个链接, 有时候都能用完,导致链接超时. 我们也不想改现有的架构,更不想换数据库.
后来是引入 redis. 上报的先写入 redis, 相同的数据会被新的覆盖,不会无限叠加 然后起一个新的线程,定时消费 redis 的数据,写入 MongoDB, 因为这些数据没有实时的要求,也不是特别重要, redis 真崩了,丢了问题也不大 |
 |
40
opengps 12 天前
我的经典答复，那时候甚至没有这么流行用时序存储 https://www.opengps.cn/Blog/View.aspx?id=284
|
 |
41
highkay 12 天前
老项目的话，建议额外引入单独的“IOT 服务”组件，使用时序数据库存储，这么做就是最佳实践，系统也是相对隔离来维护的，降低总体的复杂度，然后通过批的方式把业务需要用的（主要是联查）数据插入到 mysql 里面
|
 |
42
OliverDD 12 天前
这种海量终端机器生成的结构化/半结构化监控数据，就是 OLAP 使用场景啊，建议上 OLAP 数据库，比如单机 duckdb 、独立数据库就 clickhouse ；也可以时序数据库。
|
Select Language