关于物联网系统的数据库设计和选型

[wxt]

之前做能耗监测类的项目，因为有个集中器主控，所以一般一个集中器连接几百块仪表，一个项目也就几十个集中器。当时系统数据库用的 mysql 按月和设备编号分表。也就是一个月一个设备一张数据表。

最近做了一个项目，但是量大了，可以理解为有一万个集中器了，每个集中器固定有二十多个仪表，沿用原来代码发现 mysql 一个月就要建一万多个数据表，这个很明显不合理了。目前看一个设备一个月也就一百万到四百万条记录吧。

只有一台 32 核，64g ，19t 硬盘的服务器的话大家有什么更好的方案和技术选型，是不是要放弃 mysql 数据库。

甲方说年底可能要到三万个设备，明年要五万个。

[nebkad]

https://www.infoq.cn/article/2017/07/why-time-series-database
《我们为什么需要一个时序数据库？》

[wxt]

@nebkad 多谢，有什么好的开源稳定的时序库推荐吗

[duke807]

我喜歡直接用目錄和文件，按照子項目分不同目錄，每個設備再搞一個子目錄，目錄中有設備的 info 文件，數據直接用固定的二進制格式追加到目錄下的數據文件中，單個設備數據量大的話可按時間段或文件大小用多個文件儲存。
（二進制格式可以是 C 語言 struct 數據結構，或者是 MessagePack 這樣的動態結構，或者直接用字符串。）
全程不需要類似 PostgreSQL MongoDB 這樣的專用數據庫。

[CEBBCAT]

诶？怎么没提数据备份的事情？不用担心数据丢失吗？

[dayeye2006199]

可以一张表，但是指定一个 partition key （月份＋设备）。https://dev.mysql.com/doc/refman/8.0/en/partitioning-overview.html

其实就是系统帮你做分表。查询的时候只会扫有你目标数据的 partition 。例如指定一个设备号，就只会看 partition key 里面包含这个设备号的分区，所以性能会很高。

这么做的好处是你现有数据库设计和下游的查询代码基本不需要怎么改动。
查询性能和你目前的方案性能基本一致：找 parition + 找到表之后查询。查询 partition 设计合理就是个 log n 的复杂度。

[twing37]

- clickhouse
- cassandra / scylladb

[singerll]

淘思，我觉得挺不错的一个公司

[aragakiyuii]

clickhouse

[opengps]

我做过类似的，如果不能使用时序数据库的话，mysql 要设计成无主键超简逻辑超大容量的结构，我博客有分享

[opengps]

https://www.opengps.cn/Blog/View.aspx?id=284

[bthulu]

mariadb 啊, 无缝兼容 mysql 还自带时序数据库

[wangtian2020]

是跟 plc 什么相关的吗，我们公司用的 PostgreSQL 。不过我是前端，其他不懂

[joesonw]

influxdb

[masterclock]

从时序数据库里挑一个
TimescaleDB 基于 PG ，没啥缺点
InfluxDB 排名第一，除单机外没啥缺点

其他的都大概有点缺点

[banmuyutian]

我司用 InfluxDB

[cco]

监控基本上都是无脑时序吧。opentsdb,influxDB 都可以。

[spacezip]

偶然点进来不太懂开发 我觉得存储性能够一般问题不大
朋友公司 全国四五十万个仪表 双机 1u 双路 32 核心 256 内存 只不过数据量很小每天几个 g 存储目前是 8t nvme 固态

[youngce]

InfluxDB 性能好但是单机、mongodb 性能差一点但是分布式方案成熟

[v2orz]

借楼问一下 用 influxDB 的大佬们是怎么做高可用的啊？

[blackshadow]

@v2orz 高可用要商业版把。 开源的只支持单机模式。

[MoYi123]

@singerll 2 年前用过, bug 还挺多的.

[winnie2012]

https://www.taosdata.com/?zh

[cshlxm]

支持下国产，tdengine ，涛思，用下来感觉不错

[singerll]

@MoYi123 2019 年 7 月 12 日，涛思数据宣布 TDengine 正式开源。
开源后发展的还挺好的，我见过他们商务，这个公司搞笑的就是没有专职商务人员，商务都是技术人员兼职的，跟我们公司的技术交流群里，提的技术问题商务是解答最快的。。。。。
实话说我觉得他们真的是一个想做技术的公司，跟拿开源改文件名骗钱的完全不一样。

[pengtdyd]

只要是单机的不能用于生产环境！！！

[wxt]

@pengtdyd 没办法，甲方只能提供一台服务器，情况该说的也都说了，服务器带了个磁盘阵列。

[wxt]

@dayeye2006199 这种方式目前看可能是优选了，改动最小。

[wxt]

@opengps 多谢

[wxt]

@spacezip 我们最初计算大概是一万个设备一个月大概是 1T,目前看可能没那么大。

[wxt]

@CEBBCAT 甲方认为数据存储一个月就行，做了个磁盘阵列。

[leonhao]

IOT 这块做过几个项目，推荐 timescaledb ，简单好用，没有坑。clikchouse 一生黑，各种 bug ，浪费时间。

[moen]

关系型的话用 TimescaleDB ，起码能自动分表还能对历史数据做压缩

[PopRain]

发现很多搞 IOT 的都喜欢按设备建表，为什么不把设备 ID 作为数据库的一个字段？ 既然数据仅仅保留一个月，这点数据对于数据库来说实在是小 case 了。（可以按时间分区，删除起来也不影响当前工作表）

[wxt]

@duke807 感觉这种方式不太适合我们 这个数据回头还得查询 计算处理什么的 感觉操作文件弄起来有点麻烦。

[zhangrenjie]

刚开始是使用 influxdb ，后面转到了 hbase,慢慢堆起来之后发现 Hbase 磁盘占用太多了，现在在踩坑 clickhouse 。

[liveej]

也推荐 TDengine ，省资源，技术支持方便

[ljhskyso7]

@wxt 可以试试这个： http://iotbase.io/

第一个真正意义上的物联网数据库，特点已经在官网有说明。总结一下：MQTT 消息直写（也兼容 pg 线协议），顶级的写入性能，顶级的分析查询性能（引擎内部对标 ClickHouse ，比 ClickHouse 快；外部对标 Timescale ，比 Timescale 快的 2-3 个数量级），免运维设计，极好的工程稳定性，完整地支持常用 SQL 函数。有待改进的是，目前只支持单机（但支持 HA ），复杂的 SQL 分析函数和 JOIN 还在进行中。

目前团队正在进行一些上云的工作，所以 SQL 方面的功能性增强会稍微放几天。

团队正在对有真实需求的企业用户提供免费内测，CEO 直接提供企业级支持，欢迎申请：
[email protected]

[wxt]

@ljhskyso7 多谢 抱拳