一个程序开发问题请教各位 V 友大佬，每秒 10 万条数据需要存储，怎样选择技术方案

[morota]

物联网传感器发送的数据，走 tcp 或者 mqtt ，每秒大概有 10 万条，每条数据大概 20 个字节大小(5 个 int 值) 现在的问题是：服务端如何保存这些数据。

1, 用什么数据库，如何高频插入 2, 服务器选什么样的配置，来配合数据插入。CPU ，内存，硬盘需要多大。

请各位大佬不吝指教

[asmoker]

ck

[kenneth104]

非程序员
加缓冲层，1 层不够再来 1 层

[FanError]

先扔到消息队列里，再慢慢消费。

[rockxsj]

1 、日志服务器收到之后先落地本地文件
2 、fluentbit watch 本地文件然后发送到 kafka
3 、写个程序从 kafka 消费写入到最终数据库 starrocks

[hxzhouh1]

好像有个国产消息队列 TDengine ， 专门应对这种物联网场景的

[morota]

@FanError 消息队列的话，内存是不是需要配置很大的内存，否则会爆？

[morota]

@rockxsj 消息队列的话，内存是不是需要配置很大的内存，否则会爆？

[saintatgod]

1. 使用时序数据库或者 nosql ，或者 pgsql 这样的数据库，使用队列异步去消费这些数据，插入时候可以批量插入，最好在插入前对数据库进行好分区，然后按照分区读写。
2. 服务器的话需要 16 核的 CPU ， 内存按照 32-64 来搞，硬盘的话，你这个量级如果没有估算错，至少 1T ，另外就是带宽搞大一点。
基本上就这样。

[E520]

@morota 这也要看你的消费处理速度，消费的快，那堆积内存就不大， 你可以算一下 1 秒 10 万条数据，占多少内存，去计算就行了

[morota]

@saintatgod 感谢大佬，算了一下带宽至少需要 10M ，对吗？

[rockxsj]

@morota #7 kafka 是顺序写入硬盘的，不需要内存很大，硬盘大写就行了

[tool2dx]

搜了一下，一般正规一点的 E5 服务器（ 24 核心+24G 内存），mysql 每秒能支持到 117 万的请求。

当然他测试客户端没那么多，你是物联网，tcp 来源比较碎片化，性能可能要打折。

感觉优先走分布式，一个机房宽带顶不住啊。

[tool2dx]

@morota “感谢大佬，算了一下带宽至少需要 10M ，对吗？”

肯定不是按照字节来算。你要根据终端数量的 tcp ip 封包切割来算。哪怕只是 20 字节，频繁握手对于带宽的压力也不小。

[vkillwucy]

kafka + flink + starrocks 大数据套件搞起来

[KOMA1NIUJUNSHENG]

搞不懂和大数据有什么关系，这种物联网硬件数据明显用时序数据库啊

[bthulu]

那就是每秒 50 万个 int, 共 2MB. 就是每秒 2MB, 直接写文件, 一条一行. 这样是个设备就能满足要求.
几十块收个几年前的斐讯盒子, 刷机, 把自己的程序放上去就行了.

[standchan]

clickhouse ，不要求实时的话，都放在消息队列里面慢慢消费

[songyoucai]

做过物联网的来回答一下。 首先你的边缘网关，就需要处理这些数据。并不是所有的数据都需要入库的，比如传感器每 5s 上报一次。有一些频率甚至更低。 想想你物联网网关，如果是走的 5g 来上报数据，流量卡吃得消吗

假设你已经是边缘网关清洗过的数据，现在设备几万台，，每秒就是有 10 万条数据. .这时候需要用到时序数据库，消息队列是给物联网后续的指令去消费的。


重点: 边缘网关做数据清洗和心跳,定期上报异常数据和转发指令。这样如果是平常的数据，可以每十分钟发送一次数据包到服务器。异常数据(超过指定阈值。比如温度过高，报警信息)和指令回复可立即上报。

时序数据库存储 来做数据存储，消息队列来消费数据。 进行告警时段统计等信息。

[Curtion]

时序数据库直接存问题也不大吧

[ggabc]

缓冲一下分批量写入就行

[bthulu]

为啥你们想的这么复杂呢? 就起个服务接收物联网设备请求, 顺序写文件就行了, 什么设备都能满足要求.

你们 BT 下过小姐姐嘛? 每秒几十 M 都毫无压力, 存储数据这块, 就他这个每秒 2M, 随便搞个树莓派都能做到.

唯一难点就是, 这每秒 10 万条数据来自几个设备, 如果是 10 万个设备, 那可能确实需要两三千块钱买个 ryzen 5600 级别的主机.

如果就那么几十个设备, 真的需要花钱吗?

[a33291]

@bthulu +1 tcp 收先存内存,然后分块落盘,即使 hdd 也至少几十 M 的写入,另外一侧读做业务完事
只要磁盘够就行

[yunpiao111]

存的话 怎么样都可以, 存成文件都可以, 你接下来的这部分数据除了保存, 是不是还有读取需求和留存时间要求, 这部分需求也影响选型
- 如果后期要检索, 最好性能好点+大存储的机器搭一个时序数据库, 或者直接用一个云时序数据库
- 如果只是留存, 机器选型成数据压缩后转发->云对象存储

[csys]

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

[SoulSleep]

@bthulu #16 “几十块收个几年前的斐讯盒子, 刷机, 把自己的程序放上去就行了.”..................你只考虑 1 秒里发生的事+理论数值，实际情况怕是 10 个斐讯盒子也撑不住
————————————————————————————————
1.10 万/秒+物联网，显然是落库到时序数据库，想要高频那就批量插，持久化之前不要搞太多逻辑，存下来再说处理的事
2.如果每秒 10 万条===每秒 10 万个请求，那你得瓶颈可能在网络、CPU 上，网络比较传统，大力出奇迹，上高带宽，CPU 低频多核，不行就分布式多台扛。
内存没太特殊，硬盘现在很多数据库有压缩技术，你这个数据量不大。

[ymz]

InfluxDB

[ymz]

@songyoucai 边缘网关是硬件设计好阈值，直接对数据进行清洗后再向服务器上报么

[cus]

这个 10w/s 是多少设备呢

[cat007]

1, 用什么数据库，如何高频插入 ？用 iotdb ，10w/s 才是这个数据库的起步
2, 服务器选什么样的配置，来配合数据插入。CPU ，内存，硬盘需要多大？ 10w/s 级别官方推荐 2-4 核就可以，具体看官网资源规划
链接 https://iotdb.apache.org/zh/

[Jinnrry]

kafka 接受数据
ck 或者 sr 存数据

[minoic]

时序数据库，例如 InfluxDB

[qiyilai]

@hxzhouh1 得花钱买企业版的，要不然一言难尽

[morota]

设备倒是不多，大概 50 个，每个发送 2000 条。但是这是最初的一个数据量，后续设备会持续增加。
看了大家的回复，总结一下大概是：
1 ，直接写到文件里
2 ，存到时序数据库里

写到文件里岂不是要出现非常多的文件。跟 BT 下小姐姐一样的技术，感觉难度更大，更不好搞。
还是倾向于写到时序数据库里

那么问题焦点就是内存和带宽需要很大吗，需要分布式吗？

[nanrenlei]

这玩意要结合具体业务场景具体分析的，比如这些数据是要永久存储还是消费完就不用了，还有实效性，如果用一次就不用了可以不用数据库，如果实效性不要求特别及时的话可以上消息队列，如果要永久存的话可以使用 InfluxDB 、hbase ，mongo 和 mysql 就不建议用了，这么大的数据量查询都是个问题

[Plutooo]

消息队列异步消费+1
网传 kafka 吞吐能 17w ，rocketmq 能 11w ，感觉完全没啥问题

[wkong]

WAL ，直接写文件

[Outer2048]

先放到 kafka ，只要硬盘够大，每秒 10w 问题不大
问题是一天 8,640,000,000 数据量，mysql 肯定是不行了，请楼下的懂王解答

[lqw3030]

把数据处理（聚合、筛选）前置，就像楼上老哥提到的边缘设备处理

[songyoucai]

@ymz 对的，这只是他众多功能中的一种。

[a67793581]

@songyoucai 感谢分享,有一个细节,是请求过来直接丢时序数据库吗? 还是先丢消息队列,然后就是消息队列具体要多大才能扛住这个量级 没有计算过

[meeop]

简单啊，你搞 10w 个服务器负载均衡，每个服务器就只需要 1qps 的存储了，随便搞

[wulili]

看似很多，也就每秒 2mb 左右的数据量，内存能有什么压力，都先丢内存里，把数据整合一下，再慢慢插入数据库或者写入文件都可以吧。

[jimrok]

先用日志方式收数据，多台服务器的磁盘写入肯定能保证，放入数据库你要考虑好，单节点吞吐量肯定不够，需要一个群集才能吃下这些数据，还需要分片存储。每个设备你要知道存在那个库，哪个表里，还需要一套元数据管理服务。

[ming159]

假设一条消息 1KB. 10W 条 约 100MB 数据.
在这个基础上留出一定的余量, 比如 就按 200MB 算. 关键是 2 处 IO 瓶颈.
1. 你的服务器 SSD 硬盘每秒写入速度是多少?
2. 带宽是多少?

剩下的,写个简单的测试程序,先直接内存生成 200MB 假数据, 循环往测试服务器写. 你会发现,貌似一台单机基本就没压力.
剩下的就是看你们团队技术偏好,数据增长规模多少,来选合适的数据库就行了. 一台不行 2 台.

[songyoucai]

@a67793581 看你具体需求，一般都是先丢进消息队列，然后时序数据库去消费， 在消费的时候，根据具体的业务逻辑来格式化数据。消息队列只管生产和消费，时序数据库要管查询、计算，统计。

[everhythm]

真实需求真的是这样么……相当于 10w 人在线的实时联网游戏了

首先每秒 10w 条，是不是一定分开 10w 条请求，不是的话考虑合并上报，楼上也说了每几分钟合并成文件上传，即合并数据的空间或时间

然后这个高频插入，是插入之后需要实时查询么，不实时那慢慢屯到 MQ 慢慢消化也行？数据插入后如何使用会影响你的设计

[MagicLi]

@morota #10 你这个带宽估计太粗糙了，如果是 4G 的话，稍微留一点余量。

[a67793581]

@songyoucai 嗯 目前公司用的是 kafka + flink + hive

[pkoukk]

楼上都在说啥啊，物联网数据，5 个 int ，这不就是标准时序数据库么？ 10W 在时序数据库里算个锤子多
市面上流行的时序数据库都支持百万级写入

[sampeng]

就一句，和技术无关。无论如何先落盘。再消费到系统里面做业务存储。不然有锅都没地儿甩。存储随便，这点 metric 数据你是看不起谁呢…

[ytmsdy]

kafka+ InfluxDB

[pkoukk]

@Plutooo 消息队列的吞吐能力影响因素太多了，首先是集群数量和机器配置。
然后各种队列配置也影响很大，Retention 策略，Hash 策略，是否压缩等等等等

[fengemma9]

付费数据库适合你

[morota]

@pkoukk 直接往里面插入吗？每秒都插入？

[Plutooo]

@pkoukk #52 我记得这个吞吐量说的都是单机情况

[JungleZZ]

有个疑问，这些数据是直接落库使用的吗？我也是做物联网的，我们设备的数据都是转到 rocketmq 供下游服务消费后了处理了之后才存表的。举例：计算设备每天的运行时间，那肯定得是第二天统计了头天的数据然后存表。就算是大量的数据要落库，你也可以考虑下他们是否要求实时性，如果不是，那就丢队列慢慢消费。

[pkxutao]

@rockxsj #4 请教下，为什么不能直接入 kafka ，需要先落到本地文件的原因是什么？

[fuis]

直接三板斧搞定：Kafka ，Redis ，MySQL 。数据来了之后先存到 mq 里慢慢消费

[reatang]

可不可以在开头过滤一些无所谓的数据，手工降频

[pkxutao]

@bthulu #21 请问写文件的话，怎么做逻辑查询呢？

[xuanbg]

看你这个 10 万/秒是浪涌还是持续性的。浪涌的一般丢消息队列削峰，后面正常入库就完了。持续性 10 万每秒，那就只能上负载均衡+数据库集群了。单数据库无论如何扛不住 10 万/秒的写入。

[ptaooo]

应该算是典型的时序数据吧
国外的 influxDB
国内的 TDengine
应该都可以满足了

[ala2008]

一定避免直接写数据库，存在瓶颈

[me1onsoda]

seriously ？ 60*60*24*100000 不算增量一天就是 9 位数的存储，真的有必要每条消息都要存储吗

[sss15]

@pkxutao #60 写文件就是把消息先存下来，类似丢进消息队列，后续还要实现消费的逻辑

[ychost]

物联网数据走时序数据库把 influxDB

[cskason]

只是存下来？后续要做什么处理？如果只是存下来，直接写文件。要是写数据库的话，上 tidb 集群之类的，缓存下然后批量写入数据库就可以了。

[minoic]

十万条其实不多，可以参考一下 https://docs.influxdata.com/enterprise_influxdb/v1/guides/hardware_sizing/
新版本理论上性能更强

[andyxq]

你搞的事情跟我高度一致。
目前正在使用 Influxdb, 我这里每秒写入超过了 10 万，但是遇到了服务器资源占用过多和查询效率的问题。
正在考虑用 CH 替换。CH 的技术预研和压力测试都搞完了，比 Influxdb 好不少，写入测得单机 27w/s 写入。
配置要求 4C8G ， 低于 8G 运行一段事件会有莫名的内存报错。硬盘与数据量相关无法给出。

[IDAEngine]

Kafka

[zhangeric]

时序数据库加分多个接收端呗

[liuhuansir]

kafka+clickhouse ，我司的方案，监控类系统

[wangyzj]

kafka

[COW]

@morota 好奇你的带宽 10M 是怎么算出来的

[morota]

@andyxq 感谢提供数据，那看来写入到 ck 是没问题的。

[morota]

@COW 按每秒 2M 算的。。

[liprais]

kafka 接 10w qps 毫无压力，慢慢消费呗

[hxzhouh1]

@qiyilai 好吧，我只是看到过，没真正用过

[mayli]

Clickhouse 吧，这个规模不算大，clickhouse 也有 server 端 async write

[iyaozhen]

你这个量不多，问题不大。做过类似的

随便找个 mq ，然后慢慢消费。消费的时候批量聚合下，然后插入

[yplam]

我们的做法是接入层缓存一个设备 ID 与业务 ID(譬如客户 ID)关系，然后根据业务 ID 转发到不同消息队列，这样同一个客户的数据都会到同一个消费者，这样方便缓存设备影子状态以及做规则触发，后面数据存储压力也不大

[rockxsj]

@pkxutao #57 落地前保持架构简单，减少故障点，确保日志不会丢啊

[forschers]

看场景吧 时序数据 InfluxDB 其他的可以 Kafka ，
Doirs 不知道可以不

[Greendays]

学习一下。现在也在搞物联网，不过数据量远没有这么大。说不定以后能用到。

[carlton]

比较典型的物联网场景，但是没有提到数据后续问题，是否有业务处理逻辑、数据后续查询等，常规的物联网场景里的话
1. 数据先进 Kafka ， 根据业务分类进不同消息队列
2. 不同场景去消费，比如实时展示 redis ，业务逻辑处理 flink
3. 数据库选时序数据库，比如：Influxdb

另外理论上这个数据量在边缘应该是有办法优化的，比如变化传值，数据不变就不传

[nicebird]

时序数据库里直接扔估计就行了

[lmq2582609]

用 mongodb 试试写入和并发查询性能都不错
influxdb 写入性能不错，并发查询性能一般

[KeYee]

kafka+flink+ck

[rainywinter]

降低频率。 批量发送，批量保存

[grzhan]

这里说个不用轮子如果自己实现的思路，可以参考 vmagent 的设计：

https://jiekun.dev/posts/vmagent-data-structures/

程序内部自己维护一个内存的数据队列（在 Golang 就是 Channel ），一批接收请求塞到队列里的 handler （ cpu num 个 goroutine ），以及消费内存队列数据块的 consumer

请求会以 round-robin 的形式分到这些 handler 里，handler 需要把接收到的请求里的数据组装成合适大小的 block （可能是几十兆？这个是调优参数），然后当 block 足够大或者每隔一定时间后，handler 就把 block 刷到内存队列里

塞进队列之前，会有一批 worker （应该也是 cpu num 个）会序列化（ protobuf 或者自己定义的二进制协议）并基于 snappy 或者 zstd 算法压缩这批数据 block ，压缩的关键在于大大减小原始负载的数据大小，进一步增加后续磁盘写入 IO 的吞吐

consumer 会将内存队列里的 block 拿出来顺序写入到本地文件中，多个数据条目拼装的 block 且经过压缩，落盘的吞吐还是比较理想的。

你需求的数据量其实也就每秒 2M 左右，如果压缩一下甚至这个数据量会更小，所以理想情况下应该比较低配的机器就能够满足你的要求。

核心就是组装（其实就是 buffer 的思路）和压缩，来尽量提高顺序 IO 的写入吞吐，这是容易产生的瓶颈。

当然这套方案只考虑了写入，在查询上是没有什么优化的（没有索引），所以如果要实现比较好的查询的话可能还是要考虑开源的轮子，基于 MergeTree 的 Clickhouse 以及 VictoriaMetrics ，或者 InfluxDB 等时序数据库方案应该能很好满足这方面需求，但思路还是要注意写入数据库时数据的合并来实现对于 IO 吞吐的友好

[Macv1994]

@morota 得看你你消费数据的速度。

[a33291]

@pkxutao #60 写文件落盘只是先把数据"接住",接到之后还是常规的做法,消费时写入数据库做统计分析或者其他的事情
这里大部分人说的都是第一步"接数据"的事情

[grzhan]

此外这套方案是通过牺牲数据完整性来提高性能的，因为这里很明显会有一批热数据还在内存里没写到磁盘的，所以如果发生断电等事故（程序没有优雅关闭）势必会有一些数据丢失，如果要保证数据完整性就需要引入 WAL 日志机制以及频繁的 fsync 同步写入来保证数据落盘，这个会非常影响性能，所以看自己权衡了，但 IoT 场景应该还好要求不高？

[nealHuang]

核心在量，大小可以忽略，所以并发是必须的，但是并发的同时还要保证写入的顺序，除非自己控制一下，可以写落盘后面再组包，可以考虑用 actor 模型

[cenbiq]

先在采样和存储压力上做一个平衡，思考一下业务真的需要这么大的原始数据量吗？是否存在冗余？然后再根据你最终确认的写入带宽和查询需求选取一个符合的时序数据库。

[249239432]

hadoop 存文件即可，我迁移的时候直接可以跑满 G 口带宽，也就是一秒 1G 的文件

[jixiangqd]

clickhouse 有嵌入式版本，感觉也可以考虑。后面查询也方便

[Marelbruim]

我们用的是 kafka-flink-doris

[chanlk]

@morota #33 50 个设备？每秒 10W 条？请问这是啥类型的设备，上报频率那么高？

[luciankaltz]

看起来是个非常明确的边缘设备+时序的场景
不确定这边 10w rows/s 是发生在边缘端还是已经到了一个聚合中心，也不确定是不是有自己的采集程序还是这个数字只是传感器的上报频率汇总之类的。甚至如果是内网传输的话其实上面说的很多带宽的问题都没有那么大

理论上来说时序的数据库应该都能支持（ 10w rows/s 并不是一个特别大的数字）。但是考虑到性能和部署条件，可能需要实际测试一下部署的结果

楼上还有说用 clickhouse 的，我不确定用关系型去存一个明显的时序的场景是不是更切合。当然你说要存那肯定没问题（

另外就是后续的使用场景，是用来出大盘还是有一些数据分析的需求，查询的场景更多的是最近分析，最近一周/一个月分析，还是历史全量汇总分析，之类的

回答一下楼主最开始提的几个问题
1. 写入频率。做个简单的 batch ，10w rows/s 对于常见的时序数据库都不是问题。唯一可能需要看下写入时的资源占用
2. 服务器配置，同上。这个相对比较主观，我的猜测是 2c/4c 的服务器就基本能满足。内存 1:2 或者 1:4 （大概率 1:2 就够了）。长时间存储的话只要数据库支持存算分离，长期数据保存到一个对象存储上面，成本应该非常小

有兴趣的话可以考虑一下 GreptimeDB

备注：利益相关