CN117708236A - 时序数据库分库控制方法以及相关设备 - Google Patents

Abstract

本申请提供了一种时序数据库分库控制方法以及相关设备，方法包括：配置预设的分库策略，根据分库策略计算监控资源对应的关联关系，并将关联关系存入Redis数据库，关联关系用于确定监控资源对应的时序数据库和Kafka信息；确定数据报文对应的目标监控资源，并基于Redis数据库中的分库策略和关联关系，确定对应的目标时序数据库和目标Kafka信息，其中，不同的监控资源对应生成不同的数据报文；将挂载有目标时序数据库和目标Kafka信息的数据报文发送至对应的kafka主题，以使kafka主题消费数据报文时，将数据报文中数据库信息插入至目标时序数据库，进而基于时序数据库提高了数据插入的性能，以实现更高效和节约资源的数据管理。

Description

时序数据库分库控制方法以及相关设备

技术领域

本申请涉及运维监控技术领域，尤其涉及一种时序数据库分库控制方法以及相关设备。

背景技术

当前，随着云计算和大数据技术的发展，云监控及运维监控成为保障系统稳定运行的关键环节，在这样的背景下，云监控、运维监控以及容器监控等系统，通常需要处理巨量的数据并保障数据的隔离性，其中，这些系统倾向于使用诸如ElasticSearch(ES)集群这样的技术来存储监控数据，ES集群能够处理高速的数据写入，支持数据的快速增长，进而实现对数据的存储；

然而，在当前ES集群的实际应用过程中，会存在数据插入量过大导致集群磁盘IO承受不住压力，从而影响整个系统的稳定性和响应速度的情况发生，具体的，当数据插入并发量大到一定程度时，单一ES集群的存储能力和插入线程的处理能力均会受到严重影响，导致服务中断或性能下降，这不仅影响数据存储的效率，而且还可能影响到其他所有业务的正常运行。

发明内容

以下是对本文详细描述的主题的概述。本概述并非是为了限制权利要求的保护范围。

本申请实施例提供了一种时序数据库分库控制方法以及相关设备，旨在解决现有技术中前ES集群的实际应用过程中，会存在数据插入量过大导致集群磁盘IO承受不住压力，从而影响整个系统的稳定性和响应速度的技术问题。

为实现上述目的，本申请实施例的第一方面提出了一种时序数据库分库控制方法，所述方法应用于所述时序数据库分库系统，所述系统包括接口层、控制层和执行层，所述方法包括：

配置预设的分库策略，并将所述分库策略存入Redis数据库；

根据所述分库策略计算所述监控资源对应的关联关系，并将所述关联关系存入所述Redis数据库，所述关联关系用于确定所述监控资源对应的时序数据库和Kafka信息；

获取数据报文，确定所述数据报文对应的目标监控资源，并基于所述Redis数据库中的所述分库策略和所述关联关系，确定所述目标监控资源对应的目标时序数据库和目标Kafka信息，其中，所述不同的监控资源对应生成不同的数据报文；

将挂载有所述目标时序数据库和所述目标Kafka信息的所述数据报文发送至对应的kafka主题，以使所述kafka主题消费所述数据报文时，将所述数据报文中数据库信息插入至所述目标时序数据库。

在一些实施例中，所述根据所述分库策略计算所述监控资源对应的关联关系，并将所述关联关系存入所述Redis数据库，包括：

通过所述控制层编写所述分库策略对应的分库算法；

获取所述监控资源的租户、ip和资源类型；

通过所述执行层执行所述分库算法，以根据所述监控资源的租户、ip和资源类型计算所述监控资源与所述时序数据库之间的第一关联关系；

获取所述时序数据库与所述Kafka信息之间的第二关联关系；

将所述第一关联关系和所述第二关联关系存入所述Redis数据库。

在一些实施例中，所述分库算法包括hash一致性算法，所述根据所述监控资源的租户、ip和资源类型计算所述监控资源与所述时序数据库之间的第一关联关系，包括：

根据所述监控资源的租户、ip和资源类型计算所述监控资源对应的hash值；

对多个所述时序数据库进行编码处理，根据编码结果将多个所述时序数据库分布在预设的库编码轮盘上，以使多个所述时序数据库对应不同的编码范围；

根据所述监控资源的hash值落入的所述编码范围，划分所述监控资源应存储于的所述时序数据库，以得到所述监控资源与所述时序数据库之间的第一关联关系。

在一些实施例中，所述hash值的取值范围为0到2的32次方，所述对多个所述时序数据库进行编码处理，根据编码结果将多个所述时序数据库分布在预设的库编码轮盘上，以使多个所述时序数据库对应不同的编码范围，包括：

根据所述hash值的取值范围多个所述时序数据库进行编码处理，以确定多个所述时序数据库对应的编码值；

根据所述编码值的大小顺序将多个所述时序数据库分布在预设的库编码轮盘上；

将相邻的两个所述时序数据库之间的编码范围，确定为右侧的所述时序数据库对应的编码范围。

在一些实施例中，所述将所述数据报文中数据库信息插入至所述目标时序数据库之后，所述方法还包括：

获取待查询数据，并确定所述待查询数据对应的所述监控资源的租户、ip和资源类型；

确定所述待查询数据对应的时间维度；

基于所述Redis数据库，从中确定所述监控资源和所述时间维度对应的所述目标时序数据库，以根据所述目标时序数据库得到对应的看板数据和报表数据。

在一些实施例中，所述将挂载有所述目标时序数据库和所述目标Kafka信息的所述数据报文发送至对应的kafka主题，包括：

根据所述分库策略配置至少一个kafka集群，所述kafka集群包括多个kafka主题；

根据所述目标Kafka信息确定对应的kafka主题，以将挂载有所述目标时序数据库和所述目标Kafka信息的所述数据报文发送至对应的kafka主题。

为实现上述目的，本申请实施例的第二方面提出了一种时序数据库分库控制装置，所述时序数据库分库控制装包括：

分库策略配置单元，用于配置预设的分库策略，并将所述分库策略存入Redis数据库；

资源上报单元，用于根据所述分库策略计算监控资源对应的关联关系，并将所述关联关系存入所述Redis数据库，所述关联关系用于确定所述监控资源对应的时序数据库和Kafka信息；

数据上报单元，用于获取数据报文，确定所述数据报文对应的目标监控资源，并基于所述Redis数据库中的所述分库策略和所述关联关系，确定所述目标监控资源对应的目标时序数据库和目标Kafka信息，其中，所述不同的监控资源对应生成不同的数据报文；

数据库分库单元，用于将挂载有所述目标时序数据库和所述目标Kafka信息的所述数据报文发送至对应的kafka主题，以使所述kafka主题消费所述数据报文时，将所述数据报文中数据库信息插入至所述目标时序数据库。

为实现上述目的，本申请实施例的第三方面提出了一种时序数据库分库系统，包括：接口层、控制层和执行层；

所述接口层，用于配置预设的分库策略，并将所述分库策略存入Redis数据库；

所述控制层，用于编写所述分库策略对应的分库算法；

所述执行层，用于根据所述分库策略对应的所述分库算法计算监控资源对应的关联关系，并将所述关联关系存入所述Redis数据库，所述关联关系用于确定所述监控资源对应的时序数据库和Kafka信息；以及用于获取数据报文，确定所述数据报文对应的目标监控资源，并基于所述Redis数据库中的所述分库策略和所述关联关系，确定所述目标监控资源对应的目标时序数据库和目标Kafka信息，其中，所述不同的监控资源对应生成不同的数据报文；以及用于将挂载有所述目标时序数据库和所述目标Kafka信息的所述数据报文发送至多个kafka集群，以使多个所述kafka集群中kafka主题消费所述数据报文时，将所述数据报文中数据库信息插入至所述目标时序数据库。

为实现上述目的，本申请实施例的第四方面提出了一种电子设备，所述电子设备包括存储器、处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现上述第一方面所述的方法。

为实现上述目的，本申请实施例的第五方面提出了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述第一方面所述的方法。

本申请提供的时序数据库分库控制方法以及相关设备，具有以下有益效果：首先，本申请通过配置预设的分库策略，并将分库策略的存储在Redis数据库中，提高了访问效率和策略调用的速度；其次，本申请通过计算监控资源的关联关系并将其存储，通过确定资源与监控数据库之间的映射过程，以确保后续数据能快速、准确的插入到正确的时序数据库中；进一步的，通过判断数据报文对应的目标监控资源，并利用Redis数据库中的分库策略和关联关系，确定目标时序数据库和Kafka信息，实现了数据流向的智能化控制，以降低了因数据插入并发量大导致的性能瓶颈，从而增强了系统的数据处理能力和响应速度；最终，本申请通过将数据报文导向对应的Kafka主题，并确保Kafka主题可以消费数据报文，使得数据能够正确的、高效的插入至目标时序数据库，进而减轻了单一数据库的负担，实现数据库分库系统动态扩展，并增加整个数据库分库系统的可靠性，综上，本申请通过采用时序数据库的分库策略，以利用时序数据库特性降低存储成本，并提升数据处理效率，进而减少了对单一磁盘IO的依赖，提高了数据插入的性能，以实现更高效和节约资源的数据管理。

附图说明

图1是本申请实施例提供的时序数据库分库控制方法的流程示意图；

图2是本申请另一实施例提供的时序数据库分库控制方法的流程示意图；

图3是本申请另一实施例提供的时序数据库分库控制方法的流程示意图；

图4是本申请另一实施例提供的时序数据库分库控制方法的流程示意图；

图5是本申请另一实施例提供的时序数据库分库控制方法的流程示意图；

图6是本申请另一实施例提供的时序数据库分库控制方法的流程示意图；

图7是本申请另一实施例提供的时序数据库分库系统的结构示意图；

图8是本申请实施例提供的电子设备的硬件结构示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。

需要说明的是，虽然在装置示意图中进行了功能模块划分，在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于装置中的模块划分，或流程图中的顺序执行所示出或描述的步骤。说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

当前，随着云计算和大数据技术的发展，云监控及运维监控成为保障系统稳定运行的关键环节，在这样的背景下，云监控、运维监控以及容器监控等系统，通常需要处理巨量的数据并保障数据的隔离性，其中，这些系统倾向于使用诸如ElasticSearch(ES)集群这样的技术来存储监控数据，ES集群能够处理高速的数据写入，支持数据的快速增长，进而实现对数据的存储；然而，在当前ES集群的实际应用过程中，会存在数据插入量过大导致集群磁盘IO承受不住压力，从而影响整个系统的稳定性和响应速度的情况发生，具体的，当数据插入并发量大到一定程度时，单一ES集群的存储能力和插入线程的处理能力均会受到严重影响，导致服务中断或性能下降，这不仅影响数据存储的效率，而且还可能影响到其他所有业务的正常运行。

基于此，本申请实施例提供了一种时序数据库分库控制方法以及相关设备，可以基于时序数据库提高了数据插入的性能，以实现更高效和节约资源的数据管理，进而解决现有技术中的技术问题，具体通过如下实施例进行说明。

第一方面，请参见图1，图1示出了本申请实施例提供的一种时序数据库分库控制方法，方法应用于时序数据库分库系统，系统包括接口层、控制层和执行层，如图1所示，时序数据库分库控制方法包括但不限于步骤S110至步骤S140：

步骤S110，配置预设的分库策略，并将分库策略存入Redis数据库；

步骤S120，根据分库策略计算监控资源对应的关联关系，并将关联关系存入Redis数据库，关联关系用于确定监控资源对应的时序数据库和Kafka信息；

步骤S130，获取数据报文，确定数据报文对应的目标监控资源，并基于Redis数据库中的分库策略和关联关系，确定目标监控资源对应的目标时序数据库和目标Kafka信息，其中，不同的监控资源对应生成不同的数据报文；

步骤S140，将挂载有目标时序数据库和目标Kafka信息的数据报文发送至对应的kafka主题，以使kafka主题消费数据报文时，将数据报文中数据库信息插入至目标时序数据库。

在一些实施例中，本申请中的时序数据库分库系统按职责可以划分为接口层、控制层和执行层,其中，接口层用于定义分库的策略、看板、报表接口，入参及返回值定义等；控制层用于负责分库算法的编写，将输入参数传递进各实现模块方法并返回数据；执行层用于根据接口约定实现各模块方法，数据按照算法入库等等具体功能，以使数据库可以实现按照定时任务做聚合表等功能，进而在数据入库时定时生成聚合数据来满足报表和看板的查询。

在一些实施例中，步骤S110通过接口层配置预设的分库策略，这使得数据管理变得更为灵活和高效，分库策略的存储在Redis数据库中，提高了访问效率和策略调用的速度，也方便了策略的动态调整和优化。

在一些实施例中，时序数据库分库系统的接口层可以通过系统的配置界面，获取用户输入的分库策略配置参数，进而进行分库策略的设定，如定义分库的策略、看板、报表接口，入参及返回值定义等分库规则，从而在后续步骤中可以通过分库规则获取关联关系，并把相关的信息存到redis数据库中。

在一些实施例中，步骤S120为资源上报的过程，本申请系统可以实时获取待处理的监控资源，然后通过计算监控资源的关联关系并将其存储，优化了资源与监控数据库之间的映射过程，这种优化确保了数据的快速、准确的插入到正确的时序数据库中，提升了数据处理的精准性和系统的稳定性，其中，上述“监控资源”应该可以包括具体数据库的实例对象，而这些监控资源在运行过程中会产生的状态信息、指标信息等数据，如包括数据库实例的读写情况等运行数据，当新的运行数据产生时，这些数据以数据报文的形式发送到系统，实现数据上报。

在一些实施例中，在通过界面配置获取分库策略后，可以根据分库策略和监控资源的资源IP段算出对应资源和对应时序库的关联关系，同时计算出时序库和kafka信息的关联关系，并将这些信息储存在redis中，其中，Kafka是一种分布式流处理平台，它能够处理和存储数据流，同时还能对数据流进行处理和分析，kafka主要被用作实时的日志聚合系统，由Kafka集群保存和处理这些实时数据，本申请中，Kafka信息包括Kafka传输的消息数据，以及Kafka集群的配置或状态信息，可以作为一种持久化存储，用于数据的发布和订阅，这里的数据可以是传感器数据、日志数据、用户行为数据等等；redis数据库是一个开源的高性能键-值数据库，可以储存键和值之间的映射，这个映射被存到计算机的内存中，因此读写速度非常快，且Redis的数据也可以定期写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了基于复制的主-从异步同步，故在本申请中，redis数据库被用作中间存储介质，保存分库策略、资源IP和租户、产品类型等信息。

其中，本申请使用Kafka信息对应Kafka集群作为数据报文的中转，使得每个时序数据库以及对应的Kafka信息会被打包进数据报文并发送至对应的Kafka主题，这样，消费Kafka主题的程序可以根据数据报文中的数据库信息，将数据插入至正确的时序数据库，进而在拥有多个Kafka集群时，可以多块盘同时写入，可以避免像es这种集群部署时对master节点线程数据的依赖，集群之间的自平衡策略等、磁盘IO的性能瓶颈，降低了各业务模块之间业务的相互影响。

在一些实施例中，步骤S130通过判断数据报文对应的目标监控资源，并利用Redis数据库中的分库策略和关联关系，确定目标时序数据库和Kafka信息，实现了数据流向的智能化控制。这种方法降低了因数据插入并发量大导致的性能瓶颈，从而增强了系统的数据处理能力和响应速度，其中，数据报文中会包含数据对应的监控资源的ID和类型等参数，进而使得系统可以在查阅redis中的策略信息，找出对应的数据库，以及该数据库对应的kafka信息，然后将kafka信息挂载在数据报文上，以将数据报文发送到对应的kafka主题中进行消费分库。

在一些实施例中，步骤S140通过有效的将数据报文导向对应的Kafka主题，并确保Kafka主题可以消费数据报文，使得数据能够正确的、高效的插入至目标时序数据库，进而可以减轻单一数据库的负担，并增加了整个监控系统的可扩展性和可靠性。

在一些实施例中，Kafka主题以当做发布/订阅模式下的分类名或者种类型的数据流，发布者可以往主题中发送消息，订阅者从主题中读取消息，Kafka主题中的数据可以被划分为多个分区，同一个Kafka主题的各个分区的数据可以分布在Kafka集群的不同服务器上，故当新的运行数据产生时，这些数据以报文的形式发送到系统，系统会查阅redis数据库中的策略信息，找出该资源对应哪个数据库，以及该数据库对应的kafka信息，然后挂载在报文上，这个数据将会被发送到对应的kafka主题中，kafka主题所在的kafka集群会持续消费各个主题上的数据，当一个数据报文被消费时，kafka会查看报文挂上的数据库信息，然后把这个数据插入到对应的数据库中，进而实现了对时序数据库的动态扩展和智能分库。

在一些实施例中，通过上述步骤S110至步骤S140，本申请通过基于时序数据库进行分库策略，可以实现在界面配置预设的分库策略后，把策略存入redis数据库，在资源上报的时候查询分库策略把资源和库和kafka信息挂上存入redis，在数据上报的时候按照资源在报文上挂上分库策略以及发往对应的kafka信息，并在数据处理完后按照报文中数据库信息插入到对应库中的分库控制过程，进而可以克服现有技术的局限，通过利用时序数据库在数据插入、压缩、自动淘汰等方面的优势，使得本申请可以实现更高效和节约资源的数据管理，其中，时序数据库的高压缩比可以降低存储成本，其数据插入的高性能及自动淘汰机制显著可以提升数据处理效率，此外，上述分库策略还可以减少对单一磁盘IO的依赖，提高了数据插入的性能，此外，还可以使用时序数据库通过定时聚合任务优化看板和报表的查询过程。

可以想到的是，当前使用ES集群做存储的现有技术中还存在耗费资源过多，导致数据库集群需要的资源量非常多、集群库在做数据淘汰的时候会出现自平衡的现象，由于本身插入量太大会导致集群出现故障等问题，但由于本申请使用的时序数据库具有数据插入高压缩比、数据插入高性能、高效数据聚合、数据自动淘汰机制等特性，故在本申请实现分库以及动态扩展数据库的过程中，本申请可以有效克服上述现有技术问题，具体的，数据插入高压缩比、数据插入高性能、高效数据聚合的特性可以有效克服存在耗费资源过多，导致数据库集群需要的资源量非常多、由于本身插入量太大会导致集群出现故障的技术问题；数据自动淘汰机制的特性可以有效克服集群库在做数据淘汰的时候会出现自平衡的现象的技术问题；

同时，由于时序数据库可以按照定时任务做聚合表，故在步骤S140之后，还可以包括，在数据入库时定时生成聚合数据来满足报表和看板的查询需求，数据查询时，按照Redis数据库中的分库策略和关联关系找到对应库并查询相关数据，以根据相关数据进行长时间维度的看板查询和报表输出，进而解决现有技术中数据量太大，不能支持过长时间维度的看板查询和报表输出的技术问题。

请参见图2，图2示出了本申请实施例提供的一种时序数据库分库控制方法，其中，根据分库策略计算监控资源对应的关联关系，并将关联关系存入Redis数据库包括但不限于步骤S210至步骤S250：

步骤S210，编写分库策略对应的分库算法；

步骤S220，获取监控资源的租户、ip和资源类型；

步骤S230，执行分库算法，以根据监控资源的租户、ip和资源类型计算监控资源与时序数据库之间的第一关联关系；

步骤S240，获取时序数据库与Kafka信息之间的第二关联关系；

步骤S250，将第一关联关系和第二关联关系存入Redis数据库。

在一些实施例中，分库算法是分库策略实施过程中使用的具体技术方法，用于确定数据具体应该存储在哪一个数据库或数据库实例中。

在一些实施例中，当新的监控资源(如服务器、应用等)加入到系统中，这些资源的信息会被上报到系统中，系统会根据之前设置的分库策略，为这个新的资源找到一个最适合的数据库，并自动将资源的信息、对应数据库的信息、以及对应的kafka信息连接起来，即对应监控资源与时序数据库之间的第一关联关系，以及时序数据库与Kafka信息之间的第二关联关系。

在一些实施例中，监控资源包括运维监控资源和云监控资源，云监控以及运维监控等之间存在数据隔离，业务隔离，数据存储和告警计算要做到相互独立，不能产生互相影响；监控存储采集指标的明细特别大每秒十几w/s的写入量，以及需要支持指标数据快速增长并动态扩容数据存储，故本申请可以根据资源的租户、ip以及资源类型计算监控资源与时序数据库之间的第一关联关系，并在后续过程汇总根据第一关联关系进行分库，进而实现通过按照产品或者租户的方式把相关资源在分库的时候按照算法分到独立的库中，从而实现了按照产品和租户的数据隔离，满足各产品或者各租户之间数据隔离，以同时兼容运维监控资源和云监控资源，解决现有技术中使用同一个库，云监控以及运维监控和各容器监控等等数据不能做到隔离，会导致一个业务出现问题从而影响所有的业务的技术问题。

在一些实施例中，系统中预设有时序数据库和对应的Kafka信息之间对照关系表，故在确定监控资源对应的时序数据库的情况下，可以根据对照关系表获取时序数据库与Kafka信息之间的第二关联关系。

请参见图3，图3示出了本申请实施例提供的一种时序数据库分库控制方法，其中，分库算法包括hash一致性算法，根据监控资源的租户、ip和资源类型计算监控资源与时序数据库之间的第一关联关系包括但不限于步骤S310至步骤S330：

步骤S310，根据监控资源的租户、ip和资源类型计算监控资源对应的hash值；

步骤S320，对多个时序数据库进行编码处理，根据编码结果将多个时序数据库分布在预设的库编码轮盘上，以使多个时序数据库对应不同的编码范围；

步骤S330，根据监控资源的hash值落入的编码范围，划分监控资源应存储于的时序数据库，以得到监控资源与时序数据库之间的第一关联关系；

在一些实施例中，通过上述步骤S310至S330，本申请使用hash一致性算法来实现对应资源固定落到对应库，以保证在数据库扩展的时候数据落库不会发生位置变化，进而实现数据库分库，并确保数据库能动态扩展，其中，hash一致性算法可以直接计算出数据应该分布的数据库位置，查找效率高，且能尽量保证数据在各个数据库之间分布均衡，避免数据倾斜，同时，在扩展或缩小数据库时，可以使得大多数资源仍然保留在原有的数据库中，只有一小部分会在数据库之间进行迁移，这使得系统在进行动态扩展或缩小数据库节点的时候，对已有资源的影响最小化，提升了整体系统的稳定性，并有效处理资源的添加和删除，具有良好的扩展性，可以有效的支持数据库节点的动态扩展和缩小。

请参见图4，图4示出了本申请实施例提供的一种时序数据库分库控制方法，其中，hash值的取值范围为0到2的32次方，对多个时序数据库进行编码处理，根据编码结果将多个时序数据库分布在预设的库编码轮盘上，以使多个时序数据库对应不同的编码范围，包括但不限于步骤S410至步骤S430：

步骤S410，根据hash值的取值范围多个时序数据库进行编码处理，以确定多个时序数据库对应的编码值；

步骤S420，根据编码值的大小顺序将多个时序数据库分布在预设的库编码轮盘上；

步骤S430，将相邻的两个时序数据库之间的编码范围，确定为右侧的时序数据库对应的编码范围；

在一些实施例中，步骤S410中，每个时序数据库被赋予一个编码值。这个编码是基于数据库的特定属性(如资源的租户、IP地址或资源类型)计算得到的哈希值，哈希函数将这些属性映射到一个大范围的整数值上，通常是0到2^32，每个数据库的编码值是其在整个分布式系统中的唯一标识符，这个值确定了该数据库在分布式环境中的位置。

在一些实施例中，步骤S420中，在确定了编码值之后，数据库将根据这些值的大小顺序被放置在一个预设的库编码轮盘上，可以将这个库编码轮盘视为一种逻辑圆环，每个数据库占据圆环上的一个位置，这个圆环的结构便于当新的数据库加入或现有数据库移除时，可以轻松地重新分配和均衡负载。

在一些实施例中，步骤S430中，在编码轮盘上，两个相邻的数据库之间的编码范围被划分给它们之间的右侧数据库，这意味着每个数据库都对应一个编码区间，如果一个资源的哈希值落在这个区间内，那么这个资源就被分配到该数据库，当数据库轮盘上的节点增加或减少时，这些范围会相应地调整，但是由于是基于哈希的一致性算法，所以整体的调整是最小化的，大部分资源会保持在原有的数据库。

请参见图5，图5示出了本申请实施例提供的一种时序数据库分库控制方法，其中，将数据报文中数据库信息插入至目标时序数据库之后，方法还包括但不限于步骤S510至步骤S530：

步骤S510，获取待查询数据，并确定待查询数据对应的监控资源的租户、ip和资源类型；

步骤S520，确定待查询数据对应的时间维度；

步骤S530，基于Redis数据库，从中确定监控资源和时间维度对应的目标时序数据库，以根据目标时序数据库得到对应的看板数据和报表数据；

在一些实施例中，步骤S510需要确定要查询的数据，并确定要查询的数据对应的监控资源的信息，包括租户的身份、该租户的IP地址和资源类型；步骤S520需要确定要查询的数据的时间范围；步骤S530将根据在步骤S510和S520中确定的参数，从Redis数据库中查询数据，进而检索到你的目标资源和时间范围对应的信息，具体的，本申请系统可以包括监控看板，监控看板通过接口层调用ip以及租户和产品类型查询分库的redis数据库获取要查询的库，并按照时间维度来判断是查询聚合库还是明细库,从而去对应库查出对应的信息，从而在对应库中查询出相关的看板数据和报表数据，满足报表和看板的查询需求，其中，由于本申请是基于世界数据库进行数据查询的，故根据时间维度，步骤S530还可以包括，根据时间维度定时生成聚合数据，以进行长时间维度的看板查询和报表输出。

具体的，当需要查询监控数据时(例如查看看板或生成报表)，查询系统会先在redis中查找资源对应的数据库信息，并根据时间维度和其他查询条件，确定是查询聚合数据还是原始数据，并向对应的数据库发起查询，在数据库返回查询结果，系统可以对查询结果处理后展示在监控看板上。

请参见图6，图6示出了本申请实施例提供的一种时序数据库分库控制方法，其中，将挂载有目标时序数据库和目标Kafka信息的数据报文发送至对应的kafka主题包括但不限于步骤S310至步骤S330：

步骤S610，根据分库策略配置至少一个kafka集群，kafka集群包括多个kafka主题；

步骤S620，根据目标Kafka信息确定对应的kafka主题，以将挂载有目标时序数据库和目标Kafka信息的数据报文发送至对应的kafka主题；

在一些实施例中，因为本申请中的数据明细是根据消费kafka主题来插入到对应时序库中，故在分库策略中可以配置对应数量的kafka集群，也就是说当一个kafka集群无法承担海量数据的吞吐时，本申请可以分kafka集群进行消费插入，以解决数据插入并发特别大的时候，使用单集群库来存储会出现插入线程太多并发过载的技术问题。

第二方面，本申请实施例还提供了一种时序数据库分库控制装置，其特征在于，时序数据库分库控制装包括：分库策略配置单元，用于配置预设的分库策略，并将分库策略存入Redis数据库；资源上报单元，用于根据分库策略计算监控资源对应的关联关系，并将关联关系存入Redis数据库，关联关系用于确定监控资源对应的时序数据库和Kafka信息；数据上报单元，用于获取数据报文，确定数据报文对应的目标监控资源，并基于Redis数据库中的分库策略和关联关系，确定目标监控资源对应的目标时序数据库和目标Kafka信息，其中，不同的监控资源对应生成不同的数据报文；数据库分库单元，用于将挂载有目标时序数据库和目标Kafka信息的数据报文发送至对应的kafka主题，以使kafka主题消费数据报文时，将数据报文中数据库信息插入至目标时序数据库。

第三方面，本申请实施例还提供了一种时序数据库分库系统，包括：接口层、控制层和执行层；接口层用于，接口层，用于配置预设的分库策略，并将分库策略存入Redis数据库；控制层，用于编写分库策略对应的分库算法；执行层，用于根据分库策略对应的分库算法计算监控资源对应的关联关系，并将关联关系存入Redis数据库，关联关系用于确定监控资源对应的时序数据库和Kafka信息；以及用于获取数据报文，确定数据报文对应的目标监控资源，并基于Redis数据库中的分库策略和关联关系，确定目标监控资源对应的目标时序数据库和目标Kafka信息，其中，不同的监控资源对应生成不同的数据报文；以及用于将挂载有目标时序数据库和目标Kafka信息的数据报文发送至多个kafka集群，以使多个kafka集群中kafka主题消费数据报文时，将数据报文中数据库信息插入至目标时序数据库。

其中，接口层主要用于定义分库的策略、看板、报表接口，入参及返回值定义等参数配置处理，控制层主要用于负责分库算法的编写，将输入参数传递进各实现模块方法并返回数据，执行层则用于根据接口层配置的参数，调用接口约定实现各模块方法以及通过控制层调用分库算法，以实现资源上报、数据上报以及消费分库等具体功能。

具体的，参考图7，图7对应了本申请中执行层进行资源上报、数据上报以及消费分库的过程，可以用看出，本申请可以基于Go语言进行系统编程，进而通过gotransit服务，对运维监控和云监控进行采集数据整理过程，以获取对应的资源数据，并可以将获取到的资源数据发生至多个kafka集群中(如kafka集群1、kafka集群2)，且kafka集群还可以通过flink组件(如kafka集群1之间连接的flink1、kafka集群2之间连接的flink2)对资源数据进行告警计算和指标计算处理，处理后的kafka集群在处理器的控制下进行数据消费时，可以根据Redis数据库中的分库策略和关联关系将数据插入至多个时序数据库中(如时序数据库1至4)，以完成时序数据库分库，同时多个时序数据库将存储在服务端，使得用户可以通过服务端对多个时序数据库进行查询，以满足用户对数据报表和数据看板的查询需求，其中，flink组件是一个流计算框架，可以用来处理流式数据，flink组件和处理器均可以部署在本申请系统中的执行层，进而实现对kafka集群的相关计算，以及通过执行go数据插入动作，将kafka集群中的数据库信息插入至目标时序数据库中，实现更高效和节约资源的数据管理。

第四方面，本申请实施例还提供了一种电子设备，电子设备包括：存储器、处理器、存储在存储器上并可在处理器上运行的程序以及用于实现处理器和存储器之间的连接通信的数据总线，程序被处理器执行时实现上述时序数据库分库控制方法。该电子设备可以为包括平板电脑、车载电脑等任意智能终端。

请参阅图8，图8示意了另一实施例的电子设备的硬件结构，电子设备包括：

处理器801，可以采用通用的CPU(CentralProcessingUnit，中央处理器)、微处理器、应用专用集成电路(ApplicationSpecificIntegratedCircuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本申请实施例所提供的技术方案；

存储器802，可以采用只读存储器(ReadOnlyMemory，ROM)、静态存储设备、动态存储设备或者随机存取存储器(RandomAccessMemory，RAM)等形式实现。存储器802可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器802中，并由处理器801来调用执行本申请实施例的时序数据库分库控制方法；

输入/输出接口803，用于实现信息输入及输出；

通信接口804，用于实现本设备与其他设备的通信交互，可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信；

总线805，在设备的各个组件(例如处理器801、存储器802、输入/输出接口803和通信接口804)之间传输信息；

其中处理器801、存储器802、输入/输出接口803和通信接口804通过总线805实现彼此之间在设备内部的通信连接。

第五方面，本申请实施例还提供了一种计算机可读存储介质，计算机可读存储介质存储有一个或者多个程序，一个或者多个程序可被一个或者多个处理器执行，以实现上述时序数据库分库控制方法。

存储器作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序以及非暂态性计算机可执行程序。此外，存储器可以包括高速随机存取存储器，还可以包括非暂态存储器，例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施方式中，存储器可选包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至该处理器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

本申请实施例描述的实施例是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域技术人员可知，随着技术的演变和新应用场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

本领域技术人员可以理解的是，图1至8中示出的技术方案并不构成对本申请实施例的限定，可以包括比图示更多或更少的步骤，或者组合某些步骤，或者不同的步骤。

本申请的说明书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚的列出的那些步骤或单元，而是可包括没有清楚的列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、对应的系统可以被实施为软件、固件、硬件及其适当的组合。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机可读存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机可读存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机可读存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。

以上参照附图说明了本申请实施例的优选实施例，并非因此局限本申请实施例的权利范围。本领域技术人员不脱离本申请实施例的范围和实质内所作的任何修改、等同替换和改进，均应在本申请实施例的权利范围之内。

Claims (10)

1.一种时序数据库分库控制方法，其特征在于，所述方法应用于所述时序数据库分库系统，所述方法包括：

配置预设的分库策略，并将所述分库策略存入Redis数据库；

根据所述分库策略计算监控资源对应的关联关系，并将所述关联关系存入所述Redis数据库，所述关联关系用于确定所述监控资源对应的时序数据库和Kafka信息；

获取数据报文，确定所述数据报文对应的目标监控资源，并基于所述Redis数据库中的所述分库策略和所述关联关系，确定所述目标监控资源对应的目标时序数据库和目标Kafka信息，其中，所述不同的监控资源对应生成不同的数据报文；

将挂载有所述目标时序数据库和所述目标Kafka信息的所述数据报文发送至对应的kafka主题，以使所述kafka主题消费所述数据报文时，将所述数据报文中数据库信息插入至所述目标时序数据库。

2.根据权利要求1所述的时序数据库分库控制方法，其特征在于，所述根据所述分库策略计算所述监控资源对应的关联关系，并将所述关联关系存入所述Redis数据库，包括：

编写所述分库策略对应的分库算法；

获取所述监控资源的租户、ip和资源类型；

执行所述分库算法，以根据所述监控资源的租户、ip和资源类型计算所述监控资源与所述时序数据库之间的第一关联关系；

获取所述时序数据库与所述Kafka信息之间的第二关联关系；

将所述第一关联关系和所述第二关联关系存入所述Redis数据库。

3.根据权利要求2所述的时序数据库分库控制方法，其特征在于，所述分库算法包括hash一致性算法，所述根据所述监控资源的租户、ip和资源类型计算所述监控资源与所述时序数据库之间的第一关联关系，包括：

根据所述监控资源的租户、ip和资源类型计算所述监控资源对应的hash值；

对多个所述时序数据库进行编码处理，根据编码结果将多个所述时序数据库分布在预设的库编码轮盘上，以使多个所述时序数据库对应不同的编码范围；

根据所述监控资源的hash值落入的所述编码范围，划分所述监控资源应存储于的所述时序数据库，以得到所述监控资源与所述时序数据库之间的第一关联关系。

4.根据权利要求3所述的时序数据库分库控制方法，其特征在于，所述hash值的取值范围为0到2的32次方，所述对多个所述时序数据库进行编码处理，根据编码结果将多个所述时序数据库分布在预设的库编码轮盘上，以使多个所述时序数据库对应不同的编码范围，包括：

根据所述hash值的取值范围多个所述时序数据库进行编码处理，以确定多个所述时序数据库对应的编码值；

根据所述编码值的大小顺序将多个所述时序数据库分布在预设的库编码轮盘上；

将相邻的两个所述时序数据库之间的编码范围，确定为右侧的所述时序数据库对应的编码范围。

5.根据权利要求3所述的时序数据库分库控制方法，其特征在于，所述将所述数据报文中数据库信息插入至所述目标时序数据库之后，所述方法还包括：

获取待查询数据，并确定所述待查询数据对应的所述监控资源的租户、ip和资源类型；

确定所述待查询数据对应的时间维度；

基于所述Redis数据库，从中确定所述监控资源和所述时间维度对应的所述目标时序数据库，以根据所述目标时序数据库得到对应的看板数据和报表数据。

6.根据权利要求1所述的时序数据库分库控制方法，其特征在于，所述将挂载有所述目标时序数据库和所述目标Kafka信息的所述数据报文发送至对应的kafka主题，包括：

根据所述分库策略配置至少一个kafka集群，所述kafka集群包括多个kafka主题；

根据所述目标Kafka信息确定对应的kafka主题，以将挂载有所述目标时序数据库和所述目标Kafka信息的所述数据报文发送至对应的kafka主题。

7.一种时序数据库分库控制装置，其特征在于，所述时序数据库分库控制装包括：

分库策略配置单元，用于配置预设的分库策略，并将所述分库策略存入Redis数据库；

资源上报单元，用于根据所述分库策略计算监控资源对应的关联关系，并将所述关联关系存入所述Redis数据库，所述关联关系用于确定所述监控资源对应的时序数据库和Kafka信息；

数据上报单元，用于获取数据报文，确定所述数据报文对应的目标监控资源，并基于所述Redis数据库中的所述分库策略和所述关联关系，确定所述目标监控资源对应的目标时序数据库和目标Kafka信息，其中，所述不同的监控资源对应生成不同的数据报文；

数据库分库单元，用于将挂载有所述目标时序数据库和所述目标Kafka信息的所述数据报文发送至对应的kafka主题，以使所述kafka主题消费所述数据报文时，将所述数据报文中数据库信息插入至所述目标时序数据库。

8.一种时序数据库分库系统，其特征在于，包括：接口层、控制层和执行层；

所述接口层，用于配置预设的分库策略，并将所述分库策略存入Redis数据库；

所述控制层，用于编写所述分库策略对应的分库算法；

所述执行层，用于根据所述分库策略对应的所述分库算法计算监控资源对应的关联关系，并将所述关联关系存入所述Redis数据库，所述关联关系用于确定所述监控资源对应的时序数据库和Kafka信息；以及用于获取数据报文，确定所述数据报文对应的目标监控资源，并基于所述Redis数据库中的所述分库策略和所述关联关系，确定所述目标监控资源对应的目标时序数据库和目标Kafka信息，其中，所述不同的监控资源对应生成不同的数据报文；以及用于将挂载有所述目标时序数据库和所述目标Kafka信息的所述数据报文发送至多个kafka集群，以使多个所述kafka集群中kafka主题消费所述数据报文时，将所述数据报文中数据库信息插入至所述目标时序数据库。

9.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至6中任意一项所述的时序数据库分库控制方法。

10.一种计算机可读存储介质，其特征在于，存储有计算机程序，所述计算机程序被处理器执行时，实现如权利要求1至6中任意一项所述的时序数据库分库控制方法。