Tdengine

<article class=“article fmt article-content”><p>近日，树根互联与涛思数据达成签约单干，独特推动智能制作畛域的建设。作为一家处于高速发展期的工业互联网企业，树根互联将新一代信息技术与制造业深度交融，开发了以自主可控的工业互联网操作系统为外围的工业互联网平台——根云平台。这一平台间断四年（2019-2022）入选了Gartner“寰球工业互联网平台魔力象限”。在本次单干中，TDengine 胜利利用于根云平台的建设中，为其提供更弱小的数据反对和剖析能力。</p><p>据理解，树根互联旗下根云平台先前采纳的时序数据库计划是 InfluxDB。随着业务规模不断扩大，InfluxDB 在解决高基数数据时呈现了写入和查问性能降落的问题。为了应答这一挑战，其团队开始对原有数据架构进行降级和调整，通过多计划技术选型后，他们察看到 TDengine 在高基数场景下的高性能和高压缩比特点，最终决定抉择 TDengine 作为新的数据基座。</p><p>值得一提的是，本次单干的革新成果也十分显著。通过引入 TDengine Enterprise（企业版）的多级存储计划，根云平台胜利将原先须要应用 30 多台 NVME 存储服务器的架构，优化为仅需 3 台高效云盘+机械硬盘的服务器配置。这一革新不仅大幅节俭了硬件老本开销，还升高了运维的工作量。这种高效的多级存储架构使得数据管理更加灵便和高效，为根云平台的下一步倒退提供了更稳固、弱小的数据反对，助力其更好地满足智能制作畛域的需要和挑战。</p><h4>对于树根互联</h4><p>树根互联自成立以来，一直开辟跨行业、跨畛域的服务能力，已为配备制作、钢铁冶金、汽车整车及零配件、电气等数十个工业细分行业近千家工业企业提供工业互联网服务。树根互联提供的工业互联网解决方案次要包含智能制作 IIoT 解决方案、产品智能化 IIoT 解决方案、产业链 IIoT 解决方案，全面赋能工业企业的智能生产治理、产品与服务的翻新以及产业链协同，提供低成本、低门槛、高效率、高牢靠的工业互联网数字化转型服务。此外，其还助力打造了环保、铸造、纺织等多个产业链工业互联网利用，带动一大批上下游企业实际数字化转型。</p><h4>对于 TDengine</h4><p>TDengine 外围是一款高性能、集群开源、云原生的时序数据库（Time Series Database，TSDB），专为物联网、工业互联网、电力、IT 运维等场景设计并优化，具备极强的弹性伸缩能力。同时它还带有内建的缓存、流式计算、数据订阅等零碎性能，能大幅缩小零碎设计的复杂度，升高研发和经营老本，是一个高性能、分布式的物联网、工业大数据平台。以后 TDengine 次要提供两大版本，别离是反对私有化部署的 TDengine Enterprise 以及全托管的物联网、工业互联网云服务平台 TDengine Cloud，两者在开源时序数据库 TDengine OSS 的性能根底上有更多增强，用户可依据本身业务体量和需要进行版本抉择。</p></article>

<article class=“article fmt article-content”><p>内存透露是一种常见的问题，它会导致程序的内存占用逐步减少，最终导致系统资源耗尽或程序解体。AddressSanitizer (ASan) 和 Valgrind 是很好的内存检测工具，TDengine 的 CI 过程就应用了 ASan 。不过这次内存透露问题产生在 Windows 下，咱们 CI 临时还没有笼罩到，因而 TDengine 研发抉择应用 Windbg 来解决问题。后果证实，在 Windows 下，应用 Windbg 也是一个不错的抉择。</p><h2>内存透露的罕用检测办法</h2><p><strong>内存透露通常会产生在以下状况下：</strong></p><ul><li>程序未正确开释已调配的内存</li><li>程序中存在循环援用，导致垃圾收集器无奈回收内存</li><li>程序中存在内存透露的第三方库或组件</li></ul><p><strong>内存透露的检测办法次要包含以下几种：</strong></p><ol><li>动态代码剖析工具：未开释的指针或内存调配谬误等问题，不能检测在程序运行时动静分配内存的状况。</li><li>动态分析工具：能够应用内存调配和开释跟踪器来跟踪程序中的内存调配和开释操作，并检测是否存在内存透露的状况。然而，应用某些工具（如Valgrind）可能会对程序的性能产生肯定的影响。</li><li>调试器：WinDbg 和 GDB。</li></ol><p><strong>优缺点：</strong></p><ul><li>动态代码剖析工具能够在晚期发现问题，然而它们不能检测程序运行时动静分配内存的状况。</li><li>动态分析工具能够在程序运行时检测问题，然而它们可能会影响程序性能，并且在检测大型应用程序时可能须要大量的工夫和资源。不过在资源短缺的测试环境中跑的话，就都不是问题了，比方 ASan 就帮咱们发现过不少问题。</li><li>调试器能够在程序运行时检测问题，并提供弱小的剖析工具。</li></ul><h2>实际剖析</h2><h3>基本原理</h3><p>应用 Windbg 定位内存泄露，依赖 glags 组件记录程序在运行期间所有申请和开释的内存，同时记录的还有申请内存时的调用栈信息。这样在程序运行期间，应用 umdh 组件进行两次快照记录，通过比拟两次快照信息的差别，就能够发现两次快照间隔时间段中申请却并未开释的内存申请信息。如果有内存泄露，diff 后果最前边个别就是透露点的调用栈信息。当然，两次快照期间，要尽量触发内存泄露，能力更精确的定位。diff 后果中还会有大量失常的申请没来得及开释的调用信息，不过 diff 后果中能看到调用次数，比拟容易甄别。</p><h3>问题介绍</h3><p>taosdump 在 windows 导入数据出错：</p><pre><code>build and install latest TDengine 3.0 branch on Windowsuse “taosBenchmark -I stmt -y” to create a lot of tables and data (10000 * 10000).use “taosdump -D test -o outputFile” to dump outuse “taos -s ‘drop database test’” to drop databaseuse “taosdump -i inputFile” to dump in.</code></pre><p>谬误日志：taosd “tsem_init failed, errno: 28”</p><p>Taosdump: dumpInAvroDataImpl() LN7039 taos_stmt_execute() failed! reason: Out of Memory, timestamp: 1500000009256</p><h3>定位过程</h3><h4>配置 gflags</h4><p>gflags 工具应该位于门路：C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\gflags，如果没有的话，能够间接返回 Microsoft 的官方网站下载安装：https://learn.microsoft.com/zh-cn/windows-hardware/drivers/de…</p><p>装置实现后，在命令行执行 gflags.exe /i your_application.exe 可设置跟踪目标，同时能够设置相干参数。双击运行也是能够的，Image File 对应 /i 参数，抉择启动程序 your_application.exe 后先按 tab 键，而后抉择其余配置。</p><p></p><h4>定位步骤</h4><ol><li>启动 your_application.exe（我要调试的是 taosdump.exe，所以下边是 taosdump.exe）</li></ol><p>“C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\gflags” -i taosdump.exe +ust</p><ol start=“2”><li>拷贝 pdb 文件到 mysymbols 目录，pdb 文件存储了编译后的程序的调试信息，和可执行程序一起生成，能够在应用程序生成目录中找到。</li><li><p>Set pdb 目录</p><pre><code>set _NT_SYMBOL_PATH=c:\mysymbols;srvc:\mycachehttps://msdl.microsoft.com/download/symbols</code></pre></li><li><p>生成第一次内存快照</p><pre><code>“C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\umdh” -pn:taosdump.exe -f:C:\xstest\umdhlog\taosdump11.log</code></pre></li><li><p>生成第二次内存快照</p><pre><code>“C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\umdh” -pn:taosdump.exe -f:C:\xstest\umdhlog\taosdump12.log</code></pre></li><li><p>生成快照比拟后果（umdh）</p><pre><code>“C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\umdh” C:\xstest\umdhlog\taosdump11.log C:\xstest\umdhlog\taosdump12.log -f:C:\xstest\umdhlog\taosdumpdiff11_12.log</code></pre></li></ol><h3>剖析与解决</h3><h4>后果文件</h4><p>因为 taosdump 程序启动后直至退出都在做大量的业务工作，内存泄露很容易产生在两次快照期间。 988040 – 6ecf0 示意”申请次数 – 开释次数”， 很显著产生了内存泄露，透露点在 buildRequest 函数的 sem_init 这里。</p><pre><code>+ 919350 ( 988040 - 6ecf0) 201b0 allocs BackTrace9CB6973F+ 1ea5c ( 201b0 - 1754) BackTrace9CB6973F allocations ntdll!RtlpAllocateHeapInternal+948D5 taos!heap_alloc_dbg_internal+1F6 (minkernel\crts\ucrt\src\appcrt\heap\debug_heap.cpp, 359) taos!heap_alloc_dbg+4D (minkernel\crts\ucrt\src\appcrt\heap\debug_heap.cpp, 450) taos!_calloc_dbg+6C (minkernel\crts\ucrt\src\appcrt\heap\debug_heap.cpp, 518) taos!calloc+2E (minkernel\crts\ucrt\src\appcrt\heap\calloc.cpp, 30) taos!sem_init+5D (C:\workroom\TDengine\contrib\pthread\sem_init.c, 109) taos!buildRequest+209 (C:\workroom\TDengine\source\client\src\clientImpl.c, 192) taos!stmtCreateRequest+73 (C:\workroom\TDengine\source\client\src\clientStmt.c, 15) taos!stmtSetTbName+115 (C:\workroom\TDengine\source\client\src\clientStmt.c, 588) taos!taos_stmt_set_tbname+7F (C:\workroom\TDengine\source\client\src\clientMain.c, 1350) taosdump!dumpInAvroDataImpl+E25 (C:\workroom\TDengine\tools\taos-tools\src\taosdump.c, 6260) taosdump!dumpInOneAvroFile+3D2 (C:\workroom\TDengine\tools\taos-tools\src\taosdump.c, 7229) taosdump!dumpInAvroWorkThreadFp+20B (C:\workroom\TDengine\tools\taos-tools\src\taosdump.c, 7306) taosdump!ptw32_threadStart+CD (C:\workroom\TDengine\contrib\pthread\ptw32_threadStart.c, 233) taosdump!thread_start<unsigned int (__cdecl*)(void *),1>+9C (minkernel\crts\ucrt\src\appcrt\startup\thread.cpp, 97) KERNEL32!BaseThreadInitThunk+10 ntdll!RtlUserThreadStart+2B</code></pre><h4>透露点批改</h4><p>接下来查看代码并批改，C 语言对内存的应用自由度很高，因而也比拟麻烦。能够看到有些门路脱漏了 tsem_destory 的调用。</p><p></p><p>更加具体的代码计划请见 https://github.com/taosdata/TDengine/pull/19580</p><h2>总结</h2><p>工欲善其事必先利其器，把握更多的工具和伎俩，在解决问题时能力比拟从容，Windbg 定位内存透露的形式非常简单，然而很无效。不过须要留神，它依赖 pdb 文件，因而，公布应用程序时要记得保留 pdb 文件。pdb 文件蕴含了程序的符号信息，可能帮忙咱们在调试过程中精确定位问题所在。</p><p>另外，从出问题的代码能够看出，这块内存的治理形式还是比拟容易出错，RAII 机制能较好的防止资源泄露，C 语言中也能够通过模仿 RAII 来达到相似的成果，尽管没有 C++ 那么晦涩，兴许当前能够思考优化一下。</p><blockquote>RAII（Resource Acquisition Is Initialization）机制是一种重要的资源管理形式，它将资源的获取和对象的生命周期关联起来。通过在对象的构造函数中获取资源，在析构函数中开释资源，咱们能够确保资源的正确治理，避免资源透露和内存透露等问题。RAII 机制在 C++ 等编程语言中失去广泛应用，是一种无效的资源管理形式。</blockquote></article> ...

2 月 27-29 日，2024 美国国内输配电电网及公共事业展（DISTRIBUTECH International 2024）在美国-佛罗里达州-奥兰多国家会展中心举办。作为寰球当先的年度输配电行业盛会，也是美洲地区名列前茅的业余展览会，该展会的举办周期为一年一届，参展商数量及参展品牌已达到 700 家，涵盖电力输送自动化和控制系统、能源效率、需要响应、可再生能源集成、先进计量、T&D 零碎运行和可靠性、通信技术、网络安全、水务技术等方面的信息、产品和服务。 十分荣幸的是，TDengine 团队作为 DISTRIBUTECH International 2024 参展商也受邀参加了本次会议，通过与现场参会者的激情互动和交换，TDengine 在配电和传输场景中展现了数据共享和高级剖析的弱小性能。越来越多的海内电力行业用户在这里理解并体验 TDengine，对它的性能和性能体现产生了浓厚兴趣。 事实上，TDengine 在电力场景下曾经领有十分宽泛的实际，这些企业我的项目均获得了显著的革新成果。中节能风力发电股份有限公司在中节能风电运维平台搭建中，胜利利用 TDengine 后，结果显示数据存储方面的劣势显著——整体压缩比晋升了 7-8 倍，而数据查问的响应工夫也仅需秒级。相比之下，在上海电气的“SmartOPS 储能智慧运维零碎”中，应用 InfluxDB 执行查问时须要期待十分钟以上能力失去后果，而应用雷同的 SQL 语句，在 TDengine 中只须要 0.2 秒即可实现查问；在采集点数量雷同的状况下，TDengine 压缩后的数据量仅为 InfluxDB 的 1/3。这些后果均突显出 TDengine 在输配电场景数据存储和查问方面的显著劣势。 加入 DISTRIBUTECH International 2024 为涛思数据提供了难得的机会，让咱们得以与国内电力行业专业人士开展深刻交换和互动，展现 TDengine 在输配电畛域当先的技术和弱小的产品能力。咱们置信，借助这次机会，TDengine 将进一步增强在海内市场的影响力和知名度。 最初大家一起来感触下 TDengine 展位现场的火爆气氛！

在智慧水务零碎中，通常须要对设施产生的液位、电流、水量等实时指标数据进行存储、剖析和监控，这些数据属于典型的时序数据。随着设施数量的减少，数据量可能达到了百万甚至千万级别，传统的实时数据库或关系型数据库曾经无奈满足业务需要。面对这种状况，许多企业开始意识到时序数据库的重要性。 在这一背景下，福州市城建数智科技有限公司与涛思数据达成单干。在其数据库调研阶段，TDengine 从泛滥备选计划中怀才不遇，成为搭建智慧水务物联网平台的首选计划，以解决水务监控运维零碎中海量时序数据存储的难题。将来，福州市城建数智科技有限公司将借助 TDengine 弱小的时序数据库性能，实现对液位、电流、水量等实时指标数据的高效存储、剖析和监控。TDengine 的高性能写入和查问能力，以及灵便的扩展性和可靠性，将为智慧水务物联网平台提供稳固牢靠的数据管理解决方案。 值得一提的是，TDengine 在水务行业曾经领有十分丰盛的企业实际。在禹为科技灌区信息化平台 的建设中，经验了数据库&定时工作的架构、以流式计算为外围的架构和以 TDengine 为外围的架构三个阶段，最终 TDengine 代替了 OpenTSDB+Redis+MySQL，进步了数据实时性和一致性，极大节俭了存储空间和老本。鼎蓝水务也在智慧排水系统中利用 TDengine 来解决来自拦蓄盾检测设施上报的数据，在解决 13 个设施、百万量级的数据量写入工作时，TDengine 的内存开销只有 1.5GB，查问时内存增长也很小，整体内存开销比 SQLServer 升高了 50%。 对于福州城建福州市城建数智科技有限公司为国有独资企业，是一家集征询、布局、设计、测绘、勘察、监理、检测、施工和数字科技等于一体的高新技术企业。公司以宜居环境建设（水务工程、环境工程）综合技术服务为企业外围竞争力，大力发展特色技术服务（特色修建、特色街区、特色道桥、园林景观）及工程总承包、全过程工程征询、数字水务等综合性业务，保持科技翻新倒退策略，踊跃推动业务、服务、治理等数字化转型及机制体制翻新，打造具备全过程、全方位服务能力的全国一流、福建区域龙头宜居环境建设技术服务商。 对于 TDengineTDengine 外围是一款高性能、集群开源、云原生的时序数据库（Time Series Database，TSDB），专为物联网、工业互联网、电力、IT 运维等场景设计并优化，具备极强的弹性伸缩能力。同时它还带有内建的缓存、流式计算、数据订阅等零碎性能，能大幅缩小零碎设计的复杂度，升高研发和经营老本，是一个高性能、分布式的物联网、工业大数据平台。以后 TDengine 次要提供两大版本，别离是反对私有化部署的 TDengine Enterprise 以及全托管的物联网、工业互联网云服务平台 TDengine Cloud，两者在开源时序数据库 TDengine OSS 的性能根底上有更多增强，用户可依据本身业务体量和需要进行版本抉择。

在 TDengine 3.0 中，咱们对流式计算、数据订阅性能都进行了再降级，帮忙用户极大简化了数据架构的复杂程度，升高整体运维老本。TDengine 提供的相似音讯队列产品的数据订阅、生产接口，实质上是为了帮忙利用实时获取写入 TDengine 的数据，或者以事件达到程序解决数据，与其余音讯队列相比，它提供了更大的灵活性，同时无效地升高了传输的数据量与利用的复杂度。 在本篇文章中，TDengine 研发人员具体揭秘了 TDengine 数据订阅的流程和具体实现，给到有须要的人参考。此前咱们还在《对于 TDengine 3.0 数据订阅，你须要晓得这些》一文中汇总了局部重要的语法规定，如果你正在钻研 TDengine 数据订阅性能，能够联合来看。 数据订阅的分类TDengine 反对多种订阅类型，包含子查问后果订阅、超级表订阅以及整个数据库订阅。超级表订阅和库订阅反对参数 with meta，增加此参数后，订阅的后果将蕴含数据的 meta 信息，个别用于数据同步迁徙。具体语法如下： 列订阅 CREATE TOPIC topic_name as subquery;库订阅 CREATE TOPIC topic_name as database db_name [with meta];超级表订阅 CREATE TOPIC topic_name as stable stb_name [with meta];与 Kafka 比照始终以来，TDengine 做产品的初衷就是简略易用，因而在做数据订阅性能时，API 全副对标的都是 Kafka。如果有人深入研究过 TDengine 的模型，就会发现它的架构模型和 Kafka 的很多设计都是绝对应的，Topic 和 Kafka 类似，Vnode 跟 Kafka 中的 Partition 也很靠近，子表的表名跟 Kafka 中的 Event Key 对应，因而这个架构设计人造地就带有音讯队列的特点，也正是基于此，TDengine 做数据订阅性能能力如此得心应手。 TDengine 的数据订阅性能与 Kafka 相比，基本概念都是统一的，只是具体实现形式可能有所不同，实现门路如下所示： ...

改版降级，不同以“网”！为了更好地服务客户，让大家可能更便捷、清晰地理解咱们的产品和性能，咱们决定给 TDengine 官网换个新“皮肤”~精心筹备下，新官网终于胜利与大家见面啦——https://www.taosdata.com/。TDengine 新官网都做了哪些扭转呢？一起来看看吧！ 关键词一：四大性能四大特点四大性能 四大亮点 进入官网首页，沿着大 Banner 图下滑鼠标，首先映入眼帘的就是 TDengine 的四大性能及四大特点。四大性能即数据汇聚、数据存储、数据分析及数据散发，四大特点则包含高性能、原生的程度扩大能力、大数据/小老本、60s 开箱体验，这两大板块足以让大家对 TDengine 的产品力有一个深刻的理解。如果你想要理解 TDengine 的产品信息，就从这里动手吧！ 关键词二：两大版本 TDengine 提供了 TDengine Enterprise、TDengine Cloud 两大版本，无论是集体开发者、中小企业还是大企业，都可轻松体验。其中，TDengine Enterprise 反对私有化部署，能够部署在边缘侧、本地、私有云/公有云上，在开源时序数据库（Time Series Database） TDengine OSS 的性能根底上有更多增强；TDengine Cloud 是一款全托管的物联网、工业互联网云服务平台，无需装置、部署、保护，注册即可应用，鼎力节俭人力老本。用户可依据本身业务体量和需要进行版本抉择。 关键词三：按场景划分客户案例 多年倒退间，TDengine 被越来越多的开发者和企业应用到数据架构革新我的项目中，从新创公司到行业巨头，来自各行各业的用户声音以文字的模式被记录下来，积淀到了 TDengine 的官网博客中，给到更多有须要的用户做参考。为了让大家能疾速定位所需信息，新官网的客户案例按场景进行了划分，用户可迅速匹配场景信息，优化检索门路，获取案例资源。 要害四：开发者模块上线 在新官网中，咱们还独自设置了开发者模块，模块下蕴含“技术文档”“博客”“资源”“流动”“TDengine OSS”几块内容，针对开发者须要的信息进行了打包汇总，不便大家间接进行拜访，缩小检索工夫。 新版官网页面整体视觉出现更加对立简洁，性能亮点也是高深莫测，置信肯定能给大家带来全新的应用体验。“硬装”已到位，“软装”天然也不会落下，将来咱们也将不断丰富欠缺官网内容，致力为大家提供良好的内容和服务！你还在等什么？快来体验 TDengine 的新网站吧！

6 月 26 日，涛思数据旗下时序数据库（Time Series Database） TDengine 正式公布 IoT 场景下 TDengine 3.0 性能比照剖析报告，该报告在 IoT 场景下从数据写入、压缩和查问等维度，比照了 TDengine 与市场其余风行的时序数据库产品的性能差别，其中所有测试均在标准化条件下应用公开数据实现。此外，为了不便开发者验证报告后果，该报告中的数据在筹备好物理环境后，能够由脚本一键执行生成。IoT 场景下三大数据库写入性能比照早在 2 月 21 日，TDengine 就曾经针对 DevOps 场景公布了第一期 TDengine 3.0 性能比照剖析报告，报告显示在 DevOps 场景下，TDengine 3.0 在写入、查问、存储、资源耗费等方面均优于另外两大时序数据库产品，验证了 TDengine 基于时序数据场景所设计的独特架构带来的性能劣势以及老本管制程度。 值得一提的是，上述两大报告均是基于性能基准测试平台 Time Series Benchmark Suite (TSBS) 实现的。TSBS 是由 Timescale 打造并开源，集多种利用场景下时序数据生成、数据写入、查询处理、自动化后果汇总统计等性能于一体的时序数据库性能基准测评平台。因为其开源的个性，自 2018 年以来，该平台已被寰球多家当先的时序数据库厂商应用，成为时序数据库性能测试上应用最为宽泛的平台。 据理解，本次 TDengine 公布的 IoT 场景下 TDengine 3.0 性能比照剖析报告应用 TSBS IoT 场景作为根底数据集，模仿虚构货运公司车队中一组卡车的时序数据，预设了五种卡车规模场景，在雷同的 AWS 云环境下运行了 TDengine 3.0、TimescaleDB 2.10.1 和 InfluxDB 1.8.10，从四大维度进行比照测试并输入后果。 测试报告后果可简略总结如下： 数据写入比照：在全副的五个场景中，TDengine 写入性能均优于 TimescaleDB 和 InfluxDB。写入性能最大达到 TimescaleDB 的 3.3 倍，InfluxDB 的 16.2 倍。此外，TDengine 在写入过程中耗费了起码计算（CPU）资源和磁盘 IO 开销。 ...

近年来，国家频频公布建设自主可控翻新体系的利好政策，推动我国在芯片、服务器、操作系统、软件应用等IT产业链端的逐步欠缺，企业也在减速推动“新基建”和“数字化转型”，在此背景之下，信创产业迎来高速倒退的机遇期。 从上述背景登程，北京涛思数据科技有限公司与天翼云科技有限公司于近日实现产品兼容性适配互认证。本次测试是由涛思数据旗下时序数据库 TDengine 与天翼云平台进行适配认证，结果显示，单方产品互相良好兼容，零碎性能运行稳固，产品体验良好，满足了用户性能、性能和可靠性要求。单方将在国家信创产业的背景下，为推动行业良性倒退，减速数字化转型提供平安保障。与天翼云胜利进行兼容性互认证，标记着时序数据库在信创畛域更进一步，能够实现与支流云平台协同部署、稳固运行，为单方深入策略单干奠定了技术根底，并将进一步减速国产化利用落地过程，实现互助共赢。 对于天翼云天翼云是中国电信旗下一家科技型、平台型、服务型公司，以“云网交融、平安可信、绿色低碳、生态凋谢”四大劣势向客户提供私有云、公有云、专属云、混合云、边缘云全栈云服务，满足政府机构、大中小企业数字化转型需要。作为寰球当先的云服务商，天翼云秉承央企使命，致力于成为数字经济主力军，投身科技强国伟大事业，为用户提供平安、普惠云服务。 对于 TDengineTDengine 是一款开源、高性能、云原生的时序数据库（TDengineTime Series Database ），由专一时序大数据处理的北京涛思数据科技有限公司（TAOS Data）研发并领有自主知识产权。作为一款专为物联网、工业互联网、金融、IT 运维监控等场景设计并优化的时序数据库，TDengine具备极强的弹性伸缩能力，同时还带有内建的缓存、流式计算、数据订阅等零碎性能，能大幅缩小零碎设计的复杂度，升高研发和经营老本，是一个极简的时序数据处理平台。

最近TDengine 终于将时序数据技术创新这把火烧到了美国波士顿并取得了一众国外开发者的热捧而这一次 TDengine 的胜利落地还得从两天前的一场数据大会说起...波士顿当地工夫 5 月 9 日，一场名为 ODSC East 的数据技术盛会在波士顿缓缓拉开序幕，如果你是与数据库打交道或者进行数据技术钻研的开发者，那你对这场大会应该有所耳闻。ODSC East 全称 Open Data Science Conference East，翻译过去即“凋谢数据迷信大会（美国东部）”，不仅在美国东部，作为一场全球性的技术盛会，ODSC 每年还会在美国西部、欧洲、亚洲等多地进行举办，实现翻新技术的无效流传、交融和倒退。 对于开源企业和开源爱好者来说，ODSC 肯定是一场不可多得的盛会，这场会议齐全以技术开源社区为核心，它的指标是将寰球数据迷信社区汇集在一起，独特交换翻新思维、推动开源软件的倒退。每一届 ODSC 都会汇聚泛滥人工智能和数据迷信畛域的专业人士和出名学者，在为期三天的工夫里，与会者不仅可能和这些专家进行沟通、接触到更多翻新技术，还会理解到该畛域最新的工具和框架倒退，独特摸索如何将人工智能和数据技术更好地利用在本人的我的项目和工作中。 十分荣幸，涛思数据作为 Open Data Science Conference East 的金牌赞助商也参加了本次会议，在会议现场，TDengine 的展位也吸引了泛滥开发者的关注，TDengine 创始人 & 外围研发陶建辉和现场的开发者们一起畅聊 TDengine 的泛滥翻新开源技术，探讨翻新对于开源社区倒退的重要性。 为了和更多的参会者有更深刻的交换，在 5 月 10 日早晨，TDengine 美国团队还举办了一场交换晚宴。在完结 ODSC 一天的深度学习后，参会者在晚宴轻松的气氛中放松身心，也对 TDengine 的开源社区和翻新技术建设了更为深刻的理解。 TDengine 自 2019 年开源，当初 GitHub 上曾经汇聚了 21.3k star，用户实例也达到了 247.6k，使用者遍布寰球。从回馈用户的角度登程，TDengine 技术创新的脚步从没有进行，从 1.0 到 2.0 再到 3.0，TDengine 曾经真正倒退成为一款云原生时序数据库，解决了困扰时序数据库倒退的高基数难题，反对 10 亿个设施采集数据、100 个节点，反对存储与计算拆散。与此同时，基于 TDengine 打造的全托管的时序数据处理云服务平台 TDengine Cloud 也胜利推出，正式反对 Microsoft Azure、AWS、Google Cloud、阿里云四大私有云，将来还将接轨更多的云厂商。 ...

TDengine 自诞生之日起，除产品层面的技术创新和实力晋升外，也在鼎力欠缺本身产品生态，以此进一步满足用户的业务需要、晋升应用体验。 近日，TDengine 与 Apache SeaTunnel 开展集成单干，单方将于 4 月 18 日 19:00 联结进行直播，分享两大软件集成利用的最佳实际。 （Apache Seatunnel 是一个易用、高性能、反对实时流式和离线批处理的海量数据处理产品，架构于 Apache Spark 和 Apache Flink 之上。） 此前，TDengine 曾经与 Kafka、Telegraf、Grafana、Google Data Studio、EMQ X、Prometheus、StatsD 和 collectd 等泛滥第三方工具开展集成，之后又连贯了工业英特尔® 边缘洞见软件包、数据同步工具 DataX，插件也正式上架 Grafana 官网、连接器上线 Google Data Studio 利用商店。此次 TDengine 与 Apache SeaTunnel 开展集成单干，进一步扩充了本身生态幅员，为用户带来利用上的更多抉择。 两者联结将带来怎么的惊喜，欢送大家关注 4 月 18 日行将到来的线上直播！赶快扫描下方视频号卡片预约观看直播吧~ 报名通道 讲师介绍李宏宇北京沃东天骏信息技术有限公司 架构师，历经阿里、京东等多家成熟互联网公司及罗辑思维等初创公司。十年后端及数据开发教训，目前次要聚焦在实时数据仓库畛域工作。霍立波北京涛思数据科技有限公司 连接器开发工程师，相熟 Java、GO、rust、node 等多种开发语言，对应用的各个框架与工具底层实现有深刻了解。目前次要围绕 TDengine 做生态开发。 流动议程 依照常规，直播中咱们为大家筹备了抽奖环节，中奖者可取得社区提供的精美周边礼品，来到直播间就有机会中奖~此外，填写流动反馈表也能取得抽奖机会哦：http://whaleops.mikecrm.com/1pxlyDU！ 奖品一览 社区介绍Apache SeaTunnel(Incubating)Apache SeaTunnel(Incubating) 是一个云原生的高性能海量数据集成平台。美国工夫 2021 年 12 月 9 日， SeaTunnel 以全票通过的优良体现正式成为 Apache 孵化器我的项目，这也是 Apache 基金会中第一个诞生自中国的数据集成平台我的项目。目前，SeaTunnel 在 GitHub 上 Star 数达 4.1k+，社区达到 5000+人规模。2017 年对外开源后，SeaTunnel 曾经公布了 30 多个版本，并通过大量企业生产应用，在 Bilibili、新浪、水滴筹、搜狗、趣头条、唯品会等公司的生产实践中，广泛应用于海量数据集成、数据 ETL、数据聚合以及多源数据处理等场景中，贡献者 160+。 ...

TDengine 3.0尽管对底层做了大规模的优化重构，然而绝对于数据文件的工作逻辑和 2.0 相比是整体放弃不变的。本系列文章的宗旨在于帮忙用户深刻了解产品，并且领有根本的性能调试思路，从而取得更好的产品体验。 本期文章会在解说 TDengine 时序数据库 (Time Series DataBase)的索引文件（.head 文件）工作原理的同时，介绍索引文件在最新的 TDengine 3.0.2.5 中的优化。而在下一期的文章中，会对两大版本数据文件的差别做一个总结式的阐明。如下是 TDengine 的数据文件的构造——也就是这个四位一体的文件组。 在此前的文章，次要讲述的是 .data 和 .last（3.0 中曾经更名为 .stt 文件）文件的工作原理。详情可见：https://mp.weixin.qq.com/s/OGS1WIlySSKveEOk4Reg3Q 接下来，咱们将和大家一起以产品使用者的视角持续向前摸索，揭开.head 文件的原理。 .head 类文件存储了 .data 文件中的数据块的索引信息。在.data文件中的每个数据块的 BRIN 索引信息在 .head 类文件中以表为分组，依照工夫程序递增，造成索引块组。（注：硬盘上的数据用的是 BRIN 索引，在落盘之前的内存数据用的是 skiplist 索引。）在查问的时候，会先加载这个 .head 文件中的索引信息，从而找到 .data 文件中的时序数据返回给用户。 （注：BRIN 索引指的是 Block Range Index，次要实用于有着人造程序的数据集，因为不须要再做排序，所以资源消耗少，非常符合时序数据的查问，也是 TDengine 和关系型数据库的外围区别之一。） 一个清晰可见的逻辑是——索引的作用是帮忙咱们疾速定位数据的地位，但当你操作索引的工夫变得特地长的时候，索引的价值无形之中就会变低了。所以，在 .head 文件较大的时候就可能会呈现影响查问性能的瓶颈。 而影响 .head 文件大小的因素有两个： 一是 maxrows 和 minrows 这两个参数。很好了解，同样1000行数据，maxrows=200须要 5 个数据块，maxrows为 1000，只须要 1 块。每个数据块都须要一条索引信息存储在 .head 文件中。（详情可参考：https://mp.weixin.qq.com/s/OGS1WIlySSKveEOk4Reg3Q）另一个会让 .head 文件十分大的参数是 duration （ 即 2.0 中的 days）。咱们晓得 duration 是管制单个数据文件存储数据天数的参数 ( 详情可参考：https://mp.weixin.qq.com/s/uJEQwN0NnmSTBAMOecAtoA)。所以如果 duration 很大的话，单个数据文件存储的数据量就肯定也很大，数据块就会很多。以上的实践场景是实在产生过的——之前咱们在反对某企业用户的时候，就曾遇到过生产环境上 duration 参数设置为 1000 多天导致数据查问性能重大降落的状况。然而因为 duration 参数建库后不能批改，所以最初只能导出数据，从新建库批改为正当的 duration 后再导回，这样问题才得以解决。（所以，默认值取 duration 为 10 就是一个折中的抉择，理论应用时能够依据查问类型和机器性能灵便调试。）另外一个用户则是查问时间跨度大，查问并发量大 ，导致大量的服务器资源被用于读取 .head 文件影响了查问性能。 ...

一年之计在于春，新的一年曾经启动，你打算怎么度过？ 去年还未实现的打算，还没有实现的指标，感到遗憾的事件，以及想换还没有换掉的工作......不要放弃，跟着春天的脚步，新的一年争取全副实现！ 而这个春天，咱们也有一个欲望，那就是你的退出。没错，求贤若渴的涛思数据，need U！ 咱们是谁？涛思数据 (TAOS Data) 瞄准日益增长的物联网数据市场，专一时序空间大数据的存储、查问、剖析和计算，不依赖任何开源或第三方软件，开发了领有自主知识产权、100% 自主可控的开源、高性能、云原生的时序数据库（Time Series Database）TDengine，被宽泛使用于物联网、车联网、工业互联网、IT 运维等畛域。2016 年成立至今，以不到百人的团队，涛思数据取得了来自经纬中国、红杉资本中国、GGV 纪源资本、指数资本在内的多家机构投资，总融资额靠近 7000 万美金。 旗下时序数据库 TDengine 于 2019 年 7 月开源，在 GitHub 上的 Star 数曾经达到了 20.8k，屡次登顶 GitHub 寰球趋势排行榜。寰球运行的 TDengine 用户实例数超过 200k，均匀每天新增数百个新部署，用户遍布寰球 50 多个国家/地区。 2022 年 8 月，TDengine 推出 3.0 版本，真正成为了一款云原生时序数据库，反对 10 亿个设施采集数据、100 个节点，反对存储与计算拆散，解决了困扰时序数据库倒退的高基数难题；还将存储引擎、查问引擎都进行了优化降级，并打造了全新的流式计算引擎，无需再集成 Kafka、Redis、Spark、Flink 等软件，性能晋升的同时零碎架构复杂度也实现了大幅升高。同年 9 月，TDengine Cloud 上线海内市场并同步反对 Microsoft Azure、AWS、Google Cloud 三大公有云平台，TDengine PI 连接器也在不久后胜利上线，基于此，企业既能保留传统的 PI 零碎，又能轻松取得古代云平台提供的所有益处。点击进入www.taosdata.com理解更多信息。 咱们能为你提供什么？根底福利缴纳六险一金（蕴含补充医疗保险）下午茶零食供应一直高端体检年年有餐补、交通补、工作餐、团建一个不缺生日/结婚/生养津贴统统有 增值福利健身房 Club 会员工作居住证办理高额期权机会优秀人才解决北京户口+北京市小客车指标 工程师文化设置工程师亮点贡献奖（奖金 10000 元起步）程序员整体占比 80%，扁平化治理，技术气氛浓重有对外分享技术话题、打造集体影响力的机会 广大的倒退空间与牛人为伍，GitHub 中国开发者集体奉献排行榜前 20 名里有 4 位来自 TDengine一对一 mentor 专人定向培养，帮你少走弯路与来自大厂、毕业于国内外出名学府的大佬过招，疾速晋升教训 ...

2 月 21 日，开源、高性能、云原生的时序数据平台 TDengine 正式公布 TDengine 3.0 性能比照剖析报告，该报告从数据写入、压缩和查问等维度，比照了 TDengine 与市场其余风行的时序数据库（Time Series Database，TSDB）产品的性能差别。报告旨在验证 TDengine 基于时序数据场景所设计的独特架构带来的性能劣势以及老本管制程度，其中所有测试均在标准化条件下应用公开数据实现。 TDengine 抉择的性能基准测试平台是 Time Series Benchmark Suite (TSBS)。TSBS 是由 Timescale 打造并开源，集多种利用场景下时序数据生成、数据写入、查询处理、自动化后果汇总统计等性能于一体的时序数据库性能基准测评平台。因为其开源的个性，自 2018 年以来，该平台已被寰球多家当先的时序数据库厂商应用，成为时序数据库性能测试上应用最为宽泛的平台。TDengine 新公布的性能测试报告采纳 TSBS 平台中针对 DevOps 的场景作为根底数据集，在雷同的 AWS 云环境下运行了 TDengine 3.0、TimescaleDB 2.6 和 InfluxDB 1.8，从五大维度进行比照测试并输入后果。 “降本增效始终是企业可继续倒退的重要指标，而随着业务中时序数据量级的继续大幅增长，所选数据库的性能高下会间接影响到零碎的响应工夫和经营老本。”TDengine 创始人与外围开发陶建辉示意，“随着 TDengine 3.0 TSBS 性能测试报告的公布，咱们比以往任何时候都更有信念，无论数据规模如何晋升、企业处在哪个倒退阶段，TDengine 都能以最低老本为其提供所需性能。” 该测试报告的要点包含： 数据写入比照：在全副的五个场景中，TDengine 写入性能均优于 TimescaleDB 和 InfluxDB。写入性能最大达到 TimescaleDB 的 6.7 倍，InfluxDB 的 10.6 倍。此外，TDengine 在写入过程中耗费了起码计算（CPU）资源和磁盘 IO 开销。数据查问比照：对于大多数查问类型，TDengine 的性能均优于 InfluxDB 和 TimescaleDB，在 Complex queries 类型的查问中展现出微小的劣势——TDengine 的 Complex queries 查问性能最高达到了 InfluxDB 的 37 倍、 TimescaleDB 的 28.6 倍。数据存储比照：因为高效的数据存储和压缩机制，局部场景中，存储雷同规模的数据，TDengine 占用的磁盘空间远低于 InfluxDB 和 TimescaleDB。报告显示，随着数据集规模的增长，TDengine 在数据存储方面的劣势更加显著，这也间接阐明 TDengine 更加实用于时序大数据的存储。雷同数据规模下，TimescaleDB 落盘数据规模最高达到了 TDengine 的 26.9 倍，InfluxDB 磁盘占用最高是 TDengine 的 4.5 倍。资源耗费比照：从整体 CPU 开销上来看，TDengine 不仅实现全副查问的工夫低于 TimescaleDB 和 InfluxDB，在整体上CPU计算资源的耗费也远小于 TimescaleDB 和 InfluxDB。在整个查问过程中，TDengine 内存也始终维持在一个绝对安稳的状态。无关测试报告执行后果和重现步骤的详细信息，请参阅残缺报告：https://www.taosdata.com/perf...。 ...

作者：大数据模型本篇文章出自 2022 年“用 TDengine，写 TDengine”征文投稿流动。 因为工作的关系，最近几年我接触到过各种国产数据库，唯独对 TDengine 朝思暮想。在泛滥数据库中，TiDB 一枝独秀，OceanBase 出身名门世家，openGauss 有华为撑腰，只有 TDengine 给人有一种草莽出英雄的感觉；在开发上，TiDB 借用了 rocksDB 的性能，openGauss 是基于 postgreSQL9.2.4 开发的，即便 OceanBase 也是基于外部利用需要开始打造的，只有 TDengine 不依赖任何开源或第三方软件自研而成。而且它不是一款通用型的数据库，剑走偏锋，它有本人独特的社会利用场景，次要为工业网服务。 基于对 TDengine 的定义和了解，笔者将会在本篇文章中从 TDengine 能解决什么问题、它的劣势与亮点、它与其它数据库的区别等维度开展详述，心愿能帮忙到对 TDengine 感兴趣的小伙伴。 “区别于通用数据库，TDengine 抛掉无用包袱”数据库想要实现杰出的的读写，最外围的能力就是索引，个别数据库产品都具备正向索引能力。所谓正向索引就是通过文档记录外面的标识符为关键字，通过要害标识符不再须要进行全盘扫描。尽管 B树索引、哈希索引、位图索引有区别，然而大方向都属于正向索引。 除了正向索引，还有反向索引【也称倒排索引】，反向索引次要用于全文检索，例如 ElasticSearch，大多数据库都是正向索引。TDengine 也是应用正向索引，它的特别之处是标识符必定蕴含工夫戳，再加上一个维度指标数据，形成一个对数据值明确的形容——某个工夫某个指标对象的数据值是多少。 从数据组织的存储引擎来看，数据库底层能够分为 B树机制、LSM 机制，两种机制没有最好，各有各的长处和毛病：B树最大益处在于它对数据继续低落读性能的解决，即便数据量级增大，它的读也没有放大。 神秘在于对数据进行终极长久存储时，B树是以有序有法则的数据结构保留在硬盘上的。这样随着数据越来越大，它仍然放弃有序有法则的个性，面对成千上万的读操作，都能够遵循条件运行，缩小或防止读放大的行为。 与 B树机制截然相同，LSM 机制则是缩小防止了写放大。LSM 机制充分利用了内存，在内存外面开拓了一个空间，写数据优先往内存里放，写进去间接返回用户胜利，而不是像 B树那样写一个，我要找出谁比我大谁比我小，只有内存有够，就间接往内存外面填就好，当内存达到肯定的阈值，将内存中的数据以批量、程序的形式一次写入硬盘上，内存则重置清零再服务新的写要求。 传统数据库 MySQL、Oracle 应用的是 B树机制，而 TiDB、OceanBae 应用的是优化后的 LSM 机制，而 TDengine 应用的是 B树 + LSM 机制的形式，其中 B树存储的是元数据【次要是工夫戳+指标数据】，LSM 机制存储的是具体的数据，元数据以有序表构造形式进行存储，而具体数据则是以追加的形式写入，这样即防止了读话大和写放大。 一般来说，OLTP 产品为了晋升并发管制的性能，必定会有写时复制或者 MVCC 的性能选项，写时复制与 MVCC 尽管保障了数据的一致性，然而带来更多的 IO 累赘。TDengine 不须要对数据进行批改，所以不须要思考数据一致性的问题，数据是以有序的法则并追加的模式写进去的，因为只有读和写，所以也不须要锁爱护，抛掉一些无用的包袱，能够集中优化其它中央，例如列式表。 ...

在钢铁行业的生产、运输、治理等环节中，都会波及大量时序数据的存储剖析、运维监控等操作，每日产生的数据量甚至高达亿级，而传统的工业实时库与关系型数据库，都难以应答这种数量级的数据处理需要，想要保障业务倒退，则亟需更为业余的时序数据库（Time Series Database，TSDB）。本篇文章汇总了三大钢铁行业数据治理场景下的数据架构降级计划，供有相干业务需要的开发者参考。 中天钢铁 x TDengine“目前 TDengine 在咱们的生产环境中运行安稳，通过对生产环境的机器进行检测，CPU 使用率平时不到 1%，内存使用率稳固在 25%。在 TDengine 安稳运行的数周工夫里，中天钢铁的新零碎均匀每周收录 3000 多辆车辆表与 100 多条船只表，每张表中数据或多或少，累计数量已达百万，业务的实际效果也达到了预期。”业务背景为了满足业务倒退需要，中天钢铁须要新开发一套性能，对厂内每辆运输车辆货运船只的实时 GPS 地位进行追踪和实时监控，通过大数据平台对 GPS 坐标进行解决、剖析、可视化展现。这些 GPS 数据来自于中天云商 App，只有运输车辆司机关上云商 App，零碎每隔 10 秒会主动发送该车辆 GPS 信号到大数据平台，再由大数据平台剖析解决，数据量之大可见一斑。实质上来讲，行车记录、行船记录都是时序数据，也因而，从数据特点登程中天钢铁开始对时序数据库进行选型调研，在进行性能比照后抉择了 TDengine。 架构图 点击案例查看更多技术细节 钢铁行业能源管理系统 x TDengine“TDengine 是涛思数据面对高速增长的物联网大数据市场和技术挑战推出的创新性的大数据处理产品，在时序空间大数据处理上，有着本人独到的劣势。TDengine 单核每秒能解决至多 2 万次申请，插入数百万个数据点，读出一千万以上数据点，比现有通用数据库快十倍以上，也远远超出了 InSQL、PI 这两个工业实时数据库的读写能力。”业务背景湖北某特钢公司的电力能源介质的计量，是通过 TBox 工控网关采集多功能电表来实现的，须要欠缺并实现“峰谷平尖”电能量费率计量和能源报表。我的项目一期首先要求采集电能量数据，每天产生的数据量在 2800 万条以上，我的项目二期如果再接入非电数据，每天产生的数据量预估在 1 亿条左右，数据处理压力剧增。TBox 工控网关基于后期我的项目施行和理论利用需要提供了残缺的技术计划，蕴含从电表采集电能数据并写入 TDengine 时序数据库，再通过 ETL 工具解决后转存到 Oracle database，从而满足企业一期电能量数据报表对实时数据采集和存储的要求。 架构图 点击案例查看更多技术细节 钢铁行业节水减排我的项目 x TDengine“TDengine 存储 26 亿行数据状况下，占用的磁盘空间只有 2.8GB，而实际上入库的原数据大小应为 30GB，其列式存储压缩率能够达到惊人的 10%，咱们筹备了 1.8TB 磁盘，目前只用了千分之一。基于超级表个性，咱们还从构造上省下了 26 亿行的标签数据，设想一下如果该表的每一行数据都还要带上这几个数据（type，sendorid，opcid，共计 436 字节），那其本来数据量间接就会达到 TB 级别，就算压缩率再好也要占用百 GB 级别的存储。”业务背景由邯钢牵头的“十三五”水专项“钢铁行业水污染全过程控制技术系统集成与综合利用示范”课题中，深度（平潭）科技承当了“进步水循环利用的分质/分级供水技术、水系统优化和水网络智慧治理”的钻研工作，翻新开发了具备自主知识产权的“钢铁联结企业全过程节水减排专家管理系统智慧平台”。 ...

随着一系列利好政策的公布，国产数据库行业正在产生天翻地覆的变动，投融资此起彼伏，国产化代替过程减速，国产数据库行业倒退热火朝天。在此背景下，墨天轮颁布了《2022 年度数据库获奖名单》，通过对墨天轮排行榜排名及年度得分、生态建设、市场流动、市场份额、专利数等 38 个综合指标进行评估遴选，2022 年度数据库产业的重要奖项浮出水面。其中，涛思数据旗下时序数据库（Time Series Database） TDengine 荣获“2022 年度时序数据库”奖项。 据理解，墨天轮于 2019 年 6 月推出了中国数据库风行度排行，会于每月 1 日更新排名，同时公布上月的大事记以及排行榜解读文章。截至目前，参加排名的数据库数量曾经从 50 个减少到 256 个，排行榜的重磅水平显著晋升。近日，墨天轮依据墨天轮数据库风行度排行体现以及其余指标，综合得出了 2022 年度中国数据库墨力象限，其中，TDengine 呈现在“特定畛域者”象限，在时序数据垂直场景下已成为佼佼者。 回顾 2022 年，开源方面，TDengine 在 GitHub 上的 Star 数胜利冲破至 20.4k ，并再次登上 GitHub 寰球趋势榜第一名。市场拓展方面，其付费企业客户翻了一番。产品翻新上，2022 年 8 月 TDengine 3.0 公布，TDengine 正式降级成为了一款真正的云原生时序数据库，并打造了全新的流式计算引擎；同时，TDengine Cloud 也胜利登陆了海内市场，TDengine PI 连接器也在不久后胜利上线。由此可见，正是凭借着开源、市场、产品的“三面开花”，TDengine 在 2022 年度墨天轮排行榜上仍旧榜上有名。 目前，TDengine 已间断两年霸榜墨天轮时序数据库排行榜，势头不减，位列中国时序数据库排行榜 2022 年全年复合增长率第一。接下来，TDengine 还将持续施展潜能，深耕数据技术，助力企业实现全面数字化转型倒退。 想理解更多 TDengine Database的具体细节，欢送大家在GitHub上查看相干源代码。

TDengine 3.0 尽管对底层做了大规模的优化重构，然而绝对于数据文件的工作逻辑和 2.0 相比是整体放弃不变的。本系列文章的宗旨在于帮忙用户深刻了解产品，并且领有根本的性能调试思路，从而取得更好的产品体验。援用本期文章会在解说 TDengine 时序数据库 (Time Series DataBase)的索引文件（.head 文件）工作原理的同时，介绍索引文件在最新的 TDengine 3.0.2.5 中的优化。而在下一期的文章中，会对两大版本数据文件的差别做一个总结式的阐明。如下是 TDengine 的数据文件的构造——也就是这个四位一体的文件组。 在此前的文章，次要讲述的是 .data 和 .last（3.0 中曾经更名为 .stt 文件）文件的工作原理。详情可见：https://mp.weixin.qq.com/s/OG... 接下来，咱们将和大家一起以产品使用者的视角持续向前摸索，揭开.head 文件的原理。 .head 类文件存储了 .data 文件中的数据块的索引信息。在.data文件中的每个数据块的 BRIN 索引信息在 .head 类文件中以表为分组，依照工夫程序递增，造成索引块组。（注：硬盘上的数据用的是 BRIN 索引，在落盘之前的内存数据用的是 skiplist 索引。）在查问的时候，会先加载这个 .head 文件中的索引信息，从而找到 .data 文件中的时序数据返回给用户。 （注：BRIN 索引指的是 Block Range Index，次要实用于有着人造程序的数据集，因为不须要再做排序，所以资源消耗少，非常符合时序数据的查问，也是 TDengine 和关系型数据库的外围区别之一。） 一个清晰可见的逻辑是——索引的作用是帮忙咱们疾速定位数据的地位，但当你操作索引的工夫变得特地长的时候，索引的价值无形之中就会变低了。所以，在 .head 文件较大的时候就可能会呈现影响查问性能的瓶颈。 而影响 .head 文件大小的因素有两个： 一是 maxrows 和 minrows 这两个参数。很好了解，同样1000行数据，maxrows=200须要 5 个数据块，maxrows为 1000，只须要 1 块。每个数据块都须要一条索引信息存储在 .head 文件中。（详情可参考：https://mp.weixin.qq.com/s/OG...）另一个会让 .head 文件十分大的参数是 duration （ 即 2.0 中的 days）。咱们晓得 duration 是管制单个数据文件存储数据天数的参数 ( 详情可参考：https://mp.weixin.qq.com/s/uJ...)。所以如果 duration 很大的话，单个数据文件存储的数据量就肯定也很大，数据块就会很多。以上的实践场景是实在产生过的——之前咱们在反对某企业用户的时候，就曾遇到过生产环境上 duration 参数设置为 1000 多天导致数据查问性能重大降落的状况。然而因为 duration 参数建库后不能批改，所以最初只能导出数据，从新建库批改为正当的 duration 后再导回，这样问题才得以解决。（所以，默认值取 duration 为 10 就是一个折中的抉择，理论应用时能够依据查问类型和机器性能灵便调试。）另外一个用户则是查问时间跨度大，查问并发量大 ，导致大量的服务器资源被用于读取 .head 文件影响了查问性能。 ...

在工业畛域， 生产、测试、运行阶段都可能会产生大量带有工夫戳的传感器数据，这都属于典型的时序数据。时序数据次要由各类型实时监测、查看与剖析设施所采集或产生，波及制作、电力、化工、工程作业等多个行业，具备写多读少、量十分大等典型个性。如 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 搭建了新的数据处理架构。 ...

煤矿行业具备产业规模大、散布地区广、安全性要求低等特点，而大部分煤矿零碎都是独立运行的，为了实现各个系统数据的无效利用和深度交融，以此达成预警、数据分析等目标，煤矿行业亟需智能化赋能。在拥抱工业物联网、人工智能、大数据等新技术的同时，其智能化倒退路线也面临着泛滥挑战： 一是，设施治理层面的挑战，随着自动化水平越来越高，设施复杂度和治理难度也逐渐增大，如何保障设施安全可靠的运行，晋升设施的利用率，促成设施保值增值也成了挑战之一；二是，平安生产的挑战，平安是基本，如何通过数字化伎俩，将人和物的不平安因素对立治理好，晋升整体煤矿企业平安生产程度至关重要。从以上挑战登程，一些煤矿企业曾经开始进行数据架构转型实际，也获得了一些停顿，值得一提的是，时序数据库（Time Series Database）在其中施展了重要作用。本文将这些案例进行了相干汇总，供读者参考。 TDengine x 智慧矿山零碎“咱们以智慧矿山业务中的 5000 设施、每天 1000 万采集点的数据量级下，在以车建模和以地位建模联合的数据模型下，TDengine 的性能远没有达到极限，目前零碎对于车和地位的查问速度都在毫秒级。基于目前对 TDengine 的了解和应用教训，咱们打算在环保监测和生产集控设施场景中进一步应用它来欠缺零碎。”业务背景元智信息的智慧矿山我的项目须要一款数据库来撑持起生产交互管控零碎的采运排环节所有过程设施的采集、存储、计算和监控性能。这些数据涵盖范围广，包含挖机、卡车的采集数据、调度治理数据、设施 GPS 信息、以及每一个固定地位工序的采集数据等。在 MySQL、InfluxDB、TDengine 的数据库选型调研中，TDengine 怀才不遇（点击下方案例查看具体起因）。 架构图 点击【案例】查看更多技术细节 TDengine x 陕煤矿山我的项目“最终落地时我的项目采纳了 3 个节点的集群环境，定位设施采纳超级表进行治理，将数据标签及数据类型作为 tag 辨别各类定位设施。每个定位设施采纳子表存储，理论我的项目已蕴含 2 万多个定位设施。从写入性能到查问性能均大幅满足现场理论需要：总计定位数据量超过 11 亿条，数据压缩后 TDengine 数据目录占用磁盘大概 12GB，整体压缩率能够达到 3/100。”业务背景为买通煤矿生产环境中各类繁多子系统之间的数据壁垒，实现各类子系统数据之间的互联互通，陕煤开发团队打造了全矿井数字化平台。以地位数据为例，因为初期零碎容量较小且硬件设施上传周期较大，所以采纳了传统的 SQL Server 数据库来进行轨迹数据存储。随着后续我的项目迭代，硬件设施定位精度进步且上报周期缩短，也导致数据库存储压力增大。思考到数据类型及特点，其决定应用时序数据库，在 OpenTSDB、TDengine、InfluxDB 三款数据库中做选型调研。 架构图 点击【案例】查看更多技术细节 TDengine x 华夏天信露天煤矿“对于每个电机，客户要求零碎可能疾速读取相干设施属性趋势图，这是咱们发现 TDengine 最弱小的中央：针对一天 2 万条数据展现速度在 200ms 内。之所以 TDengine 对这类查问速度飞快，次要是设计时依照设施分表后，数据按块存储并按块查出来，绝对 Key-Value 型数据库节俭很多寻址工夫。”业务背景华夏天信 RED-MOS 露天煤矿智慧矿山操作系统，在对接某高空生产集控系统数据时，接入的监控点数量将近 1 万 5 千点，其中靠近 2300 点须要绑定组态显示，即时页面更新，整体数据采集到显示到前端要求秒级展现及大数据量展现（历史数据回溯），可展现 30 天的全量数据，点数量超过 50 万条，读取工夫要求在 5~10 s，这对底层的数据库提出了一个相当大的挑战。 ...

近日，凭借着 2022 年的技术创新和凋谢开源优良问题，时序数据库 TDengine 又荣登了来自两大出名技术社区掘金及 InfoQ 的重磅榜单。 聚焦数字化转型新时代、新机遇，稀土掘金技术社区首次打造了「2022 稀土掘金引力榜」，该榜单从人物、企业、产品/案例三大维度设置 5 类奖项，蕴含年度新锐人物 Top10、年度新锐企业 Top10、年度翻新产品 Top10、年度最佳实际案例 Top10、年度技术品牌流传案例 Top10。其中，TDengine 从泛滥产品中突围而出，跻身 2022 稀土掘金引力榜 · 年度翻新产品 Top10。 同样，通过间断数月的企业实地走访、行业调研以及专家访谈交换，以“深刻数字经济·洞见技术价值”为主题的「InfoQ 2022 中国技术力量年初榜单」也于近日颁布了获奖名单，该评选活动设计了十大开源新锐我的项目、十大卓越技术团队、十大云原生翻新技术计划、数智化科技翻新 TOP20、数智化生产翻新 TOP15 以及数智化企业服务翻新 TOP15 六大榜单，TDengine 在十大开源新锐我的项目榜单中怀才不遇、名列其中。 秉持着技术创新和凋谢开源的初心，2022 年 TDengine 在 GitHub 上的 Star 数胜利冲破至 20.3k，并再次登上 GitHub 寰球趋势榜第一名。尽管开源仅仅才倒退了三年工夫，但 TDengine 已成长为时序数据库（Time Series Database）畛域 Star 数排名第三的新星我的项目，并在全副开源数据库产品中，位居第六；同时，放弃着在开源时序数据库畛域中最快的 PR 增长速度。 在产品翻新上，2022 年 TDengine 不仅正式公布了 3.0 版本，TDengine Cloud 也正式上线了海内市场，还公布了 TDengine PI 连接器，助力企业疾速将传统零碎中的数据迁徙到古代技术栈中。其中，TDengine 3.0 成为了一款真正的云原生时序数据库，解决了困扰时序数据库倒退的高基数难题，反对 10 亿个设施采集数据、100 个节点，反对存储与计算拆散，并降级了全新的流式计算引擎，在打造极简的时序数据处理平台上更进一步。 借助开源和翻新的力量，TDengine 用户曾经遍布寰球，装置实例数超过了 192k，被宽泛使用于物联网、车联网、工业互联网、IT 运维等畛域，倒退了包含西门子、美的、京东云、蔚来汽车、现实汽车、零跑汽车、同花顺、顺丰科技、逾越速运在内的多行业企业客户。在 2023 年，TDengine 将会帮忙更多有数字化转型需要的企业解决数据难题，独特解析数字化新时代的数据时机和挑战。 ...

小 T 导读：TDengine 是专为时序数据而研发的大数据平台，存储和计算都针对时序数据的特点量身定制，在反对规范 SQL 的根底之上，还提供了一系列贴合时序业务场景的特色查问语法，极大中央便了时序场景的利用开发。TDengine 提供的特色查问包含数据切分查问和窗口切分查问，本文将从语法层面深刻解读这两种特色查问。数据切分查问依据业务须要，有时咱们须要按肯定的维度对数据进行切分，当在切分出的数据空间内进行一系列的计算时，就须要应用数据切分子句，语法如下：PARTITION BY part_list在上述语法中，part_list 能够是任意的标量表达式，包含列、常量、标量函数和它们的组合。时序数据库（Time Series Database）TDengine 按如下形式解决数据切分子句： 数据切分子句位于 WHERE 子句之后；数据切分子句将表数据按指定的维度进行切分，每个切分的分片进行指定的计算。计算由之后的子句定义（窗口子句、GROUP BY 子句或 SELECT 子句）；数据切分子句能够和窗口切分子句（或 GROUP BY 子句）一起应用，此时前面的子句作用在每个切分的分片上。例如，将数据按标签 location 进行分组，并对每个组按 10 分钟进行降采样，取其最大值。select max(current) from meters partition by location interval(10m)数据切分子句最常见的用法就是在超级表查问中，按标签将子表数据进行切分，而后别离进行计算。特地是 PARTITION BY TBNAME 用法，它将每个子表的数据独立进去，造成一条条独立的工夫序列，极大中央便了各种时序场景的统计分析。 窗口切分查问TDengine 反对按时间段窗口切分形式进行聚合后果查问，比方温度传感器每秒采集一次数据，但需查问每隔 10 分钟的温度平均值，这种场景下能够应用窗口子句来取得须要的查问后果。想要让查问的数据汇合依照窗口切分成查问子集并进行聚合，就须要用到窗口子句，窗口蕴含工夫窗口（time window）、状态窗口（status window）、会话窗口（session window）三种窗口。其中工夫窗口又可划分为滑动工夫窗口和翻转工夫窗口。窗口切分查问语法如下： SELECT select_list FROM tb_name [WHERE where_condition] [SESSION(ts_col, tol_val)] [STATE_WINDOW(col)] [INTERVAL(interval [, offset]) [SLIDING sliding]] [FILL({NONE | VALUE | PREV | NULL | LINEAR | NEXT})]窗口子句的规定窗口子句位于数据切分子句之后，GROUP BY 子句之前，且不能够和 GROUP BY 子句一起应用；窗口子句将数据按窗口进行切分，对每个窗口进行 SELECT 列表中表达式的计算，SELECT 列表中的表达式只能蕴含： ...

在数字技术蓬勃发展的当下，产业数字化转型也在热火朝天地进行，在此过程中，数据层面的开掘和剖析起到了至关重要的作用，数据技术的翻新倒退和无效使用成为要害。近日，由 ITPUB、IT168 联结打造的《技术扭转世界 翻新引领将来——2022 技术卓越奖》，评比后果正式揭晓，凭借当先的技术劣势、独到的用户服务教训、开源凋谢的生态理念，涛思数据旗下产品云原生时序数据库（Time Series Database） TDengine 3.0 胜利入选。 IT168“技术卓越奖”评选活动自 2004 年启动至今曾经领有 10 多年的历史了，其在一年完结时对本年度的 IT 技术与产品进行集中盘点、总结与评比，通过层层筛选，最终评比出“技术卓越奖”、“产品创新奖”、“年度产品奖”等一系列奖项获得者，奖项含金量和重磅水平可见一斑。 作为国产数据库的实践者与引领者，涛思数据专一时序空间大数据的存储、查问、剖析和计算，通过技术创新，为物联网、工业互联网、汽车、能源等行业提供全栈、高性能、低成本的大数据平台。不依赖任何开源或第三方软件，涛思数据开发了领有自主知识产权、100% 自主可控的时序数据库 TDengine。在 2022 年 8 月份，TDengine 曾经演进到 3.0 版本，成为了一款真正的高性能、云原生的时序数据库。 在云原生的加持下，TDengine 3.0 解决了困扰时序数据库倒退的高基数难题，反对 10 亿个设施采集数据、100 个节点，反对存储与计算拆散，并打造了全新的流式计算引擎，无需再集成 Kafka、Redis、Spark、Flink 等软件，大幅升高零碎架构的复杂度，真正成为了一款极简的时序数据处理平台。同时，TDengine 3.0 还将存储引擎、查问引擎都进行了优化降级，存储和查问性能取得进一步晋升。 目前，曾经在电力、工业、能源、金融、车联网、智慧城市等诸多行业畛域获得利用，产品落地于多个行业头部企业中，寰球运行的 TDengine 实例数超过 189.4k，用户遍布寰球。早在 2019 年，TDengine 就曾经实现了代码开源，目前在 GitHub 上的 Star 数曾经达到了 20.4k，数次登顶 GitHub 寰球趋势榜，吸引着宽广开发者的关注。 面向未来，涛思数据将持续深耕数据技术的翻新与倒退，继续迭代产品和服务，深刻到不同的场景中，助力更多企业减速数据基础设施的更新和欠缺，实现数据对业务价值的更深层次驱动。 想理解更多 TDengine Database的具体细节，欢送大家在GitHub上查看相干源代码。

中国空间技术研究院（航天五院）隶属于中国航天科技集团有限公司，成立于 1968 年 2 月 20 日，首任院长是驰名科学家钱学森。通过 50 余年的倒退，已成为中国次要的空间技术及其产品研制基地，是中国空间事业最具实力的骨干力量。 自 1970 年 4 月 24 日胜利发射我国第一颗人造地球卫星以来，研究院已抓总研制并胜利发射了 390 余颗航天器，实现 240 余颗航天器在轨运行，研制的航天器笼罩载人航天、月球与深空探测、导航定位、对地观测、通信播送、空间科学与技术试验六大系列航天器，实现了大、中、小、微型航天器的系列化、平台化发展。研究院圆满完成载人航天工程、探月工程、北斗工程、高分工程为代表的重大航天工作，为我国航天三大里程碑的逾越倒退做出了突出贡献。 近年来，航天科技行业鼎力推动近程测试等信息化伎俩的利用，从而精简试验队规模、进步工作效率、降低成本，以适应高密度发射和商业化倒退要求。在此场景下，研究院打造了面向航天器的数据处理系统，应用时序数据库（Time Series Database）用于遥测数据的存储和剖析，具备高并发、写多读少的数据处理特点，而这恰好是国产时序数据库 TDengine 善于解决的典型场景。 在该零碎的时序数据库选型调研中，TDengine 以极其弱小的读写性能和数据压缩能力、多平台的易适配能力，聚合查问速度怀才不遇，极大升高了客户运维老本和业务压力，进步了工作效率。将来，TDengine 也将持续在航天畛域施展更多能力，与研究院一起独特助力。 想理解更多 TDengine Database的具体细节，欢送大家在GitHub上查看相干源代码。

中冶京诚工程技术有限公司（简称：中冶京诚）是我国最早从事冶金工程征询、设计、工程承包业务的国家级大型科技型企业，是由冶金工业部北京钢铁设计钻研总院改制成立的国际化工程技术公司，现隶属于中国冶金科工团体有限公司，是世界五百强中国五矿团体有限公司的外围骨干子企业。 作为国内外客户认可的知名品牌企业，近 70 年来，先后为国内外 500 余家客户提供了近 6500 项工程技术服务，参加实现了宝钢、鞍钢、武钢、太钢、首钢京唐、河钢等国内钢铁企业的新建和改扩建工程，海内工程业务拓展 27 个国家，是我国钢铁工业建设的次要力量和工程技术输入的重要参与者。在历年国家住建部、勘察设计协会等年度排名中，均位居行业前列。 其中中冶京诚高速棒线材智能化团队凭借 70 多年棒线材轧制工程技术底蕴和教训积攒，继续打造技术当先的根底自动化零碎，联合机器视觉、数据分析、人工智能等先进技术，打造欠缺对立的智能化数据中心，胜利构建了新一代高速棒线材车间智能化整体解决方案。中冶京诚打算将所有生产线数据汇总接入到过程数据中心，通过数据中心突破车间数据孤岛，实现生产过程数据、工厂设计数据、视频音频图像数据、生产治理数据等车间数据的深度交融。 而过往应用的 InfluxDB 在性能上稍显有余，且不合乎国产化独立自主的趋势，中冶京诚心愿找到其余替换的国产时序数据库解决方案。与 InfluxDB 相比，国产时序数据库（Time Series Database，TSDB） TDengine 搭建集群的老本更低廉、查问更具备劣势，存储性能和稳定性体现也更加突出。在这些劣势的加持下，中冶京诚抉择与 TDengine 开展单干，独特实现钢铁工业智慧化，并在钢铁智能车间多个我的项目中实现了车间数据的深度交融利用。 想理解更多 TDengine Database的具体细节，欢送大家在GitHub上查看相干源代码。

随着新兴技术的疾速倒退，越来越多的企业开始以技术的交融翻新来推动业务的数字化智能化转型，其中也诞生了很多胜利的利用实际案例。2023 年 1 月 9 日，北京涛思数据科技有限公司(TAOS Data) 正式颁布「2022 年度中国时序数据利用创新奖」获奖名单，共评比出包含中天钢铁、大疆车联网、OPPO、西门子、玉溪卷烟厂、美的团体、中通科技、顺丰速运、国轩高科、金航数码、正大天晴在内的 33 个获奖利用，波及到了物联网、工业互联网、金融、IT 运维等多个利用场景。 「2022 年度中国时序数据利用创新奖」颁布（排名不分先后） 据理解，「2022 年度中国时序数据利用创新奖」以各参评企业的数据架构革新落地案例作为评比资料，从革新我的项目的力度和成果及其对行业倒退的影响力等维度作为评比规范，通过严格筛选，最终 33 个翻新利用怀才不遇。围绕行业影响、业务效益、翻新引领、技术利用四大维度，本年度获奖企业涵盖工业互联网、车联网、物流、金融、制药、智慧能源、智慧工厂等泛滥畛域的行业头部企业。作为企业数字化实际的先行者，他们联结时序数据库（Time Series Database）TDengine 独特解决数据难题，在要害产业场景进行联结摸索翻新，通过交融翻新的数据技术赋予了业务更高的利用价值。 本次评选活动的意义不仅在于打造一个翻新利用胜利展现和转化的重要平台，更是以这些行业标杆的胜利利用，推动以技术创新驱动企业数字化转型的倒退之路，让更多的行业企业可能借鉴到获奖利用的转型经验和丰盛教训。 作为本次评选活动的主办方，涛思数据瞄准日益增长的物联网数据市场，专一时序空间大数据的存储、查问、剖析和计算，目前其曾经取得经纬中国、红杉资本中国、GGV 纪源资本、指数资本等多家机构的投资。不依赖任何开源或第三方软件，涛思数据开发了领有自主知识产权、自主可控的开源、高性能、云原生的极简时序数据处理平台 TDengine。 目前 TDengine 曾经演进到 3.0 版本，解决了困扰时序数据库倒退的高基数难题，反对 10 亿个设施采集数据、100 个节点，反对存储与计算拆散，优化降级了存储引擎、查问引擎，并打造了全新的流式计算引擎，无需再集成 Kafka、Redis、Spark、Flink 等软件，大幅升高零碎架构的复杂度，真正成为了一款极简的时序数据处理平台。TDengine 在 GitHub 上的 Star 数曾经达到了 20.4k，寰球运行的 TDengine 实例数超过 187.5k，用户遍布寰球。 “在过来一年里，TDengine 与中天钢铁、大疆车联网、OPPO、西门子、玉溪卷烟厂、美的等一众行业头部企业达成单干，单方联合各自的技术劣势进行联结翻新，让物联网、时序大数据的解决变得更加简略高效，独特推动着钢铁、车联网、智慧工业等泛滥行业的数字化倒退。”TDengine 创始人&外围开发陶建辉示意， “这些头部企业在各自业务场景下的数据架构胜利革新案例也成为推动着 TDengine 一直精进的不竭能源，明天咱们以评比的形式将它们公布出来，也心愿能帮忙到更多有数字化转型需要的企业胜利借鉴复制到这些教训。” 点击进入www.taosdata.com 查看获奖利用的具体解决方案。 想理解更多 TDengine Database的具体细节，欢送大家在GitHub上查看相干源代码。

时序数据库(Time Series Database)是用于存储和治理工夫序列数据的专业化数据库，具备写多读少、冷热明显、高并发写入、无事务要求、海量数据继续写入等特点，能够基于工夫区间聚合剖析和高效检索，广泛应用在物联网、经济金融、环境监控、工业制作、农业生产、硬件和软件系统监控等场景。 随着技术的一直倒退，时序数据库这个赛道里最近几年呈现了很多的佼佼者，明天就来将这些时序数据库从性能到利用一起梳理比照下。 1 TDengine vs InfluxDB 性能PK性能是用户在抉择和应用时序数据库时十分关注的一个点。 1.1 数据库介绍InfluxDB是一个用Go语言编写的开源时序数据库。其外围是一个自定义构建的存储引擎，它针对时序数据进行了优化，是目前最为风行的时序数据库之一。 TDengine是一款集成了音讯队列，数据库，流式计算等性能的物联网大数据平台。该产品不依赖任何开源或第三方软件，领有齐全自主知识产权，具备高性能、高牢靠、可伸缩、零治理、简略易学等技术特点。TDengine是以后时序数据库畛域中一匹势头正劲的黑马，在国产时序数据库中算是No.1了。 “一言不合上数据”，接下来，咱们正式进入测试环节。 1.2 环境筹备为了不便大家复现，咱们所有的测试都是运行在Ubuntu 20.10的两台azure虚拟机上进行的，配置如下： 1.3 测试方法与步骤通过一系列装置软件及代码筹备工作之后，咱们开始进行脚本测试数据工作：批改脚本：须要将timeseriesdatabase-comparisons/build/tsdbcompare/write_to_server.sh，把add='tdvs'，批改为你选用的数据库服务端hostname。运行脚本测试： timeseriesdatabasecomparisons/build/tsdbcompare/loop_scale_to_server.sh留神：如果遇到烦扰因素导致写入失败，能够手动传入参数再次执行失去测试后果。 1.4 理论测量数据 通过一番测试后，咱们制作了这样一张表格。通过它咱们能够分明地看到：不论是单线程还是多线程，不论是小批次还是大批次，TDengine都始终稳稳放弃着2倍左右的速度劣势。其中5000batch，16wokers的场景下（InfluxDB与Graphite的比照报告中的测试项），InfluxDB耗时35.04秒，而TDengine耗时仅17.92秒。 1.5 PK论断以后的测试后果比拟无力地阐明了两点论断： 在InfluxDB公布的本人最优的条件下，TDengine的写入速度是它的两倍。当设施数放大到1000的时候，TDengine的写入速度是InfluxDB的5倍左右。咱们应用该测试条件（5000batch size，16workers）作出两张以设施台数为横轴的折线图，因为这将极具代表性。 这两张图充分说明了一点：设施数越多，数据量越大，TDengine的劣势就越显著。 而思考到本次性能测试比照的接口类型并不统一，TDengine采纳的是cgo接口而InfluxDB为rest，性能上会有大量浮动，绝不会从根本上扭转后果。 2、TDengine vs Prometheus 架构设计PK通过比照能加深对这两个零碎的了解，不便后续架构选型时作出正确决定。他们的设计思路有很多值得借鉴的中央，尽管目前工作中须要用到这些设计思路的中央不多，然而理解他们的设计能极大满足我的好奇心。 2.1 架构、实现计划不同之处Prometheus 架构设计 通过prometheus的架构图能够看出，prometheus提供了本地存储，即tsdb时序数据库。本地存储的劣势就是运维简略，毛病就是无奈海量的metrics长久化和数据存在失落的危险，咱们在理论应用过程中，呈现过几次wal文件损坏，无奈再写入的问题。当然prometheus2.0当前压缩数据能力失去了很大的晋升。为了解决单节点存储的限度，prometheus没有本人实现集群存储，而是提供了近程读写的接口，让用户本人抉择适合的时序数据库来实现prometheus的扩展性。 TDengine 分布式系统架构设计 如上图所示，在数据节点（Dnode）、虚构节点（Vnode）、治理节点（Mnode）之上，TDengine 3.0 集群新增了弹性计算节点（Qnode）和流计算节点（Snode）。其中 Qnode 次要在运行查问计算工作中起作用，当一个查问执行时，依赖执行打算，调度器会安顿一个或多个 Qnode；Snode 次要负责运行流计算工作，能够同时执行多个。 2.2 利用差别点面向场景不同• Prometheus Prometheus 专一于运维须要的指标数据，特点是存储的就是一个数值，数据附带了很多维度信息，作为标签。 # 如：cpu_total_seconds：{timestamp=2020-09-05-21-27, host="192.168.1.10", type="idle"}=3551341；Prometheus专一于单机性能，用于存储最近一段时间数据，没有长期长久化的思考，弱化分布式集群性能，由其余组件（如Thanos）来实现高可用。 • TDengine TDengine 用于存储工业中某类传感器设施采集的指标，所以数据类型多样，如浮点，字符串等。TDengine 面向工业物联网时序场景，数据具备量大、写操作为主读操作为辅、更新删除操作较少等特点，TDengine从这些数据特点登程设计了存储、查问、写入的性能特色，为了缩小零碎架构的繁杂，TDengine 还自带了数据订阅、流式计算等性能。TDengine 心愿通过分布式集群来提供可扩展性、高牢靠和高性能，防止单点故障，免费版就是提供集群能力，有长久化多级存储在不同设施上的能力。 应用形式不同• Prometheus Prometheus不须要提前建表，而 TDengine 是关系型数据库模型，须要提前定义好表构造。写入的数据须要自带形容，蕴含很多不同维度的标签(lable)，这些都是动静的。• TDengineTDengine 一个采集点一张表，所以一张表不会并发写入。而 Promtheus 为了防止存储的采样数据产生很多小文件，是以块为单位存储指标的。 ...

数据订阅是一种数据查问形式，其特点为：客户端执行一个查问语句后，能够增量模式，一直收到新达到服务端的、合乎查问条件的数据。相比一般查问，订阅可能继续地、低提早地将新写入的数据返回客户端。什么时候须要数据订阅？订阅是一种低成本地、实时获取 TDengine 最新数据的办法。客户端程序与数据库的交互，通常是由客户端发动查问，再由数据库返回数据。假如每当数据库有数据写入时，都须要立刻将新的写入后果发送给某客户端，如果用查问的形式实现，则须要由客户端定时发动轮询。而大量的发动查问，会减少客户端与服务器的资源耗费；且依据轮询的频率，获取最新数据会有肯定的提早。咱们能够将订阅看作是继续一直的长查问，一旦数据更新（包含新插入），则会立刻被推送至客户端，当数据没有更新时，不会有额定的资源耗费。 TDengine 的订阅能够在服务端过滤数据，从而升高了资源耗费，并且简化了应用层实现。 很多分布式数据库须要集成音讯队列产品来实现数据订阅性能。而 TDengine 提供了相似音讯队列产品的数据订阅、生产接口，用户无需再集成其余产品，从而简化零碎设计的复杂度，升高运维老本。 那么，TDengine 是如何实现订阅性能的？如何通过订阅性能获取数据？ 2023 年 1 月 10 日 20:00-21:00，TDengine 研发工程师刘继聪为大家直播分享《分布式数据库订阅性能的原理及实现》。 内容纲要： 订阅性能及其根本应用分布式订阅、消费者与消费者组通过订阅获取 TSDB 数据以及 WAL 数据通过订阅进行 DB 的实时备份刘继聪，毕业于复旦大学，计算机科学与技术业余，曾就任于阿里云，现负责涛思数据流式计算引擎、数据订阅研发。感兴趣的小伙伴扫描下方图片上的二维码预约观看。 想理解更多 TDengine Database的具体细节，欢送大家在GitHub上查看相干源代码。

在日常应用 TDengine 时，参数是用户们无奈绕开的重要一环。深刻理解参数的属性，失效范畴，查问更改形式等会让咱们在应用数据库的过程中更加节时高效，也有助于咱们更加深刻地了解数据库的架构体系。 在 3.0 版本中，TDengine 对参数做了更好的分类，也提供了几个非常不便的查问入口。首先，咱们来看下它们的应用形式—— 参数分级集群级别参数：SHOW CLUSTER VARIABLES;代表集群搭建时，必须要保障雷同的一组参数。 客户端级别参数：SHOW LOCAL VARIABLES；代表以后客户端配置参数的运行值。 数据节点级别参数：SHOW DNODE dnode_id VARIABLES;SHOW DNODE dnode_id VARIABLES like "xxxxxxxxx";代表该数据节点上所有参数以后配置值（蕴含集群变量、客户端变量），反对 like 子句检索具体的变量值。 数据库级别变量：数据库级别的变量不是通过 show 命令查问的，它须要通过元数据库 information_schema 的零碎表以 SQL 模式查问得出，例如： select * from information_schema.ins_databases\G;（\G不便展现） 参数具体含意TDengine 的集群、客户端、数据节点（即上文 1-3 ）的参数具体含意如下： https://docs.taosdata.com/ref... 留神：局部参数默认是不裸露在配置文件中的，但手动配置它们也能够应用，目标是心愿用户不要随便批改它们从而造成不好的影响。 数据库级别的参数具体含意如下： https://docs.taosdata.com/tao...参数阐明 参数批改形式不论是数据库的服务端还是客户端，它们在启动的初始化阶段都须要调用雷同的函数读取 /etc/taos/taos.cfg（默认门路）加载所需参数。因而，参数的更新形式以冷更新为主，对于上述集群、客户端、数据节点（即上文 1-3 ）的参数，具体更新形式如下： 关上 /etc/taos/taos.cfg；删除参数前的正文符 #（若不删除，则批改有效，依然应用默认值）；批改参数值 ；保留退出；重启数据库服务端/客户端； 以上范畴的参数中，只有日志参数是反对热更新的。如果须要动静调整日志级别用于诊断剖析数据库状态，能够通过 alter dnode命令来实现，具体细节可参考： https://docs.taosdata.com/tao...批改数据节点配置 如果要批改客户端的变量，能够通过alter local 命令来实现，具体细节可参考： https://docs.taosdata.com/tao...批改客户端配置 数据库级别变量不反对冷更新，只反对局部参数的热更，具体细节可参考： https://docs.taosdata.com/tao...批改数据库参数 这里就引申出了另一个问题，针对局部不可批改的参数，即在数据库部署的后期，咱们须要留神哪些地方呢？在后续的文章中，我会持续和大家分享内容，一起迅速把握 TDengine 这款开源、高性能、云原生的时序数据库（Time Series Database）。 ...

北京科技大学设计研究院有限公司作为北京科技大学全资产业化技术推广机构，从 2013 年开始在冶金、钢铁行业进行业务零碎开发和施行，围绕先进资料、绿色低碳和智能制作一直深耕细作，继续翻新。其领有高效轧制与智能制作国家工程钻研核心、国家板带生产先进配备工程技术钻研核心和北京市交通与能源用特殊钢工程技术钻研核心三个次要钻研机构，多年来始终专一于金属材料加工畛域的自动化、信息化、智能化全产业链解决方案，曾经建设起齐备的管制管理体系、售后服务体系和维保服务体系，并已通过品质、环境、职业衰弱、信息安全、信息技术服务等多项管理体系认证，取得北京市优良技术转移机构及首届钢铁工业智能制作优良品牌名称、入选北京市专精特新中小企业，“金属材料轧制过程智能检测与精准管制关键技术利用”荣获中国技术市场协会金桥奖我的项目一等奖。 在企业数字化的晚期阶段，很多企业在解决工业生产中大量的典型时序数据时，因海内软件有先发劣势，大都抉择了 Wonderware InTouch + InSQL/Historian 的解决方案。然而随着业务的倒退，生产中须要监测的指标从几万个减少到几十万甚至百万个以上，原有计划在扩大能力上遇到瓶颈，呈现了以下挑战： 非国产化：在简单的国际形势下，存在一些不确定性封闭性：很多软件是闭源的，而且处于本人的关闭体系之下，扩展性差高度复杂度：须要洽购一系列产品组合高老本：洽购价格昂贵、性能扩大须要额定付费，依赖 Windows、SQL Server 等其他软件，会产生额定的洽购老本服务响应慢：国外产品广泛服务响应不及时，反馈常常以天为单位，服务保障性差面对上述挑战， 时序数据库（Time Series Database） TDengine 在晋升数据存取效率、突破传统数据孤岛、晋升数据无效利用率方面为北京科技大学设计研究院的冶金数字化提供了实质性的帮忙，帮助打造了智能化对立平台，不便部署、简化整体架构的同时，凭借高性能、高压缩率，TDengine 还实现了总体领有老本的大幅升高、满足国产化等要求。 将来，TDengine 将与北京科技大学设计研究院一起，充分利用单方技术劣势，赋能冶金行业倒退，让冶金行业的数据处理能力失去实质性晋升。 想理解更多 TDengine Database的具体细节，欢送大家在GitHub上查看相干源代码。

日月其迈，时盛岁新2022 的进度条曾经加载至“100%”疫情肆虐下，毫无疑问这依然是头顶风雪攀登山峰的一年好在现在曙光已现回望这一年，TDengine 也硕果满满 2022 年是 TDengine 创建的第六个年头咱们付出着，也在播种着拥抱开源、深耕技术、单干翻新TDengine 的初心和前进方向从未扭转回望是为了更好地总结过来、瞭望远方令咱们快慰的是，回顾可喜，将来可期。 从“云就绪”到云原生，产品继续新陈代谢2022 年 8 月，TDengine 3.0 版本在首届 TDengine 开发者大会上正式公布，在数千名开发者独特的见证下， TDengine 正式降级成为了一款真正的云原生时序数据库（Time Series Database），破解了困扰时序数据库倒退的高基数难题，反对 10 亿个设施采集数据、100 个节点，反对存储与计算拆散。同时这一全新版本还针对存储引擎、计算引擎进行了降级优化，并打造了全新的流式计算引擎，无需再集成 Kafka、Redis、Spark、Flink 等软件，大幅升高了零碎架构的复杂度。 继 3.0 公布后，工夫拨回到 2022 年 10 月，TDengine Cloud 胜利登陆海内市场，这是一个齐全托管的、开源的云时序数据平台，借助该平台，物联网和大数据开发人员能够在私有云上间接拜访和部署持重、平安、扩展性强的 TDengine。同时，为了让企业既能保留传统的 PI 零碎，又能轻松取得古代云平台提供的所有益处，TDengine PI 连接器也在不久后胜利上线，利用该连接器，用户只需几次点击，就能够疾速将传统零碎中的数据迁徙到古代技术栈中，目前这一服务在 TDengine Cloud 和 TDengine 3.0 企业版中均可取得。 除了产品层面的技术迭代翻新，为了满足用户的业务需要，晋升用户的应用体验，TDengine 也在鼎力欠缺本身产品生态，在曾经可能与 Kafka、Telegraf、Grafana、Google Data Studio、EMQ X、Prometheus、StatsD 和 collectd 等泛滥第三方工具集成的根底上，TDengine 又连贯了工业英特尔® 边缘洞见软件包、数据同步工具 DataX，插件也正式上架 Grafana 官网、连接器上线 Google Data Studio 利用商店。在工具反对上，新增了 taosAdapter（TDengine 集群和应用程序之间的桥梁和适配器）、taosKeeper（TDengine 3.0 版本监控指标的导出工具）等更多实用型工具。 20.3k Star，三载开源再创佳绩2022 年是 TDengine 开源的第三个年头，在鼎力锻炼产品技术实力的同时，TDengine 也始终在保持着凋谢开源的初心，而这也帮忙它吸引到了国内外越来越多的开发者的关注。目前，TDengine 曾经在 GitHub 上播种了 20.3k 的 Star，并再次登上 GitHub 寰球趋势榜第一名。 ...

金航数码科技有限责任公司（航空工业信息技术核心）是中国航空工业团体有限公司（航空工业）的信息技术业余撑持机构，肩负着“推动产业数字化，践行数字产业化”的使命，致力于做数字技术驱动工业转型的集大成者。其总部设立在北京，在成都、上海、西安、沈阳、南昌等地均设有分支机构，在治理与 IT 征询、系统工程、综合治理、生产制作、客户服务、IT 基础设施与信息安全等业务畛域，为客户提供笼罩产品全生命周期、治理全业务流程、产业全价值链的“三全”解决方案。 金航数码聚焦以数字化转型为外围的倒退策略，深耕物联网、大数据、人工智能、云计算等新技术的钻研与利用，重点倒退了“征询+软件+零碎”三大业务群，其以征询为引领、软件为外围、零碎为撑持，继续为配备制造业的高质量倒退提供“数.智”解决方案。 金航数码自主研发的金航物联网平台（SuperLink），交融利用了云计算、大数据、人工智能等先进 IT 技术，实现了热加工设施互联以及“生产工作-工艺规程-合炉配炉-过程治理-数据分析”全笼罩的生产治理纵向贯通，通过建设热加工的数字孪生优化场景，热加工效率和产品质量一致性取得全面晋升。 随着业务的倒退，该平台原有的数据解决方案越来越难以应答数百台热加工设施的数据处理，在查问、写入等方面性能均无奈满足业务需要。为了解决平台的性能枷锁以及实现数据库自主可控，金航数码抉择利用 TDengine 革新现有数据库架构。作为一款国产化开源时序数据库(Time Series DataBase)，TDengine 不仅能实现高效建表、高速写入、间断查问等，在存储方面的优良设计也帮忙金航数码进一步节俭了内存空间，升高了资源耗费及业务倒退老本。将来 TDengine 将和金航数码一起助力航空工业信息化，以模型和数据为外围，减速行业的数字化、智能化倒退。 想理解更多 TDengine Database的具体细节，欢送大家在GitHub上查看相干源代码。

新奥团体于 1989 年创建于河北廊坊，以城市燃气为终点，逐渐笼罩了分销、贸易、输储、生产、工程智造等天然气产业全场景，贯通清洁能源产业链，提供智能化低碳综合能源服务。目前，新奥在全国21个省，已服务超过 2681 万个家庭用户、21 万家企业。 新奥团体旗下企业新奥新智科技有限公司（简称“新奥新智”）是一家智能生态运营商，致力于以物联促成智能、用智能降级产业。其依靠智能物联、新智云、联结学习、平台引擎等技术，重点建设了组织中台、行业中台和数智中台，为产业客户的数字化倒退提供赋能产品及解决方案。作为新奥的数字化创值型能力平台，新奥新智始终秉持着“源自客户、成就彼此、共创生态”的新奥之道，以长期实践教训和弱小的产品能力一直推动着多产业智能化倒退。 新奥团体作为国内较大的清洁能源分销商，旗下的新奥新智通过信息化伎俩对能源站、燃气管网、燃气表等进行设施网联，实现高效治理和监测。然而随着利用场景的增多、联网设施的指数级增长，使得数据存储老本大幅度晋升，数据写入和查问迟缓。新奥团体在进行整体物联网数据处理平台搭建和降级的过程中，逐步发现了老式时序数据库 OpenTSDB 写入性能和并发查问能力的有余，重度依赖 HBase，整体平台运维十分惨重。同时数据从边缘侧采集到应用层展现有显著延时；报表计算也无奈在限定工夫内实现，重大影响了业务的时效性。 为了解决微小数据量带来的数据存储挑战以及原计划性能有余的问题，通过多轮深刻的技术探讨和选型评测，新奥新智抉择利用时序数据库 TDengine Database 来革新原有数据架构，革新实现后，不仅零碎架构失去了极大简化，数据读写能力也失去了极大晋升，企业的总领有老本显著升高，同时对于将来整体物联网平台的降级和扩大打下了良好的根底。 想理解更多 TDengine Database的具体细节，欢送大家在GitHub上查看相干源代码。

深圳华锐分布式技术股份有限公司（简称“华锐技术”）是一家专一于为资本市场提供下一代分布式低时延根底技术及外围业务零碎的国家高新技术企业，致力于晋升中国金融基础设施自主能力，自主研发了下一代分布式中间件，助力金融机构实现外围业务零碎的分布式转型，已倒退成为下一代分布式低时延金融技术的引领者。华锐技术于 2018 年、2019 年间断取得外乡创投排名第一的深创投 A 轮、Pre-B 轮投资；2020 年取得招商局团体、招商银行、国泰君安证券旗下机构 B 轮投资；2021 年上半年实现由华泰翻新领投的 Pre-C 轮融资，红杉资本中国基金的 C 轮融资；近日取得由国鑫创投、长江翻新、粤财基金、亚布力创投、德成基金独特参加的数亿元融资。 作为国内当先的低时延分布式平台，华锐技术平台每天须要反对客户解决各种金融机构的海量行情数据，为了确保这些行情数据的准确性，搭建了实时风控系统。随着业务的一直扩张，数据存量和增量的数量级一直回升，数据的实时写入成为瓶颈，查问剖析变得极为迟缓，数据存储老本显著增长。而传统的关系型数据库、NoSQL 数据库都没有针对时序数据个性进行适配优化，性能体现十分无限。更多的是依附集群技术，减少更多计算和存储资源来应答，导致系统的运行保护老本急剧回升。TDengine 充分利用时序数据特点，通过自主翻新的存储引擎设计，使得数据写入、查问性能大幅晋升，存储老本大幅升高；同时，其内建的音讯队列、缓存、流式计算等性能，可能简化零碎复杂度，进一步升高利用开发和经营保护老本。在这些技术劣势的加持下，华锐技术抉择与 TDengine 开展单干，独特破解行情数据的解决难题，并在多个金融我的项目中实现大规模行情数据实时处理。 此前，TDengine 已在中泰证券、同花顺等诸多金融场景中获得成功实践——企业通过 TDengine 构建行情核心，用于存储海量的股、基、债、期资产的行情时序数据，基于海量行情数据及其产生大量的加工、模仿数据，进行回测、因子、深度学习模型等量化利用。将来，TDengine 将与华锐技术一起，充分利用单方技术劣势，赋能金融行业倒退，让金融行业的数据处理能力失去实质性晋升。 点击这里，查看 TDengine 金融场景解决方案。 想理解更多 TDengine Database的具体细节，欢送大家在GitHub上查看相干源代码。

近日，涛思数据旗下开源、高性能、云原生的时序数据库（Time Series Database，TSDB）TDengine 胜利上线亚马逊云科技 Marketplace，为用户提供了更加丰盛的订阅渠道。 TDengine 是针对时序数据特点研发和优化的数据库解决方案，对于车联网、物联网、工业互联网、IT 运维等场景下的时序大数据处理，能起到更为显著的降本增效作用。当初通过亚马逊云科技 Marketplace（中国区）网站 ，用户能够疾速订购 TDengine 产品及服务，针对现有业务痛点灵便地制订部署打算。亚马逊云科技 Marketplace 为用户提供了一个精心严选的数字化产品目录，用户通过它能够轻松地查找、购买、部署和治理构建解决方案，以及经营其业务所需的来自独立软件供应商（ISV）的服务及软件。亚马逊云科技 Marketplace 中蕴含数千种热门服务以及软件产品，例如平安、网络、存储、机器学习、商业智能、数据库和开发经营软件等。此外，其还提供灵便的付款选项和多种部署形式，可能简化服务及软件的许可和洽购过程。 涛思数据作为亚马逊云科技合作伙伴，瞄准日益增长的物联网数据市场，专一时序空间大数据的存储、查问、剖析和计算，通过技术创新，为物联网、工业互联网、汽车、能源等行业提供全栈、高性能、低成本的大数据平台。其不依赖任何开源或第三方软件，开发了领有自主知识产权、100%自主可控的时序数据库 TDengine，目前 TDengine 曾经演进到3.0版本，成为了一款真正的高性能、云原生的时序数据库。 在云原生的加持下，TDengine 3.0解决了困扰时序数据库倒退的高基数难题，反对10亿个设施采集数据、100个节点，反对存储与计算拆散并打造了全新的流式计算引擎，无需再集成 Kafka、Redis、Spark、Flink 等软件，大幅升高零碎架构的复杂度，真正成为了一款极简的时序数据处理平台。同时，TDengine 3.0还将存储引擎、查问引擎都进行了优化降级，存储和查问性能取得进一步晋升。作为数据库新兴赛道的领军者，TDengine 目前曾经在电力、工业、能源、金融、车联网、智慧城市等诸多行业畛域获得诸多利用，帮忙一众企业用户将其业务零碎、物联网平台以更低的老本和更快的速度推向市场，依附一直地技术创新，继续冲破企业研发和运维老本的最低线，产品性能也在一直晋升。 从用户需要登程，TDengine 研发团队始终在一直对产品性能进行打磨与更新，同时为了更好地服务用户，TDengine 保护了数十个用户群，让用户的每个问题都有业余的官网技术人员进行解答。在产品和服务质量的双重保障下，TDengine 的用户群体也在不断扩大，在 GitHub 上的 Star 数达到了 20.3K，寰球运行的 TDengine 实例数超过 157.2K，用户遍布寰球。 亚马逊云科技 Marketplace（中国区）网站（https://awsmarketplace.amazon...）向用户提供了敌对的产品界面，帮忙用户通过产品种类、软件供应商、部署形式和定价形式等多个搜寻过滤器疾速查找相干产品。亚马逊云科技 Marketplace（中国区）官网还反对中英文关键词搜寻，在找到您感兴趣的产品后，您能够查看产品详细信息页面。产品详细信息页面蕴含能够帮忙您疾速理解和应用该产品的所有信息，例如，价格信息局部，在确定区域后，您能够查看相应 Amazon EC2 实例的每小时应用价格。上面咱们就向您展现如何通过亚马逊云科技 Marketplace（中国区）网站订阅以及启动时序数据库 TDengine。 第一步通过亚马逊云科技 Marketplace（中国区）网站搜寻框，搜寻“TDengine”，点击产品并抉择右侧“持续订阅”； 第二步进入下一页浏览相干内容以及条款阐明后，点击“承受条款”按钮。 第三步点击“持续配置”，并设置相干参数，包含实例类型、部署区域、VPC、子网、平安组等相干参数，即可启动蕴含涛思产品的实例。该产品由宁夏西云数据科技有限公司代理销售许可证，具体 License 价格请致电10100966-8-2。 点击“这里”，可通过亚马逊云科技 Marketplace 网站订阅及启动时序数据库 TDengine。 想理解更多 TDengine Database的具体细节，欢送大家在GitHub上查看相干源代码。

一汽解放汽车有限公司是中国第一汽车股份有限公司旗下一汽解放集团股份有限公司（深交所上市，股票代码000800）的全资子公司，成立于 2003 年 1 月 18 日，是中、重、轻型卡车及客车制作企业，整车年生产能力 39.3 万辆。2021 年，一汽解放共销售整车近 44 万辆，其中中重卡销售 37.34 万辆，份额 23.7%，稳坐行业第一，荣获中重卡销量寰球“五连冠”、重卡销量寰球“六连冠”，牵引车销量间断十六年行业相对当先。 随着车联网技术平台的深入倒退，智慧交通物流正逐渐变为事实，智能网联让解放卡车不再单纯局限为运输的载体，而是成为挪动的数据交互平台，从而实现智能运输、场景互联。作为国内商用车领军企业，一汽解放于 2019 年公布了“哥伦布智慧物流凋谢打算”，致力于从“传统的卡车制造商”向“智慧交通运输解决方案提供者”转型。对于车联网技术的利用与探索，早在 2017 年，一汽解放便率先“试水”车联网，并于近年成为车联网航线的实践者，摸索更广大的智慧物流“新蓝海”。 目前，其已实现了商用车智能网联解决方案从硬件到平台到服务经营的全面布局，并通过车规级智能网联设施和自主研发的车联网云平台，为数百家物流公司、1000 多家车队以及 200 万以上司机提供笼罩车队治理、智能网联车载终端、智能座舱、平安保险等在内的一体化物流解决方案。 对于一汽解放来说，数据处理的有效性和高效性始终都是其关注的重点，理论业务数据量微小，要求底层平台可能反对超过百万辆车的采集数据实时接入，同时反对高并发、大批量历史数据的查问获取，以撑持简单的业务计算服务，TDengine 的设计劣势恰好可能满足上述需要。而除了这些，一汽解放同样关注数据库的稳定性和行业知名度。在其选型调研阶段，凭借着在行业内良好的口碑以及优良的性能，TDengine 怀才不遇，取得用户青眼。单方团队通过继续技术单干和超大规模 TDenigne 时序数据库集群交付，曾经实现全数据业务上线和继续稳固运行。 此前，TDengine 曾经屡次被利用到车联网场景的数据处理中，不仅帮忙大疆车载实现了在海量数据并发场景下的高效统计报表能力和查问 SQL 效率、助力蔚来汽车节俭了 50% 的存储空间及 60% 的集群计算资源老本；还为零跑汽车解决了 HBase 入库不及时的问题，用更少的服务器资源入库更多的数据……此次 TDengine 与一汽解放达成商业单干，单方也将从理论业务的倒退需要登程发展更多有价值的技术单干，一一突破原有数据架构的数据存储问题，让汽车制作行业的数据处理实现更高水平的降本增效。 想理解更多 TDengine Database的具体细节，欢送大家在GitHub上查看相干源代码。

近日，TDengine 3.0.2.0 正式公布了。这是自往年 8 月份 TDengine 3.0 公布以来的第一个重要改良版本。 TDengine 3.0 带来了几大外围个性，包含云原生架构、流式计算，还加强了数据订阅性能；更重要的是，3.0 系列版本开始提供了全平台反对，服务器/客户端均已反对 Linux、Windows 和 MacOS。 TDengine 3.0 是一款真正的云原生时序数据库（Time Series Database，TSDB）。它有几大亮点： 能够反对 10 亿个设施、100 个节点反对存储与计算拆散，引入了计算节点（QNode），并重构了整个计算引擎欠缺并优化了对音讯队列、流式计算和缓存的反对，引入事件驱动的流式计算解决了困扰时序数据库的高基数问题3.0 公布之后，大量用户下载试用，也提供了很多有价值的反馈。最近一段时间，研发团队引入各类外部优化共 455 个，包含晋升零碎稳定性，改良写入和查问性能，以及优化内存应用效率。为了保证系统品质，研发团队还开发了数千个性能、性能和稳定性测试用例。 通过诸多优化之后，TDengine 的性能也失去了充沛的晋升和验证。 上面咱们看一下到 3.0.2.0 版本为止，TDengine 3.0 提供的次要个性和加强： 反对事件驱动的流式计算反对用 SQL 语法创立流式计算，不便用户轻松实现较为简单的业务逻辑 CREATE STREAM [IF NOT EXISTS] stream_name [stream_options] INTO stb_name AS subquerystream_options: { TRIGGER [AT_ONCE | WINDOW_CLOSE | MAX_DELAY time] WATERMARK time IGNORE EXPIRED [0 | 1]}为反对数据订阅，提供了一个全新的音讯队列、基于 WAL 从新设计了数据订阅性能，具体利用可参考相干文档 反对新的 SQL 查问语法，去掉了对一些查问语法的限度具体变更可参考相干文档 ...

中泰证券股份有限公司（原名齐鲁证券有限公司）成立于 2001 年 5 月，是全国大型综合类上市券商（股票代码：600918），在全国 28 个省市自治区设有 45 家分公司、284 家证券营业部，员工 9000 多人，控股中泰期货、中泰资本、中泰金融国内、中泰资管、中泰创投、齐鲁股权交易中心，参股万家基金，造成了集证券、期货、基金等为一体的综合性证券控股集团。 在中泰证券所面临的金融量化交易场景中，每天都会产生大量的交易记录和交易信息须要存储，同时对数据也有较高要求的查问需要，整体需要概括来讲包含历史数据的存储、实时数据的接管以及数据的监控和剖析。随着数据量级的一直晋升，传统的关系型数据库曾经无奈满足这类大体量时序数据的写入、存储、剖析监控等业务需要，业务倒退亟需进行数据架构降级。 在此背景下，TDengine 与中泰证券正式签约单干，将来单方将深刻摸索数据技术如何更深度解决金融量化交易场景的数据技术难题，从时序数据处理需要特点登程进行金融我的项目的数据架构改革，独特推动金融行业向好向快倒退。置信在中泰证券的助力下，时序数据库 TDengine 也可能更加精准疾速进行技术创新降级，继续深入金融业务赋能口头。 点击这里，查看 TDengine 金融场景解决方案。 想理解更多 TDengine Database的具体细节，欢送大家在GitHub上查看相干源代码。

2022 年行将走过，而 TDengine 在这一年的提高大家引人注目，不仅 GitHub 冲破了 20000 Star，寰球装置实例直线上涨到了 178.1k，受到国内外开发者更宽泛的关注。在产品迭代上更是推出了 3.0 版本，叠加了云原生、流计算等翻新元素，解决了时序数据库业内难解的高基数难题，还对查问引擎、存储引擎进行了进一步的优化与降级…… 如果你也始终在关注着 TDengine，那你也肯定有很多想对 TDengine 说的话，或者想分享的 TDengine 实用教训，那无妨用键盘把它们“敲”进去，和咱们一起独特推动和记录 TDengine 的每一次提高。 叮铃铃铃~~2022 年度“用 TDengine，写 TDengine”有奖征文活动如期而至，赶快关上你的电脑，把你与 TDengine 在 2022 年产生的故事用文字说给大家。只有参加投稿，你就有机会取得咱们精心筹备的精美奖品，如果你能在投票环节怀才不遇，那就能够拿走科技感十足的前三等大奖了（下滑揭晓奖品名单）！所有的奖品咱们都会赶在大年三十之前邮寄给获奖选手，也心愿这份“新年礼品”能为大家新的一年带来一份“好彩头”~ Part.1 如何参加内容创作范畴（字数要求：1000字以上） TDengine 3.0 的学习和应用教训TDengine 业务落地实际TDengine 革新原有架构的教训分享TDengine 集群应用实际TDengine 业务建模思考TDengine 3.0 代码剖析理解 TDengine 的渠道官网：https://www.taosdata.com/GitHub 社区：https://github.com/taosdata/T... 投稿形式第一步：稿件实现之后公布至官网单干媒体平台“SegmentFault”上，标注好作者名 第二步：加小助手小T微信号（ID：tdengine），将公布后的链接推送给小T 第三步：小T会给参赛者同步发送一则原创申明，参赛者签订后立刻失效以上所有操作实现后投稿即胜利。 流动工夫节点 本次流动的截止投稿日期为 2023 年 1 月 6 日24:00，稿件收集到位之后咱们会基于上述创作条件先进行一轮筛选，筛选工夫为 1 月 7 日-8 日 24:00；合乎上述创作条件的优质稿件将会通过 TDengine 公众号进行公示投票评比，投票工夫为 1 月 9 日-11 日 24:00；最初咱们会在 1 月 12 日进行最终的获奖人选揭晓并进行线上“颁奖”，为最终的获奖选手邮寄咱们的大奖！ ...

TDengine 提供的混合解决方案，能够让企业既能保留传统的 PI 零碎，又能轻松取得古代云平台提供的所有益处。涛思数据发表公布 TDengine PI 连接器。 在很多制造业企业中，因为历史的起因，他们抉择了用 PI System 来存储生产过程中产生的时序数据。利用新的 TDengine PI 连接器，只需几次点击，就能够疾速将传统零碎中的数据迁徙到古代技术栈中，而且反对私有云和私有化部署，进而实现更为凋谢和低成本的实时剖析。 TDengine 是一款开源、云原生的时序数据库（Time Series Database），专为物联网、工业互联网、金融、IT 运维监控等场景设计并优化，具备极强的弹性伸缩能力。同时它还带有内建的缓存、流式计算、数据订阅等零碎性能，能大幅缩小零碎设计的复杂度，升高研发和经营老本，是一个极简的时序数据处理平台。自 2019 年开源以来，TDengine 失去了宽广开发者和用户的极大认可，在 GitHub 上播种了 19.5k star，运行实例数超过 16.5 万，遍布寰球 50 多个国家和地区。 TDengine PI 连接器功能强大，简略易用，反对 PI 客户构建一个混合的解决方案，以利用现有投资，同时利用古代数据平台的弱小剖析能力。 “有价值的经营数据往往被锁在关闭的传统零碎中，这妨碍了业务的翻新和倒退”，涛思数据创始人陶建辉示意。“TDengine PI 连接器为工业数据提供了一个凋谢的解决方案，使用户可能利用古代的数据分析工具进一步开掘数据的价值。” TDengine PI 连接器的劣势只需几次点击，即可将数据复制到云上。借助 TDengine PI 连接器，只须要抉择 PI 测点或 AF（Asset Framework）框架，就能够将数据以流式形式源源不断地写入 TDengine Cloud 或私有化部署的零碎中。在实现疾速设置后，TDengine PI 连接器即可解决 ETL 的简单逻辑，包含中断之后的主动回填。利用弱小的混合解决方案来伸缩零碎。在该解决方案中，新的测点数据保留在 TDengine 中，而传统的测点数据仍存在于 PI 中，而且所有存储在这两个零碎中的数据都能够用 PI AF、PI Vision 或 TDengine Data Explorer 实现剖析和可视化。对企业而言，之前在 PI 上的投入不会损失，同时还能够扩大到一个使 PI 和 TDengine 共存的、齐全集成的混合解决方案。利用开放系统将数据解锁。TDengine 能够与数据经营中罕用的很多剖析和可视化工具无缝集成。TDengine 合乎工业物联网开源凋谢的大趋势，通过将工业企业数据集成到古代零碎和工作流之中，能够实现面向未来的平滑迁徙。让“即用即付”代替购买软件许可。除私有化部署外，借助 TDengine Cloud，用户只需依照理论使用量付费，平台自身没有后期费用，也没有对测点数目或剖析的限度。TDengine 能够作为齐全托管的服务，具备主动备份以及云的不同区域之间的数据复制性能。往年 8 月份，咱们正式公布了 TDengine 3.0，反对 Kubernetes 和容器，使其成为一款真正云原生的时序数据库。上个月咱们又在北美市场公布了 TDengine Cloud，这是一个齐全托管的、开源的云时序数据平台。TDengine Cloud 和 TDengine 3.0 企业版都提供了 TDengine PI 连接器。 ...

小 T 导读：为了在数据采集项频繁变动的状况下保障用户依然可能顺利地实现数据记录工作，TDengine 提供了三种无模式写入协定，别离是 InfluxDB Line 协定、OpenTSDB Telnet 协定和 OpenTSDB JSON 格局协定。本文将对无模式写入形式的次要解决逻辑、映射规定与变更解决等进行剖析，便于用户了解与应用。 通常来说，物联网利用常会采集比拟多的数据项，用于实现智能管制、业务剖析、设施监控等性能。但在此过程中，因为应用逻辑的版本升级，或者设施本身的硬件调整等起因，数据采集项可能较为频繁地呈现变动。这也是时序数据库（Time Series Database，TSDB）须要应答的一个挑战。 为了在这种状况下顺利完成数据记录工作，TDengine 提供了 Schemaless 写入形式，让用户能够省略掉事后创立超级表/子表的步骤，凭借数据写入接口可能主动创立与数据对应的存储构造。在必要时，Schemaless 将主动减少必要的数据列，保障用户写入的数据可能被正确存储。 值得一提的是，通过无模式写入形式建设的超级表及其对应的子表，与通过 SQL 间接建设的超级表和子表齐全没有区别，你也能够通过 SQL 语句间接向其中写入数据。但须要留神，通过无模式写入形式建设的表，其表名是基于标签值依照固定的映射规定生成的，所以无奈明确地进行表意，不足可读性。 无模式写入行协定TDengine 的无模式写入行协定兼容 InfluxDB 的行协定（Line Protocol）、OpenTSDB 的 telnet 行协定、OpenTSDB 的 JSON 格局协定。然而应用这三种协定的时候，须要在 API 中指定输出内容应用解析协定的规范。 对于 InfluxDB、OpenTSDB 的规范写入协定请参考《在 TDengine 中如何高效写入？四种写入形式提效大全》。上面首先以 InfluxDB 的行协定为根底，介绍 TDengine 扩大的协定内容，容许用户采纳更加精密的形式管制（超级表）模式。 Schemaless 采纳一个字符串来表白一个数据行（能够向写入 API 中一次传入多行字符串来实现多个数据行的批量写入），其格局约定如下：measurement,tag_set field_set timestamp 其中： measurement 将作为数据表名。它与 tag_set 之间应用一个英文逗号来分隔。tag_set 将作为标签数据，其格局形如 <tag_key>=<tag_value>,<tag_key>=<tag_value>，也即能够应用英文逗号来分隔多个标签数据。它与 field_set 之间应用一个半角空格来分隔。field_set 将作为一般列数据，其格局形如 <field_key>=<field_value>,<field_key>=<field_value>，同样是应用英文逗号来分隔多个一般列的数据。它与 timestamp 之间应用一个半角空格来分隔。timestamp 即本行数据对应的主键工夫戳。tag_set 中所有的数据主动转化为 nchar 数据类型，并不需要应用双引号（”)。在无模式写入数据行协定中，field_set 中的每个数据项都须要对本身的数据类型进行形容。具体来说： ...

小 T 导读：用户在做时序数据库（Time Series Database，TSDB）的选型调研时，通常要进行环境模拟测试，以观察所选数据库的性能优劣和老本损耗状况。为不便用户，TDengine 官网提供了一款名为 taosBenchmark 的测试工具，本文将会具体解说其应用形式，供读者参考。 taosBenchmark （曾用名 taosdemo ) 是一个用于测试 TDengine 产品性能的工具。taosBenchmark 能够测试 TDengine 的插入、查问和订阅等性能的性能，它能够模仿由大量设施产生的大量数据，还能够灵便地管制数据库、超级表、标签列的数量和类型，数据列的数量和类型，子表的数量，每张子表的数据量，插入数据的工夫距离，taosBenchmark 的工作线程数量，是否以及如何插入乱序数据等。为了兼容过往用户的应用习惯，TDengine 安装包提供 了 taosdemo 作为 taosBenchmark 的软链接。 装置taosBenchmark 有两种装置形式: 装置 TDengine 官网安装包的同时会主动装置 taosBenchmark，详情请参考 TDengine 装置（https://docs.taosdata.com/ope...）。独自编译 taos-tools 并装置，详情请参考 taos-tools 仓库（https://github.com/taosdata/t...）。 运行配置和运行形式taosBenchmark 须要在操作系统的终端执行，该工具反对两种配置形式：命令行参数和 JSON 配置文件。但这两种形式是互斥的，在应用配置文件时只能应用一个命令行参数 -f <json file> 指定配置文件；在应用命令行参数运行 taosBenchmark 并管制其行为时则不能应用 -f 参数而要用其它参数来配置。除此之外，taosBenchmark 还提供了一种非凡的运行形式，即无参数运行。 taosBenchmark 反对对 TDengine 做齐备的性能测试，其所反对的 TDengine 性能分为三大类：写入、查问和订阅。这三种性能之间是互斥的，每次运行 taosBenchmark 只能抉择其中之一。值得注意的是，所要测试的性能类型在应用命令行配置形式时是不可配置的，命令行配置形式只能测试写入性能。若要测试 TDengine 的查问和订阅性能，必须应用配置文件的形式，通过配置文件中的参数 filetype 指定所要测试的性能类型。 具体的命令行参数和 JSON 配置文件，可移步至 https://docs.taosdata.com/ref... 进行查阅。但须要留神的是，在运行 taosBenchmark 之前肯定要确保 TDengine 集群曾经在正确运行。 ...

在金融量化交易场景中，每天都会产生大量的交易记录和交易信息须要存储，同时对数据也有较高要求的查问需要，整体需要概括起来就是历史数据的存储、实时数据的接管以及数据的监控和剖析。对于这类有典型时序特色的数据，很多企业在业务初期抉择了团队相熟的 HBase、MySQL、MongoDB 等数据库。然而随着业务的疾速倒退，这些数据库曾经无奈满足大体量数据的写入、存储、剖析监控等业务需要。 为了帮忙一众金融企业寻找到适合的数据库解决方案，咱们汇总了几个比拟有代表性的企业客户案例，心愿他们的相干实践经验应该可能给到行业从业者一些解决思路。 TDengine x 同花顺“目前从大数据监控这个场景看，TDengine 在老本、性能和应用便利性方面都显示出十分大的劣势，尤其是在节省成本方面给咱们带来了很大惊喜。在预研和我的项目落地过程中，涛思数据的工程师也提供了业余、及时的帮忙，后续咱们也将在同花顺的更多场景中尝试利用 TDengine。”业务背景同花顺每天须要接管海量交易所行情数据，确保行情数据的数据精确。但因为该局部数据过于宏大，而且应用场景颇多，每天会产生很多的加工数据，整个零碎除了对实时数据的读写性能及延时有较高要求外，还须要聚焦历史日级别数据做投资组合的各种剖析，在整个剖析过程中，波及巨量的数据集，这对历史数据库的读写性能也提出了很高的要求。之前采纳的 Postgres+LevelDB 数据存储计划，除了依赖多、稳定性较差外，性能方面也无奈满足需要（点击下方案例链接获取具体业务痛点问题）。通过对 ClickHouse、InfluxDB、TDengine 等时序数据存储计划的调研，最终其抉择了 TDengine。 架构图 革新后性能比照 点击案例查看更多技术细节 TDengine x 弘源泰平“在写入上，单节点TDengine能够轻松实现每秒大略 3 万行数据的写入量，同时耗费服务器资源又比 InfluxDB 与 MySQL 要小很多。目前咱们通过 TDengine 录入的两个信号表曾经写入了 82 亿条数据，原数据大略为 92GB，理论占用存储空间为 20G 左右，压缩率高达 23%。除了写入与存储，TDengine 进行日常查问的速度也非常优良，面对几十亿级别的大表，也能实现毫秒级响应。”业务背景弘源泰平的量化交易系统每天要接管大量的行情数据，也要基于行情产生大量的决策信号。这些数据都须要及时存下来，供盘中和盘后应用。传统寄存行情数据的形式有文件系统、关系型数据库或者文档数据库。此前他们别离尝试了 MySQL 和出名的时序数据库（Time Series Database） InfluxDB，然而性能都没有达到预期，呈现了响应工夫长、资源节约等诸多问题（点击下方案例链接获取具体业务痛点问题）。最终，其改用 TDengine 彻底解决了实时写入大量数据点和疾速查问的问题。 资源耗费服务器配置如下：64G内存+40核 1.8GHz CPU+机械硬盘。在业务运行期间，taosd 的 CPU 在 4% 高低浮动，过程应用的物理内存百分比为 11.2%。因为其 vnode 配置较多，而每个 vnode 都有本人固定的内存缓冲区，因而内存占用稍多，但后续即使是持续大量减少新表或者加大写入量，内存占用也不会再有显著的浮动了。 点击案例查看更多技术细节 TDengine x 同心源（三亚）基金“对入库的总数据量进行下估算，粗略计算为 408*320 亿行，大略 12TB 左右，前面通过统计最终理论占用磁盘空间却只有2T左右，这令咱们非常震惊——压缩率高达 16.7%。在查问方面，从TDengine客户端服务器应用Python从服务端拉取间断两个月的期货行情数据，耗时仅需 0.16 秒。”业务背景从同心源的业务模式登程，业务人员次要通过数据挖掘和主动模式识别这两种形式来发现市场的交易法则，其工作场景基于大量的金融数据之上。通过多年倒退，股票市场数据量越发宏大，随着每日新数据的荡涤写入，总量变得更加水涨船高。对于十几 TB 的数据量，单是进行存储曾经不易，如果还要对数据进行查问下载等操作，更是难上加难。种种问题叠加，同心源对市面上的支流数据库逐步丢失信念，尝试应用更有针对性的时序数据库，TDengine 便是他们的抉择之一。 ...

小 T 导读：尽管 TDengine 曾经提供了十分多的罕用计算函数，然而在具体实际中，企业的开发团队往往会因为本人非凡的业务需要，须要特有的计算函数，这时候，反对自定义函数性能就特地重要了。本文将介绍 TDengine 3.0 反对的 UDF 机制。 在应用 TDengine 这款时序数据库（Time Series Database, TSDB）的时候，咱们常常会用到各种内置函数，通过在数据库中实现很多计算，能够大大简化数据库应用层的开发工作。 TDengine 提供了大量的内置函数，能够分为几个大类： 单行函数：单行函数为查问后果中的每一行返回一个后果行 数学函数：如 ABS、SIN、COS、LOG、POW 等字符串函数：如 CHAR_LENGTH、CONCAT、LOWER、SUBSTR、UPPER 等转换函数：如 CAST、TO_JSON、TO_UNIXTIMESTAMP 等工夫和日期函数：NOW、TIMEDIFF、TIMEZONE、TODAY 等聚合函数：聚合函数为查问后果集的每一个分组返回单个后果行 如 AVG、COUNT、STDDEV、SUM 等选择函数时序数据特有函数零碎信息函数 尽管 TDengine 曾经提供了这么多罕用的计算函数，然而在具体实际中，企业的开发团队往往会因为本人非凡的业务需要，须要特有的计算函数，这时候，反对自定义函数性能就特地重要了。 本文将具体介绍如何在 TDengine 中定义并应用自定义函数。 利用 UDF(User Defined Function) 性能，TDengine 能够插入用户编写的解决代码并在查问中应用它们，这样就能很不便地解决非凡利用场景中的应用需要。 UDF 通常以数据表中的一列数据做为输出，同时反对以嵌套子查问的后果作为输出。 TDengine 反对通过 C/C++ 语言来定义 UDF。TDengine 3.0 优化了相干机制，所以本文形容的个性实用于 3.0 及以上版本。 基本概念用户能够通过 UDF 实现两类函数：标量函数和聚合函数。标量函数对每行数据输入一个值，如求绝对值 abs，正弦函数 sin，字符串拼接函数 concat 等。聚合函数对多行数据进行输入一个值，如求平均数 avg，最大值 max 等。 实现 UDF 时，须要实现规定的接口函数 标量函数须要实现标量接口函数 scalarfn聚合函数须要实现聚合接口函数 aggfn_start、aggfn、aggfn_finish如果须要初始化，实现 udf_init；如果须要清理工作，实现 udf_destroy接口函数的名称是 UDF 名称，或者是 UDF 名称和特定后缀（_start, _finish, _init, _destroy)的连贯。列表中的scalarfn、aggfn、udf须要替换成udf函数名。 ...

小 T 导读：为了让大家更好地进行 TDengine 集群间的备份和迁徙工作，一款名为 taosdump 的工具应用程序被打造进去。在本篇文章中，咱们对 taosdump 的应用办法和注意事项进行了相干汇总，给到有须要的开发者。作为 TDengine 的一款工具应用程序，taosdump 反对从运行中的 TDengine 集群备份数据，并将备份的数据恢复到雷同或另一个运行中的 TDengine 集群中，其应用 Apache AVRO（https://avro.apache.org/）作为数据文件格式来存储备份数据。 值得一提的是，taosdump 能够用 Database、超级表或一般表作为逻辑数据单元进行备份，也能够对 Database、超级表和一般表中指定时间段内的数据记录进行备份。在应用时，咱们能够对 taosdump 指定数据备份的目录门路；如果不指定地位，它就会默认将数据备份到当前目录；如果指定的地位曾经有数据文件，taosdump 会提醒用户并立刻退出，防止数据被笼罩。这意味着同一门路只能被用于一次备份。如果大家看到相干提醒，务必小心操作。 但须要留神的是，taosdump 是一个逻辑备份工具，它不应被用于备份任何原始数据、环境设置、 硬件信息、服务端配置或集群的拓扑构造。 装置taosdump 有以下两种装置形式： 装置 taosTools 官网安装包，你能够进入 https://www.taosdata.com/all-... 此页面找到 taosTools 并进行下载安装。独自编译 taosTools 并装置，详情请参考 taos-tools 仓库（https://github.com/taosdata/t...）。罕用应用场景taosdump 备份数据备份所有数据库：指定 -A 或 --all-databases 参数；备份多个指定数据库：应用 -D db1,db2,... 参数；备份指定数据库中的某些超级表或一般表：应用 dbname stbname1 stbname2 tbname1 tbname2 ... 参数，留神这种输出序列第一个参数为数据库名称，且只反对一个数据库，第二个和之后的参数为该数据库中的超级表或一般表名称，两头以空格分隔；备份零碎 log 库：TDengine 集群通常会蕴含一个零碎数据库，名为 log，这个数据库内的数据为 TDengine 自我运行的数据，taosdump 默认不会对 log 库进行备份。如果有特定需要对 log 库进行备份，能够应用 -a 或 --allow-sys 命令行参数。“宽容”模式备份：taosdump 1.4.1 之后的版本提供 -n 参数和 -L 参数，用于备份数据时不应用转义字符和“宽容”模式，能够在表名、列名、标签名没应用转义字符的状况下缩小备份数据工夫和备份数据占用空间。如果不确定是否合乎应用 -n 和 -L 条件时，请应用默认参数进行“严格”模式进行备份。转义字符的阐明请参考官网文档（https://docs.taosdata.com/tao...）。须要留神taosdump 1.4.1 之后的版本提供 -I 参数，用于解析 avro 文件 schema 和数据，如果指定 -s 参数将只解析 schema。taosdump 1.4.2 之后的备份应用 -B 参数指定的批次数，默认值为 16384，如果在某些环境下因为网络速度或磁盘性能有余导致 “Error actual dump .. batch ..” ，能够通过 -B 参数调整为更小的值进行尝试。taosdump 的导出不反对中断复原，所以当过程意外终止后，正确的解决形式是删除以后已导出或生成的所有相干文件。taosdump 的导入反对中断复原，然而当过程重新启动时，会收到一些“表曾经存在”的提醒，能够漠视。taosdump 复原数据如果咱们想要复原指定门路下的数据文件，形式是：应用 -i 参数加上数据文件所在门路。如前文提及，咱们不能应用同一个目录备份不同数据汇合，也不能在同一门路屡次备份同一数据集，否则备份数据会造成笼罩或屡次备份。 ...

小 T 导读：taosAdapter 是 TDengine 这款时序数据库（Time Series Database）的配套工具，是 TDengine 集群和应用程序之间的桥梁和适配器。当咱们须要从数据收集代理软件（如 Telegraf、StatsD、collectd 等）摄取数据时，应用 taosAdapter 能让这一操作变得更加高效。此外，它还提供了 InfluxDB/OpenTSDB 兼容的数据摄取接口，容许 InfluxDB/OpenTSDB 应用程序无缝移植到 TDengine。本文将整体介绍一下 taosAdapter，不便大家应用。taosAdapter 次要提供以下性能： RESTful 接口兼容 InfluxDB v1 写接口兼容 OpenTSDB JSON 和 telnet 格局写入无缝连贯到 Telegraf无缝连贯到 collectd无缝连贯到 StatsD反对 Prometheus remote_read 和 remote_writetaosAdapter 架构图 taosAdapter 部署办法装置 taosAdapter有两种装置形式，你能够抉择进入涛思数据官网（https://www.taosdata.com/）下载 TDengine server 安装包，无需任何额定操作即可装置好 taosAdapter。 这种形式下，如果你须要将 taosAdapter 拆散部署在 TDengine server 之外的服务器上，则应该在该服务器上安装残缺的 TDengine 来装置 taosAdapter。除此之外，你还能够抉择应用源代码编译生成 taosAdapter，具体可参考如下文档（https://github.com/taosdata/t...）。 启动/进行 taosAdapter在 Linux 零碎上 taosAdapter 服务默认由 systemd 治理，应用命令 systemctl start taosadapter 能够启动 taosAdapter 服务，应用命令 systemctl stop taosadapter 能够进行 taosAdapter 服务。 ...

在车联网场景中，智能车辆会通过各类传感器定时采集车身状态信息，比方行驶速度、发动机转速、轮胎压力值、里程数等，此外，还会由某个事件触发产生车辆事件数据，比方门锁上防、撤防、车辆碰撞、异样挪动等，在每次上报数据时都会带有工夫戳，这是十分典型的时序数据场景。在这类场景下，高写入、高压缩率、疾速查问是对于数据处理最根本的要求。 但始终以来，在应答车联网场景下时序数据的存储时，企业大多抉择的都是 MongoDB 或 Apache HBase，这两大数据库技术绝对更加成熟，在业务规模尚未扩张之前，因为设施不多、数据量不大，加上查问场景繁多，尚且能够满足业务需要。随着业务的减速扩张，写入速度太慢、撑持老本过低等问题也逐步浮现。本文将会从四个典型的车联网案例登程，给到你数据架构降级思路。 TDengine x 大疆车载“在大疆车载以后的云端平台中，TDengine 的利用不仅节约了存储老本和开发学习老本，同时也体现出了很好的写入读取性能，满足了智能驾驶云端平台海量时序数据的解决需要。在查问方面，不论是抉择特定数据的查问还是轻量的查问，都是毫秒级返回数据。”业务背景因为以后的智能驾驶业务还是新的业务场景，所以大疆车载在选型上的历史累赘绝对较轻。在数据库选型要求上，从业务需要登程，次要聚焦在两点：首先，联合当下的业务场景，须要满足单台车辆的高频音讯上报频率；其次，反对在数据量大的时候，通过聚合函数，或选择函数来疾速筛选出须要的数据。此外，对数据库要求反对集群部署的同时，也要求更低的查问语句编写上手难度；而且需反对单表千万量级，在海量数据并发场景下，须要有较高的统计报表能力和较好的查问 SQL 效率。 架构图 点击案例查看更多技术细节 TDengine x 蔚来汽车能源“在实际效果上，革新实现后，查问速度晋升显著，从应用 HBase 查问单设施 24 小时数据的秒级返回，到应用 TDengine 查问查问雷同数据的毫秒级返回；每天增量数据占用的存储空间相当于原来应用 HBase 时的 50%；集群计算资源老本相比应用 HBase 节俭超过 60%。”业务背景为了给用户提供更好的补能体验，蔚来能源在加电基础设施上进行了大量的投入，须要对设施进行更高效的治理——将设施采集数据上报至云端进行存储，并提供实时数据查问、历史数据查问等业务服务，用来做设施监控和剖析。在业务诞生之初，其用作数据存储的选型是 MySQL + HBase，MySQL 存储设备最新实时数据，HBase 存储设备原始数据。随着换电站和超充站等设施在全国的疾速布局，设施数量持续增长，积攒的数据量越来越多，长时间跨度数据查问效率呈现瓶颈，再加上查问场景不断丰富，HBase 曾经无奈满足以后业务须要（具体痛点问题见下方案例链接）。 测试论断采纳批量写入数据形式，调整适合的单批次数据量大小，应用单机部署（8 核 32 GB，500 GB 存储）默认配置的 TDengine 服务，RESTful API写入形式，在 4k 并发流量下写入没有问题，同时生产积压数据时峰值达到 7 k/s，因为单条音讯蕴含信息量太大，理论解决中会拆分为 30 条写入 TDengine，所以理论写入 QPS 为 210 k/s，比满足同样数据流量的 HBase 集群规模要小不少，能够节省成本，再加上 TDengine 自身部署不依赖其余三方软件，也能够同时节俭运维老本。 架构图 点击案例查看更多技术细节 TDengine x 零跑汽车“在利用 TDengine 后，不必再像 MongoDB 一样，在查问前须要依据业务加工出需要数据；入库性能高，解决了以前HBase入库不及时的问题，能够用更少的服务器资源入库更多的数据，节俭更多老本。同时，TDengine高压缩的算法能晋升 10 到 20 倍的压缩性能，升高了存储压力和老本。”业务背景始终以来，在数据存储上零跑汽车的抉择都是 MongoDB 和 HBase，然而随着业务的减速扩张，写入速度太慢、撑持老本过低等问题也逐步浮现（具体痛点问题见下方案例链接）。从降本增效的角度思考，零跑决定在 C11 新车型上试用下其余的数据库，在剖析数据特点后，最终确定采纳时序数据库（Time-Series Database）。 ...

小 T 导读：TDengine 3.0 引入了全新的流式计算引擎，既反对工夫驱动的流式计算，也反对事件驱动的流式计算。本文将对新的流式计算引擎的语法规定进行具体介绍，不便开发者及企业应用。 TDengine 是一款开源、云原生的时序数据库（Time Series Database，TSDB），专为物联网、工业互联网、金融、IT 运维监控等场景设计并优化。近期公布的 TDengine 3.0，全新的流式计算引擎是其一大亮点。 TDengine 3.0 的流式计算引擎提供了实时处理写入的数据流能力，应用 SQL 定义实时流变换，当数据被写入流的源表后，数据会被以定义的形式主动解决，并依据定义的触发模式向目标表推送后果。它提供了代替简单流解决零碎的轻量级解决方案，并可能在高吞吐的数据写入状况下，提供毫秒级的计算结果提早。 流式计算能够蕴含数据过滤，标量函数计算（含 UDF），以及窗口聚合（反对滑动窗口、会话窗口与状态窗口），能够以超级表、子表、一般表为源表，写入到目标超级表。在创立流时，目标超级表将被主动创立，随后新插入的数据会被流定义的形式解决并写入其中，通过 partition by 子句，能够以表名或标签划分 partition，不同的 partition 将写入到目标超级表的不同子表。 TDengine 的流式计算可能反对散布在多个 vnode 中的超级表聚合；还可能解决乱序数据的写入：它提供了 watermark 机制以度量容忍数据乱序的水平，并提供了 ignore expired 配置项以决定乱序数据的解决策略——抛弃或者从新计算。上面咱们就一起看一下 TDengine 中流式计算相干的 SQL 语法。 流式计算的创立、删除与展现创立CREATE STREAM [IF NOT EXISTS] stream_name [stream_options] INTO stb_name AS subquerystream_options: { TRIGGER [AT_ONCE | WINDOW_CLOSE | MAX_DELAY time] WATERMARK time}其中 subquery 是 select 一般查问语法的子集： subquery: SELECT select_list from_clause [WHERE condition] [PARTITION BY tag_list] [window_clause]反对会话窗口、状态窗口与滑动窗口，其中，会话窗口与状态窗口搭配超级表时必须与 partition by tbname 一起应用： ...

小 T 导读：作为一款业余的时序数据库（Time Series Database，TSDB），为满足用户在不同场景下的查问需要，TDengine 提供了丰盛的查问性能。除了一些次要的查问外，还包含多表聚合查问、降采样查问及间断查问，本文将从实际操作层面对这三种非凡查问进行解读。 查问数据次要查问性能TDengine 采纳 SQL 作为查询语言，应用程序能够通过 REST API 或连接器发送 SQL 语句，用户还能够通过 TDengine 命令行工具 taos 手动执行 SQL 即席查问（Ad-Hoc Query）。TDengine 反对如下查问性能： 单列、多列数据查问标签和数值的多种过滤条件：>, <, =, <>, like 等聚合后果的分组（Group by）、排序（Order by）、束缚输入（Limit/Offset）数值列及聚合后果的四则运算工夫戳对齐的连贯查问（Join Query: 隐式连贯）操作多种聚合/计算函数: count, max, min, avg, sum, twa, stddev, leastsquares, top, bottom, first, last, percentile, apercentile, last_row, spread, diff 等例如：在命令行工具 taos 中，咱们须要从表 d1001 中查问出 voltage > 215 的记录，按工夫降序排列，仅仅输入如下 2 条后果。 taos> select * from d1001 where voltage > 215 order by ts desc limit 2; ts | current | voltage | phase |====================================================================================== 2018-10-03 14:38:16.800 | 12.30000 | 221 | 0.31000 | 2018-10-03 14:38:15.000 | 12.60000 | 218 | 0.33000 |Query OK, 2 row(s) in set (0.001100s)为满足物联网场景的需要，TDengine 还反对几个非凡的函数，比方 twa(工夫加权均匀)、spread (最大值与最小值的差)、last_row(最初一条记录)等，将来还将有更多与物联网场景相干的函数增加进来。 ...

小 T 导读：车联网业务是中通科技配送全链路业务中十分重要的一环，在理论的我的项目需要中，须要实时查问车辆最新地位状态，达到车辆经营可视化治理。中智车联服务平台抉择了用 TDengine 来高效解决从车辆上实时采集的时序数据。 业务背景目前，中通科技领有一支千人规模的研发团队，在数字信息科技研发方面以“互联网+物流”的理念，自研的软件系统和数字化工具已达百余个，赋能笼罩快递业务全场景，同时为快运、国内、云仓、优选、金融、商业等生态圈业务提供全方位的研发反对，建设起欠缺的互联网产品研发体系，全场景、全链路的数字化、互联化和智能化的业务地图愈发成熟。 2021 年年底，中通快递已实现了总部园区的实景三维模型，通过接入园区内的在线传感器，依据现有园区各功能区的区位布局，基于此三维模型发展园区内生产规划、调度运行和保护治理的全过程利用，从而实现园区内人、车、物在精准运行、资源优化和配置服务中的全过程精益化治理。 随着生产设施的小型化和智能化，快递企业也将更快地进入空间地理信息数据生产畛域，有包裹流动的中央，就会有时空数据服务的需要。 这里先给大家介绍一下配送全链路业务，这是指包裹从商家仓进去始终到用户手上的这段派送履约链路，它蕴含 4 个次要的实操流程，别离是分拨实操、运输实操、站点实操和快递员实操。把 4 种实操治理放到三个零碎外面，这三个零碎别离是分拨治理、运输治理、末端站点实操治理。具体如下图所示。 其中车联网业务也是十分重要的一环，通过人、车、货、场全链条笼罩的车联网设施利用，实现物流运输全链路感知。在理论的我的项目需要中，咱们须要实时查问车辆最新地位状态，达到车辆经营可视化治理，也就是咱们的中智车联服务平台。 技术选型在上述业务过程中，咱们应用了 TDengine 来实现这个指标。 在选型时，咱们比照了 Prometheus 和 TDengine 这两款很有代表性的时序数据库（Time-Series Database）。 相对而言，TDengine 的“一个设施采集点一张表”的底层设计，自带的降采样和窗口函数的优良性能，都非常符合车辆网场景。其列式存储带来的压缩比也更好。所以咱们抉择了 TDengine。 技术架构咱们在每辆车上都装置了部标机（即卫星定位汽车行驶记录仪），来实时采集车辆的行驶速度、工夫、里程以及与车辆行驶相干的其余状态信息。采集到的数据，通过咱们的 IoT service 这层利用来解决。而后数据经由 MQ （音讯队列）层由 JDBC-RESTful 的形式写入 TDengine 集群，以供上游平台应用，而部标机产生的其余类数据则通过别的路径供上游平台应用。 咱们应用了三节点三正本的模式落地了 TDengine 集群。 建表很简略，咱们抉择了一类数据对应一张超级表，超级表下依据车牌号划分子表，表构造如下图所示。目前还是我的项目初期，所以只接入了 700 余辆车，后续会逐渐减少接入车辆。也正因为这套环境接入设施不多，写入方面并无压力，远远达不到 TDengine 的写入极限。 具体利用咱们要通过数据的变动来实时失去车辆的很多信息，比方是否有停留、超速、疾驶、离线等事件产生。有些性能能够通过 TDengine 的查问性能实现，有些不不便实现的临时通过利用来实现。 上面咱们通过几个例子来看看目前业务中应用比拟频繁的查问： 1.获取车辆的最新地位 SQL 语句如下。 select last_row(longitude,latitude),deviceId from ioc_gps.vehicle_location groupby deviceId where device_id = #{deviceId} and ts >= #{startTime} and ts <= #{endTime}业务须要疾速查问每辆车的最新坐标，这里用到了 TDengine 提供的 last_row 函数。除了查问独自某辆车，常常还会依据 groupId 或者一批 deviceId 去查问一批车辆的最新坐标。 ...

长期以来，工业软件畛域始终是传统国外软件的天下，PI 和 Wonderware 就是其中的佼佼者。近年来，随着国内软件代替浪潮和少量互联网技术向传统行业的技术溢出，这个市场正在开始产生微小的变动。 以工业时序数据库（Time Series Database，TSDB）畛域为例，已有多家大型工业企业将原来的 Wonderware InSQL/Historian 替换为新一代开源时序数据库 TDengine。到底是什么深层次的起因驱动着这个变动的产生？作为新一代的时序数据库产品，TDengine 具备哪些劣势？让咱们接下来做一些深刻的剖析。 实在代替案例某大型卷烟厂，通过引入 TDengine，重构了其挪动平台及 MES 现场操作站架构，重点打造了“一部手机管生产”，以买通企业外部不同层级、不同零碎之间的数据壁垒，实现对内撑持业务利用和管理决策、对外提供数据共享及服务能力。就具体成绩而言，他们打造了基于二维码的产品全生命周期零碎和品质危险预警系统。大大提高了零碎性能，升高了存储和计算成本，减速了其数字化过程。 某钢铁冶金企业的能源介质监控我的项目中，仅一期电力能源设施每天产生的数据量就在 3000 万条以上；我的项目二期还会有几千个流量设施接入，整个零碎数据点也将远超 50000 点，每天产生的数据量预估在 1 亿条左右。为了解决如此大数据量带来的数据存储挑战以及原计划性能有余的问题，他们应用了 TDengine，后果是获得了显著的成果，数据读写能力也失去了极大晋升。 传统工业时序数据处理利用现状对于工业生产中大量的典型时序数据，企业数字化的晚期，因海内软件有先发劣势，很多企业抉择了 Wonderware InTouch + InSQL/Historian 的解决方案。然而随着业务的倒退，生产中须要监测的指标从几万个减少到几十万甚至百万个以上，原有的时序数据库在扩大能力上遇到了瓶颈。 几个次要的挑战如下： 非国产化：在简单的国际形势下，存在一些不确定性封闭性：很多软件是闭源的，而且处于本人的关闭体系之下，扩展性差高度复杂度：须要洽购一系列产品组合高老本：洽购价格昂贵、性能扩大须要额定付费，依赖 Windows、SQL Server 等其他软件，会产生额定的洽购老本服务响应慢：国外产品广泛服务响应不及时，反馈常常以天为单位，服务保障性差新一代时序数据库 TDengine面对上述挑战，从多家企业的替换教训中，咱们能够看到 TDengine 时序数据库在晋升数据存取效率、突破传统数据孤岛、晋升数据无效利用率方面都为企业的数字化提供了实质性的帮忙。作为专为海量时序数据场景而设计研发的 TDengine，提供了如下外围性能： 1.云原生（Cloud Native）：时序数据与元数据处理全副采纳分布式技术，实现计算和存储拆散，具备程度扩大能力，存储和计算资源可动静扩容或缩容反对 10 亿个工夫线，反对 100 个以上节点，整个集群的启动速度能够管制在一分钟以内，齐全解决时序数据业内的 High Cardinality 的问题反对多正本，保证系统的高可用，另外通过 WAL 来保证数据存储的高牢靠反对容器和 Kubernetes 部署，具备欠缺的可观测性（Observability），让零碎的经营保护变的轻松简略2.极简时序数据平台（Simplified Solution）：反对音讯队列，而且对外提供的 API 与 Kafka 相似，无学习老本反对流式计算，除间断查问外，也反对事件驱动的流计算，采纳 SQL 语法，反对自定义函数，让流计算的学习老本简直为零反对缓存，每条工夫线的最新数据全副缓存，通过 SQL 函数就可疾速获取，无需再集成 Redis 等缓存软件通过对缓存、流式计算、音讯队列的反对，采纳 TDengine 的时序数据处理系统，不再须要集成Kafka、Redis、Spark 和 Flink 等软件，技术架构将大为简化，部署、经营保护老本将大为升高3.便捷的数据分析（Easy Data Analytics）：从新设计了计算引擎，反对规范 SQL，反对嵌套查问，反对自定义函数，反对 Information Schema 零碎数据库针对时序数据的解决进行扩大，提供了泛滥时序数据分析性能通过标签疾速索引，通过分区、分片技术，通过计算节点的弹性伸缩，反对对海量时序数据的多维度的高效聚合剖析TDengine 不仅能实时地解决数据的写入和查问，也能作为弱小的时序数据分析工具在不便部署，简化整体架构的同时，凭借其高性能、高压缩率，TDengine 还能够极大升高企业的总体领有老本。 ...

随着云原生时序数据库（Time Series Database，TSDB） TDengine 3.0 的公布，很多用户其实会好奇：“和 2.0 比起来，3.0 有哪些直观的优化呢？” 本文将以 Update 这一性能的变动为例，具体介绍一下 3.0 的粗疏优化。 和 2.0 比起来，3.0 版本的 Update 不再须要参数配置，“局部列更新”成为数据库自身的个性，并且还解决了 2.0 的 Update 机制的一些有余。 一、2.0 时代的 Update:对于 TDengine 的 Update 性能，老用户应该都比较清楚： 在 2.0 版本中，TDengine 通过对 database 级别参数值 “update” 的配置，来实现对雷同工夫戳行的数据更新。 update 为 0 ，不更新；update 为 1 ，整行更新，未指定值的列会被更新为 NULL；update 为 2，局部列更新，未指定值或者写入 NULL 的列会保留原有值。一开始，TDengine 只反对 update 为 1 （即整行更新）。但在很多场景下，用户往往不会在同一时间更新一张表中的所有列，因而咱们后续又反对了 update 为 2（即局部列更新）。 显然，局部列更新更为灵便，因为它既能够做到整行更新，又能够做到部分更新。然而通过它的逻辑，咱们或者会有这样的疑难：如果我想把一个值更新为 NULL 值，应该怎么办呢？这个疑难是有情理的。不过 2.0 版本并不反对这样的更新。 在 2.0 的版本中，数据能够被分为两大类 NORMAL 和 NULL 。 NORMAL 类代表 TDengine 所有数据类型中的非空值字面量，而 NULL 则代表所有数据类型的空值字面量。 ...

小 T 导读：为应答不同场景下的写入需要，TDengine 共提供了四种写入协定，其中最罕用的当属 SQL 写入了，为了让大家在理论写入操作时更加不便，咱们整顿了一篇具体解读 SQL INSERT 语法规定的文章。倡议提前珍藏，有须要时可随时参考。 在诸多时序数据库（Time Series Database）中，如果能反对 SQL，则能够大大降低用户的学习和接入老本，而 TDengine 正是这样一款产品。 TDengine SQL 是供应用户进行数据写入和查问的次要工具。为了便于用户疾速上手，它在肯定水平上与规范 SQL 格调和模式相似。因为 TDengine 的晚期版本没有提供时序数据的删除性能，因而其 SQL 语法也没有提供数据删除的相干性能。不过从 TDengine 企业版从 2.6 开始提供了 DELETE 语句。 为更好地阐明 SQL 语法的规定及其特点，本文假如存在一个数据集。以智能电表（meters）为例，假如每个智能电表采集电流、电压和相位三个量。其建模如下： taos> DESCRIBE meters; Field | Type | Length | Note |================================================================================= ts | TIMESTAMP | 8 | | current | FLOAT | 4 | | voltage | INT | 4 | | phase | FLOAT | 4 | | location | BINARY | 64 | TAG | groupid | INT | 4 | TAG |创立超级表和字表的语句可参考 TDengine 官网的官网文档。 ...

小 T 导读：家喻户晓，TDengine 反对多种写入协定，包含 SQL、InfluxDB Line 协定、OpenTSDB Telnet 协定、OpenTSDB JSON 格局协定。但说到如何进行写入操作，很多读者可能都是一头雾水，本篇文章为大家汇总了一系列的写入教程，不便有须要的开发者作为写入指南珍藏应用。 TDengine 中的 SQL 写入即模式化写入，在写入到 Database 之前，须要事后定义好数据表的 Schema 模式，具体来说就是数据表蕴含多少列，每列寄存的数据类型是什么。即在建表时应用规范的 SQL 语句指定表的 Schema，再遵循事后建好的列跟标签值的数量和类型进行数据写入。 除了 SQL 写入外， TDengine 还反对三种无模式写入协定，别离是 InfluxDB Line 协定、OpenTSDB Telnet 协定和 OpenTSDB JSON 格局协定。如果你对 NoSQL 比拟相熟，那对无模式写入应该就不会生疏了。艰深来讲，无模式写入为用户提供了一种以文本格式将数据写入到 TDengine 的形式，更加便捷。 物联网场景中的利用常常须要采集比拟多的数据项，用于实现智能管制、业务剖析和设施监控等，因为应用逻辑的版本升级，或者设施本身的硬件调整等起因，数据采集项有可能比拟频繁地呈现变动，为了在这种状况下仍能不便地实现数据记录工作，TDengine 从 2.2 版本开始就提供了无模式写入形式，写入时无需提前创立超级表和子表，其引擎能自适应数据并对表构造进行调整。 在应用 TDengine 写入数据时，数据能够单条插入，也能够批量插入，能够插入一个数据采集点的数据，也能够同时插入多个数据采集点的数据。此外，TDengine 不仅反对多线程插入、工夫乱序数据插入，也反对历史数据插入。上面将对四种写入协定进行阐明，以供参考。 SQL 写入用户能够让利用通过连接器执行 INSERT 语句来插入数据，还能够通过 TAOS Shell，手动输出 INSERT 语句来实现。 一次写入一条上面这条 INSERT 就将一条记录写入到表 d1001 中： INSERT INTO d1001 VALUES (1538548685000, 10.3, 219, 0.31);一次写入多条TDengine 反对一次写入多条记录，比方上面这条命令就将两条记录写入到表 d1001 中： ...

在 8 月 13 日的 TDengine 开发者大会上，TDengine 计算引擎架构师廖浩均带来题为《TDengine 3.0——全新计算查问引擎的设计》的主题演讲，具体论述了 TDengine 3.0 计算查问引擎技术的优化与降级。本文依据此演讲整顿而成。点击【这里】查看残缺演讲视频 3.0 中的查问引擎在 2.0 版本的根底上进行了重写，在承继 2.0 查问引擎既有劣势和技术个性的根底上，在工程实现和整体架构设计上有了极大的改善和晋升。 总体来讲，TDengine 3.0 大幅加强了对 SQL 语义的反对、欠缺了 SQL 查问语法；强化了整体执行框架及 SQL 查问的调度能力；提供更好的执行工作隔离机制，对于谬误具备更好的容忍度；提供反对存算拆散架构的能力。它次要蕴含以下几个方面的特点： 1.反对规范 SQL 查问语法 全新的 SQL 解析器、打算生成及优化器，引入伪列 (_wstart/_wend/_qstart/_qend/_rowts) 等语法概念和新的（分组）关键词，全面加强查问语法。打消 2.x 版本中对时序数据查问施加的诸多限度，能够像应用关系对象数据库查问引擎一样应用 SQL 查问语法。反对标签/一般列的运算，标量函数和矢量函数的嵌套、任意字段（列）的分组/排序/聚合、无限度的多级子查问。2.反对存算拆散架构 反对存算拆散的体系架构，反对集群内计算节点动静、疾速、弹性部署。查问引擎可能将查问按需调度到计算节点，无效升高存储节点（Vnode）计算资源的压力。原生的流批一体化查询处理TDengine 3.0 原生反对流计算和交互式查问。流计算引擎也应用 SQL 语言作为交互路径，因而，流计算引擎间接应用查问框架的 SQL 解析解决、执行打算生成、查问执行算子、用户利用交互等诸多方面的能力。3.更优良的鲁棒性和韧性设计 为防止用户谬误导致的主服务宕机，用户定义函数的执行服务（UDFD）与 TDengine 的主过程进行隔离，UDFD 能够在解体当前主动被从新拉起。对于 SQL 查问转化为调度器的查问工作（Job），Job 在被合成当前会按层级调度执行，并且同档次工作互相独立执行，单个工作失败当前能够从新拉起进行解决。对于不同分层的工作（Task），失败工作能够从上游工作的后果缓存（Sink Node）中再次申请数据并尝试从新执行。4.更好的执行可观测性 将查问打算、执行开销、查问中 Task 的动静执行状态等相干信息通过命令行交互界面（CLI）出现给用户，助力用户定位查问执行的瓶颈，并进行针对性的优化解决。提供 Explain 指令，用户能够通过 Explain 取得查问执行的打算、各算子执行开销等信息，为用户层面 SQL 改写和优化性能提供反对。通过心跳信息，将服务端执行状态推送到调度器，并反馈给用户，让用户更好确定查问执行的状态。5.反对数据集快照查问 全面内置版本化的查问反对能力，能够为事件驱动流计算引擎提供指定版本和工夫范畴的历史数据追溯查问。为双（多）活集群提供数据同步版本化读取能力。查问引擎架构设计 上图是 TDengine 3.0 的查问引擎架构，右边的 Query Wrapper 运行在 Vnode 和 Qnode 上，它外面蕴含了一个执行器，其中的 Index 模块是解决 Vnode 中存储的标签数据的索引。执行器自身并不解决与调度器的交互行为，Query Wrapper 负责解决执行 Task 动作并将后果缓存在 Sink Node；此外，执行器会调用 function 模块和 ScalarFunc 模块进行计算解决，并在必要的状况下通过 function 模块调用 UDF 服务。 ...

小 T 导读：8 月 13 日，涛思数据举办了成立 5 年来的第一次 TDengine 开发者大会，重磅公布了 TDengine 3.0，一款真正云原生的时序数据库（Time Series Database，TSDB）。援用明势资本是涛思数据最早的投资方。咱们邀请到明势资本开创合伙人黄明明加入此次大会，并做主题演讲——《翻新与世界：下一代根底软件的中国解围之路》。本文为演讲内容实录。” 非常感谢陶总邀请加入 TDengine 开发者大会，在座的各位很多都是行业里的技术专家，我就抛砖引玉地分享一下明势资本的一些观点。 可能一些理解明势资本的敌人晓得，明势资本是中国最早开始投资硬科技的投资机构之一。在新能源和智能电动车畛域，明势是现实汽车、小牛电动的第一个投资人；在机器人畛域，明势是云鲸扫拖机器人，镁伽合作机器人这些“独角兽”公司的第一个投资人；在先进制作畛域，明势也投资了像德速机械、橙子自动化、李群自动化等一批十分优良的公司。 因为明势资本成立以来投资了很多“硬”科技我的项目，所以会很多同行会问，你们是怎么开始关注根底软件这个畛域的？在答复这个问题之前，我想先向在场的各位提出一个问题：明天这个世界上最优良的制造业企业是哪家？ 我预计很多人心里的答案会是 3C 行业中华为、苹果、三星这样的企业，这些毫无疑问都是世界上很优良的企业，然而我的答案是一家堪称恐怖的超级制作企业——特斯拉。 兴许很多人讲到特斯拉，认为它只是一家电动车公司，也有人感觉特斯拉是一家机器人公司，还有人更进一步，感觉它是一家人工智能公司。然而，用马斯克的本人的话来讲，特斯拉最强的劣势是——它是一家超级制作企业。 为什么说特斯拉是一家超级制作企业？因为它第一次把整个在主动驾驶上的这一套“感知-学习-自动化”的框架利用到了人类的生产制作的环节。 我跟现实汽车创始人李想交换时，他说，“特斯拉可能是人类历史上第一家不仅把大量的 R&D 投入在产品的研发上，同样把大量的 R&D 投入到整个生产制作流程上的科技公司。所以它能够做到单工位的实时纠正，产线优化、产品设计和产线制作环节的全链路买通。在特斯拉他们称为 Manufacturing Development Program，就是把你的设计-研发-生产制作环节全副买通。 相熟特斯拉的人可能都晓得，你这个月买的 Model 3 和两个月后买的同款 Model 3 曾经不是同样的 Model 3。软件就不必提了，特斯拉是实时在线降级的。它外面用的生产制作工艺，甚至外围零部件通通处在继续的优化过程中。 智能电动车是继智能手机和挪动互联网之后一个最大的结构性机会，这一点曾经成为共识，寰球很多优良的科技企业都涌入到这个畛域。我就举最简略粗犷的一个指标——单车毛利率——来阐明特斯拉作为一家超级制作企业的劣势。 就明天国内的造车企业来说，单车毛利做得最好的是咱们明势投资的现实汽车，能够做到略超过 20%。然而特斯拉能够把一台二十多万的车做到 30% 的毛利，这是十分恐怖的。 如果各位理解一下智能电动车的整车老本的组成的话，晓得这是一个简直不可能实现的工作。甚至大家耳熟能详的一些国内卖的不错并且曾经有了肯定规模劣势的电动车，它单车的毛利甚至是负的。这些车不是 PPT 造车，这些车曾经是在大街小巷跑的车，也就说一台车从出厂那一天起曾经是亏损的，再加上摊分的生产、研发、营销的费用，亏损金额会继续放大。 可能把单台车的效率做到极致，这是特斯拉的软件定义制作，是寰球制造业将来倒退的必然趋势，所以任何中国优良的制造业企业，咱们认为都是要向特斯拉去深刻学习。 其实软件定义制作说起来也不是什么新的话题。最优良的 ERP 的第一代鼻祖是谁？是 SAP。SAP 来自哪里？德国。咱们始终认为美国的软件是全世界最发达的，为什么不是美国？因为在上世纪七八十年代，全世界最优良的制造业企业还是传统的汽车工业，而德国领有全世界最优良的汽车制作企业，所以他们能催生出那个时代最优良的根底软件。 咱们明势认为，软件其实是社会生产力倒退的一个体现，只有领有了那个时代的世界级的企业，能力催生出那个时代世界级的软件公司，这个不是说工程师有多聪慧，就可能高山拔楼做起来的事件。 再看明天咱们的中国，随着中国新一代制造业的崛起，中国也有机会催生出下一代的根底软件公司。 第一，中国的制造业企业产值宏大，曾经超过了欧美。就拿电动汽车上游产业链中的新能源电池来说，明天寰球最大的新能源电池企业是宁德时代，占据了寰球市场份额的 34%，也就是说寰球每三辆电动车中就有一辆配套了宁德时代的电池。 第二，数据规模宏大，而且正在继续井喷。 第三，互联网背景浓烈，对信息化、数字化“后发先至”。 比如说现实汽车的创始人李想，之前在互联网的守业经验让他从开办现实的第一天起，头脑里就根植了用数据驱动来解决问题的理念。这也是咱们明势最看重的新一代的制造业企业的新范式。 就像能源产业环境变动催生了特斯拉、现实等新兴势力一样，IT 产业环境变动也必将催生新的根底软件。 企业数据规模激增，中心化架构不堪重负。企业业务在线化，数据处理时效性要求大大晋升。IT 人工成本逐年晋升，全托管的价值日渐浮现。IT 基础设施上云，在云上解决数据成为必然。云化是软件定义制作一个十分大的驱动力，咱们投资的其余一些根底软件公司，包含 PingCAP、 StarRocks，他们的创始人去硅谷回来当前都跟我说了一个雷同的领会：明天如果咱们的根底软件不上云，不能提供分布式的云端服务，是无奈跟寰球市场的用户交换的。利用架构往弹性化发展，数据平台也须要相应的变动。开源重塑产品迭代模式与市场推广模式。我本人是学电子工程出身的，咱们 90 年代毕业的时候如果能用好根底软件或者数据库软件，就曾经很牛了，素来没有想到中国人可能写出本人的下一代的根底软件。 ...

在 8 月 13 日的 TDengine 开发者大会上，TDengine 存储引擎架构师程洪泽带来题为《TDengine 的存储引擎降级之路——从 1.0 到 3.0》的主题演讲，具体论述了 TDengine 3.0 存储引擎的技术优化与降级。本文依据此演讲整顿而成。 点击【这里】查看残缺演讲视频 相比前两个版本，3.0 的存储引擎更重视各种场景下的存储和查问效率，不仅要对治理节点进一步“减负”，提供高效正当的更新、删除性能，反对数据备份、流式解决等性能，还要思考到数据维度收缩下的高效解决、多表场景下的开机启动速度、正当高效且精确地应用系统资源等需要。 TDengine 3.0 存储引擎的更新能够分为三大块，首先是 TQ，基于 WAL 的音讯队列；其次是 META，基于 TDB 的元数据存储引擎；第三是 TSDB（Time Series Database），用来存储时序数据的类 LSM 存储引擎（TSDB SE）。 音讯队列存储引擎 在 1.0 和 2.0 时咱们提供了一个基于 TSDB 存储的间断查问性能，过后的想法是用它来代替流式解决。工作流程能够概括为：App 定时发查问工作上来，查问引擎执行查问，TSDB 返回后果给查问引擎，查问引擎再把后果返回给 App。 这一性能的长处是能够复用查问引擎，简略易开发，但毛病也很显著，不仅会呈现计算实时性差、查问压力大导致算力节约的状况，更重要的是乱序问题无奈解决。数据在进入 TSDB 之后都会依照工夫戳进行排序，一个乱序的数据进来后插到后面，TSDB 是无奈推出这条数据的，这就会导致乱序问题的呈现；另外因为查问引擎是复用的，TSDB 的查问引擎也不会对新的乱序数据进行解决、对后果进行更改校验。 从这一技术背景登程，TDengine 3.0 中须要设计一个存储引擎来反对音讯队列和流式计算。这个存储引擎能通知咱们什么样的数据是增量数据，这样一来，流式计算只需解决增量数据就好了，其余的数据就不必管了。 此外这个存储引擎须要构建在一个 Pipe 之上，保证数据进入和进来的前后程序统一。在设计时，咱们发现 TDengine 的 WAL 其实就是一个人造的 Pipe。于是咱们在 WAL 之上加了一层索引，并进行大量的适配开发，实现了 TQ 存储引擎。 如果大家深入研究过 TDengine 的模型，就会发现它的架构模型和 Kafka 的很多设计都是绝对应的，超级表和 Kafka 的 Topic 类似、Vnode 跟 Kafka 中的 Partition 也很靠近，子表的表名跟 Kafka 中的 Event Key 对应，因而这个架构设计人造地就带有音讯队列的特点，从这点登程，TDengine 3.0 想要实现一个音讯队列是非常容易的。 ...

在 8 月 13 日的 TDengine 开发者大会上，TDengine 分布式系统架构师关胜亮带来题为《反对 10 亿工夫线、100 个节点的 TDengine 分布式系统架构设计》的主题演讲，具体论述了 TDengine 3.0 新的架构设计思路。本文依据此演讲整顿而成。在物联网大数据时代，随着企业业务的一直扩张，须要采集的设施数量急剧回升，通常要达到百万甚至千万的级别，采集频率也从以前的 15 分钟一个点逐步演变到当初的 1 分钟、30 秒、15 秒，甚至 1 秒的一个点，这么多数据还要源源不断地发往云端，如何进行更好地写入、存储及查问，成为企业亟待解决的难题。 在测点数暴涨、数据采集频次一直进步的大数据时代，传统实时数据库暴露出下列问题： 没有程度扩大能力，如果数据量减少，只能依附硬件 scale up技术架构古老，应用磁盘阵列，大多运行在 Windows 环境下数据分析能力偏弱，不反对当初风行的各种大数据分析接口不反对云端部署，更无奈反对 PaaS在此背景下，依附 Hadoop 架构造成的一系列通用数据存储解决方案，成为一众企业的首选，为了可能适配更多的业务场景，还要集成如 Kafka、Redis、Spark 等泛滥第三方开源软件，在一次次的实际中，也暴露出诸多问题，如开发效率低、运行效率差、运维简单以及利用推向市场慢等。 在此基础上，时序数据库（Time Series Database）应运而生了。尽管新兴的时序数据库之间竞争强烈，但因为业务场景的复杂性和数据的多样性，还没有哪一款产品真正成为物联网场景的领跑者，而大部分产品还都存在以下三点难以漠视的问题： 性能繁多，须要集成其他软件，晋升零碎负重及运维难度不是规范 SQL，学习老本高没有实现真正的云原生化，程度扩大能力无限在调研了数百个业务场景的根底上，TDengine 实现了 3.0 版本的迭代，集群反对 10 亿条以上的工夫线、100 台服务器节点，成为一款真正的云原生时序数据库，具备极强的弹性伸缩能力，且无需再集成 Kafka、Redis、Spark、Flink 等软件，能够大幅升高零碎架构的复杂度。 TDengine 分布式系统架构设计 如上图所示，在数据节点（Dnode）、虚构节点（Vnode）、治理节点（Mnode）之上，TDengine 3.0 集群新增了弹性计算节点（Qnode）和流计算节点（Snode）。其中 Qnode 次要在运行查问计算工作中起作用，当一个查问执行时，依赖执行打算，调度器会安顿一个或多个 Qnode；Snode 次要负责运行流计算工作，能够同时执行多个。 针对数据库级别的元数据管理，3.0 版本通过两阶段提交来保障要害操作的一致性，以上图为例，假如咱们要创立一张超级表，零碎首先会把 SQL 语句先解析成申请发给 Mnode，之后 Mnode 会把这个申请发给各个不同的 Vnode（ Vnode1 和 Vnode2），最初咱们会等这些申请都完结之后再做一个长久化，而后把它返回给客户。 ...

在 8 月 13 日的 TDengine 开发者大会上，涛思数据创始人陶建辉进行了题为《高性能、云原生的极简时序数据处理平台》的主题演讲。在本次演讲中，他不仅分享了时序数据库现阶段的技术痛点，还深刻阐释了打造 TDengine 3.0 的起因以及实际思路。本文依据演讲内容整顿而成。 在 2017 年刚开始做时序数据库（Time Series Database，TSDB）时，学物理的我想当然地认为做好数据库没有大家说的那么难，但做了 5 年后才发现，这真的不是一件很容易的事。上面我具体说说难在哪里： 程度扩展性（Scalability）问题。在 TDengine 刚开发没多久时，我用一台 128 核的机器对 TDengine 进行了测试，后果性能远远没有达到预期，这件事件也让我分明地意识到，现实的程度扩大能力很难实现。没有真正的云原生化。我集体特地深信云是将来，数据库也肯定要走向云原生（Cloud Native），但在深度钻研市面上的数据库产品后，我发现大部分数据库都不是云原生，而仅仅是“云就绪”（Cloud Ready），即数据库服务提供商在转售云平台。真正的云原生数据库应该具备存算拆散、计算和存储能力弹性扩张、可能在云上部署、自动化部署等特点。复杂性（Complex）问题。2016 年我看到很多人在解决一些简略的时序数据时，要把整个 Hadoop 零碎搬过去，要加 HBase 层，还要把 Flink、Spark 等等全副加上，这对于研发人员来讲就是个劫难。但时至今日，这个复杂性也并没有随着时序数据库的倒退失去充沛的解决，只有打造一个集 Kafka、Flink、Spark、Redis 等第三方工具性能于一体的极简时序数据处理平台，这一问题才无望充沛解决。数据分析能力跟不上。诸如 InfluxDB、Prometheus 等较为风行的 Time-Series Database，因为不反对 SQL，导致很多失常的数据服务、数据仓库的分析方法都用不上。联合我过往一直跨界的教训，我发现了这个问题，所以 TDengine 早就反对了 SQL，不过依然须要优化和增强。发现并解决上述的问题，便是咱们打造 TDengine 3.0 的初衷。从去年 6 月开始，在 40 多个研发一年多的致力下，TDengine 3.0 终于在明天正式和大家见面了。 上面咱们就一起看看 TDengine 3.0 是什么样子的。 云原生时序数据库程度扩大TDengine 的新分布式架构 打造云原生时序数据库，第一个因素就是必须是分布式架构。其实 TDengine 以前也是分布式架构，但为了实现云原生的种种个性，咱们在此架构根底上引入了一个新的节点——计算节点 Qnode。 通过云原生如何解决可扩展性问题？还是通过分片分区来解决，数据切分的办法咱们没有做太多改变，TDengine 一开始就是这么做的，在时间轴上以天或周为单位对数据进行切分，同时将定量设施的数据调配给每个区（Vnode）进行解决。 跟 2.x 相比，3.0 最大的不同就是元数据的治理也变成了齐全分布式的。这也是我在此前版本中汲取了一个教训而做出的扭转，最开始我没想到元数据的治理如此之难。 ...

小 T 导读：为了更好地反对阳光氢能 PEM 绿电制氢零碎，本文作者所在的部门须要寻找一套满足业务和性能需求、而且具备国产知识产权的时序数据库，来代替本来应用的 InfluxDB。本文分享了他们将 InfluxDB 替换为 TDengine 的具体起因，以及相干的实际思路。 企业简介阳光电源成立于 1997 年，专一于逆变器的自主研发与制作。通过二十多年的技术积攒，团体逐步确立在光伏逆变器畛域的龙头位置，打造了风、光、储、氢的新能源残缺格局，做到传统业务和翻新业务并行不悖、协同倒退。 我的项目介绍在碳中和这个大背景下，氢能是新能源畛域中与油气行业现有业务联合最严密的一类，也是帮忙油气行业早日实现碳达峰、碳中和的最佳门路之一。2022 年 7 月 16 日，阳光氢能 200Nm³/h PEM 绿电制氢零碎启运发货。该套零碎采纳国内当先的 PEM 电解水制氢技术和 IGBT 制氢电源，工艺简单，波及多项国内专利技术。为了更好地监测整体生产流程数据，咱们须要寻找一套满足业务和性能需求，而且具备国产知识产权的时序数据库（Time Series Database），以响应国家信创号召。 时序数据库选型之 InfluxDB vs TDengine在 InfluxDB 和 TDengine 之间，之所以抉择 TDengine ，其实我很早之前就写过一篇文章，题目是《从 InfluxDB 到 TDengine，咱们为什么会做出这个抉择》，在其中表述的比较清楚了。这里能够再简略总结一下： 第一，TDengine 超级表和一般表的概念十分符合咱们我的项目的业务场景。此前咱们的我的项目是一个站点一个单元对应多个测点，当初利用超级表-一般表的模型，业务模型会更加清晰。 第二，查问更具备劣势。在应用老版 InfluxDB 的历史数据查问性能时，只有操作略微频繁一点（比方抉择一个时间段之后，曲线很久还没有渲染进去，又去换了一个时间段），就会导致页面卡死，取不到数据，这时候须要重启浏览器，极度影响客户体验。 然而在应用 TDengine 之后，不论是大批量拉取范畴数据，还是应用函数计算，查问再也没有呈现过浏览器卡死的状况。TDengine 拉取单设施大范畴工夫数据查问的 SQL 以及耗时状况，如以下截图如下： 不得不说，这些查问的性能都非常杰出，齐全满足咱们的利用场景。 第三，搭建集群的老本更低廉。家喻户晓，InfluxDB 集群性能是闭源的，如果后续业务倒退须要用到集群时会带来很大的不便。然而 TDengine 的集群性能是开源的，且扩大不便，因而能够显著升高运维老本。 最初，从用户反对的角度来说，选用国外的 Database 有很大的不确定性，但在应用 TDengine 时如果须要反对，就能够间接通过微信/邮箱等工具随时和技术人员进行交换，更加无效不便。如果对产品性能性能、业务保障要求高的话，就能够随时降级到企业级的服务。 TDengine 落地实际在咱们的这套零碎中利用的 TDengine 版本为 2.4.0.0，次要用于存储大量设施产生的时序数据，咱们整个我的项目的智能化都是基于这些数据开展。采集设施次要为碱液循环泵、脱氧塔、纯水机、电解槽等制氢设施。 该套制氢零碎除 PEM 制氢劣势外，还具备智能化水平高的特点，采纳的智能控制算法与可再生能源稳定、间歇性特点相符合，兼具高效、经济、平安、智能等劣势，实用于制、储、加一体化制氢我的项目。在这个过程中，咱们会对 TDengine 存储的设施数据进行剖析计算，最初通过大屏展现以达到实时监控、剖析等需要。 整个业务架构大抵如下：以咱们本人编写的 mosbusTCP 驱动，联合数采硬件设施采集设施数据，而后通过 JDBC-RESTful 的形式将数据写入 TDengine。数据采集点总共有 9000 多个，频率为大略每秒写入一次。 目前单列模型下，最大的超级表曾经保留了几百亿行的的数据，以后磁盘占用 55GB 左右的空间，压缩比大略在 10-15% 之间。 教训分享值得一提的是，TDengine 是依据表来做数据分片的，vnode 就是最小单位，在这种状况下，保障数据量平衡的前提是写入量平均，否则如果某些设施过热，某些设施过冷，就会呈现某个 vnode 极大，某个 vnode 极小的状况。 ...

2022 年 8 月 13 日，TDengine 3.0 正式公布了！通过一年多的致力研发，咱们终于能够骄傲地发表这一音讯。 这是一次重磅降级，TDengine 3.0 是真正的云原生时序数据库（Time-Series Database，TSDB）。 咱们先来整体看一下 3.0 的几大亮点： 能够反对 10 亿个设施采集的数据、100 个节点反对存储与计算拆散，引入计算节点，并重构了整个计算引擎欠缺并优化了对音讯队列、流式计算和缓存的反对，引入事件驱动的流式计算TDengine 面市以来，从 1.0 到 2.0，从外围性能开源到集群性能开源，失去了大量商业客户和社区用户的高度认可，寰球装置的 TDengine 运行实例数曾经靠近 14 万，每天有超过 1000 人次克隆代码，在寰球开发者中产生了肯定的影响力。日常有大量的社区开发者基于本人的业务需要，提出 issue，奉献性能，社区十分沉闷。 作为一款开源的时序数据库产品，TDengine 曾经广泛应用于物联网、工业互联网、车联网、金融、IT 运维监控等场景。目前曾经有大量的企业客户和社区用户将 TDengine 部署在其外围业务场景中。用户场景越多，TDengine 失去的用户需要和反馈越多，正是这些需要和反馈在推动着 TDengine 一直演进。 常常关注 TDengine 的用户应该都很相熟了，咱们曾经公布了上百篇用户案例，这都是企业客户和开源用户的第一手实践经验。有心的读者都会发现，在每篇用户案例的开端，用户也毫不讳言在应用 TDengine 过程中遇到的问题，更是提出了对 TDengine 的更多期待。这都是 TDengine 优化迭代的能源。 上面咱们具体看一下 TDengine 3.0 的外围性能。 1. 云原生TDengine 3.0 能够充分利用云计算平台以及分布式系统的劣势。作为一款云原生，而不只是能在云上运行的时序数据库，TDengine 3.0 具备云原生数据库的几大特点：程度扩展性(Scalability)、弹性(Elasticity)、韧性(Resiliency)、可观测性(Observability)以及运维自动化(Automation)。咱们就联合 TDengine 的逻辑架构，顺次看看它是如何实现这几大特点的。 TDengine 的逻辑架构图 程度扩展性(Scalability)TDengine 通过数据采集点和工夫两个维度对大数据进行切分，从而实现了程度扩大能力，既反对分片，也反对分区。通过将每个数据采集点的元数据分布在各个 vnode 里，而不是寄存在中心点，咱们解决了困扰时序数据库的高基数（High Cardinality）问题。TDengine 具备超强的程度扩大能力，为取得更多的数据处理能力，只须要退出更多的数据节点即可。通过测试，咱们能够验证，在 10 亿工夫线，100 个数据节点的状况下，整个 TDengine 性能还能失去很好的保障。 ...

小 T 导读：作为薪水较为可观的 IT 职业之一，DBA 貌似是一个门槛低、活还少的技术岗位，只有承受过相应的系统性训练，应该就能够胜利入门。但想要真正胜任这个岗位，理论却并不容易。DBA 的工作到底是怎么的？它的前景如何？想做好 DBA 又须要具备哪些能力？咱们采访了两位有丰盛工作教训的 DBA 和运维工程师，上面一起看一看他们的感悟吧。DBA 的一天是怎么的？分享人：涛思数据交付工程师 董延琼（注：本章节 DBA 特指运维 DBA）自己不仅是一个在 IT 行业摸爬滚打（混吃等死）、脚踏实地（得过且过）十多年的从业者，也是一个有着近十年丰盛工作教训的 DBA（老油条）。在刚进职场的五年里，我在一家中字头上面的三产做运维，主机、数据库都有接触，起初被敌人“坑”去守业公司玩了三年 MySQL，再起初持续给国字头做了三年数据库（Oracle）运维，当初的职场身份是时序数据库（Time Series Database）TDengine 团队的交付工程师。郑重声明：那种一杯茶一包烟，一张表导一天的高兴日子，我基本就没经验过。对于运维 DBA 的工作，其实和西医治病的理念有点像，在此援用一下魏文侯问扁鹊三兄弟医术的故事，很有意思。对话是这样的： 魏文候问扁鹊：“你们兄弟三人，哪一位医术最精呢？”扁鹊答复说：“大哥医术最精，二哥次之，我最差。”魏文候又问：“那为什么我没有据说过他们呢？”扁鹊解释说：“大哥于病视神，在疾病还未造成时就将其除掉了，大家都没怎么见过他治病，所以他的名声传不出家门；二哥治病，是在疾病刚刚萌芽时就治愈它了，大家都只见到他治一些不重大的小病，所以他的名声也不出于邻里之间；而我通常是等病倒退到肯定水平才发现，通过针刺血脉、投汤药、割皮解肌来治病。大家都认为我善于医治各种疑难杂症，因而闻名于诸侯之间。”当初预计很多 DBA 都会有相似的想法。现实的工作就是每天解决一下小问题，调调优，防患于未然，争取将大问题都掐死在摇篮里，剩余时间就是看看材料，晋升一下本人，平平淡淡地“混过”每一天。但很可怜的是，如果真的抱着这样的想法，那么你离被裁也就不远了，因为你在老板眼里就是个鸿鹄之志，混迹退职场中打酱油的“老油条”。 其实咱们换位思考一下也就能了解了，如果你是老板，一个员工终日没啥闲事，除了聊天打屁，就是上网看书，零碎一年也没有呈现过啥大问题，身为老板的你是不是也感觉这人力老本花的有点冤。 而与之相同的另一种状况是，你的员工每天忙忙碌碌，加班解决问题，好几次重大问题都及时无效地解决了，防止造成更重大的损失。你是不是感觉这招人的钱花的还比拟值，甚至年初还想发点钱激励他再接再厉。 转到价值观踊跃的一面，如果你是个踊跃上进（年少无知）的 DBA，每天应该怎么安顿本人的工作呢？ 其实和运维相干的工作，性质都差不多，不论是运维 DBA、主机工程师或网络管理员。说到运维，就肯定要说一下墨菲定律（Murphy’s Law），放在运维畛域几乎太有用了。 墨菲定律次要包含以下四方面： 任何事都没有外表看起来那么简略所有的事都会比你预计的工夫长会出错的事总会出错如果你放心某种状况产生，那么它就更有可能产生对应到运维畛域就是： 简略的小问题，可能是某个丧心病狂的程序员的大 Bug，一旦漠视，就可能把你尽心保护的数据库搞崩；备份复原的工夫，永远都超过你所预计的工夫；高危操作通常都会出事（一般操作一样有危险）；如果你放心库挂了没有备份复原，那么备份大概率不能用。相应的应答措施则是： 刨根求底，每个小问题都搞清楚，不放弃任何隐患；把打算工夫乘以 10，能多长就多长（把泡茶、抽烟、上厕所也算在内）；提前做好预案的预案，提前为某个操作失败想方法；每天查看备份，条件运行多备几份，反正存储不花本人的钱。将以上四点贯彻到底，你就领有了无比空虚（累死累活）的运维 DBA 的一天。当然事件也不是相对，以上大部分内容都是在探讨传统的关系型数据库，如 Oracle、MySQL、PostgreSQL 等，对于其它的诸如 InfluxDB、TDengine、TiDB 等新兴数据库就又另当别论了。 以 TDengine 为例（当然这种安装包不到 100 MB 的 Database 通常是不配领有专属 DBA 的）： 装置步骤不到三步运维命令不超过 50 个参数不到 100 个DBA 除了降级、重启，貌似就没啥工作可干了。 DBA 的倒退曾经没前途了吗？分享人：涛思数据交付工程师 董延琼如果笃定地说数据库 DBA 没有前途，那可能有些果断了。但某些 DBA 的前途的确渺茫了，比方 DB2 和 Sybase 的 DBA 们。可能有的小伙伴不太理解这两个产品，要晓得，DB2 当年的风头还在 Oracle 之上。不禁要缅怀一句，“舞榭歌台，风流总被，雨打风吹去”。 ...

小 T 导读：在 2021 楼宇科技 TRUE 大会上，美的暖通与楼宇事业部首次公布了数字化平台 iBuilding，以“软驱硬核”形式赋能建筑行业。作为一个全新的我的项目，iBuilding 在数据库选型上比拟审慎，别离比照了多款 Database 产品之后，才做出了本人的抉择。本文分享了他们的数据库选型思考和落地教训。 政策背景依据 2021 年 12 月由美控智慧修建联结亿欧智库独特公布的《中国楼宇自控白皮书》，2021 年中国楼宇智能化市场产值约达 7238.2 亿元，联合近几年行业的发展趋势，通过初步估算，2016-2021 年中国楼宇智能化市场规模逐年回升，存量规模靠近 5000 亿元，新增规模超过 2200 亿元。 因楼宇智能化在低碳、节能方面劣势突出，同时能为人们的生存带来更多舒服体验，加之政府对楼宇智能化建设规范化、科学化的疏导，将来楼宇智能化将有十分好的发展前景。从指标来看，楼宇智能化合乎建筑行业对数字化和智能化的倒退需要，将来将持续助力中国建筑行业转型降级，以适应国家对节能减排和数字经济的要求。 业务介绍随着 5G 时代的到来，美的一方面在持续打造工业互联网产品，另一方面也在一直进行科技赋能，研发更加绿色环保的集成计划，为工业及制造业提供全新的思路。 作为美的团体旗下的五大业务板块之一，美的暖通与楼宇事业部确立了“暖通及楼宇智慧生态集成解决方案引领者”的倒退愿景，旨在用智慧集成的行业解决方案满足简单的修建需要，目前次要涉足中央空调、电梯、楼宇管制等畛域。在 2021 楼宇科技 TRUE 大会上，美的暖通与楼宇事业部首次公布了数字化平台 iBuilding，以“软驱硬核”形式赋能建筑行业。 作为一个全新的我的项目，咱们别离比照了关系型数据库（Relational Database）以及支流的时序数据库（Time Series Database），包含 InfluxDB、TDengine、MySQL 等。比照关系型数据库 MySQL 来说，在这个场景下，咱们不须要简单的查问，却须要高效的存储和大范畴工夫的数据拉取。和同为时序数据库的 InfluxDB 比照，TDengine 的单机版性能远好于 InfluxDB。因而，在综合评估了适配、查问、写入和存储等综合能力后，咱们最终抉择了 TDengine 这款产品。 iBuilding 我的项目属于“智慧楼宇”的一部分，我的项目自身用于边缘侧对大型制冷设施（中央空调）的智能监控与交互。具体利用场景是：我的项目所波及的几十个楼区，各自都有一些大型离心式冷水机组（10 台左右），咱们在每个楼区都部署了一个 TDengine 到 ARM64 零碎上。通过 Python 程序，零碎会先进行数据采集，而后把数据写入 TDengine ，最初再把数据上传到云端的 TDengine 进行解决。 具体实际以其中一个 Database 环境为例： 咱们依据 TDengine “一个设施一张表，一类设施一个超级表”的建模准则，创立了如下表，两类设施的指标数别离为 97 和 199 ，数据列以 float 和 int 为主，设施每 5s 上报一批数据： ...

作者：陶建辉｜TDengine 创始人、外围开发 常常有人问我，为什么 2017 年在市场上曾经有这么多时序数据库的背景之下，你还敢去开发一款新的时序数据库？为什么你的团队都 80 多人了，五年过来，还在埋头研发 TDengine 这一款产品？周末写篇博文，与大家分享一下我的想法。 时序数据库（Time Series Database）并不是一个新兴的概念。追溯其历史，1999 年问世的 RRDtool 应该是最早的专用时序数据库了。在驰名的数据库排行网站 DB-engines 下面，时序数据库的逐渐风行起始于 2015 年，而在过来的两年，时序数据库成为风行度最高的数据库。过来两年数据库发展趋势榜 2016 年底，我看到万物互联的时代曾经到来，高效解决各种传感器、设施产生的时序数据将成为一重要的技术畛域，因而就着手开发 TDengine 这个新的时序数据库系统，2017 年 6 月正式组建团队。 TDengine 面市以来，从 1.0 到 2.0，从外围性能开源到集群性能开源，失去了大量商业客户和社区用户的高度认可，寰球装置的 TDengine 运行实例数曾经超过 13 万，每天克隆源代码的人次都超过 1000，在寰球开发者社区产生了肯定的影响力。 刚开始守业的时候，我就进行了深刻的思考：新的时序数据库还有生存空间吗？换句话说，现有的这些数据库对利用而言是不是曾经足够好了？它们能满足业务需要吗？当初我也常常思考，时序数据库值得你死磕吗？明天我从技术的角度来剖析一下这个问题，与大家分享。 1、可扩展性 / Scalability因为 IT 基础设施的爆炸性增长和物联网（IoT）的呈现，数据的规模正在迅速增长。一个古代的数据中心可能须要收集多达 1 亿个指标——从网络设备和服务器到虚拟机、容器和微服务的一切都在一直地发送工夫序列数据。再比方，分布式电网中的每个智能电表每分钟至多产生一个数据点，而中国的智能电表，至多有十亿个。任何一台计算机都不可能解决这么多的数据，所以任何旨在解决工夫序列数据的零碎必须是可扩大的。 然而，许多市场当先的时序数据库并没有提供可扩大的解决方案。就拿 Prometheus 来说，它能够算是用于 Kubernetes 环境的时序数据库的一个事实标准，但它并没有提供分布式的设计，而必须依附 Cortex、Thanos 或其余第三方工具来实现可扩展性。InfluxDB 有集群性能，然而只向企业客户提供，没有抉择开源。 为了解决这个问题，很多开发者的抉择是，在应用程序和时序数据库服务器（如 InfluxDB 或 Prometheus）之间部署一个代理服务器，来建设本人的可扩大的解决方案。而后依据时序 ID 的哈希值，将收集到的时序数据在多个时序数据库服务器之间调配。从数据写入角度看，这的确解决了可扩展性的问题。但对于查问，代理服务器必须合并来自每个底层节点的查问后果，而这是一个很大的技术挑战。对于一些查问，比方计算标准差，还不能只是合并后果，而是必须从每个节点检索原始数据。这意味着须要重写整个查问引擎，须要的工作量相当之大。 进一步，认真钻研一下 InfluxDB 和 TimeScaleDB 的设计，就会发现，它们的可扩展性实际上是相当无限的。它们将元数据存储在一个核心地位，每个工夫序列总是会关联一组标签或标识。这意味着，如果你有 10 亿个工夫序列，零碎就须要存储 10 亿组标签。看出问题了吗？当你要聚合多个工夫序列时，零碎须要首先确定哪些工夫序列合乎标签过滤条件，而在一个很大的数据集中，这会导致很大的提早。这就是所谓的工夫序列数据库的 High-cardinality 问题。 ...

DBeaver 是一款风行、开源的数据库管理工具以及 SQL 客户端，其功能强大，并且反对任何领有 JDBC-Driver 的数据库（这意味着反对简直所有数据库）。援用其官网的介绍是这样的：援用Free multi-platform database tool for developers, database administrators, analysts and all people who need to work with databases. Supports all popular databases: MySQL, PostgreSQL, SQLite, Oracle, DB2, SQL Server, Sybase, MS Access, Teradata, Firebird, Apache Hive, Phoenix, Presto, etc.援用很多 TDengine 的用户，常常问到如何应用 DBeaver 来连贯、治理 TDengine。本文将通过 22.1.2 版本的 DBeaver 具体进行阐明。前置条件DBeaver 依赖 Java (JDK) 11 ，不过其安装包中已蕴含。可选装置 Maven、Git。已装置并启动了 TDengine。若应用 TSDBDriver 驱动类连贯 TDengine，请在本地装置 TDengine 客户端。若应用 RestfulDriver 驱动类连贯 TDengine，请确保 taosAdapter 曾经失常运行。配置能够克隆 DBeaver 在 GitHub 上的源码，执行 mvn package，也能够间接下载打包好的安装包。此处抉择间接下载安装包。在 GitHub DBeaver 仓库的 Releases 处下载对应版本的 DBeaver，比方零碎为 macOS，处理器芯片是 M1 ，此处下载 dbeaver-ce-22.1.2-macos-aarch64.dmg 进行装置。点击数据库标签，抉择驱动管理器： ...

小 T 导读：SIMICAS® OEM 设施近程运维套件是由 SIEMENS DE&DS DSM 团队开发的一套面向设施制造商的数字化解决方案。在确定抉择 TDengine 作为零碎的时序数据库后，他们在 SIMICAS® OEM 2.0 版本中移除了 Flink、Kafka 以及 Redis，大大简化了零碎架构。我的项目背景IIoT（Industrial Internet of Things）是工业物联网的简称，它将具备感知、监控能力的各类采集、管制传感器或控制器，以及挪动通信、智能剖析等技术一直融入到工业生产过程的各个环节，从而大幅提高制作效率，改善产品质量，升高产品成本和资源耗费，最终实现将传统工业晋升到智能化的新阶段。 通过新的互联网连贯设施获取的数据可用于提高效率、实时决策、解决关键问题，并最终发明新的翻新体验。然而随着相互连接的设施越来越多，公司所面临的碎片化和新挑战也越来越多。为了获取和利用数据的力量，他们须要解决方案来提供可互操作的端到端合作，从而在互联网和设施之间架起桥梁，同时驾驭行将到来的翻新浪潮。 SIMICAS® OEM 设施近程运维套件是由 SIEMENS DE&DS DSM 团队开发的一套面向设施制造商的数字化解决方案，该计划借助物联网实现设施的高效近程运维，对售后服务数据进行智能剖析，从而真正实现整体售后环节的降本增效。 在 IIoT 大背景的倒退浪潮下，SIMICAS 为企业提供了一个踏入数字化世界的灵便抉择，帮忙企业依据本身倒退需要定制数字化倒退门路。SIMICAS 解决方案由四个局部组成：SIMICAS 智能网关、SIMICAS 组态工具，以及两个在西门子基于云的开放式物联网操作系统 MindSphere 根底上开发的 APP——SIMICAS 生产透镜和 SIMICAS 产效剖析。 一、零碎架构在其 1.0 版中，咱们应用了 Flink + Kafka + PostgreSQL + Redis 的架构。该零碎的数据流如下： 设施数据通过部署至现场的网关上传至物联网接入组件，组件依据配置对数据进行解析解决后，将其写入 Kafka 队列，Flink 从 Kafka 中生产数据并进行计算，原始值及计算后的指标数据都会被写入 PostgreSQL 中，最新值还会存一份到 Redis 中，以便更快地响应前端实时的数据查问，设施历史数据则从 PostgreSQL 中查问。 二、业务挑战1.0 零碎落地之后，咱们遇到了两大挑战，一个是部署繁琐，一个是利用简单。 具体来说，因为引入了 Flink 和 Kafka，导致系统部署时十分繁琐，服务器开销微小；同时为了满足大量数据的存储问题，PostgreSQL 中不得不做分库分表操作，应用程序较为简单。 ...

小 T 导读：TDengine Kafka Connector 在 TDengine 的官网文档上放进去曾经有一段时间了，咱们也收到了一些开发者的反馈。文档中的教程应用 Confluent 平台（集成了 Kafka）演示了如何应用 Source Connector 和 Sink Connector，然而很多开发者在生产环境中并没有应用 Confluent，所以为不便大家，本文将应用独立部署的 Kafka 来演示。 本文蕴含以下内容： 如何应用 TDengine Sink Connector， 把数据从 Kafka 同步到 TDengine。TDengine Sink Connector 的实现原理。一个简略的测试脚本，帮忙你在本人的环境中疾速测试。通过更改生成测试数据的程序和配置参数，你能够模仿本人的应用场景。测试同步同一个 topic，应用不同分区数和不同 Sink 工作数对性能的影响。背景常识如果你对文章结尾呈现的术语并不生疏，那么能够跳过这一部分。 · 什么是 Kafka？Kafka 的外围是一个通用的、分布式的、可反复生产的音讯队列。 与之相比，作为一款时序数据库（Time-Series Database），TDengine 也可看作针对结构化的时序数据的音讯队列。 · 什么是 Kafka Connect? 为什么应用 Kafka Connect？Kafka Connect 是 Kafka 的一个组件，简化了 Kafka 与其它数据源的集成。用户通过 Kafka Connect 读写 Kafka；通过 Kafka Connect 插件（也称 Kafka Connector）来读写各种数据源。 为不便集成，Kafka 曾经提供了生产者和消费者 API 以及客户端库，那为什么还须要 Kafka Connect 呢？因为一个好的 Kafka 客户端程序，不是单单生产或生产数据，还须要思考容错、重启、日志、弹性伸缩、序列化以及反序列化等。当开发者本人实现了这所有，就相当于开发了一个和 Kafka Connect 相似的货色。 ...

小 T 导读：在 TDengine 安稳运行的数周工夫里，中天钢铁的新零碎均匀每周收录 3000 多辆车辆表与 100 多条船只表，每张表中数据或多或少，累计数量已达百万，业务的实际效果也达到了预期。本文分享了他们对于新我的项目的数据库选型、利用的思考，同时也进行了业务成果剖析。 为了满足业务倒退需要，咱们须要新开发一套性能，对厂内每辆运输车辆的实时 GPS 地位进行追踪，通过大数据平台对 GPS 坐标进行解决、剖析、可视化展现。同时也须要对公司货运船只进行实时监控，使用 GPS 平台的剖析解决能力对船只的航运轨迹进行预判，计算其是否偏离航线。这些 GPS 数据来自于中天云商 App，只有运输车辆司机关上云商 App，零碎每隔 10 秒会主动发送该车辆 GPS 信号到大数据平台，再由大数据平台剖析解决。 数据处理门路次要为，大数据平台将 ERP 中关联过合同的 MMSI 信息同步到 GPS 平台，由 GPS 平台挑选出 300 条船舶的 MMSI 同步至船达通平台，同时将接收数据接口地址发送到船达通平台，船达通平台会依据 MMSI 编号以及推送地址，每隔 10 分钟将该船只的最新地位以及动动态信息推送至 GPS 平台。基于此，调研到一个适合的数据库，对于实现我的项目的数据处理需要至关重要。 对于数据库选型调研的思考实质上来讲，行车记录、行船记录都是时序数据，人造带有工夫戳，这些时序数据达到服务器时都是有序递增的，且时序数据的特点是流量安稳却十分微小，这点和电商数据不太一样，比方双十一时电商数据会呈现陡增，平时却没有那么高流量。作为典型的时序数据，车联网数据每隔 10 秒或 10 分钟发送一条，绝对固定，在调研时咱们发现，TDengine “一辆车一张表”的模型很符合这一场景。 同时，时序数据在查问时要匹配特定的工夫线或数据标签，且实时状态查问、数据降精度、整体趋势剖析较多，一般数据库无奈提供这种函数。基于“一辆车一张表”这样的设计，TDengine 可能实现任何一台设施采集的数据，在存储介质里都是一块一块间断寄存的，且依照工夫排序，保障了在查问单个设施一个时间段的数据时，查问性能可能有数量级的晋升。 另外一方面，尽管不同设施因为网络的起因，达到服务器的工夫无法控制，是齐全乱序的，但对于同一个设施而言，数据点的时序却是能够保障的。“一个设施一张表”就保障了一张表插入的数据是有时序保障的，这样一来数据插入操作就变成了一个简略地追加操作，插入性能也有了大幅度晋升。 在压缩性能上，通过下表几家 Database 的比照，也可看出 TDengine 的优良： 同时 TDengine 针对同类型设施间的聚合问题，创新性地提出超级表的概念，让多设施间的聚合变得灵便不便，也让实时数据大屏显示、监测设施分类管理变得极其简略。总结而言，TDengine 针对时序数据的写入、存储、索引、查问等方面都进行了特定的优化，从而实现了更优的数据加载、压缩、查问、写入性能，十分匹配工业传感器数据的利用剖析场景。 尽管接入设施繁多，但 TDengine 兼容性很强，写入、读取和统计效率也大大高于其余同类型数据库。比照 InfluxDB 来看，其测试数据显示如下： 为了评估不同长度的工夫窗口对查问性能的影响，咱们选取了第四个查问场景，设定并行执行的 work 数量 16， 工夫区间是随机选取的 1h / 2h / 4h / 8h / 12h 等间断时间段，单个聚合工夫窗口维持在 1min 不变。取得的查问响应工夫如下所示： ...

作者 ｜ 温金雄、彭涛、周玉峰 小 T 导读：为了解决宽广新能源汽车车主面临的充电效率问题，协鑫能科打造了以换电为外围业务的挪动能源品牌「协鑫电港」，须要对各种数据流进行科学管理、正当使用与智能调度，在数据库的抉择上尤为重要。本文分享了他们对于数据库架构的搭建思考以及 TDengine 的利用心得。企业简介协鑫能源科技股份有限公司（证券简称：协鑫能科 002015.SZ） 系协鑫（团体）控股有限公司旗下企业，主营业务为清洁能源经营、挪动能源经营以及综合能源服务。公司倾力打造从清洁能源生产、补能服务到储能的便捷、经济、绿色的出行生态圈，为电动化出行提供一体化能源解决方案，致力于成为当先的挪动数字能源科技运营商。 1、业务痛点随着新能源汽车的宽泛遍及，补能的效率问题逐步成为了宽广车主面临的痛点难题。为了解决此难题，作为一家头部的新能源公司，协鑫能科翻新冲破，切入能源服务畛域，打造了以换电为外围业务的挪动能源解决方案品牌「协鑫电港」。 因为这是一个在全新畛域中打造的全新我的项目，想要获得成功，须要对各种数据流进行科学管理、正当使用与智能调度，所以针对该场景，咱们一开始便把量级最大的物联网数据处理计划锁定在了时序数据库（Time Series Database）上，重点比照了 InfluxDB、OpenTSDB 以及 TDengine。 最终，TDengine 以其独特而迷信的设计和优良的测试体现成为咱们选中的时序数据处理引擎，承当了用户车辆数据、电池设施数据以及换电港工作设施等的海量数据存储剖析工作，为咱们解决了该我的项目上难度最大的一个环节。最终，咱们决定应用 TDengine 2.4.0.10 版本，并在电信的天翼云上落地了该我的项目。 2、架构与搭建从流量削峰以及数据安全的角度登程，咱们会先通过应用某 MQTT 音讯服务器把这些不同品种的设施数据先对立转发给到 Kafka。其中不同类型的数据，将会别离上传到不同的 Kafka topic，最初再通过 Java 连接器把数据写入 TDengine。具体架构如下图所示： 在整体架构上，除了 TDengine，也有一些其它数据库独特支持系统服务，其中 MySQL 负责存储订单、流水等须要精密查问的关系型数据，但因为 MySQL 能够接受的数据量比拟无限，为了做一些大表的连贯查问，因而咱们也接入了 TiDB，负责剖析报表类数据的存储。 目前接入 TDengine 最次要的入库数据是车辆传感器（如：车辆里程、经纬度等）以及换电站电池相干的传感器（电池的各种指标）数据。以后共有 55 张超级表，子表数量达到 11 万张。 咱们以后在 TDengine、TiDB、MySQL 中存储的数据量比例大略为 6:3:1，仅仅应用了三台 4C+16G 的服务器，TDengine 便挑起了整个零碎数据存储的大头，轻松撑持起了咱们的服务。在数据库的抉择上，咱们始终认为不同数据库之间术业有专攻，不得不抵赖，TDengine 在存储引擎上的独特设计，在降低成本方面的成果非常显著。 对于 TDengine，咱们一开始应用的是单节点，在稳固经营了几个月后，于往年 3 月实现了动静扩容，倒退到了 3 节点集群模式，把数据库也降级到了三正本（从图中能够看进去）。 TDengine 的动静扩大十分不便，只有确保一些必要的参数保持一致，就能够间接通过 “create dnode”把新的计算资源加进来。退出后，再通过 “alter database iot replica 3” 这个命令，即可间接在线令数据库变为 3 正本，从而实现数据的备份及高可用。 ...

两年前，咱们有篇博客介绍了如何通过 IDEA database 工具连贯 TDengine，但这段时间以来 TDengine、taos-jdbcdriver 有了很大的迭代更新，JDBC Connector 曾经从 TDengine 仓库中独立进去。社区中有些用户示意在应用 IDEA database 连贯 TDengine 时会报错，于是，咱们决定从新写一篇无关 IDEA 数据库管理工具连贯 TDengine 的文章。本篇博客以目前 2.0.39 版本的 JDBC Connector 为例，介绍如何应用源码编译、打包，以及如何应用 IDEA 数据库工具连贯 TDengine。源码编译 JDBC-Connector首先从 GitHub 仓库克隆 JDBC 连接器的源码，git clone https://github.com/taosdata/t... （须要旧版本能够 -b 指定对应版本分支），或者设置： 在 taos-connector-jdbc 目录下执行：mvn clean package -Dmaven.test.skip=true 应用 IDEA database 连贯 TDengine关上 IDEA database 工具，在驱动中增加 target 文件夹下的 taos-jdbcdriver-2.0.39-dist.jar。抉择 RESTful 形式进行连贯（留神：应用 com.taosdata.jdbc.TSDBDriver 驱动类须要装置 TDengine 客户端）。 而后通过驱动创立数据源。TDengine 的 JDBC URL 标准为：jdbc:[TAOS|TAOS-RS]://[host_name]:[port]/[database_name]?[user={user}|&password={password}|&charset={charset}|&cfgdir={config_dir}|&locale={locale}|&timezone={timezone}]应用 RESTful 连贯，此处 URL 示例为：jdbc:TAOS-RS://VM-24-8-centos:6041/log（ 此处应用域名须要在 Hosts 文件内增加解析；URL 内的 locale、timezone 参数在 RESTful 连贯中不失效） ...

从上周开始，北京就正式进入了“三伏天”，尽管天气还没有达到北方的 40 度低温，但也就差个几度而已，体感温度也曾经靠近 40 度了。等到周末终于有工夫了，乐不可支进来户外玩，后果不一会就大汗淋漓，游玩的情绪依然如故，回家第一件事就是开空调，巴不得把本人塞进冰箱里降降温。 难道酷暑天气咱们真的只能抉择“家里蹲”了吗？！ 当然不是！咱们为你筹备了一个好去处，在这里你能吹着收费空调、吃着收费雪糕、拿着各种精美礼品、听着各种有价值的分享……没错，它就是在不久前刚刚启动的 「TDengine 开发者大会」！就在 8 月的第二个周六，咱们要回绝躺平，来解锁一个不一样的周末时光~ 当初购买大会门票享受的是 6 折优惠，早鸟票只有 199 元！但咱们的优惠力度还不止于此，想要收费取得大会门票吗？别急，“购票福利第二弹”行将揭晓！ 为了回馈始终关注和反对 TDengine 的宽广开发者，在大会售票阶段，咱们发动了「“码”上赢门票」限时购票福利流动，这也是咱们为有购票需要的敌人们开启的第二波“购票福利”了。心动不如赶快口头，流动限时开启，快来带走属于你的大会通行证，各种精美礼品等你带回家！ 流动规定步骤一：装置 TDengine 数据库。步骤二：应用 taosBenchmark 命令行工具创立名为 test 的数据库。步骤三：启动 TDengine 命令行工具 taos 执行查问。通过 SQL 语句查问表 meters 中每 1 秒工夫窗口（提醒：应用 INTERVAL 关键字）的 phase 字段平均值，体验 TDengine 查问计算 1 亿条数据的性能。其中第 6 条记录的 phase 平均值即为报名明码。步骤四：将查问语句和明码截图发给小 T，审核通过后即可获取门票。如果你苦思冥想仍然不晓得答案是什么，那也不要焦急，连忙加小 T 微信（ID：tdengine），即可获取 SQL 语句提醒。前路的最大阻碍都曾经为你扫平，你还在等什么，赶快口头起来吧！ 小小剧透一下，目前本次大会确定缺席的嘉宾曾经有小米团体副总裁崔宝秋博士、明势资本创始人黄明明、Apache Software Foundation Member 郭炜、SphereEx CTO 潘娟、OneFlow 创始人 & CEO 袁进辉、极客邦科技创始人 & CEO 霍太稳、快猫星云创始人 & CEO 来炜、OPPO 高级后端工程师唐恒建等，哪位嘉宾的演讲你比拟期待呢？欢送评论区留言探讨~ ...

往年 5 月，TDengine 曾经正式走过了 5 个年头，在一众涛思人的庆贺下，它的 5 岁生日过的低调却又不失典礼感。在这 5 年工夫里，TDengine 创始了一个又一个的大事记，实现了双开源、在 GitHub 取得了 18.6k Star、寰球运行的实例数已超过十万…..现在，在它迈进下一个五年的开始，行将问世的 3.0 版本也将作为第一个大事记，在往年 8 月与大家正式见面。 8 月 13 日，由涛思数据举办的前沿数据技术交换盛会「TDengine 开发者大会」将在北京·昆泰嘉瑞文化核心举办。本次会议次要面向关注物联网、车联网、工业互联网、IT 运维监控等场景下的时序数据处理的开发者与相干从业人员，为始终关注 TDengine 的社区开发者打造一个畅谈数据技术前沿趋势的平台。在本次会议上，TDengine 3.0 将正式公布，其外围性能也将一一揭秘，诸多颠覆性翻新思路让你一探到底。 为什么咱们要做这场大会？自 2017 年“数字经济”被政府工作报告首次提及后，就成为各行各业乃至于集体倒退的一个风向标，企业的“数字化转型”也在热火朝天地进行着。在数字化转型的过程中，数据技术的重要性显而易见，作为企业倒退的贵重资产，数据处理能力与业务倒退需要始终是呈正相干的。在此背景下，数据架构的迭代降级也是企业在继续摸索的一大主题。 此时也恰逢 TDengine 3.0 新鲜出炉，涛思数据的外围研发团队在攻克 3.0 大关时也对时序场景下的数据技术创新有了进一步的感悟和了解。因而，咱们决定启动一场数据库行业的技术峰会，面向关注物联网、车联网、工业互联网、IT 运维监控等场景下，有时序数据处理需要的开发者与相干从业人员，并邀请到一众业内大咖交换观点、碰撞思维，TDengine 3.0 的外围研发成员也会借此平台分享 3.0 的泛滥翻新思路。 本次大会旨在探讨数字化转型与数据技术深度交融门路，从时序数据库内核实现看翻新技术的新倒退，通过解锁能源、IoT、车联网、金融、工业互联网及 IT 运维等行业技术实际，帮忙有数字化转型需要的企业找到数据架构降级的最佳计划。 这场大会有哪些你感兴趣的专题内容？主论坛在大会主论坛上，涛思数据创始人陶建辉将会携手包含小米团体副总裁崔宝秋博士在内的多位根底软件畛域出名大咖、出名投资人，对数据技术、企业数字化转型所面临的难点、将来发展趋势等进行深刻解读，还将重磅揭晓 TDengine 3.0 版本的出炉。同时，主论坛还有精心策划的开源方向的圆桌论坛环节，多位数据库技术大咖齐聚一堂，分享对数据技术创新的多元化思考。 技术专场 —— 核心技术专场在本场分论坛中，TDengine 3.0 的外围研发人员将会就 3.0 的性能点及其核心技术进行相干分享，让 TDengine 社区开发者、关注者、企业用户等对 3.0 版本的相干技术和性能建设深度理解，便于与本身业务进行疾速交融。同时，也心愿为参会人员带来时序数据库翻新技术的更深层次解读。 行业最佳实际专场 —— 能源、金融、车联网等行业的最佳实际详解在本场分论坛中，咱们邀请到能源、金融、车联网等行业的 TDengine 典型用户，从具体实际登程，分享他们所面临的数据架构倒退难点、解决思路等相干教训，论述其对于 TDengine 在实现业务降本增效方面的利用感触，为时序数据场景下的数据解决方案提供翻新思路。 这场大会有哪些你想结交的行业大咖？为了让大会专场演讲内容更加重磅且具备可参考性，本次大会邀请到了不同畛域的演讲嘉宾，除了 TDengine 3.0 的外围研发人员，咱们还邀请到包含关注数据库赛道的出名投资人、数据库畛域的技术专家、物联网车联网金融等行业的合作伙伴，力求从赛道、技术、实际等多个维度为参会者带来全方位的数据架构业余内容解读。 ...

小 T 导读：在应用 TDengine 的时候，通过官网的技术文档能够学习到建库（database）、建表（table）的各种 SQL 语句，然而一旦要跟本人的具体业务场景联合，经验不足的敌人可能会不晓得到底如何下手，本文将分享一些常见的建模形式，心愿帮忙大家更好地落地 TDengine。不同于 OpenTSDB、Prometheus 等时序数据库（Time-Series Database），TDengine 容许一个表有多个列（即每条记录中，多个采集量共用一个工夫戳的存储形式），这样在建表时能够有更大的灵活性。 智能电表是个典型的能够依照设施建表，多列存储时序数据的例子。但在理论应用过程中，状况可能会更简单，肯定要联合自身数据的状况来灵便设计表构造。 依照设施建表，在官网文档中曾经有具体的例子和介绍，本文除了介绍一个设施一张表的建模形式外，还会对另外几种建模形式做一个补充。 1、依照设施建表的规范情景上文中的智能电表例子就是一个设施一张表的规范情景。这种规范情景有以下特点： (1) 雷同类型的设施，采集指标完全相同。（比方上文例子中的智能电表，只采集电流、电压、相位三个指标）(2) 就同一个设施而言，各采集指标同时采集，采集工夫戳雷同。(3) 就同一个设施而言，各采集指标每次采集的数据最好是在同一个音讯中上报到 TDengine，而非别离上报。 这种状况的解决最简略： 采纳多列模式，即为每个类型的设施创立一张多列超级表。为该类型的每个设施创立一张子表。子表从第二列起，每一列均为一个采集指标。图一：TDengine database 表设计 以智能电表为例：图二：一个采集点一张表 图三：超级表应用实例 2、依照设施建表，但同类型设施的采集指标不完全相同理论生产中，同类型的设施有时候采集指标也不完全相同，这种状况下有以下特点： (1) 雷同类型的设施，采集指标大体雷同，但每个设施可能有大量个性化的指标。（前提：所有个性化指标总数加上共有指标总数不超过 1024 个，2.1.7.0 版本后总数为不超过 4096 个）(2) 就同一个设施而言，各采集指标同时采集，采集工夫戳雷同。(3) 就同一个设施而言，各采集指标每次采集的数据在同一个音讯中上报到 TDengine，而非别离上报。 这种状况相似于 1，但区别是每个设施可能有个性化的采集指标。针对这种情景的解决思路常称为“大宽表”： 创立一个多列超级表，蕴含所有不同的采集指标列，为所有采集指标的选集。为每个设施创立一张子表。子表从第二列起，每一列均为一个采集指标。数据写入时，对于该设施不具备的采集指标填入 null 值。图示和图三靠近，不同处在于建设超级表时，采集指标须要依照最多的设施去解决。 3、依照采集指标建表-1更简单的场景中，设施的固定表构造很难形象进去，或者表构造常常扭转，无奈固定，此时须要有更灵便的解决思路。以下任一个特点满足时，需思考按指标建表的思路： (1) 雷同类型的设施，采集指标无奈固定，或者每个设施有大量个性化的指标。（前提：所有个性化指标总数加上共有指标总数超过 1024，2.1.7.0 版本后为指标总数超过 4096 个）(2) 就同一个设施而言，各采集指标有各自的采集工夫戳。（即同一个设施的不同采集指标的采集工夫、采集周期等无奈保障雷同）(3) 就同一个设施而言，各采集指标每次采集的数据分多个音讯上报到 TDengine，且时间延迟无奈确定。 这种情景要求更高的灵活性。个别解决思路如下： 创立单列的超级表，即工夫戳+采集值，而在标签项中减少采集指标 ID 这一标签。每个设施的每个采集指标独自创立一张表，在标签项中减少具体的采集指标 ID。不同数据类型的采集指标要划归不同超级表，比方数值型、布尔型和字符串型的数据应该别离纳入三类对应的超级表。图四：单列模型建模示例示例如下：图五：单列模型建模实例 4、依照采集指标建表-2此场景可能呈现在工业物联网 PLC 数据采集中。 (1) 雷同类型的设施，采集指标无奈固定。(2) 就同一设施而言，各采集指标有各自的采集频率，不过采集频率是确定的，比方 PLC1~PLC10 的采集频率是 10ms，PLC11~PLC20 的采集频率是 20ms。(3) 就同一设施而言，后续可能会动静增加 PLC 通道。冀望能够在不批改代码的状况下动静减少超级表的列。(4) 心愿通过一个超级表来对立治理。 ...

Hi，TDengine database 的用户敌人们，为避免过多的共性问题困扰大家，不便大家学习、排汇教训，咱们会对近期社区内用户遇到的共性问题进行精选、汇总，给大家分享。 这是此专栏的第二期内容，将为大家分享如下几个常见问题： 一. 如何以最快的速度排查连贯问题？（蕴含连接器）首先须要明确几点： 在网络能够互通的状况下，不论是客户端还是连接器，所有对数据库的连贯问题根本都属于配置问题；遇到连接器连贯问题后，请第一工夫先排查 TDengine 客户端是否能够失常工作（具体确认形式为确保客户端能够顺利查问每个数据库服务端的子表）；连贯问题具体的谬误体现次要为：1) “Unable to establish connection”； 2) “Unable to resolve FQDN”； 接下来是具体排查办法： 在服务端运行 taosd | grep -i fqdn ，或者 cat 数据文件目录（默认为/var/lib/taos）/dnode/dnodeEps.json | grep -i fqdn，获取输入的 fqdn 参数值。在客户端服务器的 hosts 文件中，查看本人是否有把正确的 fqdn 参数值和数据库服务端 ip 写上。如果步骤 1 的输入后果是 localhost，客户端在发动连贯解析的时候就会连到本人 127.0.0.1 从而呈现连贯失败，所以这时候，须要通过 taos.cfg（默认门路 /etc/taos）把服务端的 fqdn 参数值批改成其余值，而后在数据文件目录（默认为/var/lib/taos）/dnode/dnodeEps.json 下同步更新 dnodeFqdn 的值，而后重启数据库服务加载新的配置，回到步骤 1。如果步骤 1 的输入后果并非 localhost，持续步骤4。 客户端从新发动连贯。如果连贯仍然有问题，请留神查看防火墙的端口规定，云服务器还要注意安全组的规定。若充沛尝试后仍不能解决，请在 gitHub 或微信群中反馈，会由官网工作人员帮助解决。二. 2.0 版本 TDengine 如何做不同机器之间的数据迁徙？先登录旧的数据库服务，show dnodes 记录下各个 dnode 的 ID 对应的 End Point 及 IP；布局好新的数据库服务各节点的 fqdn 及 IP 地址，以及与旧零碎各节点的对应关系；将旧零碎各节点的数据文件复制到新零碎对应的节点的数据文件目录下；将旧零碎各节点的 taos.cfg 复制到新零碎对应的各节点，并做好相应批改：firstEP/fqdn/dataDir/logDir 等等；编辑新零碎各节点数据文件夹里 dnodeEps.json，将其中的 dnodeFqdn 批改为新零碎现有的 fqdn 参数值，dnodePort 批改为新零碎现有的 serverPort 参数值（总之，要确保该文件的各项配置与咱们在 taos.cfg 中理论配置保持一致）；启动新零碎，迁徙结束;三. 如何批改数据文件目录 dataDir？进行数据库服务；批改 taos.cfg 下的 dataDir 值为咱们须要的新目录门路；把原有的数据文件全副挪动到新的目录上面，确保在新的 dataDir 下，能看到之前的 dnode,mnode,vnode,vnode_bak；再次启动服务；四. vnode_bak 目录有什么用？数据文件目录下的 vnode_bak 是存储数据库曾经删掉的库的数据文件的，如果误删除了数据库，能够分割咱们企业版团队提供数据复原服务。 ...

小 T 导读：为了满足智能驾驶业务的数据处理需要，大疆车载试图从多家数据库中进行选型调研，帮忙智能驾驶业务晋升写入查问性能、升高运维老本。本文将分享大疆车载在数据库选型、零碎搭建和业务迁徙等方面的教训。依据国家发改委、科技部、工信部等 11 个部门联结印发的《智能汽车翻新倒退策略》，到 2025 年，中国规范智能汽车的技术创新、产业生态、基础设施、法规规范、产品监管和网络安全体系根本造成。同时，实现有条件智能驾驶的智能汽车达到规模化生产，实现高度智能驾驶的智能汽车在特定环境下市场化利用。目前，随着我国正在踊跃倒退智能网联汽车，无人驾驶技术进一步推动，互联网巨头企业进入市场、加大投入研发技术，无人驾驶市场正处于疾速倒退阶段。无人机头部企业大疆车载也在去年 4 月份发表进入智能驾驶畛域。 因为以后的智能驾驶业务还是新的业务场景，所以大疆车载在选型上的历史累赘绝对较轻。在 Database 选型要求上，从业务需要登程，次要聚焦在两点：首先，联合当下的业务场景，须要满足单台车辆的高频音讯上报频率；其次，反对在数据量大的时候，通过聚合函数，或选择函数来疾速筛选出须要的数据。 此外，对数据库要求反对集群部署的同时，也要求更低的查问语句编写上手难度；而且需反对单表千万量级，在海量数据并发场景下，须要有较高的统计报表能力和较好的查问 SQL 效率；最初通过数据压缩、运维老本和并发能力上的考量，最终选定 TDengine 来存储海量数据。 综合来看，TDengine 满足需要的次要起因如下： 国产、开源的时序数据库（Time Series Database）开源版反对分布式集群，不便扩大列式存储，数据压缩比率高，读写性能优良一个设施一张表，对应咱们一个车辆一张表，模型符合超级表对于分组聚合查问的弱小反对能力TDengine 建表思路作为智能驾驶畛域的创新者之一，大疆车载为汽车主机厂提供了软硬一体的智能驾驶解决方案。其中，车辆云端平台负责对车辆状态信息进行监控，具体包含 GPS、速度、转速、里程等，经由 MQTT 流转到 TDengine 存储，满足车辆历史轨迹回放和车辆实时状态监控。 车辆音讯样例数据展现如下： {"message_id": "a78b6d9a","device_key": "deviceKey2","ts": "2022-03-01 15:01:59","longitude": 123.9795647512915,"latitude": 21.58338210717887,"altitude": 51.47800064086914,"signal_strength": 12,"satellites_in_view": 21,"speed": 72.798225,"acceleration": 12,"rpm":2190,"gear": "D","direction": -91.32959,"mileage": 10020,"ip": "10.1.2.3","create_time": "2022-03-01 15:02:03",}落脚到理论业务上，咱们搭建的表构造如下： 咱们落地应用的是 TDengine 2.2.1.3 单机版 ，依照车辆惟一的标识 DeviceKey 来创立子表，如 device_stat_$deviceKey，一个车辆的状态信息都存在一张子表中。mqtt_msg 超级表也是一样的逻辑，也是以 DeviceKey 来创立子表。 架构与迁徙 除了上报的 GPS、速度等，App 端还会和车辆/设施之间进行大量的命令交互，如下发车辆指令操作，这些咱们也是应用 TDengine 来进行存储和链路追踪的。具体到链路音讯追踪的应用上，咱们会将设施与云端、云端与 App 之间双向通信的 MQTT 音讯转发到 Kafka 音讯队列中，而后业务零碎进行生产解析，失去 TraceID、音讯 ID、音讯版本、音讯类型、音讯工夫戳、音讯内容等不同字段的数据，而后将其写入 TDengine 的 mqtt_msg 超级表当中。 ...

Hi，大家好，为避免过多的共性问题困扰用户，不便用户学习、排汇教训，咱们会对近期社区内用户遇到的共性问题进行精选、汇总，以专栏的模式给大家带来分享。这是本专栏的第三期内容，分享的内容如下： 内容预览为何批量写入数据时，工夫戳应用 NOW 函数拼接会导致数据失落？如何给集群平滑扩容？集群扩容后，DNode 状态为 Offline 该如何排查？如何给集群平滑缩容？老手小福利：疾速上手 TDengine 建模。1. 为何批量写入数据时，工夫戳应用 NOW 函数拼接会导致数据失落？答复这个问题首先须要强调一个概念，TDengine 作为一个时序数据库（Time-Series Database），首个工夫戳字段起到主键的作用，内存索引的构建、磁盘数据的存储与其密切相关，不能有反复的工夫戳。 NOW 函数（以及 NOW 关键字）返回客户端以后工夫。当执行批量写入时，若首列工夫戳给的值都是 NOW，在数据库默认毫秒的工夫级别下是辨别不开的，后续写入的反复工夫戳将会失落或更新，解决反复工夫戳的具体逻辑由在 TDengine 中建库（Database）时的 Update 参数决定。 2. 如何给集群平滑扩容？对集群进行扩容须要手动增加节点。具体操作步骤如下： 第一个节点部署胜利后，为后续待增加的节点顺次装置 TDengine 服务端程序，编辑 /etc/hosts，将集群所有节点的域名解析增加进去（如已部署 DNS server，则无需编辑）。将第一个节点的配置文件 taos.cfg 复制到待增加的节点中，将其中的 fqdn 参数改为节点本身的 fqdn (hostname)。启动待增加节点的 taosd 服务，而后进入 taos 命令行执行上面语句将待增加节点增加进集群：CREATE DNode ‘Node2:6030’ 。执行 SHOW DNodes 查看数据节点的状态是否为 Ready。为 Ready 代表集群扩容胜利。3. 集群扩容后，DNode 状态为 Offline 该如何排查？新的节点失常退出集群后，数据节点列表中会显示该节点处于 Ready 状态。若该节点状态为 Offline，可依照如下内容进行排查： 查看该节点 taosd 是否已启动、防火墙是否敞开；确认待退出节点的数据文件夹是否清空；查看所有节点 /etc/hosts 域名解析是否残缺、无效（须要有所有节点的解析，包含 arbitrator）；该节点 firstEP、fqdn 参数是否正确配置。4. 如何给集群平滑缩容？集群缩容是通过 DROP DNode 删除节点来实现的，间接进行指定 DNode 的 taosd 过程只会让该节点 Offline，但不能实现缩容的成果。具体操作步骤如下： ...

作为一款时序数据库（Time-Series Database），TDengine 提供了按工夫主动划分窗口并执行查问的能力。这个性能的用处和应用场景你是不是分明呢？本文将为你介绍这一性能及其典型应用场景。什么是窗口查问？时序数据经常须要依据采集工夫对数据进行查问，实质上是在时间轴上划分出工夫窗口，并对窗口内的数据进行聚合和查问计算。比方一个最简略的场景：查问”2018-01-01 00:00:00.000″到”2018-01-31 00:00:00.000″原始数据的最大值、最小值、平均值，则”2018-01-01 00:00:00.000″到”2018-01-31 00:00:00.000″就造成了一个查问的工夫窗口。 在理论生产利用中，业务场景要求的查问条件往往比这个更简单，须要时序数据库可能依照不同规定、沿时间轴进行窗口划分，并对各个窗口内的时序数据别离进行聚合、抉择计算等操作。 TDengine 提供的三种窗口查问能力详解TDengine 从 2.2.x.x 版本起，反对了三类时序窗口查问，别离是等距离窗口（interval）、状态窗口（state_window）和会话窗口（session），大大简化了利用开发时对工夫序列逻辑的解决。 窗口查问，从子表的查问语法为： SELECT function_list FROM tb_name [WHERE where_condition] [SESSION(ts_col, tol_val)][STATE_WINDOW(col)] [INTERVAL(interval [, offset]) [SLIDING sliding]] [FILL({NONE | VALUE | PREV | NULL | LINEAR | NEXT})]窗口查问，从超级表的查问语法为： SELECT function_list FROM stb_name [WHERE where_condition] [INTERVAL(interval [, offset]) [SLIDING sliding]] [FILL({NONE | VALUE | PREV | NULL | LINEAR | NEXT})] [GROUP BY tags]上面别离看一下这三类时序窗口查问性能。 1. 等距离窗口（interval）依照固定的工夫窗口长度，周期性地对时间轴进行窗口划分，并容许对每个窗口内的数据进行聚合查问。咱们再通过几个例子看看等距离窗口的具体利用场景。 在工业生产中，有很多监控指标须要实时展现趋势线。但有些指标如振动等，理论采集的频率十分高，如果展现原始数据会难以看清趋势，同时因为数据量过于密集，会给前端页面的展现造成微小压力。 但通过 interval 等距离窗口，能够依照指定窗口长度对原始数据做聚合（相当于对原始数据进行了降采样），之后再展现趋势线时，前端展现须要从数据库拉取的数据量会大大减少，从而显著提高效率。 ...

「以技术之光变革世界，以社区之光共创将来」，暨 TD Hero 发布会，将于 2022 年 7 月 2 日 14:00 在线上召开，欢送共临直播间，畅聊社区共建的这些事儿。TD Hero 是由 TDengine 技术社区发动的，以开发者为主体的我的项目。TDengine 社区心愿可能与更多开发者一起共建，激励开发者以多种形式奉献社区，让技术社区可能更加蓬勃地倒退；心愿让更多开发者的光辉，被更多的看见，一起以技术的能量去拥抱开源我的项目，以及时序数据库畛域的更多可能（更多我的项目详情，请点击「成为 TD Hero，做用技术扭转世界的超级英雄 ｜ 来自 TDengine 社区的邀请函」查看）。 第一批的 TD Hero 由社区外部举荐产生，他们都在过往的社区建设中为 TDengine 提供了许多反对和奉献，于咱们，是 Contributor，更是难能可贵的搭档。 咱们十分迫切地想要介绍这些搭档给更多人意识，同时欢送更多的搭档一起退出到咱们将来的社区建设中来。 2022 年 7 月 2 日（周六），14:00-16:30，咱们将于线上召开 TD Hero 发布会——「以技术之光变革世界，以社区之光共创将来」。 发布会上，你会更深刻地理解 TDengine 技术社区将来的布局，以及 TD Hero 体系的相干内容。同时，你也会结识咱们十分优良的 15 位新晋 TD Hero，听他们聊聊与 TDengine 共建社区的一些故事。咱们更期待的是有趣味、有想法的你也一起退出咱们，成为 TD Hero，一起共创将来。https://v.qq.com/x/page/x3344... 会议将围绕 4 个议题，以「圆桌会议」的形式召开： 议题 1：Contributor 谈 TDengine 社区的技术奉献 议题 2：User Group Meetup 分享者谈 TDengine 社区的 SIG 构建 ...

近年来，各大厂商纷纷拥抱云原生技术，由此带来的海量数据给传统的技术架构带来了微小冲击，传统监控首当其冲。服务上云之后，大都基于 Docker 容器部署、Kubernetes 服务治理，资源弹性伸缩且实时变动，传统监控难以支撑住此场景下的业务需要，可观测性（Observability）逐步倒退成为云原生畛域的热门方向。 在此背景下，云时代的零碎可观测平台观测云与物联网大数据解决方案商涛思数据达成深度策略单干，依附国产时序数据库 TDengine 的技术和性能劣势，观测云将进一步满足云、云原生、利用及业务上的监测需要，从基础设施到日志数据再到全链路利用性能实现全面被动观测，让企业在上云体验上更加顺滑。 多种存储混合查找，观测云设计 DQL 引擎专一查问在观测云的数据存储构造中，数据采集软件会被部署到不同的用户环境中采集所需数据，在数据上传后零碎会依据数据类型进行相应的分类，分类实现后所有数据会经由 Worker 进行对应解决，再依据相应的分类写入到各种不同的存储当中。在数据存储实现后，依据业务需要用户须要对数据进行查问操作，但不同的数据存储存在查询语言的差别，如何补救语言差别实现查问操作成为一个亟待解决的问题。 观测云所应用的的存储能够概括为三种，一种是如 TDengine 个别的时序数据库（Time-Series Database），一种是Elasticsearch（简称 ES），此外还有一部分数据存储在 Redis、MySQL 这类关系型数据库当中，对应如此多品种的存储，在遍历查问方面极度不敌对，尤其是对于前端来说。观测云的解决方案是从新定义一套能够查问多种数据类型的查询语言，并由此设计出了 DQL 引擎，真正意义上实现了数据查问层面的垂直划分。 为了打造出一种可能对立查找多种存储混合的查询语言，观测云在设计上进行了深刻思考，并依靠于具体实现一直打磨，设计出了专一于查问且语法简略的 DQL 引擎，代码展现如下： M（Metric）::nsq_nodes:(LAST(message_count) AS 音讯数) BY server_host L（Log）::openway_gin:(MAX(cost_time)) {host = ‘prd-dataway’} BY http_url R（RUL）::view:(COUNT_DISTINCT(userid)) { app_id = 'appid_xyz' and view_path = re('.*/scene/.*') }在解决了多种存储共存的问题后，为满足业务倒退需要，进一步晋升前端操作体验，观测云决定对既有的存储系统架构进行降级革新。 与 TDengine 单干，晋升用户体验观测云此前应用的时序数据库是 InfluxDB，利用至今，其越来越难以撑持私有化部署业务，多种问题和瓶颈导致业务倒退受到限制，最终观测云决定对 InfluxDB 进行替换。他们将眼光转移到国内数据库畛域，发现在多年的倒退之下，一些优质的国产时序数据库应运而起，TDengine 就是其中之一。在理解了 TDengine 的种种个性之后，观测云对两种时序数据库进行了相干测试。根据上述测试后果，观测云发现，不论是从写入、查问抑或是存储方面，TDengine 在性能上能够说是全面当先于 InfluxDB。无论是简略查问还是简单的聚合查问，都有 10x～20x 的性能晋升，存储空间能节俭大概一半，在写入性能上也有两倍晋升，也就是说原先可能须要应用两个或者三个节点能力满足用户的写入需要，利用 TDengine 后一个节点大概就顶住了，肯定水平上又节俭了一部分的部署老本。 目前，观测云正在逐渐将数据从 InfluxDB 迁徙至 TDengine，TDengine 将会被利用在多租户隔离、高频 I/O、私有化部署等场景中。 作为一个 SaaS 平台，观测云须要接入多租户进行对应服务，因而平台方首先须要思考的就是不同租户之间如何以不同的 DB/Index 进行隔离。在 TDengine 中，多个 DB 能够共享一个 database 服务，观测云能够顺利施行这个计划。 ...

TDengine 曾经反对工业英特尔® 边缘洞见软件包 为减速传统行业的数字化转型，英特尔推出了工业英特尔® 边缘洞见（Intel® Edge Insights for Industrial，以下简称 EII）软件包。家喻户晓，在工业生成的很多环节，都会产生大量的时序数据（Time-Series Data），数据就是财产，通过对这些数据进行全方位的剖析，有可能挖掘出对业务决策很有帮忙的信息，从而进一步发明价值、晋升效率。 EII 能够在 Docker 上运行，以便将基础设施与应用程序离开，让用户可能更快地进行开发。 其官网阐明如下： 工业英特尔® 边缘洞见软件包是一款通过事后验证、可随时部署的软件参考设计，专门面向视频和工夫序列数据的获取。它蕴含人工智能剖析，并能够公布到本地利用或远端。因为构建在 Docker 上，因而它易于批改，并能够依据您的利用进行定制。（图片起源：工业英特尔® 边缘洞见软件包） 工业英特尔® 边缘洞见软件包是通过生产环境验证的软件堆栈，可在边缘平安地提取、剖析和存储视频与时序数据。从下面的架构图也能够看出，在软件包之上编写本人的算法模型也是非常容易的。 TDengine 是由涛思数据开发的开源、高性能、分布式、反对 SQL 的时序数据库（Time Series Database），在物联网、工业互联网、车联网、IT 运维、能源、金融等畛域。 通过翻新的存储引擎设计，无论是数据写入还是查问，TDengine 的性能比通用数据库快 10 倍以上，也远超其余时序数据库，而且存储空间也大为节俭。通过原生分布式的设计，TDengine 提供了程度扩大的能力，只须要减少节点就能取得更强的数据处理能力，同时通过多正本机制保障了零碎的高可用。TDengine 采纳 SQL 作为数据查询语言，缩小学习和迁徙老本，同时提供 SQL 扩大来解决时序数据特有的剖析，而且反对不便灵便的 schemaless 数据写入。时序数据处理是 EII 中的重要模块。为反对时序数据的存储和剖析，目前 EII 应用的时序数据库为 InfluxDB。跟 InfluxDB 相比，TDengine 在性能和压缩率方面都有非常明显的劣势。具体比照能够参考相干测试报告：《TDengine 和 InfluxDB 写入性能比照测试报告》和《TDengine 和 InfluxDB 查问性能比照测试报告》。因而，涛思数据的工程师尝试将 TDengine 引入了 EII，使得时序数据可能保留在这款更为高效的时序数据库中，晋升解决效率并降低成本。 引入 TDengine 之后，具体的数据流程如下： 感兴趣的读者能够参考 Intel 网站上的相干文档来应用 EII + TDengine。读者能够参照该文档，构建本人的 Docker 镜像。运行 EII 之后，能够应用 Telegraf 来采集时序数据，将其保留在 TDengine 之中，而后能够用 Grafana 以图形化形式查看。 ...

涛思数据作为一家做开源的底层时序数据库（Time-Series Database，TSDB）的公司，与其余泛滥的中间件、数据库、根底软件公司一样，咱们的产品 TDengine 不间接卖给最终用户，而是与独立软件提供商、零碎集成商单干，被集成到利用零碎里，从而被最终用户应用，因而 TDengine 更多是间接面向软件开发者（To Developer，2D）的产品。如何施展开发者的能量，让开发者胜利，是 TDengine 技术社区的重要一环。 为了给更多开发者赋能，激励开发者踊跃踊跃地在社区中发光发热，并继续与咱们产生连贯，更好地参加到对 TDengine 的奉献当中，咱们技术社区正式启动一个新我的项目：TD Hero。 这是一个以开发者为主体的社区我的项目，期待成为 TD Hero 的搭档能够和咱们一起去经验、去体验技术社区的更多可能性，同时去发明、去变革时序数据库的将来。 目前第一批 TD Hero 由社区外部举荐产生，他们将在 7 月正式与大家见面！ 咱们也期待社区中有更多的开发者能够退出咱们，成为 TDengine 技术社区的 TD Hero，与咱们携手，让将来更具备有限可能！ 如果你心愿成为咱们的 TD Hero，倡议仔细阅读以下详细信息： 什么是 TD Hero？TD Hero 是愿与 TDengine 独特创立开源生态的开发者。TD Hero 对技术社区有浓重的趣味，有着过硬的技术水平，有能力，爱分享，有杰出的学习能力，有充分的激情和 TDengine 一起前行。TD Hero 是社区意见首领，是代码贡献者，是优良的布道师，更是能够通过技术扭转世界的「超能力者」。 如何成为 TD Hero？酷爱 TDengine 产品，有志愿共建和推广开源我的项目的优良开发者，欢送退出 TDengine 生态！ 咱们期待这样的你退出到 TDengine 的开发者生态中： 纯熟应用或深刻理解 TDengine 产品在多产业中踊跃推广 TDengine 产品落地常常沉闷在技术社区，乐于为其余开发者提供帮忙数据库领域专家技术博客、书籍的撰写者杰出的行业布道师欢送你与 TDengine 共创开源社区。 TD Hero 享受哪些权利？每一位为社区踊跃做出奉献的 TD Hero 都会取得以下专属权利 每一位优良如你的开发者，都理当被光照见，都是「用代码扭转世界的超级英雄」！欢送自荐或者找到你相识的 TDengine 员工举荐你退出咱们！ ...

小 T 导读：DataX 是由阿里云开源的离线数据同步工具/平台，目前曾经反对多种支流异构数据源在内的高效的数据相互同步性能。咱们的研发团队实现了 TDengine 的适配，相干代码已被 DataX 官网承受并合并到骨干中。DataX 是由阿里云开源的离线数据同步工具/平台，目前曾经实现了包含 MySQL、Oracle、OceanBase、SQL Server、PostgreSQL、HDFS、Hive、HBase 等多种异构数据源在内的高效的数据相互同步性能。 DataX 的设计思路是： DataX 自身作为数据同步框架，将不同数据源的同步形象为从数据源读取数据的 Reader 插件，以及向指标端写入数据的 Writer 插件，实践上 DataX 框架能够反对任意数据源类型的数据同步工作。同时 DataX 插件体系作为一套生态系统，每接入一套新数据源，就能够实现该数据源和现有数据源的互通。基于该设计思路，咱们的研发团队实现了 TDengine 的适配，实现了 TDengineReader 和 TDengineWriter 两个插件，并被 DataX 官网承受，合并到了其骨干中。 TDengineReader 提供的性能包含： 反对通过 SQL 进行数据筛选；依据工夫距离进行工作切分；反对 TDengine 的全副数据类型；反对批量读取，能够通过 batchSize 参数管制批量拉取后果集的大小，从而进步读取性能。TDengineWriter 反对的性能包含： 反对 OpenTSDB 的 json 格局的行协定，能够应用 TDengine 的 Schemaless 形式写入 TDengine。反对批量写入，能够通过 batchSize 参数管制批量写入的数量，从而进步写入性能。目前 TDengine 曾经退出 DataX 正式反对的数据库列表中。当初，如果用户要将历史 Database（比方 MySQL、OpenTSDB 等）中的数据迁徙到 TDengine，或者将 TDengine 中的数据导出，就能够利用 DataX 来实现了。 更多应用细节，能够参考“基于 DataX 的 TDengine 数据迁徙工具”一文。 ...

Google Data Studio 是一个弱小的报表可视化工具，它提供了丰盛的数据图表和数据连贯，能够十分不便地依照既定模板生成报表。因其简便易用和生态丰盛而在数据分析畛域失去一众数据科学家的青眼。 Data Studio 能够反对多种数据起源，除了诸如 Google Analytics、Google AdWords、Search Console、BigQuery 等 Google 本人的服务之外，用户也能够间接将离线文件上传至 Google Cloud Storage，或是通过连接器来接入其它数据源。 TDengine 作为一款高性能、分布式、反对 SQL 的时序数据库（Time-Series Database），广泛应用于物联网、工业互联网、车联网、IT 运维、能源、金融等畛域，让大量设施、数据采集器每天产生的高达 TB 甚至 PB 级的数据可能失去高效实时的解决，对业务的运行状态进行实时的监测和预警，进而从大数据中挖掘出商业价值。 海内外曾经有相当数量的社区用户和商业伙伴在不同的畛域应用 TDengine 来解决海量的时序数据，包含存储、剖析和展示，以帮忙改良其产品或服务。 例如美国时尚健身网红产品 Experience Lyric 智能筋膜枪，就在应用 TDengine 来存储和剖析设施运行时产生的监控数据。Experience Lyric 的数据科学家提出了一个需要，心愿 TDengine 能反对应用 Google Data Studio 来对数据进行进一步的剖析。TDengine 的研发团队认为这个需要很有价值，于是迅速响应，在很短的工夫内就实现了 Google Data Studio 和 TDengine 的技术对接。 当初，你也能够利用 TDengine 的时序数据处理能力和 Google Data Studio 的剖析能力来对用户应用产品的行为习惯数据建模并剖析了，进而能够依据剖析后果来改善本人的产品。 目前 TDengine 连接器曾经公布到 Google Data Studio 利用商店，你能够在 “Connect to Data” 页面下间接搜寻 TDengine，将其选作数据源。接下来抉择 AUTHORIZE 按钮。设置容许连贯本人的账号到内部服务。在接下来的页面抉择运行 TDengine REST 服务的 URL，并输出用户名、明码、数据库名称、表名称以及查问工夫范畴，并点击右上角的 CONNECT 按钮。连贯胜利后，就能够应用 GDS 不便地进行数据处理并创立报表了。目前的维度和指标规定是：timestamp 类型的字段和 tag 字段会被连接器定义为维度，而其余类型的字段是指标。用户还能够依据本人的需要创立不同的表。赶快试试，看看本人能取得哪些新的数据洞察吧。 ...

作者 | 李珲 编辑 | 尔悦 小 T 导读：家喻户晓，压缩算法的目标次要是为了缩小存储空间或传输带宽，通过把原始数据转换成比原始格局更紧凑的模式，来进步数据的传输、存储和解决效率。咱们相熟的很多压缩软件都是借助非常复杂的算法才得以实现，像一些时序数据库（Time-Series Database），比方 TDengine，也是通过内置压缩性能，能力实现对时序数据的高比例压缩。那具体来说，数据压缩的流程是怎么的？时序数据库中常见的数据编码和压缩算法又有哪些呢？本篇文章将会从具体实际登程进行教训分享。数据压缩/解压缩的流程压缩：输出原始数据，通过压缩器编码后，输入压缩后的数据。 input data —-> compressor —-> coded data 解压缩：输出压缩过的数据，通过解压缩器解码/重建后，输入原始数据。 coded data —-> decompressor —-> output data 如果输入数据和输出数据始终完全相同，那么这个压缩计划被称为可逆压缩，也称无损编码器。否则，它就是一个非可逆压缩，也称有损编码器。 可逆压缩：可能无失真地从压缩后的数据重构，精确地还原原始数据。可用于对数据准确性要求严格的场合，如可执行文件和一般文件的压缩、磁盘的压缩，也可用于多媒体数据的压缩。该办法的压缩比拟小，如差分编码、RLE、Huffman 编码、LZW 编码、算术编码。非可逆压缩：有失真，不能齐全精确地复原原始数据，重构的数据只是原始数据的一个近似。可用于对数据的准确性要求不高的场合，如多媒体数据的压缩。该办法的压缩率比拟高，例如预测编码、音感编码、分形压缩、小波压缩、JPEG/MPEG。 咱们都晓得，数据在计算机外部是以二进制形式示意和存储的，因而，艰深地讲，数据压缩就是以起码的比特数示意数据对象。数据压缩的实质是用计算工夫换取存储空间，不同数据类型对应不同的数据压缩算法，不存在某个压缩算法可能压缩任意数据。数据压缩说到底是对数据趋势性、规律性的总结，这个数据规律性可分为基于内容（比方视频的帧与帧之间、图像的像素与像素之间的类似）、基于示意（比方变换编码、熵编码）和基于码流（比方差量压缩、深度压缩）等多种级别。 举一个数据压缩的简略例子：给定一个字符串”this is a example”，失常状况下，每个字符占用 8 个比特位，假如该字符串含有 17 个字符（蕴含空格），每一个字符呈现的频率别离是a(2),e(2),h(1),i(2),m(1),p(1), t(1),s(2),x(1),l(1),空格(3). 当初咱们依照字母呈现的频率进行编码，用 111 示意“空格”，001 示意“a”，110 示意“e”，011 示意“i”，000 示意“s”，0101 示意“h”，1011 示意“m”，1000 示意“p”，0100 示意“t”，1010 示意“x”，1001 示意“l”。最初”this is a example”被编码成 010001010110001110110001110011101010001101110001001110，共 54 个比特。相比未压缩前的 136 比特，存储空间放大了 2.5 倍。 时序数据是如何被压缩的？时序数据库（Time-Series Database）中常见的数据编码和压缩算法有如下几种： 霍夫曼编码下面例子中提到的就是霍夫曼编码。这是一个流传最为宽泛的压缩计划，19 世纪 50 年代，David Huffman 在他的论文“一种构建极小多余编码的办法”中第一次形容了这种办法。霍夫曼编码通过失去给定字母表的最优前缀码进行工作。 ...

小 T 导读：此前有人在某问答网站上公布了这样一个问题：既然局部时序数据库如 InfluxDB、TimescaleDB 是基于关系型、非时序数据库 PostgreSQL 开发而来，那在时序数据场景下，是否用 MySQL/MongoDB 这类数据库去代替时序数据库（Time-Series Database）应用？对于此问题，涛思数据资深研发工程师试图从原理和实际登程为同样有此疑难的敌人作出解答。从数据库的定义来看，数据库就是一个数据管理系统，是用来存放数据文件的一个软件，它可能反对用户的增加、批改、删除、查问等操作。因而从定义上讲，时序数据库和关系/非关系型数据库是一样的，都是用来存放数据的。但因为存储的数据特点不同，这两类数据库的利用场景也不尽相同： 关系型数据库：次要用来存储结构化数据，应用实物保证数据一致性，应用 SQL 语言来进行查问操作。这类数据库的典型代表次要包含 MySQL、Oracle、SQL Server 等。非关系型数据库：次要用来存储非结构化数据，数据能够不通过验证进行存储，应用 JSON 数据对象进行查问操作。其典型代表次要有 MongoDB、Redis 等。而时序数据库次要用于存储实时数据，最显著的特点就是每条数据都会带有工夫戳属性，在电力、石化、冶金、智能汽车、监控等畛域利用较为宽泛。这类 Database 的典型代表次要包含 TDengine、InfluxDB、TimescaleDB 等。上面直切主题，咱们来讨论一下关系/非关系型数据库是否能代替时序数据库。 是否用关系/非关系型数据库代替时序数据库 ？事实上，如果数据采集频率少，数据量不大的话，应用关系/非关系型数据库代替时序数据库是齐全没有问题的。但如果从久远角度来看，这种做法却存在着很大的危险，具体起因还要从时序数据库的特点讲起。 时序数据具备采集频率高、数据量大、写操作为主读操作为辅、很少有更新或删除操作、却有统计聚合等实时计算操作等特点，关系/非关系型数据库很难满足这样高的性能需求。在大数据场景下，如果性能达不到要求，数据没有方法被无效存储的话，那么这样的数据库是无奈代替时序数据库的。 举一个简略的例子，在雷同的测试环境（16 核 64G 内存）下，以传统的关系型数据库 MySQL 和时序数据库 TDengine 为例，做一下 benchmark 的比照测试 ： 别离应用 MySQL 自带的 benchmark 工具 mysqlslap 和 TDengine 自带的 benchmark 工具taosbenchmark，设置 16 个线程，写入单表 10 万条记录，表构造为 1 个 timestamp 类型，2 个 int 类型，2 个字符串类型，测试后果如下： MySQL——mysqlslap -uroot -p1234 --concurrency=16 --number-of-queries=100000 --create-sc hema=tests --query="INSERT INTO meters(c0, c1, c2, c3) VALUES (RAND() * 100, RAND() * 100, uuid(), uuid())" ...

小 T 导读：为了更不便用户应用 TDengine + Grafana 这个组合，在 TDengine 和 Grafana 两个团队的合作之下，TDengine 插件正式上架 Grafana 官网！一行命令即可实现装置配置。Grafana 某种程度上曾经成为以后最风行的图形化运维监控解决方案。作为一款风行的时序数据库（Time-Series Database），TDengine 在 3 年前开源之后不久就提供了对 Grafana 的反对。 TDengine 的利用场景十分宽泛，典型的如物联网、工业互联网、车联网、IT 运维、能源、金融等。随着 TDengine 在各个领域利用越来越宽泛，很多用户抉择将 Grafana 配合 TDengine 应用，以可视化的形式监控各项指标的状态。 用户的需要就是咱们的能源。TDengine 研发团队依据用户的场景需要和应用习惯，一直地降级革新 TDengine Grafana 插件，不仅提供了告警零碎，还推出了基于 Grafana 的零依赖监控解决方案 TDinsight。 为了更不便用户应用 TDengine + Grafana 这个组合，在 TDengine 和 Grafana 两个团队的合作之下，TDengine 插件正式上架 Grafana 官网！ 请看大屏幕：https://grafana.com/grafana/p... 当初大家能够在 Grafana 治理界面中的配置数据源页面间接搜寻并装置 TDengine ，省去了编辑 Grafana 配置文件的步骤。 为了不便用户通过 Kubernetes 、Docker 或者脚本等形式进行运维自动化，咱们还提供了命令行工具。只有一行命令即可实现装置： bash -c "$(curl -fsSL https://raw.githubusercontent.com/taosdata/grafanaplugin/master/install.sh)"对于内网无奈连贯互联网的企业用户，咱们也提供了离线装置办法。详情可参考相干文档。 ...

涛思数据与华为云深度交融达成联营联运单干，成为严密合作伙伴。依靠华为云 Stack 深厚技术底蕴，联合涛思数据 TDengine 弱小引擎能力，大幅升高零碎总领有老本与复杂程度，缩小研发运维难度。单方携手打造高效稳固平安的物联网数据处理解决方案，作为智能基础设施，赋能产业数字化转型。 涛思数据联结创始人李广谈到：“ 单方紧密结合是对将来产数转型宏观背景下，物联网数据处理市场的独特看好，也是对 TDengine 产品技术与品牌能力的高度认可。单方团队严密合作，通过联营单干模式拉通单方产品技术和服务的能力，以 TDengine + 华为云 Stack 的形式，在能源、电力、工业、航空、航天、金融、汽车、化工、科研等诸多行业畛域，向华为云 Stack 用户提供 TDengine 弱小的能力和优质服务。通过这种单干，单方一起赋能行业用户，让用户的物联网平台能以更低的老本和更快的速度走向市场 ”。 华为云是寰球当先的云服务提供商，致力于提供稳固牢靠、平安可信的云服务。华为云 Stack 是华为云为大型政企用户部署在本地数据中心的云基础设施。通过继续同步华为云私有云能力，为用户提供云上和本地体验统一的云服务，兼顾私有云的疾速创新能力和公有云的可管可控。同时匹配华为云政企组织架构和业务流程，实现用户视角一朵云。华为云通过生态单干模式翻新，强化与合作伙伴的联结经营，为用户提供 “ 一揽子 ” 解决方案，并以集成联运 Kit，晋升产品服务体验、用户满意度，继续优化产品。 借助开源劣势，TDengine 在寰球市场疾速倒退。GitHub 上， TDengine 已取得 18.5k Star。寰球运行 TDengine 实例数超过 123.9k，遍布各次要国家和地区。作为一款高性能、分布式、反对 SQL 的时序数据库，TDengine 齐全应用 C 语言自主研发，从时序数据特点登程进行设计和优化。带有内建的缓存、流式计算、数据订阅等零碎性能，能大幅缩小研发和运维的复杂度，可广泛应用于各行业畛域，帮忙企业解决数据处理痛点。TDengine 次要具备以下劣势特点： 性能弱小，10 倍以上性能晋升齐全自主研发，不依赖第三方软件，信创国产化代替零运维老本、零学习老本，无需分库分表，实时备份，规范 SQL，反对 JDBC、C/C++、Go、Python、Rust、RESTful 等丰盛的编程接口与 Telegraf、Grafana、EMQ X、Prometheus、Matlab、Spark 等第三方工具无缝链接高安全性，残缺信息安全策略贯通数据采集、传输拜访全流程，用户可自定义加密策略，进行业余技术加密目前 TDengine HCS 版已正式登陆华为云严选市场，详情可征询华为云、涛思数据。作为华为云严密合作伙伴，涛思数据将与华为云携手独特发展行业深度单干，继续打造互利共赢的生态合作伙伴关系，独特布局寰球市场，强强联合为用户提供更便捷、更高效、更平安的产品及服务。 想理解更多 TDengine Database的具体细节，欢送大家在GitHub上查看相干源代码。

作者 | 尔悦 采访嘉宾 | 张玮绚（Wade） 小T导读：在去年 11 月，曾在甲骨文北京研发核心外围开发团队任职的张玮绚（Wade）转身成为了涛思数据的一员，负责 TDengine 的研发管理工作。在行将进入 45 岁之际，他决然抉择了转换赛道，重燃少年时期的冒险精力。从 90 分完美主义登程，他心愿将来本人可能和团队一起将 TDengine 打造成为时序数据库的代名词。本文中 Wade 将会论述转换赛道的心路历程，分享本人的人生和职场教训，给到有须要的人一些参考。从“化学家”到“开发者”，叛逆学霸的自学之路和大多数人不一样，Wade 的初中时代并没有在学校度过，而是抉择了在家中自学。至于为什么做出这样的抉择，用他本人的话说就是“上课真的很无聊”，寥寥数语勾画出了一个叛逆的少年形象。 “除了始终是短板的英语，我从初中开始根本所有课程都是自学的，包含大学的高等数学、线性代数、概率论、数理统计、模仿电路和数字电路等，以及计算机系的课程，像数据结构、汇编语言、操作系统等等都是自学，不爱上课这个习惯也随同了我半生。” 和普遍意义上的叛逆少年不一样，精确一点来说， Wade 更应该被称为一个叛逆的学霸。在他的前半生里，因为叛逆的性情，“自学”成为了他的一种习惯，但这种学习形式却并没有成为他的累赘，反而推动着他在不断进步——不仅在自学半年初中课程之后就考上了让本人心仪的高中，更是通过致力，让本人的短板学科英语也在半年工夫内从 8 分考到了 82 分。升入高中之后，各种物理化学比赛的奖项也是手到擒来。 脱离了照本宣科，Wade 的学习能源更多时候源自趣味推动。少年的他幻想是成为一名货真价实的化学家，也因而他在进入大学时优先选择了化学业余，随后却发现和本人设想中相差甚远，机缘巧合下他接触了计算机基础课并学习了 FORTRAN 语言编程，彼时的情绪如同是哥伦布发现了美洲新大陆，趣味和激情也在悄悄间产生转移。在本科阶段，Wade 自学了计算机系的根底课程，本科毕业后胜利考进了清华大学计算机系统构造业余持续读研，在业余上，彻底从一名“化学家”转为了一名“开发者”。 斗转星移间，少年时期的特立独行逐步被覆盖在工夫洪流中，在接下来的十余年职场生涯里，Wade 成为了一名越发成熟的开发者乃至是管理者——他发现过 HP-UX 操作系统的 Bug、Solaris 上 C++ 编译器的 Bug（那时候开源软件还只是个传说，这些操作系统级别的产品都只能由各个厂商的相应部门解决），做过不少架构设计、开发、性能剖析方面的工作，比拟善于写 Functional Spec……从 EMC 到腾讯再到甲骨文，Wade 的开发和职场经验越来越丰盛。 “我始终是做根底软件的，对根底软件有一种说不清道不明的感情，已经我也尝试过在两家企业做利用和解决方案团队的负责人，但总是提不起激情。在我此前的工作中，常常会和数据库产品打交道，也理解过时序数据库这个畛域。进入中年之后，我始终想要寻找到一个可能重燃本身冒险精力的工作，在接触到 TDengine 时，我感觉本人找到了。” 45 岁转换赛道，想把 TDengine 打造成时序数据库的代名词在行将进入 45 岁之际，Wade 抉择退出了涛思数据，负责 TDengine 的研发管理工作。在做出这一决定之前，他从产品、团队、赛道三个方面进行了调研剖析。 从产品层面来说，作为 Wade 已经接触和试用过的一款数据库产品，TDengine 笨重的安装包、超群的数据插入速度和存储查问性能给了他十分粗浅的印象。但相比于产品，从一个管理者的角度来说，一个高素质的团队可能更吸引他的退出，而想要打造一个高水平的团队、重视产品和技术的企业文化，又和公司创始人密不可分，而 Wade 此前对 Jeff（涛思数据创始人陶建辉）也早有耳闻，认为他是一个极具极客精力且充斥守业激情的人。 除此之外，一个成熟的职场人在抉择职场方向时，赛道是否具备可继续倒退的后劲也是关注点之一。在 Wade 看来，时序数据库比关系数据库或者说强统一事务数据库的门槛要更低一些，在这个赛道上胜利的概率显然要更大一些。但门槛略低也不等于就容易做好，入行容易拔尖难，想要在一个行业中锋芒毕露，产品力还是基本，产品的利用化落地同样要害，而这两点也始终都是 TDengine 在着重发力的倒退方向。 ...

监控零碎TDengine 是一款开源、高性能、分布式 反对 SQL 的时序数据库。TDinsight 是应用内置监控数据库和 Grafana 对 TDengine 进行监控的解决方案。一个监控零碎须要解决哪些问题？ 数据从何而来？如何存储数据？如何展现数据？这几个问题都有许多解决方案： 数据采集：collectd / StatsD / Telegraf 展现数据：Grafana 存储数据：TDengine / InfluxDB / MySQL ...... TDengine 非常适宜用于监控零碎的数据存储。 TelegrafTelegraf, a server-based agent, collects and sends metrics and events from databases, systems, and IoT sensors. Written in Go, Telegraf compiles into a single binary with no external dependencies–requiring very minimal memory.上手体验Linux(cent os)前置工作 确认taosAdapter是否工作 装置telegraf配置 在配置文件 /etc/telegraf/telegraf.conf中减少输入配置 db=telegraf，用于指定存储监控内容的库，须要提前创立 减少输入（以http输入至TDengine为例）[[outputs.http]] url = "http://127.0.0.1:6041/influxdb/v1/write?db=telegraf" method = "POST" timeout = "5s" username = "root" password = "taosdata" data_format = "influx" influx_max_line_bytes = 250启动 ...

注意事项：强烈建议有降级需要的用户间接降级至各个版本分支的最新版本（ https://www.taosdata.com/all-... ）；TDengine 在降级后不能够做版本回退。因而，请务必依据注释的降级流程，提前做好备份，从而避免出现不可预期的问题；降级完结后，请第一工夫验证数据库服务的完好性；对于应用 RESTful 接口服务的用户，降级完结后，要记得用 systemctl start taosadapter 启动 taosadapter 服务，以保障 RESTful 接口可用；以 2.0.16 为分界线，降级步骤稍有不同，请留神查看本人的数据库服务版本。（版本查看形式：在服务端的 taos shell 里执行 select server_version()）；注释：2.0-2.0.15 版本，向上降级到 2.0.16 以及之后的任意版本，操作如下（蕴含集群与单机）：降级前，请在服务器上筹备好新版本的安装包（下载链接：https://www.taosdata.com/all-...）；确保以后节点处于失常工作的状态：show dnodes: 各 dnode status 均为 ready；show mnodes: 各 mnode role 均为 master 或者 slave；show 库名.vgroups: 各 vgroup status 均为 ready，且 role 均为 master 或者 slave；数据库读写失常；在所有节点进行数据库服务：systemctl stop taosd备份所有节点数据文件目录下（默认为：/var/lib/taos）所有内容到其余门路或存储（vnode_bak 可清空）；cd 进入各个节点数据文件目录下；ls -ltR | grep -i “wal” 查看”数据文件目录下所有 wal 文件是否为空；如果为空，进入步骤 9；如果非空，则启动该节点的数据库过程再敞开。肯定要等到所有节点的该文件为空，能力进行下一步。（如果重复启停该目录依然不能为空，请分割 TDengine 官网取得反对）；在数据库服务处于进行的状态下，在所有节点一一执行 rmtaos（卸载形式取决于安装包类型，可参考：https://www.taosdata.com/blog...)，而后装置新版本install.sh（或其余装置形式，参考同上）；所有节点降级结束后，在各个节点的 Linux shell中应用 taosd –force-keep-file 命令启动服务过程；新开一个 linux 终端，输出 taos -h xxxx -p 命令（依据理论状况填写用户明码），再次执行步骤 2 ，并对数据完整性进行查看。确认无误后，可勾销掉 taosd –force-keep-file 的过程。从新以 systemctl start taosd 形式启动 taosd 服务。【可选】按需执行： systemctl start taosadapter；再次执行步骤 2 ，并对数据完整性进行查看。查看无误后，降级结束。2.0.16 版本及之后的版本，向上降级到任意版本，操作如下（蕴含集群与单机）：降级前，请在服务器上筹备好新版本的安装包（下载链接：https://www.taosdata.com/all-...）；确保以后节点处于失常工作的状态：show dnodes: 各 dnode status 均为 ready；show mnodes: 各 mnode role 均为 master 或者 slave；show 库名.vgroups: 各 vgroup status 均为 ready，且 role 均为 master 或者 slave；数据库读写失常；在所有节点进行数据库服务：systemctl stop taosd备份所有节点数据文件目录下（默认为：/var/lib/taos）所有内容到其余门路或存储（vnode_bak 可清空）；cd 进入各个节点数据文件目录下；ls -ltR | grep -i “wal” 查看”数据文件目录下所有 wal 文件是否为空；如果为空，进入步骤 9；如果非空，则启动该节点的数据库过程再敞开。肯定要等到所有节点的该文件为空，能力进行下一步。（如果重复启停该目录依然不能为空，请分割 TDengine 官网取得反对）；在数据库服务处于进行的状态下，在所有节点一一执行 rmtaos（卸载形式取决于安装包类型，可参考：https://www.taosdata.com/blog...)，而后装置新版本 install.sh（或其余装置形式，参考同上）；在各个节点启动数据库服务：systemctl start taosd；【可选】按需执行： systemctl start taosadapter；再次执行步骤 2 ，并对数据完整性进行查看。查看无误后，降级结束。想理解更多 TDengine Database的具体细节，欢送大家在GitHub上查看相干源代码。 ...

小 T 导读：在拓斯达的智能工厂整体解决方案我的项目中，传统的关系型数据库曾经无奈高效解决时序数据，在加载、存储和查问等多个方面都遇到了挑战，最终他们抉择了 TDengine 来匹配工业传感器数据的利用剖析场景。本文将讲述他们利用 TDengine 的具体实际。企业简介广东拓斯达科技股份有限公司（简称：拓斯达，股票代码：300607）是广东省首家登陆创业板的机器人骨干企业。拓斯达保持“让工业制作更美妙”的企业使命，通过以工业机器人、注塑机、CNC为外围的智能配备，以及管制、伺服、视觉三大核心技术，打造以核心技术驱动的智能硬件平台，为制作企业提供智能工厂整体解决方案。 我的项目介绍在工业畛域， 生产、测试、运行阶段都可能会产生大量带有工夫戳的传感器数据，这都属于典型的时序数据。时序数据次要由各类型实时监测、查看与剖析设施所采集或产生，波及制作、电力、化工、工程作业等多个行业，具备写多读少、量十分大等典型个性。 在咱们的业务中，传统的关系型数据库（Relational Database）曾经无奈高效解决时序数据，在加载、存储和查问等多个方面都遇到了挑战。次要问题能够汇总如下： 写入吞吐低：单机写入吞吐量低，很难满足时序数据千万级的写入压力；存储老本大：在对时序数据进行压缩时性能不佳，需占用大量机器资源；保护老本高：单机零碎，须要在下层人工进行分库分表，保护老本高；查问性能差：海量实时数据的聚合剖析性能差。为了更好地满足时序数据的解决需要，咱们决定进行数据库选型调研，最终抉择了时序数据库（Time-Series Database）TDengine。 事实证明，TDengine 针对时序数据的写入、存储、索引、查问等方面都进行了特定的优化，从而实现了更优的数据加载、数据压缩、查问写入性能，十分匹配工业传感器数据的利用剖析场景。 抉择 TDengine 的理由与通用数据库相比，TDengine 的压缩率体现惊人，外围起因是其采纳列式存储，而且采纳了二阶段压缩策略，还针对不同数据类型采取了不同的压缩算法，这种压缩机制使其压缩率远超其余数据库。 此外 TDengine 还领有极高的读写性能，并且读写速度受数据存储规模的影响微不足道，要晓得通用数据库的数据量一旦过百万级，读写速度就会有显著降落，之前咱们做过一次 MySQL 批量插入数据的测试，性能差距显著，这也是在大量级数据存储下咱们会抉择TDengine的重要起因之一。具体来说，TDengine 劣势如下： 数据的读写速度快且自带工夫戳，应用 SQL 进行数据库操作，简略易学，反对简单查问数据压缩率高，大量级的数据也不会占据过多存储空间，可导出数据进行备份领有交换社区和交换群，遇见问题能够和 TDengine 的其余使用者一起探讨，而且官网的同学也能提供及时的帮忙当然，世上没有完满的数据库，咱们在利用之后总结出了两点待改良的中央： 无奈应用可视化软件如 Navicat 等进行数据库操作（TDengine GUI）目前还没有 Windows 版的服务端，像咱们上一个客户，只在本地 Windows 上应用程序，在没有装置虚拟机和部署到服务器的状况下，就无奈部署 TDengine但每一款产品都是在发现问题和改良问题的步调中逐步提高的，而且对于咱们的业务实现来说，TDengine 不存在显著的短板。没有最优的数据库，在场景匹配的状况下，咱们最终采纳了 TDengine。 落地实际平台架构咱们是通过网关采集设施数据推送到 MQTT，Java 后端监听到后会写入 TDengine，在后端按需要查询处理后再把数据返回给前端。 具体来说，网关会先读取后盾公布的上行规定，在采集到设施数据后，应用上行规定对数据进行解决计算后再将后果返回给上行规定模块，后盾监听到后，会连贯 TDengine 进行数据库表的创立批改和数据写入。之前在云平台咱们应用过 Kafka 进行数据的公布订阅，当初所有环境都改为 MQTT 了。 超级表及建模思路在利用 TDengine 时，咱们建设了流水数据库 “iot_platform” 用来存储网关传来的数据，便于日后查问应用。咱们遵循“一个采集点一张表，一类数据一个超级表”的思路来建表，在具体实际上设计了两张超级表，一张是用于存储 log 指令内容的“logs”表，另一张是用于存储其它指令内容的“datas”表，数据类型根本为电流电压、设施状态等。在进行数据存储时首先会对数据加以判断，再决定将数据存储到哪张表里。 落地成果运行一段时间后，TDengine 的查问、写入速度齐全能够满足咱们目前的客户需要，最慢的分钟级，最快的能达到 1 秒一条；一个设施一天最多能写入近十万条数据，近千个设施同时写入也齐全没有问题，相较于之前，写入速度晋升了数十倍。查问数据在以月为单位的工夫范畴内没有过于显著的提早，整体的数据压缩比大略是1/10，目前每天产生的数据量在数G左右。 流水数据查问查问某一时间段内的流水数据，应用查问语句： SELECT datagettime as ts , ${dataName} as data FROM ${tableName} <where> uuid = ${uuid} <if test="startTime != null "> and datagettime > #{startTime} </if> <if test="endTime != null "> and #{endTime} > datagettime </if> and ${dataName} is not null </where> limit 0, ${countLimit}聚合函数计算一天的数据 ...

作者 | 刘垚 编辑 | 尔悦 小 T 导读：在应用或者实现分布式数据库（Distributed Database）时，会面临把一个表的数据依照肯定的策略扩散到各个数据库节点上的状况，随之而来的是多节点数据查问复杂性的问题，例如 Join 和子查问。本文将会为你解读分布式数据库下子查问和 Join 等简单 SQL 如何实现，来帮忙你更好地解决上述问题。首先简略讲一下 SQL 的执行过程： SQL ==> Parser ==> Translate & Semantic Check ==> Optimizer ==> Coordinator ==> Executer Parser 产生的是语法树，即 Abstract Syntax Tree；Translate & Semantic Check，这一步会从 Catalog 读取元数据，用元数据欠缺语法树，便于 Optimizer 应用。例如：常见的 select from tableA，个别会在这一步把“”换成 tableA 的列；Optimizer 产生的是优化之后的逻辑执行打算，即 Optimized Logical Plan，执行打算是个有向无环图，即 DAG；Coordinator 负责散发逻辑执行打算给各个节点去计算；Executer 会把逻辑执行打算转成物理执行打算，即 Physical Plan。开源的数据库有很多，咱们能够联合一些支流数据库的源代码来了解子查问和 Join 的实现形式，比方关系型数据库 ：Impala、Presto、ClickHouse，时序数据库（Time- Series Database）： TDengine 等。上面从子查问和 Join 两局部进行剖析。 子查问局部逻辑执行打算有多种 Node，别离对应着 SQL 中的各种计算，包含 Scan Node、Join Node、Aggregate Node、Sort Node、Project Node 等等，相应的物理执行打算的算子为 Scan Operator 、Join Operator、Aggregate Operator、Sort Operator、Project Operator 等等。而数据库个别没有计算子查问的算子，这是因为将形象语法树转成逻辑执行打算之后，就曾经没有子查问的概念了，其运行逻辑是数据算子之间自下而上逐层传递，并逐层计算，并不特地计算子查问。上面讲一下分布式数据库针对子查问的一些相干解决。 ...

在 OPPO 的穿戴产品的手环/手表类业务中，产生的数据类型为时序数据，具备写入量微小且存在离线/历史数据补录（更新）的解决需要。此前应用的 MongoDB/MySQL 集群计划，后端存储压力较大，须要常常扩盘，针对此痛点，OPPO 云计算中心智慧物联云团队尝试调研比照了几款时序数据库（Time-Series Database）产品，试图寻找一个降本增效的解决方案。 除了存储压力外，咱们进行数据库替换还有一个比拟重要的起因，就是 MySQL 和 MongoDB 的各个集群都比拟独立，保护和需要开发成本绝对较高。 以上是三款 Database 的初步调研后果，TSHouse 是 OPPO 云监控时序数据库，其底层为 Prometheus 的 TSDB 存储引擎，目前不反对历史数据和乱序写入；InfluxDB 对历史数据写入会进行二次压缩，影响性能，这两款数据库都不满足当下的数据处理需要。初步钻研 TDengine 后，咱们发现其作为国产时序数据库开源产品，不仅能够满足历史数据高效写入，还领有较高的压缩能力。随后，咱们抉择对 TDengine 进行了比拟具体的产品调研和性能测试。 TDengine 产品与能力调研产品调研某个数据表的构造如下：咱们写入 60 万行数据，到 MySQL（目前局部业务部署在 MySQL 集群）和 TDengine 的 4C 12G 容器上，对 CPU/内存/磁盘进行察看。测试发现 CPU 和内存耗费根本持平的状况下，TDengine 的落盘数据是 MySQL 环境的1/4左右。 同时，咱们在不同规格容器及物理机场景下进行 TDengine 写入测试，局部记录如下：须要阐明的是，对于不同业务场景须要进行理论测试，能力确定适宜该业务的部署参数。在整个测试过程中，TDengine 工程师们也为咱们进行了及时答疑和帮忙。 能力调研随后咱们依据 TDengine 丰盛的产品手册，对一些要害能力进行了验证，包含数据管理、数据写入、聚合计算、集群扩容、故障可靠性保障等场景。 在数据管理上，TDengine 的元数据与业务数据是拆散开来的。如下图所示，Mnode 负责管理元数据信息；单个 Vnode 能够寄存多个表数据，相当于相当于程度分片，单个表的数据，又能够持续依照日期分片。在数据写入逻辑上，整体和 LSM 相似：WAL，内存块，磁盘 FILE。在 TDengine 中，数据在文件中是按块间断存储的。每个数据块只蕴含一张表的数据，且数据是依照工夫主键递增排列的。数据在数据块中按列存储，这样使得同类型的数据可能寄存在一起，大大提高了压缩比，节俭了存储空间。TDengine 是 10 天一组 data file，data file 里的 .data 文件只进行追加，且后续不会进行压缩。这种益处是：对历史数据和乱序极其敌对，十分实用于 IoT 场景；没有压缩也就缩小了写入之后的资源耗费，保障了较好的读写性能。 ...

小 T 导读：作为开创团队成员之一，廖浩均在 2017 年就正式退出了涛思数据，彼时整个团队才不过寥寥五个人，TDengine 也才诞生不久。作为一位毕业于中科院计算所的计算机利用技术业余博士，廖浩均为什么会决定从一家稳固的上市企业转移阵地到一家数据库初创公司？在进入涛思数据之后，他又见证和参加了 TDengine 的哪些扭转与提高？立足当下展望未来，携手 TDengine，他会如何走好接下来的路？在对廖浩均的采访记录中，这些问题的答案也曾经跃然纸上。创始人“三顾茅庐”，博士“大佬”做出最终抉择作为一个学霸，廖浩均的学业生涯是比拟顺畅的，从北京师范大学信息管理与信息系统业余毕业后，他十分顺利地就考取了中科院计算所（中科院研究生院）计算机利用技术业余的硕士，接着一路绿灯开挂式地走完了博士学位。在毕业之际，因为盲目并不太善于科研畛域的工作内容，他决然而然决定进入工业界待业。 但一贯雷厉风行的廖浩均却在承受到涛思数据递出的橄榄枝时犹豫再三，在 Jeff（涛思数据创始人陶建辉） 的“三顾茅庐”后才终于下定决心。 在正式退出涛思前，廖浩均在一家绝对稳固的上市企业中工作，循序渐进的工作中没有多少惊喜也没有太多的波澜，长此以往他便生出了换份工作的想法，而恰逢其时，通过读书期间实验室师兄的推荐，他结识了正在进行人生中第三次守业的 Jeff。提起来和 Jeff 的初次见面和沟通，廖浩均依然历历在目。 “在和 Jeff 电话简略聊过后，我打算去望京科技园实地访问，过后感觉时序数据库（Time-Series Database）这个方向还是很有意思的，Jeff 也是一个相当充斥激情的人。但两次交换后我依然无奈下定决心退出，次要来源于我对本人的顾虑，尽管我之前做过数据库的相干工作，然而曾经有一段时间没有接触数据库技术了，我有些放心本人无奈胜任。” 带着这种虚心的态度，廖浩均决定要和 TDengine 这款产品再彼此多理解一些。在随后几次与 Jeff 更深度的沟通下，他逐步为这位年近 50 却仍旧奋斗在代码创作第一线上的创始人的激情和保持折服，也为 TDengine 这款时序数据库所深深吸引，同时也看到了物联网、时序数据库畛域广大的市场时机，他决定挑战一下本人，抓住这次转换赛道的机会。 “在与 Jeff 的面对面交换中，我更加深刻地理解了 TDengine，也看到了 Jeff 的技术能力——做分布式通信的专家开始跨界搞数据库，而且竟然应用不带插件的 vim 编程。此外，我发现过后的涛思数据尽管‘庙小’，但包容的‘大神’却并不少，不仅有刚毕业的新锐海归，还有工业数据库畛域的资深专家。总的来说，感动我退出涛思数据的起因有三点：Jeff 是一个很厉害的专家，他的工程能力和产品认知的敏锐性在我意识的人中无出其右；时序数据这个方向也很有前景；我本人应该可能胜任这个挑战。” Jeff 的“穷追猛打”下，廖浩均心中沉寂已久的技术激情又开始蠢蠢欲动了，最终他信心 All In 时序数据库，而这个抉择的正确性也在前面几年工夫里失去了印证。 “其实，在退出涛思之前，我并不是很理解时序数据库这个细分畛域中的产品。在2017年，时序数据库这个概念对国内的诸多用户来说还是太前沿，然而万物互联和物联网的迅猛发展的确都能切身体会到。一般来说，此前只有公交车、出租车等机动车上装置有用于上传车辆状态和地位数据的专门设施，起初在智能穿戴设施、2017 年最火爆风口‘共享单车’、主动驾驶等方向上都会产生大量的时序数据……毫无疑问，这些场景都在激发着时序数据利用和治理的需要。依照这个趋势倒退上来，时序数据库的倒退势不可挡，在我看来，这种直观的感触和体验最有说服力。” 一个被申请了专利的设计思路，将工夫压缩晋升近 50 倍在退出涛思数据后，廖浩均次要负责查询处理相干的工作，在读书时他就接触过大量空间数据相干的工作，钻研畛域次要集中在空间数据索引和查问算法两大方向上，因而在解决工作时也绝对比拟得心应手。“我在入职两三天后就上手了工作，做的第一件事就是减少 TDengine 的聚合查问性能。” 廖浩均的一个直观感触是，在一个全新的设计理念下发展设计以及进行工程开发，没有其余的任何可借鉴的实践经验，真的十分考验技术人的思考能力和创造性。例如 TDengine 中的多表架构设计，其最开始的状态是采纳每个表程序查问迭代来实现，起初发现这种办法效率太差，百万级别的表查问耗时都会达到小时级别。 “在某天下班前，我打算在服务器上跑一下刚实现的查问代码，后果等了快 10 分钟还没有出后果，起初发现查问跑了 1 个多小时当前过程挂起，最初后果也没进去。过后就头大了，这种查问效率基本没法应用，可是怎么改却没有现成的思路，只能本人尝试。起初憋了好几天，迸发出的灵感也帮忙我打造出了全新的解决逻辑，前面我将思路与 Jeff 简略交换了一下，失去认可后就开始入手调整代码。调整后初步测试后果，就将工夫压缩到分钟级别，晋升近 50 多倍。随着后续又进行了一系列工程优化办法，调整实现当前间接将工夫压缩到秒级。这是我印象中特地粗浅的一件事。” 在 TDengine 的发展史中，正是这个设计让多表交互式查询处理成为了可能，为 TDengine 可能高效进行查询处理服务胜利奠基。之后这个设计思路申请了 PCT 寰球专利爱护，也成为廖浩均职业生涯中的又一个闪光点。 ...

小 T 导读：作为一款典型的时序数据库（Time-Series Database）产品，TDengine 被宽泛使用于物联网、工业互联网、车联网、IT 运维、能源、金融等畛域。TDengine 自身提供了大量的计算函数，在很多场景下，用户都不须要本人编程来实现某些计算性能。当然，随着场景的一直增多，用户提出了越来越多的需要，TDengine 也在一直地演进和晋升。 通过研发同学的不懈努力，TDengine 2.6 版本正式公布了。该版本带来泛滥新个性，一方面是优化了 SQL 语法，一方面是减少了大量的计算函数，以反对用户的更多应用场景。该版本还修复了之前版本存在的一些 bug。 上面具体来看一下，2.6 版本带来的重要更新。 SQL 语法优化1.在新的 SQL 语法中，TIMESTAMP 反对缩写在 SQL 语句中用到的工夫戳，能够只提供日期，比方 “2022-02-02”，零碎主动将其转换为“2022-02-02 00:00:00”。 比方在之前的版本中，执行以下语句： taos> select last(ts), sum(f1) from t1987 where ts>="2017-07-15" interval(1m) ;Dengine 会报错： DB error: invalid SQL: invalid timestamp (0.000065s) 咱们必须这样写： select last(ts), sum(f1) from t1987 where ts>="2017-07-15 00:00:00.000" interval(1m)在 2.6 版本中，能够只提供日期局部了。 2.加强了 LIKE 通配符应用的校验规定当 LIKE 匹配字符为字符串时，SQL 才能够被解析。 3.新增多个工夫窗口关键词_WSTART：窗口起始工夫 _WSTOP：窗口完结工夫 _WDURATION(precision)：窗口持续时间 _QSTART: 查问起始工夫 _QSTOP: 查问完结工夫 ...

小 T 导读：想用 Spark 对接 TDengine？保姆级教程来了。0、前言TDengine 是由涛思数据开发并开源的一款高性能、分布式、反对 SQL 的时序数据库（Time-Series Database）。 在上一篇文章中，咱们示范了如何应用 Apache Flink 连贯 TDengine，应用 Apache Spark 的小伙伴们曾经急不可待地期待续集了。 绝对于 Flink，Spark 对接起来就简略多了。 1、技术实现Spark 自身封装了 JDBC 的办法，所以咱们间接应用 Spark 官网的示例代码就能够实现对接了。 2、示例代码package com.taosdata.java; import org.apache.spark.sql.Dataset;import org.apache.spark.sql.Row;import org.apache.spark.sql.SaveMode;import org.apache.spark.sql.SparkSession;import org.apache.spark.sql.jdbc.JdbcDialect;import org.apache.spark.sql.jdbc.JdbcDialects;public class SparkTest{ public static void main(String[] args) { // 数据库配置 String url = "jdbc:TAOS://u05:6030/tt?user=root&password=taosdata"; String driver = "com.taosdata.jdbc.TSDBDriver"; String dbtable = "t1"; SparkSession sparkSession = SparkSession.builder() .appName("DataSourceJDBC") // 设置利用名称 .master("local") // 本地单线程运行 .getOrCreate(); // 创立DataFrame Dataset<Row> df = sparkSession .read() // 返回一个DataFrameReader，可用于将非流数据作为DataFrame读取 .format("jdbc") // JDBC数据源 .option("url", url) .option("driver", driver) .option("query", "select * from tt.meters limit 100") // 二选一，sql语句或者表 .load(); // 将DataFrame的内容显示 df.show(); df.write() // 返回一个DataFrameWriter，可用于将DataFrame写入内部存储系统 .format("jdbc") // JDBC数据源 .mode(SaveMode.Append) // 如果第一次生成了，后续会追加 .option("url", url) .option("driver", driver) .option("dbtable", "test.meters") // 表名 .save(); sparkSession.stop(); }}3、简略测试 JNI 读写1) 环境筹备：a) Spark 装置&启动： ...

小 T 导读：想用 Flink 对接 TDengine？保姆级教程来了。 0、前言TDengine 是由涛思数据开发并开源的一款高性能、分布式、反对 SQL 的时序数据库（Time-Series Database）。 除了外围的时序数据库性能外，TDengine 还提供缓存、数据订阅、流式计算等大数据平台所须要的系列性能。然而很多小伙伴出于架构的思考，还是须要将数据导出到 Apache Flink、Apache Spark 等平台进行计算剖析。 为了帮忙大家对接，咱们特地推出了保姆级课程，包学包会。 1、技术实现Apache Flink 提供了 SourceFunction 和 SinkFunction，用来提供 Flink 和内部数据源的连贯，其中 SouceFunction 为从数据源读取数据，SinkFunction 为将数据写入数据源。 与此同时，Flink 提供了 RichSourceFunction 和 RichSinkFunction 这两个类（继承自AbstractRichFunction），提供了额定的初始化(open(Configuration))和销毁办法(close())。 通过重写这两个办法，能够防止每次读写数据时都从新建设连贯。 2、代码实现残缺源码：https://github.com/liuyq-617/... 代码逻辑： 1) 自定义类 SourceFromTDengine用处：数据源连贯，数据读取 package com.taosdata.flink;import org.apache.flink.configuration.Configuration;import org.apache.flink.streaming.api.functions.source.RichSourceFunction;import com.taosdata.model.Sensor;import java.sql.*;import java.util.Properties;public class SourceFromTDengine extends RichSourceFunction<Sensor> { Statement statement; private Connection connection; private String property; public SourceFromTDengine(){ super(); } @Override public void open(Configuration parameters) throws Exception { super.open(parameters); String driver = "com.taosdata.jdbc.rs.RestfulDriver"; String host = "u05"; String username = "root"; String password = "taosdata"; String prop = System.getProperty("java.library.path"); Logger LOG = LoggerFactory.getLogger(SourceFromTDengine.class); LOG.info("java.library.path:{}", prop); System.out.println(prop); Class.forName( driver ); Properties properties = new Properties(); connection = DriverManager.getConnection("jdbc:TAOS-RS://" + host + ":6041/tt" + "?user=root&password=taosdata" , properties); statement = connection.createStatement(); } @Override public void close() throws Exception { super.close(); if (connection != null) { connection.close(); } if (statement != null) { statement.close(); } } @Override public void run(SourceContext<Sensor> sourceContext) throws Exception { try { String sql = "select * from tt.meters"; ResultSet resultSet = statement.executeQuery(sql); while (resultSet.next()) { Sensor sensor = new Sensor( resultSet.getLong(1), resultSet.getInt( "vol" ), resultSet.getFloat( "current" ), resultSet.getString( "location" ).trim()); sourceContext.collect( sensor ); } } catch (Exception e) { e.printStackTrace(); } } @Override public void cancel() { }} 2) 自定义类 SinkToTDengine用处：数据源连贯，数据写入 ...

Hi，TDengine 的用户敌人们，为避免过多的共性问题困扰大家，不便大家学习、排汇教训，从明天开始咱们会对近期社区内用户遇到的共性问题进行精选、汇总，每两周给大家带来一次分享。 这是此类专栏的第一期内容，为大家分享如下七个常见问题： 客户端连贯串如何保障高可用？Java 利用应用 taos-jdbcdriver 连贯 TDengine 时， RESTful 与原生 ( JNI ) 接口性能相比如何，该如何选型？TDengine 如何做表关联？是应用 JOIN 吗？为什么 RESTful 接口无响应、Grafana 无奈增加 TDengine 为数据源、TDengineGUI 选了 6041 端口还是无奈连贯胜利？TDengine 数据备份工具 taosdump 如何应用？Windows 客户端无奈失常显示中文字符？产生了 OOM 怎么办？ 1. 客户端连贯串如何保障高可用？本周有较多的用户提到了这个问题，相似的还有 「如何给多节点 TDengine 集群的链接配置高可用」。这个问题时常呈现在社区中，DBA、运维同学较为关怀。咱们曾经整顿成了文章，详情可看博客：「 TDengine 如何做到客户端高可用 」 2. Java 利用应用 taos-jdbcdriver 连贯 TDengine 时， RESTful 与原生 ( jni ) 接口性能相比如何，该如何选型？应用 RESTful 连贯时，不依赖 TDengine 客户端驱动，能够跨平台，RESTful 连贯反对所有能运行 Java 的平台。原生连贯反对的平台则和 TDengine 客户端驱动反对的平台统一。 因而 RESTful 相比于原生连贯应用起来更加灵便、不便，但采纳 RESTful 的形式连贯，其性能相较于原生连贯会低 30% 左右。 举荐在每秒写入量小于 200 万条记录的场景下，优先选择 RESTful 。用户也可依据本人场景做性能测试，若应用 RESTful 连贯时性能齐全能满足业务操作需要则优先选择 RESTful ，反之抉择原生连贯。 ...

当初支流的时序数据库的确集群计划大多数都抉择闭源，除了从技术角度上来看，商业的考量也是泛滥大厂必须思考的元素之一。TDengine 作为一款全自研的开源软件，继2019年单机版开源后，在2020年也发表集群版正式开源。这意味着，在集群搭建方面，对于研发资源薄弱、工夫精力都无限的企业来说，无疑是拨云见日的一则好消息。 正在苦寻计划的技术人，或者正在做技术选型的领导者们，欢送大家移步我司官网，下载和测试 返回官网，查看更多 简略的广告之后，还是要用真正的技术谈话，也为苦苦寻求技术计划的搭档们提供一种新的思路。对于TDengine 集群的设计思路，能够从以下四方面来简略形容。（彩蛋！结尾有视频微课堂解说，不想看文字的搭档能够间接拉到最初呦～） 1、集群与次要逻辑单元TDengine是基于硬件、软件系统不牢靠、肯定会有故障的假如进行设计的，是基于任何单台计算机都无足够能力解决海量数据的假如进行设计的。因而TDengine从研发的第一天起，就依照分布式高牢靠架构进行设计，是齐全去中心化的，是程度扩大的，这样任何单台或多台服务器宕机或软件谬误都不影响零碎的服务。 通过节点虚拟化并辅以自动化负载平衡技术，TDengine能最大限度地利用异构集群中的计算和存储资源。而且只有数据正本数大于一，无论是硬软件的降级、还是IDC的迁徙等都无需进行集群的服务，极大地保证系统的失常运行，并且升高了系统管理员和运维人员的工作量。 上面的示例图上有八个物理节点，每个物理节点被逻辑的划分为多个虚构节点。 图例：物理节点(dnode)、虚构数据节点(vnode)、虚构数据节点组(vgroup)、虚构治理节点(mnode) 2、一典型的操作流程为解释vnode, mnode, taosc和利用之间的关系以及各自表演的角色，上面对写入数据这个典型操作的流程进行分析。 利用通过JDBC、ODBC或其余API接口发动插入数据的申请。taosc会查看缓存，看是有保留有该表的meta data。如果有，间接到第4步。如果没有，taosc将向mnode收回get meta-data申请。mnode将该表的meta-data返回给taosc。Meta-data蕴含有该表的schema, 而且还有该表所属的vgroup信息（vnode ID以及所在的dnode的IP地址，如果正本数为N，就有N组vnodeID/IP)。如果taosc迟迟得不到mnode回应，而且存在多个mnode,taosc将向下一个mnode发出请求。taosc向master vnode发动插入申请。vnode插入数据后，给taosc一个应答，示意插入胜利。如果taosc迟迟得不到vnode的回应，taosc会认为该节点曾经离线。这种状况下，如果被插入的数据库有多个正本，taosc将向vgroup里下一个vnode收回插入申请。taosc告诉APP，写入胜利。3、数据分区vnode(虚构数据节点)保留采集的时序数据，而且查问、计算都在这些节点上进行。为便于负载平衡、数据恢复、反对异构环境，TDengine将一个物理节点依据其计算和存储资源切分为多个vnode。这些vnode的治理是TDengine主动实现的，对利用齐全通明。 对于独自一个数据采集点，无论其数据量多大，一个vnode（或vnode group, 如果正本数大于1）有足够的计算资源和存储资源来解决（如果每秒生成一条16字节的记录，一年产生的原始数据不到0.5G），因而TDengine将一张表的所有数据都寄存在一个vnode里，而不会让同一个采集点的数据分布到两个或多个dnode上。而且一个vnode可存储多张表的数据，一个vnode可包容的表的数目由配置参数sessionsPerVnode指定，缺省为2000。设计上，一个vnode里所有的表都属于同一个DB。因而一个数据库DB须要的vnode或vgroup的个数等于：数据库表的数目/sessionsPerVnode。 创立DB时，零碎并不会马上分配资源。但当创立一张表时，零碎将看是否有曾经调配的vnode, 而且是否有空位，如果有，立刻在该有空位的vnode创立表。如果没有，零碎将从集群中，依据以后的负载状况，在一个dnode上创立一新的vnode, 而后创立表。如果DB有多个正本，零碎不是只创立一个vnode，而是一个vgroup(虚构数据节点组)。系统对vnode的数目没有任何限度，仅仅受限于物理节点自身的计算和存储资源。 sessionsPerVnode的设置须要思考具体场景，创立DB时，能够个性化指定该参数。该参数不宜过大，也不宜过小。过小，极其状况，就是每个数据采集点一个vnode, 这样导致系统数据文件过多。过大，虚拟化带来的劣势就会丢失。给定集群计算资源的状况下，整个零碎vnode的个数应该是CPU核的数目的两倍以上。 4、负载平衡每个dnode(物理节点)都定时向 mnode(虚构治理节点)报告其状态（包含硬盘空间、内存大小、CPU、网络、虚构节点个数等），因而mnode理解整个集群的状态。基于整体状态，当mnode发现某个dnode负载过重，它会将dnode上的一个或多个vnode挪到其余dnode。在移动过程中，对外服务持续进行，数据插入、查问和计算操作都不受影响。负载平衡操作完结后，利用也无需重启，将主动连贯新的vnode。 如果mnode一段时间没有收到dnode的状态报告，mnode会认为这个dnode曾经离线。如果离线工夫超过肯定时长（时长由配置参数offlineThreshold决定），该dnode将被mnode强制剔除出集群。该dnode上的vnodes如果正本数大于一，零碎将主动在其余dnode上创立新的正本，以保证数据的正本数。 总结比拟常见的对于集群计划的问题，TDengien在设计之初就曾经思考到，这也是为什么很多企业纷纷将数据库迁徙过去的很重要的一个起因。当企业还在花十倍甚至百倍的人力物力研发和搭建本人的集成计划时，跑在后面的企业曾经借助更业余的力量和计划，实现了研发为业务赋能的承诺。 想理解更多 TDengine Database的具体细节，欢送大家在GitHub上查看相干源代码。

作者：刘健 同心源（三亚）基金 小 T 导读：同心源（三亚）基金治理有限公司是一家致力于采取迷信办法，在二级市场进行投资的私募公司。公司的团队成员均来自于国内外优良大学，创始人具备计算机博士学位，有多年的算法钻研、软件系统开发的教训。从我司的业务模式登程，业务人员次要通过数据挖掘和主动模式识别这两种形式来发现市场的交易法则。因而，咱们的工作场景是基于大量的金融数据之上的，次要包含如下几类： 国内期货市场的实时高频数据，逐笔数据等国内期货市场的历史高频数据，逐笔数据国内股票市场的高频数据，逐笔数据等国内股票市场的历史高频数据，逐笔数据根据以上数据产生的更大量级衍生数据通过多年倒退，股票市场数据量非常宏大，随着每日新数据的荡涤写入，总量变得更加水涨船高。对于十几TB的数据量，单是进行存储曾经不易，如果还要对数据进行查问下载等操作，更是难上加难。这些问题横亘眼前，也让咱们对市面上的支流数据库逐步丢失信念。 起初，通过专业人士的推荐，咱们尝试了TDengine，没想到它轻轻松松地就适配了咱们的以后业务。 具体实际与落地成果选好数据库之后咱们马上开始了搭建，并抉择了过后最新的2.1.3.2的版本部署落地，不同数据品种对应的数据库别离如下： 1）股票高频数据库，包含股票市场的历史数据+每日新增数据：这类数据每日通过Python连接器的形式，在开盘后批量导入再做剖析。其中每个表代表一个股票，共85列，以Float数据为主，共32311张。 根据上述表构造计算，当前情况每行大略有408字节的长度，而后咱们用脚本对所有表进行了行数查问，大略是320亿行。 以上述数据为根底对入库的总数据量进行下估算，粗略计算为408*320亿行，大略12TB左右，前面通过统计最终理论占用磁盘空间却只有2T左右，这令咱们非常震惊——压缩率高达16.7%。 家喻户晓，Float类型的数据压缩始终是数据库畛域的一个难题，尤其是对于行式存储的数据库更是艰难，快乐之余也非常感谢TDengine的列式存储，帮忙咱们完满解决了这个辣手的问题。 之后从官网人员处咱们得悉，在后续版本中，TDengine还对浮点类型数据做了更进一步的算法优化，压缩率还能取得大幅晋升。只不过目前须要手动编译，具体操作形式能够分割官网人员。 2）期货库：期货库是部署在另一个服务器上的，有如下三个：期货高频数据库、期货X频率数据库、期货Y频率数据库。他们别离代表着国内全副期货的高频数据和不同工夫频率的聚合数据： 1）期货高频数据库：实时记录交易所发送的tick数据 2）期货X频率数据库：依据工夫周期X设定，记录聚合后的数据 3）期货Y频率数据库：依据工夫周期Y设定，记录聚合后的数据 以上三个库别离蕴含3351、5315、5208张子表，与股票库一样，它们同样包含长期的历史数据以及实时数据。 具体的表构造如下所示： 在查问方面，因为以后咱们的查问只是针对单表进行，因而逻辑比较简单，代码如下： 此外，因为期货不存在间断多年的行情，所以对于长期的数据展现，咱们抉择用多段的每X个月数据进行拼接，查问效率十分快。例如：在TDengine客户端服务器应用Python从服务端拉取间断两个月的期货行情数据，耗时仅需0.16秒。 下图为因子1在期货菜粕上的收益曲线，从这张图中咱们也能够看出，一些其余罕用的函数比方max、last，基于TDengine的缓存等技术也都实现了毫秒级返回数据。 从“两点问题”到深刻单干仔细的读者可能也留意到了文章中的两个小问题：为什么咱们在估算原数据量时，是通过脚本来统计所有子表行数，再将其乘以单行字节，而不是间接通过TDengine的“超级表”？又为什么在文章结尾的数据分类形容中，1-4条都在后文中都看到了理论对应的数据库，然而唯独没有呈现第5条——根据以上数据产生的大量衍生数据？其实是这样，因为我的项目初期没有多表聚合查问的需要，外加为了升高数据迁徙的复杂度，因而在环境搭建初期时咱们并没有抉择超级表。 然而随着业务的不断完善，咱们将会须要更大量的数据来做更简单的剖析，这也就呈现了第5条的数据品种——根据以上数据产生的更大量级衍生数据。所以说，这部分数据将来源于咱们前面的待上线业务中。 届时，咱们将会更深刻地用到TDengine的其余外围个性，如超级表、泛滥计算函数等等。但仅就当下而言，TDengine弱小的存储能力和疾速查问曾经十分令咱们惊喜，也让咱们对将来更加深刻的单干充斥期待。 对于作者：刘健，北京航空航天大学模式识别业余硕士学历，已经供职于中国航天科技集团从事软件研发工作。2014年与敌人一起守业从事外汇、期货、股票ETF的主动交易至今。着重致力于通过数据挖掘、主动模式识别等形式在国内二级市场中进行主动量化交易。 想理解更多 TDengine Database的具体细节，欢送大家在GitHub上查看相干源代码。

> 小 T 导读：随着智慧城市的减速建设，物联设施的治理问题凸显，数字政通研发“城市治理物联网平台”对物联网设施履行监督，通过鸟瞰整体数据来发现设施问题，便于及时派单解决。面对海量物联网数据的解决，TDengine 的高效存储给了数字政通相当大的助力。 企业简介北京数字政通科技股份有限公司是北京市认证的高新技术企业和领有多项自主知识产权的软件企业，业余从事电子政务和 GIS 利用平台的开发和推广工作，为政府部门提供 GIS、MIS、OA 一体化的电子政务解决方案，并提供政府各个部门间基于数据共享的协同工作平台。 随着 5G 基站等通信工程的放慢建设，城市治理、城市平安治理成为热门话题，物联设施在咱们的社会中表演的角色也变得越来越重要，智慧燃气、智能电表、智能井盖等我的项目在泛滥城市开始布局。我的项目的疾速暴发也让“如何治理物联设施”成为一个待解的难题。 作为一个设施数据中台，由数字政通研发的“城市治理物联网平台”致力于为智慧园林、智慧井盖、智慧排水、智慧市政等城市治理我的项目的各子系统，提供数据荡涤、数据接入、数据计算、数据存储的能力。通过接入各个市区的智能设施，该平台可能提供各类设施的实时监测数据及报警数据，进一步满足各类设施的数据分析、关联剖析、历史剖析、比照剖析等需要。简略来讲，平台性能的实现就是通过鸟瞰整体数据来发现设施问题，便于及时派单解决，助力智慧城市治理。 目前，咱们曾经在全国累计接入 60 余个市区我的项目，累计单干 100 余家设施厂商，累计接入 69 种设施类型、9 万余设施量，全国范畴下日累计 5000 万数据量，全国范畴下无效报警累计 20 万 +，解决 10 万 + 报警案件。 面对海量物联网数据的解决，时序数据库 TDengine 的高效存储给了咱们相当大的助力。 技术架构剖析设施数据的解决门路如下：通过各个协定（MQ、MQTT、AMQP、HTTP、TCP、HJT212、ModBus、NB等）接入物联设施到 Kafka 中进行生产，随后进行设施数据的噪点荡涤，将有用的数据及时更新到 MySQL 以及 TDengine 中，同时依据配置的报警策略生成报警数据。 平台的报警是通过应用层来管制的，依照优先级排位如下：1-强制报警、2-具体监测项报警、3-全局报警、4-根底报警。 落地教训分享因为咱们的数据库服务泛滥，而且物联网平台次要工作是对接物联网设施，所以不同的数据库服务对硬件的需要配置要以我的项目理论接入的设施数量为衡量标准。本文案例中的场景有 57,634 个设施，对应的服务器配置为：CPU 16 核、内存 32G、硬盘 1T、带宽 120MB/s。 咱们以 TDengine 2.0.22.3 版本单正本模式落地了一个三节点的集群，备份目前依附其余形式实现。 上文中提到的 57,634 个设施属于同一类型，所以归属于同一个超级表，表构造和相干信息如下： 通过 select count(*) from iot_equip_data 能够看到，咱们以后曾经保留了 9 亿条数据。 压缩与查问成果通过查看 3 个节点的 Vnode 目录总大小，能够得悉目前数据占用总量为 8.7G。而从上述表构造咱们也能看出理论入库数据总量大略为 203GB，通过压缩后为 8.7G，压缩率达到了 4% 左右，大幅节约了存储老本。 ...