物联网传感器发送的数据，走 tcp 或者 mqtt ，每秒大概有 10 万条，每条数据大概 20 个字节大小(5 个 int 值) 现在的问题是：服务端如何保存这些数据。
1, 用什么数据库，如何高频插入 2, 服务器选什么样的配置，来配合数据插入。CPU ，内存，硬盘需要多大。
请各位大佬不吝指教
122 条回复 • 2024-12-07 09:00:51 +08:00
 |
101
breadykidliu 11 天前
@kenneth104 到时候会有缓存同步问题，层数多了还会错乱
|
 |
102
ITdream 11 天前
给你个参考, 之前做的压测, kafka 堆积在可接受范围内
(1)数据处理服务集群，6 台（ 2c8g ）- 消费者 (2)Kafka 集群，3 台（ 2c8g ） (3)IoTDB 集群 3C3D,3 台（ 4c16g ）- 数据层 单个上报 每次请求上报 1 条数据，目前能支持每秒最大并发为 13500 ，每次请求字段数为 42 ，报文大小在 1.2k 左右； 数组上报 每次请求上报 20 条数据，目前能支持每秒最大并发为 3600 设备 * 20 ，报文大小在 22.3k 左右 |
 |
103
janus77 11 天前
一个接口吗？如果是多个接口，那按分布式不就行了
|
 |
104
wqkenqing 11 天前
方案应该很多，你传的数据的条数多，但量不算大，每秒大概 2M 。就是 TPS 要求高些，可以考虑 clickhouse+kafka 物化视图。flink 也可以。写入的话，hbase 非常好用，但你里的数据量，应该不值当上这个。其它类似 clickhouse 的一些 olap 工具也可以调研一下，基本应该能满足你的需求。
|
 |
106
Suomea 11 天前
kafka + Doris ，Doris 直接使用 Routineload 接入 Kafka 数据。
1. Doris 国产的，有问题社区有官方人员对接答复，体验很好。 2. 使用固态硬盘存储。 3. Doris 冷数据支持存储到 HDFS 。 |
 |
107
herewego 11 天前
丢 ES
|
 |
108
mark2025 11 天前
pgsql 单点写入 110MByte 每秒，pg17 提升到 180MB 。你这个数据量不算啥，只要固态盘就行。
|
 |
111
nativeBoy 11 天前
如果数据有规律的话，是否可以考虑编码减少数据量
|
 |
112
winnie2012 11 天前
我们现在就是 Kafka + PostgreSQL ，Kafka 只收集数据不处理，PostgreSQL 的表设计参考了 TDengine 的原则，一个设备一张分区子表，按 1 个设备 1 秒插入 1 条数据来算，单表的一年数据量才 3000 万，分散插入压力和查询压力，后台起个 N 个任务批量往 PostgreSQL 里插入数据。
|
 |
113
hongye 11 天前
以前碰到过这类的场景，收集上来的数据基本上都是一样，价值不大，能边缘处理就边缘处理。
|
 |
114
qiyilai 11 天前
@leeyuzhe ，并不是说产品多差多难用，我回复也是说选 td 就得选企业收费版
1 、开源版支持的系统有限，尤其是和信创有关的（欧拉 麒麟） 2 、开源版实测的写入能力比不上单节点的 influxdb （例如将 prometheus 的存储改为 td 后，td 的 cpu 内存波动剧烈且无法查询，influxdb 则没有） 3 、开源版的一些函数是不给用的，见官方文档（这个无可厚非毕竟是要赚钱的） 4 、使用开源版出现的问题在官方群里提问基本不会被解答的（也能理解） |
 |
115
guo4224 11 天前
随便搞个 es 什么都能写，怕丢不保险可以搞个 mq ，每秒十万真的不多
|
 |
116
EndlessMemory 11 天前
加个中间层
|
 |
117
weiwenhao 11 天前
垃圾心跳数据没什么好存的，非要存就存日志。本地设备可以做简单计算就做一下简单计算，汇聚成 1 ～ 5 分钟平均或者 95 数据在上报。
汇聚后的数据再上报到云端服务器，云端服务器写到 kafka 里面。数据存储可以用 es/hadoop/influxdb 等文档形数据库 |
 |
119
NoKey 11 天前
上面有同行业的给了解决方案了，非相关行业的按照工作习惯来考虑，简化处理不同数据分一下队列（ kafka ），用多个队列来支撑，然后，多个服务来消费，往时序数据库写，至于起多少个服务，跑起来看消息积压情况，反正服务可以横向扩展，走容器化还可以搞一个动态伸缩的调度服务起服务
|
 |
120
morota OP 感谢诸位大佬的解惑。准备先在边缘处理一下数据，然后走 mq ，最后进 ck 。用这个方案调研一下。
|
 |
121
zzmark06 8 天前
1. 少做无用设计
2. 少造轮子。 然后分析场景： 问 1：数据收集到后，是否需要有各种处理和校验 问 2：数据接收到后，时效性要求是什么程度 问 3：数据格式是否是时序型数据，有没有高基数问题 问 4：数据收集后，用来支持什么服务 预先做几个回答 海量打点采集，时效性要求一般都很低，所以此类业务都是入队列(如 kafka ），再攒批次，写列存/写时序库。 秒 10w 行，就得看每行多大了。clickhouse 单机 16 核心写速到 200mb 没啥问题。 至于时序库，这东西有门槛，除非是场景化很强烈，不然都不太推荐选用。尤其是 prometheus/victoriametric ，一旦有高基数，资源占用很难控制。 常规来说，这类数据都是拿来做聚合分析，时序库在一些方向的分析很快，压缩比也很高；列存更通用些，也看设计。 |
 |
122
saintatgod 4 天前
@morota 差不多，可能的话多点也无所谓，10M 打底吧
|
Select Language