共计 4128 个字符，预计需要花费 11 分钟才能阅读完成。
作者：张红朋
小 T 导读：广东领益智造股份有限公司是寰球当先的智能制作平台企业，致力于以技术先进、品质牢靠为外围竞争力，为客户提供“一站式”精细智造解决方案，实现精细、好看、高品质、低成本于一体的终端产品。业务涵盖生产电子、医疗器械、汽车零部件等多个行业，凭借先进的研发与制作能力，领益智造与世界知名企业建设了巩固的策略单干关系，综合实力位居寰球同行业前三强。
在对生产设施的 AOI 全检数据进行品质剖析时，咱们对关系型数据库做了很多预处理运算，然而在计算正态分布、盒须图、尺寸剖析及原始数据查问上遇到了致命的性能问题。此前咱们抉择的数据库服务器已达到较高的硬件配置（1.5T 的内存、96 逻辑核的 CPU、全闪盘的业余存储），再想要通过进步服务器配置来实现响应速度的晋升是十分艰难的。即便数据库对查问做了相应的索引，抉择一周的数据进行查问时，零碎的响应工夫依然在 20 秒以上。
为了解决当下的问题，咱们找了很多计划进行测试。首先应用 Hadoop 生成 10 亿的数据量进行查问的模仿测试，发现实时查问时的查问效率还没有关系型数据库好，因而排除了 Hadoop 代替计划。接着对杉岩的对像存储计划进行测试，因其对象存储的缘故，采纳此计划的话才购买不久的服务器资源就无奈应用了，同时还须要再投入软硬件费用，老本较高。
正当咱们筹备验证 ClickHouse 计划时，却在查问材料时无心中发现了 TDengine，查看官网的性能报告后，咱们决定对其进行测试。咱们下载了 2020 年的 TDengine 社区版进行测试，发现在写入、查问时的效率很惊艳，随即开始开展其与业务匹配度的评估，确认了在计算正态分布、盒须图、尺寸剖析时的匹配度均很高，而这些问题恰好又是咱们当初所急需解决的。
最终咱们决定应用关系型数据库和时序数据库同时保留两份数据，以此来满足不同的业务场景。
一、教训分享
联合数据特点和应用场景，咱们开始构建超级表，以其中一张表为例，数据模型创立如下：
create table t_qualityproductdetail (ftime TIMESTAMP,fqualityproductid BINARY(32),fpromachineid BIGINT,fjobnumber BINARY(50),fsn BINARY(250),value FLOAT,standard FLOAT,max FLOAT,min FLOAT,createon TIMESTAMP,fisok INT) TAGS (fproductid BIGINT,fprocessesid BIGINT,faiid BIGINT,fmachineid BIGINT,fresult INT,fcount INT)
在引入 TDengine 时首先面临的就是工夫戳的问题。因为咱们每一个产品在同一个工夫点会有多个数据产生，且这些数据是在同一台机器上产生的，依照官网文档，在一个超级表中一台机器一个子表的形式会造成“只能存储最初一条数据”的问题，经剖析后最终咱们决定把表拆到每个检测点的粒度，以此形式解决了此问题。
但由此也带来了一个新的问题，那就是表数量超限。在 2.2 以前的版本上，官网倡议超级表的数量不应超过 4 万个，而咱们的产品、生产机台号、检测机台号外加检测点的汇合，按计算会远大于 4 万个，咱们也很放心在上线后会对性能造成较大影响，但所幸新的 2.2 版本没有这一限度了。
通过与官网的沟通，咱们在应用过程中接触到了更多 TDengine 的个性，将其利用到业务中反对更多的时序数据场景，目前 TDengine 曾经被利用在两头表预处理、良率计算、通过序列号查问产品实例的测点明细等业务中，其中在良率计算上还用到了一些小技巧，在此给大家做一下教训分享。
在良率计算逻辑调整上，关系型数据库中是通过子查问的关联来进行每台机器的良率计算，判断良品是通过一个 Fresult 进行判断，后果为 1（良品）、2（不良品）、3（重测），计算时采纳以下形式：
select FProcessesID,FConmpyID,FMachineID,FProductID,FProMachineID,cast(FTime as date) FTime,FCount,count(0) FTotalCount,sum(case FRESULT when 1 then 1 else 0 end) FOKCount from [T_QualityProduct] t0 WITH (nolock) where FTime >=@currdate and FTime <@currenddate group by FProcessesID,FConmpyID,FMachineID,FProductID,FProMachineID,cast(FTime as date),FCount而 TDengine 不反对 case when 的运算，在解决时须要计算两次，先是通过以下形式来计算总数：
select FProMachineID,FCount,count(*) FTotalCount from [T_QualityProduct] where FTime >=@currdate and FTime <@currenddate group by FProcessesID,FConmpyID,FMachineID,FProductID,FProMachineID,FCount interval(1d)而后再通过以下形式计算良品数量：
select FProMachineID,FCount,count(*) FOKCount from [T_QualityProduct] where FTime >=@currdate and FTime <@currenddate and FRESULT =1 group by FProcessesID,FConmpyID,FMachineID,FProductID,FProMachineID,FCount interval(1d)算出后果后通过程序代码把上述多条件分组汇总的数据合并到一起。
以上这种计算形式有两个毛病，一是须要查问两次，效率不高；二是程序代码中须要做多条件的匹配汇总，代码革新工作量较大，效率低。经重复沟通后，最终咱们决定减少一个 fisok 的 Int 类型的字段，良品用 1，其余用 0 来展现，经此革新后，代码和执行效率有了质的晋升。能够间接应用以下的代码来实现查问：
select FCount, count(*) FTotalCount,sum(fisok) FOKCount，sum(fisok)/count(*) yeild from [T_QualityProduct] where FTime >=@currdate and FTime <@currenddate group by FProcessesID,FConmpyID,FMachineID,FProductID,FProMachineID,FCount interval(1d)最终咱们应用此形式胜利计算出了良率，且性能远高于关系型数据库，程序代码也不必改变。
二、成果展现
在 TDengine 胜利上线接入后，咱们将每日良率、线别机台良率、尺寸良率剖析、正态分布、361 剖析、盒须图、原始数据查看等业务都移到了 TDengine 中，而 TDengine 在理论业务中也展现出了如测试时所体现的高效性能。
1. 存储容量比照
1）某关系型数据库的数据空间和索引空间大小，QualityProductDetail 和 QualityProduct 两张表别离求和。
2）TDengine 通过在 CentOS 执行 du -sh /var/lib/taos 查看文件夹大小。
2. 查问效率比照
- 通过正态分布语句进行查问比照
1）5 天查问条件：FTime between ‘2021-06-21 00:00:00.000000’ and ‘2021-06-25 23:59:59.999999’ and FAIID=1693 and FProcessesID=1 and value<999 and FCount=1
2）3 月查问条件：FTime between ‘2021-06-01 20:00:00.000000’ and ‘2021-09-01 19:59:59.999999’ and FAIID=1693 and FProcessesID=1 and value<999 and FCount=1
- 查问效率比照具体测试数据
1）5 天数据
某关系型数据库——查问后果量 414,995 条，均匀耗时 328.13 秒
TDengine——查问后果量 413,180 条，均匀耗时 4.61 秒
2）3 个月数据
某关系型数据库——查问后果量 1,949,501 条，均匀耗时 340.29 秒
TDengine——查问后果量 1,848,385 条，均匀耗时 20.80 秒
通过以上的比照测试，咱们发现在同等条件下，查问最近 5 天的数据，某关系型数据库均匀耗时 328.13 秒，而用 TDengine 则均匀耗时 4.61 秒，用时为原来的 70 分之一，查问效率晋升了 70 倍，把数据拉长到 3 个月，效率也有 15 倍的晋升。在咱们失常的业务场景下，80% 的状况会查问最近 7 天的数据，70 倍的查问效率晋升也如实映射为失常业务环境下的体现。
咱们应用原来的关系型数据库时，会建设大量的索引来晋升查问速度，但发现进行原始数据查问计算时效率还是太低，响应工夫以十秒为单位，故而采纳了预处理的计划，把每日的良率提前按产品、机台进行混部，这样在查问时就能够有较快的查问速度，但同时也就义了空间和实时性。通过以上比照能够看出，在建好索引和两头表的状况下，同样的数据量级，某关系型数据库的空间应用是 TDengine 的 40 倍。
三、写在最初
伴随物联网技术终端和利用的跨越式倒退，其背地微小的市场空间和经济效益日益浮现，作为一个大的技术趋势被科技企业宽泛关注。在此背景下，TDengine 作为一款专为物联网大数据场景而生的时序数据库，它所展现出的高效性能和老本管控能力都十分惊艳，成为科技企业抓住物联网时机的一个无力抓手。
目前咱们已着手把稼动率的我的项目迁徙到 TDengine 上，同时团体在 2021 年底把物联部门晋升为一级部门，后续将会有更多的设施联机数据须要存储和剖析。
想理解更多 TDengine 的具体细节，欢送大家在 GitHub 上查看相干源代码。