物联网传感器发送的数据，走 tcp 或者 mqtt ，每秒大概有 10 万条，每条数据大概 20 个字节大小(5 个 int 值)
现在的问题是：服务端如何保存这些数据。
1, 用什么数据库，如何高频插入
2, 服务器选什么样的配置，来配合数据插入。CPU ，内存，硬盘需要多大。
请各位大佬不吝指教

ck

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

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

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

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

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

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

1. 使用时序数据库或者 nosql ，或者 pgsql 这样的数据库，使用队列异步去消费这些数据，插入时候可以批量插入，最好在插入前对数据库进行好分区，然后按照分区读写。

2. 服务器的话需要 16 核的 CPU ， 内存按照 32-64 来搞，硬盘的话，你这个量级如果没有估算错，至少 1T ，另外就是带宽搞大一点。
   基本上就这样。

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

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

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

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

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

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

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

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

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

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

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

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

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

假设你已经是边缘网关清洗过的数据，现在设备几万台，，每秒就是有 10 万条数据. .这时候需要用到时序数据库，消息队列是给物联网后续的指令去消费的。
重点: 边缘网关做数据清洗和心跳,定期上报异常数据和转发指令。这样如果是平常的数据，可以每十分钟发送一次数据包到服务器。异常数据(超过指定阈值。比如温度过高，报警信息)和指令回复可立即上报。

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

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

缓冲一下分批量写入就行

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

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

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

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

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

存的话 怎么样都可以, 存成文件都可以, 你接下来的这部分数据除了保存, 是不是还有读取需求和留存时间要求, 这部分需求也影响选型

• 如果后期要检索, 最好性能好点+大存储的机器搭一个时序数据库, 或者直接用一个云时序数据库

• 如果只是留存, 机器选型成数据压缩后转发->云对象存储

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

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

  InfluxDB

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

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

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

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

  时序数据库，例如 InfluxDB

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

  设备倒是不多，大概 50 个，每个发送 2000 条。但是这是最初的一个数据量，后续设备会持续增加。
  看了大家的回复，总结一下大概是：

• ，直接写到文件里
• ，存到时序数据库里

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

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

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

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

WAL ，直接写文件

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

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

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

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

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

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

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

假设一条消息 1KB. 10W 条 约 100MB 数据.
在这个基础上留出一定的余量, 比如 就按 200MB 算. 关键是 2 处 IO 瓶颈.

1. 你的服务器 SSD 硬盘每秒写入速度是多少?
2. 带宽是多少?

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

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

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

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

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

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

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

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

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

kafka+ InfluxDB

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

付费数据库适合你