这是一个创建于 65 天前的主题，其中的信息可能已经有所发展或是发生改变。
当前将监护仪的毫秒级数据存储到数据库，少量数据还可以访问，但是时间长了就无法访问。是应该替换成时序数据库吗？比如 基于 PostgreSQL 的 TimescaleDB ？有没有可以参考的方案
72 条回复 2025-12-15 03:36:56 +08:00
 | 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 可以试试 |
 | 6 Yasuke 2025 年 12 月 1 日 |
 | 7 opengps 2025 年 12 月 1 日 传统关系数据库想用出时序的效果，确实需要费很大精力优化，还是直接用时序更省心 |
 | 8 chaoshui 2025 年 12 月 1 日 推荐 InfluxDB |
 | 9 polarbearn 2025 年 12 月 1 日 Apache IoTDB https://github.com/apache/iotdb |
 | 10 KongLiu 2025 年 12 月 1 日 时序数据库推荐 InfluxDB ，之前我们有个项目是要本地存储的，用的方案是存成 SQLite ，做好分库也不错 |
 | 12 RonnieColeman 2025 年 12 月 1 日 我们有个项目需要存储传感器数据，用的 influxDb |
 | 13 mrsatangel 2025 年 12 月 1 日 https://github.com/GreptimeTeam/greptimedb 支持 MySQL/PG 协议 |
 | 15 emacsistyzy 2025 年 12 月 1 日 clickhouse . 查询性能和数据压缩比都相当可以. 而且也相对简单. |
 | 16 xmdbb 2025 年 12 月 1 日 目前在用 clickhouse ，量大的查候也是不住，除非集群； 目前基本只存 3/7/30 天的日，，如果要求存更久就加算走集群或使用服 |
 | 17 sead 2025 年 12 月 1 日 clickhouse +1 不过这个不合适实时频繁写入，需要实时部分得隔离到 PostgreSQL 这类能频繁写入的，并分批入库到 clickhouse ； 其他的没有用过，clickhouse 最给力的是内存资源使用的没有那么猛，查询还非常给力 |
 | 18 526326991 2025 年 12 月 1 日 国产做的好的涛思数据库（ https://www.taosdata.com/）可以试试 但是迭代版本过快 我司正在用 |
 | 20 stardustree 2025 年 12 月 1 日 “毫秒级数据”，时间精度这么高的数据，要做好降采样。 |
 | 21 Saunak OP @stardustree 生理信号的原始波形。100-500Hz 。从研究目的上来说似乎不太好降采样 |
 | 22 snow0 2025 年 12 月 1 日 超大数据量考虑 cassandra |
 | 23 waiing 2025 年 12 月 1 日 @mrsatangel 最近也在看这个，有实际项目使用吗，体验如何，我们主要存储设备上报的数据，目前在用 timescaleDB ，主要考虑设备量有上来看选什么方案更好。 |
| 24 stardustree 2025 年 12 月 1 日 @Saunak 降采样的策略很灵活： 比如是否存在查询超长时间波形的需求：如果有的话，直接展示原始数据大概率是不行的，哪怕不考虑性能，前端的图都画不出来。可以处理成最大值、最小值、P95 值之类的按时间颗粒度的统计值，有点像股票 k 线图 如果只支持查询短时间的波形：随便 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 试一试！ |
 | 34 realpg PRO @mrsatangel #32 这项目是中国公司做的吗? |
| 35 waising 2025 年 12 月 2 日 @mrsatangel #32 V2Fpc2luZw== |
 | 36 iamtuzi3333 2025 年 12 月 2 日 如果是同一个数据格式就很好处理，随便一个都行；我这也是物联网，但是每个设备数据格式都不一样，最后还是用了 MySQL 处理。 |
 | 37 lancelock 2025 年 12 月 2 日 选个主流的时序库都行 |
 | 38 chenxiansheng 2025 年 12 月 2 日 推荐用国内的涛思吧，有社区版本，存储查询效率都还不错 |
 | 39 zouzou0208 2025 年 12 月 2 日 greptimedb 不错 |
 | 40 kapaseker 2025 年 12 月 2 日 有个 cnosdb ，我看过他家的 rust 课程，哈哈。 |
 | 41 tanxnative 2025 年 12 月 2 日 @faceair VictoriaMetrics 是个非常棒的时序存储中间件,时序数据计算方面有什么推荐吗? 好像现在 flink , risingwave 均未对 VictoriaMetrics 提供完善支持 timescaledb 单机(默认) influxdb 集群收费 tdengine 集成 flink 部分功能需要企业版 clickhouse 依赖 zk |
 | 42 shellic 2025 年 12 月 2 日 我们设备数据是秒级的，我们直接简单粗暴用 Doris 了配合 Group Commit 凑活用着哈哈哈哈 |
 | 43 vincent109 2025 年 12 月 2 日 TDengine |
 | 44 play78 2025 年 12 月 2 日 不建议用 TDengine ，以前营销过度，经常拉踩同行。营造产品很厉害的感觉。 |
 | 45 AnroZ 2025 年 12 月 2 日 毫秒级数据先存到一个数据块（可以用：parquet 格式），再把数据块或者地址存到关系库；嫌弃麻烦可以用 TD 或 InfluxDB |
| 46 mrsatangel 2025 年 12 月 2 日 @realpg 是一个开源项目（ https://github.com/GreptimeTeam/greptimedb ），我们在硅谷和国内都有 office |
| 47 mrsatangel 2025 年 12 月 2 日 @tanxnative https://docs.greptime.cn/user-guide/flow-computation/overview/ GreptimeDB 的流计算功能开源版可以免费使用，支持降精度，可以用 SQL 来写流计算任务 |
| 48 faceair 2025 年 12 月 2 日 @tanxnative #41 PromQL 就行，你套一个别的查询引擎没必要吧 |
 | 49 Jiubia 2025 年 12 月 2 日 @tanxnative 推荐 VictoriaMetrics ，支持集群部署。api 接口和查询语句兼容 Prometheus ，所以你可以直接把他当做 Prometheus Plus 来用。 数据来源支持 Prometheus 的主动抓取，和 HTTP 的被动接受 性能尚可，之前每分钟约 5G 数据，在一个 6c12g 的服务器就能扛住了 目前他们的企业版只有多租户集群，单用户版集群是免费商用的。 |
 | 51 han3sui 2025 年 12 月 2 日 毫秒级，基本是要做本地缓存机制的，一般先往内存写，设置一个阈值，超出了往 redis 写，然后每秒批量往时序库里插 |
| 52 tanxnative 2025 年 12 月 2 日 @faceair 需要关联其他数据源中数据 |
 | 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 日 手滑发出了： timescaledb 现在用着还行，问题不大 tdengine 过去碰瓷营销，太恶心了 |
 | 62 encro 2025 年 12 月 2 日 clickhouse ，最简单最好用了。 我比较过 VictoriaMetrics,TimerscaleDB,TSDB |
| 63 encro 2025 年 12 月 2 日 现在在用一个 starrocks |
| 64 tanxnative 2025 年 12 月 2 日 刚去看了一下资料, 如果需要计算, 还可以考虑 risingwave |
 | 65 ThisDay 2025 年 12 月 2 日 @mrsatangel #32 国内有什么 offer ？感兴趣！！ |
 | 66 yeelooyeeuu 2025 年 12 月 2 日 推荐 InfluxDB |
 | 67 ponder09 2025 年 12 月 3 日 @yeelooyeeuu 建议用 influxdb 的哪个版本呢 |
| 68 tanxnative 2025 年 12 月 3 日 @yeelooyeeuu 之前了解到 influxdb 最新的集群版本是需要收费的 |
| 69 realpg PRO |
| 70 xmdbb 2025 年 12 月 3 日 @yudoo 目前平均每天 200 万左右，我们就一台 4c8g 的机器，写入日志目前是队列批量定时写入。 但是磁盘空间和查询时候 CPU 占用很高，所以才取平衡点减少保留天数。 |
| 71 mrsatangel 2025 年 12 月 3 日 @realpg 软著申请了不少，这玩意不是挺简单的吗？ |
 | 72 Rorysky 2025 年 12 月 15 日 为什么无法访问，工业场景用的 mysql 一点没问题 |
Select Language