这是一个创建于 1304 天前的主题，其中的信息可能已经有所发展或是发生改变。
之前做能耗监测类的项目，因为有个集中器主控，所以一般一个集中器连接几百块仪表，一个项目也就几十个集中器。当时系统数据库用的 mysql 按月和设备编号分表。也就是一个月一个设备一张数据表。
最近做了一个项目，但是量大了，可以理解为有一万个集中器了，每个集中器固定有二十多个仪表，沿用原来代码发现 mysql 一个月就要建一万多个数据表，这个很明显不合理了。目前看一个设备一个月也就一百万到四百万条记录吧。
只有一台 32 核，64g ，19t 硬盘的服务器的话大家有什么更好的方案和技术选型，是不是要放弃 mysql 数据库。
甲方说年底可能要到三万个设备，明年要五万个。
 | 1 nebkad 2022-03-18 01:37:00 +08:00  1 https://www.infoq.cn/article/2017/07/why-time-series-database 《我们为什么需要一个时序数据库？》 |
 | 3 duke807 2022-03-18 01:58:22 +08:00 我喜直接用目和文件，按照子目分不同目，每再搞一子目，目中有的 info 文件，直接用固定的二制格式追加到目下的文件中，量大的可按段或文件大小用多文件存。 （二制格式可以是 C 言 struct ，或者是 MessagePack 的，或者直接用字符串。） 全程不需要似 PostgreSQL MongoDB 的用。 |
 | 4 CEBBCAT 2022-03-18 02:09:20 +08:00 诶？怎么没提数据备份的事情？不用担心数据丢失吗？ |
 | 5 dayeye2006199 2022-03-18 02:18:39 +08:00 1 可以一张表，但是指定一个 partition key （月份＋设备）。https://dev.mysql.com/doc/refman/8.0/en/partitioning-overview.html 其实就是系统帮你做分表。查询的时候只会扫有你目标数据的 partition 。例如指定一个设备号，就只会看 partition key 里面包含这个设备号的分区，所以性能会很高。 这么做的好处是你现有数据库设计和下游的查询代码基本不需要怎么改动。 查询性能和你目前的方案性能基本一致：找 parition + 找到表之后查询。查询 partition 设计合理就是个 log n 的复杂度。 |
 | 6 twing37 2022-03-18 03:48:55 +08:00 - clickhouse - cassandra / scylladb |
 | 7 singerll 2022-03-18 05:00:16 +08:00 via Android 淘思，我觉得挺不错的一个公司 |
 | 8 aragakiyuii 2022-03-18 07:06:20 +08:00 via iPhone clickhouse |
 | 9 opengps 2022-03-18 07:39:28 +08:00 via Android 我做过类似的，如果不能使用时序数据库的话，mysql 要设计成无主键超简逻辑超大容量的结构，我博客有分享 |
| 10 opengps 2022-03-18 08:02:49 +08:00 via Android |
 | 11 bthulu 2022-03-18 08:13:45 +08:00 mariadb 啊, 无缝兼容 mysql 还自带时序数据库 |
 | 12 wangtian2020 2022-03-18 08:27:18 +08:00 是跟 plc 什么相关的吗，我们公司用的 PostgreSQL 。不过我是前端，其他不懂 |
 | 13 joesonw 2022-03-18 08:29:56 +08:00 via iPhone influxdb |
 | 14 masterclock 2022-03-18 08:31:50 +08:00 从时序数据库里挑一个 TimescaleDB 基于 PG ，没啥缺点 InfluxDB 排名第一，除单机外没啥缺点 其他的都大概有点缺点 |
 | 15 banmuyutian 2022-03-18 09:03:38 +08:00 我司用 InfluxDB |
 | 16 cco 2022-03-18 09:10:24 +08:00 监控基本上都是无脑时序吧。opentsdb,influxDB 都可以。 |
 | 17 spacezip 2022-03-18 09:10:36 +08:00 偶然点进来不太懂开发 我觉得存储性能够一般问题不大 朋友公司 全国四五十万个仪表 双机 1u 双路 32 核心 256 内存 只不过数据量很小每天几个 g 存储目前是 8t nvme 固态 |
 | 18 youngce 2022-03-18 09:27:47 +08:00 InfluxDB 性能好但是单机、mongodb 性能差一点但是分布式方案成熟 |
 | 19 v2orz 2022-03-18 09:53:01 +08:00 借楼问一下 用 influxDB 的大佬们是怎么做高可用的啊？ |
 | 22 E2gCaBAT5I87sw1M 2022-03-18 09:59:50 +08:00 |
 | 23 cshlxm 2022-03-18 10:01:45 +08:00 支持下国产，tdengine ，涛思，用下来感觉不错 |
| 24 singerll 2022-03-18 10:43:49 +08:00 @MoYi123 2019 年 7 月 12 日，涛思数据宣布 TDengine 正式开源。 开源后发展的还挺好的，我见过他们商务，这个公司搞笑的就是没有专职商务人员，商务都是技术人员兼职的，跟我们公司的技术交流群里，提的技术问题商务是解答最快的。。。。。 实话说我觉得他们真的是一个想做技术的公司，跟拿开源改文件名骗钱的完全不一样。 |
 | 25 pengtdyd 2022-03-18 11:21:14 +08:00 只要是单机的不能用于生产环境！！！ |
 | 27 wxt OP @dayeye2006199 这种方式目前看可能是优选了，改动最小。 |
 | 31 leonhao 2022-03-18 13:44:44 +08:00 IOT 这块做过几个项目，推荐 timescaledb ，简单好用，没有坑。clikchouse 一生黑，各种 bug ，浪费时间。 |
 | 32 moen 2022-03-18 13:46:50 +08:00 关系型的话用 TimescaleDB ，起码能自动分表还能对历史数据做压缩 |
 | 33 PopRain 2022-03-18 15:47:14 +08:00 发现很多搞 IOT 的都喜欢按设备建表，为什么不把设备 ID 作为数据库的一个字段？ 既然数据仅仅保留一个月，这点数据对于数据库来说实在是小 case 了。（可以按时间分区，删除起来也不影响当前工作表） |
 | 35 slowly 2022-03-18 19:51:59 +08:00 刚开始是使用 influxdb ，后面转到了 hbase,慢慢堆起来之后发现 Hbase 磁盘占用太多了，现在在踩坑 clickhouse 。 |
 | 36 liveej 2022-03-19 08:55:21 +08:00 也推荐 TDengine ，省资源，技术支持方便 |
 | 37 ljhskyso7 2022-03-19 15:08:26 +08:00 via iPhone @wxt 可以试试这个： http://iotbase.io/ 第一个真正意义上的物联网数据库，特点已经在官网有说明。总结一下：MQTT 消息直写（也兼容 pg 线协议），顶级的写入性能，顶级的分析查询性能（引擎内部对标 ClickHouse ，比 ClickHouse 快；外部对标 Timescale ，比 Timescale 快的 2-3 个数量级），免运维设计，极好的工程稳定性，完整地支持常用 SQL 函数。有待改进的是，目前只支持单机（但支持 HA ），复杂的 SQL 分析函数和 JOIN 还在进行中。 目前团队正在进行一些上云的工作，所以 SQL 方面的功能性增强会稍微放几天。 团队正在对有真实需求的企业用户提供免费内测，CEO 直接提供企业级支持，欢迎申请： [email protected] |
| 39 wxt OP 2 回顾一下，最后我们选用的涛思，大概运行半年多了，目前看没什么毛病很稳定，速度也还可以，也兼容很多之前的 mysql 语句，所以程序改动相对比较小。 |
Select Language