当前位置: 首页 > 科技观察

实时数据库:一夜之间,感受到了时序数据库的威胁

时间:2023-03-16 19:14:51 科技观察

进入正题之前,先讲个故事。2018年接触工业互联网之前,完全不知道时序数据库(以下简称时序数据库),因为做标准的原因开始慢慢接触国内的一些时序数据库厂商,其中有许多充满活力的初创公司和经验丰富的老牌信息制造商。强大的BATH天团在TSDB上也有布局。一时间,各种TSDB产品如雨后春笋般涌现。什么时候开始流行的?事实上,从2016年开始就有这种趋势。引用DB-Engines上公布的一张图,2016年的12个月,TSDB的热度上升了26%,排名第一,是图数据库第二名的两倍多。DB-Engines:https://db-engines.com/en/blog_post/622016年各种数据库的热度有所上升,在GoogleTrends中查看了最受欢迎的InfluxDB。这个数据库是在2013年7月左右发布的第一个版本,从那时起人气就一直无法阻挡。InfluxDB的搜索热度从2013年到2019年发生了变化,所以我们加快了学习的步伐,希望能尽快梳理出标准,让业务伙伴在技术选型时有一定的参考。“我们十多年前就开始研究这个数据库,但它被称为另一个名字——实时数据库。”很多工业信息化起步的兄弟给我们提到了“实时数据库”的概念,说“我们的功能其实是一样的”。这让我有些摸不着头脑,很想搞清楚这两个数据库之间的关系。可以算作一种吗?但是当时只能在网上找到CSDN上一篇关于这两个数据库对比的文章《工业大数据漫谈12:实时数据库与时序数据库》(https://blog.csdn.net/guanhui1997/article/details/72840769),说的很清楚,如果你有同样的困惑,可以点进去看看~不过你也可以看看我接下来要写的,因为我们拉的做实时/时序数据库的伙伴已经讨论过好几次这个问题了。所以这篇文章是一些学习心得,会尽量包括:这两个数据库的背景、具体差异和一些小趋势。下面先从一些概念开始铺垫~时序数据时序数据是按照稳定的频率或不固定的周期频率连续产生的一系列基于时间的指标监控数据。它由三个元素组成:时间戳、标签和指示符。时间序列数据库时间序列数据库是用来保存海量时间序列数据的数据库。我们可能是同父异母的兄弟姐妹?实时数据库诞生于传统行业,早在几十年前就已经得到发展。技术非常成熟,主要支持快速写入、存储和查询,有时还涉及实时反馈控制。时序数据库诞生于互联网,脱胎于物联网,主要支持海量网络监控和传感器数据的快速写入和分析。下面我们就来看看为什么实时数据库是专门针对工业场景设计的。工业场景中80%以上的数据都有这样的特点:都有时间戳,按时间顺序产生;其中大部分是结构化数据;频率高,数据量大。以一家中型工业企业为例。在过程监控过程中,可能涉及5万到10万个传感器测量点,每天输出的数据量可达数百GB。通常,工业企业会要求数据能够长期保存,以便随时查询历史趋势。这个简单的需求,已经展示了传统实时数据库需要具备的一些能力,可以概括为:高速写入能力:工业级实时数据库通常对写入速度有很高的要求。以流程行业的场景为例,每个环节都安装了传感器,每个传感器的采集频率都很高,所以并发写入量会特别大,有时甚至每秒百万个测点必需的。因此,除了对软件的要求外,也会选择一些高性能的服务器。快速查询能力:查询需求分为两部分,一是响应实时查询请求,及时反映系统状态;另一种是快速查询历史数据,因为历史数据量非常大,在查询的时候,需要对特定时间段的数据进行汇总,即使是一个整体的数据也需要快速响应检查年份。超强的数据压缩能力:如前所述,监控数据会长期保存,5年甚至10年是常有的事。在存储容量有限的情况下,需要对数据进行一定程度的压缩,通常的方法会分为无损压缩和有损压缩。相比之下,有损压缩的压缩比会更大,有时甚至达到1:30-40,这就需要设计合理的算法来保留数据的细节。这使数据能够在恢复后保留重要特征。积累丰富的工具:传统的实时数据库解决方案一般都是从采集到可视化的一整套系统。多年来积累了丰富的工具包,例如数百种协议或来自各种场景的数据。模型,这些都是工业软件的重要竞争力。追求绝对稳定:行业对软件的稳定性要求特别高。除了使用主备来保证高可用外,程序的持续运行完全靠软件的质量来保证。工程师们会自豪地拍着胸膛,保证软件能运行十年。不会出错的。我们先来看看时序数据库的诞生环境。进入互联网高速发展时期后,随着通信技术的革新和数据通信成本的下降,掀起了万物互联的浪潮。不仅互联网监控需要采集数据,人们每天接触的手机、智能手环、共享单车、汽车等都在源源不断地产生数据。人们实时收集这些数据并发送到云端,利用大数据技术进行分析、监控和预测业务,用数据驱动企业降低成本、提高效率、提高服务质量。仔细看看互联网场景下的数据特征。其实和工业领域的大部分实时数据类似:1、单条数据不是很长,但是数据量很大。2.它们都有时间戳,并且是按顺序生成的。3.大部分数据是结构化的,用于描述某个参数在某个时间点的特征4.写入的频率会远高于查询的频率5.存储的数据很少需要更新6.用户会更关注一段时间内的数据特征,而不是某个时间点7.大多数数据查询分析都是基于某个时间段或某个取值范围8.需要进行统计和画面显示。从上面的数据特征可以明显看出,虽然两个数据库是在不同的环境下生产的,但是面临的问题是一样的,需要解决的问题是相似的。因此,两个数据库设计的功能有很多重叠的部分。功能需求请参考CCSA大数据技术标准推进委员会(TC601)时序数据库评价体系(http://databench.cn/evaluate?standard_id=5c07aec44b079)。这就像两个素未谋面的兄妹。可以说是一家人。你想取代我吗?它不是那么容易。随着物联网和工业互联网带来的新浪潮,一系列新的生产方式、组织方式和商业模式开始涌现。物联网技术正在逐渐向行业渗透,不断增加的传感器、不断飙升的数据量、更高的大数据分析需求对实时数据库的传统技术架构提出了挑战。有些问题需要直面:扩展性遇到瓶颈。传统的技术架构虽然可以保证单机的极高性能,也可以通过增加机器来线性扩展性能,但无法像分布式系统那样实现动态灵活的伸缩,需要提前规划。当业务升级需要系统扩展时,旧架构的扩展性难以满足需求。无法对接大数据生态。数据收集的最终目的是为了被理解和使用。在大数据行业,对于海量数据的存储和分析,已经有非常成熟的解决方案。无论是hadoop还是spark生态系统,都面临着新旧技术的对接。许多工业企业因为要使用新的大数据分析技术,不得不对现有系统进行升级或更换。价格很高。传统的工业实时数据库解决方案非常昂贵,一般只有大型企业才能勉强接受。不过,随着新技术、新理念的普及,越来越多的中小企业也意识到了数据的重要性,但考虑到资金投入,他们更倾向于寻找成本更低的解决方案。这时,来自互联网家族的时序数据库解决方案就显示出一些先天的优势,例如:分布式架构的天然优势:传统的实时数据库多为主备部署架构,通常需要更高配置的机器才能运行。追求单机的卓越性能;同时,在稳定性方面,对运行软件的稳定性会有极高的要求,完全由高质量的代码来保证;由于存储容量有限,对数据压缩比也有超高的要求。而时序数据库的分布式架构使得系统可以很容易的进行水平扩展,让数据库不再依赖于昂贵的硬件和存储设备,利用集群的天然优势实现高可用,没有单点瓶颈或失败。可以运行在普通的x86服务器甚至虚拟机上,大大降低了使用成本。更灵活的数据模型:由于行业场景的特殊性,传统的实时数据库往往采用单值模型。被监测的参数称为测量点。写的时候会为每个测量点建立一个模型。例如,一个风扇的温度指标算一个测点,十个风扇的十个指标就是100个测点。每个测点在查询时都会附有描述性信息(名称、精度、数据类型、开关量/模拟量等),查询时会针对每个测点的值进行查询。可以高效地编写单值模型。单值模型的例子,而时序数据库开始采用多值模型,类似于面向对象的处理方式。例如,风扇是一个数据模型,可以包括温度、压力等多个测量维度,以及经纬度、序列号等标签信息。更适合对外提供服务时的分析场景。当然,单值模型和多值模型是可以相互转换的。很多数据库提供的服务是多值模型,但底层存储仍然是单值模型。多值模型示例现在大部分时序数据库都选择扩展性更好的NoSQL数据库。与关系型数据库相比,数据模型更加灵活,非常适合时间序列数据的多值模型;更容易扩展,当资源有限或需要提高性能时,可以轻松添加机器;查询效率高;开源软件成本低;并可与大数据生态无缝对接。看一下使用NoSQL数据库作为底层存储的TSDB:开源TSDB的底层存储模型,但是使用NoSQL数据库也会失去一些特性,比如不支持事务,需要通过其他方式保证数据的一致性;比如不支持SQL,SQL作为一种标准的查询语句已经被人们使用,是一种学习成本非常低的操作。因此,时序数据库厂商也在尝试集成SQL引擎,以降低使用门槛。时序数据库描述的这么好,会不会继承传统的实时数据库?这不是那么容易。首先,业界的实时数据库经过多年客户需求打磨,性能绝对完美,甚至可以进行一定的反馈控制。配套的产品也很齐全,通常内置采集工具,适配各种接口协议,具有计算能力和定制化的可视化能力(实时数据库在这方面的设计上投入了大量精力,使得图表可以展示监控数据的一些特征和细节),是一个完整的解决方案。时序数据库的设计缺乏这些领域的知识积累,大部分只用于监控分析场景;过多的部署依赖和不完善的配套工具也是问题;性能和可靠性远非实时反馈控制也有一定距离。此外,近年来,实时数据库厂商也在积极行动。他们相继在产品中添加了分布式版本甚至云服务版本。通常,他们会逆向建立一套以实时数据库为核心的数据管理和分析系统。生态圈,气势丝毫不输给互联网玩家。枪声在赛道上响起,没有人放弃比赛。让我们一起进步。无论技术架构如何变化,最终目的都是为了解决用户的需求。以需求为导向的设计永远不会过时。接下来看看出现了哪些新的需求:查询的需求逐渐超过了写的需求:在互联网时代,查询的需求已经不仅仅满足于一些基本的条件查询或者插值查询。随着联网场景的丰富和人们对信息全面掌控的需求,基于地图的应用越来越多。查询将从时间维度逐渐扩展到空间维度。除了保证实时性,更丰富的视觉呈现也是一种趋势。逐渐转向云服务:出于安全和性能原因,传统工业场景使用私有化部署处理实时数据。机器、软件和后续服务是一个非常高的成本,而且还需要专业的技术人员进行系统维护。当业务逐步上云后,一方面节省了购买机器的成本,也不需要为机器和软件系统安排专门的维护工程师。您只需要知道如何开发和维护服务。另外,你用多少服务就买多少,避免了一次性购买服务造成的资源浪费或者资源不够进行二次建设,可以为企业减少很多开支。随着网络和云计算技术的成熟,相关性能和安全性将不断升级,最终接近私有化部署的效果,云服务已成为不可阻挡的趋势。计算分布式到边缘:工业领域其实是物联网的一个重要实验场。工业互联网的发展必然带来更多传感器的使用,更多数据的采集。当数据量过大时,集中处理难以实时响应,这就带来了数据计算向边缘发展。需要实时响应的监控由边缘设备及时处理并反馈。然后将需要用于大规模分析的数据集中存储。这种分层处理的方式可以有效提升时间敏感数据的价值,同时减轻存储系统的负担。所以很多时序数据库都在开发边缘计算版本,会配合流计算能力来丰富功能。结合边缘计算的时序数据解决方案更适合工业互联网的处理场景。综上所述,其实在技术发展的过程中,两个数据库都在不断打磨自身的功能,以满足不断变化的业务需求。各自取长补短,相互补充,甚至做出一些妥协。唯一的出路——停滞产生焦虑,变革带来活力。每个人都想在新风中抓住机会。而脚踏实地做事的人,才能登上顶峰。王妙琼,中国信息通信研究院云所工程师,CCSATC601大数据行业应用工作组组长。主要研究方向为大数据基础平台架构、工业大数据应用等。主导编写了流计算、时序数据库等多项行业标准和研究报告。