共计 2399 个字符，预计需要花费 6 分钟才能阅读完成。
在工业畛域，生产、测试、运行阶段都可能会产生大量带有工夫戳的传感器数据，这都属于典型的时序数据。时序数据次要由各类型实时监测、查看与剖析设施所采集或产生，波及制作、电力、化工、工程作业等多个行业，具备写多读少、量十分大等典型个性。如 Apache HBase、MySQL 等互联网公司罕用的数据库在写入、存储、查问、运维等方面都暴露出了诸多问题。这种状况下，从业务倒退的角度登程，数据架构革新成为了事不宜迟。
本文汇总了包含西门子、美的、拓斯达、和利时在内的四家比拟具备代表性的工业企业的架构革新案例，一起来看看他们都是如何做的，革新成果是否达成了预期。
西门子 x TDengine
“从高性能、高可用、低成本、高度一体化几个指标登程，咱们发现 TDengine 正好合乎产品重构所有的要求，尤其是低成本和高度一体化这两个点，这是目前绝大部分数据平台或时序数据库都不具备的。在确定抉择 TDengine 作为零碎的数据库后，咱们在 SIMICAS® OEM 2.0 版本中移除了 Flink、Kafka 以及 Redis，零碎架构大大简化。”
业务背景
SIMICAS® OEM 设施近程运维套件是由 SIEMENS DE&DS DSM 团队开发的一套面向设施制造商的数字化解决方案。在其 1.0 版中，团队应用了 Flink + Kafka + PostgreSQL + Redis 的架构，因为引入了 Flink 和 Kafka，导致系统部署时十分繁琐，服务器开销微小；同时为了满足大量数据的存储问题，PostgreSQL 中不得不做分库分表操作，应用程序较为简单。这种状况下，如何升高零碎复杂度、缩小硬件资源开销，帮忙客户缩小老本，成为研发团队的外围工作。在调研过程中，TDengine 怀才不遇。
架构图
点击【案例】查看更多技术细节
美的 x TDengine
“以后，TDengine 次要被利用于中央空调制冷设施的监控业务中，作为后行试点，这一场景曾经获得了不错的成果。在楼宇智能化方面，咱们也有很多工作要做，从边缘侧的监控、到指令管制、再到边云协同的一体化服务，咱们会在这些场景中持续摸索和开掘 TDengine 的后劲。”
业务背景
在 2021 楼宇科技 TRUE 大会上，美的暖通与楼宇事业部首次公布了数字化平台 iBuilding，以“软驱硬核”形式赋能建筑行业。作为一个全新的我的项目，iBuilding 在数据库选型上比拟审慎，别离比照了关系型数据库（Relational Database）以及支流的时序数据库（Time Series Database），包含 InfluxDB、TDengine、MySQL 等，因为在需要上更偏差于高效的存储和大范畴工夫的数据拉取，iBuilding 在综合评估了适配、查问、写入和存储等综合能力后，最终抉择了 TDengine。
架构图
点击【案例】查看更多技术细节
拓斯达 x TDengine
“运行一段时间后，TDengine 的查问、写入速度齐全能够满足咱们目前的客户需要，最慢的分钟级，最快的能达到 1 秒一条；一个设施一天最多能写入近十万条数据，近千个设施同时写入也齐全没有问题，相较于之前，写入速度晋升了数十倍。查问数据在以月为单位的工夫范畴内也没有过于显著的提早，整体的数据压缩比大略是 1/10，目前每天产生的数据量在数 G 左右。”
业务背景
在拓斯达的业务中，传统的关系型数据库曾经无奈高效解决时序数据，在加载、存储和查问等多个方面都遇到了挑战，次要问题包含写入吞吐低、存储老本大、保护老本高、查问性能差。为了更好地满足时序数据的解决需要，拓斯达开始进行数据库选型调研，他们发现，TDengine 专为时序数据库所打造和优化的写入、存储、查问等性能，十分匹配工业传感器数据的利用剖析场景，最终其应用 TDengine 搭建了新的数据处理架构。
架构实现思路
通过网关采集设施数据推送到 MQTT，Java 后端监听到后会写入 TDengine，在后端按需要查询处理后再把数据返回给前端。具体来说，网关会先读取后盾公布的上行规定，在采集到设施数据后，应用上行规定对数据进行解决计算后再将后果返回给上行规定模块，后盾监听到后，会连贯 TDengine 进行数据库表的创立批改和数据写入。之前在云平台拓斯达应用过 Kafka 进行数据的公布订阅，当初所有环境都改为 MQTT 了。
点击【案例】查看更多技术细节
和利时 x TDengine
“在测试阶段，咱们发现，同等条件下，TDengine 的压缩率最高，数据占用的存储空间最小；在原始数据查问上，OpenTSDB 最慢，TDengine 与 HolliTSDB 在伯仲之间；在聚合查问操作上，TDengine 最快，HolliTSDB 的速度和 InfluxDB 相当，OpenTSDB 最慢。同时，InfluxDB 只能单机部署，集群版本并未开源，且查问性能存在瓶颈，其 QPS 约为 30-50。”
业务背景
在物联网场景下，面对宏大的时序数据处理需要，Oracle、PostgreSQL 等传统关系型数据库越来越吃力，因而和利时开始进行时序数据库的选型，对包含 InfluxDB、OpenTSDB、HolliTSDB（和利时自研时序数据库）和 TDengine 在内的四款时序数据库进行了选型调研及相干测试。测试结果显示，在同等条件下，TDengine 在查问、存储等方面均优于其余几款数据库，最终和利时决定接入 TDengine，以享受更多元的本地化反对和响应。
架构图
点击【案例】查看更多技术细节
结语
从以上案例中不难看出，在工业互联网场景下，面对宏大的时序数据处理需要，业余的时序数据库显然比传统的关系型数据库成果更加显著，上述企业案例在架构革新之后，的确达到了更高水平的降本增效。如果你有同样的困扰，欢送增加小 T 微信，能够邀请你进入 TDengine 用户交换群，和业余的解决方案架构师点对点沟通。
想理解更多 TDengine Database 的具体细节，欢送大家在 GitHub 上查看相干源代码。
