工业企业搞数字化转型，最头疼的莫过于 “数据基础设施跟不上”—— 成千上万的设备测点、实时涌来的时序数据、云与 AI 的落地需求，选不对平台不仅白费钱，还会拖慢整个转型节奏。今天我们就拿两款主流工业数据平台——TDengine 与 AVEVA PI System 做深度对比，帮你理清选型思路，避开 “高价踩坑”“扩展受限” 的雷区。 先认识下两款核心平台 关于 AVEVA PI System 作为
工业数据管理的核心矛盾，正从 “如何存下海量数据” 转向 “如何让数据真正服务业务”。Chat BI（智能问数）用自然语言降低了分析门槛，但其“有问才答”的被动模式，在复杂的工业现场逐渐暴露出局限：参数语义混乱、设备关联复杂、响应滞后。 TDengine IDMP 通过 “无问智推” 模式，将数据消费从 “人找数据” 推向 “数据找人”，这一演进并非概念创新，而是基于工业场景特性的技术落地，核心是
过去十年，工业和物联网场景经历了快速的数字化建设：传感器接入、系统联网、数据上云……数据平台已能轻松承载每秒千万级别的写入，每天几 TB 的存储量。但今天再回头看，这些看似“完成”的系统，实际上只解决了一个问题：把数据“存起来”。而“用起来”这一层，仍旧是碎片化的、高门槛的、效率低下的。 为了解决“用起来”的问题，行业开始尝试自然语言查询、自动生成 SQL 等方式，并逐渐发展出 Chat BI 这
小T导读：运维数据库到底有多复杂？从系统部署到数据接入，从权限配置到监控告警，动辄涉及命令行、脚本和各种文档查找，一不留神就可能“翻车”。为了让时序数据库 TDengine 用户轻松应对这些挑战，我们推出了《TDengine 运维实战手册》系列内容，将系统性地介绍 TDengine 提供的各类运维工具和实践方法，帮你从繁杂中解脱出来。本文为第一篇，带你了解 TDengine 的可视化管理组件 ta
在做设备预测性维护或能源管理分析时，你是否也曾思考过：如何才能让机器“理解”我们收集的大量时序数据？工业现场的数据是结构化的，而语义分析、知识推理却往往需要 RDF 等图谱格式。换句话说，“会说话”的数据更聪明，但“翻译”的门槛太高。 时序数据库 TDengine 最近完成了一项全新集成——连接 Ontop，一个开源的虚拟知识图谱系统，实现时序数据向知识图谱的自动转化，带你一步迈入语义化分析的新世
高性能时序数据库 + 企业级报表平台，帮你用更少的操作、更高的效率，制作出更稳定、更规范的专业报表，彻底告别复制粘贴和手动更新。
现在有了 TDengine × Looker Studio 的全新集成，数据可视化这件事，也能变得轻松高效。
在新能源行业中，多采用数据中台来管理业务数据，使用时序数据库（Time Series Database）来管理时序数据，他们的数据都来自数采网关。以风力发电场景为例，需要实时计算风机的各种 KPI 指标，往往通过数据中台的定时任务来完成这些计算。目前，现有的方案存在几个方面的问题：首先，由于是定时任务，KPI 计算的实时性无法保证，特别是在 KPI 的计算需要多个步骤才能完成的情况下，延迟可能会长
内存泄漏是一种常见的，它会导致程序的内存占用逐渐增加，最终导致系统资源耗尽或程序崩溃。这次内存泄漏发生在 Windows 下， 研发选择使用 Windbg 来解决。结果证明，在 Windows 下，使用 Windbg 也是一个不错的选择。
利用 Enterprise 和 Cloud 的数据接入功能，我们现在能够将 MQTT、InfluxDB 中的数据通过规则无缝转换至 中，由于该功能在实现及使用上与 Logstash 类似，本文将结合 Logstash 为大家进行解读。
近日，TDengine 3.2.1.0 成功发布，本文将向大家简单介绍一下该版本涉及到的重大功能优化。
本篇文章中，我们将就如何在 TDengine 中开启 TSZ 压缩算法进行详细说明，并会针对 TSZ 压缩算法展开功能测试，为大家验证其在实际业务场景中的更优性能。
在本文中，TDengine 资深研发将以 TDengine 3.0 为对象，为大家介绍数据订阅功能的正确打开方式，给到有需要的人作参考指南，避免走入应用误区。
通过 TDengine Java connector，Seeq 可以轻松支持查询 TDengine 提供的时序数据，并提供数据展现、分析、预测等功能。本文将对此进行介绍。
为了帮助开发者更好地进行 SpringBoot 的开发，避免开发盲点，我们将 TDengine 资深研发所做的内部分享——《SpringBoot 多语言支持方案》进行了相关整理，给到有需要的开发者参考。
本文将通过一个具体的案例，介绍 Intel 团队如何使用 TDengine 作为基础软件存储实验数据，并通过 TDengine 高效的查询能力在 OpenVINO 部署深度学习模型，最终在 AIxBoard 开发板上实时运行分类任务。
为了给用户打造更丰富的可视化方案，TDengine 在开源不久就提供了对 Grafana 的支持，此后也在不断升级改造 TDengine Grafana 插件，还推出了基于 Grafana 的零依赖监控解决方案 TDinsight。本篇文章将以 tdengine-datasource 为例介绍 Grafana 插件开发。
在本篇文章中，我们将从 GitHub 上的一个关于内存泄漏的 issue入手，和大家探讨下导致内存泄漏的原因，以及如何避免和定位内存泄漏。
经过我们不断地打磨优化之后，TDengine 3.0 在性能、功能、稳定性各个方面均有大幅提升，已经从一款时序数据库蜕变成为高性能、云原生、分布式的物联网、工业大数据平台。
大家都知道：由于单机数据库在数据规模、并发访问量等方面存在瓶颈，无法满足大规模应用的需求。因此才有了把数据切割分片，分布存储分布处理在多个节点上的数据库，也就是分布式数据库的由来。 而为了实现数据库的高可用，又有了多副本的概念，副本之间的数据需要用特定算法保持一致，从而可以随时切换身份对外提供高可用服务—— TDengine 就是一款这样的分布式时序数据库（Time Series Databas
本文介绍如何使用存储在 TDengine 中的现有数据来预测未来数据。我们将模拟一些测试数据以反映真实的电力系统，并演示如何使用 TDengine 和一些 Python 库来预测未来一年的数据。
许多用户会有一个疑问，“落盘”俩字听起来就很底层，似乎无法和手头的性能问题联系到一起，本篇文章的目的就是让大家对它们俩建立起直观的认识。
如果需要对数据库性能优化，了解数据文件的存储方式和工作原理是必要的。 对于时序数据库（Time Series Database） TDengine 来说，在 2.x 版本中时序数据的保留策略是由keep和days这两个参数把控的。（详情可见：https://mp.weixin.qq.com/s/uJEQwN0NnmSTBAMOecAtoA）我们通过 keep 和 days 来对时序数据进行分段保留，而每一段时间的数据就可以便对应着数据库中数据vnode目录下的一组数据文件，也就是我们这篇文章的主角。
TDengine 3.0.4.0 发布了一个重要特性： 支持用 Python 语言编写的自定义函数（UDF）。这个特性极大节省了 UDF 开发的时间成本。作为时序大数据处理平台，不支持 Python UDF 显然是不完整的。UDF 在实现自己业务中特有的逻辑时非常有用，比如量化交易场景计算自研的交易信号。本文内容由浅入深包括 4 个示例程序： 定义一个只接收一个整数的标量函数： 输入 n， 输出
在 3.0 当中，我们在产品底层做了很大的变化调整，除了架构更加科学高效以外，用户体验也是我们重点优化的方向。
选择到一款合适的数据库，对于打造一个适合业务发展的数据架构至关重要。为了找到该问题的最优解，涛思数据解决方案架构师从数据本质出发进行分析，结合具体实践输出本文，给到大家参考。
TDengine 3.0 的发布至今，我们除了在持续地优化产品质量的本身，也一直在努力地提升用户体验。但由于 3.0 底层有大量的重构优化，导致开源版的 2.0 用户无法通过常规途径来升级到 3.0 ，本期文章将会协助大部分开源版用户解决这个问题。
基于第三方基准性能测试平台 TSBS（Time Series Benchmark Suite） 标准数据集，TDengine 团队分别就 TSBS 指定的 DevOps 中 cpu-only 五个场景，对时序数据库（Time Series Database，TSDB）TimescaleDB 和 TDengine 进行了对比测试。本文将会从写入、存储、查询及资源开销等几大维度为大家汇总分析测试结果。
taosKeeper 应用语法解读
Copyright © 2005-2025 51CTO.COM 版权所有 京ICP证060544号
