这是一个创建于 195 天前的主题，其中的信息可能已经有所发展或是发生改变。
当前将监护仪的毫秒级数据存储到数据库，少量数据还可以访问，但是时间长了就无法访问。是应该替换成时序数据库吗？比如 基于 PostgreSQL 的 TimescaleDB ？有没有可以参考的方案
 |
1 faceair 2025 年 12 月 1 日 1
VictoriaMetrics |
 |
2 defunct9 2025 年 12 月 1 日不要用 TimerscaleDB ，之前 prometheus 的持久化放到 TimescaleDB ，一是机器的 CPU 占用极高，而是磁盘空间极高，没法用。 |
 |
3 qi1 2025 年 12 月 1 日阿里的 TSDB 呢，有问题他们还能给运维（我没用过，听说来的） |
 |
4 hugowangnz 2025 年 12 月 1 日我读研那会儿做时序数据，那时候最热门的时序数据库是 influxDB |
 |
5 bigdude 2025 年 12 月 1 日国产的 tdengine 可以试试 |
 |
7 opengps 2025 年 12 月 1 日传统关系数据库想用出时序的效果，确实需要费很大精力优化，还是直接用时序更省心 |
 |
8 chaoshui 2025 年 12 月 1 日推荐 InfluxDB |
 |
10 KongLiu 2025 年 12 月 1 日时序数据库推荐 InfluxDB ，之前我们有个项目是要本地存储的，用的方案是存成 SQLite ，做好分库也不错 |
 |
12 RonnieColeman 2025 年 12 月 1 日我们有个项目需要存储传感器数据，用的 influxDb |
 |
15 emacsistyzy 2025 年 12 月 1 日clickhouse . 查询性能和数据压缩比都相当可以. 而且也相对简单. |
 |
16 xmdbb 2025 年 12 月 1 日目前在用 clickhouse ，量大的話查詢時候也是撐不住，除非集群； |
 |
17 sead 2025 年 12 月 1 日clickhouse +1 不过这个不合适实时频繁写入，需要实时部分得隔离到 PostgreSQL 这类能频繁写入的，并分批入库到 clickhouse ； 其他的没有用过，clickhouse 最给力的是内存资源使用的没有那么猛，查询还非常给力 |
 |
20 stardustree 2025 年 12 月 1 日“毫秒级数据”，时间精度这么高的数据，要做好降采样。 |
 |
22 snow0 2025 年 12 月 1 日超大数据量考虑 cassandra |
 |
23 waising 2025 年 12 月 1 日@mrsatangel 最近也在看这个，有实际项目使用吗，体验如何，我们主要存储设备上报的数据，目前在用 timescaleDB ，主要考虑设备量有上来看选什么方案更好。 |
|
24 stardustree 2025 年 12 月 1 日@Saunak 降采样的策略很灵活： 如果只支持查询短时间的波形：随便 1 个时序数据库都能满足需求，非常简单，你只需要考虑可维护性、并发限制、成本这些方面 甚至可以考虑一种特殊算法的降采样逻辑，精度只有轻微的变化： https://www.base.is/flot/ |
 |
25 BQsummer 2025 年 12 月 1 日tdengine 就是坨屎, 底层用关系型数据库魔改的; prometheus 不合适, 取值的时候会做估算, 不适合精确数据 |
 |
27 v1 2025 年 12 月 1 日大胆点，上 elasticsearch |
 |
28 yemoluo 2025 年 12 月 1 日@sead 这块我们是直接扔 redis ，以 5 分钟作为单位扔的，然后写一个任务 5 分钟写到 clickhouse 里。最后差不多直接搞了一台来写 |
 |
29 luckyc 2025 年 12 月 1 日InfluxDB 不能满足么? |
 |
30 playniuniu 2025 年 12 月 1 日 1
可以试试 questdb ，做量化高频不少人选这个，可以满足需求 |
 |
31 0x663 2025 年 12 月 1 日dolphindb |
 |
32 mrsatangel 2025 年 12 月 2 日@waising 利益相关，我是 greptimedb 的员工。目前国家电网、oceanbase 、emqx 以及海外不少客户已经生产使用了。可以留个联系方式我拉你进用户群。 |
 |
33 malaohu 2025 年 12 月 2 日今年打算折腾一下用 InfluxDB 试一试！ |
 |
36 iamtuzi3333 2025 年 12 月 2 日如果是同一个数据格式就很好处理，随便一个都行；我这也是物联网，但是每个设备数据格式都不一样，最后还是用了 MySQL 处理。 |
 |
40 kapaseker 2025 年 12 月 2 日有个 cnosdb ，我看过他家的 rust 课程，哈哈。 |
 |
41 tanxnative 2025 年 12 月 2 日@faceair VictoriaMetrics 是个非常棒的时序存储中间件,时序数据计算方面有什么推荐吗? |
 |
42 shellic 2025 年 12 月 2 日我们设备数据是秒级的，我们直接简单粗暴用 Doris 了配合 Group Commit 凑活用着哈哈哈哈 |
 |
44 play78 2025 年 12 月 2 日不建议用 TDengine ，以前营销过度，经常拉踩同行。营造产品很厉害的感觉。 |
 |
45 AnroZ 2025 年 12 月 2 日毫秒级数据先存到一个数据块（可以用：parquet 格式），再把数据块或者地址存到关系库；嫌弃麻烦可以用 TD 或 InfluxDB |
 |
49 Jiubia 2025 年 12 月 2 日@tanxnative 推荐 VictoriaMetrics ，支持集群部署。api 接口和查询语句兼容 Prometheus ，所以你可以直接把他当做 Prometheus Plus 来用。 |
 |
51 han3sui 2025 年 12 月 2 日毫秒级，基本是要做本地缓存机制的，一般先往内存写，设置一个阈值，超出了往 redis 写，然后每秒批量往时序库里插 |
 |
54 madadimy 2025 年 12 月 2 日目前在用 InfluxDB 用 InfluxDB 最好配套用固态硬盘，有点吃内存，数据备份不友好 增量备份不好用 |
 |
55 Yosomi 2025 年 12 月 2 日绕不开 Influxdb 的 |
 |
56 tf2 2025 年 12 月 2 日不推荐 InfluxDB 2.x 。那个 查询语法不能说恶心只能说怪。 1.x 的各种性能问题，如果你用得不多还行。 |
 |
57 chd0919 2025 年 12 月 2 日之前用的 tdengine ，但是不推荐，感觉还不成熟 |
 |
59 masterclock 2025 年 12 月 2 日influxdb 1 的时候使用很好，但不支持 cluster ，然后 1-2-3 升级过于不平滑，甚至查询语言都换了 |
|
60 masterclock 2025 年 12 月 2 日手滑发出了： |
 |
62 encro 2025 年 12 月 2 日clickhouse ，最简单最好用了。 |
|
63 encro 2025 年 12 月 2 日现在在用一个 starrocks |
|
64 tanxnative 2025 年 12 月 2 日刚去看了一下资料, 如果需要计算, 还可以考虑 risingwave |
|
70 xmdbb 2025 年 12 月 3 日@yudoo 目前平均每天 200 万左右，我们就一台 4c8g 的机器，写入日志目前是队列批量定时写入。 |
 |
72 Rorysky 2025 年 12 月 15 日为什么无法访问，工业场景用的 mysql 一点没问题 |
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。
