Tdengine

小 T 导读：对于青岛协同翻新金融研究院来说，始终打交道的交易记录、价格等数据均为时序数据，在抉择数据库（Database）时，TDengine “一个设施一张表”的设计吸引了他们的眼光。目前 TDengine 曾经在其生产零碎中稳固运行了 38 周。本文总结了他们在选型、搭建等方面的所思所想，以及利用 TDengine 之后所获得的成果。 企业简介：为切实服务国家经济、金融倒退，中国金融量化迷信与技术协同翻新核心在山东青岛设立了一个高端智库，即青岛协同翻新金融研究院。依靠于翻新核心的国内顶级专家资源、在量化金融与金融科技领域的国内当先实践钻研与实务技术成绩，研究院致力于促成我国金融畛域创新型尖端实践人才、适用性高端技术人才的教育与造就，晋升相干畛域在风险管理、资产定价、产品设计等各方面的定量分析与决策技术水平，踊跃保护金融稳固、促成金融倒退。 单刀直入地说，咱们抉择 TDengine 的理由很简略——“一个设施一张表”的模型很适宜咱们的量化剖析场景。实质上来讲，交易记录、价格等都是时序数据，其实就是“一只股票一张表”，所以非常符合。 在咱们的业务场景中，TDengine 次要负责三点：一是对回测的数据反对，因为它能够轻松抗住海量数据的写入。目前咱们的数据入库形式是应用 Python 连接器间接写入 TDengine（6030 端口）。具体形式为：会通过券商的直连贯口将他们提供的数据做一个 SQL 拼接，利用拼接 SQL 的形式，单个 SQL 写入几千行数据，将少量数据一次性写入到一个表中。目前，咱们每天新增数据量大略在 2000 万行左右。 （注：股票回测是指设定了某些股票指标组合后，基于历史曾经产生过的实在行情数据，在历史上某一个工夫点开始，严格依照设定的组合进行选股，并模仿实在金融市场交易的规定进行模型买入、模型卖出，得出一个时间段内的盈利率、最大回撤率等数据。） 二是基于以上数据进行的回测数据分析。 三是局部盘中策略的数据预加载。 但因为这块有每秒几万次的查问用在高频业务上，所以临时还没有尝试利用 TDengine，目前大部分盘中业务应用的还是 Redis。据社区工作人员示意，将来的 TDengine 3.0 版本将会反对自定义工夫范畴的缓存，届时或者能够帮到咱们。 除了上述次要的应用场景之外，TDengine 还帮忙咱们实现了局部深度学习模型的数据训练和测试。 具体落地与实际效果在目前的业务中，咱们选用了三台 8 核 16G 服务器，以此搭建了三正本的集群。 这里大家须要留神，三节点并不代表三正本，也并不代表你的数据库曾经具备了高可用性。数据库的高可用是在 "create database xxxx replica 1/2/3" 的过程中指定的，然而如果你遗记了也没关系，前期能够通过 "alter database xxxx replica 1/2/3" 来动静地进行调整。TDengine 会主动复制出一批分片（Vnode），并平均地散布在各个节点之上，成果如下”show 库名.vgroups”所示。 （注：如果数据量很大，在数据同步的过程中因为网络稳定导致数据文件复制中断，也能够手动复制 Vnode 目录下的文件到指定节点再启动。） 依据不同类型的业务，咱们创立了 7 张不同的超级表，子表数量为 33076 张，目前咱们导入的数据总量曾经达到了 46 亿之多，其中最大的一张超级表白到了 26 亿行，理论磁盘占用大略在 130GB 左右。表的列数如下图”columns”所示，数据类型以 Float 为主。 ...

小 T 导读：在平安解决方案 SuperCloud 中，亿咖通面临着磁盘占用量大、车辆最新状态实时查问难以实现两个外围问题。最终，他们抉择了让 TDengine 承当数据中台的重要角色，负责车辆实时数据的写入、存储以及实时查问。本文讲述了研发团队在后期应用 Apache HBase 时遇到的具体难点、为什么没有保持抉择 OpenTSDB，以及抉择 TDengine 的过程和功效。企业简介亿咖通科技是一家汽车智能化科技公司，在武汉、杭州、上海、苏州、马来西亚吉隆坡、英国伦敦等国内外多地设立有分支机构和研发核心，致力于继续打造行业当先的智能网联生态开放平台，全面为车企赋能，发明更智能、更平安的出行体验。 我的项目介绍为实现高水准的主动驾驶能力，亿咖通科技（ECARX）打造了一整套平安解决方案 SuperCloud，该计划旨在利用人工智能技术以及摄像头、雷达、声纳等多种传感器技术来保障驾乘者的平安。主动驾驶的外围数据就是设施的影子数据和状态数据，对设施进行精准的数据管制和采集，再联合高精地图的数据，是实现主动驾驶的两个重要环节。值得一提的是，亿咖通也是目前国内为数不多的领有高精地图资质的企业。 在 SuperCloud 我的项目当中，TDengine 承当着数据中台的重要角色，负责车辆实时数据的写入、存储以及实时查问。 选型通过在此之前，咱们应用的存储架构是 Kafka + Flink + HBase，但随着业务的倒退，逐步发现 HBase 的 Key-Value 存储模型并不适宜咱们的场景，究其原因，是因为落地到数据库的都是结构化的数据，Key-Value 存储模型会导致磁盘占用量特地大，并且性能上也无奈实现车辆最新状态的实时查问，这也是亟待解决的两个外围问题。 通过调研，咱们发现时序数据库才是正确的抉择方向，而且外围数据也合乎时序数据的种种特点，因而，咱们决定在 InfluxDB、TDengine 和 OpenTSDB 之间进行产品选型。 事实上，一开始咱们抉择的是 OpenTSDB，因为它基于 HBase，所以咱们很不便上手。但成也萧何败也萧何，也正因为要依赖 HBase，OpenTSDB 并没有解决 HBase 遗留的性能、压缩率等问题。而 InfluxDB 因为单机性能并不够卓越，而且集群性能没有开源，所以也没有被驳回。最终通过各种维度的比照后，咱们决然抉择了国产、开源、反对 SQL 的时序数据库 TDengine。 TDengine 十分合乎咱们当初的业务场景，尤其是超级表的概念，甚至能够说是为咱们量身定做的。咱们为每辆车都调配了一个子表，用以接管 IHU 设施产生的数据。（注：IHU 是亿咖通投入研发的第一代整车计算平台产品，于 2017 年第二季度投放市场应用，是一款采纳车载专用处理器、基于车身总线零碎和第三方应用服务打造而成的多媒体娱乐零碎，能实现包含地图导航、多媒体娱乐、车辆信息等一系列信息娱乐性能及车联网服务。） 优化后的新架构为：Kafka + Flink + TDengine。Flink 上游的数据可分为 2 类，一类是用 json 存储的结构化数据，还有一类是如图片、视频一类的非结构化数据。上游如果是结构化的 json 数据，则通过如下链路写入 TDengine：Kafka—>Flink—>TDengine，如果是非结构化的数据，则会间接存储到 S3 上，而后把这些视频图片的文件门路通过如下链路写入 TDengine：S3—->Kafka —-> Flink—>TDengine。 ...

3 月 30 日，CSDN 2021 年度 IT 技术影响力之星颁奖典礼胜利举办，并揭晓了集体、公司和翻新技术及产品等三大类共 12 个奖项的评比后果。在颁奖典礼上，涛思数据摘得两项荣誉。依靠不断创新的技术力量，开源、高性能、分布式且反对 SQL 的时序数据库 TDengine 取得“年度开源我的项目”奖项，同时，涛思数据创始人& CEO 陶建辉被授予“年度 IT 领军人物”的荣誉称号。 据理解，CSDN IT 技术影响力之星评比自 2021 年 12 月 6 日启动，经集体/企业提名、业界专家举荐评审，历经 4 个月工夫，以实在数据为根底，最终评比出了集体、公司和翻新技术及产品三类维度的奖项。从产品和技术实力登程，TDengine 榜上有名。 近年来，凭借产品、技术、服务等方面的劣势，TDengine 屡次入围各大榜单，包含“科创中国”开源翻新榜、中国开源云联盟的优良开源我的项目榜单、墨天轮的年度时序数据库排行榜、SegmentFault 思否的中国技术先锋年度评比 | 2021 中国新锐技术先锋企业榜单及开源中国发动的“优良中国开源原生创企”榜单等，斩获了诸多行业荣誉。 从时序数据特点登程，打造两个外围翻新点在 TDengine 设计之初，陶建辉就剖析出了时序数据所具备的数据量大、结构化大、以写操作为主读操作为辅等十大特点，出这些特点登程创立出时序数据库 TDengine。 作为一款领有自主知识产权、100% 自主可控的时序数据库，TDengine 具备高性能、分布式、反对 SQL 三大特点，将数据库、缓存、音讯队列、流式计算等性能齐全交融在一起，并针对物联网大数据特点进行了各种优化，重点翻新了“一个设施一张表”、“超级表”等设计。 其中，“一个设施一张表”以每个设施独自建表存储的形式，保障单个采集点的数据在存储介质上以块为单位进行间断存储，缩小随机读且实现了成数量级晋升查问速度。然而这种设计却带来了一个问题，即因表数量过多难以聚合难以查问，利用“超级表”设计能够通过打标签的形式让所有的表疾速聚合，将动态属性和动静属性拆散开来存储，节俭存储空间的同时更加便于进行聚合查问等操作。 相比通用的大数据平台数据， TDengine 的插入、查问等性能要高 10 倍以上，同时极大升高了存储空间，可宽泛使用于物联网、车联网、工业大数据等畛域。目前涛思数据就 TDengine 的技术创新曾经申请多项技术发明专利，且全副提交 PCT 专利申请。 围绕行业痛点做产品翻新，开源实力和用户规模继续上涨自 2019 年 TDengine 于 GitHub（https://github.com/taosdata/T...）正式开源后，短短几年间，其在寰球范畴内已播种了 18000+ Star，屡次在 GitHub 寰球趋势排行榜上排名第一，在开源社区的影响力可见一斑。 同时 TDengine 的用户规模也取得了显著增长，倒退至今，其已取得了超过百万用户的青眼，运行实例超过 109K，次要用户包含顺丰科技、现实汽车、京东云、同花顺、得物、转转、零跑汽车、逾越速运等，改善了包含金融、物流、汽车、电商、智慧能源、智慧农业在内的多个行业数据痛点问题。 ...

小 T 导读：在对多款时序数据库进行了选型测试后，同程旅行自研的“夜鹰监控”搭载 TDengine 代替了现有存储设备，缩小运维老本。本文分享了他们对建表模型的计划抉择思路，接入 TDengine 后所遇到问题的解决教训以及落地成果展现。同程旅行有一套自研的根底监控零碎“夜鹰监控”。目前夜鹰监控应用状况为百万级别 endpoint、亿级 metric、每秒 200 万并发写入以及 2 万并发查问。其存储组件基于 RRD 存储，RRD 存储尽管领有很好的性能，却也存在着一些问题——基于内存缓存定期写入 RRD，在机器重启后会失落局部数据。 呈现这一问题的起因是 RRD 写入为单点写入，当机器故障后无奈实现主动切换，这一存储个性也导致无奈展现更长时间的原始数据。 针对此问题，夜鹰监控做了很多高可用设计，但还是很难满足业务的需要，之后又进行了如下革新： 引入了 ES 存储，为夜鹰监控提供 7 天内原始数据的查问，目前部署的 2 套存储。RRD 提供给 API 调用，调用量在几万级 TPS。ES 提供给夜鹰面板应用，保留 7 天原始数据，调用量在几百 QPS。但随着根底监控零碎接入指标的增长，目前 2 套存储系统在资源耗费方面始终在增长，同时业务对监控也提出了更多的聚合计算性能要求。基于此，咱们须要寻找一个新的时序数据库来代替现有的存储系统，以缩小运维老本。 在进行时序数据库选型时，理论需要次要有以下三点： 性能强，能够反对千万级别并发写入、10 万级的并发读取高可用，能够横向扩大，不存在单点故障性能强，提供四则运算、最大、最小、均匀、最新等聚合计算性能通过比照 InfluxDB、TDengine、Prometheus、Druid、ClickHouse 等多款市面风行的时序数据库产品后，最终 TDengine 从中怀才不遇，能满足咱们所有的选型要求。 一、基于 TDengine 的建表模型夜鹰监控零碎不仅存在零碎指标数据，同时也会存在业务指标数据。前者诸如 CPU、内存、磁盘、网络一类，这类信息是能够预测的指标，其指标名是固定的，总数约为 2000 万个。后者则会通过夜鹰监控的 API 上传业务本身定义的指标，指标名是无奈预测的，其特点是并发量不大却存在长尾效应，随着工夫累积，一年能够达到一亿级。 而 TDengine 在创立表之前须要先规划表的构造，从下面的数据存储背景来看，如果要将海量的指标数量间接一次性扁平化全副创立，则会造成性能的降落。通过和 TDengine 技术支持人员沟通，他们给出了两个建表计划： 其一，将零碎类根底指标聚合到一个超级表，一张表寄存一个节点，多个指标一次性写入。这个形式的益处是表的数量能够升高到千万级别，但因为夜鹰监控的数据是单条上传的，很难做到一个表外面全副指标集齐再写入。并且不同的指标上传频率不同，如果再依据频率建不同的超级表，运维治理老本会十分高。 其二，将不同的指标建成一个一个的子表，5 千万个左右的指标汇聚成一个集群，分多个集群接入。这种形式的益处是表构造简略，但运维治理多个集群会很麻烦。不过咱们也理解到涛思数据明年会公布 TDengine 3.0 版本，能反对超过上亿张表，那么这一计划就能够很好的进行数据迁徙了。 最终，咱们抉择了第二个计划。同时为了缩小搭建集群的数量，筹备写个程序定期清理掉过期的子表。目前夜鹰监控的超级表构造如下。 夜鹰监控接入 TDengine 后，架构图如下。 二、接入 TDengine 之后的成果展现在进行数据迁徙时，咱们先是将夜鹰监控数据转移到 Kafka 中，之后通过生产转换程序将 Kafka 的数据格式转为了 TDengine SQL 格局。 这个过程还遇到了如下三个小问题，解决思路放在这里给大家参考： ...

小 T 导读：禹为科技在古代灌区信息化平台的建设过程中，经验了数据库&定时工作的架构、以流式计算为外围的架构和以 TDengine 为外围的架构三个阶段，最终选用 TDengine 帮忙其对水位、流量、水量等实时指标数据分析。本文分享了他们技术选型的过程，建库建表的思路以及应用 TDengine 后的收益。公司简介成都禹为科技有限责任公司是一家基于多年水利行业教训胜利孵化而出的高科技企业，专一于物联网、大数据和数字孪生技术在水利行业中的利用，致力于通过本身行业教训和研发能力为水利行业管理者与建设者提供全方位的数字化解决方案和价值服务。灌区信息化平台是以灌区内建设物理网零碎、无人机零碎联合卫星遥感等感知零碎为根底，对灌区内的水雨情、土壤墒情、工程信息、气象信息及作物散布等信息进行监督，通过大数据分析，联合 GIS、数字孪生等技术为灌区提供量测水服务、供需水预报、水资源综合调度、水旱灾害进攻、供用水治理、重点区域视频监督、近程设施管制等性能。 相较于以往的水利信息化零碎，古代灌区信息化平台出现以下特点： 设施厂家多，数据没有对立标准，数据品质无奈保障数据多且存储周期长，一个中型灌区一年数据量约为 300~500 亿条，数据要求至多保留 10 年及以上，要害数据甚至要求保留 20 年及以上数据类型较为集中，次要集中在水位、流量、闸门开度、环境温湿度、土壤温湿度、雨量等须要实时展现的指标较多，个别有各要害节点上的实时水位、小时均匀水位、5 分钟水量、日水量等个性化的数据 OLAP 需要较多，且对数据准确性要求较高产品架构图为理解耦零碎中的数据接入和数据分析，咱们将数据的接入和计算剖析拆分为独立的通用物联网平台及大数据平台，在整个零碎的技术选型计划中，咱们经验了数据库&定时工作的架构、以流式计算为外围的架构和以 TDengine 为外围的架构三个阶段。 一、技术计划1. 数据库&定时工作的架构在零碎设计之初，咱们思考间接应用 MySQL+MongoDB+定时工作的形式来撑持咱们的零碎：MySQL 存储所有的业务数据及维度信息；MongoDB 存储设备实时数据以及水量等业务数据；为了解决分钟水量、日水量等数据的计算，咱们应用定时工作在计算时从 MongoDB 中获取实时数据，从MySQL中获取维度数据，将解决好的数据再写回 MongoDB 中，通过提前预计算的形式为前端提供数据。 但这种形式有以下几个问题： 无奈对设施数据进行灵便的治理剖析，设施数据乱序后须要通过人工干预或程序预处理的形式纠偏；须要提前思考多种维度的数据处理，以便满足实时数据展现和 OLAP 查问的需要；5 分钟水量、日水量等数据应用定时工作计算会导致数据库负载过重；在数据较多的状况下，MongoDB 必须应用更多的硬件资源搭建数据库集群，能力满足存储和数据查问的要求。2. 以流式计算为外围的架构鉴于在数据库&定时工作的架构计划中呈现的数据处理较慢的问题，联合笔者在过往工作中所积攒的教训，咱们设计了流式计算数据架构计划。 数据通过物联网零碎进入零碎，通过解决后会依据设施类型被标准化为对立格局的数据，而后数据被写入 OpenTSDB 和 Kafka 中，供 Flink 生产。Flink 依照 Job 定义生产 Kafka 数据，并依照 MySQL 中的维表信息进行加工解决，而后写入 MongoDB 中；同时还将数据处理为分钟水量、日数量等业务实时所需的数据。 相较于上一版计划，数据乱序问题以及数据实时计算的问题失去了良好的解决，同时也能很好地满足 OLAP 等业务对数据的查问要求。但该计划减少了 Flink、Kafka 以及 OpenTSDB 三个较为大型的工具，无形中减少了我的项目的建设老本及运维老本。是否有一种平台能够集数据存储、音讯队列、大数据计算及剖析于一身，且不会过多的减少硬件老本？TDengine 最终走进了咱们的眼帘。 3. 以 TDengine 为外围的架构因为以上两个计划都各自有本人的缺点，咱们试着调研寻求一个更适宜咱们的平台计划，偶然间笔者从一位从事工业物联网多年的敌人那里理解到 TDengine 这个产品，于是咱们迅速从查问效率、写入效率、稳定性、容错率以及性能完整性等方面对多个数据库进行了调研，最终咱们认为 TDengine 是当下最适宜咱们的。起因如下： ...

小 T 导读：至数物联网平台场景多、数据模型简单，随同着业务需要的一直迭代及数据量的一直上涨，原有的 OpenTSDB+MySQL 的组合逐步力不从心，局限性日益凸显。在对 TDengine 进行充沛理解与调研后，基于 TDengine 对至数摇光进行了彻底性的革新。本文分享了至数联合本身平台特点进行零碎架构降级革新的教训，以供参考。 公司简介&我的项目背景至数（Medatc）是一家致力于打造行业最佳设施资产数据化经营、治理、服务的平台，为客户提供全方位的设施资产治理撑持，其领有丰盛的行业教训，以及在大数据、人工智能、物联网、互联网+畛域的翻新实际能力。公司成立至今曾经取得红杉资本等出名投资机构的策略投资。 至数摇光（即：至数物联网平台）通过动静能量被动标识，动静环境被动标识，智能网关，利用工业互联网时序数据高效采集，边缘计算以及智能算法主动散发等一系列技术，基于医疗设施行业主数据标准，助力医疗机构短周期、低成本、高质量、广覆盖地实现有源设施智慧治理。 一、至数摇光具备场景多、数据模型简单的特点至数摇光是以提效降耗为指标，帮忙医疗机构实现有源设施的高效治理，为设施应用效率智能剖析，设施迷信配置，设施动静调配，设施平安保障提供全方位撑持。目前共推出了 15 项智能场景利用，30 项事件及异样告警揭示。 至数摇光的上述场景革新前数据库采纳 OpenTSDB+MySQL 联合的形式实现，因为 OpenTSDB 无奈满足简单查问场景，因而 80% 的场景指标只能基于 MySQL 数据库来实现，这样带来的问题就是 MySQL 数据库的数据增长迅速，须要定时做冷热数据拆散及数据库表保护动作。 二、TDengine 助力至数物联网平台实现技术改造作为一个大而全的数据库，OpenTSDB 稍显轻便，随同着业务需要的一直迭代及数据量的一直上涨，其局限性日益凸显，零碎的架构降级和革新工作日渐迫切。 2021 年咱们在对 TDengine 有了充沛的理解后，决定将至数摇光从时序数据 OpenTSDB 迁徙到 TDengine，并基于 TDengine 的个性对摇光进行彻底性的革新。目前革新工作曾经全副实现，革新后有大概 80% 左右的指标模型放到了 TDengine 中，20% 左右的主数据或维表数据寄存在 MySQL 数据库中。 相较于革新前的 80% 指标模型寄存在 MySQL 中，20% 指标数据寄存在 OpenTSDB 数据库中，后果刚好进行了颠倒，服务器资源应用状况也有所降落。利用整体的页面影响速度显著进步，数据模型及数据指标上也能够更加地灵便多变。 以下为至数摇光网络拓扑路图： 以下为革新前后的数据库比照： 以下以 11 万条数据表来做查问，后果如下： 聚合查问，1,155,876 条数据在耗时不到 0.17 秒的工夫实现 GROUP BY 聚合查问： 写入状况，这里截了一张 Flink 写入TDengine 数据库图片，3 个小时左右的工夫里写入了 250 万条采集数据，这样的写入量远远没有达到 TDengine 的写入瓶颈，对业务的增长留有富余的空间。 ...

小 T 导读：在北京智能建筑边缘侧采集数据存储的计划中，面临着在无限的计算资源下，如何实现最高效的数据存储、剖析和计算的问题。通过调研与测试，最终抉择了由 TDengine 解决时序数据，SQLite 解决关系数据，以此更好地实现边缘侧的数据自治。本文讲述了他们的选型和建模思路以及落地后的成果展现，作为教训参考分享给有须要的读者。 公司简介北京智能建筑科技有限公司作为北京市在智能建筑和智慧城市畛域的翻新平台，是冬奥科技平台公司、智慧冬奥国家重点项目设计单位和外围施行单位，同时，北智建作为国家高新技术企业，致力于打造中国最大的智能建筑 AIoT 平台。 在云计算模式中，采集的数据必须要传到云上进行集中式的存储、归档及剖析，依靠云端计算资源进行简单的计算，再将所失去的指导性论断通过网络下发给终端。而对于边缘计算，即把一部分的存储和计算的能力下沉到边缘侧（即设施侧），因为终端设备能够较独立地进行数据存储、计算、决策和利用，因而边缘侧会更加智能，对云端依赖更小，数据处理的时效性也更高，且不再受网络影响。 一般来说，边缘侧往往是一些可能大量铺设的小型智能终端，出于老本思考，其配置的内存、CPU 等硬件资源和计算能力都很无限。边缘计算的难点就在于是否在无限的计算资源下，实现最高效的数据存储、剖析和计算。总结下来，边缘计算对数据库能力的要求次要反映在以下几个方面，这也是咱们在抉择数据库时的重点考量维度： 超高读写性能低硬件开销通用接口，适配边缘侧多样计算需要实时数据的缓存能力、流式计算能力历史数据长久化存储、高效压缩能力历史数据回溯能力、按工夫窗口的统计聚合能力一、技术选型整体而言，时序数据库具备上述各项能力，也是边缘侧采集数据存储的最佳抉择。但市面上时序数据库产品泛滥，如何筛选也是一个难点。 如 OpenTSDB（底层基于 HBase 革新）、InfluxDB 等一类的时序数据库，其运行起来的硬件资源开销过高，对于边缘侧来说还是太重了。起初咱们察看到了一个极轻量化的开源时序数据库 —— TDengine，过后它的整个安装包只有 2 MB 多，应用 C 语言齐全自主研发，外围性能就是一个高性能分布式时序数据库。具体劣势汇总如下： TDengine 社区曾经公布了反对 ARM64 处理器的版本，能够顺畅地运行在树莓派等支流的边缘侧硬件上，同时提供对实时数据的缓存、历史数据的回溯、按时间段进行聚合计算等多种能力。TDengine ARM 版本反对的接口也有很多种，与失常集群版简直没有区别。同时，它还提供了一个 taos shell 客户端，让调试人员能够不便地去查看 TDengine 的运行状态。反对包含 C/C++、JAVA、Python、RESTful、Go 在内的多种语言，学习成本低装置超级简略，无任何依赖装置无任何依赖应用便捷SQLite VS TDengine另外提起边缘侧、嵌入式设施中的数据存储，那就不得不提 SQLite。SQLite 是一个不须要后盾的超轻量级数据库，即插即用的特点也让它成为世界上装机量最高的数据库。SQLite甚至在官网上将本身定位与 fopen() 对标，而不再是作为一款数据库。SQLite 提供的一系列 API 都是对标关系型数据库的，它甚至还反对了事务，因而业界经常把它用作嵌入式关系型数据库。其与 TDengine 的各项比照如下：从下面的比拟中咱们能够看到，TDengine 和 SQLite 要解决的问题侧重点不同，各有千秋。从咱们本身业务的切实需要登程，两者并非必须要进行取舍，而是能够依据业务需要灵便搭配应用——由 TDengine 解决时序数据，由 SQLite 解决关系数据，以此更好地实现边缘侧的数据自治。基于此，在存储方面咱们决定采纳 TDengine + SQLite 的组合模式。 二、架构与具体实现技术架构 物理视图逻辑视图在边缘端日志性能（为边缘端的设施提供日志上报）的设计上，咱们采纳 TDengine 对日志进行存储，该性能的设计是为出现异常情况的设施提供溯源根据，在与告警性能配合下能够让开发人员疾速定位到问题，及时进行解决。此外在边缘端进行日志解决，就能利用边缘端的算力加重中台的压力，还能够撑持 2 万设施异常情况下的日志并发写入。 对于设施的采集值，咱们同样采纳 TDengine 进行存储和检索。以往采纳关系型数据库进行存储时，在设施比拟多、数据量宏大的状况下，查问会十分的慢，体验感极差。反观 TDengine 高压缩算法能晋升 10 到 20 倍的压缩性能，升高存储压力的同时也解决了数据存储老本高的问题，还达到了升高硬件老本的成果。 ...

在新年前夕的全员总结大会上，涛思数据的一位 70 后研发老将播种了一份名为“最具开源精力奖”的奖项，这不仅是对他在 2021 年基于 TDengine 所做出的开源奉献的认可，更是映射出其长久以来保持走在开源路上的不变初心。作为老一辈开源人，桑树多以资深的研发技术、乐于分享的精力、无处不流传的毅力，真正践行着开源人的使命。对于如何参加开源社区建设、如何突破 35+ 大龄程序员职场焦虑等当下的热点问题，他也积淀下了本人的观点和思考。 从 1998 到 2022，20 余年开源路上的保持与酷爱作为一名 70 后程序员，桑树多与开源的故事最早能够追溯至 1998 年。彼时才从哈尔滨工业大学毕业不久的他进入了一家科技公司，正式开启了本人的代码职场生涯，也关上了微妙开源世界的大门。 从开始应用 Linux 桌面环境，到本人入手为新的硬件设施移植驱动软件，再到起初陆续参加了 Linux Kernel、MeeGo、Ubuntu 等开源软件的开发，桑树多的开源之路走得越来越深，与开源技术也结下了长达 20 余年的不解之缘。图为 2011 年桑树多（左）在 Portland Linux Kernel Developer Summit 上与 Linus Torvalds（右）的合影 “从 Red Hat Linux 5.0 开始，我接触到开源，而后一步步从使用者成为爱好者，最初成为了一名贡献者。回顾过往 20 年参加开源的经验，真的不得不感叹一句受害良多。” 对于做开发的同学来说，“开源”这个概念并不生疏。近年来，随同着云计算、大数据、人工智能等数字技术的疾速倒退，开源模式的热度也在一直攀升，日渐成为数字技术创新和产业数字化转型的重要模式，开源软件也成为了各大互联网企业背地的撑持力量。 从科技倒退的轨道来看，参加开源的重要性显而易见，但依然有很多开发者以工作忙碌等为理由来广开言路。事实上，这并不是一件如许艰难的事件，桑树多用他的亲身经历进行了阐明。 “你能够先成为使用者并积极参与社区探讨，通过学习其他人解决问题的办法和代码相熟开源软件的架构和设计思维，再进一步倒退本人提交 Patch 和 PR 解决问题，成为 Contributor——在其余用户遇到本人解决过的问题时被动帮忙别人，在有能力时踊跃奉献代码。” “而对于开源小白来说，你能够从本身的技术趣味登程来抉择想要参加的开源方向，如果对数据库感兴趣，那 TDengine 就是一个非常适合上手学习的开源我的项目，如果是对音讯队列感兴趣能够抉择 Kafka。” 入门容易保持却难，咱们无妨从桑树多的经验中探寻一下保持的理由。参加开源到底给他带来了什么？ 从开发者到 Contributor，寻找参加开源的取得感开源到底是什么？参加开源的意义又在哪里？ “简略来说，开源的意义就是突破传统软件研发自上而下的研发模式，更多利用自组织开发模式疾速迭代打造精品软件，如果你还想更加深刻地从文化和理念的角度去了解开源，那能够学习一下《大教堂与集市》这本书。” 作为一个资深的开源软件开发者，桑树多的开源经验也向咱们展现了参加开源到底可能带来哪些扭转和帮忙。 “能够负责任地讲，参加开源肯定会减少本人的职场竞争力，因为这能够让你更容易接触到先进的技术，像 Linux Kernel 之类的很多开源软件，代码曾经通过千锤百炼，通过浏览这些代码就能够学习其背地的设计思维。而且你还能够在开源社区内进行探讨学习，让本人可能更快地播种成长。” 此外，桑树多还认为，如果能成为一名 Contributor，通过本人编写的代码给关注的开源软件带来晋升，那将是一件十分有自豪感的事件。首先本身技术实力在专家 review 的环节能够失去别人的认可；其次在 review 过程中进行观点交换也能够帮忙本人学习别人的观点，发现本身的疏漏和有余；在有了肯定教训之后，你也能够去帮忙他人 review 代码，以此实现教学相长。 ...

小 T 导读：在欧圣达的物联网智能设施平台我的项目中，需反对数百万以上物联网表具和智能终端的接入治理，反对分布式部署且具备良好扩展性。在规定引擎场景下，TDengine 提供了很好的查问和存储性能，成为本我的项目实现实时告警和监控服务的重要一环。本篇文章分享了欧圣达在数据库调研和搭建阶段的思考和教训，供参考。 公司简介哈工欧圣达是深圳市欧圣达科技有限公司和哈工大机器人团体的合资公司，总公司深圳市欧圣达科技有限公司成立于 2010 年 5 月，总部位于深圳，下设合肥研发核心、华东分公司（合肥）和东北分公司（成都）。公司始终致力于燃气、供热等公共事业畛域的智慧化解决方案研发和利用推广，领有超过 10 余项自主知识产权的、基于 5G/NB-IoT 和大数据的“一体化平台+智能平安终端”智慧燃气解决方案，作为核心成员参加制订并公布 2019、2020 年 5G 智慧燃气行业标准。 某燃气公司拟建设一套物联网智能设施平台来满足各类物联网设施接入以及数据的采集、存储、剖析、展现等各类需要，我的项目需包含数据采集模块、数据分析模块、监控告警模块、预付费实时结算模块、API 接口模块、大屏\地图显示模块、后盾治理模块、手机 App 功能模块。 该平台的搭建目标是为了取代各燃气表厂原有的数据接管服务器，实现对各表厂物联网表具（含 FSK、GFSK、LoRa、GPRS、4G、5G、NB-IoT 等技术标准）读数、压力、温度、监控报警、气价调整、零碎参数设置等远传管制和治理。零碎需反对数百万以上物联网表具和智能终端的接入治理， 1 秒内刹时并发连接数不低于 5 万，零碎反对分布式部署，且具备良好的扩展性，可能依据业务须要，灵便的扩大零碎性能和接入能力。 一、选型调研以上是典型的时序物联网场景，因而咱们调研了国外的支流时序数据库 InfluxDB，但思考到国家基础设施建设平安，咱们最终把眼光投向了国产开源数据库 TDengine。咱们联合业务数据量对 TDengine 进行了数百万设施的压测，满足本我的项目的数据存储和性能要求。具体测试后果如下： 从测试后果来看，TDengine 的整体硬件耗费资源比拟低，且能满足数百万设施的并发写入。此外相比 MongoDB，其压缩率能够晋升至 1/10 – 1/20，也为咱们节约了大量存储老本。最有吸引力的一点是 TDengine 具备欠缺的开源社区生态，不仅反对集群版部署，更有欠缺的中国服务团队及多元化的服务模式，能够做到实时响应。 二、业务架构部署在具体搭建上，咱们将不同厂家、不同型号设施定义为产品，不同产品的通信机制、上报数据项、指令内容、上报频次都是不同的，咱们应用 TDengine 对不同产品创立对应的超级表，应用设施 ID 创立子表。 技术架构图如下图所示：具体门路上，传感器数据通过 MQ 缓存、结构化解析后进入到 TDengine，供后续业务进行查问应用。规定引擎依据已有的规定参数，进行传感器数据订阅，实时判断传感器是否触发了报警规定，从而实现我的项目的实时监控和报警需要。同时，规定引擎还会依据传感器数据，触发对应的指令操作（如复原服务、暂停服务指令），通过 MQ 异步传播给传感器。TDengine 在规定引擎场景下，提供了很好的查问性能，是实现实时告警和监控服务的重要一环。 建模思路在本我的项目中，每种设施的协定及上报数据参数都是不同的，咱们将公共属性（如所属公司、所属分公司、所属厂家、是否预付费等）作为超级表 tags，将共有参数（如阀门状态、最新读数、抄表工夫、温度、压力、电量、信号强度等）作为一般列，通信工夫戳+工夫漂移作为 TDengine 主键，其余非共有参数（如一些设施会上报刹时工况流量、一些会上报抄表模块电池电量等）作为子表字段。以本我的项目的其中一张表作为示例，构造如下： show create stable device_meter_record\G;create table device_meter_record (receive_time TIMESTAMP,meter_readnum DOUBLE,meter_balance INT,meter_volume DOUBLE,meter_time TIMESTAMP,meter_temperature DOUBLE,meter_pressure DOUBLE,meter_instantflow DOUBLE,cust_num BINARY(50),cust_name BINARY(255),company_id BINARY(32),subcompany_id BINARY(32),readingteam_id BINARY(32),subreadingteam_id BINARY(32),area_id BINARY(32),community_id BINARY(32),building_id BINARY(32),user_type BINARY(20),is_holiday BOOL,supplier_id BINARY(32),supplier_device_code BINARY(20),platform_balance INT,platform_last_reading DOUBLE,platform_last_balance INT,platform_price BINARY(15)) TAGS (device_id BINARY(32),device_no BINARY(32),sno BINARY(32),model_id BINARY(32),type_id BINARY(100))成果展现最终咱们采纳了 3 节点 8 核 16 G 满足整体业务需要，零碎能够依据时间段范畴、针对单个设施进行数据上报的查问性能，且反对依照小时用量、日用量、月用量、年用量四个维度进行统计分析。目前单个超级表的压缩率为 2.5%。 ...

小 T 导读：在元智信息的智慧矿山我的项目中，须要一款数据库能撑持起生产交互管控零碎的采运排环节所有过程设施的采集、存储、计算和监控性能。在 MySQL、InfluxDB、TDengine 的数据库选型调研中，TDengine 怀才不遇。本文讲述了他们的选型思路、建模思路以及计划翻新点，作为教训参考分享给有须要的读者。 公司简介元智信息是国内当先的露天矿业项目管理征询和技术计划提供商。元智公司为全国范畴内的工矿企业提供一站式的技术支持服务， 包含可行性研究剖析、矿山布局与调度、生产评估、生产优化、业务零碎整合、系统集成和软件开发等专项服务。 一、行业背景智慧矿山是以矿山数字化、信息化为前提和根底，对矿山生产、职业衰弱与平安、技术支持与后勤保障等各方面进行被动感知、主动剖析和疾速解决。建设智慧矿山，首先以建设和实现矿山在生产、平安、经营与治理等环节的信息化为前提，最终实现”矿山一张图”的系统管理指标，开启矿山“通明+智能+管控”的平安生产新模式。 二、应用场景介绍在整个矿山生产交互管控零碎的采运排环节，须要对所有过程设施进行采集、存储、计算和监控。这些数据涵盖范围广，包含挖机、卡车的采集数据、调度治理数据、设施 GPS 信息、以及每一个固定地位工序的采集数据等。 数据类型采：露天矿山采掘设施，超大型电铲与液压铲。矿山中利用采掘设施进行矿产资源以及覆盖物的开掘工作，在理论利用中，须要采集和监控各个采掘设施的信息，如设施运行参数（像电压和电流等）和地位信息。运：次要是运输环节。在采煤的过程中，须要对大量的剥离物（如表土和岩石）进行排弃，将原煤运输到煤仓、破碎站以及选煤厂。在此过程中，须要通过平安正当的调度来实现矿产附属物及矿品的运输。因而，咱们会实时采集卡车运输设备地位信息、胎压、油耗等信息，以保障平安调度。排：排土工作系指从露天采场将剥离笼罩在矿床上部及其四周的大量表土和岩石，运送到专门设置的场地如（排土场）。次要通过卡车运输来实现。即煤炭开采剥离过程中产生的渣土剥离后通过运输系统排出生产作业区，排土过程中正当布局以达到露天煤矿生态环保过程中的环保作业要求。数据量级个别大规模的矿山车辆数量，往往超过 800 台。如果是整个团体级别的利用，卡车数量可达 3000 ～ 7000 台。以目前的平安生产要求，卡车的采集频率是 5 ～ 10 秒，在有更高要求的场景中，须要采纳更高的频率，采集的数据内容包含卡车 GPS 定位数据、油耗数据、胎压数据以及卡车的速度信息。以 800 台设施估算，采集频率 5 秒，一天 24 小时会产出大略 1000 多万条数据。这个数据量绝对于传统的数据存储是个比拟大的量级。数据利用在理论的利用场景中，对车辆的数据利用，其中一个次要维度就是车辆轨迹，特地是车辆的实时地位必须满足矿山生产的车辆调度实时需要。 三、选型比照MySQLMySQL 是咱们团队在各种利用开发畛域应用最多的数据库，从复用技术教训的角度上思考，最后思考过 MySQL 的可行性。然而在通过剖析和验证后，咱们就排除了应用关系型数据库的计划。次要起因如下： 存储压力：在最后应用 MySQL 的论证剖析中，因为在 MySQL 中的 InnoDB 存储引擎最小存储单元页的大小是 16 kb 左右， 而 MySQL 以页为根底的查问数据加载时，数据的加载量会带来极大的零碎累赘。并且，MySQL 作为关系型数据库，采纳的是 B+ 树存储构造，初步估算，深度为 3 的 B+ 树预计能撑持 2000 万条左右的数据，这个数据量级是远远满足不了咱们的业务场景的。性能存在瓶颈：在理论验证中，随同着数据量的减少，MySQL 性能急剧下降。InfluxDB其次，咱们进行了 InfluxDB 的调研。验证的初级阶段，从查问效率的 QPS 维度看，InfluxDB 的查问问题不大，效率能够满足。然而，在测试智慧矿山的物联网模型查问时，很快遇到了 InfluxDB 对于此类查问实时效率低下的问题，而且设计复杂度也很高。 在 1000 台设施的状况下，须要查所有设施的平均速度，查问实时性要求高。 但 InfluxDB 没有明确的基于设施的建表形式，如果用一张表存所有设施数据，数据量就会很大，查问性能也会降落。比拟显著的是，在百万数据量级以内，这种建表形式查问工夫在 1 秒左右，而当数据到了千万量级的时候，查问效率降落非常显著。 在咱们实在的智慧矿山中、所有设施产生的数据量级条件下，这个查问效率的降落是显著不合乎咱们要求的。 ...

主讲人信息杨攀 开发者生态 VPTGO 鲲鹏会北京分会会长，大规模高并发领域专家，领有多年大规模即时通讯和社交产品研发、设计、经营教训，多年开发者社区经营教训。原 MSN Mobile China、飞信外围团队成员，前融云创始人 CTO。现负责涛思数据开发者关系和开发者生态业务，致力于连贯开发者，拓展 TDengine 生态，遍及高性能、分布式、反对 SQL 的时序数据库技术。 三句话简介1、涛思数据的外围产品 TDengine 在 GitHub 上已累计取得 17.9k Star，目前国内时序数据库畛域 Top 1，国内 CNCF 数据库畛域 Top 5。2、广阔的行业市场，已广泛应用于物联网、车联网、工业互联网、IT运维等畛域，涛思目前处于 B 轮，迄今为止累计取得融资 7000 万美金，行业笼罩亚洲，北美，欧洲等多个国家和地区，波及电力，能源，金融，交通运输，新能源等畛域。3、公司会集了来自各个领域的优秀人才，人均 985 硕士学历，人均融资额 100 万美金，创国内记录。 公司介绍北京涛思数据科技有限公司（TAOS Data）瞄准日益增长的物联网数据市场，专一时序空间大数据的存储、查问、剖析和计算，不依赖任何开源或第三方软件，开发了领有自主知识产权、100% 自主可控的高性能、分布式、反对 SQL 的时序数据库 TDengine。采纳 AGPL 许可证，涛思数据曾经将 TDengine 的内核（存储、计算引擎和集群）100% 开源，将来将尽最大致力打造开发者社区，保护凋谢开源的商业模式。 抱着给行业赋能、让开发者胜利的使命，通过技术创新，涛思数据旨在为物联网、工业互联网、汽车、能源等行业用户提供全栈、高性能、低成本的大数据平台，并提供最好的技术支持和服务，发明出商业价值和社会价值。在融资方面，公司曾经取得投资方经纬中国、红杉资本、GGV 纪源资本、明势资本、蛮子基金、永辉瑞金等多家机构的近 7000 万美元的投资，深受资本市场青眼。 在团队成员上，涛思数据创始人陶建辉是一名间断创业者，他在美国留学工作十多年后抉择回国守业，曾胜利开办了“和信”与“高兴妈咪”两家高科技企业。其研发团队全副毕业于中国科大、中国科学院、清华、上海交大、美国密歇根大学、马里兰大学等出名学府或机构，大都领有硕士或博士学历，在分布式计算、数据存储和数据库上有多年研发教训。 图 1. 团队掠影 公司官网：https://www.taosdata.com/?zh招聘网站：https://www.taosdata.com/careers公司在 SegmentFault 的技术博客：涛思数据 - SegmentFault 思否 咱们的产品是什么？作为一款国产开源、同时也是应用 C 语言齐全自主研发的时序数据库，TDengine 不依赖任何底层数据引擎。除外围的快 10 倍以上的时序数据库性能外，其还实现了将实时数据和历史数据操作合一通明，具备缓存、数据订阅、流式计算、音讯队列等性能，为物联网数据处理提供了全栈解决方案，无需再集成 Kafka、Redis、Spark、HBase、ZooKeeper 等软件，大幅升高零碎架构复杂度的同时极大进步了数据处理的性能，可宽泛使用于物联网、车联网、工业互联网、IT 运维等畛域。 图 2. TDengine 技术生态图 ...

作者：陈玉 涛思数据 WAL（Write Ahead Log），是 TDengine 的一个重要的功能模块，它能够实现数据的容错能力，保证数据的高可用。 听着简单，其实也很简略。对于关系型数据库的使用者来说，它大略就相当于 Oracle 中的 redolog ，MySQL 中的 binlog 和 redolog，外面记录的是所有对于数据库的更新批改操作。 Write Ahead Log 翻译一下是“预写日志”，含意就是：在数据写入存储之前，先依照工夫程序在日志中做一下记录，这样就能够确保利用可能通过这个日志将数据库复原到任意的某个状态，即便数据库因为断电等意外事故宕机，也能防止数据的失落。 目前，TDengine社区版尚不反对将数据回滚到指定工夫，如有须要，能够分割咱们的企业版团队来解决。 TDengine 中的 WAL 实现机制稍有非凡。它把 WAL 分为两局部，一种是 mnode 目录下的 WAL，一种是 vnode 目录下的 WAL。（为了不便本文的浏览，这里须要大家首先理解TDengine的基础架构：治理节点（mnode）和虚构数据节点（vnode）的概念：https://www.taosdata.com/docs...） 在 TDengine 的数据文件门路下（默认为/var/lib/taos），就能够看到上述目录构造。 mnode 的 WAL 内容是长久化在硬盘上的，作为最重要的治理节点，它的 WAL 记录着所有对于数据库的 DDL 操作（比方创立删除操作：create dnode，create account，create mnode，create user，create table， drop dnode ，drop table等，或者批改操作：alter database，alter table ，alter user等） 而 vnode 目录下的 WAL 则次要负责记录着写入数据的操作，与此同时也记录着对表的 DDL 操作，在触发落盘后会清零。（这就是咱们在之前的文章——比方《存储老本仅为OpenTSDB的1/10，TDengine的最大杀手锏居然是什么？》——中常常提及的局部，大家能够联合此文浏览，以加深了解。） 之后，写入 vnode 的时序数据会落盘到数据文件目录 /vnode/vnodeX/tsdb/data 上面。而对于表的 DDL 操作（也就是表的元数据）则会落盘到数据文件目录/vnode/vnodeX/tsdb/meta文件中，如下所示： ...

作者：许海军 小 T 导读：格创东智科技有限公司成立于 2018 年，孵化于中国 500 强企业 TCL，是我国出名的工业互联网平台服务商。公司依靠 TCL 团体 40 年工业场景和制作基因积淀，基于“面向工业现场”的研发方向和“连贯、协同、共享”的倒退理念，深度交融人工智能、大数据、云计算、物联网等前沿技术，为智能工厂和制造业园区打造的数字化能源管理计划，可广泛应用于多个垂直行业，运行监控、能效治理、智能剖析、运维治理、能源洽购、碳排放治理等数十个功能模块，实现欠缺的能源管理价值闭环，建设数字化能源 &碳计量体系，智慧化用能及碳管理系统，打造涵盖企业碳追踪、碳计量、碳治理、碳中和的一站式解决方案。 TCL 空调能源管理平台对工厂电、水、天然气、油等指标进行实时采集、动静监测，并以工夫维度、厂家、车间、生产线类型、生产线、设施等维度进行剖析、节能计量、计费、成本核算、进行行业对标、生成剖析报告等，实现企业能源精细化治理，促成节能降耗；实时监控用户的用能平安数据，及时向平安管理人员发送报警信息，领导其发展隐患治理，为帮忙企业施行用能平安及能源管理提供信息化服务。 G-Things 是咱们的利用智能平台产品家族的物联网平台，咱们先来看一下在该平台上的数据流转状况。 工业设施会将数据上报到平台数据接入网关，而后接入网关负责解析报文，并过滤掉非法数据报文，之后再将数据下发到 Apache Kafka 消息中间件，由平台实时处理、长久化服务进行生产，长久化服务会把最新数据写入 Redis，并将数据长久化到时序数据库。对于平台存储架构，设计上反对 OpenTSDB、ClickHouse、TDengine 等时序数据库切换，咱们要依据我的项目理论状况来选型。 一、存储计划选型咱们看一下能源行业数据的个性： 数据的时序性：设施源源不断地产生数据，这些数据会带着工夫戳上报到平台数据流量稳固：上报频率比较稳定，采集频率在 30 秒一次数据是数值类型：是一些应用累计量、电流、电流、压力之类的数据数据不存在变更：数据是记录某一时刻的采集表记数据，上报无需更新或删除；数据的聚合及剖析基于工夫维度、空间维度：工夫维度有年、月、周、日、时，最短 15 分钟统计一次，空间维度有厂家、车间、生产线类型、生产线、设施等数据量大：按一个工厂 4 万表记计算，每 30 秒钟一笔数据，一天采集的数据会超过 1 亿条基于能源行业的数据个性，咱们要在平台反对的 OpenTSDB、ClickHouse 和 TDengine 这 3 个时序数据库存储引擎中作出抉择。上面是一个比照： OpenTSDB：依赖 HBase、HDFS 和 ZooKeeper 等组件，硬件资源要求高、老本高，在查问时间跨度较大时，性能骤降，另外对聚合剖析查问反对不好。ClickHouse：在数据存储、跨时间段查问及数据聚合剖析查问等方面，都满足咱们的所有选型要求，然而运维老本太高，扩大过于简单，应用的资源较多。TDengine：在数据存储、数据分析查问等方面都满足咱们的需要，并且集群版也开源了，反对横向扩大，占用资源少，在客户无限的资源条件下，是存储引擎最优的抉择。通过以上比照，咱们抉择了将 TDengine 作为本人的存储引擎。 二、TDengine 数据库建模TDengine 有两个很独特的翻新，一个是“一个数据采集点一张表”，一个是“超级表”。所以在设计数据模型时，就要思考业务模型怎么映射到超级表和具体的表。 先来看超级表。依据 TDengine 数据库的个性，咱们将电表、水表、石油气表、氧气表，对每个类型的数据采集点创立一个超级表。以创立电表为例： 再来看一般表。每个数据采集点须要独立建表。与规范的关系型数据库一样，一张表有表名，Schema，但除此之外，还能够带有一到多个标签。 三、理论利用总结我的项目上线半年以来，始终安稳运行。 在 TCL 空调能源管理我的项目中，咱们应用的硬件资源显著缩小，同选用 ClickHouse 集群作为存储的 TCL 电子工业物联网平台比照，两个我的项目的数据规模差不多，TCL 空调能源管理我的项目数据库服务器缩小了一半。 ...

作者：段雪林 小T导读：SENSORO（北京升哲科技有限公司）是一家当先的物联网与人工智能独角兽企业。作为城市级数据服务提供商，公司在新一代信息技术畛域领有外围研发能力，在国内首次实现物联网与人工智能畛域端到端、一体化的技术与产品能力，蕴含自研物联网通信芯片、通信基站、智能感知终端和智能视觉终端及外围数据平台等。SENSORO 面向城市基础设施与外围因素提供全域数字化服务计划，通过将多项外围自研关键性技术深刻利用到智慧城市、农村振兴、区域治理、社会民生等畛域，打造物联网与人工智能利用的数字利用标杆，赋能我国城乡数字经济的高质量倒退。 建设城市级传感器网络所波及的传感器品种非常多样，由此产生的数据量也非常宏大， 如果只是应用MySQL、PostgreSQL等OLTP零碎进行数据的简略存储，不仅会产生很多问题，而且其程度扩大能力也无限，同时也因为没有专门针对物联网数据进行优化而不足足够的压缩成果，数据存储老本很高。 在零碎开发初期，联合之前的教训咱们先是抉择了Apache Druid作为存储传感数据的数据库，然而在应用过程中却遇到了各种各样的问题，这使得咱们将眼光转移到了TDengine这款时序数据库。事实上，在TDengine开源之初咱们就留神到了这个新兴的时序数据库，浏览过后公布的白皮书与性能测试报告时惊艳感由衷而生，随即联系到了涛思的同学们，进行了更深刻的交换与测试。 但因为平台波及的非凡数据模型，单干便始终搁置了下来。次要问题在于数据有A、B两个维度且是多对多关系还会随工夫变动，基于A创立子表（此时无奈将B设置成tag列）就无奈通过B进行聚合查问，还须要破费较大的工夫与精力革新成TDengine特有的超级表构造。之后TDengine也通过了多个版本迭代，反对了join查问，而咱们的数据模型也产生了变动，迁徙到TDengine时不再须要做出很多的零碎模块改变。 一、基于Apache Druid现存零碎的问题基于Apache Druid，零碎最大的问题就是保护老本了。Druid划分了Coordinator、Overlord、Broker、Router、Historical、MiddleManager六个过程，要实现残缺的集群性能，其还须要Deep Storage （反对S3和HDFS），Metadata Storage（典型如MySQL、PGSQL），以及为实现服务发现与选主性能而须要的ZooKeeper，由此也能够看出Druid是一套极为简单的零碎。 同时，Druid对外部的各种依赖也导致运维同学在解决一些问题时，会间接或间接地影响到它的运行，比方咱们将S3的AccessKey进行规范化解决——由以前的全局通用改成某个bucket惟一，或者将PGPool降级，都会影响到Druid。而且Druid针对每一个过程和内部依赖都有厚厚的几页配置项，且从JVM本身来看，不同过程、配置、MaxDirectMemorySize都会重大影响写入查问性能。如果你要从官网文档的配置页面从顶划到底，可能会把手指划抽筋。 基于Apache Druid 的零碎架构(Druid每个过程都独自的部署并有不同的配置） 为了节俭存储老本，咱们在部署Druid集群时对于Historical节点采纳了多种不同的机器配置，在近期数据的解决上，机器装备SSD硬盘并设置较多正本数。这导致数量最多的Data Server节点，有一些不能与Middle Manager共享，同时不同的节点因为装备了不同核数CPU与内存，对应的JVM配置和其余线程池配置也不同，进一步加大了运维老本。 另外，因为Druid的数据模型分为Primary timestamp、Dimensions、Metrics，而Metrics列只能在启用Druid的Rollup时才会存在，而Rollup意味着写入时聚合且数据会有肯定水平的失落。这种状况下，想把每行数据都原原本本地记录下来，只能把数据全都记录在Dimensions列，不应用Metrics，而这也会影响数据压缩以及某些场景的聚合查问性能。 此外还有一些问题如Druid的SQL编译性能问题、原生查问简单的嵌套构造等在此便不再一一列举，总之基于上述问题咱们决定再次具体测试一下TDengine。 二、与Druid的比照导入雷同的两份数据到Druid和TDengine中，以下为在三节点（8c16g）环境下，100万个传感设施、每个传感设施是40列（6个字符串数据列、30个double数据列以及4个字符串tag列），总计5.5亿条记录的后果。这里要留神一点，因为数据很多为随机生成，数据压缩率个别会比真实情况要差。 资源比照： 响应工夫比照：1. 随机单设施原始数据查问1) 查问后果集100条2) 反复1000次查问，每次查问设施随机指定3) 查问工夫区间别离为：1天、7天、1月,4) 统计查问耗时的最大值、最小值、平均值5) SELECT * FROM device_${random} LIMIT 100 2. 随机单设施聚合查问1) 聚合计算某列的工夫距离的平均值2) 反复1000次查问，每次查问设施随机指定3) 查问工夫区间别离为：1天、7天、7天、1月，对应聚合工夫为1小时、1小时、7天，7天。4) 统计查问耗时的最大值、最小值、平均值5) SELECT AVG(col_1) FROM device_${random} WHERE ts >= ${tStart} and ts < ${tEnd} INTERVAL(${timeslot}) 3. 随机多设施聚合查问1) 聚合计算某列的工夫距离的总和2) 反复1000次查问，每次查问设施约10000个3) 查问工夫区间别离为：1天、7天、7天、1月，对应聚合工夫为1小时、1小时、7天，7天。4) 统计查问耗时的最大值、最小值、平均值5) SELECT SUM(col_1) FROM stable WHERE ts >= ${tStart} and ts < ${tEnd} AND device_id in (${deviceId_array}) INTERVAL(${timeslot}) ...

作者：关中旭 小T导读：陕西煤业股份有限公司(股票代码：601225），是陕西煤业化工集团有限责任公司煤炭资产惟一上市平台。陕煤在煤矿智能化倒退上成绩斐然，创始了首个全国智能化无人开采工作面，首个全国智能化掘进机器人。不仅是国内采煤新形式的先河，更填补了煤矿开采技术的空白。 为实现煤矿企业数字化生产治理，进步煤矿企业生产安全性、扩大煤矿企业管理手段及治理思路，陕煤开发团队思考将煤矿企业人员、车辆、设施、环境参数等各类根底数据，进行对立存储和智能剖析决策，在此背景下打造全矿井数字化平台，实现了煤矿企业井下人员、胶轮车及电机·车地位监控、井下各类设施状态监控、井下各类传感器数据监控、井下地位地点的告警剖析及事件联动。 此平台的搭建意义在于买通煤矿生产环境中各类繁多子系统之间的数据壁垒，实现各类子系统数据之间的互联互通。在实现门路上，平台底层基于规范TCP/UDP协定接入公司自研硬件设施，并通过定制化的协定转换模组接入其余非标的设施通信协议，将上传数据进行归集入库存储并通过大数据分析平台进行驱动剖析，最初依据业务具体情况生成数据统计与驱动后果。 一、技术选型以地位数据为例，井下人员、车辆佩戴装置定位设施后将基于井下网络进行地位数据的实时上传，人员默认上报周期为1秒，车辆默认为0.5秒。在原有单零碎我的项目中，因为初期零碎容量较小且硬件设施上传周期较大，所以采纳了传统SQL Server数据库来进行轨迹数据存储。但随着后续我的项目迭代，硬件设施定位精度进步且上报周期缩短，也导致数据库存储压力增大。 为解决大数据量存储问题，咱们先是思考在数据接收端减少大量数据过滤算法，对原始数据进行预筛来缩小最终入库数量，在数据库侧则采纳减少分库分表的策略，那在数据查问端就须要对分库分表进行大量的查问语句优化。这样一来，整体我的项目不仅复杂度较高，而且后续保护类工作量微小。 在平台设计阶段，一是鉴于上述失败教训，其次咱们也思考到不论是地位数据还是传感器数据，尽管数据载体不一样，但它们都是蕴含工夫戳的序列数据，且数据存储固化后很少再有须要更新的业务场景，采纳时序数据库来存储这类数据再适合不过了。基于此，咱们开始进行选型调研，对几类时序数据库进行了综合比拟： OpenTSDB基于HBase的时序数据库实现，反对集群横向扩大，然而部署及运维老本较高，且提供的查问函数较少，不适宜后续查问业务的扩大。TDengine**早在TDengine开源之初咱们就对其有所关注。对一个新兴根底开源我的项目，稳定性始终是咱们掂量的重要规范，TDengine在后续开源的2.X版本中不仅减少了集群模块且稳定性也大幅提高，同时其SQL语句与传统关系型数据库语句类似，部署及保护绝对简略，社区环境很好，也有企业单干模式。InfluxDBInfluxDB在开源时序库畛域长期占据TOP1的地位，社区比拟沉闷且生态建设也挺好。但因为集群模块没有开源，不实用公司产品的高可用要求。综合上述几类时序数据库的优缺点，最终咱们决定采纳TDengine作为本我的项目根底数据的存储计划。 二、建库建表基于TDengine的产品架构图搭建如下： 建模思路在定位业务时能够细分出人员、车辆等不同的定位对象，只管数据类型不同，但定位相干数据字段均统一，因而定位数据应用一张超级表进行治理即可。在TDengine超级表内数据类型及各个数据对象编号将作为tag进行辨别，在查问业务时应用超级表并关联tag字段进行查问。从咱们的理论业务登程，具体建表思路如下： 三、落地成果最终落地时我的项目采纳了3个节点的集群环境，定位设施采纳超级表进行治理，将数据标签及数据类型作为tag辨别各类定位设施。每个定位设施采纳子表存储，理论我的项目已蕴含2万多个定位设施。从写入性能到查问性能均大幅满足现场理论需要：总计定位数据量超过11亿条，数据压缩后TDengine数据目录占用磁盘大概12G，整体压缩率能够达到3/100。 下图示例为我的项目中人员与车辆定位理论应用场景，基于TDengine数据库引擎，对井下的人员、车辆数量以及地位进行实时统计与展现。 四、将来布局随着我的项目的一直推动直到施行落地，咱们也见证了TDengine的几次大版本更新，目前集群整体运行状况绝对稳固，性能和老本管控也达到了咱们的预期。为了帮忙TDengine可能实现更好地倒退，在此也为其提出几点优化倡议： 目前TDengine在陕煤应用的监控性能还较为简单，心愿后续版本升级过程中可能优化集群环境监控相干的性能。目前我的项目在应用JDBC驱动时，是通过客户端连贯TDengine的。随着版本升级，运维工作量较高，须要同步降级服务器和客户端，且JDBC驱动降级的话还须要同步降级对应服务，步骤绝对繁琐，心愿在接下来的版本中能加以改善。想理解更多TDengine的具体细节，欢送大家在GitHub上查看相干源代码。

作者：王强 很久以前就听闻了TDengine的小名，也看过TDengine的很多相干数据和报告，给我留下的印象总体来说还是很不错的。到当初TDengine曾经开源两年了，机缘巧合我就想理解一下整体的社区状况，看看开源社区的综合活跃度是什么程度。做了一篇笔记，给感兴趣的同学做个参考。 GitHub仓库一般来说大家看开源我的项目活跃度第一步都是直奔GitHub仓库，这个我也不能免俗。点进去一看Star有17.6k，Fork 4.2k，看上去挺厉害。咱们再一起瞧瞧贡献者和issue的细节。 从提交曲线来看活跃度还不错，但大部分提交其实都来自于大量贡献者（小于100人），阐明这个我的项目目前还处于开源社区的初期阶段，除了官网以外大部分人只是应用而没参加到我的项目建设里。提交的issue倒是没有什么刷问题的迹象，灌水issue（比如说改个错字之类）十分少见，绝大部分都是失常的报告bug、改良倡议之类。目前敞开的issue有两千多，open状态的不到500，对于刚做两年多的细分畛域我的项目来说算是不错的问题。 从GitHub仓库来看，TDengine的社区状况和国内很大一部分开源我的项目差不多，那就是整体活跃度还不错，但参加人数果然还是不够。当然，对于这种新生我的项目来说咱们不能奢求太多，毕竟罗马非一日建成，除非是偏“大众化”畛域的网红级我的项目，否则两年工夫做到这种程度还是很失常的。何况TDengine次要市场还是在国内，客户群体以大型行业客户为主，这一畛域人造就没有很大参加开源事业的激情。随着TDengine的市场持续扩充，置信这一情况会失去改观。 中文社区当然了，GitHub仓库只是开源社区的一部分，很多时候甚至只是冰山一角。IT世界是自在的，程序员往往会在各种稀奇古怪的中央表白他们对某种技术的激情。所以咱们再来看看互联网上各种社区里TDengine的探讨详情。 先点开相熟的知乎，搜寻TDengine，下滑有近百条内容，能够看出一些感兴趣的同学和我一样，会先来知乎向大家进行发问理解，TDengine的团队应该也在保护这个社区渠道，整体而言，从这里还是能获取很多对于TDengine的内容的，甚至有一些问题的浏览量达到了10万+。 再看CSDN，相干的文章探讨数量还是很多的，在业余度比拟高的前提下点击量大都算是不错的程度（在技术圈子里，业余文章有500点击都算是很棒了，越业余越没人看是常态）。不过看多了也会发现个问题，介绍装置应用入门之类的文章多，真正谈及深度应用体验的少。对于想从其余产品跳过来的用户，果然还是心愿看到更多深度体验，尤其是我的项目教训分享的嘛。 TDengine官网在InfoQ写作平台入驻进去了，官网发文相当勤奋，外面给的内容干货极多。集体认为这一部分是对感兴趣的潜在用户价值最高的局部。因为在没应用前，开发人员对某个我的项目的技术细节其实是不会太过关注的，没有亲自体验亲自操作总是有雾里看花的朦胧感。这时候更能提起趣味的往往是各种实际案例报告和分享，内容干货越多越吸引人。尤其是很多案例报告会提到一些大家都容易遇到的痛点，这时候看看作者是怎么用新技术新办法解决问题的就很有价值。毕竟大家工作还是很忙的，新常识跟本人当初的工作分割越多，产生趣味的机会才会更大。 V2ex是我集体比拟喜爱逛的社区，其实外面探讨深度技术的不算多，但整体气氛很轻松。我始终认为如果一个偏公众的社区都能看到某个开源我的项目的探讨，就能证实它曾经“出圈”了，而V2ex就是我眼中的“风向标”之一。目前这里对TDengine的探讨尽管数量很少，但大家的印象都比拟侧面，能够说风评是上等程度。思考到这个社区里大家嘴都比拟毒，常常对各种技术毫不留情批评，TDengine能有这个风评是很难得的。（上面是某条评论，看着不像水军） 英文社区非GitHub的英文社区里，思考到TDengine目前以中国市场为主，仿佛咱们不应该对“老外”的关注度报什么心愿。首先来看Twitter，额...关注数一千多，转发寥寥无几，然而官号还是十分勤奋在更新的，如果国外的敌人想初步对TDengine做一个理解，来Twitter是一个可行的计划。顺便一提官网推特的各项数据都比微博好很多，果然搞技术的还是要看推，微博就留给公众生存娱乐吧。 Medium上相干内容也不多。我认为Medium在国内技术社区里是影响力相当大的，很多技术人喜爱在这里写货色。如果咱们能在这里看到一些对于TDengine的自发探讨、文章，阐明我的项目在寰球的影响力曾经达到了一个很高的程度了。目前TDengine只有两年开源历史，国内影响力有余能够了解，心愿未来能在Medium上见到它的身影。 reddit的影响力在技术圈里也是很大的，尽管也没有太多的内容，但能够发现一些官网的脚印。官网能留神到这里是一个很好的开始，这阐明开发团队曾经在为寰球大范畴扩大做布局和思考，甚至提前开始铺路了。 集体认为目前TDengine官网确实不须要将太多精力放在国外社区，等到国内影响力达到肯定水平后国内影响力也就是瓜熟蒂落的事件了。但国外的敌人们如果想要对其做充沛理解，可能须要擅于在国内的技术社区去挖掘一些内容。 一点总结和思考察看TDengine社区活跃度的时候其实我在思考一件事件，那就是开源社区活跃度真的是特地重要，或者说对所有新技术来说都特地重要的事件吗？诚然，TDengine的社区数据跟咱们耳熟能详的一些传统数据库比起来可能的确有些差距，但这些必须跟我的项目的畛域特点、市场环境综合起来能力偏心对待。 TDengine的客户多为行业客户，指望他们在社区里踊跃发言本来是不太事实的，然而它却突破了这个“事实”。在国内很多技术社区里搜寻TDengine时你会发现很多对于开发者撰写的利用案例，这些应用过TDengine的人违心站进去去讲他们的应用办法和应用成果，由此咱们也能够看到TDengine的技术口碑的确是很不错的，或者真的能够在我的项目中尝试一把，当然，审慎起见，各种测试肯定要后行。 另一个角度来说，晚期阶段社区活跃度有余反而是一件坏事。很多我的项目在积攒有余的时候过早出圈、过早吸引了太多开发者甚至公众关注，烦扰了官网的眼帘甚至影响了后续的开发和市场策略，这很难说就是侧面的。有些我的项目人造就适宜炽热的氛围，还有些项目选择宁静、小而美的路线却能有更久远的倒退，TDengine应该就属于后者。等到内力积攒到肯定水平，我的项目具备了弱小实力并领有大量客户和实际后，开源社区活跃度也天然会迎来暴发了。

吉科软信息技术有限公司是国家高新技术企业，公司以“让天下没有不释怀的食品”为使命，以“做数字化保卫食品安全的领军企业”为愿景，以打造食用农产品全流程追溯、全流程监管、全流程服务、全产业链降级为外围的产业互联网生态链为主营业务，使用卫星遥感、5G通信、大数据、云计算、物联网、区块链和人工智能等技术，推出一系列国内首创、行业当先和可落地的研发成绩，为智慧农业、智慧食安、智慧城市提供解决方案。 业务背景车辆轨迹定位监控我的项目旨在通过车辆的轨迹监管、异样预警、历史轨迹回放，达成对车辆的对立监管、轨迹追踪、大数据分析及可视化利用等目标。该我的项目现已对数万台车辆通过车载定位设施上报定位数据至GIS网关服务，服务解析报文下发至音讯队列，利用再将定位数据写入InfluxDB，最新车辆地位信息写入Redis，为客户提供车辆实时地位跟踪和历史轨迹回放等查问剖析服务。 时序数据库选型首先咱们梳理了以后车辆监管架构的次要个性和新需要： 继续高并发写入，带有tag，工夫戳有时会乱序写入(存在离线数据上传的状况，离线数据的工夫戳小于以后工夫戳)；业务数量级增长快，预估将来每天写入约8亿条数据；对基于工夫戳范畴的聚合查问，属于低频查问，通常是由用户触发，查问最近几天的轨迹，按执行工作的工夫进行轨迹回放。实时查问需要，对每个车辆有最初一个定位点数据的查问需要，获取实时地位监控；因为数据量十分大，所以须要反对数据压缩，降本增效；冀望每个车辆独自建表；需反对批量数据写入，且业务冀望写入延时较低；车辆监管我的项目有产品国产化的需要，在中间件的抉择上需采纳国产化产品。此前，咱们的我的项目一期采纳了InfluxDB时序数据库作为存储车辆轨迹数据，二期我的项目须要从新降级改版后进行全新架构设计，同时也要思考业务规模的快速增长、国产化要求及InfluxDB的单节点问题。因而我司须要对时序数据库进行从新选型。咱们对业界支流的时序数据库做了剖析和测试： InfluxDB：由InfluxData开发的开源时序型数据。它由Go写成，着力于高性能地查问与存储时序型数据。被广泛应用于存储系统的监控数据，IoT行业的实时数据等场景。毛病是开源版本只反对一个节点，开源版本没有集群性能,存在前后版本兼容性问题，非国产化产品。OpenTSDB：基于HBase的分布式、可伸缩的工夫序列数据库。作为基于通用存储开发的时序数据库典型代表，起步比拟早，在时序数据库畛域的认可度绝对较高，但HBase老本高的问题无奈罢黜。TDengine：国产开源时序数据库，应用类SQL查询语言来插入或查问数据；通过间断查问，反对基于滑动窗口的流式计算；引入超级表，让设施之间的数据聚合通过标签变得简略灵便；内嵌缓存机制，每台设施的最新状态或记录都可疾速取得；分布式架构，反对线性扩大，以保障任何规模的数据量都能够解决；反对多正本，无单点故障，保证系统的高可用与高牢靠。这些性能和个性都十分合乎咱们的需要。通过理论比照后、再加上迁徙改变最小化以及国产化需要等因素，咱们最终选定TDengine作为车辆轨迹数据的存储计划。 TDengine的落地利用初期咱们选用了三台服务器，搭建了3节点3正本的集群。目前已投入一批车辆经营监控，后续咱们将逐渐迁徙全副车辆的轨迹数据至TDengine。 历史数据从InfluxDB迁徙至TDengine，采纳的计划是基于Datax数据同步，咱们扩大开发了InfluxDB的读插件和TDengine的写插件，单过程数据同步可达到6万/秒的同步速度。（该速度受限于influxdb的读取，在该过程中 influxdb的内存上涨过快撑不住， 所以最终测试的同步速度 是6万/秒。目前官网已公布“基于DataX的TDengine数据迁徙工具和taosAdaptor工具”） 以迁徙的局部数据进行剖析：总数据量为6.5亿，散布在14742个子表中，占用磁盘空间4.7G，压缩率达到4%。开启了cachelast选项为1缓存子表最近一行数据，利用该缓存个性，查问指定车辆的最新GIS定位数据进行实时监控时，可间接从缓存中读取，放慢读取速度。 在应用TDengine之前，对于所有车辆的最新地位实时监控，咱们采纳的计划是在接管gis数据存储至InfluxDB时，同时将车辆的最新地位数据存储至Redis和Mysql，应用TDengine后计划中对实时地位的存储间接应用TDengine的缓存子表最近一行数据的个性就能够实现，齐全能够去掉Redis和Mysql的存储。 TDengine的性能体现我的项目对车辆轨迹数据的利用场景次要集中在车辆实时地位监控、车辆工夫范畴内的轨迹回放。 1.车辆实时地位监控场景：查问单个或多个车辆的最新GIS地位数据。单个车辆最新地位查问：select last_row(*) from d_track where car_id in ('dc8a9a0d7b634c9ba4446445c6c'); 利用查问超表的单个车辆最新地位数据工夫在11毫秒。如果间接锁定子表进行查问的话， select last_row(*) from _018d16c826cb405ea4a94a14cd4f95a9 ;返回最初一条地位数据的响应工夫在1毫秒。多个车辆的最新地位数据查问，仍旧应用超表联合标签进行查问，查问响应工夫在12毫秒左右。持续扩充查问范畴，查问500~1000个车辆的最新地位的查问响应工夫也能在1秒之内返回后果，齐全达到业务响应的工夫需要。 2.工夫范畴内车辆的轨迹数据查问指定车辆在指定工夫范畴内的轨迹数据查问，间接定位到具体的子表进行查问，select * from _0128a4d193424dcfb217242f054716d4 where time >'2021-09-08 10:34:44.000' and time <'2021-09-23 21:38:18.000' ;测试数据的查问响应工夫为0.07秒左右。在以上两种数据查问场景中，TDengine的性能不仅齐全可满足需要，更是比原InfluxDB+Redis+Mysql计划大幅度的晋升，解决了原计划中车辆查问较大时间跨度的轨迹数据响应超级慢的问题。 写在最初非常感谢涛思的TDengine，切实解决了咱们在国产化、性能、降本、平滑迁徙的刚性需要。也非常感谢涛思的罗格老师在咱们尝试和利用TDengine过程中给予的悉心领导，放慢了咱们对TDengine的把握，更快的利用落地。以后TDengine的大规模利用车辆监管我的项目中，撑持现有数万辆车的行驶轨迹监控，将来将持续扩充规模撑持更多的车辆轨迹监控。 作者孙运盛 吉科软技术研究院架构师

作者：冰茹 小T导读： 和利时始创于1993年，业务集中在工业自动化、交通自动化和医疗大衰弱三大畛域，联合自动化与信息化两方面的技术劣势，提出了“智能管制、智慧治理、自主可控、平安可信”的策略指导方针。围绕团体三大业务，公司对工业互联网、大数据、5G、信息安全等新兴技术发展更深刻的钻研和利用示范，打造面向各畛域利用的工业互联网平台，进一步促成智能制作解决方案的落地利用。 在物联网场景下，面对宏大的时序数据处理需要，Oracle、PostgreSQL等传统关系型数据库越来越吃力。基于此，目前国内外支流工业互联网平台简直都曾经采纳时序数据库，来承接海量涌入的工业数据。 究其原因，能够从数据的三个外围需要来解释。咱们都晓得，企业在抉择数据库、文件系统等产品时，最终目标都是为了以最佳性价比来满足数据的三个外围需要：数据写入、数据读取、数据存储。时序数据库齐全是依照时序数据的三个需要特色进行设计和开发的，在数据处理上更加具备针对性： 在数据写入上，如果将工夫看作一个主坐标轴，时序数据通常是依照工夫程序到达，到达的数据简直总是作为新条目被记录，在数据处理操作上95%-99%都是写入操作；在数据读取上，随机地位的单个测量读取、删除操作简直没有，读取和删除都是批量的，从某工夫点开始的一段时间内读取的数据可能十分微小；在数据存储上，时序数据结构简略，价值随时间推移迅速升高，通常都是通过压缩、挪动、删除等伎俩来升高存储老本。而关系型数据库次要应答的数据特点却天壤之别： 数据写入：大多数操作都是DML操作，插入、更新、删除等数据读取：读取逻辑个别都比较复杂数据存储：很少压缩，个别也不设置数据生命周期治理因而，从数据实质的角度而言，时序数据库（不变性、唯一性以及可排序性）和关系型数据库的服务需要齐全不同。这也是咱们一开始就锁定时序数据库来满足工业互联网场景的外围起因。 一、时序数据库选型咱们对包含InfluxDB、OpenTSDB、HolliTSDB（和利时自研时序数据库）、TDengine在内的四款时序数据库进行了选型调研及相干测试。 测试数据的频率为1秒钟，数据集蕴含10000台设施，每台设施有10000条记录，每条数据采集记录蕴含3个标签字段、2个数据字段、1个工夫戳字段。测试比照项包含占用磁盘空间、百万条数据遍历查问、聚合查问（COUNT、AVG、SUM、MAX、MIN）。测试后果如下所示： 占用磁盘空间百万条数据遍历查问聚合查问COUNT聚合查问AVG聚合查问SUM聚合查问MAX聚合查问MIN同等条件下，TDengine的压缩率最高，数据占用的存储空间最小；在原始数据查问上，OpenTSDB最慢，TDengine与HolliTSDB在伯仲之间；在聚合查问操作上，TDengine最快，HolliTSDB的速度和InfluxDB相当，OpenTSDB最慢。同时，InfluxDB只能单机部署，集群版本并未开源，且查问性能存在瓶颈，其QPS约为30-50。 从性能测试后果来看，咱们抉择TDengine的起因次要源于以下几点： TDengine在查问性能维度上的体现十分优异，满足了咱们的业务查问需要集群性能开源，不便横向扩大，更弹性在开源热潮之下，反对如TDengine个别的国产开源数据库、操作系统、中间件等也是企业的必修课最终咱们决定接入TDengine，以享受更多元的本地化反对和响应。 二、技术架构与实现目前TDengine作为边缘版时序数据库在搭建应用，具体的技术架构如下图所示： 基于TDengine进行建库建表思路如下： CREATE STABLE IF NOT EXISTS ts_super (time TIMESTAMP, s BIGINT, vl BIGINT,vf DOUBLE,vb BOOL,vs BINARY(16349))TAGS (innerId BIGINT, namespace BINARY(256), id BINARY(256), type BINARY(1), seq int);在构建列时，蕴含元素为time（工夫，主键）、s（数据品质）、vl（整形类型数据L）、vf（浮点型数据F）、vb（布尔型数据B）、vs（字符串数据S），其中time、s是必填的列，残余列则要依据测点类型填写，比方测点上报的是整形数据，就只须要设置time、s、vl这三列，vf、vb、vs这三列为null。 在构建tag时，要包含innerId（测点外部编码）、id（测点id）、type（测点类型，L/F/B/S）、seq （序号，L/F/B类型数据设置为0，S类型测点的seq可能为0,1,2,3...） 同时，在建库建表的操作中咱们也碰到了一些小问题，放在这里给大家做下参考： 因为表名不反对特殊字符，所以须要再生成一个惟一编码作为表名；查问语句会被填充，导致查问过程性能变慢，网卡被打满。这种状况下只须要将查问申请手动压缩，就能无效升高带宽占用率；TDengine字符串最长能够有16374字节 ，超过的话须要从逻辑上解决。咱们采纳的计划是如果长度超过16374 ，截取该字符串，同一个测点再建新的表，通过tag关联。三、实际效果展现1. 数据库配置TDengine集群5个节点，正本数设置为3。批改配置为： minTablesPerVnode 10tableIncStepPerVnode 10compressMsgSize 1024rpcForceTcp 1httpMaxThreads 16各节点机器配置如下： 2. 查问客户端配置客户端共有三台主机，每台主机上别离运行时序查问及其对应的AB，各主机上的时序查问独立运行，别离启动一/二/三个时序查问及其对应的AB进行性能测试。 3. 数据阐明共1000个测点，80000万条数据，数据频率为每秒钟1条。存储散布如下所示，存储压缩率不超过1/10。 4. 查问后果 在咱们的业务查问当中，减少QPS的次要形式是减少查问的并发数。AB从1到2，QPS减少了45%，均匀响应工夫不超过1000ms，很好满足了客户需要 5. 资源耗费(统计3个查问服务的实例)TDengine node节点资源耗费 在查问过程中，数据是绝对平均的散布，然而不同节点的CPU耗费依然有较大的方差。这是因为TDengine的RESTful的底层是在服务端通过独自的代理线程作为客户端查问，所以会受到申请均匀度的影响。如果TDengine在后续能够做代理层面的负载平衡，置信可能放大这个偏差。 6. 查问服务资源耗费 ...

作者：潘文彪 小 T 导读： 中节能风力发电股份有限公司（股票简称：节能风电，股票代码：601016）是中国节能环保团体有限公司控股的古代股份制公司。公司先后胜利中标并示范建设了国家第一个百万千瓦级风电基地启动我的项目——河北张北单晶河 200 兆瓦风电特许权我的项目，和第一个千万千瓦级风电基地启动我的项目——甘肃玉门昌马 200 兆瓦风电特许权我的项目，是国家首个百万千瓦、千万千瓦风电基地的示范者和引领者，在业内建立了较高的知名度和良好的品牌形象。建成、在建我的项目装机规模 547.97 万千瓦，已倒退成为张北坝上地区、甘肃河西走廊地区最大的风电开发商之一，是我国风电畛域一支重要的力量。 一、我的项目背景公司作为中节能团体在风电畛域的专业化公司和外围上市平台，具备成熟的风电开发和运维教训，然而随着在建风场逐渐增多以及各类新型传感器的加装，传统运维形式曾经越来越吃力，数字化智能化的需要越来越强烈，因而迫切需要基于海量时序数据的数据平台来撑持繁冗的运维工作。 因而，咱们做了大量的时序数据调研工作。然而选型工作也并非一帆风顺，开始咱们尝试传统的工控时序数据库，然而随着测点数量的增多，单机版架构曾经有力撑持，前期咱们也尝试了 InfluxDB 和 OpenTSDB 等分布式架构的时序数据库，然而性能又达不到要求。 时机偶合，咱们留神到一款国产、开源的时序数据库 TDengine，所以也尝试了一下。 二、TDengine 选型测试针对咱们重点关注的查问性能，咱们做了如下几个测试。 1. 单测点历史数据聚合查问随机抉择任一个测点，查问该测点在某个时间段测点采集值的 count，max，min，avg；比方从 2020-01-01 00:00:00.000 到 2020-02-01 00:00:00.000 的 31 天内的共 535680 条数据记录的 count，max，min，avg。 具体的查问语句为： select count(*),max(col117),min(col117),avg(col117) from t_QH01 where ts>='2021-08-15 00:00:00.000' and ts<'2021-08-16 00:00:00.000'试验截图如下： 3 次查问测试时延如下： 2. 分组聚合查问查问某个时间段内测点采集值的 count，max，min，avg，比方查问从 2020-01-01 00:00:00.000 到 2020-02-01 00:00:00.000 的 31 天内的数据记录的 count，max，min，avg。 数据库中对应查问语句为： select count(*),max(col117),min(col117),avg(col117) from t_QH01 where ts >='2021-08-01 00:00:00.000' and ts<'2021-09-01 00:00:00.000' group by wtcode >>E:/taosTempData/2试验截图如下： ...

作者：马祥荣 小 T 导读： 作为一家业务遍布多个国家及地区的物流公司，货拉拉面临的技术环境是非常复杂的，在云时代浪潮下基于混合云疾速构建环境搭建零碎成为其必然的抉择。然而在混合云上如何对基于各家云构建的零碎进行无效的治理是个挑战，尤其对处于零碎最底层的数据库层面临的问题、业务诉求、各方痛点，是货拉拉 DBA 团队现下所须要重点解决的。 目前 DBA 团队治理的数据存储包含 MySQL、Redis、Elasticsearch、Kafka、MQ、Canal 等，为了保障监控采样的实时性，咱们自研的监控零碎设置的采样距离为 10 秒，这样每天都会产生宏大的监控数据，监控指标的数据量达到 20 亿+。后期因为治理实例少，监控数据量也少，所有数据都被寄存到了 MySQL 中；之后随着治理实例越来越多，应用 MySQL 来存储规模日益宏大的监控数据越发力不从心，急需进行降级革新。结合实际具体需要，通过对不同时序数据库进行调研，最终咱们抉择了 TDengine，顺利完成了数据存储监控的降级革新。 一、监控零碎开发中遇到的问题从存储门路来看，每种数据存储都散布在多个区域，每个区域将监控采样数据投递上报到音讯总线，而后由生产程序统⼀生产，生产程序会将必要的告警数据更新到告警表，同时将监控原始数据存储到 MySQL。比方，针对 Redis 这款数据存储，监控采样距离设置 10 秒，那么每天实例采样次数就会达到 3000 万+，监控指标累计 6 亿+，数据量之宏大可见一斑。晚期为了将数据存储到 MySQL 中，同时也能很好地反对监控绘图的应用，每⼀次实例监控采样时都会计算出该实例全量监控项采样数据，而后将本次采样的后果作为⼀条记录存储下来。 即便通过这样的优化解决，在做时间跨度大的监控绘图时，前端仍然会呈现提早卡顿的问题，后端监控数据存储的 MySQL 也压力山大，常常满载，天天被吐槽。因而针对这种时间跨度大的查问，咱们专门开发了⼀系列的数据聚合调度工作——依照不同的时间跨度，提前将 10 秒采集距离的监控数据做好聚合，监控绘图程序再依据不同的时间跨度选取不同的聚合数据表绘图，以此解决长时间跨度监控绘图展现提早卡顿的问题。 但这依然治标不治本。为了压缩监控数据存储空间，原始 10 秒距离的监控数据表只能归档保留 3 天工夫的监控数据，但存储大小也将近有 200GB， 加上与之相干的不同时间段的数据聚合表，存储一下子冲破 300GB。这还只是 Redis 监控数据的存储大小，加上其它数据存储的监控数据，至多须要 1TB+空间的 MySQL 存储。 数据汇合工作治理简单、前期监控原数据回溯缺失、MySQL 存储空间日益增长带来的隐患，都是亟待解决的问题。 二、时序数据库选型为了解决 MySQL 监控数据存储的问题，咱们把注意力转移到了适宜存储监控数据的时序数据库上。市面上各种时序数据库产品目不暇接，有老牌的，也有后起之秀，通过⼀系列调研选型，咱们抉择了 TDengine，次要是因为其具备的如下几大长处： 采纳分布式架构，可反对线性扩大数据存储压缩率超高集群模式反对多正本，无单点故障单机模式性能强悍装置部署保护简略SQL⽀持工夫维度聚合查问客户端反对 RESTful API值得一提的是，TDengine 的 SQL 原生语法反对工夫维度聚合查问，同时数据存储压缩率⾼存储空间小，这两点间接切中了咱们的痛点。落地后实测雷同数据的存储空间只有 MySQL 存储空间的非常之⼀甚至更少。 还有⼀个惊喜是，在现有监控数据存储(MySQL)顶不住的状况下，⼀台 8C16GB 的单机版 TDengine 轻松就抗下目前所有监控流量和存储压力, 且运行稳固，根本没有故障。 ...

作者：何佳瑞 小 T 导读： 在万物互联的时代，大到企业数字化转型、数字城市建设，小到和生存非亲非故的家居生活、智能驾驶、静止衰弱等，都离不开智能物理设施宽泛的连贯和互通。AIoT 是人工智能和 IoT 技术的交融，通过物联设施网产生、收集来自不同维度的、海量的数据存储于云端、边缘端和设施端再通过海量数据分析引擎，以及更高模式的机器学习、神经网络，实现万物数据化、万物智联化。 2014 年起，京东从智能家居畛域开始发力，在业界率先推出语音交互入口-叮咚智能音箱，实现了宽泛的设施品类互联生态，同时整合团体外部批发、物流、大衰弱、工业品等要害畛域的物联网技术能力，继续助力社区、城市、车联、工业等要害行业畛域，宽泛服务于实体经济，助力企业转型降级。本文在京东云 IoT 多年来行业实践经验积攒的根底上，分享在数据存储方面的一些做法。 一、场景与痛点数据是数字化时代企业的外围资产。京东云智能家居场景保护着大量的智能设施，这些设施联网后，会依据设施设定的速率继续产生时序数据，比方有的设施采样距离是 15 秒。京东云 IoT 团队联合本公司数据特点与业务需要，对多种工业时序数据库进行了技术选型，以解决宏大的数据存储和计算带来的挑战： 数据存储具备较高的数据压缩比，节约存储资源，升高 IT 老本写入和查问性能优异，数据库底层逻辑的优化能够缩小 CPU 开销反对数据预聚合，领有丰盛的计算算子强有力的稳固架构二、技术选型咱们对两种业界支流的时序数据库做了剖析和测试： OpenTSDB：基于 HBase 的分布式、可伸缩的工夫序列数据库。作为基于通用存储开发的时序数据库典型代表，起步比拟早，在时序数据库畛域的认可度绝对较高，但 HBase 老本高的问题无奈罢黜。TDengine：在性能、老本、运维难度等方面都体现不俗，反对横向扩大，且高可用。通过理论比照测试，咱们初步选定 TDengine 作为数据存储计划。TDengine 相比于 OpenTSDB 有显著的劣势： TDengine 写入吞吐量高出 200%1 亿条记录均匀查问工夫晋升 100 倍100 万条记录读取工夫晋升 32 倍1 亿条记录按工夫分组取均值工夫晋升 40 倍老本开销升高 2-3 倍三、数据建模TDengine 数据建模需依据数据的个性设计相应的 Schema，以达到最好的性能体现。对于物联网设施而言，是围绕着设施孪生工作的。设施有对应的物类型、物模型，物模型形容了设施的属性感知和交互行为。因而，咱们基于物类型、物模型进行了 Schema 的设计： 基于物类型、物模型创立超级表数据聚合以字表为维度，依照物模型及数据个性，抉择不同的聚合算子进行聚合超级表举例如下： 四、落地施行联合业务需要与数据特点，咱们采纳的计划是：将设施上报的元数据存储在 metadata 库中，而后通过定时工作的形式，每小时以设施的维度，依据物模型，进行数据聚合，将聚合后的数据存储在 statistics 库中。同时为了缩小数据存储的压力，将 metadata 的数据过期工夫设置为固定时长。 五、革新成果在与 TDengine 工程师沟通后， 咱们只应用了 3 台 4C16G 形成的 TDengine 的集群，就承载了线上的业务。数据聚合方面，依据 TDengine 的性能、机器配置和后期测试的工夫开销，只需很短的工夫就实现了全量设施的数据聚合。 ...

作者：唐时涛 小 T 导读：格创东智科技有限公司成立于 2018 年，孵化于中国 500 强企业 TCL，是我国出名的工业互联网平台服务商。公司依靠 TCL 团体 40 年工业场景和制作基因积淀，基于“面向工业现场”的研发方向和“连贯、协同、共享”的倒退理念，深度交融人工智能、大数据、云计算、物联网等前沿技术，打造了新一代具备自主知识产权的工业互联网平台——"东智工业利用智能平台"。 作为东智工业利用智能平台产品家族的物联网平台，G-Things 为工业设施提供了安全可靠的连贯通信能力，其反对数据采集、规定引擎、数据转发、指令下发、数据可视化，同时提供凋谢的 API 与第三方零碎疾速对接，为工业企业提供高效率、低成本、高牢靠的工业物联网解决方案。 从采集的数据类型上来看，平台采集的设施数据以及零碎业务次要有以下时序数据个性: 设施所有采集的数据是时序性的、结构化的设施采集点的数据源是惟一的数据存在时效性以写操作为主，读操作为辅须要统计、聚合的实时计算操作数据的查问个别指定工夫区间反对高频数据接入为了让用户在最大水平上实现降本增效，G-Things 在接入不同的租户时，会从用户类型(轻量级、重量级等)、设施规模、设施采集的数据量等角度帮忙用户抉择适配正当的时序数据长久化落地计划。 一、时序数据库选型调研自 2019 年咱们便开始关注一些国内的数据库，通过调研发现 TDengine 很适宜咱们的业务场景，它领有读写性能弱小、部署简略、超强的数据压缩比等个性，同时超级表、子表的标签 tag 设计也很好地符合了平台物模型中的设施模型、设施概念。 为了验证 TDengine 在读写、存储等方面的性能，咱们将其与 Cassandra 、OpenTSDB 在同等条件之下进行了相干的读写性能比照测试，测试后果如下： 在等同数据集和硬件环境下，比照发现： TDengine 的性能远超 Cassandra 和 OpenTSDB，写入性能别离是两者的近 20 倍、25 倍，读取性能约为 17 倍、32 倍，聚合函数性能约为 4000 倍、1000 倍，按标签分组查问性能约为 2500 倍、1000 倍，按工夫分组查问性能约为 119 倍、40 倍，压缩比约为 26 倍、5 倍。 基于此，TDengine 在选型中怀才不遇。 二、技术架构与具体实际具体到理论业务中，咱们应用 TDengine 次要存储以下三种类型的数据： 租户设施上抛的原始数据。通过实时计算解决后保留，租户彼此之间数据隔离，一个租户一个 TDengine 库零碎计算设施状态变更的日志数据零碎中跟设施关联的相干控制台的操作日志数据TDengine 在平台中的总体架构图如下所示： 相比于原架构，应用 TDengine 之后呈现了以下变动： ...

导语：2021 年是寰球进入后疫情时代的第二年，各行各业都仍然处在疫情所带来的阴郁中，因为病毒的一直肆虐，企业的业务拓展处处碰壁，各种行业交换峰会也举步维艰。但只有咱们以乐观的心态来应答将来不确定的挑战，以一直的技术创新作为在风雪中后退的驱动力，当在这一年年末驻足时就会发现，往年总会比去年有所提高。始终以来，涛思数据都是将产品和服务放在第一位，从客户的需要登程做技术创新，以技术创新来推动行业倒退。在新旧年交替之际，咱们“打包”了包含产品、用户、开源、流动、融资等各方面的年初数据，为始终在关注咱们的企业和开发者递交一份 2021 年度“成绩单”。 站在 2021 年的“高峰”之上，回望来时之路，过来一年的问题跃然纸上，这也成为一众涛思人一年耕耘之下的最好回报。 ·2021，基于客户需要做产品迭代2021 年，TDengine 依然依照两周一个版本的频率迭代，同时扭转了公布规定，同步推动 beta 版本和稳固版本，让社区用户能够更早体验到新性能。合并了 4607 个 Pull Requests，正在运行的测试例靠近 1800 个，软件代码行数共计 104 万行…… 从用户需要登程，咱们在 2021 年公布了大大小小 30 余个新性能，重点包含：升高企业迁徙老本的独立程序 taosAdapter、基于 Grafana 的 TDengine 零依赖监控解决方案 TDinsight、纳秒工夫精度、浮点数有损压缩、原生接口写入、嵌套查问、无模式（Schemaless）写入等等。 如果大家对公布的 Releases 感兴趣，能够到以下地址查看：https://github.com/taosdata/T... ·2021，TDengine 开源数据再创新高早在 2019 年，涛思数据便将 TDengine 开源，2020 年再次加大开源力度，将 TDengine 外围的集群个性也进行了开源，所有的外围代码均托管于 GitHub 上。截至目前，TDengine 在 GitHub 上的 Star 数已达 17500，Fork 数达到 4200，PR&Issue 数达到 9400，Contributor 超过了 160 人。 2021 年，TDengine 的各项开源数据再创新高；2022 年，咱们仍旧还会本着成就开发者的初心加大力度打造开源力量，回馈社区。 ·2021，用户规模的晋升激励着技术和产品的提高凭借着继续一直的技术创新和稳固壮大的开源力量，涛思数据的市场规模也在往年创始新高，用户数量实现了快速增长。 目前，TDengine 在寰球各地的上线实例数曾经靠近 10 万，在国内外近 400 个城市里都能看到 TDengine 被应用的身影。用户数量的晋升在肯定水平上印证了行业和市场的必定，也成为激励技术和产品提高的最佳推动力量。 ...

整顿 | 尔悦嘉宾 | 廖浩均 小 T 导读：近年来，随着各种新兴技术的倒退，物联网、工业互联网等行业取得了疾速倒退，由此产生的时序数据量也越来越宏大，通用大数据计划越来越难以为继，各种时序数据库产品应运而生，迁徙也成为企业面临的重难点操作之一。 相比于 TDengine，OpenTSDB 算是入场更早一些的“玩家”，基于 Hbase 的产品模式无利也有弊：为有 Hbase 根底服务的企业升高了门槛的同时，适度依赖 Hbase 也为性能、压缩成果加设了一个瓶颈。随着企业业务规模的不断扩大，监控零碎的部署老本和运行效率都会出现增长的态势，随着工夫的推移，OpenTSDB 的缺点所带来的负面效应将齐全超过侧面成果，顺丰科技的业务案例便印证了这一点。 此前，顺丰科技应用 OpenTSDB 作为全量监控数据存储计划，不仅运维和应用老本很高，性能上也越来越难以满足需要——日常大跨度和高频次查问曾经无奈满足以后业务倒退的需要，查问返回后果甚至须要十几秒。随着用户量的减少，反对较低 QPS 的 OpenTSDB 非常容易解体，一旦解体将导致整个服务都变为不可用状态。随后在调研过市面的时序数据库产品后，顺丰科技便决定向 TDengine 进行迁徙。 为了帮忙和顺丰科技一样有迁徙需要的企业，咱们举办了 TDengine 技术公开课，本文基于涛思数据联结创始人廖浩均主讲的《TDengine 技术底细分享——兼容 OpenTSDB》整顿，从具体的操作层面为大家答疑解惑。 一、从 OpenTSDB 迁徙到 TDengine 的注意事项在做出迁徙决定之前，一些同学可能比拟关注的是 TDengine 对 OpenTSDB 的兼容度如何？这个问题要从两个维度来看，一是写入协定的全兼容，二是查问性能的全笼罩。前者来看，你无需扭转任何一行代码就能够将数据齐全写入到 TDengine 之中，非常简单不便。后者的话，咱们提供了 OpenTSDB 查问性能的齐全笼罩，然而有两点须要留神，一是不提供 OpenTSDB 的查问语法反对，二是不提供等效元数据查问反对。 之所以不提供 OpenTSDB 的语法反对，起因总结起来次要在于三点： 首先，围绕上图 OpenTSDB 的一个查问表达式来看，整体语义绝对比较复杂，且查问语法表意能力弱，无奈应用其映射出残缺的查问能力。同时这套语法规定也不太合乎应用 SQL 的习惯，无奈满足一些非常复杂的利用查问，比方对于下方的 SQL 语句的查问：这是一个 from 词句的非相干查问，通过 Json 这种形式是没有方法表达出来的。 SELECT id, SUM(avg_conn)FROM ( SELECT AVG(connection) as avg_conn, id FROM t1 INTERVAL(10s) GROUP BY id)GROUP BY id其次，相比于 OpenTSDB，TDengine 提供的查问性能、聚合函数更加丰盛，还提供如 TWA、TRATE、LEASTSQUARES、TOP、BOTTOM、LAST_ROW 等，如果要匹配其查问语法的话，就不可能残缺地去应用 TDengine 所提供的所有查问性能了。第三，OpenTSDB 还在查问过程中提供了一种特地的插值机制，导致 TDengine 很难提供完全一致的查问后果。 ...

2021 年邻近年末之期，涛思数据的荣誉墙上再添两个重量级奖项，这也成为新收到的最夺目的“新年礼物”。 涛思数据荣登 2021 AIoT 新维奖·企业榜·行业先锋榜在数字化时代，物联网无疑曾经成为企业转型降级的技术底座，各行各业都在借助 AIoT、云计算、大数据等技术进行业务翻新，甚至是商业模式转变，在摸索中寻找新机遇。 2021 年 12 月 9 日，在由挚物 AIoT 产业研究院联结物联网智库举办的“智微见著·踏‘物’寻‘机’|2021 中国 AIoT 产业年会”上，凭借技术实力、行业影响力和发展潜力等综合实力，涛思数据荣登“2021AIoT 新维奖·企业榜·行业先锋榜”，同时入选全新升级版的《2022 中国 AIoT 产业全景图谱报告》。 在 2021 年初，涛思数据就在由物联网智库与云和资本联结主办的“拨迷见物·2020 AIoT 产业年初盛典”上荣登了企业新锐榜，并入选了物联网智库与挚物·AIoT 产业研究院联结重磅公布的《2021 中国 AIoT 产业全景图谱报告》。 从 2020 到 2021，物联网行业的科技翻新一直，而涛思数据始终也没有“落伍”，和泛滥获奖企业一起，以本身的技术创新推动着整个物联网行业的倒退。 “守业邦 100 将来独角兽”榜上有名12 月 16-17 日，守业邦 100 将来独角兽峰会暨 2021 守业邦年会在上海举办，并于现场公布了“2021 守业邦 100 将来独角兽榜单”，作为极具后劲的科技翻新企业，涛思数据从 700 多家企业中怀才不遇，胜利入榜。 “2021 守业邦 100 将来独角兽”聚焦于寻找成立工夫在 10 年内，估值在 1 亿~10 亿美金，正处于高速成长阶段，将来极有可能晋升为独角兽行列的企业。守业邦官方消息显示，该榜单通过长达近 2 个月的征集报名，经由数百家投资机构的举荐，最终有超过 700 家企业提交报名信息。 从翻新实际、成长速度、融资能力、治理团队和发展前景五大评比维度登程，涛思数据凭借着本身弱小的技术创新、实力强悍的团队成员、资本市场的鼎力青眼、用户数量的飞速增长，从参赛群雄中怀才不遇，胜利斩获“守业邦 100 将来独角兽”荣誉称号，成为无望扭转将来产业格局的革新者之一。 ...

作者：曲春辉，负责工业数字化平台架构 小 T 导读： 作为全球性的电气产品和服务经销商，蓝格赛于 2000 年进驻中国市场，始终致力于帮忙中国更无效地应用能源。通过 20 年的一直壮大，现在蓝格赛在中国国内电气产品和服务经销商中曾经成为重要的市场参与者之一，通过 6 家业务实体、全国 53 个销售网点服务工业、商业及楼宇客户，为它们提供多样化的工业自动化产品及解决方案。本次我的项目为某市政供水水厂的数字化我的项目，数据来源于包含水泵、阀门、电表、液位计、流量计等多种设施近 6000 测点。该平台须要实现以下性能：数据秒级采集，历史数据留存 3 年，为下层利用提供数据撑持，包含所有测点的刹时数据、聚合剖析、数据报表等。值得注意的是，在本我的项目中聚合查问的应用场景十分的多，页面上图表不管大小有上百张之多，因而聚合查问的实现也是本我的项目的要害之处。 依据本我的项目特点，从整体架构的具体实现成果登程，咱们对存储技术提出了很高的要求，甚至能够说，存储技术的抉择会间接影响我的项目后续的推动乃至成败，这是一个决定平台“脊梁”硬不硬的组件。思考到这一问题，团队在技术选型上着实破费了一些功夫，本次选型也绝对更加谨慎。 在选型过程中咱们共调研了 20 多个开源存储技术，从开源组织、受权协定、数据模型、社区成熟度、开发语言、组件依赖、性能、稳定性、聚合敌对、操作系统、集群撑持、正本策略等多个角度进行了比照，最终抉择了 TDengine 作为海量数据存储引擎。 一、从 7 个长处看抉择 TDengine 的起因事实上，咱们最后抉择的是单纯以 InfluxDB 作为本次我的项目的外围存储组件，不过这一构想在进行技术验证时却发现难以持续推动。 次要起因是在技术验证的过程中，咱们发现了 InfluxDB 存在的几个问题，其中最重要的两个是： 首先，社区版本仅反对单节点。这个能够说是 InfluxDB 十分不敌对的一个点了，少数我的项目采纳的都是集群设计方案，如果数据只能在其中一个节点上存储，节约其余节点存储空间不说，一旦所在节点呈现故障，对整个我的项目的影响是劫难级的。其次，随着数据量及存储时长的晋升，InfluxDB 的聚合性能呈现了微小的瓶颈，咱们在理论测试的时候，模仿了百万测点近 1 年的数据，当聚合申请比拟多的时候，基本上就很慢了，这点也对本我的项目影响很大。因为以上两个问题的存在，从架构实现的角度来讲，咱们必须对存储技术进行从新抉择。恰好此时 TDengine 也凋谢了集群版本，偶尔的契机下又听到了陶老师对于时序数据的特点总结，感觉钻研的十分深刻，总结的也很全面。 后经与团队沟通，在技术选型调研时就一并把 TDengine 蕴含在了调研范畴之内。简略尝试之后，咱们发现 TDengine 的数据模型真的非常适合工业场景，总结来说有以下几个长处。 长处： 社区版本反对集群： 能够比拟好的利用集群的存储空间，数据也能够分散开来。聚合性能优越： 因为 TDengine 的数据模型特定及对集群的撑持，在模仿测试过程中，基本上没有遇到聚合瓶颈。随着数据量的减少及存储时长的缩短，聚合性能也十分稳固。简略易用： 在工业场景中，组件低耦合是很必要的，TDengine 开箱即用的个性很“香”，学习成本低，上手疾速。数据模型优良： 在工业场景中，设施及测点的增减十分的广泛，TDengine 的超级表及子表的概念很好地解决了这个问题，单列模式的场景对本我的项目来说十分敌对。查问语义具备普适性： TDengine 的查问语句与 InfluxDB 十分靠近，这点也十分好。版本升级简略： 卸载原有版本，装置新版本即可，无需数据迁徙。社区反对： 一般的问题基本上都能够在 issue 上失去回答，遇到紧急问题的时候，涛思数据的共事甚至能够亲自近程解决，为他们点赞，在应用的时候释怀不少。二、10 个看板页面，近百个聚合申请选型确定之后，咱们就正式开始了搭建。搭载 TDengine 之后的架构图如下所示： 采纳该计划的很大一部分起因是 InfluxDB 和 TDengine 在查问语义上的人造一致性。咱们为 TDengine 外层包装了一层 SDK，对应用层凋谢 SDK，使应用层对存储技术无感，在 SDK 外部通过查问的时间跨度、组件衰弱水平等多个因素主动抉择查问引擎，这样能够保障其中一个技术在呈现问题的时候，另一个技术随时顶上来，大大降低了因为技术稳定性所带来的危险。 ...

小T导读： 为进一步晋升TDengine本身的监控和运维能力，涛思数据开发了TDinsight，这是基于Grafana的一个零依赖监控解决方案，可配合TDengine 2.3.3.0及以上版本应用。作为根底组件，TDengine自身的安稳运行至关重要，所以在理论利用过程中，咱们也须要监控它的各项运行指标。 TDengine启动后，会主动创立一个监测数据库log，并主动将服务器的CPU、内存、硬盘空间、带宽、申请数、磁盘读写速度、慢查问等信息定时写入该数据库。 TDengine还会将重要的零碎操作（比方登录、创立、删除数据库等）日志以及各种谬误报警信息记录下来寄存在log库中。系统管理员能够通过命令行间接查看这个数据库，也能够通过Web以图形化界面查看这些监测信息。这些监测信息的采集缺省是关上的，但能够批改配置文件里的选项monitor来管制。 为进一步晋升TDengine本身的监控和运维能力，涛思数据开发了TDinsight，这是基于Grafana的一个零依赖监控解决方案。TDinsight能够配合TDengine 2.3.3.0及以上版本应用。 TDinsight提供了丰盛的监控选项，其残缺的界面视图如下： TDinsight仪表盘旨在提供TDengine相干资源（如DNodes、MNodes和VNodes）的应用状况，或数据库的应用状况及状态。咱们顺次来看一下。 1、集群状态（Cluster Status） 这部分包含集群以后信息和状态，告警信息也在此处（从左到右，从上到下）。在这里能够看到集群的状况、数据库个数、以后连接数，像DNodes/MNodes/VGroups/VNodes之类每种资源的总数和存活数等。 2、DNodes概览（DNodes Overview） 在这里能够看到DNode的生命周期、数量变动等信息，如果有任何DNode的状态为离线，则还会显示离线的起因。 3、MNodes概览（MNodes Overview） 能够查看MNode的状态和数量等信息。 4、申请（Requests） 能够查看插入申请数、插入记录数随工夫的变动状况，均匀每秒插入次数，查问申请数及变化率（count of second），以及HTTP申请数和申请速率（count of second）。 5、数据库（Database） 数据库应用状况，对变量 $database 的每个值即每个数据库进行反复多行展现，具体包含超级表数量、所有表数量、所有超级表子表的数量、所有一般表数量随工夫变动图以及每个VGroups蕴含的表数量。 6、DNode 资源应用状况（DNode Usage） 数据节点资源应用状况展现，对变量 $fqdn 即每个数据节点进行反复多行展现，具体包含：从创立DNode开始通过的工夫、以后DNode是否为MNode、CPU核数、以后DNode的VNode数量、处于master角色的VNode数量、taosd过程的CPU使用率、taosd过程的内存应用状况、taosd数据目录的总磁盘应用百分比、过程和零碎CPU使用率、磁盘IO速率和网络IO等。此外还有登录历史（Login History）信息。 TDinsight的装置部署非常简单，为不便用户，咱们提供了一个自动化脚本 TDinsight.sh 。更多应用细节，能够参考相干文档。 快来下载试用吧！

作者：喻东 东莞中融数字 小 T 导读：当下我国养殖企业广泛采纳传统塑料耳标+人工定期剖析+兽医现场诊断来做家畜异样预防，尽管市面上有固定摄像头、滑轨追踪摄像头、电信 NB 卡等计划，但这种形式依旧会存在家畜辨认谬误、高提早等问题，无奈做到实时监控每一头家畜。基于此，咱们利用新兴技术打造了家畜“特色采集+AI 剖析”的 AIoT 平台，来实现家畜异样的早发现、早报警、早预防。具体场景如下：应用 APP 提前录入采集器编号，再将采集器固定在家畜身上（耳朵、颈部、腿部等），采集器每分钟会采集 20 次特色数据，采集数据品种包含温度、流汗状况、经纬度、静止、脉搏、环境温湿度等。将采集到的数据进行边缘计算，再将汇总后果通过 4G 网络发送至云端服务器，之后云端会依据经纬度等要求获取到所对应的天气、风量等变量，联合采集器数据，AI 会综合评估出家畜以后的衰弱状况，例如是否有食欲不振、瘫坐不动、发烧趋势等。 一、 架构和具体实现与传统物联网我的项目一样，本平台对数据的写入性能有较高的要求，同时也有肯定的聚合查问需要，具体操作上写多读少，是典型的高并发写入场景。咱们之前采纳的是 MongoDB 的计划，还做了月份分表，然而进行聚合查问的效率并不高，而且也不便当，之后咱们又尝试引入 Cassandra，但应用上仍旧不够便当。 偶尔的机会下，咱们理解到 InfluxDB 和 TDengine，在搭建测试环境后对两者别离进行了测试，最终敲定 TDengine。除了两者间接的性能差距外，TDengine 提供的表数据 TTL 机制、数据压缩、流式计算等性能也让咱们更加青眼于它。 基于超级表的设计原理，咱们将家畜的业务关联信息作为 tag，不便关联 MySQL，同时一个采集器就作为一个子表存在，采集器测点作为子表的列。 表构造别离如下图所示：图一为家畜所佩戴的采集器表，也能够认为是家畜表，其与采集器一一绑定，图二与图三则为装置在养殖场固定地位的环境温湿度表，此外还有存储原始报文数据的表等，就不在此一一列举了。 图 1 图 2 图 3 目前我司的所有物联网数据表都是基于 TDengine 超级表设计的，针对外围的家畜超级表，其关联的 tag 会比其余表更多一些。须要留神的是，为了保障 TDengine 中 tag 与 MySQL 统一，每当业务中批改了家畜的根本属性，也须要同步执行 tag 批改操作。 这种表设计不便咱们追溯可能呈现的解决延时等问题，表中的 collect_time 为采集工夫，insert_time 为数据落盘工夫，如果两者的时间差较大，则可能就呈现了网络差、采集器故障、服务端吞吐量不够等问题，此时就须要排查下起因了。 家畜数据采集到数据落盘的全流程如下图所示，通过采集器采集到的数据通过 4G 网络上报，由设施网关初步解决数据并推送至 MQ，晋升吞吐量，之后传输给消费者，最终落盘到 TDengine。 二、数据迁徙和实际效果因为咱们之前应用的是其余数据库，更换新的数据库时会产生数据迁徙的操作，具体迁徙步骤如下： 新产生的采集器数据别离写入 MongoDB 和 TDengine，即一份数据写两份，旧数据查 MongoDB，新数据查 TDengine，以便呈现问题后能及时解救；逐渐将历史数据格式化导入到 TDengine；AI 剖析的数据源由 MySQL 数仓改为 TDengine。在迁徙过程中咱们也遇到了一些小问题，次要有两点： ...

作者：刘健 同心源（三亚）基金 小 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的主动交易至今。着重致力于通过数据挖掘、主动模式识别等形式在国内二级市场中进行主动量化交易。 近期taosAdapter已正式公布，反对从OpenTSDB等时序数据库向TDengine无缝迁徙，欢送浏览TDengine此前公布的技术文章，理解体验taosAdapter！

作者：宁龙 华自科技 小 T 导读：华自科技专一于自动化、信息化和智能化技术，为能源、环保、工业管制、水利等畛域用户提供外围软硬件产品与零碎解决方案，是多能物联技术领航企业。公司在电站及泵站自动化管制设施市场占有率寰球当先，是联合国工业倒退组织国内小水电核心管制设施制作基地。物联网数据平台是电站及泵站智慧运维平台的外围组成，其整体架构如下： 物联网数据平台的数据起源次要为电站、水厂、储能站，通过数据网关，将各场站端的设施运行数据传输至云平台的音讯队列（MQ）中，数据处理服务订阅MQ的音讯，依据设定的规定引擎，进行实时数据处理，之后将数据存储落盘。数据服务API则依据业务需要提供蕴含实时数据和历史数据在内的数据API。 一、现状及痛点对于历史数据，目前咱们采纳的MySQL分库分表计划来存储；实时数据会存储在Redis中。在测点数较少或者集控需要不是很多的场景下，根本满足需要。 历史数据历史数据用MySQL存储，一个站点对应一个数据库；一个测点对应一张表，建表语句大抵如下： CREATE TABLE `yc_测点id` ( `ts` datetime NOT NULL, `val` double NOT NULL);实时数据实时数据缓存到Redis中，以测点Id为key，同时缓存数据上报的工夫、测量值和品质值等信息。 数据计算查问咱们利用MySQL的各种函数、多表连贯、应用程序内存计算等形式，计算出后果返回给前端，对于月、年等报表类的计算，则采纳定时工作生成。 痛点随着平台业务的倒退，接入的站点越来越多，或者单站的测点数越来越多，问题逐步凸显进去了。具体能够演绎为如下几个方面： 运维难对于新接入的站点，首先得为这个站建设好数据库、数据表，减少了接站的工作量；因为一个站对应着一个数据库，随着平台接入的站点越来越多，数据库一直减少，数据库的治理和备份老本一直进步；随着测点的减少，缓存实时数据的单机Redis迟早有一天会撑不住，须要思考保护Redis集群。开发难随着平台的业务倒退，越来越多的站被接入平台，集控需要(跨站聚合剖析需要)减少，跨库跨表的查问操作越来越多，这就减少了零碎开发的难度，重大影响了零碎响应速度和稳定性。 老本高老本次要有两个方面，一个是人力老本高，因为开发、运维的难度减少，造成员工工作量减少，工作效率变低，从企业经营角度看，人力老本变高；另一个是硬件资源老本高，因为服务节点泛滥，占用的主机、内存和磁盘空间也会很多，购买或租用这些硬件资源须要收入更多费用。 二、技术选型为了解决目前这些问题，咱们决定从新进行技术选型，寻找代替计划，降级目前数据库存储计划。联合平台理论须要，咱们确定了几个选型要求： 业务改变小：尽可能减少对现有业务的影响；开源收费：必须是开源的，并且容许收费商用，最好也有商业版；迭代更新：社区沉闷，一直在迭代更新和公布新版本；性能高：单机能反对每秒10万以上的插入效率；开销低：服务节点少，占用的内存、CPU和磁盘空间少；反对集群：可能集群部署，容量可程度扩大；装置保护简略: 数据量较小的状况下，反对单机部署，并且占用资源较少；咱们理解了多款典型的时序数据库产品，最终InfluxDB、庚顿、麦杰、TimescaleDB、TDengine这几款进入了咱们的考查范畴。上面咱们来具体看一下： 1. InfluxDB在开源时序数据库畛域长期霸榜，社区沉闷，生态也比拟丰盛，性能也算中规中距，惟一的缺点就是集群模块不开源。 2. 庚顿、麦杰 两者都是传统老牌工业畛域的时序数据库王者，性能、性能都十分不错，惟一的毛病就是不开源，只有商业版，而且价格昂贵。 3. TimescaleDB 它是在PostgreSQL之上开发的一个插件，是基于关系数据库的时序数据库，对于咱们现有的业务应用简直无感知，下层能够持续用MyBatis、JPA等ORM框架，但它不是一个纯正的时序数据库；另外，它对集群反对不好，不反对程度扩大。 4. TDengine 反对应用类SQL查询语言来插入或查问数据，内嵌音讯队列和缓存机制、无历史数据与实时数据之分、分布式架构，反对线性扩大、反对多正本，无单点故障。看到官网的这些介绍，霎时感觉TDengine就是为咱们筹备的，于是马上做了各种验证，结果表明，TDengine齐全符号咱们的选型要求。 为什么没有采纳传统Hadoop生态提到大数据，人们可能第一反馈就会想到Hadopp生态。因而咱们后期也考查过腾讯云的TBDS数据套件。说实话那一套货色真的是太轻便了，Hadoop、HBase、HDFS、ZooKeeper、Hive、Spark\Flink这系列的货色搞下来，还真不是个别团队能玩得转的，另外我司的业务场景不止云端服务，还有可能会私有化部署在站内，硬件条件可能也就是一两台情况个别的服务器。 三、TDengine存储模型设计因为TDengine能够设置将最新一条数据存储在内存中，因而咱们利用这个个性替换掉了用Redis存储实时数据这个环节，改成实时数据间接查问TDengine。 TDengine里有超级表的概念，每种设施对应一个超级表。这个超级表只负责存储这种类型的设施数据，数据存储采纳横表存储。然而，这显然不合乎咱们的场景，因为在咱们的场景里没有固定的某一设施对象，且每个测点的频率都可能不统一。 同时为了尽可能减少对现有业务的影响，咱们将超表设计成如下构造： CREATE STABLE IF NOT EXISTS stb_站点id ( ts timestamp, val double ) TAGS (测id nchar(64))TDengine的子表，能够在插入数据时动态创建，这是TDengine的一个很好用的性能。这样能省去创立子表的业务环节，升高了业务复杂度。子表构造如下： insert into 测点类型_测点id USING stb_站点id (测点id) VALUES ( ts, val,q) eg: insert into yc_15143115161750995367 USING stb_站点id ('15143115161750995367') VALUES ( ts, val,q)四、应用到的TDengine个性缓存（Cache）咱们间接应用TDengine提供的缓存（Cache）性能，替换了原有零碎中的Redis。创立数据库间接开启cachelast=1，将每张表的最初一条记录缓存，应用程序通过last_row函数疾速获取实时数据。 ...

在上一篇文章中，咱们介绍了运维监控场景下，如何从OpenTSDB迁徙到TDengine。 如果利用特地简单，或者应用领域并不是运维监控场景，本文将更加全面深刻地介绍将OpenTSDB利用迁徙到TDengine的高级话题。 其余场景的迁徙评估与策略1、TDengine 与 OpenTSDB 的差别本节将具体介绍OpenTSDB与TDengine在零碎性能层面上存在的差别。 读完本节之后，你能够全面地评估是否能将某些基于OpenTSDB的简单利用迁徙到TDengine上，以及迁徙之后应该留神的问题。 TDengine以后只反对Grafana的可视化看板出现，所以如果利用中应用的是其余看板（例如TSDash、Status Wolf等），那么临时无奈间接迁徙到TDengine，须要将其从新适配到Grafana才能够失常运行。 截止到2.3.0.x 版本，TDengine只可能反对collectd和StatsD作为数据收集汇聚软件，当然前面会陆续提供更多的数据收集聚合软件的接入反对。如果收集端应用了其余类型的数据汇聚器，则须要适配到这两个数据汇聚端系统，能力失常写入。除了上述两个数据汇聚端软件协定以外，TDengine还反对通过 InfluxDB的行协定和OpenTSDB的数据写入协定、Json格局将数据间接写入，能够重写数据推送端的逻辑，应用TDengine反对的行协定来写入数据。 此外，如果利用中应用了OpenTSDB的以下个性，在迁徙之前还须要理解以下注意事项： /api/stats：如果利用中应用了该项个性来监控OpenTSDB的服务状态，并在利用中建设了相干的逻辑来联动解决，那么这部分状态读取和获取的逻辑须要从新适配到TDengine。TDengine提供了全新的解决集群状态监控机制，来满足利用对其进行的监控和保护的需要。/api/tree：如果依赖于OpenTSDB的该项个性来进行工夫线的层级化组织和保护，那么便无奈将其间接迁徙至TDengine。TDengine采纳了数据库->超级表->子表这样的层级来组织和保护工夫线，归属于同一个超级表的所有的工夫线在零碎中同一个层级，然而能够通过不同标签值的非凡结构来模仿应用逻辑上的多级构造。Rollup And PreAggregates：采纳了Rollup和PreAggregates，须要利用来决定在适合的中央拜访Rollup的后果，在某些场景下又要拜访原始的后果，这种构造的不透明性让利用解决逻辑变得极为简单而且齐全不具备移植性。咱们认为这种策略是时序数据库无奈提供高性能聚合状况下的斗争与折中。TDengine暂不反对多个工夫线的主动降采样和（时间段范畴的）预聚合，因为 其领有的高性能查询处理逻辑，即便不依赖于Rollup 和 （时间段）预聚合计算结果，也可能提供很高性能的查问响应，而且让你的利用查询处理逻辑更加简略。Rate: TDengine提供了两个计算数值变化率的函数，别离是Derivative（其计算结果与InfluxDB的Derivative行为统一）和IRate（其计算结果与Prometheus中的IRate函数计算结果统一）。然而这两个函数的计算结果与 Rate 有轻微的差异，但整体上性能更弱小。此外，OpenTSDB提供的所有计算函数，TDengine 均有对应的查问函数反对，并且TDengine的查问函数性能远超过OpenTSDB反对的查问函数，能够极大地简化利用解决逻辑。通过下面的介绍，置信你应该可能理解OpenTSDB迁徙到TDengine带来的变动，这些信息也有助于你正确地判断是否能够承受将利用迁徙到TDengine之上，体验TDengine提供的弱小的时序数据处理能力和便捷的应用体验。 2、迁徙策略首先将基于OpenTSDB的零碎进行迁徙波及到的数据模式设计、零碎规模估算、数据写入端革新，进行数据分流、利用适配工作；之后将两个零碎并行运行一段时间，再将历史数据迁徙到 TDengine 中。当然如果你的利用中有局部性能强依赖于上述OpenTSDB个性，同时又不心愿停止使用，能够思考放弃原有的OpenTSDB零碎运行，同时启动 TDengine来提供次要的服务。 数据模型设计一方面，TDengine 要求其入库的数据具备严格的模式定义。另一方面，TDengine 的数据模型绝对于 OpenTSDB 来说又更加丰盛，多值模型可能兼容全副的单值模型的建设需要。 当初让咱们假如一个运维监控场景，咱们应用了collectd收集设施的根底度量（metrics），蕴含了 memory、swap和disk 等几个度量，其在 OpenTSDB 中的模式如下： TDengine要求存储的数据具备数据模式，即写入数据之前需创立超级表并指定超级表的模式。对于数据模式的建设，有两种形式来实现此项工作： 1）充分利用TDengine对OpenTSDB的数据原生写入的反对，调用TDengine提供的API将（文本行或 JSON 格局）数据写入，并自动化地建设单值模型。采纳这种形式不须要对数据写入利用进行较大的调整，也不须要对写入的数据格式进行转换。 在C语言层面，TDengine提供了taos_insert_lines来间接写入OpenTSDB格局的数据（在2.3.x 版本中该函数对应的是 taos_schemaless_insert ）。其代码参考示例请参见安装包目录下示例代码 schemaless.c。 2）在充沛了解TDengine数据模型的根底上，联合生成数据的特点，手动建设OpenTSDB到TDengine的数据模型调整的映射关系。TDengine可能反对多值模型和单值模型，思考到OpenTSDB均为单值映射模型，这里举荐应用单值模型在TDengine中进行建模。 单值模型具体步骤如下：将度量（metrics）的名称作为 TDengine 超级表的名称，该超级表建成后具备两个根底的数据列—工夫戳（timestamp）和值（value），超级表的标签等效于 度量 的标签信息，标签数量等同于度量 的标签的数量。子表的表名采纳具备固定规定的形式进行命名：metric + '_' + tags1_value + '_' + tag2_value + '_' + tag3_value ...作为子表名称。 在TDengine中建设3个超级表: ...

OpenTSDB是一个经典的时序数据库系统，它没有开发本人的存储引擎，而是基于HBase，对于曾经有HBase根底服务的企业而言，升高了门槛。而且得益于其先发劣势，OpenTSDB在运维监控畛域有不少利用。不过也因为要依赖HBase，零碎的性能、压缩效率逐步成为瓶颈。随着业务零碎规模的扩充，部署老本、运行效率等方面的问题日益严重。此外，OpenTSDB的性能降级也比拟迟缓。 与之相比，TDengine有着显著的劣势： 数据写入和查问的性能远超OpenTSDB；针对时序数据的高效压缩机制，压缩后在磁盘上的存储空间不到OpenTSDB的1/5；装置部署非常简单，繁多安装包实现装置部署，除了taosAdapter须要依赖Go运行环境外，不依赖其余第三方软件，整个装置部署十分迅速;提供的内建函数笼罩OpenTSDB反对的全副查问函数，还反对更多的时序数据查问函数、标量函数及聚合函数，反对多种工夫窗口聚合、连贯查问、表达式运算、多种分组聚合、用户定义排序、以及用户定义函数等高级查问性能。采纳类SQL的语法规定，更加简略易学，基本上没有学习老本。反对多达128个标签，标签总长度可达到16KB；除HTTP之外，还提供Java、Python、C、Rust、Go等多种语言的接口。如果咱们将本来运行在OpenTSDB上的利用迁徙到TDengine上，不仅能够无效升高计算和存储资源的占用、缩小部署服务器的规模，还可能极大缩小运行保护老本，让运维管理工作更简略、更轻松，大幅升高总领有老本。 本文将以“应用最典型并广泛应用的运维监控场景”来阐明，不必编写一行代码，如何将基于OpenTSDB的利用疾速、平安、牢靠地迁徙到TDengine之上。 1、典型运维监控利用场景一个典型的运维监控利用场景的零碎整体的架构如下图（图1）所示。 图1.运维监控场景典型架构 在该利用场景中，蕴含了部署在应用环境中负责收集机器度量（Metrics）、网络度量（Metrics）以及利用度量（Metrics）的Agent工具，汇聚Agent所收集信息的数据收集器，负责数据长久化存储和治理的零碎以及监控数据可视化工具（例如：Grafana等）。 其中，部署在利用节点的Agent负责向collectd/Statsd提供不同起源的运行指标，collectd/StatsD则负责将汇聚的数据推送到OpenTSDB集群零碎，而后应用Grafana将数据以可视化的形式出现进去。 2、迁徙服务TDengine装置部署首先是TDengine的装置，从官网上下载TDengine最新稳定版，解压缩后运行install.sh进行装置。各种安装包的应用帮忙可参考《TDengine多种安装包的装置和卸载》。留神，装置实现当前，不要立刻启动taosd服务，在正确配置实现参数当前再启动。 调整数据收集器配置在TDengine 2.3版本中，在后盾服务taosd启动后，一个叫taosAdapter的HTTP的服务也会主动启用。利用taosAdapter，可能兼容Influxdb的Line Protocol和OpenTSDB的telnet/Json写入协定，所以咱们能够将collectd和StatsD收集的数据间接推送到TDengine。 如果应用collectd，批改其默认地位在/etc/collectd/collectd.conf的配置文件，使其指向taosAdapter部署的节点IP地址和端口。假如taosAdapter的IP地址为192.168.1.130，端口为6046，配置如下： LoadPlugin write_tsdb<Plugin write_tsdb> <Node> Host "192.168.1.130" Port "6046" HostTags "status=production" StoreRates false AlwaysAppendDS false </Node></Plugin>这样collectd就能够通过taosAdapter将数据写入TDengine了。如果应用的是StatsD，能够相应地调整配置文件。 调整看板（Dashborad）零碎在数据可能失常写入TDengine后，能够调整适配Grafana，将写入TDengine的数据可视化出现进去。在TDengine的装置目录下有为Grafana提供的连贯插件（connector/grafanaplugin）。应用很简略：首先将grafanaplugin目录下的dist目录整体拷贝到Grafana的插件目录（默认地址为/var/lib/grafana/plugins/），而后重启Grafana，即可在Add Data Source菜单下看见TDengine数据源。 此外，TDengine还提供了两套默认的Dashboard模板，供用户疾速查看保留到TDengine库里的信息。只须要其导入到Grafana中并激活。 图2.导入Grafana模板 至此，咱们就实现了将OpenTSDB替换成为TDengine的迁徙工作。能够看到整个流程非常简单，不须要写代码，只须要调整某个配置文件。 3、迁徙后架构实现迁徙当前，此时的零碎整体的架构如下图（图3）所示，而整个过程中采集端、数据写入端、以及监控出现端均放弃了稳固，除了极少的配置调整外，不波及任何重要的更改和变动。 图3.迁徙实现后的零碎架构 OpenTSDB的次要利用场景就是运维监控，这种状况下咱们能够轻松实现向TDengine的迁徙，从而用上TDengine更加弱小的解决能力和查问性能。 在绝大多数运维监控场景中，如果领有一个小规模的OpenTSDB集群（3台及以下的节点）作为监控数据的存储端，依赖OpenTSDB所提供的数据存储和查问性能，那么能够平安地将其替换为TDengine，并节约更多的计算和存储资源。在等同计算资源配置状况下，单台TDengine即可实现3~5台OpenTSDB节点提供的服务能力。如果规模比拟大，那便须要采纳TDengine集群。 如果利用特地简单，或者应用领域并不是运维监控场景，你能够持续浏览下一篇文章，更加全面深刻地理解将OpenTSDB利用迁徙到TDengine的高级话题。 点击摸索taosAdapter！

为了构建更为残缺的物联网大数据处理生态，反对简略高效地从其余时序数据库迁徙到TDengine，咱们开发了taosAdapter。 TDengine是涛思数据专为物联网、车联网、工业互联网、IT运维等设计和优化的大数据平台。除外围的快10倍以上的时序数据库性能外，还提供缓存、数据订阅、流式计算等性能，最大水平缩小研发和运维的复杂度，且外围代码包含集群性能全副开源。自TDengine于2019年7月发表开源以来，在GitHub上曾经曾经取得十分踊跃的反馈，有17,300多人给了star,4,100多人fork了代码。越来越多的用户开始采纳TDengine。 taosAdapter是一个新的独立程序，能够蕴含在TDengine 2.3.0.0及以上版本中。taosAdapter的外围出发点是解决用户的痛点，升高迁徙老本。 在物联网和运维监控等畛域，有些用户还在应用传统解决方案或者比拟老的产品解决时序数据处理问题，比方OpenTSDB。OpenTSDB也是一款开源的分布式时序数据库，它没有本人的存储引擎，相干性能齐全基于HBase。因为产生工夫较早，所以很多运维监控项目选择了该零碎。 以顺丰科技为例，他们采纳了 OpenTSDB+HBase 作为大数据监控平台全量监控数据的存储计划。然而随着该平台接入的数据量越来越大，他们遇到了很多痛点，像零碎依赖多、应用老本高和性能不如意等。 具体而言： 依赖多，稳定性较差：大数据监控平台是底层的基础设施，在数据存储方面又要依赖 Kafka、Spark和HBase等大数据组件。这样数据处理链路就会很长，而数据链路越长，要保证系统的可靠性，挑战也就越大。如果监控零碎自身呈现问题，也就无从基于它来发现和定位业务零碎的问题了。应用老本高：监控数据的写入量十分大，而且为了追溯历史问题，他们须要将全量监控数据保留半年以上。数据存储老本居高不下。性能不能满足需要：OpenTSDB作为全量监控数据存储计划，在写入方面性能根本满足需要，然而在日常大跨度和高频次查问方面已无奈满足要求。为了解决这些痛点，过后顺丰科技的工程师们认为有必要对全量监控数据存储计划进行降级。他们调研了多款时序数据库产品，最终决定抉择 TDengine。之后他们基于TDengine对系统进行了革新。革新实现后，TDengine集群轻松扛住了全量监控数据写入，目前运行稳固。 这次革新带来的成果晋升十分亮眼：服务端物理机由21台降至3台，每日所需存储空间同等条件下仅为OpenTSDB+HBase的约 1/10，大大降低了硬件老本。在查问性能方面，在应用预计算函数状况下，查问p99都在0.7秒以内，曾经可能满足日常绝大部分查问需要；在做大跨度（6 个月）非预计算查问状况下，首次查问耗时在 10 秒左右，后续相似查问耗时会有大幅降落（2-3s）。 睿信物联网平台也遇到了相似问题，他们之前采纳OpenTSDB存储时序数据，性能上是可能满足需要的；然而因为OpenTSDB架构简单，体量过重，给开发测试、装置部署以及运维治理等工作带来了不小的麻烦，随着业务规模的倒退，问题愈发重大。同样在通过调研之后，他们也抉择了TDengine。在降级革新的过程中，他们须要保留历史数据，所以须要将历史数据从OpenTSDB迁徙到TDengine。为此他们还专门开发了一个数据迁徙工具，并进行了详尽的测试。 用户的需要就是产品演进的能源。TDengine的研发团队开始思考这个问题：既然很多用户都有这种迁徙需要，那是不是能够官网给出一个对立的解决方案呢？ taosAdapter就是咱们的答案。taosAdapter次要有以下性能： RESTful 接口兼容InfluxDB v1 write 接口兼容OpenTSDB JSON 和 Telnet 格局写入无缝连贯Telegraf、collectd、StatsD、Icinga、TCollector它可能兼容OpenTSDB的Telnet/JSON写入协定，对于运维监控类业务，用户能够将collectd和StatsD收集的数据通过taosAdapter间接推送到TDengine。在数据可能失常写入TDengine后，能够调整适配Grafana，将写入TDengine的数据以可视化形式出现进去。TDengine也为Grafana提供了连贯插件。如果要迁徙历史数据，涛思数据还开发了数据同步工具DataX的插件，可能帮忙用户将数据主动写入到TDengine中。用户无需批改任何一行代码，只须要改几个配置，即可无缝迁徙。 下一步，taosAdapter也将持续欠缺，反对从更多平台向TDengine迁徙。 点击链接，摸索taosAdaptor！

作者 | 尔悦采访嘉宾 | 谭雪峰 就在往年六月份，又一位社区 Contributor 胜利入职涛思数据，他的身份也从 TDengine 的社区贡献者转变为专职的研发人员。在身份变换的同时，他对于本身的成长和倒退、对于代码的品质和要求、对于开源的了解和融入都有了一个新的认知和晋升。 “你是怎么对待开源的？你感觉开源能带来什么?如何能力成为一名优良的 Contributor？参加开源我的项目，成为 Contributor 后能够取得什么？...... 带着这些问题，看看他眼中的答案是否和你所见略同。 抉择成为逆流而上的“逆行者”作为大连人的谭雪峰，从小到大根本都生存在大连这座海滨城市，大学毕业后，基于本身趣味登程便在家左近找了一份研发工作，如果没有成为 TDengine GitHub 开源社区的贡献者，或者他的生存和工作轨迹也不会这么快从大连转移到首都北京。在泛滥年轻人“逃离北上广”的大潮中，谭雪峰成为从他乡到北京逆流而上的“逆行者”之一。 从一个相熟的城市转移到另一个生疏的城市，这其实是一件说起来容易但做起来并不简略的事件，在这之前，95 年出世的谭雪峰能够说曾经在大连扎根了 26 年，贸然间从故乡抽身总会产生一些不适和纠结，但谭雪峰却并没有给本人太多的思考工夫，他很快就接下了涛思数据投来的橄榄枝。 “尽管始终呆在大连是离家近了，工作生存会更加劳碌平静，亲戚朋友之间也能有个呼应，但对于研发行业来说还是北京的大环境更好。”在“苟且生存”和“诗和远方”里谭雪峰一个都没选，他抉择了“将来和成长”，这是一条攀登的路，然而无疑将会看到更好的风光。 事实上，谭雪峰并非科班出身，他喜爱钻研逆向和平安，凭借着本身的酷爱他开始自学编程，毕业之后牵强附会成为了一位研发工程师。谭雪峰婉言，刚开始工作时因为本人根底打的不够牢固，在工作推动时困难重重，但他并没有因而退缩，通过吸取书本上的专业知识以及参加 GitHub 上的一些开源我的项目，来丰盛本人的业余实践和实战技能，同时这种学习形式也为他结识 TDengine 埋下了伏笔。 “此前我是在工业物联网行业，对各种时序数据库都理解一些，以便于更好地发展工作。国产的时序数据库还是比拟少的，其中能做到开源的就更少了，因而我始终都比拟关注开源，在这些开源数据库外面，TDengine 的性能是十分高的，过后就想将它引入到平台零碎中，这样一来二去就和涛思的人意识了。” 那谭雪峰为什么会退出到涛思数据？这其中还产生了哪些故事？ 业内人都晓得，涛思数据有很多学历背景弱小、业余能力突出的研发工程师，他们有的来自国内外出名大学，有的是研究生、博士生，还有一些人领有大厂研发背景，整体团队实力十分强劲。作为一个非科班出身的工程师，谭雪凭借着什么失去了涛思数据的青眼？ 与涛思数据结缘，从开源开始“我当初在涛思数据次要负责 TDengine 的利用研发和周边生态建设工作，说起来退出涛思数据的始末，除了工作上的单干加深彼此理解外，也和关注开源这件事有很间接的关系。” 据谭雪峰回顾，刚开始接触涛思数据其实还是因为本身工作的起因，为了实现开发工作理解了 TDengine 的源码，并为了能让其在 Windows 上应用通过 GCC 编译做了一些批改，他也因而成为 TDengine 的贡献者之一。 因为谭雪峰始终通过学习开源的代码来晋升能力，从反哺精力登程也就想做一些事件来回馈开源社区。 正好这时涛思数据举办了一场开源较量——做 TDengine 和 HiveMQ 的对接，作为 Contributor 的谭雪峰略经思考便进行了报名，还获得了一个不错的后果。“这是我第一次加入开源社区活动，展现本人的同时还可能回馈社区，也正是通过这次流动让我更加深刻地理解了涛思数据，萌发了想要退出的想法。” 进入涛思数据后的谭雪峰并没有给本人太多的适应工夫，就立即投入到工作中，他将整个 Go 连接器进行了重构，在此过程中对 CGO 有了更多地理解，但不可避免也遇到了一些问题。 “遇到比拟大的问题是 CGO 的调优下面，如果 C 的办法阻塞的话会独占线程，这样一来并发性就会显著升高，过后为了解决这个性能问题我看了不少的文章，然而相干调优办法也比拟少。之后在 Go 的 GitHub 开源社区上挖掘了一些能够借鉴的教训，最初综合了几个渠道获取到的计划一一做 benchmark 并选了其中比拟优的进行业务尝试。” ...

作者：惠州工业互联网研究院 小 T 导读：惠州市新一代工业互联网翻新研究院（以下简称研究院）成立于 2018 年 6 月，是以部省联动施行国家重点研发打算“宽带通信和新型网络”重点专项为契机，在广东省科技厅和惠州市政府的反对下成立，立足惠州、面向广东、辐射全国、联动国内的工业互联网省级科技翻新平台。为实现宿舍用电的智能化治理、保障学生用电的独立性和安全性，针对学校宿舍用电的免费，研究院打造的智慧用电管控零碎采纳一室一表一爱护的计划，为学生宿舍配置智能电能计量表计和用电爱护设施，对每个用户的用电进行独立计量和爱护。 这套零碎通过互联网采集所有终端的数据，再由通讯网关将数据通过无线组成的专用网络或局域网将数据传输至远程管理计算机。系统管理软件再对数据进行存储、解决，造成学校后勤管理方须要的图形、文字等模式的文件，以此实现整个学生宿舍用电的智能化治理。 在整个零碎的构建中，令咱们比拟头疼的是对于数据库的抉择，这套用电零碎会产生大量的时序数据，在达成根底的存储、压缩和查问性能需要外，还须要均衡搭建、学习和保护等各种老本。基于此，咱们开始进行数据库选型，以期找到最适宜该用电管控零碎的数据库产品。 从零碎架构进行数据库选型智慧用电管控零碎采纳工业互联网平台典型的端网边云零碎架构，通过物联零碎及网关解耦设施与利用平台，减速数据的聚合与凋谢，服务于智慧校园平安用电、用电缴费等场景，同时可反对智慧校园其余我的项目疾速接入须要。下图为具体的架构示意图： 为了找到适合的数据库产品，咱们先对整个零碎架构进行了剖析。 在整体架构中，该数据库的数据须要作为基础设施的数据存储，通过校园网络提供包含物联零碎在内的如下数据输入： 工业通信终端：高性能通信网关能同时接入多台水电气表及智慧爱护开关，反对多种工业协定，能同时解析不同类型设施数据，并能按自设置的上报频率上报数据到物联零碎服务器。物联零碎：包含设施模型治理、设施治理、项目管理、历史音讯治理、规定引擎等性能，能接入任意物联网类型设施，可反对智慧校园其余我的项目疾速接入须要。用电零碎：实时监测、抄表零碎、免费利用、能耗监测、平安治理、系统管理，所有宿舍能够按小时/天/月/季/年颗粒度查问用电量，电表电闸实时读数和开关状态查问，告警查问，宿管分权分域治理。免费零碎：实现学校公寓宿舍治理，依据校园阶梯计费的要求，实现学生阶梯计费拆帐算法，生成的帐单由校园宿舍管理人员确认后公布到免费零碎进行查问并缴费，学生缴费后生成缴费历史清单。大屏展现、Web 门户：通过数字大屏、Web 门户中的 Dashboard 面板，直观形象的进行数据展现。这一整套零碎产生的数据量之宏大可见一斑，除了存储外，各种查问操作也非常考验性能优劣，还须要可能疾速接入其余我的项目。通过对各种数据库进行剖析后，TDengine 这款时序数据库产品浮现在咱们眼前，它的很多个性十分合乎咱们整体架构的设计初衷，也可能完满匹配零碎的数据处理需要： 多样化的数据写入反对。校园网简单的零碎环境和网络环境进步了数据写入的多样性要求，TDengine 反对多种接口写入数据，包含 SQL、Prometheus、Telegraf、collectd、StatsD、EMQ MQTT Broker、HiveMQ Broker、CSV 文件等，不仅帮忙咱们实现了工业终端层的数据写入，而且局部其余零碎的集成数据也得以用更低的老本进行了施行。较低的学习老本。咱们的研发团队是做智慧校园零碎的，得益于 TDengine 运维不便、反对 SQL 等个性，整个团队仅用很低的装置、运维、应用方面的学习老本就实现了基于 TDengine 系统实施。TDengine 在整个构架最外围的时序场景的数据读写和压缩率方面，体现优异。智慧校园的工业物联设施的数据写入量，不管在品种、数据点、并发数量方面都有极高的要求，而且在大量数据的状况下，写入数据的压缩率也十分影响存储的老本。TDengine 满足了 3 万条/秒的写入速度，并且压缩率达到了惊人的 1/7 左右。TDengine 毫秒级别的数据查问、基于时间轴的滑动窗口聚合计算等个性，以及查问后果与 Grafana、BI 插件等快捷便当地集成，为最终的数据可视化提供了很好的反对。以上几点起因，让咱们动摇地抉择了 TDengine 作为智慧用电管控零碎的数据库产品，并开始施行搭建。基于 TDengine 的建库、建表思路作为一个专门为物联网结构化数据流设计的时序数据库，TDengine 的建库、建表思路与关系型数据库齐全不同，其遵循一个数据流隔离的准则。 物联网设施产生的数据是依照工夫程序产生的数据流，在校园智慧用电管控零碎零碎，咱们高频收集宿舍用电数据，一是用来统计每小时宿舍用电状况，二是用来判断宿舍大功率应用状况，及时收回大功率电器应用报警。 这种背景下，用诸如 SQL Server 的关系型数据库来存储时序数据时，做法通常是将所有同类设施的数据都建到同一张表中，每条记录会蕴含设施 ID、数据采集（或入库）工夫戳、采集到的值，并依照工夫范畴来分表提速。这种做法的弊病在于查问麻烦且低效，从关系型数据库中查问某一个设施的数据时，还须要通过设施 ID 把其余设施的数据从大表中过滤掉，且每查问一个设施，就要面临过滤其余设施数据的开销。 与关系型数据库不同，TDengine 的设计思路是一个数据源（设施）一张表，每个数据源依照工夫程序产生的音讯流能够流入一个表中，不与其余数据流混合。表的主键是数据记录采集或入库的工夫戳，其余字段是采集的值。这样在 TDengine 中查问某个设施的指定时间段数据时，查问就简化为找到该设施的表并依照主键（工夫戳）过滤搜寻数据记录，效率大幅晋升。 此外，在 TDengine 中，咱们为了方便管理设施，对不同设施模型创立了不同的超级表，比方电表模型是一个超级表，智能爱护开关是另一个超级表。 具体到咱们的场景中，建库、建表思路如下： 超级表超级表的构造非常简单，采集字段就是工夫戳 ts 和采集值 val。但此处定义了两个标签，用于形容具体的点位动态信息。 ...

作者：曲烟信息化小组 小 T 导读：作为云南中烟外围生产厂之一，曲靖卷烟厂基于中国制作 2025 的政策号召，不断完善的网络基础设施，梳理数据采集节点，丰盛数据采集伎俩，逐渐买通制丝、卷接、包装、成型、能源等卷烟生产及保障过程中相干设施与现场终端的局域互联，构建全面笼罩生产重要区域的数据采集网络，造成卷烟工厂《制作过程数据采集规范》，实现高效稳固的数据采集，为实现全面智能化制作奠定了数据根底。近年来，曲烟围绕工业数据的“取、存、管、用”四个方面，搭建工业大数据集群及数据共享服务中台，依靠两化交融、数据管理能力评估规范体系，发展工业数据采集、数据建模、数据利用、技术开发、数据安全及平台运维等钻研。 在数据“取、存、管、用”中，“存”为基石。卷烟工业数据具备时效性强、实时数据量大等特点。而随着业务的倒退，生产中须要监测的指标从几万个减少到几十万甚至百万个以上，曲烟过来应用的某国外时序数据库软件在性能和扩大能力上，越来越难以为继，在对生产设施进行产量、资料耗费、工艺效率等大数据量存储、统计分析、跨长时间段的查问操作时，消耗老本越来越高，无奈撑持起日益增长的业务、效率需要，“如何无效晋升时序数据存取效率”成为了挡在曲烟数字化转型路上的拦路虎。 为晋升数据存取效率、突破传统数据孤岛、晋升数据无效利用率，曲烟决定从以后市面上风行的时序数据库从新进行选型，具体的选型思考和实际成果将在下文中一一进行论述。 从原有时序数据库到 TDengine在进行数据库选型之前，咱们对以后曲烟生产设施进行了一些特点剖析。在多年倒退下，设施类型越来越繁多，不同设施的通信接口、采集协定、采集参数都各不相同，单个工厂的设施数量在几十到几千之间，单台设施的采集参数数量有上百之多，参数类型蕴含数值和文本两种，根本的采集频次要求每两秒采集一次，同时反对变动上报。由此可见，每天产生的数据量有如许宏大，在这种体量的数据量基数下，存储和查问等操作也会频频呈现问题。 此前曲烟应用的国外某时序数据库是一款非开源软件，其在软件应用上，写入速度满足需要，但查问速度却太慢，同时不足统计工具，数据统计效率较低。在软件运维层面，软件体量大，运维老本高；过于受限，永恒受权也不能自在批改数据点；反对 OPC DA 数据采集，但稳定性较差、安全性有余。 曲烟革新后的零碎须要反对的个性如下：1. 性能稳固2. 高效的数据写入3. 高效的数据查问，包含最新数据和历史数据4. 可云化部署5. 可私有化部署6. 线性扩大7. 高可用 在 TDengine 于 2019 年下半年刚推出第一个开源版本时，咱们就从开源社区理解到这个国产的高性能时序数据库，很快就开始进行测试试用，并持续保持着和涛思团队的技术交换。作为第一个吃螃蟹的烟草企业，咱们也综合考量了 TDengine 的业务场景匹配度、产品市场成熟度等因素。只管过后 TDengine 还是一款绝对比拟“年老”的时序数据库，市场份额也暂不如一些老牌工业库，但它的外围代码齐全开源，社区活跃度十分高。 在外部比照测试了 OpenTSDB、InfluxDB 等开源时序数据库后，咱们发现 TDengine 的综合体现最优。而涛思团队也在 2020 年公布了 TDengine 2.0 版本，将老牌工业库以及 InfluxDB 开源版不具备的分布式集群扩大能力也开源了，这也进一步减少了咱们采纳 TDengine 做烟厂规范时序引擎的信念。很快咱们的信息技术团队便基于卷包车间的数据采集存储需要，对 TDengine 又进行了一系列生产级别的测评，教训证后它的写入速度和查问速度都满足咱们的生产需要。 其中给咱们印象最粗浅的是，那时候 TDengine 的安装包大小才不到 5MB，竟能提供这么强劲的性能——10 亿级别的数据量做聚合计算只须要 2 秒，而在之前应用的国外某时序数据库中，对全量（有余 1 亿条记录）的均值计算须要 2-3 分钟。此外，TDengine 数据库内置工夫窗口主动宰割和统计机制，让前期报表数据统计更加快捷不便，而且这款软件上手应用很简略，通过命令行能间接以 SQL 语法进行交互，和 Grafana 也能够无缝对接。在排除了开发成本的疑虑后，咱们很快就应用 TDengine + Grafana 搭建起了卷包车间的数据存储和可视化平台。 目前，曲烟卷包、制丝车间均应用的是国产时序数据库 TDengine，逐步代替了之前应用的时序数据库。 ...

作者：必和必拓研发部 小T导读：湖南必和必拓科技倒退有限公司定位于智慧城市建设与行业信息化，以后聚焦智慧住建、智慧环保、智慧司法以及智能制作四大畛域，既蕴含各类电子产品装置施工及维保，也包含自有软件研发及部署。 随着业务规模的逐步扩充，传统数据库越来越难以满足某些业务场景对查问、剖析、统计的进一步需要。为了突破当下困局，湖南必和必拓想到了三种解决方案，在进行了谨严的剖析后，咱们决定采纳物联网数据库，通过选型比照，时序数据库TDengine成为其首选计划。 如何在TDengine上进行数据建模、集群搭建、告警模块搭建？如何将数据更平滑地迁徙到TDengine？在这些操作中，可能会遇到什么问题？又该如何解决？从湖南必和必拓的实践经验登程，本文将从代码层面一一解答。 业务场景及痛点在一些业务场景中，咱们须要将长沙市在建工地的扬尘数据(温度、湿度、pm2.5、pm10、pm100、噪声、风向、风速)存储在数据库中，以便为业务提供查问、剖析和统计的操作。 但近来呈现了一个难题，咱们共有监测点107个，每分钟上送1条数据，每年就预计有“1076024*365 = 56,239,200”条数据，也就是5600多万条。目前已存储两年的数据，数据量总计约1亿多条。这些数据始终都被存储在MySQL数据库中，宏大的数据量使得查问速度越发迟缓，甚至局部页面呈现超时问题。 解决方案1：MySQL数据库分库分表如果咱们将数据库扩散到不同的表上，单表的索引大小就失去了管制，对索引以及表构造的变更会变得更加不便和高效。当数据库实例的吞吐量达到性能的瓶颈时，咱们须要扩大数据库实例，让每个数据库实例承当其中一部分数据库的申请，合成总体的大申请量的压力。 弊病： 分库分表须要提前对数据做好布局。如果依照工夫对表进行程度划分，随着监控点减少，前面的表数据量可能越来越大，容易呈现数据热点问题；如果依照监测点hash取模对表进行程度划分，当监测点减少，进行扩大就会比拟艰难。例如：之前是mod4，前面是mod6，则须要对之前的历史数据从新进行解决。在对数据进行统计分析时，可能须要进行多表的聚合查问，查问速度会受到影响。解决方案2：应用华为云物联网平台华为云物联网基于物联网资产模型，整合物联网数据集成、荡涤、存储、剖析、可视化，为物联网数据开发者提供一站式服务，可能无效升高开发门槛，缩短开发周期，疾速实现物联网数据价值变现。 弊病：后期需设施厂商针对平台接口进行适配，接入当前零代码的形式的确在配置上会比拟不便，然而平台的费用以及实时流式计算按次免费的形式，整体费用过高。 解决方案3：应用物联网数据库InfluxDB：高性能的时序数据库，能够高效的存储和查问时序数据。惋惜的是，目前社区版集群性能不开源。TDengine：TDengine是一个简略快捷、高性能的时序数据库，提供高性能的同时也极大升高了装置、部署和保护的老本。利用之后，TDengine能解决之前令咱们较为头疼的一些问题，包含前文中形容的问题，它有以下5点次要劣势： 安装简单。下载rpm包，一个命令装置结束即可运行。数据库开源，反对集群。充分考虑时序数据的特点，以超级表为模型，将每个监测点的数据独自存储在一张表中，进步了插入和查问速度。有丰盛的函数，反对窗口查问和间断查问。自带TDengineAlert模块，和AlertManager联结应用，能够推送告警信息综合思考以上解决办法，咱们发现，应用TDengine后，硬件老本和开发保护老本大大降低，写入和查问速度比OpenTSDB等还要高出一个级别。于是，TDengine成为了咱们的首选解决方案。 接下来，我将把咱们在摸索TDengine时的一些重要操作、问题点以及解决办法等教训传递给大家。 对于TDengine装置官网下载安装包，文中应用的是2.0.20.12，即：TDengine-server-2.0.20.12-Linux-x64.tar.gz。安装包中蕴含装置命令, 解压后间接应用即可。 [root@hnbhbt ~]# tar -zxvf TDengine-server-2.0.20.12-Linux-x64.tar.gz[root@hnbhbt ~]# cd TDengine-server-2.0.20.12[root@hnbhbt ~]# ./install.sh1. 启动TDengine[root@hnbhbt ~]# systemctl start taosd2. 查看TDengine状态[root@hnbhbt ~]# systemctl status taosd3. 输出以下命令进入TDengine命令行taos呈现如下显示后示意进入胜利Welcome to the TDengine shell from Linux, Client Version:2.0.20.12Copyright (c) 2020 by TAOS Data, Inc. All rights reserved.taos>卸载: 须要手动删除配置文件以及日志[root@hnbhbt ~]# sudo rm -rf /var/log/taos/[root@hnbhbt ~]# sudo rm -rf /var/lib/taos/[root@hnbhbt ~]# sudo rm -rf /etc/taos/taos.cfg注: 装置过程中须要配置TDengine的FQDN为hostname，通过Linux命令能够查看以后机器的hostname，配置相应内容即可，官网倡议尽量不要应用localhost， 文中配置的是hnbhbt.com ...

作者｜吴明敏，深度（平潭）科技 小 T 导读：深度（平潭）科技有限公司是一家 IT 综合服务提供商，致力于以工业物联网、大数据、云计算、挪动互联为根底进行行业软件研发、解决方案集成及运行保护服务。公司精准把握信息化发展趋势，重点布局工业物联网、智能制作、智慧水务、智慧物流、智慧楼宇，借助新兴技术进行交融翻新，构架智能化、智慧化的信息服务撑持平台，推动中国新型工业化过程。由邯钢牵头的“十三五”水专项“钢铁行业水污染全过程控制技术系统集成与综合利用示范”课题中，咱们承当了“进步水循环利用的分质/分级供水技术、水系统优化和水网络智慧治理”的钻研工作，翻新开发了具备自主知识产权的“钢铁联结企业全过程节水减排专家管理系统智慧平台”。 该项目标初衷是让其可能在全国范畴内实用。然而，因为在此过程中会有海量数据产生，数据的实时写入成为一大难题。同时，多种剖析算法、预警报警条件、报警解决流程、运行日报、综合统计分析报表可云端动静配置、实时的动态分析计算和历史大量数据回测在线计算也是新的技术挑战。在此背景下，如果想要满足大数据采集计算需要，如何引入高效的分布式实时处理零碎，如何设计平台的计算框架，以及如何抉择合适的时序数据库是咱们必须要解决的问题。 在 2018 年开始施行这个我的项目时，可供咱们选型的产品并不多，基本上是工业现场的实时数据库和通用的业务型数据库。然而工业实时库扩大能力和数据安全达不到咱们的要求，配置上须要配合驱动，这就要求咱们要理解一些工业现场协定，老本绝对较高；如果应用如 MySQL 个别的通用数据库，随着监控点减少，依照工夫对表进行程度划分容易呈现数据热点问题，而依照监测点 hash 取模进行划分时，扩大又会变得比拟艰难。 起初，咱们也尝试了 Kafka+Strom+HDFS 这个组合，并且曾经实现开发，然而随着业务的一直倒退，在每天要解决将近一亿条数据的状况下：实时和历史数据的读取、开发优化、数据一致性、部署运维的老本都变得越来越高。 如何能力以低成本达成高性能？选型火烧眉毛针对以上业务场景和痛点，咱们决定更换数据计划、进行产品选型，并优先比照了物联网云平台和时序数据库。 选型数据量参考如下： 物联网云平台的长处是为可能数据开发者提供一站式服务，无效升高开发门槛、缩短开发周期，其毛病也十分显著，尽管说在接入当前零代码更加不便了配置，但后期设施厂商还须要针对平台接口进行适配就不是很敌对了，平台的费用加上实时流式计算按次免费的形式，老本霎时晋升。此外，在咱们的业务中，因为业主要求生产数据不离厂，离线部署老本高、运维难且现场设施多样协定繁多，还须要定制接口。 其次就是时序数据库，因为市面上产品种类泛滥，咱们就从本身的需要登程，对两款市面风行的时序数据库进行了相干调研，别离是 InfluxDB 和 TDengine。前者尽管市场占有率绝对较高，但十分惋惜其社区版集群性能并未开源，不能齐全满足咱们的业务需要。而 TDengine 只管绝对比拟“年老”，却可能保障在提供高性能的同时也极大升高装置、部署和保护的老本，此外它还具备如下特点：- 安装简单- 集群性能开源- 从时序数据的特点登程，设计了翻新的超级表概念- 具备丰盛的函数，还有反对窗口查问和间断查问等诸多劣势 通过认真测试和比照后，最终咱们决定将 TDengine 接入到水解决专业化运维零碎中进行前期革新，而 TDengine 也没有辜负咱们的冀望，帮忙咱们达成了降本增效的指标。 TDengine 中间性试验信息如下表所示： 面对海量数据，TDengine 能力如何？上面咱们一起来看一下 TDengine 在业务实际中的具体表现。 首先咱们依据业务类型，创立了 5 张超级表，数据量比拟大的两张表构造如下： 这两张表的数据量达到了 25 亿以上，加上其余超级表后总数据行数大略在 26 亿左右。 对超级表 hgengine 查问所有设施的最新状态值，TDengine 的耗时是 0.23s。这里不得不提一下，因为咱们是 2.0.7 的旧版本，距今曾经 1 年之久，很多函数都没有缓存之类的优化，所以性能和新版差距很大。然而因为我的项目稳固运行很久了，所以就始终都没有降级到最新版本体验，非常遗憾。 接下来咱们看一下存储，TDengine 在以上数据量之下（26 亿行），占用的磁盘空间其实只有 2.8G，而实际上入库的原数据大小应为（26 亿行，每行蕴含工夫戳列 8 字节以及 float 和 double 混搭大略 4.2 字节，总共 317 亿字节）30G 左右，TDengine 的列式存储压缩率能够达到惊人的 10%。 ...

作者：李军 ｜ 三禾一科技 公司介绍安徽三禾一信息科技有限公司（以下简称三禾一科技），业余从事大数据行业利用及工业互联网解决方案，致力于携手各行业客户独特发现产业新价值。目前，三禾一科技自研的3H1高端配备运维服务平台曾经胜利利用在高端配备制作、汽车制作、环保设施、色选机械、水泥行业等畛域。 业务场景高端成形配备是国家的战略性支柱产业，利用于汽车、石化、航空、航天、军工、工程机械、家用电器等国民经济倒退中的重要畛域，是许多重大工程的根底。以后，新一代信息技术的疾速倒退，使得高端成形配备制造业正处于由数字化、网络化向智能化倒退的重要阶段。 作为一个高端配备运维服务平台，3H1的底层物联网数据库要反对数百家企业、数十万设施的接入，此前始终采纳开源的InfluxDB，起因是在其单机版本根底上能够扩大多实例分库架构，但在应用过程中一些毛病也逐步裸露，如硬件老本较高、保护难度较大，不便于横向扩大。所幸起初遇到10倍高性能数据库TDengine，经屡次试验其各项指标均满足业务需要，便始终应用至今。 为什么抉择TDengine？在配备行业物联网场景下实时数据量微小，包含温度、压力、振动、位移等泛滥参数，针对这些参数如何进行剖析和预警都是难点。这些需要详情如下： 高并发数据写入，每条记录都须要带工夫戳；不同传感器设施须要记录的数据字段不同，心愿可能针对不同设施独自建表；原始数据存储要求在5年以上，须要反对数据压缩，以升高数据存储老本；反对国产化，反对数据库厂商服务疾速响应。选用TDengine社区版2.2.1.1进行分布式模仿试验，用到了3台配置如下的服务器： 测试一：验证时序数据库产品3台数据库节点时序数据写入性能模仿2个厂区共10个车间的数据、每个车间1000个监测点，每个监测点从2017-07-14 10:40:00.000开始写入模仿数据，记录时间戳距离0.001秒，每个测点写入500000条记录。8线程写入，在写入超过50亿条记录后进行了写入程序。本次测试对50亿条数据记录的写入，均匀写入速度达到191万条/秒。 测试二：验证时序数据库产品3台数据库节点时序数据压缩能力在测试一的根底上，查看3台数据库节点理论文件大小，如下： 落盘后所有文件大小为36GB，原始数据大小为5000000000*20/1024/1024/1024=93.13GB，压缩比为36/93.13=38.65%。 测试三：时序数据库产品3台数据库节点对历史时序数据按工夫回溯查问的性能随机抉择任一个测点，查问该测点在某个时间段内的历史数据，比方从2017-07-14 10:40:00.000 到 2017-07-14 10:40:10.000 10s内的共10001条数据记录（数据输入到文件）。数据库中对应查问语句为： select * from d0 where ts >= ‘2017-07-14 10:40:00.000’ and ts <= ’2017-07-14 10:40:10.000’ >> /dev/null; 通过试验证，TDengine的写入性能高、并发高、查问时延极短；整体集群采纳分布式架构，可靠性、稳定性、数据完整性满足我的项目需要。在选型后果确定之后，咱们便立即对原有业务零碎进行了降级革新，正式引入 TDengine。 TDengine在3H1上的落地实际3H1高端配备运维服务平台重点解决高端成形配备企业由制作化向服务化转型的关键问题，为企业提供工业互联网与智能运维的整体解决方案。 平台总体架构如图1所示，其中，TDengine与高端成形配备的智能数据采集终端模块相连，助力采集终端实现对设施运行数据的采集，为零碎提供设施数据根底；工业云计算服务平台提供零碎数据的存储、转换、剖析等，为零碎提供业务数据反对；智能运维服务零碎由配备智能运维服务平台和智能运维服务APP组成，别离为企业人员提供零碎和挪动端的服务反对。 针对企业多种利用场景，零碎应用服务共分为六大功能模块。 （1）企业驾驶舱：次要是服务于设施制作企业的管理者，不便理解平台数据状况与要害业务流程的指标，从整体界面上能够很不便的理解到设施的售卖状况，企业接入的信息，平台数据的采集状况。同时还能够对一些要害的业务流程，包含企业设施的监控、报警信息的展现、培修效率的治理、设施的故障状况和三包工作的信息进行追踪与治理，如图2所示。 （2）设施资源管理：次要的目标是为了给每一个高端成形配备建设电子档案，以便理解设施历史、当前情况，优化设施运行，预测设施将来情况，查看具体的设施信息时次要展现设施的四个维度——以后工况、衰弱剖析、培修状况和历史工况。 图3所示的以后工况不便用户理解设施的根本信息、要害指标和报警状况，还可能提供设施当前情况的总览。图4所示为衰弱剖析，其目标则是让设施用户更加深刻地理解设施的当前状况、设施的健康状况随着工夫的变动状况，如果设施以后面临故障危险，也能疾速查找到引起危险的故障起因以及故障模块。培修状况则是给了用户设施培修信息的总览和以后培修工作的流程跟踪，如图5所示。历史工况则是为了进行故障模块预排查，如图6所示。 （3）维修服务治理：次要提供给维修服务部门人员所培修工作以后和历史的效率剖析。培修工作展现以后待处理的工作数量，比方待接单、待派单和待回访，同时还能够对每个培修工作进行查看和操作，查看的内容具体到培修流程的每一个环节，如图7所示。 培修效率剖析则是对培修中的要害效率指标进行统计分析、近一年来的订单量的变动状况、培修响应工夫变动状况、故障类型散布、培修人员工作统计，不便培修管理人员对维修服务和效率进行治理，如图8所示。 （4）设施衰弱剖析：通过剖析设施的历史和以后设施信息来预测设施将来可能产生的故障，并且给出故障的可能性和类型，不便培修部门为用户指定维保策略，被动分割用户，如图9所示。 （5）三包服务治理：服务于三包部门，提供以后维保流动揭示、设施维保流动记录、设施维保到期预警等性能。 （6）备品备件治理：备品备件治理通过将与维修保养相干的备品备件也都建档立案。用户和各相干部门人员能够在挪动端和零碎端进行备品备件查问申请审批等操作，缩小不必要的工作流程，进步维修保养效率。同时通过数据分析来预测备品备件需求量，保障需要的同时缩小企业的库存老本。 在利用TDengine后，这六大功能模块在应用成果上也取得了显著晋升，不光体现在数据的写入、查问性能上，同时也体现在高效的压缩效率上，真正实现了性能和老本均衡的最优化。 将来布局目前，在搭载TDengine后，3H1原有业务零碎在降级革新后取得了极大的晋升，不仅升高了研发和保护的老本，同时实现了横向扩大。TDengine优异的查问性能给咱们带来了很大的惊喜，极高的压缩效率，也给咱们节俭了大量的存储资源。将来，咱们也会尝试在更多场景利用TDengine，增强与TDengine的深度单干。

一、参考时序数据库学习系列目录 ——更新ing TDengine 官网文档 二、下载安装2.1 环境阐明环境阐明示例｜操作系统CentOS Linux release 7.6.1810 (Core)TDengine serverTDengine2.2.1.12.2 装置步骤形容装置服务端yum install TDengine-server-2.2.1.1-Linux-x64.rpm单元 3单元 4三、根本应用3.1 启动服务systemctl start taosd 3.2 命令行命令形容示例taos启动命令行客户端create database yzdb;创立库 use yzdb; create table t (ts timestamp, speed int);创立表 insert into t values ('2019-07-15 00:00:00', 10);insert into t values ('2019-07-15 01:00:00', 20);写入数据 select * from t;简略查问3.3 官网demo3.3.1 demo创立的具体形容在数据库 test 上面主动创立一张超级表 meters，该超级表下有 1 万张表，表名为 "d0" 到 "d9999"，每张表有 1 万条记录，每条记录有 (ts, current, voltage, phase) 四个字段，工夫戳从 "2017-07-14 10:40:00 000" 到 "2017-07-14 10:40:09 999"，每张表带有标签 location 和 groupId，groupId 被设置为 1 到 10， location 被设置为 "beijing" 或者 "shanghai" ...

在《这几个神秘参数，教你TDengine集群的正确应用形式》中，咱们通知了大家：如何能力让数据平均的散布在节点中。接下来，咱们和大家一起以产品使用者的视角持续向前摸索。 如果说让数据均匀分布的目标是为了最大化地应用CPU资源的话，那么充沛地利用数据压缩能力就是为了最大化地驾驭存储资源了。 我只能说，在这个方面TDengine做得棒极了。 在官网上，有这样的形容： TDengine 绝对于通用数据库，有超高的压缩比，在绝大多数场景下，TDengine 的压缩比不会低于 5 倍，有的场合，压缩比可达到 10 倍以上。上面就是TDengine在最近三个月内打出的问题。 在顺丰科技的利用案例中，TDengine轻松替换掉了OpenTSDB+HBase： 服务端物理机由21台降至3台，每日所需存储空间为93G（2正本），等同正本下仅为OpenTSDB+HBase的约1/10，在降低成本方面绝对通用性大数据平台有十分大的劣势。 在得物APP的利用案例中，TDengine通过10%的压缩率为对方节约了大量存储资源： 目前Sentinel的数据没有应用正本，全量数据扩散在三台机器中，依据计算得悉TDengine对于Sentinel监控数据的压缩率达10%，相当可观。 一是开源产品收费，二是能白白给本人省下那么多服务器，三是读写性能都不错——这种降本增效的工具谁不喜爱呢。 于是一些用户开始装置产品，并开始应用官网举荐的压测工具taosdemo造数写入，想看看是不是真的能够做到宣传的成果。 然而测试过后，很多用户感觉TDengine的压缩率并没有达到本人的预期。可另一方面，顺丰和得物这些大企业又实实在在地失去了十分可观的老本升高，那么问题到底出在哪里呢？ 大家都晓得IoT数据的特点之一就是，对于同一监测量而言，相互之间相差小且有法则，即使是字符型也会有相当大数据反复呈现或者相似的可能。正是这样的数据模型才给了TDengine的列式压缩广大的施展空间。 然而呢，如果仅以taosdemo默认配置的随机数据来做测试，生成的数据未必具备这样的特点。比方，默认的配置有一个长度为16的nchar字符类型，每个 nchar 字符占用 4 bytes 的存储空间4*16占据了简直一半的行长度又不好压缩，所以就显得压缩效率有点低。 为了优化这个体验，在2.1版本的taosdemo里默认的写入数据换成了四列INT。但如果大家想写入自定义格局的数据，只有依据这个博客操作就好了。 TDengine taosdemo工具使用指南 那么回到实在生产环境上，又会是什么状况呢。换言之，TDengine到底是如何帮忙顺丰与得物这样的独角兽企业升高存储老本的呢？ 接下来，咱们就来看看——什么叫赢在起跑线上：超级表建表语句和一般表建表语句的区别就只在这一个中央——Tag（标签）。超级表多了它就能够治理百万千万级别的子表，充沛地阐明了它的重要性。 正是因为TDengine把每个设施的标签都提取进去放在了内存里，所以才让设施的裸数据量天生就少了很多。所以，如果你想测试一样的业务场景下的性能时，在生成数据的那一刻你就会发现TDengine曾经赢了。因为想要营造出一样的场景，它基本不须要造出那么多数据。 假如一个设施光是标签数就和测点数差不多甚至更多的时候，那在原始数据上你就可能曾经省下了至多一半的磁盘占用。 接下来，咱们来看看TDengine的数据压缩流程：当数据写入内存的时候，为了避免断电等非凡状况带来的数据失落，TDengine会把数据先写入wal(write ahead log)文件。 当落盘机制被触发，数据开始长久化到存储之前，COMP参数就开始失效了。依据这个参数的值（0 1 2），TDengine会别离抉择是做不压缩，一阶段压缩，还是二阶段压缩：一阶段压缩会依据数据的类型进行了相应的列压缩，压缩算法包含delta-delta编码、simple 8B办法、zig-zag编码、LZ4等算法。所以，总结一下： 1.对于特定列有特定算法的针对性压缩2.物联网场景下数据的广泛规律性这两点独特造就了TDengine超强的压缩能力。 接下来，二阶段压缩又在一阶段压缩的根底上用通用压缩算法进行了压缩，压缩成果更高。对于TDengine压缩算法的阐明见如下链接。 https://github.com/taosdata/TDengine/blob/master/src/util/src/tcompression.c 最初，咱们再来看看，到底要如何估算出压缩率： 首先，咱们要算出裸数据的大小，官网上提供的计算公式为： Raw DataSize = numOfTables * rowSizePerTable * rowsPerTablerowSizePerTable（每行长度）能够依据每个数据类型的长度来计算。describe table你会看到表的构造以及各个字段的大小。其中binary和nchar类的长度为最大长度。理论占用要以实在数据长度为准（上面示范中binary和nachar占满全副空间），而nchar字段的占用长度还要乘4。此外，每个binary和nchar还要额定占据两个字节。 比方下表： 在假如Binary和Nchar数据都是写满16个的状况下，单行总长度就是（8+1+2+4+8+4+8+16+164+1+8）+4=128字节。用128字节乘以 rowsPerTable（每个表行数）numOfTables(表数)，就能够大体地估算出咱们的总数据量了。 其实，测试中更常见的是间接用超级表作为测试主体，间接应用超级表的count（*）数据去乘以每行长度就能够失去Raw DataSize了。 最初，再用/var/lib/taos/vnode/上面各个vnode的数据文件大小除以Raw DataSize。 功败垂成——咱们终于得出理论压缩率了。这里，大家要注意一下：在数据文件目录下的vnode目录外面还有一个wal目录。如果这外面有数据阐明数据还没有落盘到存储外面，也就是说数据是还没有压缩过的。为了让测试后果更加精准，所以大家能够应用最简略间接的方法——重启服务过程，这样就能够间接触发落盘机制了。 上图显示：重启过后，所有的wal文件大小都是0，证实数据曾经胜利被压缩后写入存储了。 本次TDengine之旅，终于到此告一段落。 其实，测试压缩率最好的方法就是在正当的数据建模之后，用本人的实在数据试去跑一下，这时候就高深莫测了。 以上，就是TDengine升高存储老本的最大杀手锏。 点击这里，体验TDengine！

作者：艾忠元 睿信物联网平台是北京睿信世达自主开发的通用物联网平台，为用户提供从传感器设施、边缘网关、云平台到APP、小程序的一整套端到端物联网SaaS云平台，能够满足用户的通用物联网性能需要；在此基础上构建了智慧水务、智慧消防、智慧环保、智慧农业、智能家居等行业利用组件，满足用户的场景化需要。 平台的整体架构如下。 现状及痛点目前采纳OpenTSDB进行时序数据的存储，性能上满足现有需要；然而因为OpenTSDB架构简单，体量过重，给开发测试、装置部署以及运维治理等工作带来了不小的麻烦，随着业务的倒退，问题逐步凸显，开始影响工作效率，具体能够演绎为以下几方面： 装置难OpenTSDB不是独立的服务组件，它还要依赖HBase、HDFS、ZooKeeper。须要把这些服务组件全副装置配置好，OpenTSDB能力失常工作，即使是一个纯熟的运维工程师，把这些服务组件全副装置配置一遍，也须要很长时间。调试难在开发测试过程中，如果呈现问题，须要对OpenTSDB进行日志剖析，甚至可能还须要对HBase、HDFS和ZooKeeper进行全面的日志剖析和问题排查，能力最终定位并解决问题。运维难在正式环境中，要求集群部署，各种服务都是双份、三份甚至n份部署，各个服务节点之间的关系盘根错节，服务节点和主机数量越多，监控治理就会越难，运维人员的工作累赘也就越重。老本高老本能够分为两个方面，一个是人力老本高，因为装置、调试、运维的难度减少，造成开发运维人员工作量减少，工作效率变低，从企业经营角度看，人力老本变高；另一个是硬件资源老本高，因为服务节点泛滥，占用的主机、内存和磁盘空间也会很多，购买或租用这些硬件资源须要更多的费用收入。技术选型为了解决目前这些问题，咱们决定从新进行技术选型，寻找OpenTSDB的代替计划，降级目前的时序数据库解决方案。进而，要对技术选型进行全面评估，结合实际须要，咱们确定了几个选型要求： 开源收费：必须是凋谢源代码的，并且容许收费商用；成熟稳固：具备较长的倒退历史，通过大量我的项目利用实际，经验过工夫的测验；社区沉闷：开发者社区人员多，探讨、问答、征询、推广等线上线下流动频繁；迭代更新：有开发人员始终在保护，一直在迭代更新和公布新版本；性能高：单机能反对每秒10万以上的插入效率，并可能通过扩大硬件反对更高的插入效率；开销低：服务节点少，占用的内存、CPU和磁盘空间少；反对集群：可能集群部署，容量可程度扩大。通过初步考察，InfluxDB、TimescaleDB和TDengine这3个时序数据库进入了咱们的考查范畴。 InfluxDB在DB-Engines网站上，InfluxDB处于时序数据库排名的第一位，满足咱们绝大部分的要求，但集群模块闭源，因而被排除在外。 TimescaleDBTimescaleDB在DB-Engines中的排名也比拟高，简直满足咱们的所有选型要求，然而它是PostgreSQL上的一个时序数据库插件，是基于RDBMS的时序数据库，不是一个纯正的时序数据库；另外，对集群反对不好，不反对程度扩大。 TDengine和InfluxDB一样，TDengine最后的开源版本也不反对集群，也被排除在外。去年TDengine开源了集群版本后，又进入了咱们的考查范畴。通过各方面的综合考查评估，TDengine满足咱们所有的选型要求，成为技术选型的最终目标。 数据建模因为是既有系统升级革新，必须合乎现有零碎架构，不能影响现有性能。因而，数据建模必须限定在肯定的范畴内，有肯定的束缚和限度，不能像设计一个新零碎那样有那么大的自由度。总结下来，次要有两方面的束缚和限度： schema-free（模式自在）不须要有create table之类的建表过程，就能够间接进行数据的写入和查问。目前曾经应用了OpenTSDB这种schema-free的数据库，并依照schema-free的形式进行数据的读写，心愿连续这种形式，防止性能和架构上的调整。 单列模式物联网平台的设计初衷是要可能撑持所有的利用场景，不能只思考某一种特定的利用场景，必须设计成一种通用架构，为应用层提供足够的灵便度。因而，咱们将设施和指标之间的关系设计为动静绑定关系，并且可能进行动静绑定配置。 比方，某种液位仪有液位和间隔两个指标，在A场景下只须要采集液位，在B场景下只须要采集间隔。 为了可能撑持设施和指标之间的这种动静绑定关系，咱们采纳了单列模式（也被称为纵表模式或窄表模式），每个指标独自保留一条数据，如果设施有n个指标，就保留n条数据。相同，多列模式（也被称为横表模式或宽表模式）是将设施的所有指标数据存储为一条数据，分不同的列存储不同指标值。 很显然，TDengine不是schema-free的，须要先建表，而后能力进行数据读写，这就冲破了下面的束缚和限度，无奈满足架构上的要求，难道要放弃TDengine？还有没有变通的方法呢？通过一番考察剖析，最终还是找到了解决办法。 上面从三方面进行拆解阐明。 通用超级表TDengine里有超级表的概念，每种设施对应一个超级表，这个超级表只负责存储这种类型的设施数据；因为后面的束缚和限度，咱们必定不能这么用。但能够变通的来用，设计一个可能兼容所有设施类型的通用超级表，把所有设施的数据往这个超级表里装；这样，只须要在零碎装置部署的时候，一次性执行超级表的建表脚本，理论运行时，就不须要再动态创建超级表了。 单列模式TDengine反对单列模式和多列模式，出于插入效率和存储效率的思考，官网举荐多列模式。然而，为了合乎后面的束缚和限度，满足通用场景需要，咱们采纳了单列模式，一条数据中仅存储一个指标值。 联合下面的思路，咱们的数据模型的设计如下（为了不便剖析问题，省去了几个无关的标签）： 数据列蕴含工夫和指标值两列，对应上报工夫和上报的具体值，标签中的指标编码用来对同一个设施下的不同指标做辨别，查问的时候能够用来做条件过滤。 主动建表TDengine中还有一般表的概念（为了和超级表概念辨别开，这里称为一般表），一般表也须要先创立后插入。还好TDengine反对主动建表，能够在插入的时候，顺带建表。于是，咱们就能够利用主动建表语法进行主动建表，屏蔽一般表的建表过程。具体写法如下： 通用超级表，单例模式，再加上主动建表，通过这些方法，咱们把表的概念变得越来越弱化，TDengine逐步被革新成了一个schema-free的数据库，能够依照schema-free的形式来应用TDengine。 这样一来，在不改变架构，不影响性能的前提下，数据建模工作就圆满完成了。 代码革新在物联网平台现有的架构中，有一个时序数据服务，专门负责对时序数据库进行封装，而后对外提供时序数据的写入和查问服务，物联网平台的其余所有模块都通过这个服务来拜访时序数据库。 有了这样的架构设计，代码革新工作就变得非常简单。只须要改变这个时序数据服务，在现有根底上减少对TDengine的反对，将写入和查问两个性能依照TDengine的JDBC接口进行接口适配，将时序数据的写入和查问切换到TDengine。 通过这种形式，咱们就把TDengine的革新迁徙屏蔽在了时序数据服务外部，下层利用无需关怀，性能上不受任何影响。 数据迁徙工具降级革新我的项目，须要保留历史数据，须要对历史数据进行数据迁徙。为此，咱们专门开发了一个数据迁徙工具，将OpenTSDB中的历史数据迁徙到TDengine，并且进行了详尽的功能测试。 为了确保海量数据的疾速迁徙，咱们还做了性能优化，并进行了大数据量的压力测试。数据迁徙是降级上线过程中十分重要的一个环节，所以，咱们在这个工具上投入了很多精力，甚至比代码革新自身还多。 降级上线为了可能平滑顺利地实现降级上线，不影响用户失常应用，咱们制订了具体的迁徙计划，将降级上线分为三阶段实现。 第一阶段：数据迁徙将革新后的新版本上线，OpenTSDB和TDengine并行运行，同时向两个数据库写入数据，因为OpenTSDB有全量数据，查问申请全副交给OpenTSDB；与此同时，启动数据迁徙工具，将历史数据迁徙到TDengine，待数据迁徙实现，进入到第二阶段。 第二阶段：试运行OpenTSDB和TDengine仍然并行运行，也同时向两个数据库写入数据；数据迁徙曾经实现，TDengine中曾经具备全量数据，因而，查问申请全副切换到TDengine。察看两周左右的工夫，没有发现任何问题，进入到第三阶段。 第三阶段：正式上线TDengine通过试运行一切正常，性能和性能都没有问题，于是咱们将OpenTSDB进行运行，数据只向TDengine写入，OpenTSDB占用的资源全副回收。 到此为止，降级上线全副实现。 革新成果迁徙到TDengine后，成果非常明显，硬件资源缩小到原来的1/5，效率有了显著的晋升。随着存储规模的一直变大，这种改善和晋升成果会越来越显著。此外，在运维治理、费用收入、开发测试等方面也有了很大的改善。 开发人员当初能够本人电脑上搭建一套环境，轻易折腾，不必放心跑不起来，也不必放心影响他人；性能测试的时候，用配置低一些的机器也没问题，照样能做出压测成果；遇到技术难题，原来通过Google、百度、StackOverflow寻找答案，当初能够间接在官网渠道https://github.com/taosdata/TDengine提issue，也能够在TDengine的技术社区发问，TDengine的技术专家亲自回答，响应十分快；TDengine的体积小，只有几M，上传起来十分快，有些私有化部署我的项目，不容许拜访外网，只能手动上传，体积小的劣势就非常明显；装置部署简略，配合Docker容器，能够在几分钟内实现装置部署；经营监控工作变简略了，只须要对TDengine的几个过程进行监控；占用的磁盘空间显著变小了，缩小到原来的1/5；应用的主机缩小到原来的1/5，相应的费用收入也缩小了。总结此次降级革新总体进行得比较顺利，但过程中也有一些挫折，尤其是在数据建模的时候遇到了一些艰难。方法总比艰难多，通过一些办法和技巧，咱们把TDengine革新成了schema-free的数据库，满足了物联网平台的要求，最终实现了降级革新。 目前，曾经撑持起了所有物联网设施上报的数据，同时撑持起了应用层的各种利用场景。 革新后的成果显著，硬件资源缩小为原来1/5，开发、测试、运维、治理、收入等方面都有显著的改善和晋升。 咱们应用到的性能还比较简单，次要是插入、间断查问以及降采样查问，对于物联网平台来说根本够用。UNION、GROUP BY、JOIN、聚合查问等性能临时还未应用到，这些性能对于大数据分析的场景十分有用，未来在一些大数据我的项目里能够尝试应用，用来代替Hadoop全家桶。 此外，应用过程中遇到一些问题，心愿改良： JDBC-JNI不是纯Java的，依赖一个动静库，给装置部署带来不少麻烦；起初通过JDBC-RESTful解决了这个问题，然而两头多了一层RESTful Connector，性能会低一些；最现实的做法，还是用纯Java写一个直连后端服务的JDBC Driver；客户端是命令行形式，对于开发者不是很敌对，尤其是一些高级开发者，或者是用惯了图形界面的开发者；图形界面，语法高亮，语法查看，这些性能还是很香；尽管目前有两个社区开发者提供的GUI，当然官网能提供反对的话是最好不过了。

作者：尹飞小T导读：顺丰科技大数据集群每天须要采集海量监控数据，以确保集群稳固运行。之前尽管采纳了OpenTSDB+HBase作为大数据监控平台全量监控数据的存储计划，但有不少痛点，必须对全量监控数据存储计划进行革新。通过对IoTDB、Druid、ClickHouse、TDengine等时序数据存储计划的调研，最终咱们抉择了TDengine。大数据监控平台采纳TDengine后，在稳定性、写入性能、查问性能等方面都有较大的晋升，并且存储老本升高为原有计划的1/10。 场景与痛点顺丰科技致力于构建智慧大脑，建设智慧物流服务，继续深耕大数据及产品、人工智能及利用、综合物流解决方案等畛域，在中国物流科技行业处于领先地位。为了保障各类大数据服务的安稳运行，咱们围绕OpenFalcon搭建了大数据监控平台。因为OpenFalcon自身采纳的是rrdtool作为数据存储，不适宜做全量监控数据的存储，于是咱们采纳了OpenTSDB+HBase作为大数据监控平台全量监控数据的存储计划。 目前整个平台均匀写入数十亿条/天。随着大数据监控平台接入的数据量越来越大，咱们有很多痛点须要解决，包含依赖多、应用老本高和性能不能满足等问题。 依赖多，稳定性较差：作为底层大数据监控平台，在数据存储方面依赖Kafka、Spark和HBase等大数据组件。过长的数据处理链路会导致平台可靠性升高，同时因为平台依赖大数据组件，而大数据组件的监控又依赖监控平台，在大数据组件呈现不可用问题时，无奈及时通过监控平台对问题进行定位。应用老本高：因为监控数据写入数据量微小，且须要保留全量监控数据半年以上，用以追溯问题。所以根据容量布局，咱们采纳4节点OpenTSDB+21节点HBase作为全量监控数据存储集群。压缩后每天仍须要1.5T（3正本）左右空间存储，整体老本较高。性能不能满足需要：OpenTSDB作为全量监控数据存储计划，在写入方面性能根本满足需要，然而在日常大跨度和高频次查问方面已无奈满足要求。一方面，OpenTSDB查问返回后果慢，在时间跨度比拟大的状况下，须要十几秒；另一方面，OpenTSDB反对的QPS较低，随着用户越来越多，OpenTSDB容易解体，导致整个服务不可用。技术选型为解决上述问题，咱们有必要对全量监控数据存储计划进行降级。在数据库选型方面，咱们对如下数据库做了预研和剖析： IoTDB：刚孵化的Apache顶级我的项目，由清华大学奉献，单机性能不错，然而咱们在调研时发现不反对集群模式，单机模式在容灾和扩大方面，不能满足需要。Druid：性能弱小，可扩大的分布式系统，自修复、自均衡、易于操作，然而依赖ZooKeeper和Hadoop作为深度存储，整体复杂度较高。ClickHouse：性能最好，然而运维老本太高，扩大特地简单，应用的资源较多。TDengine：性能、老本、运维难度都满足，反对横向扩大，且高可用。通过综合比照，咱们初步选定TDengine作为监控数据存储计划。TDengine反对多种数据导入形式，包含JDBC和HTTP模式，应用都比拟不便。因为监控数据写入对性能要求比拟高，咱们最初采纳了Go Connector，接入过程须要做如下操作： 数据荡涤，剔除格局不对的数据；数据格式化，将数据转化为实体对象；SQL语句拼接，对数据进行判断，确定写入的SQL语句；批量写入数据，为进步写入效率，单条数据实现SQL拼接后，按批次进行数据写入。数据建模TDengine在接入数据前须要依据数据的个性设计schema，以达到最好的性能体现。大数据监控平台数据个性如下： 数据格式固定，自带工夫戳；上传数据内容不可预测，新增节点或服务都会上传新的标签内容，这导致数据模型无奈后期对立创立，须要依据数据实时创立；数据标签列不多，然而标签内容变动较多；数据数值列比拟固定，包含工夫戳，监控数值和采样频率；单条数据数据量较小，100字节左右；每天数据量大，超过50亿；保留6个月以上。根据上述特点，咱们构建了如下的数据模型。依照TDengine倡议的数据模型，每一种类型的数据采集点须要建设一个超级表，例如磁盘利用率，每个主机上的磁盘都能够采集到磁盘利用率，那么就能够将其形象成为超级表。联合咱们的数据特点和应用场景，创立数据模型如下： 以指标作为超级表，不便对同一类型的数据进行聚合剖析计算；监控数据自身包含标签信息，间接将标签信息作为超级表的标签列，雷同的标签值组成一个子表。库构造如下： 超级表构造如下： 落地施行大数据监控平台是下层大数据平台稳固运行的底座，须要确保整个零碎的高可用性；随着业务量减少，监控数据量持续增长，要保障存储系统能不便的进行横向扩大。基于以上两点，TDengine落地总体架构如下： 为保障整个零碎的高可用和可扩展性，咱们前端采纳nginx集群进行负载平衡，保障高可用性；独自拆散出客户端层，不便依据流量需要进行扩容缩容。 施行难点如下。 数据写入：因为监控指标的上传接口是开放型的，只会对格局进行校验，对于写入的数据指标不确定，不能事后创立好超级表和子表。这样对于每条数据都要查看判断是否须要创立新的超级表。如果每次判断都须要拜访TDengine的话，会导致写入速度急剧下降，齐全无奈达到要求。为了解决这个问题，在本地建设缓存，这样只须要查问一次TDengine，后续相干指标的写入数据间接走批量写入即可，大大晋升了写入速度。另外，2.0.10.0之前的版本批量创立表的速度十分慢，为了保障写入速度，须要依照创立表和插入数据分批插入，须要缓存子表的数据信息，前面的版本优化了子表创立性能，速度有了大幅晋升，也简化了数据插入流程。查问问题：1. 查问bug。监控平台数据次要是通过Grafana进行数据展现，然而在应用过程中，咱们发现官网提供的插件不反对参数设置，依据咱们的本身需要，对其进行了革新，并提供给社区应用。另外在应用过程中，触发了一个比较严重的查问bug：在设置较多看板时，刷新页面会导致服务端解体。后经排查，发现是因为Grafana中一个dashboard刷新时会同时发动多个查问申请，解决并发查问导致的，后经官网修复。2. 查问单点问题。TDengine原生HTTP查问是间接查问特定服务端实现的。这个在生产环境是存在危险的。首先，所有的查问都集中在一台服务端，容易导致单台机器过载；另外，无奈保障查问服务的高可用。基于以上两点，咱们在TDengine集群前端应用Nginx集群作反向代理，将查问申请均匀分布在各个节点，实践上能够有限扩大查问性能。容量布局：数据类型，数据规模对TDengine性能影响比拟大，每个场景最好依据本人的个性进行容量布局，影响因素包含表数量，数据长度，正本数，表活跃度等。依据这些因素调整配置参数，确保最佳性能，例如blocks，caches，ratioOfQueryCores等。依据与涛思工程师沟通，确定了TDengine的容量布局计算模型。TDengine容量布局的难点在于内存的布局，个别状况下，三节点256G内存集群最多反对2000w左右的子表数目，如果持续减少的话，会导致写入速度降落，且须要预留一部分的内存空间作为查问缓存应用，个别保留10G左右。如果子表数量超过2000w，则能够抉择扩大新节点来分担压力。 革新成果实现革新后，TDengine集群轻松扛住了全量监控数据写入，目前运行稳固。革新后架构图如下： 稳定性方面：实现革新后，大数据监控平台解脱了对大数据组件的依赖，无效缩短了数据处理链路。自上线以来，始终运行稳固，后续咱们也将继续察看。写入性能：TDengine的写入性能跟写入数据有较大关系，在依据容量布局实现相干参数调整后，在现实状况下，集群写入速度最高达到90w条/s的写入速度。在通常状况下（存在新建表，混合插入），写入速度在20w条/s。查问性能：在查问性能方面，在应用预计算函数状况下，查问p99都在0.7秒以内，曾经可能满足咱们日常绝大部分查问需要；在做大跨度（6个月）非预计算查问状况下，首次查问耗时在十秒左右，后续相似查问耗时会有大幅降落（2-3s），次要起因是TDengine会缓存最近查问后果，相似查问先读取已有缓存数据，再联合新增数据做聚合。老本方面：服务端物理机由21台降至3台，每日所需存储空间为93G（2正本），等同正本下仅为OpenTSDB+HBase的约1/10，在降低成本方面绝对通用性大数据平台有十分大的劣势。总结目前从大数据监控这个场景看，TDengine在老本，性能和应用便利性方面都有十分大的劣势，尤其是在老本方面带来很大惊喜。在预研和我的项目落地过程中，涛思的工程师提供了业余、及时的帮忙，在此表示感谢。心愿TDengine可能一直晋升性能和稳定性，开发新个性，咱们也会依据本身需要进行二次开发，向社区奉献代码。祝TDengine越来越好。对于TDengine，咱们也有一些期待改良的性能点： 对表名反对更敌对；对其余大数据平台的反对，联结查问需要；反对更加丰盛的SQL语句；灰度平滑降级；子表主动清理性能；集群异样停机复原速度。后续咱们也将在顺丰科技的更多场景中尝试利用TDengine，包含： 物联网平台，作为底层物联网数据存储引擎构建顺丰科技大数据物联网平台；Hive on TDengine，通过Hive on TDengine实现与现有其余数据源数据联结查问，使其能平滑的与现有零碎应用，升高接入门槛。

视频教程第二弹，疾速理清TDengine中的抽象概念，并学会布局生产场景中的数据模型。 点击链接，获取视频教程。 欢送来到物联网的数据世界在典型的物联网场景中，个别有多种不同类型的采集设施，采集多种不同的物理量，同一种采集设施类型，往往有多个设施散布在不同的地点，零碎需对各种采集的数据汇总，进行计算和剖析对于同一类设施，其采集的数据都是很规定的。 本文咱们以智能电表(采集量为电流、电压)为例，探讨如何在TDengine中建库、建超级表、建表。 假如每个智能电表采集电流、电压两个量，其采集的数据如下图所示。 每一条记录都有设施ID，工夫戳，采集的物理量(如上图中的电流、电压），还有与每个设施相干的动态标签（如上图中的地位Location和分组groupId）。每个设施是受外界的触发，或依照设定的周期采集数据。采集的数据点是时序的，是一个数据流。 那么TDengine如何形象这些物联网数据呢？ 这里，须要提到TDengine的要害翻新点——一个采集点一张表。同一类型的采集点用一个超级表来形容，也就是一个表构造Schema和动态标签Schema 。就上图来说，电表ID作为子表名（d1001, d1002, d1003, d1004等），动静采集的物理量作为各字段，动态属性（Location和groupId）作为子表标签。利用超级表作为模板，生成子表 – 对应各采集点，有了超级表，极大中央便了同类采集点的数据检索、查问、聚合。 这种设计有几大长处： 能保障一个采集点的数据在存储介质上是以块为单位间断存储的。如果读取一个时间段的数据，它能大幅缩小随机读取操作，成数量级的晋升读取和查问速度。因为不同采集设施产生数据的过程齐全独立，每个设施的数据源是惟一的，一张表也就只有一个写入者，这样就可采纳无锁形式来写，写入速度就能大幅晋升。对于一个数据采集点而言，其产生的数据是时序的，因而写的操作可用追加的形式实现，进一步大幅提高数据写入速度。如果采纳传统的形式，将多个设施的数据写入一张表，因为网络延时不可控，不同设施的数据达到服务器的时序是无奈保障的，写入操作是要有锁爱护的，而且一个设施的数据是难以保障间断存储在一起的。采纳一个数据采集点一张表的形式，能最大水平的保障单个数据采集点的插入和查问的性能是最优的。 数据建模的根本办法TDengine采纳关系型数据模型，须要建库、建表。因而对于一个具体的利用场景，须要思考库的设计，超级表和一般表的设计。 CREATE DATABASE dbnameUSE dbnameCREATE TABLE stbname (ts timestamp, other fields…) tags ( tag fields)CREATE TABLE tbname using stbname tags(具体标签值)INSERT INTO tbname VALUES(now, values…)创立库不同类型的数据采集点往往具备不同的数据特色，包含数据采集频率的高下，数据保留工夫的长短，正本的数目，数据块的大小等。为让各种场景下TDengine都能最大效率的工作，倡议将不同数据特色的表创立在不同的库里，因为每个库能够配置不同的存储策略。 创立一个库时，除SQL规范的选项外，利用还能够指定保留时长、正本数、内存块个数、工夫精度、文件块里最大最小记录条数、是否压缩、一个数据文件笼罩的天数等多种参数。比方倡议为数据特色雷同的表创立一个库，每个库能够配置不同的存储策略。 CREATE DATABASE power KEEP 365;上述将创立一个名为power的库，这个库的数据将保留365天。更多参数及语法见： https://www.taosdata.com/cn/documentation20/taos-sql/创立库之后，须要应用SQL命令USE将以后库切换过去，例如： USE power;将以后操作库换为power。还可应用“库名.表名”来指定操作的库、表的名字。 引入超级表一个数据采集点一张表， 意味着1000万智能电表对应1000万张表，一个物联网零碎，往往存在海量同类型的数据采集点。如何对这么多张表进行操作就是一个微小的挑战。为不便对同类型多表的操作，TDengine引入超级表。 创立超级表时，需提供：表名、表构造Schema、标签Schema。 CREATE TABLE meters (ts timestamp, current float, voltage int) TAGS (location binary(64), groupdId int);超级表的列分两局部：动静局部，动态局部。 ...

上周，涛思数据与EMQ在线上Meetup上联结公布了工业互联网一体化解决方案，基于TDengine、EMQ X搭建一个集工业数据采集、汇聚、荡涤、存储剖析以及可视化展现等能力于一体的轻量级边缘计算工业互联网平台。目前TDengine曾经全面反对ARM 32和ARM 64处理器，那么为什么，TDengine是边缘侧数据更高效的存储抉择？它比SQLite好在哪里？在Meetup上，涛思数据联结创始人侯江燚分享了这背地的技术原理。 从互联网到挪动互联网再到当初咱们的物联网，计算机、挪动终端、可穿戴设施、汽车、甚至家里的灯以及工厂里各种设施都曾经接入网络。整体来说，各种各样的设施一直地采集实时状态数据，再把这个数据会集到云端的一个计算平台，这是物联网云计算的大略思路。 整个物联网技术链有4层构造：通过传感器采集设施的状态数据 -> 通过通信模组将数据发往云端 -> 在云端进行存储、查问和计算 -> 最初接入剖析及利用零碎。 然而，在云计算模式中，数据必须要传到云上进行集中式的存储、归档及剖析等。边缘侧的节点可能是一个网关，也可能是咱们真正应用的一个终端。如果它没有本身的计算能力，必须把采集的数据发给云端，依靠云端计算资源进行简单的计算，失去一个指导性的论断，再通过网络下发给终端。很容易看出，这个过程中终端的工作十分依赖于网络。如果网络一旦呈现一些中断或故障的话，终端无奈与云端进行交互，其某些工作就会大受影响。因而这种核心侧（云端）主控的思路，对边云之间的通信要求十分高，利用起来往往要应用高老本的高速通信网络。从另一个层面说，随着数据量一直增长，云端的存储老本和计算成本也会一直升高。 解决这个问题的一个很好的思路就是边缘计算，即把一部分的存储和计算的能力下沉到边缘侧（即设施侧），终端设备较独立地进行数据存储、计算、决策和利用。这样边缘侧就变得更智能，对云端依赖更小，数据处理的时效性也更高，且不再受网络影响。 边缘计算带来的劣势简略总结如下。 然而边缘计算目前有什么艰难还没解决呢？咱们晓得，边缘侧往往是一些可能大量铺设的小型智能终端，处于老本思考，其配置的内存、CPU等硬件资源和计算能力都很无限。边缘计算的难点就在于是否在无限的计算资源下，实现最高效的数据存储、剖析和计算。这就让边缘侧的数据库抉择显得尤为重要。边缘侧的终端设备采集的数据有很显著的特色，个别都是带有工夫戳的、结构化的时序数据流。因而边缘计算对数据库能力的要求就反映在以下几个方面： 超高读写性能低硬件开销通用接口，适配边缘侧多样计算需要实时数据的缓存能力、流式计算能力历史数据长久化存储、高效压缩能力历史数据回溯能力、按工夫窗口的统计聚合能力云边协同能力TDengine——更适宜边缘侧的大数据引擎时序数据库是具备上述各项能力的，也是边缘侧采集数据存储的最佳抉择。但如OpenTSDB（底层基于HBase革新）、InfluxDB等时序数据库对于边缘侧来说还是太重了，运行起来的硬件资源开销过高。一个极轻量化的开源时序数据库就是TDengine，整个安装包只有2MB多。其外围性能是一个高性能分布式时序数据库；除此之外，还自带了音讯队列、缓存、流式计算、数据订阅等性能，为时序结构化数据存储提供一个All-in-One的解决方案。 目前TDengine社区曾经公布了反对ARM32和ARM64处理器的版本，能够顺畅地运行在树莓派等支流的边缘侧硬件上，同时提供对实时数据的缓存、历史数据回溯、按时间段聚合计算等多种能力。尽管在边缘侧用到分布式集群的概率比拟小，但如果哪几个树莓派、盒子或网关想要搭建一个集群，也是齐全能够的。 TDengine ARM版本反对的接口也有很多种，与失常集群版简直没有区别。同时，还提供了一个 taos shell客户端，让调试人员能够不便地去查看TDengine的运行状态。 TDengine 边云协同思路边缘侧资源无限，能存储的数据总量也是无限的，因而还是要向云端做数据备份和协同。边云协同思路也有很多，这里讲一下咱们的一些思路。 举个例子不便大家更好的了解。边缘侧厂区有很多网关，咱们能够在每个网关里都装一个TDengine的边缘侧版本，那么TDengine就成为边缘侧的一个存储引擎，能够把网关采集到的数据长久化存储。取决于数据采集频率和压缩状况，边缘侧能够依据现有的存储资源选择性存储肯定工夫长度的原始数据（比方一个月到半年等）。对于整型或者浮点型数据，TDengine能够将其压缩到原来的10%左右，当然这个取决于具体的数据类型，如果数据的值随机变动十分大，这个压缩比的确会受肯定影响，但整体来讲，从理论状况来看，压缩比还是在10%左右。因而，如果咱们在网关里配一个2GB甚至1GB的SD卡的话，大略能够存储10GB的原始数据量。这个量级对边缘侧实时剖析来说曾经足够。 然而如果须要存储更久的历史数据，进一步做大数据挖掘等剖析，则要把数据同步到云端数据中心存储。TDengine边缘侧的版本能够被云端的TDengine客户端间接拜访（网络畅通状况下），因而从边到云的数据同步变得非常简单。云端的应用程序能够通过TDengine的订阅模块实时拉取边缘侧网关中的最新数据，再把收到增量数据实时写入本地TDengine集群做历史归档。这个技术实现上，实质是一个定时查问，因而TDengine容许用户增加一些数据筛选条件，有选择性地同步边缘侧的数据（比方只拉取采集之大于某个阈值的记录，没有就不要），而不必把所有的历史数据都上报给云端。 基于TDengine在边缘侧的存储劣势以及边云协同的整体思路，涛思数据和EMQ也联结做了一个边缘侧的解决方案。简略来说，边缘侧网关中部署EMQ X Neuron、EMQ X Edge和EMQ X Kuiper以及TDengine，将设施采集的流式数据通过Neuron做协定解析转换成MQTT音讯，而后公布Edge（边缘侧MQTT Broker），再通过Kuiper存入在边缘部署的 TDengine 中。这样在边缘端运行的利用即可从 TDengine 中获取和解决数据，做实时显示和报警。EMQ 在边缘端运行的 Edge Manager 提供了一个治理控制台，能够很不便地实现软件配置和治理其余三个组件。点击「这里」，具体理解该计划的配置办法。这种计划相当于把协调的工作交给了EMQ。 但也可能有的用户曾经在云端用了TDengine的集群，当初也有一些工业设施，想间接通过TDengine Cluster客户端间接去拜访边缘侧的TDengine。这种也能够通过TDengine的数据订阅的模块间接实现，即云端的利用调用数据订阅模块创立一系列的订阅工作，间接去实时拉取边缘侧TDengine中的最新增量数据。这种计划相当于把协同的工作又交给了TDengine，当然这里要保障网络是畅通的。 TDengine边缘版本在树莓派上的编译上面也简略介绍一下在树莓派上编译、装置、运行TDengine的实战步骤。 环境筹备1. 烧录操作系统 烧制操作系统到SD卡。TDengine反对Ubuntu16.04、CentOS7.0及以上等支流操作系统。 2. 网络设置 配置树莓派上的网络环境，为开发版设置动态IP和hostname等，并连贯到网络。 3. 下载编译TDengine 从www.github.com/taosdata/TDengine 克隆TDengine源码到树莓派，编译并运行。 编译过程# clone source code$ git clone --recursive --recurse-submodules https://github.com/taosdata/TDengine.git# checkout to the latest version$ cd TDengine/$ git checkout ver-2.0.7.0# compile and install$ mkdir build && cd build$ cmake ../ -DCPUTYPE=aarch64 -DVERNUMBER=2.0.7.0 -DVERCOMPATIBLE=2.0.0.0$ make && make install# start taosd$ systemctl start taosd$ taosdemo编译装置实现后，就能够看到咱们提供的taosdemo程序，不便大家进行极速体验。大家能够通过taosdemo来测试一下TDengine的数据写入和查问效率。 ...

咱们简略介绍一下 HiveMQ extension for TDengine 的部署和应用办法。 TDengine 和 HiveMQ 部署办法TDengine 装置最新 TDengine server 即可。参见官网文档: https://www.taosdata.com/cn/getting-started/。 HiveMQ 装置企业版（需申请试用License）或社区版（HiveMQ Community Edition，https://github.com/hivemq/hivemq-community-edition）都能够。参见官网文档: https://www.hivemq.com/docs/hivemq/4.4/user-guide/install-hivemq.html HiveMQ TDengine 插件的编译和部署 git clone https://github.com/taosdata/TDenginecd TDengine && git submodule update --init --recursivecd src/connector/hivemq-tdengine-extension && mvn clean && mvn package将打包好的压缩包如: hivemq-tdengine-extension-{version}-distribution.zip 解压到 HiveMQ 目录的 extensions 文件夹下。如果 HiveMQ 曾经运行须要先将 HiveMQ 后盾服务停下来，否则 HiveMQ 会禁止插件运行，须要手动删除 DISABLED 文件方可使插件工作。批改插件包内的 tdengine.xml 配置文件为理论应用的数据库信息。不须要手动建库建表,插件启动时会主动创立库和表演示运行 HivMQ <HiveMQ>/bin/run.sh 发送 MQTT 音讯 应用风行的 MQTT 软件 mosquitto 发送 MQTT 音讯进行测试演示： ...

从石破天惊到在 GitHub 上大放异彩，TDengine 是如何走到明天这一步？TDengine是如何实现存储和查问的超强性能的？为何抉择开源，并且将“看家本领”全副开源？又是如何在实践中践行“只置信代码”的准则？酷爱开源的开发者们，又能从中发现怎么的趋势和切入点？本周六（2020 年 11 月 7 日），在 TDengine 集群开源三个月后，涛思数据热衷于开源的极客“男团”，筹备约上 TDengine 的爱好者，开一场线下 Party，点击这里即可报名加入。 2020 年 8 月 3 日，咱们决定将用户最刚需的集群性能开源，引起很大反应。不少以前“潜水”在 TDengine 技术交换群的用户向官网团队反馈，从去年开源时，就十分关注 TDengine，但因为集群性能之前没有开源，减少了他们在生产环境中应用 TDengine 的思考老本，而这次，能够说天时地利，再也没有理由不替换掉那套惨重冗余的 Hadoop 体系了。 集群开源后，TDengine 在 GitHub 上的再次上了一个新的高度，间断 6 天位列 GitHub 寰球趋势榜第一名，目前 Star 数已破 14,000，Fork 超过 3,600， Issue 数超过 4,000。更令人开心的是，咱们的实在用户量每天都放弃 100 以上的增长，三个月的工夫，应用 TDengine 2.0 的用户曾经冲破 10,000。 开源就要彻底，这是涛思数据从上到下的行动指南。但，公开所有源代码，用户须要什么，就开源什么，这就够了吗？ 当然不够！作为热衷于开源的极客，咱们巴不得把“心”掏出来给你看。因而，咱们把这场线下 Party 定位为技术开放日，并打算把所有技术创新点和程序的设计细节统统公布出来。作为技术直男，兴许不肯定能和你们从诗词歌赋聊到人生哲学，但肯定能够从技术创新聊到设计思维，带你们意识一个不一样的 TDengine。 你将听到陶建辉（涛思数据创始人&CEO）：TDengine 的技术创新在哪里？为什么性能指标能比通用的大数据平台快10倍？ 关胜亮（涛思数据联结创始人）：30 分钟听懂 TDengine 2.0 集群是如何设计和工作的 程洪泽（涛思数据联结创始人）：TDengine的 存储与压缩算法：如何做到存储空间不到通用数据库的1/10? 刘溢清（涛思数据研发工程师）：置信人or置信代码？开源软件，如何做好CI/CD? 奖项揭晓除了这些技术干货的分享，咱们还有两个重磅的奖项揭晓。 ...

小 T 导读：八五信息新能源电力物联网平台采纳TDengine，存储和查问剖析物联网设施的实时数据，以及光伏设施传感器的遥测数据。需撑持至多50000台设施总计400万测点的实时数据接入、解决及存储，预计日增量40多亿条。之前应用TimescaleDB，无论在读写性能，还是硬件资源上，都遇到了瓶颈，且没有集群性能。随后切换到了TDengine，读写性能进步了10倍，存储老本升高到原来1/5左右。 应用场景简介以后业务场景咱们首先在新能源电力物联网平台上应用了TDengine，次要用于光伏设施遥测实时数据的存储、查问和剖析。 新能源物联网生产经营平台通过物联网及大数据技术将现有电站数据进行整合，实现园区设施的对立运行监督，数据集中管理。给不同人员等提供全面、便捷、差异化的数据和服务。 对运维人员提供设施的状态信息、报警信息、近程故障诊断信息、实时数据等数据应用服务；对管理人员和经营人员提供各类检测数据的汇总、变化趋势等应用服务。该平台零碎整体的架构如下： 零碎的总体架构依照分层实现的设计理念，在底层设计上实现各个软件系统的职能拆散，确保各局部高效运行。 数据规模，查问压力等要求规划设计数据存储规模大略在16T左右，目前数据日增量为1亿多条，全副测点接入后预计日增量为40多亿条左右；零碎需撑持至多50000台设施总计400万测点（信号量和模拟量）的实时数据接入、解决及存储。 利用零碎的惯例查问在50QPS左右，高并发在100QPS左右。一次历史数据查问剖析最大跨度为一年且撑持多测点多模式分析形式。时序数据分析界面如下： 工况实时展现界面： 目前总数据量以及日增量： 目前创立的超级表以及子表数： 数据模型简介目前依据不同的测点类型建设了不同的超级表。依照不同的测点ID以及测点号作为tag创立了不同的子表。这样咱们针对于测点能够间接进行单表剖析，解决性能高、速度快。也能够针对多测点进行剖析，间接操作超级表，业务实现简略，同时兼顾了查问性能。 查问需要· 简略查问 针对于单测点的历史数据查问剖析以及工夫距离聚合剖析。次要是对单测点的异样数据的排查和告警数据的排查确认。TDengine是把同类设施数据纳入一个超级表，但每个设施都会依据超级表的构造建设本人的一张子表，查问单测点数据实际上只查问一个子表，遍历的数据量大大减少，查问剖析根本毫秒级响应。简略查问SQL图例： · 聚合查问 多测点雷同工夫维度不同聚合类型的工夫迁徙比照剖析。侧重于比照，不便用户更加无效的确认不同测点下的异样和差别状况。 · 大批量测点分组聚合查问 数百测点的分组分时段聚合查问；在肯定时间段内，大批量测点的查问依然能够迅速响应。 查问压力峰值并发为100qps，均匀并发量为20qps，理论场景中并发查问压力较小，未达到TDengine的查问瓶颈。 采纳TDengine带来的收益零碎性能读写性能较原TimescaleDB数据库进步10倍左右，在数据接入层不必再放心数据库的写入性能瓶颈；数据分析查问应用层也较原零碎有较大晋升，尤其是在时间跨度大的聚合类剖析简直霎时响应。 通过乱序插入性能，解决了边缘侧因为网络问题导致的数据传输不及时造成的乱序写入问题，保障了数据的完整性。 集群性能比照TimescaleDB劣势较大，TimescaleDB没有集群性能但反对流复制形式的主备库；TDengine集群容易搭建且无主从节点辨别，对利用革新和撑持较敌对，集群版读写性能晋升较大。 数据存储减少集群多正本性能，通过数据冗余晋升了零碎的平安和可靠性，升高了零碎的运维老本。 软硬件资源节俭了零碎大量的计算资源以及存储资源，升高了大概4倍左右的存储老本。 比照未应用TDengine之前TimescaleDB时序库开启压缩后对70亿数据占用磁盘为165G，且一分钟内无奈查问出一个月的历史数据；而在应用TDengine之后磁盘占用空间为40G左右，毫秒级返回针对一个月的历史数据的聚合查问。相干查问如下： 利用TDengine遇到的问题与解决思路原有时序库大数据量批量导入TDengine，在1.6版本进行批量导入十分麻烦，一次批量插入只有200条左右，前期在降级到了2.0版本以上后一次能够插入1M数据，大大晋升了不同数据库不同表构造之间的批量导入性能。 将来应用TDengine的思考通过一段时间的线上运行，TDengine有优异的性能体现，咱们决定将在后续工夫将咱们所有的物联网我的项目逐渐都更新为TDengine。 TDengine性能方面的冀望与倡议剖析型函数加强，心愿减少时序库中实用的罕用剖析函数； 加强间断聚合查问性能，目前间断聚合性能实用性不强； 产品生态，与Spark、Flink等开源剖析工具的集成。 作者: 八五信息开发工程师李良政

1. TDengine2.0之前的版本升级到2.0及以上的版本应该留神什么？☆☆☆2.0版本在之前版本的根底上，进行了齐全的重构，配置文件和数据文件是不兼容的。在降级之前务必进行如下操作： 删除配置文件，执行 sudo rm -rf /etc/taos/taos.cfg 删除日志文件，执行 sudo rm -rf /var/log/taos/ 确保数据曾经不再须要的前提下，删除数据文件，执行 sudo rm -rf /var/lib/taos/装置最新稳固版本的TDengine 如果数据须要迁徙数据或者数据文件损坏，请分割涛思数据官网技术支持团队（support@taosdata.com），进行帮助解决 2. Windows平台下JDBCDriver找不到动态链接库，怎么办？请看为此问题，撰写的技术博客 3. 创立数据表时提醒more dnodes are needed请看为此问题撰写的技术博客 4. 如何让TDengine crash时生成core文件？请看为此问题撰写的技术博客 5. 遇到谬误"Unable to establish connection", 我怎么办？客户端遇到链接故障，请依照上面的步骤进行查看： 1.查看网络环境 云服务器：查看云服务器的平安组是否关上TCP/UDP 端口6030-6042的拜访权限 本地虚拟机：查看网络是否ping通，尽量避免应用localhost 作为hostname 公司服务器：如果为NAT网络环境，请务必查看服务器是否将音讯返回值客户端 2.确保客户端与服务端版本号是完全一致的，开源社区版和企业版也不能混用 3.在服务器，执行 systemctl status taosd 查看taosd运行状态。如果没有运行，启动taosd 4.确认客户端连贯时指定了正确的服务器FQDN (Fully Qualified Domain Name(可在服务器上执行Linux命令hostname -f取得） 5.ping服务器FQDN，如果没有反馈，请查看你的网络，DNS设置，或客户端所在计算机的零碎hosts文件 6.查看防火墙设置，确认TCP/UDP 端口6030-6042 是关上的 7.对于Linux上的JDBC（ODBC, Python, Go等接口相似）连贯, 确保libtaos.so在目录/usr/local/lib/taos里, 并且/usr/local/lib/taos在零碎库函数搜寻门路LD_LIBRARY_PATH里 8.对于windows上的JDBC, ODBC, Python, Go等连贯，确保driver/c/taos.dll在你的零碎搜寻目录里 (倡议taos.dll放在目录 C:WindowsSystem32) ...

什么是IDEA Database管理工具？这里首先介绍下IDEA，IDEA全称IntelliJ IDEA，是Java语言开发的集成环境，IntelliJ在业界被公认为最好的Java开发工具之一。 IDEA是自带数据库管理工具的，相似于一个小型Navicat。这个工具能够让咱们平时的一些对数据的操作间接在 IDEA 就能够实现，不须要再切换到其余工具上。对于TDengine来说，用户能够通过JDBC驱动建设和IDEA的连贯，不须要再到命令行去写SQL语句，间接在IDEA中执行即可。这也是为大家可视化应用TDengine提供了一种解决办法。 如何通过IDEA Database管理工具连贯TDengine？应用IDEA自带的Database模块增加TDengine 填写数据库连贯 连贯测试 依照提醒配置TDengine的驱动 增加驱动 因为官网的驱动【我从maven仓库下载了一个】 依赖了Apache-common包，所以驱动不能独立运行，如果导入后会报错，提醒StringUtils包不存在，所以我改了驱动的源码，去掉了这个依赖 批改后的驱动下载地址： https://download.csdn.net/dow... 当然你也能够自行批改源码去掉TSDBDriver类中Apache-StringUtils的依赖： 驱动引入之后 再度连贯测试 能够看到曾经连贯胜利了。如果连贯呈现问题，有好多种起因，自己遇到过得是数据库版本和windows下的客户端版本不统一，把两者改为统一就解决了。 如果还有问题请参考官网文档介绍排查问题呈现起因： https://www.taosdata.com/cn/d... 还有个谬误大家能够先不必管： 具体应用步骤 至此，TDengine表中的后果曾经齐全显示进去了。 不过在这个过程中，有一个概念须要更正一下，把TDengine了解成一个时序数据库，是不完全正确的。TDengine实质上是一个开源、高效的物联网大数据平台，除外围的快10倍以上的时序数据库性能外，还提供缓存、数据订阅、流式计算等性能。这个概念很重要，请大家一起默念三遍。 作者简介：曾建强，航电修建科技研发工程师，目前负责数据可视化方面的钻研，对技术钻研有浓重的趣味，开源社区爱好者。 TDengine外围性能齐全开源，借开源东风，也收到很多来自开源社区的反对和反馈。除了这次介绍连贯IDEA办法的这位大神外，还有不少奉献干货的小伙伴。比方奉献.Net Core驱动的Maikebing同学，也始终是社区中的沉闷成员，下次能够重点向大家介绍一下，他奉献的几款工具。 心愿大家在应用TDengine的同时，也能施展本人的技术激情，参加到社区的奉献中来！

小 T 导读：上海嘉柒智能科技有限公司致力于电力行业线下线上一体化运维，为此提供整体解决方案。业务蕴含电力运维，智慧路灯，隧道一体化等。其电力运维平台数据库应用的是TDengine，采纳TDengine后，存储空间大为节俭。 业务场景嘉柒智能的电力运维平台嘉能云，专一于线下线上联结运维，具备海量设施接入能力、数据分析和计算能力，其中电力运维平台数据库应用的是TDengine，在数据层面蕴含有：数据采集，数据传输，数据存储，数据分析。 数据采集：设施多种多样，生产研发采集设施及通信治理机的厂家也十分多，这种场景特地适宜TDengine的“一个设施一张表”模式。厂家的设施都是依据规约来生产的，电力规约通常有电力协定有许多比方(IEC101、103、104国内电力调度协定)、61850（国内通用），还有一些其余的比方Modbus-RTU、CDT等。而这些协定蕴含几种数据：遥测、遥信、遥脉、遥控、遥调等，这些数据都由一个或多个点表（点表蕴含测点类型及测点数量多有不同）上报，采集频率个别是五分钟（依据被监控设施的重要性及其须要的反应时间来确定），随着设施量的减少，数据量还是相当宏大的。 遥信：要求采纳无源接点形式，即某一路遥信量的输出应是一对继电器的触点，或者是闭合，或者是断开。通过遥信端子板将继电器触点的闭合或断开转换成为低电平或高电平信号送入RTU 的YX 模块。遥信性能通常用于测量下列信号,开关的地位信号、变压器外部故障综合信号、保护装置的动作信号、通信设施运行状况信号、调压变压器抽头地位信号。主动调节安装的运行状态信号和其它可提供继电器形式输入的信号；事变总信号及安装主电源停电信号等。在TDengine中，此种类型的数据比拟适宜应用bool类型。 遥测：遥测往往又分为重要遥测、主要遥测、个别遥测和总加遥测等。遥测性能罕用于变压器的有功和无功采集；线路的有功功率采集；母线电压和线路电流采集；温度、压力、流量(流速) 等采集；周波频率采集和其它模拟信号采集。在TDengine中，此种类型的数据比拟适宜应用float类型。 遥控：采纳无源接点形式,要求其正确动作率不小于99. 99 %。所谓遥控的正确动作率是指其不误动的概率，个别拒动不认为是不正确，遥控性能罕用于断路器的合、分和电容器以及其它能够采纳继电器管制的场合。在TDengine中，此种类型的数据比拟适宜应用bool类型。 遥调：采纳无源接点形式,要求其正确率大于99. 99 %。遥调罕用于有载调压变压器抽头的升、降调节和其它可采纳一组继电器管制具备分级升降性能的场合。在TDengine中，此种类型的数据比拟适宜应用float类型。 遥脉：遥脉往往是累积量，通常用于尖峰平谷期间的电度量采集（分为有功电度、无功电），电压暂升、暂降等。在TDengine中，此种类型的数据比拟适宜应用double类型。 零碎设计数据传输：数据传输方式，多采纳RJ45口传输，或者sim卡无线传输，这取决于监控站容许的网络环境，如果是串口，则加一个转换设施将串口转为网口数据 数据分析：嘉能云电力运维平台，针对不同站具体的状况，提供相应的数据分析服务。常见的数据分析有：模拟量越限、异样开关、电气火灾、用电剖析等等，紧急情况将第一工夫告诉到电力运维负责人。TDengine的降频和流式计算性能，为此种场景，提供了极大的不便。 数据存储：接入站点泛滥，每个站点有多个设施，每个设施有多个测点，采集工夫距离小。在这样的状况下，数据量曾经十分宏大了，必须要有一个可靠性高，能疾速插入、查问大量数据的数据库。思考到数据库的方便使用，数据库性能，以及语言环境；咱们开始尝试应用TDengine，并且用python作为执行疾速插入/查问的client。 本平台反对公网接入或平台接入两种接入形式: 公网接入数据解析，数据传输皆在云端实现，平台将云端数据通过音讯队列订阅下来，且在订阅服务中，植入TDengine操作代码，将接管到的设施三遥数据间接存入TDengine，防止数据流转工夫过长。平台间接接入设施，嘉能云平台具备协定解析能力，能间接将设施上传的字节流数据解析进去，再存入TDengine。 数据存储构造：在TDengine数据库中，存储形式咱们采纳站名为数据库名，表名为设施名，一个设施一张表，以解冻工夫为主键，以点表测点标识符为字段名的模式。 因为接入设施各不相同，在接入设施之前,咱们为每个设施创立物模型，雷同物模型的设施归为一类，雷同站归为一组，再通过数据库同步到TDengine生成相应的设施表。应用TDengine的超级表，能够实现对同一类设施的对立治理。 Show databases; select * from da00012829 limit 1\G; 数据量写入：在决定应用TDengine之前，我依据：     1）十个站一千个设施；     2）五分钟采集上报一次；     3）一个设施两百个测点；     4）云端接入的状况， 做了一下简略测试：一千个设施一千张表，每张表200个field，也就是20万个测点值要分一千次，存入TDengine，经继续的插入测试，数据并无失落，且运行稳固。 上面是Log记录： 数据查问和展现数据查问：在数据查问方面，用于数据分析的数据查问，咱们感觉数据分析齐全在代码层解决是十分慢的，尤其是在数据密度大，剖析数据时段长的时候，这会很影响用户体验，TDengine除了能够疾速插入数据，另外一个重要的点就是可在数据库层面将数据预处理（过滤、填充、时间段筛选、数据查问密度等），且速度快。 查问举例：察看一个月内的电压状况，查问出相干设施的电流电压，以及产生的告警；综合剖析。依据采集距离计算：工夫范畴30天43200分钟，密度为5min一个点，则是8640个值，三相电压则一次返回三组数据。 在接口中嵌入TDengine时序浓缩数据查问代码示例，做到即时查问即时返回： 局部设施测点同比剖析示例： 应用感触TDengine的确是一款不错的时序数据库，开源、高效的存储和查问，存储空间大为节俭。最开始只是关注插入和查问性能，数据的压缩率的确给了不少的惊喜，大概11%，节俭了不少的存储空间。 connection的人性化、轻量级的软件、每种语言的样例程序，在安装包中都/examples中都能够找到。 将来优化倡议TDengine数据库的链接对象解决机制还有待晋升，心愿2.0版本之后可能扭转。 在数据库查问方面：心愿查问可能更加灵便，且能更多的分担代码计算的压力，这也将使TDengine在我的项目中的位置越重。 作者简介：张灏，上海嘉柒智能科技有限公司研发工程师， 次要从事电力运维平台开发与利用及底层数据接入，近年专一于数据利用与能耗剖析。

Kafka 作为一个流行的消息队列，以分布式高性能，高可靠性等特点已经在多种场景下广泛使用。在工业互联网、物联网时序数据存储的解决方案中也有大量用到。 但在实际部署过程中，可能会因为配置原因导致经过 Kafka 的数据在接收方产生乱序，给后续处理环节带来排序等工作，造成不必要的处理开销，降低系统的处理性能和额外排序的工作。 其实可以通过合理的规划设计 Kafka 的配置和方法来避免消息在通过 Kafka 后乱序的产生，只需要遵循以下原则即可：对于需要确保顺序的一条消息流，发送到同一个 partition 上去。 Kafka 可以在一个 topic 下设置多个 partition 来实现分布式和负载均衡，由同一 consumer group 下的不同 consumer 去消费；这样的机制能够支持多线程分布式的处理，带来高性能，但也带来了同一消息流走了不同路径的可能性，如果没有针对性的规划，从架构上就无法保证消息的顺序。如下图所示，对于同一个 topic 的一条消息流，写入不同的 partition，就会产生多条路径。 为了确保一条消息流的数据能够严格按照时间顺序被消费，则必须遵循一条路径的原则，这样才能实现 FIFO（First In First Out)。 根据 Kafka 的文档描述，把哪条记录发到哪个 partition，是由 producer 负责： ProducersProducers publish data to the topics of their choice. The producer is responsible for choosing which record to assign to which partition within the topic. This can be done in a round-robin fashion simply to balance load or it can be done according to some semantic partition function (say based on some key in the record). More on the use of partitioning in a second! ...