夏令时的坑：你的数据库真的能正确处理时间跳变吗？

于 2025-03-26 15:01:35 发布
阅读量1.1k 收藏 17
点赞数 9
文章标签： 数据库
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/taos_data/article/details/146530032
版权

1.定义

1.1 时区

时区是地球上使用相同标准时间的区域。由于地球的自转，为了保证各地的时间与当地的日出日落相协调，全球划分为多个时区。

1.2 IANA 时区

IANA（Internet Assigned Numbers Authority）时区数据库，也称为 tz database，提供全球时区信息的标准参考。它是现代各类系统和软件处理时区相关操作的基础。

IANA 使用“区域/城市”格式（如 Europe/Berlin）来明确标识时区。

时序数据库 TDengine 在不同组件中均支持使用 IANA 时区（除 Windows taos.cfg 时区设置外）。

1.3 标准时间与当地时间

标准时间是根据地球上某个固定经线确定的时间。它为各个时区提供了一个统一的参考点。

  • 格林尼治标准时间（GMT）：历史上使用的参考时间，位于0°经线。

  • 协调世界时（UTC）：现代的时间标准，类似于GMT，但更加精确。

标准时间与时区的关系：

  • 基准：标准时间（如 UTC）是时区设定的基准点。

  • 偏移量：不同时区通过相对于标准时间的偏移量来定义。例如，UTC+1表示比 UTC 快 1 小时。

  • 区域划分：全球被划分为多个时区，每个时区使用一个或多个标准时间。

相对于标准时间，每个地区根据其所在时区设定其当地时间：

  • 时区偏移：当地时间等于标准时间加上该时区的偏移量。例如，UTC+2 表示比 UTC 时间快 2 小时。

  • 夏令时（DST）：某些地区在特定时间段调整当地时间，例如将时钟拨快一小时。详见下节。

1.4 夏令时

夏令时（Daylight Saving Time，DST）是一种通过将时间提前一小时，以充分利用日光、节约能源的制度。通常在春季开始，秋季结束。夏令时的具体开始和结束时间因地区而异。以下均以柏林时间为例，对夏令时和夏令时的影响做说明。

按照这个规则，可以看到：

  • 柏林当地时间 2024 年 3 月 31 日 02:00:00 到 03:00:00 （不含 03:00:00）之间的时间不存在（跳变）。

  • 柏林当地时间 2024 年 10 月 27 日 02:00:00 到 03:00:00 （不含 03:00:00）之间的时间出现了两次。

夏令时与 IANA 时区数据库

  • 记录规则：IANA 时区数据库详细记录了各地的夏令时规则，包括开始和结束的日期与时间。

  • 自动调整：许多操作系统和软件利用 IANA 数据库来自动处理夏令时的调整。

  • 历史变更：IANA 数据库还追踪历史上的夏令时变化，以确保准确性。

夏令时与时间戳转换

  • 时间戳转为当地时间是确定的。例如，1729990654 为柏林时间 夏令时 2024-10-27 02:57:34，1729994254 为柏林时间 冬令时 2024-10-27 02:57:34 （这两个本地时间除时间偏移量外是一样的）。

  • 不指定时间偏移量时，当地时间转为时间戳是不确定的。夏令时跳过的时间不存在会造成无法转换成时间戳，如 柏林时间 2024-03-31 02:34:56 不存在，所以无法转换为时间戳。夏令时结束时重复导致无法确定是哪个时间戳，如 2024-10-27 02:57:34 不指定时间偏移量无法确定 是 1729990654 还是 1729994254。指定时间偏移量才能确定时间戳，如 2024-10-27 02:57:34 CEST(+02:00) ，指定了夏令时 2024-10-27 02:57:34 时间戳 1729990654 。

1.5 RFC3339 时间格式

RFC 3339 是一种互联网时间格式标准，用于表示日期和时间。它基于 ISO 8601 标准，但更具体地规定了一些格式细节。

其格式如下：

  • 基本格式：YYYY-MM-DDTHH:MM:SSZ

  • 时区表示：

    • Z 表示协调世界时（UTC）。

    • 偏移量格式，例如 +02:00，表示与 UTC 的时差。

通过明确的时区偏移，RFC 3339 格式可以在全球范围内准确地解析和比较时间。

RFC 3339 的优势：

  • 标准化：提供统一的格式，方便跨系统数据交换。

  • 清晰性：明确时区信息，避免时间误解。

TDengine 在 REST API 和 Explorer UI 中，均使用 RFC3339 格式进行展示。在 SQL 语句中，可使用 RFC3339 格式写入时间戳数据：

insert into t1 values('2024-10-27T01:59:59.000Z', 0);
select * from t1 where ts >= '2024-10-27T01:59:59.000Z';

1.6 未定义行为

未定义行为（Undefined Behavior）是指特定代码或操作没有明确规定的结果，也不会对该结果作出兼容性的保证。在 TDengine 中，用户不可依赖当前未定义的行为进行判断或应用。

2. 夏令时在 TDengine 中的写入与查询

我们使用下表来展示夏令时在写入和查询中的影响。

2.1 表头说明

  • TIMESTAMP：TDengine 中使用 64位整数来存储原始时间戳。

  • UTC：时间戳对应的 UTC 时间表示。

  • Europe/Berlin：表示时区 Europe/Berlin 对应的 RFC3339 格式时间。

  • Local：表示时区 Europe/Berlin 对应的当地时间（不含时区）。

2.2 表格分析

  • 在夏令时开始（柏林时间 3月31日 02:00 ）时，时间直接从 02:00 跳到 03:00（往后跳一小时）。

    • 浅绿色是夏令时开始前一小时的时间戳；

    • 深绿色是夏令时开始后一小时的时间戳；

    • 红色为 TDengine 数据库中插入了不存在的当地时间：

      • 使用 SQL INSERT INTO t1 values('2024-03-31 02:59:59',..) 插入 2024-03-31 02:00:00 到 2024-03-31 02:59:59 的数据会被自动调整为 -1000（在 TDengine 中属于未定义行为，当前该值与数据库精度 precision 有关，毫秒数据库为 -1000，微秒数据库为 -1000000，纳秒数据库为 -1000000000），因为那一时刻在本地时间中不存在；

  • 在夏令时结束（柏林时间 10 月 27 日 03:00）时，时间从 03:00 跳到 02:00 （往前跳一小时）。

    • 浅蓝色表示时钟跳变前一小时的时间戳；

    • 深蓝色表示时钟跳变后一小时内的时间戳，其无时区的当地时间与上一小时一致。

    • 紫色表示时钟跳变一小时后的时间戳；

  • 当地时间变化：可见，由于夏令时的调整而导致了当地时间的变化，可能导致某些时间段出现重复或缺失。

  • UTC时间不变：UTC 时间保持不变，确保了时间的一致性和顺序性。

  • RFC3339：RFC3339 格式时间显示了时间偏移量的变化，在夏令时开始后变为 +02:00，结束后变为 +01:00 。

  • 条件查询：

    • 夏令时开始时，跳过的时间（[03-31 02:00:00,03-31 03:00:00)）不存在，所以在使用该时间进行查询时，行为不确定：SELECT ts FROM t1 WHERE ts BETWEEN '2024-03-31 02:00:00' AND '2024-03-31 02:59:59' （不存在的本地时间戳被转换为 -1000）:

    taos> SELECT ts FROM t1 WHERE ts BETWEEN '2024-03-31 02:00:00' AND  '2024-03-31 02:59:59';
       ts       |
=================
 -1000 |
Query OK, 1 row(s) in set (0.003635s)

    当不存在的时间戳与存在的时间戳共同使用时，其结果同样不符合预期，以下为起始本地时间不存在：

    taos> SELECT ts, to_iso8601(ts,'Z') FROM t1 WHERE ts BETWEEN '2024-03-31 02:00:00' AND  '2024-03-31 03:59:59';
       ts       |       to_iso8601(ts,'Z')       |
==================================================
 -1000 | 1969-12-31T23:59:59.000Z       |
 1711843200000 | 2024-03-31T00:00:00.000Z       |
 1711846799000 | 2024-03-31T00:59:59.000Z       |
 1711846800000 | 2024-03-31T01:00:00.000Z       |
 1711846801000 | 2024-03-31T01:00:01.000Z       |
Query OK, 5 row(s) in set (0.003339s)

    以下语句中第一个 SQL 查询截止时间不存在，第二个截止时间存在，第一个 SQL 查询结果不符合预期：

    taos> SELECT ts, to_iso8601(ts,'Z') FROM t1 WHERE ts BETWEEN '2024-03-31 01:00:00' AND  '2024-03-31 02:00:00';
Query OK, 0 row(s) in set (0.000930s)

taos> SELECT ts, to_iso8601(ts,'Z') FROM t1 WHERE ts BETWEEN '2024-03-31 01:00:00' AND  '2024-03-31 01:59:59';
       ts       |       to_iso8601(ts,'Z')       |
==================================================
 1711843200000 | 2024-03-31T00:00:00.000Z       |
 1711846799000 | 2024-03-31T00:59:59.000Z       |
Query OK, 2 row(s) in set (0.001227s)

    • 夏令时结束时，跳变的时间（[10-27 02:00:00,10-27 03:00:00) 不包含 10-27 03:00:00）重复了两次，TDengine 在使用该区间内的时间戳进行查询时，也属于未定义行为。

      • 查询 [2024-10-27 02:00:00, 2024-10-27 03:00:00] 之间的数据结果，包含了两次重复的时间戳和 2024-10-27 03:00:00 这个时间点的数据：

    taos> SELECT ts, to_iso8601(ts,'Z'), TO_CHAR(ts, 'YYYY-MM-DD HH:mi:ss') FROM t1 WHERE ts BETWEEN '2024-10-27 02:00:00' AND  '2024-10-27 03:00:00';
       ts       |       to_iso8601(ts,'Z')       | to_char(ts, 'YYYY-MM-DD HH:mi:ss') |
=======================================================================================
 1729987200000 | 2024-10-27T00:00:00.000Z       | 2024-10-27 02:00:00                |
 1729990799000 | 2024-10-27T00:59:59.000Z       | 2024-10-27 02:59:59                |
 1729990800000 | 2024-10-27T01:00:00.000Z       | 2024-10-27 02:00:00                |
 1729994399000 | 2024-10-27T01:59:59.000Z       | 2024-10-27 02:59:59                |
 1729994400000 | 2024-10-27T02:00:00.000Z       | 2024-10-27 03:00:00                |
Query OK, 5 row(s) in set (0.001370s)

    但以下查询 [2024-10-27 02:00:00.000,2024-10-27 02:57:34.999] 区间只能查询到第一个2024-10-27 02:00:00 时间点的数据：

    taos> SELECT ts, to_iso8601(ts,'Z'), TO_CHAR(ts, 'YYYY-MM-DD HH:mi:ss') FROM t1 WHERE ts >= '2024-10-27 02:00:00' AND ts <= '2024-10-27 02:57:00.999';
       ts       |       to_iso8601(ts,'Z')       | to_char(ts, 'YYYY-MM-DD HH:mi:ss') |
=======================================================================================
 1729987200000 | 2024-10-27T00:00:00.000Z       | 2024-10-27 02:00:00                |
Query OK, 1 row(s) in set (0.004480s)

    以下查询 [2024-10-27 02:00:01,2024-10-27 02:57:35] 却能查到 3 条数据（包含一条 02:59:59 的当地时间数据）：

    taos> SELECT ts, to_iso8601(ts,'Z'), TO_CHAR(ts, 'YYYY-MM-DD HH:mi:ss') FROM t1 WHERE ts >= '2024-10-27 02:00:00' AND ts <= '2024-10-27 02:57:35';;
           ts            |       to_iso8601(ts,'Z')       | to_char(ts, 'YYYY-MM-DD HH:mi:ss') |
================================================================================================
 2024-10-27 02:00:00.000 | 2024-10-27T00:00:00.000Z       | 2024-10-27 02:00:00                |
 2024-10-27 02:59:59.000 | 2024-10-27T00:59:59.000Z       | 2024-10-27 02:59:59                |
 2024-10-27 02:00:00.000 | 2024-10-27T01:00:00.000Z       | 2024-10-27 02:00:00                |
Query OK, 3 row(s) in set (0.004428s)

    3 总结与建议

    3.1 总结

    仅针对使用当地时间带来的影响作说明，使用 UNIX 时间戳或 RFC3339 无影响。

    • 写入：

      • 无法写入夏令时跳变时不存在的时间数据。

      • 写入夏令时跳变时重复的时间是未定义行为。

    • 查询：

      • 查询条件指定夏令时开始时跳变的时间，其查询结果为未定义行为。

      • 查询条件指定夏令时结束时重复的时间，其查询结果为未定义行为。

    • 显示：

      • 带时区显示不受影响。

      • 显示当地时间是准确的，但夏令时结束时重复的时间会无法区分。

      • 用户应谨慎使用不带时区的时间进行展示和应用。

    3.2 建议

    为避免夏令时给查询和写入造成不必要的影响，在 TDengine 中，建议使用明确的时间偏移量进行写入和查询。

    • 使用 UNIX 时间戳：使用 UNIX 时间戳可避免时区问题。

      taos> insert into t1 values(1711846799000, 1)(1711846800000, 2);
Insert OK, 2 row(s) affected (0.001434s)

taos> select * from t1 where ts between 1711846799000 and 1711846800000;
       ts       |     v1      |
===============================
 1711846799000 |           1 |
 1711846800000 |           2 |
Query OK, 2 row(s) in set (0.003503s)

      使用 RFC3339 时间格式：带时区偏移量的 RFC3339 时间格式可以有效避免夏令时的不确定性。

      taos> insert into t1 values ('2024-10-27T02:00:00.000+02:00', 1)
                            ('2024-10-27T02:59:59.000+02:00', 2)
                            ('2024-10-27T02:00:00.000+01:00', 3)
                            ('2024-10-27T02:59:59.000+01:00', 4);
Insert OK, 4 row(s) affected (0.001514s)

taos> SELECT *,
             to_iso8601(ts,'Z'),
             to_char(ts, 'YYYY-MM-DD HH:mi:ss') FROM t1
      WHERE ts >= '2024-10-27T02:00:00.000+02:00'
        AND ts <= '2024-10-27T02:59:59.000+01:00';
       ts      |     v1  |       to_iso8601(ts,'Z')       | to_char(ts, 'YYYY-MM-DD HH:mi:ss') |
=====================================================================================================
 1729987200000 |       1 | 2024-10-27T00:00:00.000Z       | 2024-10-27 02:00:00                |
 1729990799000 |       2 | 2024-10-27T00:59:59.000Z       | 2024-10-27 02:59:59                |
 1729990800000 |       3 | 2024-10-27T01:00:00.000Z       | 2024-10-27 02:00:00                |
 1729994399000 |       4 | 2024-10-27T01:59:59.000Z       | 2024-10-27 02:59:59                |
Query OK, 4 row(s) in set (0.004275s)

taos> SELECT *,
             to_iso8601(ts,'Z'),
             to_char(ts, 'YYYY-MM-DD HH:mi:ss') FROM t1
      WHERE ts >= '2024-10-27T02:00:00.000+02:00'
        AND ts <= '2024-10-27T02:59:59.000+02:00';
       ts      |     v1  |       to_iso8601(ts,'Z')       | to_char(ts, 'YYYY-MM-DD HH:mi:ss') |
=====================================================================================================
 1729987200000 |       1 | 2024-10-27T00:00:00.000Z       | 2024-10-27 02:00:00                |
 1729990799000 |       2 | 2024-10-27T00:59:59.000Z       | 2024-10-27 02:59:59                |
Query OK, 2 row(s) in set (0.004275s)

      • 查询时注意时区设定：在查询和显示时，如果需要本地时间，务必考虑夏令时的影响。

        • taosAdapter：使用 REST API 时，支持设置 IANA 时区，结果使用 RFC3339 格式返回。

      $ curl -uroot:taosdata 'localhost:6041/rest/sql?tz=Europe/Berlin'\
  -d "select ts from tz1.t1"
{"code":0,"column_meta":[["ts","TIMESTAMP",8]],"data":[["1970-01-01T00:59:59.000+01:00"],["2024-03-31T01:00:00.000+01:00"],["2024-03-31T01:59:59.000+01:00"],["2024-03-31T03:00:00.000+02:00"],["2024-03-31T03:00:01.000+02:00"],["2024-10-27T02:00:00.000+02:00"],["2024-10-27T02:59:59.000+02:00"],["2024-10-27T02:00:00.000+01:00"],["2024-10-27T02:59:59.000+01:00"],["2024-10-27T03:00:00.000+01:00"]],"rows":10}

      • Explorer：使用 Explorer 页面进行 SQL 查询时，用户可配置客户端时区，以 RFC3339 格式显示。

      更加详细的内容可查看官方技术文档：https://docs.taosdata.com/train-faq/dst/?utm_source=tech-blog&utm_medium=zimeiti&utm_campaign=2025-01-12

      参考文档

      • DST: Wikipedia Daylight Saving Time

      • IANA Time Zone Database: https://www.iana.org/time-zones

      • RFC3339: https://datatracker.ietf.org/doc/html/rfc3339

      博客
      第四朵“云”！全托管的时序数据云平台 TDengine Cloud 正式支持阿里云
      03-20 1022
      TDengine Cloud 上线第四朵公有云
      博客
      写入性能：TDengine 最高达到 InfluxDB 的 10.3 倍，TimeScaleDB 的 6.74 倍
      03-03 1371
      为了便于大家更好地阅读和理解，基于《 TSBS 的时序数据库（Time Series Database，TSDB）性能基准测试报告》内容，我们将从写入、查询及测试过程如何复现等几大维度输出系列文章。本篇文章将为大家解读三大时序数据库在写入性能上的差异点。
      博客
      TSBS 是什么？为什么时序数据库 TDengine 会选择它作为性能对比测试平台？
      03-01 1431
      为了客观、准确、有效地评估 TDengine 3.0 的性能指标，我们决定使用 TSBS（Time Series Benchmark Suite）作为基准性能测试平台，针对 DevOps 场景的数据集对 TDengine 3.0 展开整体（包括写入、查询、存储、资源消耗等）性能评估。
      博客
      TDengine 发布主流时序数据库对比分析报告，与 InfluxDB、TimescaleDB 展开全面对比测试
      02-23 1460
      报告旨在验证 TDengine 基于时序数据场景所设计的独特架构带来的性能优势以及成本控制水平，其中所有测试均在标准化条件下使用公开数据完成。
      博客
      TDengine3.0：解决高基数问题的时序数据库设计思路
      12-05 1566
      TDengine 3.0 是第一个解决了高基数问题的时序数据库，本文将分享其设计思路。
      博客
      彻底开源、十倍性能的背后：TDengine 核心技术首度公开
      11-13 2万+
      2020年11月7日，TDengine技术开放日（北京站）在中关村举办。开源一年零四个月，14k Star，3.6k Fork，日增100+的开源用户数……除了这些亮眼的数字外，本次技术开放日上，TDengine核心作者团队，还亮出了杀手锏，首度公开了TDengine彻底开源、十倍性能的背后核心技术和设计思想。特此回顾，希望能帮助更多开发人员和物联网从业者深入了解TDengine的优势与技术理念。回顾视频和演讲PPT的获取方式见文末。当万物互联的理想一步步走向现实，物联网产业也开始面对一系列前所未有的挑战
      博客
      TDengine 2.0正式上线，集群功能开源，不用再为高可靠、数据规模大而发愁了
      08-03 2万+
      2019年7月，涛思数据团队将精心研发的TDengine 1.6版本开源，开源后，产品获得了开发者社区的积极反馈。从超过百万用户的体验反馈中，我们团队发现了一些技术问题。而彻底解决这些问题，需要我们对一些功能进行重新的设计和研发。历经八个月的披星戴月，TDengine 2.0 终于来了！下面一起来看看，TDengine 2.0具体都有哪些升级改进。秉持开源初心，率先将集群版开源我们在与开源社区用户的沟通中发现，对于时序大数据的处理，仅仅使用开源的单机版，对很多场景来说是远远不够的。而越来越多的开源时
      博客
      聚焦查询引擎优化：技术人如何在国产数据库项目中不断突破
      04-29 792
      他曾在华为写协议、在联想设计全球负载均衡系统、在 Oracle 深入区块链核心模块，参与过多个重量级项目。但直到他加入涛思数据，才真正开启了一段从“技术精英”到“团队带头人”的深度蜕变旅程。2024 年，潘魏成为之一。这份荣誉不仅是对他技术贡献的肯定，也象征着他在推动查询引擎不断进化、带领团队突破极限方面的认可。但他和的故事还要从 2020 年的那个秋天讲起。
      博客
      时序数据库 TDengine × Perspective：你需要的可视化“加速器”
      04-29 567
      数据不会说谎，但你需要一个窗口，看到它在说什么。TDengine× Perspective 不仅是一种集成方式，更是为了让数据“看得见、看得清、看得懂”。现在就赶快来试试这套解决方案吧，点击阅读原文可查看更详细的集成信息，开启你的可视化“进阶探索”之旅！
      博客
      宁德新能源：时序数据库 TDengine 支撑百万级工业设备实时数据高效治理
      04-29 1004
      宁德新能源正计划进一步拓展TDengine在数字孪生、AI 质检等核心场景中的应用，打造锂电行业的工业互联网标杆平台，持续引领新能源产业的技术创新。未来规划包括：将TDengine部署扩展至全球 5 个生产基地，实现统一的数据平台架构；集成 AI 框架，实现毫秒级工艺参数调优，推动制造过程智能化升级；构建 TB 级时序数据沙箱，供研发团队进行建模、验证与算法训练，释放数据潜能。我们期待TDengine。
      博客
      从啃源码到主导查询引擎优化，他靠什么赢得 CEO Award？
      04-24 511
      我们将深入解析传统架构在智慧交通中的短板，介绍 TDengine 在智慧高速、桥梁健康监测等场景的落地实践，展示如何通过“感知-决策-控制”三步走，实现交通数据的秒级闭环处理。在理解这一本质后，他们换了个创新思路，“线程数不受限，只需要并发运行的线程数受限即可”，最终通过“线程接力”的方式优雅解决了问题，既大幅减少了优化工作量，又满足了限制性需求，也保障了性能。“比如你在做一个功能时，如果是按自己的能力上限去思考和设计，最后把心里所有的 TODO LIST 全部消灭，我觉得你就是一个很厉害的人了。
      博客
      从边缘到云端，如何通过时序数据库 TDengine 实现数据的全局洞
      04-23 949
      TDengine边云协同解决方案凭借其高效的数据同步能力、灵活的配置机制和强大的实时处理性能，成为应对工业互联网场景下数据管理挑战的有力工具。通过统一的边云架构，TDengine能够在满足边缘侧实时处理需求的同时，将大量数据高效汇聚至云端，帮助企业在数据分析和决策上实现全局视角。希望本文能够帮助企业更好地理解边云协同技术的优势，并为其未来的数字化转型和智能化生产提供有价值的参考。
      博客
      时序数据库 TDengine 助力石油石化业务， 平滑接替 Oracle 数据库
      04-23 1188
      石油石化行业的时序数据广泛应用于能源生产、运输、加工和销售等环节，大量设备、传感器和监控系统持续生成时时序数据，用于支撑生产监控、调度优化和故障预警。早年时序数据库尚不成熟，我们曾采用 Oracle 存储某大型油田的时序数据，但随着业务数据量快速增长，各油田系统在数据处理和查询性能上逐渐暴露出瓶颈。石油石化是胜软科技重点服务的行业之一，而涛思数据也在该领域积累了丰富的实践经验。
      博客
      工业数据治理范式革新：时序数据库 TDengine虚拟表技术解析
      04-16 1232
      凭借卓越的性能和强大的功能，TDengine成功搭建了 OT 与 IT 场景之间的高效过渡桥梁。未来，业务应用将不再受制于 OT 数据与 IT 业务数据格式的差异，数据整合与应用将更加顺畅。随着业务规模的不断扩大，TDengine的易用性优势将愈发显著，为企业数字化转型筑牢坚实的数据根基，助力企业迈向智能化、高效化的未来发展之路。
      博客
      新客户 | 美妆智造全面升级：毫秒级查询 + 极致压缩
      04-16 283
      如果你也在数字化转型中遇到数据接入复杂、实时性要求高、系统集成难等挑战，欢迎进入 https://taosdata.feishu.cn/share/base/form/shrcnUtB1ogP9bwxr9LWRYFKfNb 留下你的需求信息，为了提升数据处理能力，打造更高效、智能的生产体系，创元集团与涛思数据（化妆品行业对生产精度和质量控制要求极高，创元集团在不断扩大生产规模的同时，也面临着数据管理和分析的挑战。此外，多维数据关联分析能力加强，使质量管理更加精准，助力创元集团进一步推进智能化升级。
      博客
      虚拟表、TDgpt、JDBC 异步写入…TDengine 3.3.6.0 版本 8 大升级亮点
      04-08 781
      近日，3.3.6.0 版本正式发布。除了此前已亮相的时序数据分析 AI 智能体 TDgpt，本次更新还带来了多个针对性能与易用性的重要增强：虚拟表全面上线，支持更灵活的一设备一表建模；JDBC 写入机制全新升级，单线程性能最高提升 60 倍；流计算支持 CONTINUOUS_WINDOW_CLOSE 模式、事件通知机制等关键能力，为实时处理打下更稳固的基础。本文为你整理了该版本的八大核心更新亮点，并附上社区版和企业版的详细新增功能。如果你还没来得及深入了解，不妨现在看看，哪些能力正好能解决你的当前需求👇。
      博客
      时序数据库 TDengine Cloud 私有连接实战指南：4步实现数据安全传输与成本优化
      04-08 1292
      通过上述四步简单的配置过程，现在你可以轻松地享受到由TDengineCloud 私有连接带来的诸多好处，包括但不限于更高的安全性、更低的成本以及更好的性能表现。立即采取行动吧！访问TDengine Cloud官网，注册并创建免费实例。按照TDengine Cloud 私网连接配置文档完成私有连接设置，体验前所未有的数据传输效率与安全性。
      博客
      时序数据库 TDengine + Tableau，数据可视化一步到位！
      04-08 272
      过去，我们谈TDengine，总是讲写入有多快、存储多省、查询多稳。现在，是时候看看这些数据如何“活”起来了。Tableau 的加入不仅让TDengine的数据变得更直观、更具说服力，也为你开启了一个更广阔的分析空间。下一步？快打开 Tableau，接入你的TDengine数据，做一个你自己都惊艳的仪表盘吧！
      博客
      时序数据库 TDengine × Excel：一份数据，两种效率
      04-07 534
      对于需要做简单数据查询和可视化的用户来说，Excel 是最直接的工具。现在，TDengine通过 ODBC 实现了对 Excel 的支持，进一步降低了数据使用的门槛。如果你团队正在使用 Excel 处理日常数据，不妨试试看这个集成方式，也许能节省不少时间。
      博客
      技术揭秘｜TDgpt 如何让时序数据库原生支持 AI？
      04-07 638
      在时序数据预测分析、异常检测、数据补全和数据分类等应用领域，研究人员提出并开发了众多具有不同技术特点、适用于不同场景的时序数据分析算法，已被广泛应用在时序数据预测、异常检测等任务中。这类分析算法通常以高级编程语言（Python 语言或 R 语言）工具包的形式存在，并通过开源的方式广泛分发和使用，这种应用模式极大地便利了软件开发人员在应用系统中调用复杂的分析算法，大大降低了使用高级算法的门槛。与此同时，数据库系统的研发也在不断演进。
      评论
      添加红包

      请填写红包祝福语或标题

      个

      红包个数最小为10个

      元

      红包金额最低5元

      当前余额3.43元 前往充值 >
      需支付：10.00元
      成就一亿技术人!
      领取后你会自动成为博主和红包主的粉丝 规则
      hope_wisdom
      发出的红包
      实付元
      使用余额支付
      点击重新获取
      扫码支付
      钱包余额 0

      抵扣说明：

      1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
      2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

      余额充值