具体实施方式
为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然,所描述的实施例仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
目前,通常采用Volcano模型来进行数据查询,但这种模型应用到时序数据库中是,查询效率并不佳。为此,本申请的一些实施例中:在面向时序数据库进行查询的过程中,可以量测指标作为分组依据,对数据源产生的时序数据进行分组,以获得量测指标监测数据组;在此基础上,可在不同的量测指标监测数据组下并行执行查询操作,并可分别获得不同的量测指标监测数据组下的查询结果,这类查询结果可作为生成最终查询结果的基础。据此,本申请实施例中,可通过以量测指标为维度的分组机制,实现对不同量测指标监测数据组的并行执行查询处理,这可有效提高查询效率。
以下结合附图,详细说明本申请各实施例提供的技术方案。
图1为本申请一示例性实施例提供的一种查询方法的流程示意图,图2为本申请一示例性实施例提供的一种查询方案的逻辑示意图。其中,该方法可由查询装置执行,该查询装置可实现为软件和/或硬件的结合,该查询装置可集成在计算设备中。参考图1,该方法包括:
步骤100、响应于查询指令,从时序数据库中读取所需的至少一个数据源产生的时序数据;
步骤101、以量测指标作为分组依据,分别在至少一个数据源下对时序数据进行分组,以获得至少一个数据源各自对应的至少一个量测指标监测数据组;
步骤102、按照查询指令中针对量测指标的第一查询逻辑,对至少一个数据源各自对应的至少一个量测指标监测数据组并行执行查询处理,以获得各个量测指标监测数据组各自对应的第一类查询结果;
步骤103、基于至少一个第一类查询结果,生成最终查询结果。
本实施例提供的查询方案可应用于面向时序数据库的查询场景,例如,应用性能监测、物联网、设备性能监测、工业互联网等应用场景。这些应用场景仅是示例性的,本实施例对应用场景不做限定。在这些应用场景中,可采用时序数据库进行数据管理。本实施例,可面向时序数据库,按需进行高效的查询操作。
参考图1和图2,在步骤100中,可响应于查询指令,从时序数据库中读取所需的至少一个数据源产生的时序数据。其中,查询指令可来源于各种存在查询需求的请求端,例如,用户终端、APP、云服务器等,本实施例对请求端的物理形式不做限定。数据源可以是指应用场景中执行量测的硬件设备或应用程序,例如,温度传感器、应用流量监测程序等,数据源可基于稳定频率持续产生一系列量测指标监测数据,作为时序数据库中的时序数据。在不同的应用场景中,时序数据库中的涉及到的量测指标可以是多种多样的,例如、温度、流量、占用率等,本实施例在此不做限定。另外,本实施例中的查询指令可包括但不限于聚合指令、插值指令、降采样指令或降维指令等,本实施例对此不做限定。
在时序数据库中,通常是以时间线作为时序数据的存储和查询单位,单个数据源下的时序数据可形成一条时间线。通常,我们可以通过“公制metric+属性标签tags”来确定一条时间线。其中,metric可代表一系列同类时序数据的集合;属性标签可描述数据源的特征,通常不随时间变化,不同数据源的属性标签会有差别,数据源对应的属性标签可以有一个或多个。
这样,本实施例中,可基于查询指令,确定所需的至少一条数据线,并从时序数据库中读取所需的至少一条时间线,也即是读取对应的至少一个数据源产生的时序数据。
在此基础上,参考图1和图2,在步骤101中,可以量测指标作为分组依据,分别在至少一个数据源下对时序数据进行分组,以获得至少一个数据源各自对应的至少一个量测指标监测数据组。
其中,单个数据源下可能包含单个或多个量测指标:图3为本申请一示例性实施例提供的一种时间序列单值存储模型示意图。参考图3,该条时间线包含3个属性标签和一个量测指标field(即图3中的温度)。这对应于单个数据源包含单个量测指标的情况。图4为本申请一示例性实施例提供的一种时间序列多值存储模型示意图。参考图4,该时间线包含2个属性标签和两个量测指标field(即温度和描述)。这对应于单个数据源包含多个量测指标的情况。本实施例中,可兼容单值或多值的情况,后文中不再进行区分描述。本实施例中,可采用图3和图4中示出的按列存储的方式对量测指标监测数据进行存储。
参考图3和图4,单个数据源可包含至少一个量测指标,而单个量测指标下可包含至少一个量测指标监测数据,这为本实施例中的分组机制提供了基础。对此,本实施例中,可以量测指标作为分组依据,对时序数据进行分组,从而产生量测指标监测数据组。这样,本实施例中,打破了传统的以数据线作为查询单位的限制,提出了以量测指标监测数据组作为查询单位的方案。参考图2,针对一条查询指令,本实施例中,可按照上述的分组机制,产生至少一个量测指标监测数据组。
参考图1和图2,在步骤102中,可按照查询指令中针对量测指标的第一查询逻辑,对至少一个数据源各自对应的至少一个量测指标监测数据组并行执行查询处理,以获得各个量测指标监测数据组各自对应的第一类查询结果。其中,第一查询逻辑可包括但不限于求和、求均值、求中值、求最值、求插值和求积中的一种或多种组合,本实施例对此不做限定。
其中,第一查询逻辑可以是指在单个量测指标下对量测指标监测数据执行的处理逻辑。不同的量测指标对应的第一查询逻辑可不完全相同。例如,在量测指标CPU下的第一查询逻辑可以是求均值,而在量测指标memory下的第一查询逻辑可以是求和。丰富多样的第一查询逻辑可有效提升查询指令的多样性,从而支持更多更复杂的查询需求。
基于步骤101中执行的分组操作,在步骤102中,可对不同的量测指标监测数据组并行执行查询处理,并行处理的方式可有效提高查询效率。参考图2,通过对不同的量测指标监测数据组执行查询处理,可获得各个量测指标监测数据组各自对应的第一类查询结果。
在一些情况下,查询指令中可能示意以第一类查询结果作为最终的查询结果,对此,本实施例中,可直接将各个量测指标监测数据组各自对应的第一类查询结果输出,作为响应查询指令的最终查询结果。
在另一些情况下,参考图2,查询指令中还可能包含跨数据源的第二查询逻辑,对此,本实施例中,可按照第二查询逻辑对指定的量测指标监测数据组各自对应的第一类查询结果执行查询处理,以获得第二类查询结果;基于第二类查询结果,生成最终查询结果。这类情况下,查询指令中的查询目标能是跨数据源(时间线)的,对此,可在时间线层面执行查询处理。其中,第二查询逻辑也可包括但不限于求和、求均值、求中值、求最值、求插值和求积中的一种或多种组合,本实施例对此不做限定。
本实施例中,查询指令中可能包含一个或多个第二查询逻辑,多个第二查询逻辑所涉及到的数据源可能不完全相同。优选地,本实施例中,可根据查询指令首先确定一个或多个第二查询逻辑所需的数据源(对应于步骤100中的至少一个数据源),再在数据源下确定所需的量测指标,在此基础上,再从时序数据库中读取相关的时序数据,这样,可精准读取所需的时序数据,而避免出现读取后不用的情况,从而可节省数据传输开销。当然,本实施例中,也可根据查询指令确定所需的时间线后,即读取时间线下的全部时序数据,作为查询基础,不再做量测指标的筛选。本实施例对此不做限定。
为便于描述,以下将从单个第二查询逻辑的角度出发,说明查询处理的过程。无论是上述哪种读取范围,本实施例中,可从查询指令中解析第二查询逻辑指定的目标属性标签;基于至少一个数据源各自对应的属性标签,查找与目标属性标签适配的至少一个指定数据源,作为查询指令所需的至少一个数据源;将至少一个指定数据源各自对应的至少一个量测指标监测数据组,作为指定的量测指标监测数据组。应当理解的是,在上述不同的读取范围和不同的第二查询逻辑数量下,指定数据源可以是至少一个数据源中的部分或全部,指定的量测指标监测数据组可以是分组获得的至少一个量测指标监测数据组中的部分或全部。
据此,在这类情况下,可获得至少一个第二类查询结果,并可将第二类查询结果输出,作为响应查询指令的最终查询结果。
另外,值得说明的是,除了上述的针对量测指标层面和针对数据源层面的查询逻辑外,查询指令中还可包含更多层面的查询逻辑,在此不再穷举。更低层面下产生的查询结果可作为更高层面下的查询基础,这样,可实现自下而上迭代查询,从而获得查询指令所需的最终查询结果,而在每种层面内部,则可支持并行查询处理,因此,可保证查询效率的提升。
综上,本实施例中,在面向时序数据库进行查询的过程中,可以量测指标作为分组依据,对数据源产生的时序数据进行分组,以获得量测指标监测数据组;在此基础上,可在不同的量测指标监测数据组下并行执行查询操作,并可分别获得不同的量测指标监测数据组下的查询结果,这类查询结果可作为生成最终查询结果的基础。据此,本申请实施例中,可通过以量测指标为维度的分组机制,实现对不同量测指标监测数据组的并行执行查询处理,这可有效提高查询效率。
在上述或下述实施例中,可采用按列读取的方式,从时序数据库中读取所需的至少一个数据源产生的时序数据。
本实施例中,时序数据库中可以时间线为单位进行时序数据的存储,而在单条时间线下,可将相同量测指标对应的量测指标监测数据按列存储。按列存储的效果可参考图3中的value列和图4中的温度列和描述列。基于此,参考图2,本实施例中,可针对目标数据源下的目标量测指标,按列读取目标量测指标下的量测指标监测数据。按列读取的方式与传统的volcano模型采用的按行读取的方式相比,可更加适配时间序列数据库的特点,无需再每次读取一行数据再从以上数据中甄选出所需列的数据,因此,可大大节省数据传输开销,提高读取效率,进而提升查询效率。
另外,参考图2,本实施例中,在不同量测指标下的按列读取操作可并行执行。也即是,在从目标量测指标下读取所需的量测指标监测数据的过程中,并行执行在目标数据源中其它量测指标以及其它数据源中各量测指标下读取量测指标监测数据的操作,其中,目标数据源为至少一个数据源中的任意一个,目标量测指标为目标数据源包含的至少一个量测指标中的任意一个。例如,可并行读取图4中温度列和描述列下所需的量测指标监测数据。
在按列读取的基础上,本实施例中,还可采用流式读取的方式,从时序数据库中读取所需的至少一个数据源产生的时序数据,也即是,采用按列流式读取的方式读取所需的时序数据。可选地,本实施例中,可采用按批batch等方式进行按列流式读取操作。
在一种示例性的实现方案中,还是以上述的目标数据源为例:可根据查询指令,确定在目标数据源中目标量测指标下的读取起点;按照预设的单次读取长度,从目标量测指标下的读取起点开始,流式读取在目标量测指标下所需的量测指标监测数据。其中,单次读取长度可按需进行自定义。
在该实现方案中,可在时序数据库的某一列下首先确定读取起点,之后按照读取频率和单次读取长度,持续(也即流式)读取该列下所需的量测指标监测数据。例如,若根据查询指令确定在图4所示时间线中的温度列下的读取起点为2020-10-24 10:02,读取终点为2020-10-24 10:03,而单次读取长度为1,则可首先读取温度列下的13.2,下一次再继续读取温度列下的10.6,从而完成温度列的读取工作。
同样,在不同量测指标下的按列流式读取操作也可并行执行,在此不再详述。
与流式读取方式相适配地,本实施例中,可采用流式的方式对时序数据执行分组操作。对此,还是以上述的目标量测指标为例,本实施例中,可为从目标量测指标下单次读取到的量测指标监测数据,添加目标量测指标对应的分组标识,以对目标数据源下的量测指标监测数据进行流式分组。其中,分组标识中可包含目标量测指标信息和目标数据源信息,以区分不同数据源下的目标量测指标。实际应用中,可为每次读取操作读取到的量测指标监测数据添加目标量测指标对应的分组标识,这样,每次读取到的量测指标监测数据都可被分配到正确地的量测指标监测数据组中,从而保证每个量测指标监测数据组中流式加入的量测指标监测数据的正确性。
另外,与流式读取方式和流式分组方式相适配地,本实施例中,还可采用流式方式进行查询处理操作。对此,还是以上述的目标量测指标为例,本实施例中,可按照查询指令中针对量测指标的第一查询逻辑,对目标量测指标下的初次读取到的量测指标监测数据执行查询处理,以获得初次查询结果;在初次查询结果的基础上,按照第一查询逻辑,依次融合后续各次读取操作所读取到的量测指标监测数据,以获得目标量测指标对应的第一类查询结果。例如,单次读取长度为5的情况下,初次读取后,可按照读取到的5个量测指标监测数据执行第一查询逻辑(如Sam计算),获得查询结果sam1;下一次读取操作,又读取到5个量测指标监测数据,则可对sam1和新读取到的5个量测指标监测数据执行sam计算,获得查询结果sam2,之后又一次读取操作,读取了最后3个量测指标监测数据,则可对sam2和新读取到的3个量测指标监测数据执行sam计算,以获得目标量测指标对应的第一类查询结果。
优选地,本实施例中,还可采用HTTP chunk等流式传输方式,输出最终查询结果,以适配本实施例中的流式查询处理方式。
据此,本实施例中,可采用按列流式读取方式、流式分组方式、流式查询处理方式,实现对时序数据库的流式查询,流式查询的方式对内存的占用量较少,尤其是查询数据量比较大的情况下,可有效节省内存资源。
需要说明的是,上述实施例所提供方法的各步骤的执行主体均可以是同一设备,或者,该方法也由不同设备作为执行主体。比如,步骤100至步骤102的执行主体可以为设备A;又比如,步骤100和101的执行主体可以为设备A,步骤102的执行主体可以为设备B;等等。
另外,在上述实施例及附图中的描述的一些流程中,包含了按照特定顺序出现的多个操作,但是应该清楚了解,这些操作可以不按照其在本文中出现的顺序来执行或并行执行,操作的序号如100、101等,仅仅是用于区分开各个不同的操作,序号本身不代表任何的执行顺序。另外,这些流程可以包括更多或更少的操作,并且这些操作可以按顺序执行或并行执行。需要说明的是,本文中的“第一”、“第二”等描述,是用于区分不同的查询逻辑等,不代表先后顺序,也不限定“第一”和“第二”是不同的类型。
图5为本申请另一示例性实施例提供的一种计算设备的结构示意图。如图5所示,该计算设备可包括:存储器50、处理器51。
处理器51,与存储器50耦合,用于执行存储器70中的计算机程序,以用于:
响应于查询指令,从时序数据库中读取所需的至少一个数据源产生的时序数据;
以量测指标作为分组依据,分别在至少一个数据源下对时序数据进行分组,以获得至少一个数据源各自对应的至少一个量测指标监测数据组;
按照查询指令中针对量测指标的第一查询逻辑,对至少一个数据源各自对应的至少一个量测指标监测数据组并行执行查询处理,以获得各个量测指标监测数据组各自对应的第一类查询结果;
基于至少一个第一类查询结果,生成最终查询结果。
在一可选实施例中,处理器51在基于至少一个第一类查询结果,生成最终查询结果过程中,用于:
若查询指令中还包含跨数据源的第二查询逻辑,按照第二查询逻辑对指定的量测指标监测数据组各自对应的第一类查询结果执行查询处理,以获得第二类查询结果;
基于第二类查询结果,生成最终查询结果。
在一可选实施例中,处理器51还用于:
从查询指令中解析第二查询逻辑指定的目标属性标签;
基于至少一个数据源各自对应的属性标签,查找与目标属性标签适配的至少一个指定数据源;
将至少一个指定数据源各自对应的至少一个量测指标监测数据组,作为指定的量测指标监测数据组。
在一可选实施例中,处理器51在从时序数据库中读取所需的至少一个数据源产生的时序数据过程中,用于:
从时序数据库中按列读取所需的至少一个数据源产生的时序数据;
其中,在同一数据源下,相同量测指标对应的量测指标监测数据按列存储。
在一可选实施例中,处理器51在从时序数据库中按列读取所需的至少一个数据源产生的时序数据过程中,用于:
针对目标数据源,根据查询指令,确定在目标数据源中目标量测指标下的读取起点;
按照预设的单次读取长度,从目标量测指标下的读取起点开始,流式读取在目标量测指标下所需的量测指标监测数据;
其中,目标数据源为至少一个数据源中的任意一个,目标量测指标为目标数据源包含的至少一个量测指标中的任意一个。
在一可选实施例中,处理器51在以量测指标作为分组依据,分别在至少一个数据源下对时序数据进行分组过程中,用于:
为从目标量测指标下单次读取到的量测指标监测数据,添加目标量测指标对应的分组标识,以对目标数据源下的量测指标监测数据进行流式分组。
在一可选实施例中,处理器51在按照查询指令中针对量测指标的第一查询逻辑,对至少一个数据源各自对应的至少一个量测指标监测数据组并行执行查询处理过程中,用于:
按照查询指令中针对量测指标的第一查询逻辑,对目标量测指标下的初次读取到的量测指标监测数据执行查询处理,以获得初次查询结果;
在初次查询结果的基础上,按照第一查询逻辑,依次融合后续各次读取操作所读取到的量测指标监测数据,以获得目标量测指标对应的第一类查询结果。
在一可选实施例中,处理器51还用于:
在从目标量测指标下读取所需的量测指标监测数据的过程中,并行执行在目标数据源中其它量测指标以及其它数据源中各量测指标下读取量测指标监测数据的操作;
其中,目标数据源为至少一个数据源中的任意一个,目标量测指标为目标数据源包含的至少一个量测指标中的任意一个。
在一可选实施例中,不同量测指标对应的第一查询逻辑不完全相同。
在一可选实施例中,查询指令包括数据聚合指令。
进一步,如图5所示,该计算设备还可包括:通信组件52、电源组件53等其它组件。图5中仅示意性给出部分组件,并不意味着计算设备只包括图5所示组件。
值得说明的是,上述关于物理网卡各实施例中的技术细节,可参考前述的系统实施例中关于第一物理网卡和第二物理网卡的相关描述,为节省篇幅,在此不再赘述,但这不应造成本申请保护范围的损失。
相应地,本申请实施例还提供一种存储有计算机程序的计算机可读存储介质,计算机程序被执行时能够实现上述方法实施例中可由故障监测系统执行的各步骤。
相应地,本申请实施例还提供一种计算机程序产品,包括计算机程序/指令,其中,当计算机程序被处理器执行时,致使处理器实现前述述查询方法中的步骤。该计算机程序产品可以是数据库查询软件,也可以是集成了对数据库进行查询的能力的其它应用软件,比如故障监测软件等。
上述图5中的存储器,用于存储计算机程序,并可被配置为存储其它各种数据以支持在计算平台上的操作。这些数据的示例包括用于在计算平台上操作的任何应用程序或方法的指令,联系人数据,电话簿数据,消息,图片,视频等。存储器可以由任何类型的易失性或非易失性存储设备或者它们的组合实现,如静态随机存取存储器(SRAM),电可擦除可编程只读存储器(EEPROM),可擦除可编程只读存储器(EPROM),可编程只读存储器(PROM),只读存储器(ROM),磁存储器,快闪存储器,磁盘或光盘。
上述图5中的通信组件,被配置为便于通信组件所在设备和其他设备之间有线或无线方式的通信。通信组件所在设备可以接入基于通信标准的无线网络,如WiFi,2G、3G、4G/LTE、5G等移动通信网络,或它们的组合。在一个示例性实施例中,通信组件经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中,所述通信组件还包括近场通信(NFC)模块,以促进短程通信。例如,在NFC模块可基于射频识别(RFID)技术,红外数据协会(IrDA)技术,超宽带(UWB)技术,蓝牙(BT)技术和其他技术来实现。
上述图5中的电源组件,为电源组件所在设备的各种组件提供电力。电源组件可以包括电源管理系统,一个或多个电源,及其他与为电源组件所在设备生成、管理和分配电力相关联的组件。
本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中,计算设备包括一个或多个处理器 (CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器 (RAM) 和/或非易失性内存等形式,如只读存储器 (ROM) 或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存 (PRAM)、静态随机存取存储器 (SRAM)、动态随机存取存储器 (DRAM)、其他类型的随机存取存储器 (RAM)、只读存储器 (ROM)、电可擦除可编程只读存储器 (EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘 (DVD) 或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体 (transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的保护范围之内。