时序数据库

在数据驱动的时代，高效解决时序数据成为许多畛域的要害挑战。作为一款专一于技术创新的时序数据库（Time Series Database），TDengine 不仅在工业界备受瞩目，被泛滥的头部企业所利用，同样在学术界也失去了宽泛地认可，越来越多的高校研究生抉择将 TDengine 作为研究课题输入论文。这些高质量论文从侧面佐证了 TDengine 的高性能和泛滥优质特色、在技术创新和利用价值方面的卓越功效，造成了越来越丰盛的第三方学术材料。 从另一方面来讲，这些论文不仅为学术界提供了深刻的研究成果，同时也为企业提供了数据架构调整的贵重教训。不论是学术研究者还是企业开发者，都能从这些论文中取得一些灵感和无效信息，侥幸的或者还能找到冲破技术瓶颈的办法。为了帮忙社区开发者更间接地进行参考，咱们将这些论文材料进行了相干汇总，不便有须要的小伙伴间接查阅，节俭检索工夫。 TDengine 时序数据库在设施状态监控零碎中的利用一种基于 TDengine 的烟草工业时序数据库架构的摸索运载火箭试验大数据存储架构设计与利用基于TDengine的EAST工程数据监控零碎基于TDengine的桥梁群监测大数据平台钻研TDengine在工业畛域中的钻研与实现基于TDengine的智能电网监控零碎数据存储办法钻研基于时序数据库的陆地配备监控数据存储系统基于时序数据库的高速公路数据集成平台主动驾驶数据采集与管理系统设计与实现面向化工车间环境的实时监控零碎设计面向分布式CPS的网络实时监控零碎设计基于物模型与规定引擎的物联网数据平台的设计与实现面向 IPv6 多协定的智慧园区物联网设计与实现中药生产过程智能监控零碎设计及故障检测技术钻研基于高低压电网数据协同剖析的扰动辨识基于工业物联网的水泵产品近程检测零碎基于确定学习的轴流压气机旋转失速钻研平台实现基于工业物联网和大数据分析技术的设施故障智能预测零碎钻研在咱们汇总的泛滥论文里，你能看到 TDengine 在工业物联网、智慧园区、主动驾驶、天气预报、运载火箭、桥梁建设、烟草工业等诸多行业的大数据场景下的利用及性能体现。能够看到，从性能优化到理论利用，从分布式架构到数据安全，各畛域的钻研都在强调 TDengine 的优越性能和利用后劲。 这些钻研不仅验证了 TDengine 在解决大规模时序数据方面的杰出体现，也为企业开发者提供了一个牢靠的技术根底，让大家能更深刻地摸索数据架构的科学性。除了这些内部材料之外，TDengine 也在帮忙企业用户革新数据架构过程中，积攒了很多实战经验，这些教训大多由企业开发者执笔创作生成了用户案例，集中发表在 TDengine 的官网博客上，给到更多正在摸索数据架构改革的企业进行参考。 在数据驱动的时代，TDengine 肯定会保持进行数据技术创新，为各个领域的数据处理和剖析提供强有力的反对，也争取为学术研究者和企业开发者提供越来越丰盛和扎实的产品翻新和利用实际。如果你正面临数据处理难题，欢送增加小T vx：tdengine，和咱们的资深产品研发深刻沟通。

在大规模数据存储中，实现索引查问也是一个重难点，因为树节点存储的元素数量无限，因而就会导致在利用二叉搜寻树结构时，会因为树深度过大而造成磁盘 I/O 读写过于频繁，进而导致查问效率低下。那不同的索引区别在哪里？时序数据库（Time Series Database）又应该如何抉择索引形式实现迷信的数据结构？本文将以 TDengine 为例为大家开展剖析。 B树、B+树、LSM树B树即均衡多路查找树，也称为B-树。通常咱们形容一棵B树时须要指定它的阶数，阶数示意一个节点最多有多少个孩子节点，个别用字母 m 示意阶数。当 m 取 2 时，就是咱们常见的二叉搜寻树。B树是一种自均衡树状数据结构，能对存储的数据进行 O(log n) 的工夫复杂度进行查找、插入和删除，个别较多用在存储系统上，比方数据库或文件系统。 B+树是B树的一种变体，也属于均衡多路查找树，大体构造与B树雷同，蕴含根节点、外部节点和叶子节点，多用于数据库和操作系统的文件系统中，因为B+树外部节点不保留数据，所以能在内存中寄存更多索引，减少缓存命中率。另外因为叶子节点相连遍历操作很不便，而且数据也具备程序性，便于区间查找。 B+树每个非叶子节点寄存的元素只用于索引作用，所有数据保留在叶子节点中。一个 m 阶的B+树规定了： 有 k 个子树的两头节点蕴含有 k 个元素（B树中是 k-1 个元素），每个元素不保留数据，只用来索引，所有数据都保留在叶子节点；所有的叶子节点中蕴含了全副元素的信息，及指向蕴含这些元素记录的指针，且叶子节点自身以关键字的大小自小而大的程序链接；所有的两头节点元素都同时存在于子节点，在子节点元素中是最大（或最小）元素。因为非叶子节点中寄存的元素不存放数据，所以每一层能够包容更多的元素，即磁盘中的每一页能够寄存更多元素，这样在查找时，磁盘 IO 的次数也会缩小。另外，B+树的查找要更稳固一些，因为其所有的数据都在叶子节点，而每个叶子节点通过指针形成了一种链表构造，因而遍历数据也会简略很多。 B+树的插入和删除与B树相似，它们的区别次要有以下几点： B+树内节点不存储数据，所有数据存储在叶节点(非叶子节点并不存储真正的 data)，也因而导致查问工夫复杂度固定为 log（n）。而B树能够在外部节点同时存储键和值，因而，咱们把频繁拜访的数据放在凑近根节点的中央将会大大提高热点数据的查问效率，这种个性使得B树在特定数据反复屡次查问的场景中更加高效。B树查问工夫复杂度不固定，与 key 在树中的地位无关，最好的状况下工夫复杂度为 O(1)。B+树的叶子节点有一条链相连，而B树的叶子节点各自独立。B+树叶节点两两相连可大大增加区间拜访性，可应用在肯定范畴内查问等，而B树每个节点 key 和 data 在一起，则无奈区间查找。B+树更适宜内部存储，因为内节点无 data 域，每个节点能索引的范畴更大更准确。B树节点外部每个 key 都带着 data 域，B+树节点只存储 key 的正本，实在的 key 和 data 域都在叶子节点存储，而磁盘是分 block 的，一次磁盘 IO 会读取若干个 block，具体和操作系统无关，那么因为磁盘 IO 数据大小是固定的，在一次 IO 中，单个元素越小量就越大。这就意味着B+树单次磁盘 IO 的信息量大于B树，从这点来看B+树绝对B树磁盘 IO 次数少。B树最大的益处在于它对数据继续低落读性能的解决上，即便数据量级增大，它的读也没有放大，其神秘在于对数据进行终极长久存储时，B树是以有法则的数据结构保留在硬盘上的。这样随着数据越来越大，它仍然放弃着有序有法则的个性，即使面对成千上万的读操作，都能够遵循条件运行，缩小或防止读放大的行为。 B树/B+树在数据库存储中利用十分宽泛，它能对数据进行无效地查找，防止了读放大。此外，B树和LSM常常一起应用。数据库底层能够分为B树机制、LSM机制，两种机制各有各的长处和毛病。与B树机制截然相同，LSM机制则是缩小防止了写放大。LSM机制充分利用了内存，在内存外面开拓了一个空间，写数据优先往内存里放，写进去间接返回用户胜利，而不是像B树那样写一个，要找出谁更大谁更小，只有内存足够，就间接往内存外面填就好，当内存达到肯定的阈值后就会将内存中的数据以批量、程序的形式一次写入硬盘上，内存则重置清零再服务新的写要求。 传统数据库 MySQL、Oracle 应用的都是B树机制，而 TiDB、OceanBase 一类的数据库应用的则是优化后的 LSM 机制。TDengine 应用的是B树 + LSM机制的形式，B树存储的是元数据（次要是工夫戳+指标数据），LSM机制存储的是具体的数据，元数据以有序表构造形式进行存储，而具体数据则是追加的形式写入，这样既防止了读放大又防止了写放大。 ...

小T导读：为了帮忙利用实时获取写入时序数据库（Time Series Database） TDengine 的数据，或者以事件达到程序解决数据，TDengine 提供了相似音讯队列产品的数据订阅、生产接口。这样在很多场景下，采纳 TDengine 的时序数据处理系统就不须要再集成如 Kafka 个别的音讯队列产品，从而简化零碎设计的复杂度，升高运维老本。TDengine 3.0 对数据订阅性能又进行了优化降级，本文将具体介绍其语法规定，不便开发者及企业应用。 与 Kafka 一样，利用 TDengine 时你也须要定义 topic, 但 TDengine 的 topic 是基于一个曾经存在的超级表、子表或一般表的查问条件，即一个 SELECT 语句。你能够应用 SQL 对标签、表名、列、表达式等条件进行过滤，以及对数据进行标量函数与 UDF 计算（不包含数据聚合）。与其余音讯队列软件相比，这是 TDengine 数据订阅性能最大的劣势，它提供了更大的灵活性，数据的颗粒度能够由利用随时调整，而数据的过滤与预处理是交给 TDengine 来实现，无效地缩小传输的数据量与利用的复杂度。 消费者订阅 topic 后（一个消费者能够订阅多个 topic），能够实时取得最新的数据。多个消费者能够组成一个消费者组 (consumer group)，一个消费者组里的多个消费者共享生产进度，便于多线程、分布式地生产数据，进步生产速度；但不同消费者组中的消费者即便生产同一个 topic，也并不共享生产进度。如果订阅的是超级表，数据可能会散布在多个不同的 vnode 上，也就是多个 shard 上，这样一个生产组里有多个消费者能够进步生产效率。TDengine 的音讯队列提供了音讯的 ACK 机制，在宕机、重启等简单环境下也能确保 at least once 生产。 为了实现上述性能，TDengine 会为 WAL (Write-Ahead-Log) 文件主动创立索引以反对疾速随机拜访，并提供了灵便可配置的文件切换与保留机制，用户能够按需指定 WAL 文件保留的工夫以及大小： WAL_RETENTION_PERIOD：为了数据订阅生产，须要 WAL 日志文件额定保留的最大时长策略。WAL 日志清理，不受订阅客户端生产状态影响。单位为 s，默认为 3600，示意在 WAL 保留最近 3600 秒的数据，用户能够依据数据订阅的须要批改这个参数为适当值。WAL_RETENTION_SIZE：为了数据订阅生产，须要 WAL 日志文件额定保留的最大累计大小策略。单位为 KB，默认为 0，示意累计大小无下限。通过以上形式，咱们将 WAL 革新成了一个保留事件达到程序的、可长久化的存储引擎（但因为 TSDB 具备远比 WAL 更高的压缩率，因而不举荐保留太长时间，一般来说倡议不超过几天）。对于以 topic 模式创立的查问，TDengine 将对接 WAL 而不是 TSDB 作为其存储引擎。在生产时，TDengine 依据以后生产进度从 WAL 间接读取数据，并应用对立的查问引擎实现过滤、变换等操作，将数据推送给消费者。为了不便大家上手实操，下文将对 TDengine 数据订阅相干语法进行具体解读。 ...

小T导读：为满足地震预警数据存储、检索和解决的建设与集成需要，以及响应国家国产软件自主可控的号召，中国地震台网核心决定选用国产数据库 TDengine 来存储和解决地震波形数据。本文将针对 TDengine 3.0 在地震畛域的利用开展具体解说。 对于企业：中国地震台网核心是作为中国地震局直属的公益一类事业单位，是我国防震减灾工作的业务枢纽和国际交流窗口，是地震监测预报预警、应急响应和信息化工作的国家级业务核心。 我的项目背景近年，随着国家对防震减灾要求一直进步，我国先后施行了多个大型地震监测工程项目。随着地震台站密集建设，台站仪器采集汇入中国地震台网核心的地震波形数据也增长了一个数量级。 地震波形数据次要是指由国家地震台站、各省区域地震台网等地震观测网络系统中地震计采集并传回核心的数据，具备典型的时序数据特色，是发展地震监测预警、数据分析与开掘、地震异样研判等利用的根底资料。 为了满足地震预警数据存储、检索和解决的建设与集成需要，以及响应国家国产软件自主可控的号召，该我的项目选用国产数据库来存储和解决地震波形数据。 通过竞标，最终由 TDengine 承当该我的项目。 思考到运维部署老本性能等等各个方面，数据库须要做好如下方面： 高效读写：承载每秒 500 万数据点的海量数据实时汇入，反对即席疾速查问。高数据压缩比：尽可能多的保留更多数据，同时缩小磁盘存储老本。时序剖析：基于工夫线的窗口化剖析函数或工具。弹性扩大：零碎可能反对程度扩大，随着业务规模逐年扩充，弹性扩容以反对更高的数据接入量。安全可靠：零碎可能保障多正本存储和高可用，保障在单点故障时不影响失常应用。冷热拆散：对于新采集的数据和历史数据有肯定归档能力，依照数据冷热水平拆散存储。能够对地震业余算法包集成：通过 UDF 形式，将地震业余信号处理算法集成至数据库中。本文将以中国地震台网核心的我的项目作为主体开展（该我的项目用于全国范畴的地震数据监控剖析）。 业务架构目前，该我的项目上应用的是 3.0.6.0 版本的 5 节点集群，单台服务器配置为：48CPU(s)， 192GB 内存 ，500GB SSD  + 1.2TB *6HDD 硬盘。 业务架构如下： 首先，每个地震仪个别会采集两个程度向，一个垂直向共三个通道（重量）的地触动数据，采样频率个别为 100HZ（10毫秒采样一次）。数据包中的数据通过工具解析之后会先过渡写入 cencdb 这个 TDengine 库当中，写入 cencdb 的同时， TDengine 的订阅性能会取出该数据包，并再次进行解析，获取更多层次的数据写入 TDengine 集群当中。 站点的地位由其所属台网代码、台站代码和测点地位号码决定。地震仪每天不间断的继续采集地触动数据，并每隔 0.5秒将数据打成 miniSEED 数据包传输，造成数据流。基于 TDengine “一个设施采集点一张表”的建模思路，每道数据流别离对应一张数据表和一张元数据表。 以后，该集群共有约 5.9 万张数据表，代表流入库中的 5.9 万道地震数据流。另外还有 5.9 万张元数据表（上图），存储 5.9 万道数据流中每个数据包的形容信息。 我的项目运行至今，TDengine 接入的原始数据包每天约 900GB，每秒大略接入超过 5 万个地震数据包，每天总数据量约 5000 亿条。 因为原始数据包已应用 STEM2 算法压缩，TDengine 压缩后的数据库文件与原数据包所占磁盘空间相当。对于惯例的 INT 类型数据，TDengine 压缩比可达到 5%-10% 之间，对于 VARCHAR 类型的数据，压缩比可达到 15-20%，极大水平地节约存储老本。 在集群日常负载上，单台数据库服务端 CPU 使用率 40%～50%，内存占用 14%～20%，运行安稳。 具体利用在地震监测畛域，以下这些是比拟常见的需要： 1.通过应用 SQL 查问 “XJ_BKO_00_H_H_Z”表，就能够失去该地震仪器垂直重量的振幅数据。 2.对地震数据包内的数据工夫，与理论入库工夫做差，能够统计到数据包入库的时延。因而，咱们对元数据表执行如下 SQL ，就能失去超过 5 秒时延的异样数据用作进一步剖析。 3.在地震数据中，地震波流传门路上会呈现多个不同的震相。地震学家能够对这些震相的达到工夫和振幅特色，对地震事件进行精确定位、震源机制剖析等工作。其中在地震信号中精确地辨认和捕获特定震相的行为，便是震相拾取。 咱们通过 TDengine 的 UDF （自定义函数）性能，把曾经训练好的 GPD 模型间接同 TDengine 的流计算/SQL 联合起来，实现了震相拾取的实时计算。 ...

大家都晓得：因为单机数据库在数据规模、并发访问量等方面存在瓶颈，无奈满足大规模利用的需要。因而才有了把数据切割分片，散布存储散布解决在多个节点上的数据库，也就是分布式数据库的由来。 而为了实现数据库的高可用，又有了多正本的概念，正本之间的数据须要用特定算法保持一致，从而能够随时切换身份对外提供高可用服务——TDengine 就是一款这样的分布式时序数据库（Time Series Database）。 抉择什么样的一致性或者共识算法，能够间接代表一款数据库的产品思路。 一.Why RAFT在 3.0 之前，联合时序数据的十大特点（《我为何要开发一个专用的物联网大数据平台，还开源它？》），咱们针对性地发明了多项时序数据处理专利，使得 TDengine 对大时序数据的解决能力与过后世界上的同类型产品拉开了微小的性能劣势。而在 3.0 ，咱们则引入了规范的 RAFT 算法，以更通用规范的实现形式，去实用更宽泛的利用场景。 通过 RAFT 算法所保障数据统一的多个节点，被称为一个 RAFT 组(group)；这些节点，被称为这个RAFT组的成员（member）节点。在 RAFT 组中，每个节点都保护了一份间断的日志（Log），用于记录数据写入、变更、或删除等操作的所有指令。日志是由一系列有序的日志条目 (Log Entry) 组成，每个 Log Entry 都有惟一的编号（Index），用于标识日志协商或执行的进度。 此外，每个 RAFT 节点都有本人的角色，它们能够是 Follower（跟随者）、Candidate（候选人）、Leader（领导者）。 二. Raft in TDengine对于 TDengine 来说，一个虚构节点组（vgroup）就形成了一个 RAFT 组；而这个虚构节点组的虚构数据节点（vnode），便是该 RAFT 组的成员节点，咱们也称之为正本（全副治理节点（mnode）也形成一个 RAFT 组）。 Leader 角色的 vnode/mnode 依照协定机制负责提供读写服务，在容忍故障节点不超过半数的状况下保障集群的高可用性；此外，即便产生了节点重启及 Leader 节点从新选举等事件后，RAFT 也可能始终保障新产生的 Leader 节点能够提供曾经写入胜利的全副残缺数据的读写服务。 对于 TDengine 来说，每一次对数据库的变更申请（ 比方 insert into test.d1 values(now,1,2,3) ），都对应一个 RAFT 日志记录（Log Entry）。在继续写入数据的过程中，TDengine 会依照协定机制在每个成员节点上产生完全相同的日志记录，并且以雷同的程序执行数据变更操作，以 WAL 的模式，存储在数据文件目录中。 ...

以后，寰球数字经济减速倒退，数据正在成为重组寰球因素资源、重塑寰球经济构造、扭转寰球竞争格局的要害力量。数据库作为存储与解决数据的关键技术，在数字经济大浪潮下，寰球数据库产业中新技术、新业态、新模式不断涌现。 7 月 4 日，由中国通信标准化协会和中国信息通信研究院主办，大数据技术标准推动委员会承办，InfoQ 联结主办的“2023 可信数据库倒退大会”在北京国际会议中心隆重召开。大会公布多项中国信通院及相干机构在数据库畛域的研究成果，助力我国数据库产业高质量倒退。TDengine 创始人&外围研发陶建辉在本次大会“产品翻新”分论坛下，受邀进行了题为《不只是时序数据库，而是一个极简时序数据平台》主题演讲。 随同万物互联时代的到来，高效解决各种传感器、设施产生的时序大数据成为一个重要技术畛域。而时序大数据处理在应用通用数据库解决方案过程中遇到重重挑战，在本次演讲中，陶建辉为现场听众解读了传统关系型数据库、NoSQL 数据库、工业实时库、Hadoop 大数据平台等在解决时序数据上面临的低效、简单、高老本问题，并以时序数据库（Time Series Database） TDengine 为例，通过数据模型、架构设计等论述打造时序数据管理平台的技术外围点，联合具体案例讲述了 TDengine 作为一款极简时序数据平台，如何以低成本、高性能助力以传统行业为代表的各畛域企业胜利进行数字化转型。此外，在本次大会上，中国信通院云计算与大数据研究所所长何宝宏正式公布《数据库倒退钻研报告（2023年）》暨《中国数据库产业图谱（2023年）》。《报告》涵盖中国数据库产业倒退态势介绍、数据库政策解读、数据库技术趋势分析等内容；《图谱》则全面主观地展示了中国数据库产业中的要害畛域、环节和代表企业，为社会各界提供了中国数据库倒退的一站式信息库。作为国产数据库的一份子，凭借着继续的技术创新和开源翻新，TDengine 正式入选《中国数据库产业图谱（2023年）》，为展现中国数据库产业全貌奉献一份力量。荣誉加身，砥砺前行！接下来 TDengine 将持续放弃初心，聚焦技术创新和开源布道，与更多企业开展单干丰盛实践经验，与更简单、更多元的数字化场景需要相交融，继续打磨产品，优化性能，为宽广用户提供更为优质的产品与服务体验，为更多企业的数字化转型倒退奉献本人的力量。

TDengine 3.0.4.0 公布了一个重要个性： 反对用 Python 语言编写的自定义函数（UDF）。这个个性极大节俭了 UDF 开发的工夫老本。作为时序大数据处理平台，不反对 Python UDF 显然是不残缺的。UDF 在实现本人业务中特有的逻辑时十分有用，比方量化交易场景计算自研的交易信号。本文内容由浅入深包含 4 个示例程序： 定义一个只接管一个整数的标量函数： 输出 n， 输入 ln(n^2 + 1)。定义一个接管 n 个整数的标量函数， 输出 （x1, x2, ..., xn）, 输入每个值和它们的序号的乘积的和： x1 + 2 x2 + ... + n xn。定义一个标量函数，输出一个工夫戳，输入间隔这个工夫最近的下一个周日。实现这个函数要用到第三方库 moment。咱们在这个示例中解说应用第三方库的注意事项。定义一个聚合函数，计算某一列最大值和最小值的差, 也就是实现 TDengien 内置的 spread 函数。同时也蕴含大量实用的 debug 技巧。本文假如你用的是 Linux 零碎，且已装置好了 TDengine 3.0.4.0+ 和 Python 3.x。示例一： 最简略的 UDF编写一个只接管一个整数的 UDF 函数： 输出 n， 输入 ln(n^2 + 1)。首先编写一个 Python 文件，存在零碎某个目录，比方 /root/udf/myfun.py 内容如下：from math import logdef init(): passdef destroy(): passdef process(block): rows, _ = block.shape() return [log(block.data(i, 0) ** 2 + 1) for i in range(rows)]这个文件蕴含 3 个函数， init 和 destroy 都是空函数，它们是 UDF 的生命周期函数，即便什么都不做也要定义。最要害的是 process 函数， 它承受一个数据块，这个数据块对象有两个办法： ...

介绍TDengine™ 是一种开源的云原生时序数据库（Time Series Database，TSDB），专为物联网（IoT）、连贯汽车和工业物联网进行了优化。它可能高效地实时摄取、解决和监控一天内由数十亿个传感器和数据收集器产生的PB级别的数据。 许多用户将由物联网设施、汽车或 IT 基础设施生成的海量数据实时存储到 TDengine 中，并应用规范的 SQL 命令从 TDengine 中查问数据。TDengine 反对过滤、分组、窗口、连贯和许多聚合函数以查问数据，帮忙用户依据其目标查问数据。 许多用户也心愿更深刻地理解现有数据。例如，依据以后趋势，将来将会产生什么状况？随着 AI 时代的到来，最近呈现了许多新技术或办法，例如新的机器学习和深度学习算法。那么如何应用机器学习和深度学习算法针对存储在 TDengine 的数据预测将来趋势呢？ 侥幸的是，TDengine 反对多种风行的编程语言连接器，如 Java、Python、Go、Rust、C#、NodeJS 等，用户能够应用他们喜爱的语言连接器拜访 TDengine。这些连接器提供符合规范的接口，使连接器易于与其他软件或框架集成。 本文介绍如何应用存储在 TDengine 中的现有数据来预测将来数据。咱们将模仿一些测试数据以反映实在的电力系统，并演示如何应用 TDengine 和一些 Python 库来预测将来一年的数据。 假如用户是一个电力系统公司，用户每天从电站仪表收集用电量数据，并将其存储在 TDengine 集群中。当初用户想要预测电力耗费将会如何倒退，并购买更多设施来反对它。 随着经济增长，每年用电成肯定比例上涨。另外思考到节令变动，电力消耗量会有所不同。这个城市位于北半球，所以许多家庭在夏天会应用更多的电力。咱们模仿数据来反映这些假设。 源代码托管在 https://github.com/sangshuduo/td-forecasting。 演示步骤1：部署 TDengine 并在您的零碎上运行 TDengine 服务器。请参阅官网文档https://docs.tdengine.com/get-started/理解具体阐明。 步骤2：克隆源代码git clone https://github.com/sangshuduo/td-forecasting步骤3：装置所需的Python软件包# if you are using Ubuntu 20.04 Linuxsudo apt install python3-pyqt5# 如果 PyQT5 运行失败，可能须要装置sudo apt-get install libxcb-xinerama0python3 -m pip install -r requirements.txt请留神，Python 的最小版本为 3.8。 步骤4：模仿一些数据python3 mockdata.py ...

家喻户晓，DBeaver 是一个风行的开源数据库治理和 SQL 客户端工具，为治理和应用各种类型的数据库（包含多个时序数据库）提供弱小而灵便的平台。为了让大家在利用上更加便捷，咱们与 DBeaver 达成单干，新公布的 DBeaver 23.1.1 版本正式反对时序数据库（Time Series Database） TDengine 和全托管的时序数据云平台 TDengine Cloud。此次单干标记着 TDengine 生态系统的进一步壮大倒退，为企业和开发者的数据处理难题带来了更丰盛的解决方案合集。 DBeaver 为用户提供了简洁易浏览的界面，以树状视图的模式显示数据库对象，用户可能轻松浏览表构造、表、视图、索引和其余数据库组件。其丰盛的功能集、跨平台反对以及直观的界面使其成为开发者、数据分析师和数据库管理员的热门抉择。目前，TDengine 的反对曾经蕴含在 DBeaver 的社区版和专业版中。 尽管在此前的 DBeaver 版本中，用户也能够连贯到 TDengine，然而该过程比较复杂，并且须要手动装置 TDengine Java 连接器。但单方达成单干后，你只需通过几次点击就能够从 DBeaver 中查看和操作 TDengine 数据库，包含 TDengine Cloud。 如下图所示，如果你想要通过 DBeaver 连贯 TDengine，只需点击“连贯到数据库”，在工夫序列分类中找到 TDengine，而后依照向导的批示输出集群信息，即可在几秒钟内建设连贯。 如果你想理解无关在 DBeaver 中应用 TDengine 的更多信息，包含连贯 TDengine 或 TDengine Cloud 数据库的逐渐操作，请参阅官网文档：https://docs.taosdata.com/third-party/dbeaver/。 一旦将 TDengine 连贯到 DBeaver，你就能够拜访其全副性能，包含 SQL 编辑器、数据查看器、模式编辑器和查问构建器，以此助力你简化数据库开发和治理工作。 如果你在 DBeaver 中遇到任何与 TDengine 或 TDengine Cloud 相干的问题，或者有相干的疑难或关注，请随时在 GitHub（https://github.com/taosdata/TDengine） 或 Discord 上分割咱们的团队，咱们将为你提供帮忙；也能够增加小T微信：tdengine1，申请加入 TDengine 用户交换群，也将会有业余的研发人员解答你的疑难。 ...

小T导读：在中移物联网的智慧出行场景中，须要存储车联网设施的轨迹点，还要反对对车辆轨迹进行查问。为了更好地进行数据处理，他们在 2021 年上线了 TDengine 2.0 版本的 5 节点 3 正本集群。 3.0 公布后，它的泛滥个性吸引着中移物联网进行了大版本升级。本文具体分享了中移物联网在 3.0 我的项目的业务实际和全新体验，以此给大家作参考。对于中移物联网：中移物联网有限公司是中国移动通信集团有限公司出资成立的全资子公司。公司依照中国移动整体策略布局，围绕“物联网业务服务的撑持者、专用模组和芯片的提供者、物联网专用产品的推动者”的策略定位，专业化经营物联网专用网络，设计生产物联网专用模组和芯片，打造智慧出行、智能家居、智能穿戴等特色产品，开发经营物联网连贯治理平台 OneLink 和物联网开放平台 OneNET，推广物联网解决方案，造成了五大方向业务布局和物联网“云-网-边-端 ”全方位的体系架构。 业务背景：智慧出行是中移物联网的一个十分典型的场景，咱们须要存储车联网设施的轨迹点，还要反对对轨迹进行查问。最后咱们应用的是 Oracle 小型机单表分区存储数据，运维简单不便治理。2017 年，响应团体去 IOE 的要求，该我的项目开始应用 MySQL 集群。2019 年，产品提出了更高的数据存储需要，咱们又开始调研国产数据库 TiDB，但因为其存储老本过高，不适宜轨迹存储这种低价值的数据，而且不能解决行业客户轨迹数据存储周期定制化的须要，因而咱们开始持续调研新的存储计划——国产开源时序数据库 （Time Series Database）TDengine 就是这个时候进入了咱们的视线。 在调研中咱们发现，智慧出行轨迹数据的特点人造适宜 TDengine ：高频写入，每天写入约两亿条轨迹数据；低频查问，通常是由用户触发，查问最近几天的轨迹；企业用户有定制轨迹存储周期的需要；不针对 OLAP 需要，数据价值密度低。 因而，在经验了谨严的选型测试后，咱们最终确定抉择 TDengine 作为新的数据存储引擎。具体选型过程和我的项目历史背景能够参考 2.x 版本的案例《存储空间降为原来的1/7，TDengine在中移物联网轨迹数据存储中的利用》。革新后零碎的整体架构如下图所示： 咱们在 2021 年上线 TDengine 的 2.4.0.18 的 5 节点 3 正本集群稳固运行至今。往年 3.0 公布后，它的泛滥个性非常吸引咱们，其中最典型的几个包含：Raft 协定的引入使 TDengine 领有了更规范的一致性算法存储引擎的重构优化了 2.x 版本的设计查问灵便度大幅晋升，可实现的需要变得多元化反对更弱小的流式计算 因而，只管 2 - 3 版本底层数据文件并不兼容，咱们还是本人写了程序把数据迁徙到了 3.0.2.5 版本，以至于前面官网正式公布了企业版迁徙工具 taosX 的时候，咱们早就先走一步了。 3.0 应用体验：TDengine 3.0 的装置部署上保留了和 2.0 一样的简略易用模式，降级操作只须要备份数据文件目录，笼罩装置即可，而且写入速度极高，靠近硬盘的间断写入性能。TDengine 的高效压缩算法，能够节俭大量存储空间，SQL 应用也非常简单。在此前对 MySQL 计划的替换中，咱们的存储空间降为原来的 1/7，能够看到，在节俭存储空间方面，TDengine 的劣势极为显著。 ...

许多用户会有一个疑难，“落盘”俩字听起来就很底层，仿佛无奈和手头的性能问题分割到一起，本篇文章的目标就是让大家对它们俩建设起直观的意识。 写到数据库的数据总要保存起来——所以时序数据库（Time Series Database） TDengine 中常常提到的“落盘”，其实指的是内存中的数据长久化到存储的过程。在 TDengine 中，对 vnode 的写入流程如下。（不理解vnode的用户，倡议先移步 https://docs.taosdata.com/tdinternal/arch/） 依据图中所示：内存和硬盘产生长久化的操作有两局部，本文的“落盘”指的是右侧标红局部，即是时序数据长久化到 $DataDir/vnode/vnodeX/tsdb/ 下数据文件的过程。 一 . 触发逻辑变动：相熟 2.0 版本的敌人们都晓得，触发落盘的机制有二： 写满该 vnode 三分之一的缓冲池（建库时指定，2.0 为建库参数 cache * blocks 的值， 3.0 替换为建库参数 buffer）；数据库服务过程进行的时候；在 3.0 版本，触发落盘的机制变为： 写满该 vnode 三分之一的缓冲池之后，超过“落盘最小距离”即可主动落盘。出于平安思考，该参数没有提供可配置选项；数据库服务过程进行的时候；(3.0.4.0 版本数据库单正本状况下提供)提供手动落盘的命令，flush database dbname。二.架构优化：那么它具体都达成了哪些优化呢？ 首先，在设计上 3.0 对落盘性能和过期数据检测做理解耦。在 2.0 的时候，只有数据库在落盘之后，才会触发比对数据文件的工夫范畴清理过期的文件数据的机制，从而开释硬盘空间，详情可参考：https://mp.weixin.qq.com/s/uJEQwN0NnmSTBAMOecAtoA。 自 3.0 版本开始，数据库的过期文件清理依附 trim database dbname 的命令来实现。到 3.0.3.0 版本，又减少了定时检测来主动执行 trim database。这让 3.0 的磁盘空间回收变得更加高效及时。 其次，提供手动落盘的命令。令落盘管制更加灵便。此外，因为时序数据的压缩是产生在落盘阶段的，因而对于咱们统计数据的磁盘理论占用，计算压缩率都有很大的帮忙。 三.配置优化：落盘时，内存中的行式存储的时序数据会被转为列式存储的数据块，而后执行压缩。因而，造成数据块的过程间接影响着后续的磁盘占用和查问效率，这也是 TDengine 性能优化最外围的局部之一，它是由数据库的一系列参数决定的，具体可参考文章（文章：对于 3.0 和 2.0 的数据文件差别以及性能优化思路）。TDengine 执行落盘的工作是异步的，这样当写满 1 块缓冲池后，就能够无提早地利用起来残余的 2 块缓冲池。然而如果 buffer 设置太小，就会导致落盘仍未完结时，然而曾经用光了所有三块缓冲池。这个时候数据库就只能进入期待阶段，写入查问都会受到影响，直到可用的缓冲池返回。能够看出，在这个环节中，缓冲池的大小是非常重要的，这个值由建库时的 buffer 参数指定，建库后可批改（具体可参考：https://docs.taosdata.com/taos-sql/database/）。另外，如果是落盘线程这一侧达到瓶颈导致没有可用的缓冲池返回，则能够抉择减少 numOfCommitThreads 参数值，这个参数代表每个节点上的落盘线程数量，默认等于二分之一的cpu核数。具体优化形式须要联合本人的理论状况决定，如写入频率、表宽、性能需求等等。并没有一项固定参数的独自调试就能够调试到最优状态，大家能够联合历史多期文章自行调试，也能够间接分割企业版团队做定制化的优化计划。 ...

如果须要对数据库性能优化，理解数据文件的存储形式和工作原理是必要的。 对于时序数据库（Time Series Database） TDengine 来说，在 2.x 版本中时序数据的保留策略是由keep和days这两个参数把控的。（详情可见：https://mp.weixin.qq.com/s/uJEQwN0NnmSTBAMOecAtoA）咱们通过 keep 和 days 来对时序数据进行分段保留，而每一段时间的数据就能够便对应着数据库中数据vnode目录下的一组数据文件，也就是咱们这篇文章的配角。 在3.0 版本中，此处逻辑保持一致，只是为了更好的体现“每一段时间的数据”，咱们把 "days" 参数更名为了“duration”。 而上文提到的一个数据文件组，在2.x 版本中是这个样子的，他们代表了 vnode24 中所有表在某10天（days默认参数值）内的所有数据，对于这些文件的具体含意能够参考官网文档和：https://mp.weixin.qq.com/s/OGS1WIlySSKveEOk4Reg3Q 在 2.x 的前期版本中，为了晋升预计算（sum、max、min）的性能，又把 .data/.last 文件中所有数据块的预计算后果抽离进去造成了 smad/smal 文件，于是文件组变成了如下5个文件： 到了 3.0 版本中，这个数据文件组持续演变成了下图这样的状态。那么，他们有哪些具体的变动呢？ 1.数据文件（.data）其中，.data类文件逻辑放弃不变，存储的是理论入库的时序数据，为多个数据块形成。一个数据块只属于一张表，除此之外，每一个数据块也都记录着预计算中的行数数据，属于预计算中的count 函数计算结果。  2.索引文件（.head）.head 文件和此前逻辑放弃不变，存储的是 .data 文件中数据块的索引信息。查问申请正是通过这些索引信息，来迅速定位表，定位工夫范畴，从而在 .data 文件中找到对应的数据返回给用户。 3.预计算文件（.sma）.sma 文件：存储数据块中每列数据预计算数据的文件。文件中只存储了 .data 文件中数据块的预计算。预计算是为了减速查问，尽可能防止从硬盘中读取原始数据。.sma 等于 2.x 前期版本中的 smad 文件，而 smal 则被移除了。 4.碎片文件（.stt）.stt 文件则是取代了 2.x 版本的 .last 文件，他们的大体性能保持一致，简略来说就是保留每一张表从内存落盘到磁盘时的碎片数据（小于 minrows），然而他们的运行机制有了一些区别： 在 2.x 版本中，当.last文件小于32k的时候，即使是当中某表的碎片数据曾经满足行数（大于等于 minrows）要求合并到了.data文件，然而.last 文件依然只是会被追加写入，而并不会清理掉这部分数据，该 32k 的限度是为了避免对文件频繁的操作影响性能。 而到了 3.0 的时候，在 .stt 文件中，属于同一个超级表的数据会存储在同一个数据块中，且数据块中的数据依照 （uid（表的惟一标识）, timestamp, version）递增排列。每次落盘，数据文件组都会生成一个新的 stt 文件，用来放本次落盘中的散碎数据。当 .stt 文件个数超过肯定的阈值 （由建库参数：stt_trigger 管制），则首先将多个 .stt 文件的碎片数据合并后，就会依据理论状况来决定写入 .data 文件，或写入新的 .stt 文件中。 ...

随着数字经济蓬勃发展，数据成为驱动企业数字化转型的要害生产因素，如何增强对数据资源的治理利用、实现数据洞察、激活数据价值正成为亟待解决的问题。在此背景下，数据库与操作系统、云平台等国产化软件互相联合赋能成为解决问题的思路之一。 近日，通过数月致力，涛思数据旗下时序数据库（Time Series Database） TDengine 先后与腾讯云多个产品线实现产品兼容性互认证明。在联结测试环节，TDengine 与 OpenCloudOS 8、TencentOS Server 3、TencentOS Server 2 的兼容性体现均良好，测试期间运行稳固、性能优良、安全可靠，最终胜利与三大操作系统取得产品兼容性互认证明。据理解，OpenCloudOS 8 由腾讯与合作伙伴独特倡导发动，是齐全中立、全面凋谢、平安稳固、高性能的操作系统及生态，积淀了多家厂商在软件和开源生态的劣势，继承了腾讯在操作系统和内核层面超过 10 年的技术积攒，并应用社区独立保护内核，满足企业级稳定性需要。TencentOS Server 是腾讯云针对云的场景研发的 Linux 操作系统，提供特定的性能及性能优化，为云服务器实例中的应用程序提供更高的性能及更加安全可靠的运行环境。 作为本次互认证的国产化软件之一，TDengine 是一款专为物联网、工业互联网、金融、IT 运维监控等场景设计并优化的时序数据库，其具备极强的弹性伸缩能力，同时还带有内建的缓存、流式计算、数据订阅等零碎性能，能大幅缩小零碎设计的复杂度，升高研发和经营老本，是一个极简的时序数据处理平台。 本次 TDengine 与国内几大支流的操作系统软件进行兼容互认证，是国产化产品胜利适配的胜利案例，将来 TDengine 将与几大操作系统开展更为严密的技术单干，为企业提供更加全面的国产化解决方案。接下来，TDengine 将持续保持自主翻新，在时序大数据畛域进行技术深耕，推动更多国产化适配认证的落地，携手更多合作伙伴构建自主可控的国产 IT 生态，为用户提供更优质、更平安、更可信的产品和服务。

自 3.0 版本公布以来，在研发人员和社区用户的一直致力下，时序数据库（Time Series Database）TDengine 做了大量更新，产品稳定性和易用性也在一直晋升。在咱们为 TDengine 筹备六岁生日“Party”的同时，TDengine 的研发小伙伴们也在加班加点地进行优化迭代的工作，想要在六岁生日的节点上为 TDengine 用户送上一个新版本“大礼包”，独特见证 TDengine 下一阶段的新成长。 在大家的共同努力下，TDengine 3.0.5.0 终于胜利公布，这一版本波及到的更新内容包含零碎稳定性与性能优化、系统安全、流计算、数据订阅以及一些能晋升用户体验的细节优化。新版本进一步晋升了零碎稳定性，帮忙用户将资源占用降到更低，欢送大家下载应用，咱们期待收到你的利用反馈。 3.0.5.0 版本具体更新如下： 1. 零碎稳定性与性能优化 晋升了在高密度数据写入压力下的零碎稳定性晋升了一些查问场景下的性能通过引入 RAFT Learner，正本变更不会阻塞写入通过写驱动构建缓存，晋升了 last()/last_row() 的查问性能升高了创立/删除数据库的延时默认记录长查问，不便诊断利用零碎中耗时较长的查问管制了客户端的缓存下限在 dnode 数据彻底失落后可能复原 （企业版）2. 系统安全 表级权限管制（企业版）root 用户可通过 SQL 命令来激活或更新受权码（企业版）3. 流计算 大幅升高了流计算对磁盘 I/O 和内存的资源耗费在没有 fill_history 的状况下能够暂停和复原流的运行4. 数据订阅 能够查问 topic 的生产进度可能从指定地位开始生产超级表的数据能够加上过滤条件进行生产 Consumers can subscribe supertable with tag filtering可能获取 topic 的元数据晋升了性能和稳定性5. 其余 最大行长度减少到 64KBinterp() 能够对超级表进行插值应用“REPLACE”命令可能在线降级 Python UDF，无需再重启服务过程Partition by 和 window 子句能够和"Having"子句一起应用如果你想要理解新版本更加具体的信息，能够移步至 https://github.com/taosdata/TDengine/releases/tag/ver-3.0.5.0 查看公布阐明。欢送大家下载应用，也欢送在评论区提出倡议和意见，如有任何问题请及时分割咱们，取得反对。

因为ChatGTP的惊人体现，原本曾经趋于平淡的AI，又火爆起来。毫无疑问，人类曾经进入了AI时代，AI将渗入到各行各业，渗入到生存与工作的每个方面。这是一场新的工业革命，很多工作都将隐没，但也会产生很多新的机会，而新的机会肯定属于把握AI或会应用AI技术的人。 因为 TDengine 作为一款时序数据库（Time Series Database）次要用户群是传统工业用户，遍布制作、能源、化工、矿山、汽车等泛滥行业，因而我有机会接触很多这些畛域的客户，中国的、美国的，我都有很宽泛的交换。AI的突飞猛进，让这些产业的人比IT人更加焦虑，每次交换，都会聊到AI的话题，怎么利用AI技术降低成本，进步传统产业的效率。 但通过我一年多的察看、思考，发现传统产业要能尽快、低成本、低危险的享受到AI的红利，还有很多坎要过，次要要看采取什么样的策略。周末有闲暇工夫，将本人的思考整理出来，分享给大家。 打消数据孤岛AI的根底是大数据，须要有足够的数据样本，能力训练模型，能力根据数据做出商业决策。然而对于传统产业而言，这个大数据的前提就不容易实现。 传统产业的IT、OT建设参差不齐，无论中国还是美国，大部分企业的数字化建设远落后于互联网类型的企业。以我最近打交道的美国发电企业为例，他们很多用的还是PI System，而且还是很老版本的，Aveva对Process Book都不反对了，但还在应用，因为PI相当稳固，而且能满足他们生产要求，他们也就没有更换的能源。但这个老零碎是齐全独立的，是一个数据孤岛。一个发电团体总有几十个甚至几百个电厂，每个电厂用的软件，或版本都很难统一。而且因为商业的并购、分拆的起因，导致各种零碎并存，各种软件供应商都有，而更换的老本与危险很高，因而很难对立。加上当初清洁能源的倒退，光伏、风力发电的零碎与传统的电力又不一样，因而复杂度更高。 在这种状况下要让AI赋能这些传统产业，首先要做的就是将分布各处的各种零碎、包含各种版本采集的数据进行汇总，打消数据孤岛。但因为各种零碎存在，有老掉牙的自动化零碎，也有最新的数采零碎，各种工业协定都存在，数据汇聚还不是简略的汇聚，还须要对各个数据源的数据进行荡涤、加工、解决，能力进入对立的平台。而每个数据源都不一样，因而数据汇聚是一个脏活、累活，还不产生间接的经济效益。然而数据汇聚如果不做，AI赋能谈都不必谈。 建设数据分享平台数据总是提供给各种利用，包含各种AI利用应用的，而且这些利用有外部，还有内部合作方的利用。比方新能源汽车采集大量的数据，它包含电机、电控、电池数据，甚至还有用户行为数据。这些数据不仅外部不同的部门须要应用，看如何通过数据分析晋升汽车品质，改善驾驶与乘车体验，同时泛滥第三方须要这些数据，比方电池供应商、电机供应商，他们也须要用这些数据来进行剖析，有些数据还要上报政府监管部门。因而如果不建设好弱小的数据分享平台，将无奈应答外部、内部以及监管部门的需要。 但分享就牵涉到数据的隐衷与平安问题，利益相干方应该只能看到它被答应看到的数据。比方电池供应商只应该获取脱去用户个人信息后的电池数据，而且只能看到本人的电池数据，还不能看到同一汽车主机厂其余电池供应商的数据。为了爱护隐衷，有的数据甚至要加工后能力提供，而不是间接提供原始数据。为进一步减少安全性，数据领有方还必须能随时管制利用拜访的时长，拜访的数据的时间段等。 大多数场景下，数据的分享能够是批的形式进行，定时获取一次就行。但有的场景是须要实时获取的，比方工业上总心愿做实时的异样检测。一旦检测到新的数据，就须要立刻告诉相干的利用。能够预感，实时的数据分享需要场景还会越来越多。 因为利用林林总总，新的利用、新的合作伙伴天天涌现，这个分享还必须有足够的灵活性。系统管理员收到开明分享的申请后，做个简略的配置，分享就能立刻失效，而无需进行开发或简单的配置。 因而企业要能让AI赋能，数据汇聚后，还必须建设有弱小、平安而又灵便的数据分享平台。 无缝对接的开放系统数据汇聚后，企业当然能够开发本人的AI利用，做更好的异样监测，实时报警，并为产能、老本、设施保护等提供更好的预测，而且这些都是基于整个公司层面的数据做出的，而不是局限于一个电厂或一个制造厂，让决策者有更好的宏观整体把控。 但传统企业要组建本人的AI开发甚至数据分析团队，都是相当不容易的。因为AI开发以及数据分析的人才，还很稀缺，你须要与阿里、华为、腾讯、百度这些企业竞争，在美国，则是与谷歌、微软、苹果、亚马逊等竞争。不仅他们的薪资构造、工作形式与传统产业相差太大，而且即便退出，因为对产业自身的常识理解不够，往往半年甚至一年都难施展出作用，导致投入产出不成正比。 那么最好的形式就是间接采纳第三方的AI利用，将本人领有的数据平台与第三方AI利用对接。而且为缩短周期，能够间接应用对方提供的云服务，这样就大幅减小了购买或协调资源以及部署所须要的工夫，能够立刻上线。同时云服务个别是按时长或用量免费，而无需提前领取一大笔洽购费用。这样能很快看到成果，看是否能满足要求，大幅升高了决策老本。 但AI利用提供方很多家，服务质量也参差不齐，那么作为领有数据的企业，要做到的就是保障本人数据平台的开放性，任何利用都能够通过规范的接口获取数据，这样就能去除AI利用与数据平台对接的阻碍，各种利用零碎都能与数据平台无缝对接。只有想尝试某个AI利用，一周甚至一天之内就能够看到成果，大幅提高决策效率。因而如果数据平台具备很好的开放性，那么让AI赋能，就像商场买衣服一样，能够左挑右拣，直到本人称心为止，不是苦楚，而是一件赏心悦目的事件。 个别的平台或软件都会宣称本人是凋谢的。但从我集体的教训来看，只有风行的用户量大的软件或零碎，开放性才不会有问题，而且所有的利用都会与它对接。就像咱们开发的TDengine，因为开源，装置量曾经超过27万，而且它还有规范的JDBC接口，反对SQL，能与简直所有的可视化、BI工具对接。 AI的将来与互联网一样，AI并不能取代传统产业，能源、制作、汽车、矿山这些行业仍旧存在，但AI能赋能、晋升这些产业，进步生产效率，为传统产业注入新的生机。不拥抱AI的企业将会失去竞争力，逐渐被淘汰。 AI曾经弱小，但对于传统产业而言，还有两个有余。一是要求的算力过大，导致老本过高，对于利润很低的传统产业，难以承受。另外一方面，当初的ChatGPT，依赖的都是历史数据，而工业场景，更须要的是对实时数据的剖析。因而AI在工业场景还有很多挑战以及晋升的空间，但这个挑战应该交给AI的钻研人员。 传统产业要做的是，将散布于各地的数据汇聚起来，建设一个凋谢的、能够平安、灵便共享的数据平台，能与泛滥的第三方的AI工具或服务无缝集成，在无需大量的资金和人力投入下，在简直没有决策危险的前提下，能迅速验证并享受AI带来的红利。以我本人为例，我本人开办的TDengine是一个专为物联网、工业互联网定制的大数据平台。TDengine不是以AI为核心技术的公司，但在AI的时代，咱们的惟一抉择就是全面拥抱AI。为帮忙泛滥的传统产业数字化转型、能让AI赋能，过来的一年，咱们投入了微小的人力反对开发PI System, MQTT, OPC等各种工业数据接口，反对与各种BI、AI工具对接，而且在阿里云、AWS、Azure、GCP上推出全托管的云服务。无需大量资金投入、无决策危险下，短时间内你就能够试用开明，并与AI利用、泛滥的剖析工具、可视化工具集成，体验大数据以及AI的魅力。 “Run! Don't walk. You are either running for food or running from being food!" 。咱们唯有奔跑，能力不被AI时代摈弃。 陶建辉2023年6月3日于加州湾区

正如咱们之前所言，在 3.0 当中，咱们在产品底层做了很大的变动调整，除了架构更加迷信高效以外，用户体验也是咱们重点优化的方向。以之前一篇文章为例：对于 Update 性能，用户不再须要任何配置 ，默认即是比 2.0 更欠缺的机制。（https://mp.weixin.qq.com/s/7E8kl9W8IXROx_K0EGQPkg） 切换到 3.0 版本之后，咱们面对的第一个问题就是建库建表，在 3.0 版本中，这部分逻辑产生了重大变动，这对于 3.0 初体验的用户来说是非常重要的，是数据库后续查问/写入性能保障的根基。有些表数量比拟多的用户刚换到 3.0 的时候，会感觉性能和 2.x 差一些，其实就是因为建库时应用了默认配置，导致 vgroup 数量只有 2 个，因而无奈利用到 TDengine 多线程并行的个性来解决数据。 相比起 2.0 ，3.0 的建表策略管制是很简略的，它能够让用户无难度无老本地找到本人适宜的配置。 简而言之：只须要在建库的时候指定适合的参数即可。 在 2.0 版本中，很多用户都浏览过这篇文章：https://mp.weixin.qq.com/s/H2GCESF40wnWYf4IKP_-9g，以期用自定义的建表逻辑来取得更好的性能，更正当的开销。这篇文章中的几个参数的逻辑着实是须要读者好好了解一番的，而它简单的基本在于，在 2.0 版本下，每个 vnode 的表数量在固定后是不可再调整的，所以只能够通过后期设定绝对简单的规定来施行管制。 而在 3.0 中，为了反对云原生场景下资源的灵便调配，不论是时序数据与元数据都须要分布式技术才能够做到。为此，咱们把存在于 mnode 的一般表元数据移除（具体细节可参考：https://www.taosdata.com/engineering/14534.html），让其齐全散布到了 vnode 上，采取了一致性哈希这种具备较好的容错性和可扩展性的算法，以反对 vnode 的可拆分的个性（该个性会在将来的 3.x 企业版本中公布） 因而， 3.0 和 2.0 的建表流程是齐全不一样的，细节如下：1.首先在建库时，每个 vgroup 会负责存储 0 至 2 的 32 次方-1 的等分长度；2.建表阶段，TDengine 3.0 首先会在客户端通过对表名进行 hash 计算，失去一个 hash 值；3.向治理节点收回 rpc 申请，取回数据库配置和 vgroups 的相干内容等信息；4.把建表申请中的 hash 值和取回的每个 vgroup 的 hash 范畴做一个比对；5.把申请间接发送到对应的 vgroup 中的 vnode 上实现建表。（如果对 vgroup 和 vnode 的关系并不清晰，能够先移步 https://docs.taosdata.com/tdinternal/arch/） ...

在车联网场景下，GPS 产生的时序数据量级通常都达到了亿级，高效写入、存储和疾速查问是最根本的数据处理要求，但在具体实际上这却不是一件容易实现的事件。最近某企业就遇到了这样一个问题：服务端接管存储 GPS 相干数据，按 1 次/30 秒的上传频率，一天的数据条数预计在 1.2 亿条，其想要实现后盾的实时监控和历史轨迹查问，个别用什么样的数据库进行存储？NoSQL（Redis、MongoDB）？MySQL？还是 HBase？ 置信上述企业的数据库选型问题并不是个例，抉择到一款适合的数据库，对于打造一个适宜业务倒退的数据架构至关重要。为了找到该问题的最优解，涛思数据解决方案架构师从数据实质登程进行剖析，联合具体实际输入本文，给到大家参考。 先谈 NoSQL 数据库不论是 Redis/MongoDB/ElasticSearch 当中的哪一个，在面对上述场景时都会面临同一个问题：压缩率。在车联网当中，依照国标 30s 的采样距离能够计算失去单台车的采集量为 2880 rows/day，在 10W 车辆规模下，就是 2.88 亿/天。假如单台车辆采集 250 个信号，每个信号 8 Bytes（相当于 Double），即每行 2000 Bytes，那么 1 天就会有 562.5 GB 的数据量，1 年会有约 200TB 的数据。 在这样的数据规模下，压缩率即便是 50%，也须要 100TB 的空间。而这样的空间规模，通常都须要 10 个节点以上的 NoSQL 集群（用 Redis 的话就更可怕了，须要内存 100TB 的集群）。这个论断的底层原理，就在于 NoSQL 是应用非结构化的形式来存储结构化数据的，这种模式导致了压缩成果差、存储老本高、节点规模大的劣势。 再谈 MySQL/PostgreSQL原本这两款数据库作为 SQL 类数据库，存储结构化数据是很适合的。然而，咱们看一下每秒的写入量：均匀 10W/30 = 3333 rows/s，最大值 10W rows/s，因为车联网自身会呈现“车机在一段时间内断网补传数据”、“车机上传按时钟定时”等特点，会有肯定概率触发最大值写入量，甚至超过最大值。因而选用的数据库必须具备高吞吐能力，而且还得留有余力供后续扩容。用过 MySQL 的开发者都会有体验，在没调优的状况下，这种 2KB 的行写入，1k tps 根本把单个节点打满了。 ...

2023 年 6 月 6 日，涛思数据旗下时序数据库（Time Series Database） TDengine 迎来六周年庆典，并于北京·保利国内广场T2举办了主题为“TDengine 6th Anniversary：Back to The Future”的庆典活动，设置了「TDengine」时序照片亭、「TDengine Database」主题鸡尾酒、寻找 TDengine 等诸多有意思的线下环节。同时，为回馈社区开发者和企业用户的大力支持，TDengine 早在 6 月 1 日便启动了该庆典的线上打卡我的项目，包含“集 TDengine 庆生卡片有礼”和“TDengine 知多少·答题有礼”两大线上玩法，为参加流动的上千位支持者送出了 TDengine 的泛滥新鲜周边。 在欢庆之余，回顾 TDengine 六年倒退，成长和提高跃然纸上。由小到大，由弱到强，随同着 TDengine 影响力的逐步扩充，涛思数据也走出了一条独具特色的守业之路。 2016 年底，TDengine 创始人 & 外围开发陶建辉看到了物联网大数据的市场机会，在两个月的工夫写下一万八千行代码打造了 TDengine 的原型。2017 年 5 月，北京涛思数据科技有限公司正式注册，6 月 6 日在北京望京科技园正式开始办公。陶建辉汇聚了一批来自中国科大、中国科学院、上海交大、美国密歇根大学、马里兰大学等出名学府或机构的团队成员，正式开始了 TDengine 的产品研发之旅。2018 年 8 月，在通过多轮测试后，TDengine 终于公布了第一个商用版本。 面对时序数据库广大的市场前景，涛思数据在成立之初即取得明势资本与蛮子基金的天使投资，后又取得红杉资本中国基金、经纬中国、GGV纪源资本、指数资本、永辉瑞金等多家出名机构的投资，投资总额达到了近 7000 万美元，深受资本市场青眼。 聚焦数据技术创新，随后几年倒退间 TDengine 也进行了多个版本的降级迭代，从 1.0 到 2.0 再到 3.0，TDengine 实现了从“云就绪”到云原生的里程碑式演进，正式降级成为一款真正的云原生时序数据库，破解了困扰时序数据库倒退的高基数难题，反对 10 亿个设施采集数据、100 个节点，反对存储与计算拆散；流式计算和数据订阅性能也有了进一步的降级，成为了货真价实的极简时序数据平台。 在人工智能疾速火爆的当下，TDengine 也在全面拥抱 AI，为帮忙一众传统企业更好地进行数字化转型降级，过来的一年里，TDengine 投入了微小的人力反对开发 PI System、MQTT、OPC 等各种工业数据接口，反对与各种 BI、AI 工具对接，无需大量资金投入、无决策危险下，开发者不仅能够利用到时序数据库能力，还能与 AI 利用、泛滥的剖析工具、可视化工具集成，同时体验大数据以及 AI 的魅力。 ...

随着我国数字经济继续疾速倒退，各行各业都在踊跃拥抱云技术，上云成为企业放慢数字化转型步调的要害一步。在此过程中，越来越多的企业开始意识到云原生技术的重要性，利用云原生更快地开发和部署应用程序，进步应用程序的可靠性和可扩展性。 为进一步实现开发的提质增效，近日，北京涛思数据科技有限公司与上海道客网络科技有限公司实现产品兼容性互认证。通过单方严格测试，「TDengine 时序数据库企业版」与「DaoCloud Enterprise云原生利用云平台V5.0 」互相兼容，运行稳固、安全可靠。 云原生技术作为新型基础设施，可帮忙企业充沛享受云的弹性、灵便，实现平滑迁徙、疾速开发、稳固运维，助力企业提质增效。在此背景下，TDengine 在 3.0 版本中也充沛交融了云原生技术，倒退成为了一款真正的云原生时序数据库，反对 10 亿个设施采集数据、100 个节点，反对存储与计算拆散，解决了困扰时序数据库倒退的高基数难题。 通过此次产品兼容性认证，依靠涛思数据在时序数据库畛域上的技术创新和深耕摸索，以及「DaoCloud道客」在云原生及外围畛域 Kubernetes方面的技术积淀，单方将施展各自产品技术劣势，推动产品体系的生态交融，全面提高产品竞争力，携手助力企业减速云原生落地过程，推动数据基础设施的架构变革，为各行各业数字化转型贡献力量。 对于道客科技上海道客网络科技有限公司被誉为科技领域准独角兽企业，成立于 2014 年底，公司领有自主知识产权的核心技术，致力于打造凋谢的云操作系统为实体经济赋能，推动传统企业实现数字化转型。成立迄今，公司已在金融科技、先进制作、智能汽车、批发网点、城市大脑等多个畛域深耕，标杆客户包含交通银行、浦发银行、上汽团体、东风汽车、海尔集团、金拱门（麦当劳）等。 对于 TDengineTDengine 是一款开源、高性能、云原生的时序数据库（Time Series Database），由专一时序大数据处理的北京涛思数据科技有限公司（TAOS Data）研发并领有自主知识产权。作为一款专为物联网、工业互联网、金融、IT 运维监控等场景设计并优化的时序数据库，TDengine 具备极强的弹性伸缩能力，同时还带有内建的缓存、流式计算、数据订阅等零碎性能，能大幅缩小零碎设计的复杂度，升高研发和经营老本，是一个极简的时序数据处理平台。

近日，2022 中国互联网倒退翻新与投资大赛暨 2022 年中国开源翻新大赛在北京落下帷幕，本次大赛由地方网信办信息化发展局领导，中国互联网倒退基金会、中国网络空间研究院、中国互联网投资基金联结主办。十分荣幸的是，凭借着弱小的开源创新能力和产品竞争力，时序数据库（Time Series Database） TDengine 播种了“2022 年中国开源翻新大赛”二等奖的好问题。 据理解，本届大赛是中国互联网倒退基金会“中国互联网倒退翻新与投资大赛”品牌公益我的项目在开源翻新畛域的首次尝试。大赛于 2022 年 11 月在 2022 年世界互联网大会正式公布，半年来历经初赛遴选和决赛现场评审，在业界五十位业余评委的独特见证下，最终从升级决赛的 76 个开源我的项目/社区中，提拔出 12 个一等奖和 26 个二等奖。获奖我的项目笼罩了 Risc-V、操作系统、数据库、云计算云原生、人工智能等多个畛域，局部获奖我的项目曾经跻身国内先进行列。 早在 2019 年，TDengine 的内核（存储和计算引擎）以及社区版就被发表 100% 正式开源，到 2020 年，TDengine 又发表将集群版开源，至此，TDengine 超过 90% 的外围代码全副公开，这一动作也让老成持重的 TDengine 播种了一众开发者的注目。短短三年间，TDengine 在 GitHub 上的 Star 数已胜利冲破至 21.4k，并屡次登上 GitHub 寰球趋势榜第一名，放弃着在开源时序数据库畛域中最快的 PR 增长速度，同时，借助产品的技术创新和开源的商业翻新，TDengine 在市场开辟上也始终保持着领先水平，寰球装置实例数曾经达到 266.2k。 在时序数据的技术创新上，TDengine 倒退了从 1.0 到 2.0 再到 3.0 的技术迭代，实现了从“云就绪”到云原生的里程碑式演进，正式降级成为一款真正的云原生时序数据库，破解了困扰时序数据库倒退的高基数难题，反对 10 亿个设施采集数据、100 个节点，反对存储与计算拆散；进一步降级了流式计算和数据订阅性能，同时将存储引擎和查问引擎也进行了更深层次的优化。 此外，为帮忙泛滥的传统产业数字化转型，过来的一年，TDengine 鼎力开发了 PI System、MQTT、 OPC 等各种工业数据接口，反对与各种 BI、AI 工具对接，同时在阿里云、AWS、Azure、GCP 上推出全托管的云服务 TDengine Cloud。无需大量资金投入、无决策危险下，短时间内开发者就能够试用开明，并与 AI 利用、泛滥的剖析工具、可视化工具集成，体验大数据以及 AI 的魅力。 ...

在车联网场景下，GPS 产生的时序数据量级通常都达到了亿级，高效写入、存储和疾速查问是最根本的数据处理要求，但在具体实际上这却不是一件容易实现的事件。最近某企业就遇到了这样一个问题：服务端接管存储 GPS 相干数据，按 1 次/30 秒的上传频率，一天的数据条数预计在 1.2 亿条，其想要实现后盾的实时监控和历史轨迹查问，个别用什么样的数据库进行存储？NoSQL（Redis、MongoDB）？MySQL？还是 HBase？ 置信上述企业的数据库选型问题并不是个例，抉择到一款适合的数据库，对于打造一个适宜业务倒退的数据架构至关重要。为了找到该问题的最优解，涛思数据解决方案架构师从数据实质登程进行剖析，联合具体实际输入本文，给到大家参考。 先谈 NoSQL 数据库不论是 Redis/MongoDB/ElasticSearch 当中的哪一个，在面对上述场景时都会面临同一个问题：压缩率。在车联网当中，依照国标 30s 的采样距离能够计算失去单台车的采集量为 2880 rows/day，在 10W 车辆规模下，就是 2.88 亿/天。假如单台车辆采集 250 个信号，每个信号 8 Bytes（相当于 Double），即每行 2000 Bytes，那么 1 天就会有 562.5 GB 的数据量，1 年会有约 200TB 的数据。 在这样的数据规模下，压缩率即便是 50%，也须要 100TB 的空间。而这样的空间规模，通常都须要 10 个节点以上的 NoSQL 集群（用 Redis 的话就更可怕了，须要内存 100TB 的集群）。这个论断的底层原理，就在于 NoSQL 是应用非结构化的形式来存储结构化数据的，这种模式导致了压缩成果差、存储老本高、节点规模大的劣势。 再谈 MySQL/PostgreSQL原本这两款数据库作为 SQL 类数据库，存储结构化数据是很适合的。然而，咱们看一下每秒的写入量：均匀 10W/30 = 3333 rows/s，最大值 10W rows/s，因为车联网自身会呈现“车机在一段时间内断网补传数据”、“车机上传按时钟定时”等特点，会有肯定概率触发最大值写入量，甚至超过最大值。因而选用的数据库必须具备高吞吐能力，而且还得留有余力供后续扩容。用过 MySQL 的开发者都会有体验，在没调优的状况下，这种 2KB 的行写入，1k tps 根本把单个节点打满了。 ...

交融查问语法etl-engine引擎中的交融查问提供将多源数据在内存中重组关联查问并输入查问后果的能力。交融查问语法遵循ANSI SQL规范，与惯例MySQL查问语法很类似。 反对对多种类别数据库之间读取的数据进行交融查问。反对音讯流数据传输过程中动静产生的数据与多种类型数据库之间的流计算查问。交融查问语法遵循ANSI SQL规范。样本SELECT t_u.u_id,t_u.u_name,t_u.u_phone, t_o.o_id,t_o.o_price,t_o.o_number,t_o.o_money,t_o.o_writetime, t_p.p_id,t_p.p_name,t_p.p_contacts,t_p.p_desc FROM t_u inner JOIN t_o ON t_o.u_id=t_u.u_id inner JOIN t_p ON t_o.p_id=t_p.p_id ORDER BY INTEGER(SUBSTRING(t_u.u_id,3)) ASC 语法格局select 反对SELECT [DISTINCT] field [, field ...] FROM table [, table ...] [WHERE condition] [GROUP BY field [, field ...] ] [HAVING condition] [ORDER BY order_item [, order_item ...] ] [LIMIT number_of_records [OFFSET number_of_records ] ]table 反对INNER JOIN、LEFT JOIN、RIGHT JOIN、OUTER JOIN、CROSS JOIN等运算符反对+ - * / == < <= > >= <> != || IS BETWEEN IN LIKE NOT ANY AND OR INTERSECT UNION EXCEPT EXISTS函数反对逻辑函数COALESCE(value [, value ...])IF(condition, value1, value2)IFNULL(value1, value2)NULLIF(value1, value2)数字函数（30多个）ABS(number)ACOS(number)ACOSH(number)ASIN(number)ASINH(number)ATAN(number)ATAN2(number2, number1)ATANH(number)CBRT(number)CEIL(number)COS(number)COSH(number)EXP(number)EXP2(number)EXPM1(number)FLOOR(number)IS_INF(number [, sign])IS_NAN(number)LOG(number)LOG10(number)LOG1P(number)LOG2(number)LOGB(number)POW(base, exponent)ROUND(number)SIN(number)SINH(number)SQRT(number)TAN(number)TANH(number)BIN_TO_DEC(bin)OCT_TO_DEC(oct)HEX_TO_DEC(hex)ENOTATION_TO_DEC(enotation)BIN(integer)OCT(integer)HEX(integer)ENOTATION(float)NUMBER_FORMAT(number [, precision, decimalPoint, thousandsSeparator, decimalSeparator])RAND(min, max)日期函数（30多个）NOW()DATETIME_FORMAT(datetime, format)YEAR(datetime)MONTH(datetime)DAY(datetime)HOUR(datetime)MINUTE(datetime)SECOND(datetime)MILLISECOND(datetime)MICROSECOND(datetime)NANOSECOND(datetime)WEEKDAY(datetime)UNIX_TIME(datetime)UNIX_NANO_TIME(datetime)DAY_OF_YEAR(datetime)WEEK_OF_YEAR(datetime)ADD_YEAR(datetime, duration)ADD_MONTH(datetime, duration)ADD_DAY(datetime, duration)ADD_HOUR(datetime, duration)ADD_MINUTE(datetime, duration)ADD_SECOND(datetime, duration)ADD_MILLI(datetime, duration)ADD_MICRO(datetime, duration)ADD_NANO(datetime, duration)TRUNC_MONTH(datetime)TRUNC_DAY(datetime)TRUNC_TIME(datetime)TRUNC_MINUTE(datetime)TRUNC_SECOND(datetime)TRUNC_MILLI(datetime)TRUNC_MICRO(datetime)TRUNC_NANO(datetime)DATE_DIFF(datetime1, datetime2)TIME_DIFF(datetime1, datetime2)TIME_NANO_DIFF(datetime1, datetime2)UTC(datetime)MILLI_TO_DATETIME(unix_milliseconds)NANO_TO_DATETIME(unix_nano_time)字符串函数（20多个）TRIM(str)LTRIM(str)RTRIM(str)UPPER(str)LOWER(str)BASE64_ENCODE(str)BASE64_DECODE(str)HEX_ENCODE(str)HEX_DECODE(str)LEN(str)SUBSTRING(str, position [, len])SUBSTR(str, position [, len])INSTR(str, substr)LIST_ELEM(str, sep, index)REPLACE(str, old, new)REGEXP_MATCH(str, regexp [, flags])REGEXP_FIND(str, regexp [, flags])TITLE_CASE(str)加密函数MD5(str) SHA1(str) SHA256(str) SHA512(str) MD5_HMAC(str,key_str) SHA1_HMAC(str,key_str) SHA256_HMAC(str,key_str) SHA512_HMAC(str,key_str) 类型转换函数STRING(value)INTEGER(value)FLOAT(value)DATETIME(value [, timezone])BOOLEAN(value)聚合函数COUNT([DISTINCT] *)MIN(expr)MAX(expr)SUM([DISTINCT] expr)AVG([DISTINCT] expr)参考资料 etl-engine使用手册(https://github.com/hw2499/etl-engine) etl-crontab使用手册(https://github.com/hw2499/etl-engine/wiki/etl-crontab%E8%B0%83%E5%BA%A6) 嵌入脚本开发(https://github.com/hw2499/etl-engine/wiki/%E5%B5%8C%E5%85%A5%E8%84%9A%E6%9C%AC%E5%BC%80%E5%8F%91) etl-engine配置样例(https://github.com/hw2499/etl-engine/wiki/etl-engine%E4%BD%BF%E7%94%A8%E6%A0%B7%E4%BE%8B)

没错~咱们就是要“搞事”啦揭晓谜底前TDengine 周边先来露个面人不知;鬼不觉间TDengine 曾经和大家独特走过六年工夫了从单机版开源到集群版开源从零到两万一的 Star 增长从寥寥可数的下载量到超 25 万的用户实例数从 1.0 到 2.0 到 3.0 的版本迭代......在这六年工夫里TDengine 也有了很多成长和提高而这些问题都离不开社区开发者和企业用户的大力支持为了回馈这一份反对与厚爱在 TDengine 六岁生日到来之际咱们打算举办一场大型线上庆生流动参加流动就有机会获取 TDengine 周边在这个非凡的时刻咱们心愿可能邀请到屏幕前的你 流动介绍集1. TDengine 庆生卡片有礼专为 TDengine 社区微信群同学们定制流动：2023 年 6 月 1 日-2023 年 6 月 6 日，TDengine 将会通过社交媒体（微信社群、朋友圈等）发放当日“庆生卡片”，参与者须将当日卡片转发至朋友圈，每天一张，共计 6 张，6 月 7 日-6 月 9 日，分割小 T（微信 tdengine 1），凭 6 张“庆生卡片”的朋友圈截图（将 6 天分享的截图截至一屏）和本人所在群内截图，兑换 TDengine 六周年周边大礼包（礼包内礼品随机）！ 2. TDengine 知多少·答题有礼为所有反对 TDengine 的敌人们定制流动：2023 年 6 月 1 日-2023 年 6 月 6 日，参加 TDengine 知多少 · 答题有礼流动并得分 80 分以上，有机会取得 TDengine 六周年限量周边一个（留念 T 一件、留念袜一双或其余周边一件 ）。流动链接请戳 https://www.taosdata.com/events/6th-anniversary 。如果你是 TDengine 的“忠诚粉丝”抑或你真心喜爱咱们的周边礼物那 TDengine 六周年生日“Party”期待你的参加哦！ ...

基于第三方基准性能测试平台 TSBS（Time Series Benchmark Suite） 规范数据集，TDengine 团队别离就 TSBS 指定的 DevOps 中 cpu-only 五个场景，对时序数据库（Time Series Database，TSDB）TimescaleDB 和 TDengine 进行了比照测试。本文将会从写入、存储、查问及资源开销等几大维度为大家汇总分析测试后果。 为确保后果具备可比性，本次测试选用 TimescaleDB 2.6.0 版本。为取得较好的性能，TimescaleDB 须要针对不同的场景设置不同的 Chunk 参数，不同场景下参数的设置如下表所示：上述参数的设置，充沛参考了下方 TimescaleDB vs. InfluxDB 比照报告中举荐的配置参数设置，以确保写入性能指标的最优化。TimescaleDB vs. InfluxDB: Purpose Built Differently for Time-Series Data：https://www.timescale.com/blog/timescaledb-vs-influxdb-for-ti... 对于零碎的配置详情、如何一键复现测试后果及具体的测试数据介绍等内容，大家可参考《一键获取测试脚本，轻松验证“TSBS 时序数据库性能基准测试报告”》、《TSBS 是什么？为什么时序数据库 TDengine 会抉择它作为性能比照测试平台？》两篇文章，本文便不再赘述。 写入性能最高达到了 TimescaleDB 的 6.7 倍在 TSBS 全副的 cpu-only 五个场景中，TDengine 写入性能均优于 TimescaleDB。相比 TimescaleDB，TDengine 写入速度最当先的场景是其 6.7 倍（场景二），起码也是 1.5 倍（场景五），而且对于场景四，如果将每个采集点的记录条数由 18 条减少到 576 条，TDengine 写入速度就达到了 TimescaleDB 的 13.2 倍。此外，TDengine 在写入过程中耗费的 CPU 资源和磁盘 IO 开销也是最低的。 ...

近日，TDengine 正式签约路特斯科技，打造出属于高性能跑车畛域的高效、牢靠和灵便的数据处理解决方案，帮忙路特斯科技更好的解决在业务减速扩张中的爆发式增长的车辆数据、实现数据架构的降级。 路特斯科技作为专一于技术创新和敢于打破常规的行业领先者，随着车联网的疾速倒退和本身业务的减速扩张，时序数据出现爆发式增长，如何进行无效的数据处理和剖析成为路特斯科技在降级数据架构时的重要考量规范。在车联网时序数据库革新中，其对国内外支流时序库进行了充沛调研测试，比照了 InfluxDB、TDengine、Clickhouse、OpenTSDB、Cassandra，最终抉择了极简的时序数据处理平台 TDengine ，来实现车辆 Tcam 总线报文数据的存储和剖析。 目前该利用我的项目曾经在路特斯科技上线，用来解决路特斯科技车辆数据，最终数据通过 TDengine 企业版提供的边云协同性能进行解决，且得益于 TDengine 的高吞吐量的读写、高压缩比、海量车端数据的多级存储。 对于路特斯科技路特斯（LOTUS）是世界驰名的跑车生产商，曾译名莲花跑车，路特斯创始了当先于时代的造车理念，通过在轻量化、空气动力学和底盘调校等方面的继续翻新，成为英国赛车精力和超跑文化的最佳代言，被公认为世界三大顶级跑车品牌之一。路特斯科技是路特斯品牌旗下的技术、销售和市场营销业务分部，将路特斯品牌长达75年的技术积攒融入新一代生存用车产品当中，将世界级下一代汽车研发技术与其数十年积攒的英国赛车基因相结合，以期在电动化、数字化和智能化上不断创新、继续倒退。 对于TDengineTDengine 是一款开源、高性能、云原生的时序数据库（Time Series Database），由专一时序大数据处理的北京涛思数据科技有限公司（TAOS Data）研发并领有自主知识产权。作为一款专为物联网、工业互联网、金融、IT 运维监控等场景设计并优化的时序数据库，TDengine 具备极强的弹性伸缩能力，同时还带有内建的缓存、流式计算、数据订阅等零碎性能，能大幅缩小零碎设计的复杂度，升高研发和经营老本，是一个极简的时序数据处理平台。

近日，36氪公布了 2023 年度 36Under36 名册，包含 120 位创业者和 36 位投资人。涛思数据联结创始人侯江燚入选36氪「36Under36 创业者名册」，从 500 余位优良创业者中怀才不遇。通过对申报的 500 余位创业者和 200 余位投资人的初筛、复审，36氪评比出新一届 36Under36，此次名单上的 120 位创业者，散布在前沿技术、先进制作、智能硬件、新能源、产业降级、企业服务、医疗衰弱、本地生存等十余个细分畛域，“科研、技术”是他们最显明的标签。此次 Under36 创业者领有海内名校学历的创始人有 41 位，博士及以上占比 34%、硕士占比 35%，本科以下仅 2 位；泛科技我的项目占比为 64%，而有 59% 创始人所在企业的“研发人员占比 60% 以上”。 据理解，每一年36氪都会发动 36Under36 评比。将时光拉回到 2018 年，彼时一份蕴含了 36 位创始人的 36Under36 名单新鲜出炉，居于榜首的张一鸣年仅 35 岁，字节跳动估值也还不过 750 亿美元；阳萌率领的安克翻新，凭一根“Anker”商标的 USB 充电线刚在海内市场施展拳脚；瞿芳和毛文超一起开办的小红书也才刚刚冲破用户 5000 万。尔后 5 年工夫里，36Under36 的名册曾经收纳了 432 创业者和 108 位投资人，成为了一份颇具时代症候意义的商界“清明上河图”。 在对创业者的评比中，为了使流程更具公信力，36氪邀请了 33 家投资机构分管科技、生产、医疗三大产业的合伙人——简直囊括了国内最头部的综合性基金，以及一些最有发言权的垂类机构——为创业者依照集体履历、商业模式和技术创新方面打分，最终由36氪创投研究院统计，得出了最终名单，36Under36 榜单的重磅水平由此也可见一斑。 围绕 36Under36，36氪推出了一个升级版的峰会IP：Waves大会，正如这场大会的 Slogan 所说，浪潮偏爱年轻人——92 年的侯江燚携手行将步入“六周岁”的 TDengine，他们的将来也将有有限可能。 侯江燚，涛思数据联结创始人，销售VP2010 年考入中国科大地球物理系，2017 年在美国马里兰大学拿到地球物理学硕士学位，之后退出美国大型软件公司 PayChex 做零碎研发。2018 年 9 月回国退出涛思数据，次要负责时序数据库（Time Series Database） TDengine 的接口开发、测试、零碎性能及稳定性晋升等研发工作，在企业级利用程序开发、大数据建模、数据分析方面有丰盛的教训。TDengine 开源后开始负责产品的商业化摸索。 2021 年 10 月，侯江燚入选“2021 胡润 U30 中国守业首领”名单。 ...

好消息！好消息！美国专利局复电TDengine 又有一个新专利证书下来啦！这一专利名为“一种时序数据库表构造扭转解决办法”做技术创新咱们真的是认真的~话不多说，给大家上图展现一下咱们都晓得，在当下这样一个疾速变动的时代，科技产品想要取得长期倒退，技术创新肯定是外围竞争力，只有一直新陈代谢才可能在强烈的市场竞争中怀才不遇。 TDengine 所处的根底软件畛域更是如此，早在 2013 年，数据库的国产化反动就开始衰亡了，十年倒退下，国产数据库能够说曾经呈现出了百花齐放的状态，除了传统数据库厂商，还有一批新兴数据库，波及畛域包含云数据库、时序数据库、图数据库等等。作为时序数据库赛道的一员，TDengine 也始终在推动这一细分畛域的技术提高和倒退。 就在去年 8 月份，借助云原生的力量，TDengine降级成为了一款云原生时序数据库（Time Series Database），反对 10 亿个设施采集数据、100 个节点，反对存储与计算拆散，彻底解决了困扰时序数据库倒退的高基数难题，同时还进一步降级了计算引擎、存储引擎以及流式计算等性能，在极简的时序数据平台方向上更进一步。 同时，通过一直地翻新和研发，TDengine也曾经申请了多项专利，并胜利地取得了国内和国内的认可：作为一家具备弱小专利实力的企业，TDengine 不仅重视技术创新，更重视技术的利用和落地。咱们始终深信技术创新的灵感来源于用户的实际，因而也始终在关注市场和客户需要，致力于将翻新技术和优质服务相结合，在晋升产品竞争力的同时也为用户带来了实实在在的价值。 目前 TDengine 的寰球装置实例曾经超过 246.7k，与包含京东云、货拉拉、中节能风电、和利时、陕西煤矿、蔚来能源、同程旅行、亿咖通、58同城、西门子、美的、中通等泛滥行业头部企业达成单干，利用在时序数据处理方面的技术劣势助力企业数据架构降级，实现更大力度的降本增效。 到当初为止TDengine 曾经胜利在国内外申请了四项专利接下来咱们也将持续秉承翻新的理念从用户角度登程申请发明更多的技术专利致力推动时序数据库技术的提高和倒退为时序数据场景下的更多企业发明更大的价值！

一. 存储格局下图是向VictoriaMetrics写入prometheus协定数据的示例： VM在收到写入申请时，会对申请中蕴含的时序数据做转换解决： 首先，依据metrics+labels组成的MetricName，生成一个惟一标识TSID；而后： metric(指标名称__name__) + labels + TSID作为索引index；TSID + timestamp + value作为数据data；最初，索引index和数据data别离进行存储和检索； 因而，VM的数据整体上分为索引和数据2个局部： 索引局部，用以反对依照label或tag进行多维检索，失去TSID；数据局部，用以反对依照TSID失去tv数据；二. 整体流程VictoriaMetrics在写入原始的rows数据时，写入过程分为两个局部： 写index；写tv；写入流程： 对于原始的rows数据，依据其metricsName从cache和内存索引中，查找其对应的TSID；若TSID找到，则写入tv数据，返回client；否则： 写index: 结构TSID，结构新的index items，而后将其写入内存shard；内存shard被异步的goroutine压缩并保留到磁盘；写tv数据；返回client； 三. 写入代码1.入口代码vmstorage监听tcp端口，收到vminsert的插入申请后，进行解决： // app/vmstorage/servers/vminsert.gofunc (s *VMInsertServer) run() { ... for { c, err := s.ln.Accept() ... go func() { bc, err := handshake.VMInsertServer(c, compressionLevel) ... err = clusternative.ParseStream(bc, func(rows []storage.MetricRow) error { vminsertMetricsRead.Add(len(rows)) return s.storage.AddRows(rows, uint8(*precisionBits)) // 入口代码 }, s.storage.IsReadOnly) ... }() }}写入时，1次最多写8K个rows： func (s *Storage) AddRows(mrs []MetricRow, precisionBits uint8) error { .... maxBlockLen := len(ic.rrs) for len(mrs) > 0 { mrsBlock := mrs // 一次最多写8K，maxBlockLen=8000 if len(mrs) > maxBlockLen { mrsBlock = mrs[:maxBlockLen] mrs = mrs[maxBlockLen:] } else { mrs = nil } // 写入8K rows的数据 if err := s.add(ic.rrs, ic.tmpMrs, mrsBlock, precisionBits); err != nil { if firstErr == nil { firstErr = err } continue } atomic.AddUint64(&rowsAddedTotal, uint64(len(mrsBlock))) } ....}2.写入流程的代码写入过程次要分2步： ...

VictoriaMetrics的索引文件，保留在{storagePath}/indexdb目录下： # tree ./indexdb/ -L 1./indexdb/├── 1759A6CAD53ABA2E├── 1759A6CAD53ABA2F└── snapshots一. 基本概念indexdb目录下，通常有2个索引目录： 一个为pre，即上个retentionPeriod应用的索引；一个为cur，即以后retentionPeriod应用的索引；当retentionPeriod到期后，将删掉pre，将cur配置为pre，同时创立新的索引目录作为cur；保留2个目录后，能够避免retentionPeriod到期后，没有index可用的景象。 pre与cur的索引目录，在代码中被称为table。 1. parttable目录下，蕴含若干个子目录： 每个子目录，被称为一个part；# ls indexdb/1759A6CAD53ABA2F -alh总用量 4.0Kdrwxr-xr-x 28 root root 4.0K 5月 5 09:01 .drwxr-xr-x 5 root root 71 4月 27 09:35 ..drwxr-xr-x 2 root root 98 5月 5 08:00 1141_2_1759A6CADA292254drwxr-xr-x 2 root root 98 5月 5 07:16 13868_28_1759A6CADA29209Fdrwxr-xr-x 2 root root 98 5月 5 07:53 1574_3_1759A6CADA29220Fdrwxr-xr-x 2 root root 98 5月 5 07:52 16467_45_1759A6CADA2922072. 索引文件每个part目录下，蕴含若干个索引文件： # ls indexdb/1759A6CAD53ABA2F/1141_2_1759A6CADA292254/ -alh总用量 36Kdrwxr-xr-x 2 root root 98 5月 5 08:00 .drwxr-xr-x 28 root root 4.0K 5月 5 09:01 ..-rw-r--r-- 1 root root 149 5月 5 08:00 index.bin-rw-r--r-- 1 root root 15K 5月 5 08:00 items.bin-rw-r--r-- 1 root root 2.3K 5月 5 08:00 lens.bin-rw-r--r-- 1 root root 335 5月 5 08:00 metadata.json-rw-r--r-- 1 root root 48 5月 5 08:00 metaindex.bin其中： ...

在VictoriaMetrics集群版本中，-dedup.minScrapeInterval用于数据去重，它能够配置在vmselect和vmstorage的启动参数上： 配置在vmselect上： 因为vm存储工夫戳的工夫精度是millisecond，同一个vminsert的数据发往不同vmstorage存储时，存储的是雷同的millisecond；故通常在vmselect上配置-dedup.minScrapeInterval=1ms，这样能够去重不同节点的反复数据；配置在vmstorage上： 若两个vmagent推送雷同的数据时，通常配置vmstorage的-dedup.minScrapeInterval=scrape_interval，这样能够避免单个节点上存储雷同的数据；VictoriaMetrics stores timestamps with millisecond precision, so -dedup.minScrapeInterval=1ms command-line flag must be passed to vmselect nodes when the replication is enabled, so they could de-duplicate replicated samples obtained from distinct vmstorage nodes during querying. If duplicate data is pushed to VictoriaMetrics from identically configured vmagent instances or Prometheus instances, then the -dedup.minScrapeInterval must be set to scrape_interval from scrape configs according to deduplication docs. 一. vmselectvm存储timestamps的精度为ms，通常配置vmselect的 ...

写入VictoriaMetrics的数据，首先被保留在内存shard，内存shard的数据定期的被压缩到inmemoryPart(内存中)，inmemoryPart的数据被定期的合并到磁盘part中。 tv的压缩，产生在内存shard转换为inmemoryPart的过程中。 一. 入口代码shard中寄存原始数据，通过压缩后，数据被寄存到inmemoryPart: rows被压缩到inmemoryPart的入口：mp.InitFromRows(rows)；// lib/storage/partition.gofunc (pt *partition) addRowsPart(rows []rawRow) { ... mp := getInmemoryPart() mp.InitFromRows(rows) //这里：将rows数据压缩后保留到inmemoryPart中 ... p, err := mp.NewPart() pw := &partWrapper{ p: p, mp: mp, refCount: 1, } pt.partsLock.Lock() pt.smallParts = append(pt.smallParts, pw) ok := len(pt.smallParts) <= maxSmallPartsPerPartition //常量=256 pt.partsLock.Unlock() if ok { return // 以后len(smallParts)<=256，间接返回 } // The added part exceeds available limit. Help merging parts. // // Prioritize assisted merges over searches. ...}二. 整体流程shard的rows按(tsid,timestamp)排序，而后将其分为N个block，每个block最多8k rows； ...

一. 整体流程client写入时，会首先写入内存的shard，若shard写入胜利，则间接返回client；若写入后shard已满，则将shard内的数据压缩后保留为inmemoryPart(依然在内存中)，而后返回client:inmemoryPart的数据，被后盾的goroutine，定期的merge为part构造，保留到disk中； 时序数据在磁盘中的存储： partition: 一个月1个目录，比方2023_05:part: 作为partition下的子目录，外面蕴含tv和索引信息；# ls 2023_05/117_117_20230504085731.987_20230504085737.814_175ADBE68C628DDD# # ls 2023_05/117_117_20230504085731.987_20230504085737.814_175ADBE68C628DDD/index.bin metaindex.bin min_dedup_interval timestamps.bin values.bin二. 内存shardshards的个数： shards个数跟CPU核数无关；对4C4G的机器来说，就1个shard；// The number of shards for rawRow entries per partition.//var rawRowsShardsPerPartition = (cgroup.AvailableCPUs() + 3) / 4每个shard保留的rows个数： 范畴=1w~50w；unsafe.Sizeof(rawRow{})=50对4C4G机器来说： memory.Allowed() = 4G×60%；rowRowsShardsPerPartition=1;每个shard保留的rows个数：后果=(4G×60% / 1 / 256 / 50) = 18w;// getMaxRawRowsPerShard returns the maximum number of rows that haven't been converted into parts yet.func getMaxRawRowsPerShard() int { maxRawRowsPerPartitionOnce.Do(func() { n := memory.Allowed() / rawRowsShardsPerPartition / 256 / int(unsafe.Sizeof(rawRow{})) if n < 1e4 { n = 1e4 } if n > 500e3 { n = 500e3 } maxRawRowsPerPartition = n }) return maxRawRowsPerPartition}若存在N个shards，写入时保留到哪个shard? ...

3月30日，openGemini社区公布了v1.0.1版本，较v1.0.0版本，次要修复了一些异样场景下的发现的问题，欢送大家下载试用和反馈。 v1.0版本新增了多个要害个性，并在数据压缩算法、内存治理、查问引擎等方面做了大量优化工作，整体性能获得进一步晋升 因为对数据压缩算法进行了批改，v1.0版本与v0.2版本的数据存在不兼容 社区地址：https://github.com/openGemini 社区联系方式：http://opengemini.org/contact-us 性能优化内存优化内存优化是性能优化中十分重要的一部分，openGemini的要害优化项如下： 优化乱序文件合并流程 乱序文件合并不再将乱序文件全副加载到内存，改为流式合并形式，不同数据模型下，内存开销可缩小20%-80%不等。优化索引搜寻流程 一方面在查问场景中，设置工夫线内存调配下限，防止因无节制对内存索取，对其余查问申请造成影响；另一方面在查问数据组装过程中，放弃内存拷贝，改为数据原地更新，相比优化前，单次查问可缩小40%内存空间应用。查问场景优化通常一个查问申请到来后，在openGemini外部会生成相干工夫线的迭代器，工夫线越多，一次性加载工夫线元数据和迭代器占用的内存空间越大，采纳提早加载技术，依据须要加载指定工夫线的元数据和迭代器，无效晋升了内存的利用率，升高内存开销达80%以上。 查问优化查问优化是性能优化中最为间接的优化源头，但查问优化是一个简单的工程，须要多方面的数据库领域专家常识和教训，它应用了十分多的优化策略来生成一个最优的查问打算。通过性能测试，openGemini整体的性能较优化前再次晋升了30%-80%，次要优化项如下： 简化DAG构建流程和编码 在openGemini外部，查问申请被生成为一棵树形的查问打算，为了将查问打算中各个操作尽可能并发起来，以达到查问效率晋升的目标，需再转换成示意分布式执行打算的DAG关系图，由ts-sql散发到不同的ts-store节点执行。通常一个简略查问的DAG关系图序列化之后大小为1-2KB，其序列化和网络传输开销却成为了简略查问的性能瓶颈。通过对DAG进行编码，无效升高了网络数据传输数据量，升高网络开销达95%工夫范畴查问优化 针对工夫范畴的查问，进行了预裁剪，晋升了时间跨度较大场景下的查问性能文件句柄优化 随着零碎长期的运行，数据文件越来越多，这对操作系统的文件句柄资源带来较大的耗费，优化采纳按需关上的形式进行文件句柄治理，极大的节约了系统文件句柄资源。过程启动RTO优化 ts-store过程重启时，优化了immutable的open速度，反对WAL异步回放机制。优化后，500万工夫线，存储共50.4亿条数据（Metrics），过程重启RTO为1.96s，晋升400%castor服务优化减少失败重试、连接池以晋升可靠性；反对返回更具体的错误信息；castor算子反对Group By time和tags 数据压缩算法优化openGemini采纳列式数据存储，针对每一列数据，依据不同数据类型应用不同的数据压缩算法，从而实现较好的数据压缩效率。 Float类型数据在运维监控等场景下利用十分宽泛，以后业界比拟罕用的是基于Facebook的Gorilla浮点数压缩算法，openGemini亦是如此。 但理论剖析来看Gorilla算法在局部数据模型下，压缩率并不现实，存在优化空间，因而在openGemini中采纳了自适应的压缩解决形式，依据Float数据特色的不同，抉择不同的压缩算法。优化后，openGemini采纳了Snappy，Gorilla，RLE三种压缩算法的组合，相比于独自应用Gorilla，压缩率晋升了60%，解压耗时缩小38% 新增个性反对多表full join在某些场景下，为了更灵便地剖析时序数据，咱们须要应用full join操作。例如： > SELECT * FROM mname: mtime host region total val---- ---- ------ ----- ---1434055562000000000 1 east 2 31434055562000000000 1 west 2 11434055562000000000 2 east 2 41434055562000000000 2 west 2 2 用户能够编写以下查问语句来应用full join，并失去以下后果： > SELECT m1.val, m2.val FROM (SELECT val FROM m WHERE host = '1') AS m1 FULL JOIN (SELECT val FROM m WHERE host = '2') AS m2 ON (m1.region = m2.region AND m1.total = m2.total) GROUP BY region, total name: m1,m2tags: region=east, total=2time m1.val m2.val---- ------ ------1434055562000000000 3 4name: m1,m2tags: region=west, total=2time m1.val m2.val---- ------ ------1434055562000000000 1 2 ...

从《写入性能：TDengine 最高达到 InfluxDB 的 10.3 倍，TimeScaleDB 的 6.74 倍》、《查问性能：TDengine 最高达到了 InfluxDB 的 37 倍、 TimescaleDB 的 28.6 倍》两篇文章中，咱们发现，TDengine 不仅在写入和查问性能上超过了 InfluxDB 和 TimescaleDB，在数据处理过程的资源耗费也比两大时序数据库要更低。本篇文章将会从 TDengine 的产品设计角度登程，为感兴趣的小伙伴剖析一下 TDengine 性能强耗费低的起因。 为什么 TDengine 的“写入强，开销低”？“客户端上 TDengine 对 CPU 的需要大于 TimescaleDB 和 InfluxDB， 而 InfluxDB 的写入压力基本上齐全集中在服务端，这种模式很容易导致服务端成为瓶颈。TDengine 在客户端的开销最大，峰值霎时达到了 56%，而后疾速回落。综合服务器与客户端的资源开销来看，TDengine 写入持续时间更短，在零碎整体 CPU 开销上 TDengine 依然具备相当大的劣势。”在 TSBS 测试报告全副的 cpu-only 五个场景中，TDengine 写入性能均优于 TimescaleDB 和 InfluxDB。绝对于 TimescaleDB，TDengine 写入速度最当先的场景是其 6.7 倍（场景二），起码也是 1.5 倍（场景五），而且对于场景四，如果将每个采集点的记录条数由 18 条减少到 576 条，TDengine 写入速度是 TimescaleDB 的 13.2 倍。绝对于 InfluxDB，TDengine 写入速度最当先的场景是其 10.6 倍（场景五），起码也是 3.0 倍（场景一)。此外，在保障高效写入的状况下，TDengine 在写入过程中耗费的 CPU 资源和磁盘 IO 开销也是起码的。 ...

2023 年 2 月，openGemini 正式申请加入 openEuler DB SIG，现已实现对 openEuler 的各项兼容性测试，并打算退出 openEuler 23.03 版本。openGemini 可在物联网、嵌入式、边缘计算、运维监控（AIOps）等畛域与 openEuler 社区开展单干，充沛利用自身技术竞争劣势，加强 openEuler 社区的影响力和竞争力的同时，一直开掘新的时机和技术创新点，进一步晋升 openGemini 的技术实力和社区品牌知名度。 我的项目地址https://github.com/openGeminihttps://gitee.com/src-openeuler/openGemini援用我的项目官网http://opengemini.orgopenGemini 简介openGemini 是由华为云数据库翻新实验室自行设计、研发并面向寰球开源的一款云原生分布式时序数据库。次要面向物联网和运维监控等场景，提供海量时序数据库解决和剖析的开源解决方案，以进一步升高企业经营和运维老本，晋升产品质量和生产效率。 openGemini 倒退历程 如图所示，openGemini 经验了最后由 InfluxDB 革新的技术摸索，到云服务商用、自研内核加强和开源等多个阶段的倒退，禁受住了华为云内外部 100 余家用户不同业务场景的打磨和测验，现已凋谢全副外围源码，全面拥抱开源，打造共享、共治、共建的开发社区，构建寰球技术生态和影响力。 openGemini 的架构openGemini 采纳 MPP 大规模并行处理分层架构，由 ts-sql、ts-store、ts-meta 组成。 ts-sql：对立解决客户端申请数据依照工夫线一致性 Hash 形式打散存储在不同的 ts-store 中，在查问语句执行期间，从 ts-store 获取数据并汇总，并返回客户端ts-meta：对立元数据管理数据库集群元数据和数据库元数据管理，如节点信息、数据保留工夫、数据分区信息、表信息等ts-store：对立数据管理将原始数据按时序优化的数据格式进行对立组织和存储，查问时，按指定工夫范畴和工夫线 ID 查问数据，并依据过滤条件，返回指标数据openGemini 的外围竞争力openGemini 开源后继续版本迭代，现已公布 v1.0.0 版本，在高性能、高平安、企业级个性、可扩展性、性能、利用开发等六个方面已全面具备生产环境可应用的残缺能力。 高性能openGemini 针对物联网、运维监控等畛域海量数据管理和剖析诉求，对计算引擎和存储引擎做了大量的优化设计，获得了显著成果。 反对亿级指标治理每秒千万级指标数据并发写入查问万级指标数据毫秒级响应在 30 万指标，259 亿条指标测试数据的场景下，采纳 TSBS 性能测试工具，相比开源的单机版 InfluxDB v1.7，openGemini 单机版写入性能晋升 5 倍，简略查问晋升 2-5 倍，简单查问响应工夫缩短 60 倍以上。 高平安openGemini 反对数据传输加密和用户明码鉴权，反对用户弱明码校验和审计日志。此外，openGemini 集群的各组件之间通信可配置 HTTPS 双向认证（Mutual TLS），确保每一个链接都是可信的。 ...

一、时序数据及其特点时序数据（Time Series Data）是基于绝对稳固频率继续产生的一系列指标监测数据，比方一年内的道琼斯指数、一天内不同工夫点的测量气温等。时序数据有以下几个特点： 历史数据的不变性数据的有效性数据的时效性结构化的数据数据的大量性二、时序数据库根本架构 针对时序数据的特点，时序数据库个别具备以下个性： 高速的数据入库数据的生命周期治理数据的流解决高效的数据查问定制的数据压缩三、流计算介绍 流计算次要是指针对实时获取来自不同数据源的海量数据，通过实时剖析解决，从而取得有价值的信息。常见的业务场景包含实时事件的快速反应，市场变动的实时告警，实时数据的交互剖析等。流计算个别包含如下几方面的性能：1）过滤和转换 （filter & map）2）聚合以及窗口函数 （reduce，aggregation/window）3）多数据流合并以及模式匹配 （joining & pattern detection）4）从流到块解决 四、时序数据库对流计算的反对 案例一：应用定制化的流计算 API，如上面例子所示：from(bucket: "mydb") |> range(start: -1h) |> filter(fn: (r) => r["_measurement"] == "mymeasurement") |> map(fn: (r) => ({ r with value: r.value * 2 })) |> filter(fn: (r) => r.value > 100) |> aggregateWindow(every: 1m, fn: sum, createEmpty: false) |> group(columns: ["location"]) |> join(tables: {stream1: {bucket: "mydb", measurement: "stream1", start: -1h}, stream2: {bucket: "mydb", measurement: "stream2", start: -1h}}, on: ["location"]) |> alert(name: "value_above_threshold", message: "Value is above threshold", crit: (r) => r.value > 100) |> to(bucket: "mydb", measurement: "output", tagColumns: ["location"])案例二：应用类 SQL 指令，创立流计算以及定义流计算规定，如下：CREATE STREAM current_stream TRIGGER AT_ONCE INTO current_stream_output_stb AS SELECT _wstart as start, _wend as end, max(current) as max_current FROM meters WHERE voltage <= 220 INTEVAL (5S) SLIDING (1s);

一、实践1、什么是内存对齐古代计算机中内存空间都是依照 byte 划分的，在计算机中拜访一个变量须要拜访它的内存地址，从实践上看，仿佛对任何类型的变量的拜访都能够从任何地址开始。 但在理论状况中，通常在特定的内存地址能力拜访特定类型变量，这就须要对数据在内存中寄存的地位有限度。各种类型不是依照程序排放，它们须要依据肯定的规定在空间上排列，这就是对齐。 2、为什么须要内存对齐（1）移植起因：不是所有的硬件平台都能拜访任意地址上的任意数据的，各个硬件平台对存储空间的解决上有很大的不同，局部平台对某些特定类型的数据只能从某些特定地址开始存取。 比方，市面上有些架构的 CPU 在拜访一个没有进行对齐的变量时会产生谬误，这时 CPU 会进入异样解决状态并且告诉程序不能继续执行。 举个例子，在 ARM 硬件平台上，当操作系统被要求存取一个未对齐数据时会默认给应用程序抛出硬件异样。所以，如果不进行内存对齐，代码就不具备移植性，而且难以发展在很多平台上的开发工作。 （2）性能起因：只管内存是以字节为单位，然而大部分处理器并不是按字节块来存取内存的。它个别会以双字节、4 字节、8 字节、16 字节甚至 32 字节为单位来存取内存，咱们将上述这些存取单位称为内存存取粒度。 如果变量的地址没有对齐，可能须要屡次拜访能力残缺读取到变量内容，而对齐后可能就只须要一次内存拜访。因而，内存对齐能够缩小 CPU 拜访内存的次数，进步 CPU 拜访内存的吞吐量。 举个例子，思考 4 字节存取粒度的处理器拜访 int 类型变量，该处理器只能从地址为 4 的倍数的内存地址开始读取数据。如果未通过内存对齐，获取该 int 类型的数据须要进行两次内存拜访，最初再进行数据整顿失去残缺数据： 如果通过内存对齐，一次内存拜访就能失去残缺数据，缩小了一次内存拜访： CPU 读取内存是高耗时的指令，内存对齐是在内存的使用量和 CPU 计算间的居中的优化策略。这种策略是由编译器和 CPU 独特决定，并且程序员能够设置对齐的长度。 通过上述介绍的内存对齐的必要性，咱们能够晓得，如果不了解内存对齐，在编程时就可能产生上面的问题： (1) 程序运行速度变慢； (2) 应用程序产生死锁； (3) 操作系统解体； (4) 程序会毫无征兆的出错，产生谬误的后果。 然而，咱们在写程序时个别无需思考对齐，通常是依赖编译器来为咱们抉择适宜的对齐策略。 3、内存对齐规定在学习内存对齐规定前，咱们先一起理解下四个重要的基本概念： 指定对齐值：pragma pack (n) 时指定的对齐值 n；根本数据类型的本身对齐值：根本数据类型本身占用的存储空间大小，如 char 类型为 1，short 类型为 2，int 类型为 4，double 类型为 8 等；构造体或类类型的本身对齐值：构造体或类的成员中本身对齐值最大的值，如 struct a 中有 char、int 和 double 共 3 个类型的数据成员，那么 struct a 的本身对齐值是 8 字节；数据成员、构造体和类的无效对齐值：本身对齐值或指定对齐值中的较小值。理解上述概念后，咱们一起来理解具体的内存对齐规定。 ...

去年 8 月咱们在 TDengine 开发者大会上正式公布了 TDengine 3.0，TDengine 也由此降级成为了一款云原生时序数据库（Time Series Database，TSDB）。为了主观、精确、无效地评估 TDengine 3.0 的性能指标，咱们决定应用 TSBS（Time Series Benchmark Suite）作为基准性能测试平台，针对 DevOps 场景的数据集对 TDengine 3.0 开展整体（包含写入、查问、存储、资源耗费等）性能评估。 TSBS 是一个时序数据处理（数据库）零碎的性能基准测试平台，提供了 IoT、DevOps 两个典型利用场景，它由 Timescale 开源并负责保护。作为一个性能基准测试平台，TSBS 具备便捷、易用、扩大灵便等特点，涵盖了时序数据的生成、写入（加载）、多种类别的典型查问等性能，并可能主动汇总最终后果。因为其凋谢开源的特点，失去了泛滥数据库厂商的反对，作为业余的产品性能基准测试平台被若干数据库厂商宽泛应用。 以下的性能基准报告均应用了 TSBS 作为根底 Benchmark 平台，咱们从时间跨度和公布厂商的知名度同时来看，就能发现，根底测试平台 TSBS 曾经具备了很高的认可度： 2018 年 11 月，VictoriaMetrics 的创始人 Aliaksandr Valialkin 公布 《High-cardinality TSDB benchmarks: VictoriaMetrics vs TimescaleDB vs InfluxDB》，将 VictoriaMetrics 与 TimescaleDB、InfluxDB 进行性能比照。2018 年 11 月，文章《ClickHouse Crushing Time Series》中比照了 TimescaleDB, InfluxDB, ClickHouse 在时序数据场景下的性能。2020 年 3 月，Cloudera 在网站博客中公布《Benchmarking Time Series workloads on Apache Kudu using TSBS》，在 DevOps场景 中比照了 Apache Kudu, InfluxDB, VictoriaMetrics, ClickHouse 等整体性能体现。2020 年 3 月， Redis 公布了基于 TSBS 的性能报告《RedisTimeSeries Version 1.2 Benchmarks》。 2020 年 8 月，Timescale 在其官网博客公布了性能比照报告《TimescaleDB vs. InfluxDB: Purpose Built Differently for Time-Series Data》。2021 年 8 月，QuestDB 公布了 QuestDB 与 TimescaleDB 的性能比照报告——《QuestDB vs. TimescaleDB》。DevOps 场景是一个典型的时序数据利用场景，TSBS DevOps 场景提供了 CPU 状态的模仿数据，针对每个设施（CPU）记录其 10 个测量值（metric），1 个工夫戳（纳秒分辨率），10 个标签值（tag）。生成的数据每 10 秒距离一条记录，具体的内容和示例数据如下： ...

大家好，明天我分享的是 KaiwuDB 数据服务平台（KDP），一款由咱们独立自主研发，以 KaiwuDB 为外围的数据服务产品。 KDP 产品建设指标是实现数据的云边端的一体化治理，提供一套残缺的全生命周期服务。接下来我将围绕时代背景、时序数据新解法及性能展现 3 大维度开展具体介绍。 01 数字时代下的时机与挑战以后，我国数字经济倒退已进入到快车道，数字经济产业一直壮大，为各大行业企业发明了转型和倒退的时机。 物联网概念起源于 1999 年，5G 的正式商用进一步推动了物联网的高速倒退，在物联网背景下，数据信息的价值将被进一步放大。据公开数据分析，我国物联网市场规模会由 1.7 万亿增长到 2.6 万亿，5 年复合增长率达 9%。同时，中国企业级市场规模在将来几年也将持续放弃着寰球最大的物联网市场体量。 物联网产生源源不断的时序数据，在这里将呈现第 1 个挑战：如何收集、解决、贮存海量的时序数据？ 咱们先一起来看看时序数据的处理过程，从数据诞生到剖析决策共经验 6 大环节：数据收集、数据荡涤、数据存储、数据管理 4 个环节约占全流程的 80%；初始数据分析和数据可视化仅占全流程约 20%。 在占比最多的 4 个流程中，广泛会遇到以下问题： 物联网协定多种多样，数据难以聚合；因为业务起因数据扩散在各大零碎；数据时效性差，需长期调用人力进行数据散发；数据格式、颗粒度各异导致数据品质低；数据的复用性差，依照需要解决的数据仅能应答某些场景。 说到这里，后面提到的挑战难度也不可避免地增大—如何及时且疾速地收集、解决、存储海量数据！ 业内搭档会抉择通过大数据弱小的计算能力和 BI 可视化能力实现数据即时剖析，企业通常会将开源的 Kafka、Redis、Hbase、Hadoop、Spark 等大数据软件组合应用，利用集群能力解决海量数据。 然而，也将不可避免地带来很多问题：首先，多零碎开发语言和工具不统一导致联调工夫长，进而重大影响整体开发效率；其次，多零碎运维后盾互相独立，减轻运维团队累赘；此外，数据在多套零碎中的传输，因为解决计划的限度，运行效率较低。这些问题都将拖慢整体利用推向市场的节奏。 02 有更加合乎物联网特色的解决方案吗？答案是必定的。 为此，咱们推出了 “KaiwuDB+KDP”的解决方案，致力于解决数据流程中的收集、荡涤、存储、治理、初始数据分析及数据可视化全流程的痛点。 咱们的建设理念是帮忙企业疾速成建设“业务即数据，数据即服务”的计划。 顶层：助力物联网企业倒退，减速生态迭代；中层：实现物理设施双向通信，既能集成数据，又能下发指令，向上提供高效实时数据服务，真正买通数据源端到企业治理端的数据流；底座：撑持数据和支流数据源的实时/离线汇入，联结 KaiwuDB 提供一站式的实时数据解决方案。 KDP 以 KaiwuDB 为外围，聚焦工业物联网、数字能源、交通车联网、智慧产业等畛域，搭建具备高速数据集成构建个性的行业级物联网实时信息交融平台。 为帮忙大家加深了解，这里提炼四个关键词来开展具体介绍： “高速”：集成高速、运算高速、页面响应高速，满足用户对高性能需要；“集成”：实时接入、离线接入、多源集成、多模数据集成，满足用户对多源异构数据的集成治理需要；“构建”：提供实时剖析、流式计算、数据模型解决、数据可视化等性能，为用户提供数据生产的各种根底能力；“行业级”：咱们会针对指标行业继续推出一系列模型与计划，包含通用的剖析计划与定制化计划。 如图是 KDP 产品架构，从数据采集、荡涤、存储、治理、可视化全流程都可在 KDP 实现。数据起源反对数据库、Kafka、Excel等，通过缓存、数据管道写入到 KaiwuDB 中，此外提供了齐备工具监控以上流程，最终在 KDP 以可视化模式进行后果展现。 03 KDP 到底能带来什么样的价值？联合当下现状，这里为大家展现 KDP 的 5 大外围亮点性能： 亮点 1：围绕用户应用场景，咱们开展了详尽的需要剖析，保障用户开箱即用，大幅升高学习老本； 亮点 2：低代码构建数据 BI 剖析，反对自主报表剖析，非专业开发人员也可上手操作，升高应用累赘； ...

大家好，首先非常感谢大家参加本次 KaiwuDB 1.0 系列产品发布会。作为国内数据库新生品牌力量，KaiwuDB 是浪潮集团控股的数据库企业，咱们聚焦在工业物联网、数字能源、交通车联网、智慧产业等疾速倒退的重要畛域，心愿为各大行业客户提供残缺的数据服务解决方案。 01 为什么咱们关注上述提到的几大畛域？首先，当然是市场自身的的力量，物联网现有规模曾经以百亿美元来掂量，同时还在一直成长；其次，从政策上看，数字能源、工业互联网都是国家重点倒退的行业和畛域，是将来国家经济倒退的重要驱动力。分享一组基于 IDC 等权威机构综合得出的数据： 以后寰球已接入的互联网设施高达 130 亿且这个数字预计 4 年后翻番；预计到 2030 年，寰球 3/4 的设施都将是物联网设施。 物联网设施须要接入互联网并须要具备肯定的数据采集和传输能力，预计直到 2025 年，物联网设施产生的数据会达到 79.4 ZB，同时这个数字还在以每年 60% 的速度增长，这是真正的数据爆炸。这样量级的数据给 IT 基础设施，特地是数据基础设施带来的挑战是前所未有的。 02 物联网数据不正是时序数据么？这些挑战不正是时序数据库已解决或正在解决的问题么？答：Yes and no！ 时序数据是物联网数据中占比最大的局部，所以物联网数据面临的挑战也是时序数据库要解决的问题，比方海量时序数据写入、大规模数据聚合等。值得注意的是，传统数据库的技术形式是很难应答如此大量级的数据。 好在时序数据也具备某些特点，比方它的写入基本上以追加写入为主，更新和删除操作较少；它的查问通常是以工夫范畴作为条件等。针对这些个性，咱们能够有方向地优化引擎，这也正是为什么会呈现时序数据库这一大钻研方向。 时序数据的体量个别是比拟宏大的，而且增速较快。大量数据会带来十分强的程度扩大需要，所以弹性伸缩是一个根本的治理需要。时序数据还具备一个独有特点：物联网设施规模十分宏大，假如把这些数据设施看成数据对象，传统数据库是无奈治理的。 如果仍旧采纳传统形式治理设施，势必将带来重大的性能问题。所以海量时序数据、程度扩大等这些的确是时序数据库所要解决的外围的问题。 然而，物联网利用要解决的数据又不仅仅是时序数据。比方数字能源场景下存在用电量、发电量等时序数据；另一方面也会波及很多关系性的数据，比方在能源计价，缴费，能源交易等场景下存在的高价值关系型数据。这就意味着，须要把时序数据和关系数据进行深度交融，能力更加全面地满足客户需要。 此外大量物联网数据势必也会带来昂扬的治理老本，用户会心愿把数据价值最大化进而笼罩治理老本。换言之，咱们数据库厂商须要用数据帮忙企业判断趋势，辅助决策甚至实现主动疾速响应，助力企业打造外围竞争力。 然而，很显然这些都不是明天的时序数据库的强项。所以说，物联网场景下肯定是须要一款很弱小的时序计算引擎，但又不止于时序数据库。 03 那针对当下现状，KaiwuDB 1.0 时序数据库具备哪些外围劣势？这里，咱们对 KaiwuDB 1.0 时序数据库的技术劣势做了一个总结：“快人一步”： 时序数据库最大的挑战—解决海量数据，所以“快”是至关重要的；产品最终是服务于“人”，也就是咱们的用户。一款产品好不好，最终肯定是用户说了算；数据库是物联网利用的重要基础设施，但它也只是物联网利用中的一环，提供“一”站式整体解决方案，能力更好地解决用户业务难点；对于物联网来说，分“布”式不是一个可选项，而是一个必选项。 04 “快”能够说是 KaiwuDB 最闪亮的一点咱们一起来看看如下几组数据：KaiwuDB 可反对每秒 100 万记录入库操作；千万记录简单查问毫秒内可实现；20 亿记录数据摸索 1 秒内实现；500 万记录数据可实现 15 层下钻。上述数据都已在先前与用户的单干中失去验证。 说到这里，可能有搭档想问：明天的市场有那么多的产品，凭什么说本人快呢？这里我就要来介绍一下 KaiwuDB 的外围专利技术—实时就地计算。 传统计算机在解决数据时，须要把数据读取到内存上再进行组织解决，磁盘上的数据其实是被组织成页的模式配置在内存中。咱们须要把页 Page 还原成记录 Record 后，数据库能力进行解决。 这里就会产生屡次转换，这种转换对于传统数据库来说是十分必要。然而从性能角度看，如果利用上没有大量的并发更新，比方时序数据这种模式，那这样的操作形式其实是会带来的额定开销，简略来说就是不够快！ 随着硬件的倒退，咱们能够有内存数据库，把数据都放在内存里计算。然而当呈现时序数据后，它还是会受内存限度，无奈高效地解决这种需要，并且在扩展性上也有肯定的问题。 上述现状也促使咱们推出就地实时计算这一专利技术，咱们不再因循传统的从磁盘到内存多种转换解决的模式，而是把磁盘和内存融为一体，把磁盘映射成内存，让计算引擎间接面对数据。换言之，咱们把计算推向数据，而不是把数据移向计算。 其中，咱们采纳的映射的形式是 Memory-mapped I/O 技术。咱们把文件映射到内存地址上，和传统的 IO 形式相比，Memory-mapped I/O 在很多的场景下具备性能劣势。比方传统的 IO 在读取数据时，须要把数据从零碎的缓冲区复制到用户空间的缓冲区，Memory-mapped I/O 是不须要这步操作的，所以它会更快。 ...

以下是实录文章精简版欢送大家点赞、珍藏、关注！ 大家好，明天介绍将分为 3 局部：首先从物联网蓬勃发展的时代背景登程，咱们一起来看看数据库到底将面临怎么的挑战与时机；接着我将为大家具体 KaiwuDB 1.0 时序数据库的外围性能；最初以经典场景的利用案例收尾，帮忙大家更好地理解咱们是如何落地开展利用的。 01 时代背景下新机遇—“数字化+智能化”数字化转型已成为我国重要的倒退策略，从中国制作新基建到十四五布局政策主基调，信息经济未然成为时代倒退下的新机遇。 到底何为数字化和智能化转型？— 以制造业为例，将制造商智能传感器剖析技术和人工智能联合起来，赋能企业的监控、洽购、生产、经营等各个环节，并辨认潜在危险，从而帮忙企业继续优化流程，躲避问题产生，始终保持在最优级别运行，打造企业外围竞争力。 02 “数字化+智能化”的难点与挑战数字化转型并不是一个简略我的项目，继续地数字化和智能化会面临很多的问题。随着物联网、工业互联网、车联网、智能电网等畛域的飞速发展，预计到 2025 年，我国物联网设施数将靠近 200 亿，整个世界部署的物联网设施将靠近 760 亿台。 如此量级的设施每时每刻都在产生数据，这些海量数据及其衍生数据又具备简单多样的状态；与此同时，海量数据的实时监控和剖析决策需要也在一劳永逸；这些对系统的存储和计算能力都发动了微小挑战。 现有大数据处理平台广泛架构简单臃肿，不同的厂商的组件也并非全副开源，同时现有解决形式在性能上也很难满足实时剖析决策的需要；再者，随着越来越多的生产环节发展了数字化和智能化转型，导致业务零碎愈发宏大和简单，海量并发和低时延的需要骤增；此外随着边缘技术的倒退，更多对施行性要求十分高的业务逻辑被顺延到边缘端。如何使得云边端互相协同成为了新的刚性需要。 03 KaiwuDB 1.0 时序数据库外围性能针对这些问题，咱们心愿可能有这样的一款的时序数据库—首先它能够反对简单多样的数据接入零碎，实现时序数据的高速写入和高效存储；同时它能够提供丰盛且超速的时序计算服务，并为简单利用场景提供各类接口。 基于此构想，明天咱们也正式推出 KaiwuDB 1.0-时序数据库。KaiwuDB 1.0 是一款次要面向工业物联网、交通车联网、数字能源等畛域的时序数据库，提供了弱小的简单查问能力，旨在以性能存储海量时序数据，精准反对时序大数据分析，并提供良好的 SQL 反对。 亮点性能 1 ：海量时序数据高吞吐写入 这是一款合格的时序数据库所必备的性能之一。面对大量设施产生的海量时序数据，为了保障达到低时延的业务需要，数据库必须可能实现高速高并发的写入海量时序数据。同时，在工业物联网、车联网等场景下，传感器高频地产生时序数据，有时甚至达到了毫秒级，因而时序数据库必须可能反对到毫秒精度的数据写入。 亮点性能 2 ：批量高速简单查问与多维聚合 反对间接获取时序数据最新值，提供多种维度的聚合查问接口，包含工夫窗口和标签分组，以及诸如 Min、Max、Average、Count、Sum 等根本的聚合函数；反对嵌套查问，提供了按标签过滤，包含精度和精度匹配和含糊匹配；反对近实时的数据一般查问，针对上千万条数据，查问速率能够达到秒级；反对肯定维度下对数据进行切分并在切分出的数据空间中进行一系列的计算。 亮点性能 3 ：高稳定性和高安全性 时序数据库常常被利用于工业互联网、智能制作、交通车联网等对安全级别要求十分高的畛域。所以，高可靠性和高安全性是帮忙他们掂量一款时序数据库是否合格的重要规范之一。 KaiwuDB 1.0 时序数据库可对接入的数据库用户进行身份认证，反对创立不同权限的账户，对不同账户授予不同的读写权限，并且受权可批改。同时，操作系统和数据库系统的用户权限是可拆散的，可实现对数据库内的操作进行审计。此外，KaiwuDB 1.0 时序数据库可能反对客户端和服务器端的加密通信。 亮点性能 4 ：高达 1:10 的数据压缩比 海量时序数据对存储造成了微小的压力，如何在不影响读写性能的根底上，无效地升高存储老本？对于一款时序数据库，这也是一项绕不开的必答题，KaiwuDB 针对时序数据的特点做了相应的优化，反对在线数据压缩，压缩数据无需解压即可应用，压缩比可达到 1:7 - 1:10。 亮点性能 5 ：反对多种支流编程语言KaiwuDB 对规范的 SQL 语法有着良好的反对度，反对 SQL 的写入和规范 SQL 的查问。同时咱们提供了多种支流编程语言的连接器，例如 C++、Java 等。 ...

InfluxDB Cluster - InfluxDB Enterprise 集群的开源代替计划InfluxDB Cluster - 一个开源分布式工夫序列数据库，InfluxDB Enterprise 的开源代替计划 GitHub：chengshiwen/influxdb-clusterWiki 文档：chengshiwen/influxdb-cluster/wiki下载地址：chengshiwen/influxdb-cluster/releases目录简介个性架构概念Docker 疾速开始Kubernetes & Helm Chart装置配置HTTP 接口治理指南简介InfluxDB Cluster 是一个开源的 工夫序列数据库，没有内部依赖。它对于记录指标、事件和执行剖析很有用。 InfluxDB Cluster 启发于 InfluxDB Enterprise、InfluxDB v1.8.10 和 InfluxDB v0.11.1，旨在代替 InfluxDB Enterprise。 InfluxDB Cluster 易于保护，能够与上游 InfluxDB 1.x 放弃实时更新。 个性内置 HTTP API，无需编写任何服务器端代码即可启动和运行。数据能够被标记 tag，容许非常灵活的查问。相似 SQL 的查询语言。集群反对开箱即用，因而解决数据能够程度扩大以。集群目前处于生产就绪状态。易于装置和治理，数据写入查问速度快。旨在实时应答查问。这意味着每个数据点在到来时都会被计算索引，并且在 < 100 毫秒内返回的查问中立刻可用。架构InfluxDB Cluster 装置由两组独立的过程组成：Data 节点和 Meta 节点。集群内的通信如下所示： 网络架构图： Meta 节点通过 TCP 协定和 Raft 共识协定互相通信，默认都应用端口 8089，此端口必须在 Meta 节点之间是可拜访的。默认 Meta 节点还将公开绑定到端口 8091 的 HTTP API，influxd-ctl 命令应用该 API。 ...

时序数据的概念和特点时序数据是指工夫序列数据，是按工夫程序记录的数据列。时序数据能够是期间数，也能够时点数。对于数据库而言，时序数据个别是一系列带有工夫戳和数据值的数据点，且各列数据值类型雷同、数值随工夫戳递增（减）或在无限区间内稳定。 时序数据罕用压缩编码方式从时序数据的特点来看，通用的压缩算法和按行压缩并不能很好的压缩时序数据，因而时序数据库大多都针对不同类型的数据按列采纳不同压缩编码方式来缩小数据存储的空间占用，进步存储空间利用率。 DeltaDelta差分编码又称增量编码，编码时，第一个数据不变，其余数据转换为与上一个数据的Delta。该算法利用宽泛，如须要查看文件的历史更改记录（版本控制、Git等）。在时序数据库中，很少独自应用，个别搭配Simple8b或者Zig-Zag一起应用，压缩成果更好，上面举例说明Delta工夫戳压缩： 工夫戳个别采纳 int64 类型进行存储，须要占用 8byte(64bit) 存储空间。最间接的优化就是存储工夫戳的差值，这里须要起始工夫戳和 Delta 的最大范畴阈值。有两种罕用的实现思路： 1.存储相邻两个工夫戳差值 Delta(n) = T(n) - T(n-1) 2.存储与起始工夫戳的差值 Delta(n) = T(n) - T(0) 假如起始工夫戳为 1571889600000，Delta 的最大范畴阈值为 3600s，每个 Delta 的数值须要 13bit 能够存储。因而以上工夫戳数据共占用空间为 64 + 13 * 4 = 116bit。思路 1 的劣势是不须要对块内数据顺次遍历，然而相比思路 2 可能须要更为频繁地更换起始工夫，依据理论需要抉择适合的压缩计划。 Delta of Delta又名二阶差分编码，是在Delta编码的根底上再一次应用Delta编码，比拟适宜编码枯燥递增或者递加的序列数据。例如 2,4,4,6,8 , Delta编码后为2,2,0,2,2 ，再Delta编码后为2,0,-2,0,0。通常也会搭配Simple-8B或者Zig-Zag一起应用。 Facebook Gorilla 有具体论述 Delta-of-Delta 编码的计算形式，针对不同时间跨度的数据给出了一种较为通用的解决计划（a+b=c, a示意存储标识位占用bit，b示意存储data须要的bit）。 仍然通过一组工夫戳数据来直观感触下 Delta-of-Delta 编码的压缩成果： 仍然假如起始工夫戳为 1571889600000，Delta 的最大范畴阈值为 3600s，占用存储空间比照如下： Delta 算法： 64 + 13 * 7 = 155bit 。Delta-of-delta 算法： 64 + 9 4 + 1 3 = 103bit 。能够看出 delta-of-delta 算法相比 delta 算法进一步取得了更高的压缩率。在理论利用场景中，海量时序数据的工夫戳都是密集且间断的，绝大部分都满足 delta-of-delta=0 的条件，这样能够大幅度降低工夫戳的存储空间。 Zig-Zag在一些状况下，咱们应用到的整数，往往是比拟小的。比方，咱们会记录一个用户的id、一本书的id、一个回复的数量等等。在绝大多数零碎外面，他们都是一个小整数，就像1234、1024、100等。而咱们在零碎之间进行通信的时候，往往又须要以整型（int）或长整型（int64）为根本的传输类型，为了传输一个整型（int）1，咱们须要传输00000000_00000000_00000000_00000001 32个bits，除了一位是有价值的1，其余全是根本无价值的0。 对于正整数来讲，如果在传输的时候，咱们把多余的0去掉（或者是尽可能去掉无意义的0），传输有意义的1开始的数据，那咱们就能够做到数据的压缩了，比方：00000000_00000000_00000000_00000001这个数字，咱们如果能只发送一位1或者一个字节00000001，就将压缩很多额定的数据。 zigzag给出了一个很巧的办法：补码的第一位是符号位，他妨碍了咱们对于前导0的压缩，那么，咱们就把这个符号位放到补码的最初，其余位整体前移一位：然而即便这样，也是很难压缩的，因为数字绝对值越小，他所含的前导1越多。于是，这个算法就把正数的所有数据位按位求反，符号位放弃不变，失去了这样的整数： 而对于非负整数，同样的将符号位挪动到最初，其余位往前挪一位，数据放弃不变。 负数、0、正数都有同样的示意办法了，咱们失去了有前导0的另外一个整数。不过他还是一个4字节的整数，咱们接下来就要思考怎么样将他们示意成尽可能少的字节数，并且还能还原。 比方：咱们将1转换成(00000000_00000000_00000000_00000010)zigzag这个当前，咱们最好只须要发送2bits（10），或者发送8bits（00000010），把后面的0全副省掉。因为数据传输是以字节为单位，所以，咱们最好放弃8bits这样的单位。zigzag引入了一个办法，就是用字节本人示意本人。举个例来讲： 咱们先依照七位一组的形式将下面的数字划开：1.将它跟(~0x7f)做与操作的后果，高位还有信息，所以，咱们把低7位取出来，并在倒数第八位上补一个1(0x80)：110011112.将这个数右移七位：(0000-0000000-0000000-0000000-0001111)zigzag3.再取出最初的七位，跟(~0x7f)做与操作，发现高位曾经没有信息了（全是0），那么咱们就将最初8位残缺的取出来：00001111，并且跳出循环，终止算法4.最终，咱们就失去了两个字节的数据[11001111, 00001111]解压过程：对于每一个字节，先看最高一位是否有1(0x80)。如果有，就阐明不是最初一个数据字节包，那取这个字节的最初七位进行拼装。否则，阐明就是曾经到了最初一个字节了，那间接拼装后，跳出循环，算法完结。最终失去4字节的整数。 Simple-8BSimple-8B编码方式是2010年墨尔本大学一博士在论文中提出的，在 simple 8b 中，一组整数会被存在一系列固定大小的数据块中。每个数据块里，每个整数都用固定字长来示意，这个固定字长由数据块中最大的整数来示意。而每个数据块的第一位用来标记这个数据块字长。 应用这个技术能够让咱们只须要在每个数据块中只记录一次字长，而不是去记录每个整数的字长。而且因为每个数据块的字长是一样的，咱们也可能推算出来数据块里中存储了多少个整数。 Bit-Packing这种算法是把文本用须要的起码的位来进行压缩编码。 比方八个十六进制数：1，2，3，4，5，6，7，8。转换为二进制为：00000001，00000010，00000011，00000100， 00000101，00000110，00000111，00001000。每个数只用到了低4位，而高4位没有用到（全为0），因而对低4位进行压缩编码后失去：0001，0010，0011，0100，0101，0110，0111，1000。而后补充为字节失去：00010010， 00110100，01010110，01111000。所以原来的八个十六进制数缩短了一半，失去4个十六进制数：12，34，56，78。 对于bool类型，占用一个字节（8bit），但其理论无效的只有最初1bit的0 或1，因而，在对bool类型进行压缩时，应用bit-packing压缩率很高：8个bool值，原先占用8byte(64bit)，应用bit-packing压缩后只须要1byte(8bit)，压缩率高达12.5%。 XORXOR编码方式是Gorilla内存数据库一篇论文中提出的，其次要针对时序数据（工夫戳+测量值的键值对），对工夫戳和测量值别离编码达到压缩成果。 针对工夫戳采纳前述delta of delta解决，针对测量值采纳如下办法进行压缩：1.第一个测量值不压缩（64bit）。2.对于后续的测量值，如果以后值跟前一个值的XOR后果为0，即值相等，仅存储一位‘0’。3.如果XOR后果不是0，计算XOR中前导零和尾随零的个数，存储位’1’后接a)或b):a). 应用‘0’作为管制位，如果有意义位块落在前一个有意义位块中，即前导零和后导零的数量至多与前一个值雷同，应用该信息作为块地位，只存储有意义的XOR值。b). 应用‘1’作为管制位，将前导零数的长度存储到下5位，而后将有意义的xor值的长度存储到下6位。最初存储XOR值的有意义的位。(截图自Gorilla: A Fast, Scalable, In-Memory Time Series Database) ...

本文作者： CDY，观远算法团队工程师，毕业于伦敦帝国理工学院计算机系，次要钻研方向为工夫序列算法及其落地利用，热衷于尝试各类离奇工具库，深耕于批发消费品场景，解决供应链的优化问题，为客户提供基于机器学习的AI解决方案。概述Kats是Facebook公布的一个专门为了工夫序列服务的工具库。它作为一个Toolkit包，提供了四种繁难且轻量化的API。  预测（封装了10+models，次要是传统的工夫序列模型，这些模型有反对ensemble的API，联合工夫序列特色的性能甚至能够做meta-learning）检测（官网叫做detection，大抵是对工夫序列做相似于异样检测，change point detection之类的检测）工夫序列特色（API非常简略，能够失去65个工夫序列相干的features）模仿（simulator，能够依照某些时序特色比方seasonality去发明工夫序列来不便试验）针对这四种性能，上面说一下我本人的尝试和尝试过程中的了解。 上面的内容可能会比拟粗疏，如果想间接看总结的优缺点倡议拉到最初。 Basic Representation首先这类库都会封装一个数据类型，用来作为它的API的调用输出。相似的库有AutoGluon的TabularDataset，fastai里的TabularDataLoaders。 在Kats外面，所有的pandas dataframe，series甚至numpy都能够先转成一个叫做TimeSeriesData的货色因为传统工夫序列并不是很关怀表格类数据其余的特色，而更专一于指标列，所以其实TimeSeriesData只须要两样货色，工夫和指标列大抵的调用形式如下，试验的dataset 是我司(Guandata)本人开发的一个机器学习工具库里的data，是一个销量预测的数据，蕴含的列是store，sku，date和sales。from gaia.datasets.toy_datasets import load_interview_datasetfrom kats.consts import TimeSeriesDatainterview_df = load_interview_dataset()# 首先简略的把某一个store,sku的数据拿进去做成工夫序列single_ts_df = interview_df[(interview_df['store']==0)&(interview_df['sku']==114)]# 第一种变成Kats.TimeSeriesData的办法# 作为工夫序列只关怀指标列和工夫, TimeSeriesData(df), 其中df只包含两列,一列叫做time，一列叫做valuesingle_ts_df = single_ts_df[['date', 'sales']].rename(columns={'date':'time', 'sales':'value'})single_kats_ts = TimeSeriesData(single_ts_df)# 第二种是显式的传入对应列(传入的能够是dataframe，series或者numpy array)single_kats_ts2 = TimeSeriesData(time = single_ts_df.time, value=single_ts_df.value)那么目前single_kats_ts就是一个kats.consts.TimeSeriesData的datatype的货色了，这个数据类型的大部分操作以及print之后的输入都是和pandas.DataFrame截然不同，它还比一般的pandas DataFrame多反对了一些操作，最有用也是用的最多的就是画图： import matplotlib.pyplot as plt%matplotlib inlinesingle_kats_ts.plot(cols=['value'])plt.show()BTW, kats当然反对multi-variate timeseries，形式就是在初始化的时候value传入一个dataframe，而后外面的列都成为variate value了。因为篇幅起因不再介绍，没有什么更非凡操作。 Simulator在咱们理论应用过程中，咱们可能面对的更多的是一些表格类的数据，但在很多传统的工夫序列工作中，会更关怀指标列，并把它作为一条工夫序列，所以咱们首先先模拟出N条univariate的工夫序列，模仿实在销量预测场景中by store by sku的每一条销量预测曲线。 from kats.utils.simulator import Simulator# simulate 90 days of datasim = Simulator(n=90, freq="D", start = "2021-01-01")# 目前 simulator反对合成一些工夫序列# 合成的办法包含依据STL合成，或者Arima的系数产生ts，并且退出一些trend, noise等# 简略介绍一下arima_sim是一个用ARIMA model来模仿ts的函数，参数包含ar的参数，ma的参数，d代表非安稳工夫序列的单位根(unit root)数。arima_sim_list = [sim.arima_sim(ar=[0.1, 0.05], ma = [0.04, 0.1], d = 1) for _ in range(10)]# 通过simulator，咱们还能在之前的序列根底上减少很多drift,trend,seasonality等# 上面就是调用形式，强行在外面加一些changepoint# generate 10 TimeSeriesData with trend shiftstrend_sim_list = [    sim.trend_shift_sim(        cp_arr = [30, 60, 75],        trend_arr=[3, 15, 2, 8],        intercept=30,        noise=50,        seasonal_period=7,        seasonal_magnitude=np.random.uniform(10, 100),        random_seed=random_seed    ) for _ in range(10)]# generate 10 TimeSeriesData with level shiftslevel_shift_list = [    sim.level_shift_sim(        cp_arr = [30, 60, 75],        level_arr=[1.35, 1.05, 1.35, 1.2],         noise=0.05,           seasonal_period=7,           seasonal_magnitude=np.random.uniform(0.1, 1.0),        random_seed=random_seed    ) for _ in range(10)]通过源码能够看到，在arima_sim的时候，它模仿了arima的输入作为一个array，而后调用之前TimeSeriesData进行输入。 相似地，Simulator还反对很多add_noise, add_trend, add_seasonality之类的函数，其实就是还在trend_shift_sim之类的函数里调用到了。 TsFeatures这是我感觉这个库最爽的性能，靠这个性能咱们能够做很多的事件。 家喻户晓，目前表格类数据的时序预测场景树模型是比拟NB的，DL和传统时序剖析仿佛差点意思，我集体认为次要是在理论场景下，大部分数据和特色工程适应性更加匹配树模型。比方实在数据的seasonality可能不显著，data drift大，工业对训练模型的速度有肯定耗费要求等。 但回头想，也有一部分数据，可能就用简略的arima训练就能达到不错的成果，或者在开始你须要一个不错的baseline作为根底，转发一篇大佬的文章，用这些时序的特色进行分类，察看，剖析，是能够选取到不同的模型进行尝试的。那这时候，对tsFeatures的提取就异样要害了。 之前也接触过一些疾速且主动提取time-series related features的库，比方tsfresh，然而在我无限的tsfresh应用尝试中，我的集体体验非常的差，总结为： 内存耗费大，速度慢提取到大量特色（4000+）个特色，而且命名极其简单，特色名很长。据说通过衍生规定能够缩小提取的特色进行减速，我也置信必定是我用法不精，然而作为一个主动提取时序特色的库，用起来的老本有点高了，我起初就再也没用过tsfresh。 在Kats这个库中，提取就是效率很高。 import warningswarnings.filterwarnings('ignore')model = TsFeatures()# 还是之前的那一单条数据ts_feats = model.transform(single_kats_ts)```失去的ts_feats是一个包含了40个特色的dict： ...

近些年来物联网技术高速倒退，广泛应用到了诸如智慧出行、智慧工业、智能家居等场景中，无论是何种场景的利用，都离不开对数据的“采集-解决-存储-剖析”这套流程。然而不同的利用，其本身的数据个性和业务需要大不相同，那么对于实现上述流程所需的产品组件也会有所区别。总体来说，咱们能够依照利用和数据特点分为三类场景：时序数据、音讯数据、元数据。 如上图展现了物联网场景的三大类数据。以智能汽车场景为例，车辆定时会更新以后的最新状态信息，例如发动机以后转速、以后车速等，这些形容车辆最新状态信息的数据咱们称之为元数据。而在智能汽车行驶过程中，车辆的状态数据会随着工夫的变动而变动，例如车辆一段时间内的车速、胎压等，这些形容车辆历史状态信息的数据咱们称之为时序数据。还有一种数据场景是对车辆行为进行管制的指令音讯，例如调节车辆空调温度指令下发以及车辆执行命令后的后果反馈，这些控制指令的上下行咱们称之为音讯数据。不同类型的数据利用的场景各不相同，所以对存储系统的需要也有所不同。本文章次要剖析设施元数据场景有哪些业务需要，以及如何抉择适合的存储组件和实现计划。 场景需要首先以工业设施元数据场景为例，来剖析有哪些具体的业务需要。在工业生产过程中，通常设施会以某个固定的周期（或由某个事件触发）上报最新运行状态信息，这也就是上文提到的设施元数据，例如设施 ID ，以后运行温度、湿度、压力值等。业务上依据设施元数据来治理设施，例如查问某台设施的以后运行状态，多条件在线检索设施，“圈选”出符合条件的设施汇合。通过剖析设施元数据来实时监控设施的运行状态，出现异常及时响应，防止故障产生等。上面对业务需要做一个小结： 设施状态数据定时上报，通过数据网关上云存储。存储侧须要可能反对大规模设施元数据实时更新。存储侧须要反对依据任意个设施指标作为条件查找设施。如果查问设施量较少，咱们称之为“设施检索”；如果一次查找的设施数量十分大，咱们称之为“设施圈选”。设施状态更新后，存储侧须要反对对异样状态实时监测。技术难点依据下面的场景需要，咱们能够总结为对存储侧的几个性能需要： 存储规模：反对海量设施元数据存储，可能达到千万级甚至亿级。实时更新：反对高并发、低提早的数据更新。任意字段组合检索：反对依据一个或多个字段值组合条件来检索设施元数据。反对并发检索：对应设施圈选的场景，在设施圈选的后果集较大的场景下，须要反对并发检索以晋升圈选性能。数据更新实时计算：可能探测数据更新，并可能对更新后数据进行实时计算。存储选型元数据存储场景对数据库的规模、性能、查问能力等各个方面都有较高的要求。通常来说，关系型数据库 MySQL 都是作为存储选型的第一选项，这是因为 MySQL 是最为通用，大家也最为相熟的数据库产品。然而 MySQL 个别只在小规模的数据存储（千万级）和低并发的数据更新（一万内 QPS）场景下体现优异，当规模变大时，MySQL 的性能会急剧下降，这显然不满足元数据存储的要求。到这里，大家可能会想到应用开源数据库 HBase，因为 HBase 的分布式架构可能反对大规模数据存储和写入，在这一点上是能够满足元数据存储需要的。然而 HBase 只反对了基于主键（RowKey）查问，无奈在属性列上建索引查问，所以在设施检索、圈选时的效率极低，极其状况下可能会以全表扫描加数据过滤的这种形式来查问数据，这一点上无奈满足上述的需要。最初咱们来看下表格存储 Tablestore，Tablestore 是一款云原生 Serverless 的结构化数据存储，原生具备大规模的数据存储和低提早数据更新，同时提供了多元索引性能，可能反对任意字段组合检索，是物联网平台底层依赖的外围数据存储系统，撑持了亿级设施的元数据管理。上面对上述几个存储产品在实现元数据存储场景中的能力做一个总结： 存储规模实时更新任意字段组合检索并发检索数据更新实时计算MySQL小反对（难以扩大反对（单列索引）不反对反对HBase大反对（程度扩大）不反对不反对反对Tablestore大反对（程度扩大）反对反对反对Tablestore 技术介绍表格存储 Tablestore 是一款云上的结构化数据存储产品，具备极为丰盛的产品性能和生态，提供了物联网存储 Iotstore、宽表引擎、多元索引等能力来满足时序数据、音讯数据、元数据场景的需要。针对于时序与音讯数据场景的解决方案不在本文章中开展解说。上面咱们来看一下 Tablestore 提供了哪些能力来满足元数据存储的场景需要。 Tablestore 采纳了多引擎的存储架构，不同的场景需要实现的原理不同，先来看一张图： 其中宽表引擎是一个分布式的数据表，负责设施元数据的存储与更新。宽表引擎采纳了多分区（shard）的分布式构造，每一个分区对应了一台 worker。在元数据写入的过程中，路由节点依据主键的范畴将写入申请路由到不同的分区进行解决，当某个分区的负载达到瓶颈时，服务端会主动决裂成多个分区，使得宽表引擎的整体吞吐能力可能线性进步。如下图所示： 相比于宽表引擎， 索引引擎底层采纳了倒排索引、空间索引等存储构造，可能反对任意数据组合检索、聚合。索引引擎别离提供了两种查问接口： search 和 parallelScan。 search 接口。search 接口反对多条件组合查问、含糊查问等能力，能够满足设施检索的场景需要。parallelScan 接口。parallelScan 接口反对以多并发的形式进行数据检索，可能大幅提高数据返回速度，实用用于设施元数据圈选场景。Tablestore 提供了与 Flink 实时计算对接的能力，可作为 Flink 的数据源表，将实时变动的设施元数据推送到 Flink 中进行计算，从而实现元数据检测的业务场景。与此同时，反对将计算的后果再写入 Tablestore 的数据表中，来实现记录异样数据后果。 分享完元数据存储场景的需要和 Tablestore 的技术原理后，咱们来看看如何搭建一个设施元数据场景的物联网架构。物联网数据上报网关后，依据不同的利用类型个别有三种数据流向，应用服务器订阅生产，长久化存储，转发到音讯队列。设施元数据的次要需要是存储和计算，所以咱们能够列出一个简略的数据流转过程：网关->存储->流计算。上面将介绍通过物联网平台 + Tablestore + Flink 来搭建元数据管理平台。 物联网平台 + Tablestore + Flink 实现元数据管理计划基于云上搭建的元数据管理平台架构如下图所示： ...

近年来，在能源和环保的压力下，新能源汽车成为了将来汽车倒退的新方向。为反对其疾速倒退，我国出台了一系列搀扶政策，在《新能源汽车产业倒退布局（2021-2035年）》中就有提出，到 2025 年新能源汽车新车销售量要达到汽车新车销售总量的 20% 左右，其市场广大水平可见一斑。当初炽热的主动驾驶技术，也是新能源汽车的一大劣势，而主动驾驶又须要各类传感器产生的源源不断的时序数据来辅助判断，所以与时序数据相干的采集、解决和存储等各项需要也显著增长。 始终以来，对于新能源车企来说，在时序数据的存储上，抉择的大多都是 MongoDB 或 Apache HBase，这两大数据库技术绝对更加成熟，在业务规模尚未扩张之前，因为设施不多、数据量不大，加上查问场景繁多，尚且能够满足业务需要。随着业务的减速扩张，写入速度太慢、撑持老本过低等问题也逐步浮现。 以零跑汽车为例，此前他们将时序数据别离存储在 MongoDB 和 HBase 中，前者会将数据全副存储在内存中，过高的存储老本导致只能存储一段时间内的数据，且存储的数据格式须要通过业务组织解决，不仅业务变更不灵便，能够做的业务也十分无限。后者用来存储局部实时信号，须要整套 HDFS 做撑持，应用、运维和人力等老本都很高，须要大数据相干的人才能力保障安稳运行。而且公司的 HBase 环境是公有云环境，而云平台在私有云环境，跨专网业务时常会被网络问题影响。 在适合的时候抉择适合的数据库是反对业务倒退的要害，但数据库的更换也并不是头脑一热就能拍板决定的，还须要进行数据库产品的周密察看和调研，能力选中真正适宜本身业务倒退的“天选数据库”。那对于车企来说，到底什么样的数据库更加适宜呢？咱们无妨从它所产生的数据自身去做一下剖析。 从时序数据自身的特点看车企实用的数据库类型当下车联网曾经成为车企布局将来的一个重要场景，如工业互联网一样其产生的数据分类为时序数据，而时序数据具备如下特点： 所有采集的数据都是时序的数据都是结构化的一个采集点的数据源是惟一的数据很少有更新或删除操作数据个别是按到期日期来删除的数据以写操作为主，读操作为辅数据流量安稳，能够较为精确的计算数据都有统计、聚合等实时计算操作数据肯定是指定时间段和指定区域查找的而关系型数据库次要对应的数据特点却与之差异甚广：数据写入上大多数操作都是 DML 操作，插入、更新、删除等；数据读取逻辑个别都比较复杂；在数据存储上，很少有压缩需要，个别也不设置数据生命周期治理。很显然，关系型数据库是不适宜用于解决时序数据的。 企业在抉择数据库文件系统等产品时，最终目标都是为了以最佳性价比来满足数据写入、数据读取和数据存储这三个外围需要。而时序数据库（Time-Series Database）正是从以上特点登程、以时序数据的三个外围需要为最终后果进行设计和研发的，因而在数据处理上会更加具备针对性。 近年来，随着物联网的疾速倒退、业务规模和数据量的疾速暴发，国内外越来越多的科技企业发现了用传统关系型数据库来存储时序数据的问题，针对时序数据库的选型调研也由此开始。 目前市面上的时序数据库品种繁多，老将如 InfluxDB、Prometheus，后起之秀如 OpenTSDB、TDengine 等，在对本身业务进行时序数据库选型时，除了性能各方面的考量外，大部分企业还会考量其是否具备程度扩大能力。 在性能层面，TDengine 曾做过几家时序数据库的比照——TDengine 与 InfluxDB、OpenTSDB、Cassandra、MySQL、ClickHouse 等数据库的比照测试报告，聚焦工业互联网的和利时也从使用者的角度做过一些比照——从四种时序数据库选型中怀才不遇，TDengine 在工控畛域边缘侧的利用，大家可做参考。而在程度扩大能力方面， TDengine 早在 2020 年就实现了单机和集群版的双开源，同时凭借着性能上的硬核体现，深受着车联网、物联网、工业互联网等企业客户的青眼。 上面咱们以 TDengine Database 为例，看看时序数据库针对车联网场景下宏大的时序数据的写入、查问、存储是如何实现的。 基于TDengine，你能够怎么设计架构和表作为时序数据库引擎，TDengine Database 不须要基于 Hadoop 生态搭建，也不须要拼装 Kafka、Redis、HBase 等诸多组件，它将数据处理中的缓存、音讯队列、数据库、流式计算等性能都对立在了一起，这样轻量级的设计不仅让它的安装包很小、对集群资源耗费很少，同时也在肯定水平上升高了研发、运维老本，因为须要集成的开源组件少，因此零碎能够更加强壮，也更容易保证数据的一致性。能够试验一下，如果你要搭建一套车队管理系统，你只须要写一个 Java 利用，再加上 TDengine 齐全可能实现。 从时序数据的特点登程，TDengine 没有抉择风行的 KV 存储，而是应用了结构化存储。同时，基于物联网场景里，每个数据采集点的数据源是惟一的、数据是时序的，且用户关怀的往往是一个时间段的数据而非某个非凡工夫点等特点登程，TDengine Database 要求对每个采集设施独自建表。也就是如果有 1000 万个设施，就须要建 1000 万张表。 这就是 TDengine Database 的外围翻新点之一——“一个设施一张表”，以此保障每个采集点的数据在存储介质上以块为单位进行间断存储，缩小随机读的同时成数量级晋升查问速度，还能够通过无锁、追加的形式写入，晋升写入速度。 ...

通过2个月的致力，MatrixDB 4.3 终于在11月初正式亮相，打造性能全面超过的6种新个性。 1.继续汇集隆重上线继续汇集是时序场景中常常应用的个性，用于频繁获取工夫窗口内数据点的汇集值，用户能够在时序表上定义感兴趣的继续汇集视图，视图中包含用户指定的汇集函数。 在数据继续加载到表的过程中，汇集查问在后盾继续运行，当用户想获取时序表的对应汇集后果时，间接查问继续汇集视图即可，通过物化视图实时同步源表数据并做排序归并，汇集查问时 QE 间接扫描归并后的后果并在 QD 上做二阶段汇集，使汇集查问更高效： 数据同步： 排序归并： 二阶段汇集： 2.反对 “空间” 数据类型空间数据是以空间地物的地位、形态、大小及其散布特色等信息数据，通常以坐标数据来示意，包含点线面、经纬度以及栅格数据等基本空间数据结构，如地图、实时交通流量等，各类空间数据无时不刻的在各方位出现，数据量宏大，天然也给数据管理减少了难度。 MatrixDB 4.3 版本开发增强版 PostGIS 组件，完满的反对空间数据类型的存储和计算。 3.MatrixGate 性能再降级数据接入容错机制加强数据接入的容错机制，单条数据格式谬误不会影响所在批次的其余数据，并且会在 HTTP 响应中蕴含具体错误信息，包含谬误行和谬误字段： 日志归档与删除新增 --log-archive-hours、--log-remove-after-days 等配置参数来管制日志的压缩归档和主动删除。 迁徙模式上线高效同步 Greenplum5、Greenplum6、MatrixDB 集群中的数据表到本集群。 4.可视化数据表上线在 MatrixDB 治理页面新增可视化数据表版块，通过界面查看表名、存储类型、表类型和预估行数等，以及集群状态与表的状态。 5.主动分区图形化治理 图片分区表能够通过图形化界面设置模板和自动化分区管理策略。 6.MARS 存储引擎降级 图片tag_id 反对数据类型在整型根底上新增：text , varchar , name , numeric；并反对多分组键，即用多个列作为tag_id。MARS 存储引擎的数据反对更新。去官网下载,体验最新 MatrixDB 4.3 版本！ MatrixDB - 下载 原文链接 本文为 yMatrix 原创内容，未经容许不得转载。

摘要：时序图是对立模型语言UML（Unified Model Language）中一种用来示意实体间交互关系的图。1 前言在定义零碎间接口或模块间接口时，时序图应用起来十分不便，工作中常常波及要与第三方零碎协商定义接口，或者定义零碎内多模块间接口的状况，常常会看到很多时序图。有的时序图画的很漂亮，很好的帮忙读者精确了解业务和实现办法，而有的时序图则读起来人云山雾罩，苦楚不已。本文不打算再说一遍时序图的构造和步骤，只想阐明时序图中常常遇到次要问题，并许下一个美妙的欲望：心愿当前的工作中再也不要遇到难读的时序图。 时序图是对立模型语言UML（Unified Model Language）中一种用来示意实体间交互关系的图，英文Sequence Diagram，有的人把它称为序列图、程序图、循序图，集体习惯于称为时序图，下文都以这个名字来称说。 画时序图的工具十分多，从晚期的Rational Rose、Sybase Power Designer、Visio，到Enterprise Architect、StarUML，甚至用Typora来画Markdown格调时序图也不错，再到当初按公司的要求换用亿图图示Edraw，这些工具都不错，略微适应下就能画出丑陋的时序图了。 值得举荐的是，公司CloudDesign在线设计工具提供的CloudModeling绘图工具用起来也相当难受，既便于在团队分享，又提供了Word插件便于导入设计文档，如果批改了时序图也只须要在word文档中更新一下就主动刷新了，十分不便，强烈推荐应用。网址：https://clouddragon.huawei.co... 上面进入正题。 2 关键点1：必须明确上下文把握了这一点就胜利了一大半，没有做到这一点就根本画不分明了。 为什么这句话说这么狠？不就画个时序图嘛，关上下文什么事？因为看过太多让人痛恨的时序图都栽在这个问题上。 咱们晓得时序图中参加交互的实体只有两类，即角色（Actor）和对象（Object），如果连交互的实体都不能明确的定义和达成统一，忽东忽西，忽大忽小，具体交互的流程怎么可能说分明，使所有读者和写作者达成统一呢。 为阐明这个问题，以车联网的场景举个例子，比方近程管制个性的交互时序图。 车辆受权交互时序图 近程开车窗交互时序图 近程开车门交互时序图 如图所示，咱们看到交互实体中呈现了多个相似但又不同的表述，例如“车主”、“被受权用户”、“被分享用户”这一组，“手机App”和“车主App”这一组，“TSP平台”、“TSP零碎”和“车云”这一组，而在车辆方面，有时称为“车辆”这么大的粒度，有时又称细分为“TBox”、“车身管制模块”、“PEPS”。 这里仅仅举例了3个交互时序图，而一个简单零碎往往会呈现几十上百个，当每个时序图的作者都得心应手的对交互实体进行命名时就会呈现极其凌乱的场面，最终貌似每个时序图都看起来很有情理，放在一起看却难以精确了解，使读者抓狂。 解决办法：很简略，画出一个上下文图，把所有时序图中波及的交互实体都放进去，规定它们的名字，要求所有时序图中的实体必须与上下文图中保持一致，不得本人定义新的。如果的确须要减少新的实体，那么首先更新上下文，在上下文图中把实体定义进去能力应用。 例如针对上述车联网的场景，减少一个这样的上下文就能够更加清晰： 在理论我的项目中，能够利用工具来实现这个一致性。例如CloudModeling绘图工具中，咱们会定义残缺的零碎上下文和零碎逻辑架构视图，要求所有的交互时序图必须从这外面链接援用角色和，而不是本人新建一个。 3 关键点2：决定该不该把某个实体放进时序图在下面的例子中，在车辆相干实体中，有时称为“车辆”这么大的粒度，有时又称细分为“TBox”、“车身管制模块”、“PEPS”。事实上，“TBox”、“车身管制模块”、“PEPS”都是车辆外部模块的一部分，那么到底什么状况下该把“车辆”这么大的粒度放入时序图，什么状况下该把“TBox”、“车身管制模块”、“PEPS”这样的外部模块展现进去呢？ 集体了解是这样的：实体是否展现与业务场景和所设计的对象亲密关联，只有在业务场景中与所设计对象有间接交互的实体才有必要放入时序图中，间接交互实体则该当去掉。 在下面的例子中，如果咱们设计的对象是TSP及车主手机App，那么车辆外部的实体局部就不须要开展，只须要展现与车云间接交互的TBox模块即可，如下： 近程开车门交互时序图 然而，如果咱们设计的对象换成了车身管制模块，那么交互的实体就该当省略TSP及车主手机App相干的实体，把关注点调整到与车身管制模块间接交互的实体上来，例如： 近程开车门交互时序图 4 关键点3：响应音讯要与申请音讯离开时序图中交互实体间程度的线条用来示意音讯，最常见的有三种： 4.1 同步音讯（Synchronous Message）与返回音讯（Return Message）同步音讯（也称为调用音讯）肯定要与返回音讯成对应用，特地要强调的是：返回音讯款式不得应用同步音讯的款式，这是两个齐全不同的事件。同步音讯示意一个实体对另一个实体的一个接口调用，被调用方要按流程实现提供接口的编码，并按返回音讯内容要求进行返回；调用方须要按流程实现调用接口的编码，并对返回音讯内容进行解决。为了更分明的阐明问题，往往会在音讯中注明要害的参数。 常常看到的谬误是不辨别同步音讯和返回音讯，乱画一气，十分让人恼火。有时会看到像这样的时序图，特地留神其中红色的音讯线条，看起来仿佛“TBox”实体对“TSP”实体的一个接口调用，但理论问一问作者，发现并不是这样，而是下面音讯的返回音讯。这样的画法就给人造成一种错觉，认为交互实体单方须要实现一个新的接口。 4.2 异步音讯（Asynchronous Message）音讯发送者通过音讯把信息发给音讯接收者，而后持续本人的流动，不期待接收者返回音讯。 4.3 自关联音讯（Self-Message）示意实体本身须要实现一个处理过程，也能够调用一个内部实体的音讯。 同样以下面车联网场景为例，假设设计的对象是TSP及车主手机App，那么咱们只能对这两个实体合成开发工作，如图，咱们要求“车主手机App”实现“提供开车门性能”，具体蕴含向TSP的申请开车门音讯调用及返回后果的解决；“TSP”要实现“提供开车门接口”，具体蕴含向TBox的下发开车门指令及返回后果的解决，还蕴含一个发送短信告诉的异步音讯，TSP提供的开车门接口申请参数中应蕴含要害的用户token、车辆ID信息，返回后果中应蕴含要害的胜利/失败、错误信息。 留神：这里引入了一个新的实体“短信核心”，也该当在上下文图中先加进去能力应用。 近程开车门交互时序图 5 总结三个关键点：所有交互实体放进上下文，不间接交互的实体去掉，响应音讯要与申请音讯离开。如果你画的时序图确保以上三个关键点都做到了，我想至多拿出去给大家看的时候会少挨一点埋怨。 点击关注，第一工夫理解华为云陈腐技术~

摘要：为大家带来当下时序数据模型的支流TSDB剖析及云厂商在时序数据模型方面的最新动静。本文分享自华为云社区《【万字干货】OpenMetric与时序数据库存储模型剖析（下）》，作者：麻利的小智 。 在上篇《【万字干货】OpenMetric与时序数据库存储模型剖析（上）》文章中，咱们理解了时序数据模型的相干常识内容，接下来为大家剖析当下支流TSDB及云厂商在书序数据模型方面的最新动静。 支流TSDB剖析InfluxDBInfluxDB[9]是一个一站式的时序工具箱，包含了时序平台所需的所有：多租户时序数据库、UI和仪表板工具、后盾解决和监控数据采集器。如下图9所示。 图9 InfluxDB反对动静shcema，也就是在写入数据之前，不须要做schema定义。因而，用户能够随便增加measurement、tag和field，能够是任意数量的列。 InfluxDB底层的存储引擎经验了从LevelDB到BlotDB，再到自研TSM的历程。从v1.3起，采纳的是基于自研的WAL + TSMFile + TSIFile计划，即所谓的TSM（Time-Structured Merge Tree）引擎。其思维相似LSM，针对时序数据的个性做了一些非凡优化。TSM的设计指标一是解决LevelDB的文件句柄过多问题，二是解决BoltDB的写入性能问题。 Cache: TSM的Cache与LSM的MemoryTable相似，其外部的数据为WAL中未长久化到TSM File的数据。若过程故障failover，则缓存中的数据会依据WAL中的数据进行重建。 WAL (Write Ahead Log) : 时序数据写入内存之后依照SeriesKey进行组织。数据会先写入WAL，再写入memory-index和cache，最初刷盘，以保障数据完整性和可用性。根本流程包含：依据Measurement和TagKV拼接出乎series key；查看该series key是否存在；如果存在，就间接将时序数据写入WAL、时序数据写缓存；如果不存在，就会在Index WAL中写入一组entry；根据series key所蕴含的因素在内存中构建倒排索引、接着把时序数据写入WAL和缓存。 TSM Files: TSM File与LSM的SSTable相似。在文件系统层面，每一个TSMFile对应了一个 Shard，单个最大2GB。一个TSM File中，有寄存时序数据（i.e Timestamp + Field value）的数据区，有寄存Serieskey和Field Name信息的索引区。基于 Serieskey + Fieldkey构建的形似B+tree的文件内索引，通过它就能疾速定位到时序数据所在的数据块。在TSMFile中，索引块是依照 Serieskey + Fieldkey 排序 后组织在一起的。 TSI Files：用户如果没有按预期依据Series key来指定查问条件，比方指定了更加简单的查问条件，技术手段上通常是采纳倒排索引来确保它的查问性能的。因为用户的工夫线规模会变得很大，会造成倒排索引耗费过多的内存。对此InfluxDB引入了TSIfiles。TSIFile的整体存储机制与TSMFile类似，也是以 Shard 为单位生成一个TSIFile。 在InfluxDB中有一个对标传统RDB的Database概念。逻辑上每个Database上面能够有多个measurement。在单机版中每个Database理论对应了一个文件系统的目录。 InfluxDB作为时序数据库，必然包含时序数据存储和一个用于度量、标记和字段元数据的倒排索引，以提供更疾速的多维查问。InfluxDB在TSMFile上依照上面的步骤扫描数据，以取得高性能查问成果： • 依据用户指定的工夫线（Serieskey）和FieldKey在索引区找到Serieskey+FieldKey所在的 索引数据块。 • 依据用户指定的工夫戳范畴在索引数据块中查找数据对应在哪个或哪几个索引条目 • 把检索出的索引条目所对应的时序数据块加载到内存中进一步扫描取得后果 和 Prometheus 一样，InfluxDB 数据模型有键值对作为标签，称为标签。InfluxDB 反对分辨率高达纳秒的工夫戳，以及 float64、int64、bool 和 string 数据类型。相比之下，Prometheus 反对 float64 数据类型，但对字符串和毫秒分辨率工夫戳的反对无限。InfluxDB 应用日志构造合并树的变体来存储带有预写日志，按工夫分片。这比 Prometheus 的每个工夫序列的仅附加文件办法更适宜事件记录。 ...

摘要：该论文针对多维时序数据的异样检测问题，提出了基于GAN和AutoEncoder的深度神经网络算法，并获得了以后State of the Art (SOTA)的检测成果。论文是云数据库翻新LAB在轨迹剖析层面获得的关键技术成绩之一。本文分享自华为云社区《ICDE'21 DAEMON论文解读》，作者：云数据库翻新Lab。 导读本文( DAEMON: Unsupervised Anomaly Detection and Interpretation for Multivariate Time Series)是由华为云数据库翻新Lab联结电子科技大学数据与智能实验室发表在顶会ICDE’21的文章。该文章针对多维时序数据的异样检测问题，提出了基于GAN和AutoEncoder的深度神经网络算法，并获得了以后State of the Art (SOTA)的检测成果。ICDE是CCF举荐的A类国内学术会议，是数据库和数据挖掘畛域顶级学术会议之一。该论文是华为云数据库翻新LAB在轨迹剖析层面获得的关键技术成绩之一。 1. 摘要随着IoT时代的到来，越来越多的传感器采集的时序数据被存储在数据库中，而怎么样解决这些海量数据以开掘其中的价值是近些年来学术界和工业界热门的钻研点。本文钻研了多指标时序数据的异样检测问题，以诊断产生时序数据的实体可能存在的异样。 本文的次要奉献如下： 提出了DAEMON算法，其算法基于自编码器和GAN构造，自编码器用于重构输出时序数据，GAN构造别离用于束缚自编码器的两头输入以及自编码器的重构输入以使自编码器构造的训练过程更加鲁棒并且缩小过拟合。本文提出了利用多维异样检测的重构后果进行根因定位的形式DAEMON算法可能在测试数据集上击败现有算法2. 背景 3. 算法设计 图.1 DAEMON的网络结构 A. 算法构造简介DAEMON算法的总体网络结构如图.1所示，蕴含了三个网络模块，变分自编码器G_AGA(其中蕴含编码器G_EGE和解码器G_DGD，编码器和解码器同时作为两个GAN构造中的生成器), 对应编码器的GAN构造判断器D_EDE以及对应解码器的GAN构造判断器D_DDD。 上面简述一下各个网络结构的具体性能 B. 数据预处理数据荡涤：利用spectral residual算法首先清理掉训练数据集中可能存在的异样点，这样一来，VAE将会更精确的学习到工夫序列的失常散布。数据归一化：本文利用MINMAX归一化形式对训练以及测试数据进行归一化。C. 线下训练过程DAEMON的网络蕴含三个模块，一个变分自编码器，两个GAN构造的判断器。因为GAN构造网络须要异步训练，因而，DAEMON构造对应了三个异步的训练过程，每个训练规程都对应了各自的优化器以及损失函数。 上面别离介绍各个模块： GAN构造1：GAN构造1中，生成器对应的是变分自编码器的编码器局部G_EGE，而判断器对应的是D_EDE，此GAN构造的目标是束缚生成器的散布q(z)q(z) 。由GAN的规范损失函数公式能够推导出生成器和判断器的损失函数别离为 GAN构造2：GAN构造2中，生成器对应的是变分自编码器中的解码器局部G_DGD，判断器对应的是D_DDD，此GAN构造的目标是进一步束缚自编码器的输入以让自编码器更好的学习时序数据的失常散布。和下面类似，生成器和判断器的损失函数为 变分自编码器模块：变分自编码器用于数据的重构，其本身的损失函数用输出和输入的一范数间隔定义 留神。GAN构造1，2中的判断器损失函数都只波及到判断器自身，在训练的时候，能够间接用(1)，(3)进行训练，而生成器的损失函数和变分自编码器的损失函数同时波及到一个公共的模块，即变分自编码器自身，因而，在训练自编码器网络时，实际上要同时训练三个损失函数，具体的办法为，令三个损失函数的加权和为变分自编码器的损失函数，即 在线下训练时，顺次针对公式(1)，(3)，(6)进行训练。 D. 在线检测过程在线数据W_{x_t}Wxt输出到检测器后，失去重构W'_{x_t}Wxt′，之后把被检测点x_txt和被检测点的重构x'_txt′做比拟以求取异样得分，即 E. 根因剖析从公式(7)中能够看出，异样得分实际上是由每一个维度的误差所加和得出的，因而，在根因定位的时候，间接从S_{x_t}^jSxtj中找出最大的kk个得分对应的指标既可视为根因可能呈现的地位。 4. 试验4.1 环境设定在仿真中，作者比照了四个罕用且公开的时序异样检测数据集，即SMD, SMAP, MSL, SWaT数据集。上面是各个数据集的具体指标。 作者在仿真中比照的指标为precision, recall以及F1-score。 在比照算法方面，作者比照了8种现有的算法，其中VAE算法是DAEMON去掉GAN构造后的构造，目标是为了测试GAN束缚的有效性。为了体现本文GAN构造的有效性以及创新型，作者还比照了另外两种利用GAN构造的异样检测算法GANomaly以及BeatGAN。其次，OmniAnomaly是业界驰名AIOps团队，北大的裴丹传授团队发表在KDD上的异样检测算法。 下表是作者颁布的参数设置 4.2 检测后果仿真比照后果如下表所示 能够看到，在四个公开数据集上，DAEMON都能达到SOTA的成果。 4.3 工夫耗费同时，从训练工夫和检测时间来看，DAEMON算法也能在现有算法中达到中上的程度 图.2 训练检测时间比照 4.4 根因定位最初，作者比照了根因定位的准确性，DAEMON也能在比照算法中达到SOTA的性能 5. 利用本算法曾经被集成在华为云时序存储与剖析组件GaussDB for Influx中，用于监控指标的异样检测与根因定位。 ...

摘要：随着物联网数据量的增长，“时序数据库”成为企业面临的“必答题”。据钻研机构Forrester预测，物联网所带来的产业价值要比互联网高30倍，到2020年，中国物联网产业将成长为一个超过五万亿规模的微小市场。 5G、AI、区块链等新一代信息技术与物联网减速交融。在智能互联的愿景中，物联网零碎的机器、设施和传感器收集的数据，通过人工智能技术进行剖析与关联，以更有意义的形式服务用户。然而，随着物联网数据量的增长，“时序数据库”成为企业面临的“必答题”。 高性能时序数据库，是物联网的数据存储底座时序数据库是一种针对时序数据进行垂直优化的数据库，专门用于存储和治理时序数据。向宇举例到，某个酒店在早晨8：00有200个房间被入住，那个8：00工夫点上存储的200的数字就是时序数据。 在物联网和运维监控场景下，如服务器CPU和内存使用量、电动汽车的工况数据、或是应用服务的业务指标等等，各种被采集的数据指标项多达千万甚至上亿，甚至一次采集的指标数据就可能超过数10GB，这些数据都必须要在规定工夫内全副写入数据库。并且，指标数据通常距离几秒就会被采集一次，如此海量的时序数据必然要求数据库要具备大并发写入能力和很高的数据压缩效率。 此外，时序业务通常还须要将数据从数据库中检索进去，以近乎实时的可视化形式展示，不便剖析和决策，这对数据库的查问性能也有着严格的要求。在这种场景下，传统的关系型数据库最大的问题在于数据短少压缩，查问效率低下，时序数据库一开始就被设计为高吞吐、低时延、高数据压缩率，以满足物联网和运维监控场景下对性能和贮存老本的诉求。也正是因为时序数据库的这些特点，在制造业、银行金融、社交媒体、能源、智慧家居等行业畛域都有大量的利用场景。 凝固10多年软硬件技术教训，将来挑战重重依据IDC的一份白皮书预测，到2025年寰球数据总量将达到175ZB，这其中30%为时序数据。时序数据库是在最近10年才真正倒退起来，这期间呈现了许许多多的时序数据库，光DBEngines网站收录的寰球时序数据库就多达有30多种。 向宇谈到，相比关系型数据库，时序数据库稍微简略一些，没有简单的事务反对，也没有针对单条数据的更新和删除操作。但要做好一个时序数据库并非易事，就像造车一样，要造好一辆车，单纯购买整机组装测试是远远不够的，还须要思考品质、性能、舒适性、功能性、安全性等等，一辆车凝固着人类智慧与文化的结晶。 打造一款时序数据库，须要凝固数十年数据库畛域倒退的硬件和软件技术和教训，如存储、平安、分布式系统、编译、算法、数据结构、架构设计等等，更要做到系统安全、牢靠、稳固、高效和多场景通用。“将来会有越来越多的企业心愿利用时序数据库挖掘出更多有价值的信息，时序数据库在海量工夫线治理、数据压缩、读写性能等方面正面临着微小的技术挑战。”向宇讲到。 云原生存算拆散架构，华为云数据翻新Lab实际时序数据库，作为整个物联网的数据存储底座，同时也是云厂商基础设施的重要局部。作为寰球云服务提供商，华为云的迅速倒退，其背地是大量基础设施的扩张，如何能把所有的基础设施和云服务齐全监控起来，是摆在运维团队背后不得不去解决的技术问题。现有的开源时序数据库曾经不能满足华为云监控数据日益增长的诉求，监控指标数量从数百万迅速减少到数十亿，每秒数据写入量从数亿条迅速增长到数十亿条，迫切需要一款自研的时序数据库能够撑持运维团队的监控零碎。 在2018年开始，向宇所在的华为云数据翻新Lab开始着眼于将来物联网和运维监控场景下的时序数据存储与治理，自研时序数据库GaussDB（for Influx）。在通过外部场景的验证后，GaussDB（for Influx）于2020年正式上线对外商用。 GaussDB(for Influx)采纳云原生存储与计算拆散架构，反对分钟级弹性节点扩缩容，做到不迁徙数据的同时还把事件给做了；反对亿级工夫线，每天万亿条数据写入不是问题；反对数据无损压缩，采纳自适应数据压缩算法，将数据压缩比进步到1:20；使用MPP架构、向量化、预聚合等相干技术，相比开源的OpenTSDB、InfluxDB等时序数据库，对于像单工夫线条件查问和多维聚合查问这类在时序数据库中较为常见的查问，性能上有很大幅度的晋升。 向宇介绍到，华为云的一个业务从Cassandra切换到GaussDB(for Influx)后，计算节点从总共39个（热集群18个，冷集群9个，大数据分析集群 12个）升高到了9个节点，缩减4倍计算节点。存储空间耗费从每天1TB升高到100GB以内，缩减10倍存储空间耗费。 目前华为云时序数据库GaussDB(for Influx)曾经服务15+外部和内部客户，已成为华为云基础设施重要组成部分。 研发之路没有现成的参考答案，迎难而上侧面“刚”回忆时序数据库GaussDB（for Influx）研发过程的时候，向宇说道，一个零碎从诞生到成熟，往往随同着长期的Bug修复和联合场景的继续优化。因为任何人都无奈提前把所有的利用场景都想到并且测试笼罩到，GaussDB(for Influx) 也不例外。 当初研发GaussDB(for Influx)时，向宇团队遇到的第一个问题就是“过程OOM（内存耗尽触发操作系统爱护机制）退出”。大家都晓得，呈现OOM只可能有两个起因，一是内存透露，二是内存实在应用过多。 家喻户晓，数据库外面的数据是寄存到磁盘文件，高效率的数据检索往往须要在内存中建设文件索引，不便疾速定位数据在文件中的地位。在时序数据库中，当数据在数据库中保留的工夫越长，数据文件就会越大，文件数量也就越多。程序重启过程中，须要将每个数据文件的元数据读取到内存组织为索引，这里的元数据次要包含以后文件寄存有多少工夫线，每个工夫线的数据在文件中的偏移量等等。在运维监控的场景下，工夫线的数量是呈指数增长，过后序数据库的工夫线超过亿级，虚拟机规格不变的状况下，问题呈现了，元数据无奈全副寄存内存再转化为索引，于是程序呈现OOM无奈重启。 向宇进一步论述道，时序数据库难就难在这里，因为绝大部分用户或者场景不会达到呈现问题的工夫线和数据量，面对计算资源无限，而数据量太大的状况，行业中并无卓有成效的现成办法，解决这样的问题，往往须要联合技术和教训。举个例子，程序重启过程中加载元数据，为防止在内存积压太多数据，能够抉择限流的形式，那么每次解决的数据量阈值该当如何设置就依赖长期的零碎开发教训，太大可能问题还会存在，太小又耗时过长。 “有问题不可怕，可怕的是没有问题。当问题产生时，咱们的抉择是侧面‘硬刚’，呈现一个毁灭一个！”向宇谈到。不难看出，也正是他们的这种不畏艰难，用“匠人”精力开发出华为云基础设施重要组成部分，并且曾经服务15+外部和内部客户的华为云时序数据库GaussDB(for Influx)。 点击关注，第一工夫理解华为云陈腐技术~