关于后端:压缩性能提升1020倍TDengine助力零跑科技实现性能和成本最优化

72次阅读

共计 2646 个字符,预计需要花费 7 分钟才能阅读完成。

作者:何建军 王国政|零跑科技

对于零跑

浙江零跑科技股份有限公司 (leapmotor) 作为一家科技型企业,是国内极少数领有智能电动汽车残缺自主研发能力并把握核心技术的新能源汽车厂家,由浙江大华技术股份有限公司及其次要创始人独特投资成立,始终保持核心技术的全域自研,为用户的出行和生存发明最大价值,致力成为值得尊敬的世界级智能电动车企品牌。

始终以来,在数据存储上咱们的抉择都是 MongoDB 和 HBase,然而随着业务的减速扩张,写入速度太慢、撑持老本过低等问题也逐步浮现,具体来说,次要有以下几处痛点:

  • MongoDB 存储数据会将数据全副存储在内存中,过高的存储老本导致只能存储一段时间内的数据,且存储的数据格式须要通过业务组织解决,不仅业务变更不灵便,能够做的业务也十分无限。
  • 咱们局部实时信号数据存储在 HBase 中,这是一个很重的数据库,搭建 HBase 须要整套 HDFS 做撑持,应用、运维、人力等老本都很高,须要大数据相干的人才能力保障安稳运行。而且公司的 HBase 环境是公有云环境,云平台在私有云环境,跨专网业务时常会被网络问题影响。
  • 因为存储和解决问题,只能把电动车产生的 3000 多个信号的二进制数据存储在 HDFS 上,用的时候还须要应用 Map/Reduce 进行计算获取,例如应用数据导出性能每次都须要半小时以上能力计算结束。
  • 为降低成本咱们把大量的数据存储在公有云端,然而却升高了数据应用上的便捷度和性能,特地是在切换专网时数据服务便无奈提供了。

从降本增效的角度思考,咱们决定在 C11 新车型上试用下其余的数据库,在剖析数据特点后,最终确定采纳时序数据库。但市面上时序数据库产品泛滥,之所以抉择 TDengine,一是因为它比较突出的性能和老本管控能力,其次也是因为我和它的一些渊源。

为什么抉择 TDengine?

在接触一个新的数据库产品时,通常大家比拟关注的无非就是两点:性能强、成本低,这也是咱们抉择 TDengine 的次要起因。

另外和 TDengine 的渊源要追溯到我的上一份工作,那时我对它就有过一些比拟深刻地理解,进入零跑要进行时序数据库选型时,发现大家都没有接触过,心里也都挺没有底的,我就把这段经验讲了进去,包含对 TDengine 的一些认识和见解。

我有多年大数据行业的工作教训,在理解到时序数据库后,也对市面上一些风行产品如 OpenTSDB、InfluxDB 都进行了一些调研。比照之后发现 TDengine 是专门针对物联网、车联网业务场景去设计的,在解决这些行业数据问题上更有针对性,它不仅安装包很小,对集群资源耗费也很少,并且它翻新的“一个数据采集点一张表”的数据模型,特地适宜物联网这种多设施且信息量存储十分大的数据场景。

因为有我之前的实际佐证,大家统一感觉这款数据库绝对会更有保障,在各方的鼎力推动下,咱们就开始搭载 TDengine 运作新业务了。

在搭载了 TDengine 之后,咱们播种了以下的四点提高:

  • 数据解析进去间接存储在 TDengine 中,解决了应用数据反复解析问题。
  • 不必再像 MongoDB 一样,在查问前须要依据业务加工出需要数据。TDengine 的列式存储,间接以 SQL 计算即可,大大提高了业务的灵活性。
  • TDengine 高压缩的算法能晋升 10 到 20 倍的压缩性能,升高了存储压力的同时解决了数据存储老本高的问题。
  • 入库性能高,解决了以前 HBase 入库不及时的问题,能够用更少的服务器资源入库更多的数据,节俭更多老本。

存在的问题和优化的空间

当然问题也是不可避免会存在的,对于咱们来说 TDengine 是一款很新的数据库,相比较而言 HBase 必定会在应用上更加稳固一些。咱们的业务场景数据列自身就比拟宽,有 3000 多列,而 TDengine 之前都是针对几十列。此外,还存在因开发集群时钟不准导致集群频繁重启、因数据量太大导致查问报错、连贯资源超时等诸多在理论落地时遇到的问题。

但咱们并不认为遇到问题就要一棍子打死,相同违心给 TDengine 工夫去进行优化。因为应用模式不一样,必定会遇到诸多问题,如果基于此就放弃应用的话,那这款跟物联网场景十分符合的数据库就要和咱们擦肩而过了。TDengine 失去了一个经典的利用场景案例,咱们也会因而失去一个更好的抉择。

在 TDengine 小伙伴的反对下,上述问题也失去了很好的解决。咱们后期应用 taosdemo 工具进行插入性能的测试,能达到 200 万每秒的入库性能。在查问这块,因为都是外部用户在应用,云平台查问并发并不高,所以没有进行十分深刻的测试,其查问性能也能完满匹配咱们的需要。

此外,在正本构建上他们也从业余角度给出了一些倡议,我放在本文中,给有同样问题的同学们一些参考:

具体抉择几个正本还是要看读写比,从现有架构登程的话,写入性能要求更高,两正本加一个冷备会绝对更稳当一些;之后如果查问性能要求提上来了,能够思考裁减成三个正本,三正本下读的性能以及并发能力会比两正本更强,因为最终的需要还是满足在线的实时业务,而不是数仓型业务。所以此时双正本和三正本的体验差异不大。

零跑 +TDengine 的将来瞻望

早在 2018 年我就开始关注 TDengine 了,到 2021 年它曾经倒退了三年工夫,相对来说也变得更加成熟和稳固了,也因而咱们抉择了它,而它也真的在帮忙咱们节省成本、进步速度。

当然如果咱们抉择市面上其余的数据库产品的话,可能也能胜任,然而却很难达到这样一种性能和老本的最优化。尤其咱们做的是汽车这样一种产品,数据量之大难以想象,如果没有一款可能实现高效存储的数据库,服务器老本会十分的高。这从运行节点的数量上就可窥一二,如果应用 HBase,预计须要建设十多个节点,而搭载 TDengine 的状况下三个节点就能搞定,节点少了运维起来天然也会变得更加轻松一些。

目前咱们的数据会在 TDengine 上存半年,另外每天都会同步到数仓进行为时两年的存储。大部分波及到 APP、云平台的业务,像车速、温度、充电应用状况、电池衰弱度等信号值当初都是存储在 TDengine 上。此前应用 MongoDB 进行业务解决时,须要先将数据存到 MongoDB 文档中,稍显简单,当初应用 TDengine 能够间接进行提取展现。比照来看,TDengine 在达到咱们预期的前提下,在应用上也更加不便。

在将来的布局中,咱们心愿可能引入 TDengine 的应用个性到更多的业务中去,比如说热更新、温度曲线、测速曲线、电极转速等,用更多新的个性缩小客户端 CPU 的耗费,也期待 TDengine 有更多更好的性能退出。

正文完
 0