一种分布式时序数据库、存储方法、设备及存储介质与流程

本申请涉及数据库技术领域，尤其涉及一种分布式时序数据库、存储方法、设备及存储介质。

背景技术：

时序数据库(timeseriesdatabase，tsdb)又称为时间序列数据库，是一种集时序数据高效读写、压缩存储、实时计算能力为一体的数据库服务，可广泛应用于物联网和互联网领域，实现对设备及业务服务的实时监控，实时预测告警。

目前业界主流的开源tsdb，一部分tsdb不具有分布式方案，另一部分tsdb虽然基于分布式列存储系统hbase、cassandra等实现了分布式方案，但是目前的tsdb分布式方案存在明显缺陷，例如，不具备服务高可用能力，任何服务节点挂掉或者网络不通时，将会导致部分时序数据一直写入失败；另外，还不具备负载均衡能力，需要为所有服务节点配置前置的负载均衡设备；而且当服务节点扩展时，还需要手动修改负载均衡的配置等。

技术实现要素：

本申请提出一种分布式时序数据库、存储方法、设备及存储介质，不仅可以具备服务高可用能力，而且还可以具备动态可扩展性和负载均衡能力，从而能够满足大吞吐量写入查询和大容量存储的时序数据需求。

本申请的技术方案是这样实现的：

第一方面，本申请实施例提供了一种分布式时序数据库，所述分布式时序数据库包括管理节点和若干个服务节点；其中，

所述管理节点，用于管理所述若干个服务节点，并将待存储的时序数据按照数据分片策略分配至对应的服务节点；

所述服务节点，用于接收所分配的时序数据并执行相应的服务操作。

第二方面，本申请实施例提供了一种基于分布式时序数据库的存储方法，所述分布式时序数据库包括管理节点和若干个服务节点，该方法包括：

获取待存储的时序数据；

通过所述管理节点将所述待存储的时序数据按照数据分片策略分配至对应的服务节点；

通过所述服务节点接收所分配的时序数据并执行相应的服务操作。

第三方面，本申请实施例提供了一种基于分布式时序数据库的存储设备，该存储设备包括存储器和处理器；其中，

所述存储器，用于存储能够在所述处理器上运行的可执行指令；

所述处理器，用于在运行所述可执行指令时，执行如第二方面所述的方法。

第四方面，本申请实施例提供了一种计算机存储介质，该计算机存储介质存储有基于分布式时序数据库的存储程序，所述基于分布式时序数据库的存储程序被至少一个处理器执行时实现如第二方面所述的方法。

本申请实施例所提供的一种分布式时序数据库、存储方法、设备及存储介质，所述分布式时序数据库包括管理节点和若干个服务节点；其中，所述管理节点，用于管理所述若干个服务节点，并将待存储的时序数据按照数据分片策略分配至对应的服务节点；所述服务节点，用于接收所分配的时序数据并执行相应的服务操作。这样，在该分布式时序数据库中，基于若干个服务节点实现分布式架构，而且还引入了管理节点，并通过管理节点将待存储的时序数据按照数据分片策略分配至对应的服务节点，使得即使任何一服务节点发生异常(比如挂掉或者网络不通)，这时候可以由其他服务节点执行相应的服务操作而不会导致部分时序数据写入失败；而且在该分布式时序数据库中，无需额外配置负载均衡设备即可实现服务节点的负载均衡；也就是说，本申请的分布式时序数据库不仅可以具备服务高可用能力，而且还可以具备动态可扩展性和负载均衡能力，从而能够满足大吞吐量写入查询和大容量存储的时序数据需求。

附图说明

图1为相关技术方案提供的一种基于opentsdb的分布式时序数据库的架构示意图；

图2为本申请实施例提供的一种分布式时序数据库的结构示意图；

图3为本申请实施例提供的一种数据分片方案的结构示意图；

图4为本申请实施例提供的另一种分布式时序数据库的结构示意图；

图5为本申请实施例提供的一种分布式时序数据库的应用场景示意图；

图6为本申请实施例提供的一种基于分布式时序数据库的存储方法流程示意图；

图7为本申请实施例提供的一种存储设备的具体硬件结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。可以理解的是，此处所描述的具体实施例仅仅用于解释相关申请，而非对该申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与有关申请相关的部分。

可以理解地，分布式方案主要具有以下几方面能力：(1)高可用能力，分布式系统中任何节点挂掉或者网络不通不会影响服务；(2)可扩展能力，通过增加节点，存储和服务能力可以实现动态可扩展性；(3)负载均衡能力，分布式系统中的节点能够较为均衡地承担服务和存储的负载。

另外，时序数据库(timeseriesdatabase，tsdb)是一种用于存储时序相关数据的数据库，其数据具有时序性，如监控指标数据。在时序数据中，一个时间序列(timeseries，ts)可以包括一个指标名(metricname)、一组标签(tags)和一组数据点(datapoint)。其中，一个标签包括一个键值(key)字符串和一个数值(value)字符串，以key＝value的形式描述时间序列。而一个时间序列可以包括多个标签。一个数据点可以包括一个时间戳信息(timestamp)和数值(value)。需要说明的是，数据块(block)是数据存储基本单位，以时间段为单位(如2小时)。而且相同时间段的不同时序数据将会存储在同一个block中，在block内按照时间顺序存储。

目前业界主流的开源tsdb，一部分不具有分布式高可用方案，如influxdb、prometheus/tsdb等，其中，influxdb是一个由influxdata开发的开源时序型数据，被广泛应用于存储系统的监控数据，物联网(internetofthings，iot)行业的实时数据等场景；prometheus是著名开源监控项目，其监控任务调度给具体的服务器，该服务器到目标上抓取监控数据，然后保存在本地的tsdb中；另一部分是基于分布式列存储系统hbase、cassandra等实现了分布式方案，如opentsdb、kairosdb等，其中，opentsdb是基于hbase的时序数据库，不具备通用性，主要针对具有时间特性和需求的数据，如监控数据、温度变化数据等；kairosdb是基于cassandra的高速时序列数据库，它最早是从opentsdb衍生而来的，兼容opentsdb，并具有自己的特色，现行版本支持cassandra。

图1示出了相关技术方案提供的一种基于opentsdb的分布式时序数据库的架构示意图。如图1所示，opentsdb底层存储使用分布式列式存储系统hbase，而hbase需要基于分布式服务框架(zookeeper)实现高可用性，以使得opentsdb的数据存储具有高可用能力。

在图1中，时序数据(timeseriesdata，tsd)是opentsdb的服务节点，远程过程调用(remoteprocedurecall，rpc)是一个节点请求另一个节点提供的服务。对于服务器(servers)，每一个需要获取监控项(metrics)的servers都需要设置一个收集器(collector)用来收集时间序列数据；图1中的c即是指collector，可以理解为opentsdb的代理(agent)，通过collector收集数据，推送数据；并且collector可以通过tsd简单的rpc协议向tsd推送监控数据；另外tsd还提供了一个网络产品界面设计(websiteuserinterface，webui)页面供数据查询，而且也可以通过脚本(scripts)查询监控数据，对监控数据做报警。tsd收到监控数据后，是通过asynchbase这个库来将数据写入到hbase；asynchbase是完全异步、非阻塞、线程安全的hbase客户端，使用更少的线程、锁以及内存，可以提供更高的吞吐量，特别对于大量的写操作。还需注意的是，网络设备(networkgear)与服务器(servers)之间采用简单网络管理协议(simplenetworkmanagementprotocol，snmp)，服务节点(tsd)与webui页面之间采用超文本传输协议(hypertexttransferprotocol，http)，服务节点(tsd)与脚本(scripts)之间采用http或者rpc。

然而，从图1中可以看到，每个tsd节点直接提供了时序数据的写入和查询服务，并没有借助zookeeper或者元数据服务器进行tsd节点的管理和负载均衡，也即tsd服务不具有高可用能力。换句话说，opentsdb依赖底层hbase提供了存储高可用能力，但并不具备服务高可用能力；虽然具备手动扩展能力，但是扩展之后还需要手动配置服务节点，而且不具备负载均衡能力。

也就是说，目前的tsdb分布式方案存在明显缺陷，例如，不具备服务高可用能力，任何服务节点挂掉或者网络不通时，将会导致部分时序数据一直写入失败；另外，还不具备负载均衡能力，目前需要为所有服务节点配置前置的负载均衡设备；而且当服务节点扩展时，还需要手动修改负载均衡设备的配置。

基于此，本申请实施例提供了一种分布式时序数据库，所述分布式时序数据库包括管理节点和若干个服务节点；其中，所述管理节点，用于管理所述若干个服务节点，并将待存储的时序数据按照数据分片策略分配至对应的服务节点；所述服务节点，用于接收所分配的时序数据并执行相应的服务操作。这样，在该分布式时序数据库中，基于若干个服务节点实现分布式架构，而且还引入了管理节点，并通过管理节点将待存储的时序数据按照数据分片策略分配至对应的服务节点，使得即使任何一服务节点发生异常(比如挂掉或者网络不通)，这时候可以由其他服务节点执行相应的服务操作而不会导致部分时序数据写入失败；而且在该分布式时序数据库中，无需额外配置负载均衡设备即可实现服务节点的负载均衡；也就是说，本申请的分布式时序数据库不仅可以具备服务高可用能力，而且还可以具备动态可扩展性和负载均衡能力，从而能够满足大吞吐量写入查询和大容量存储的时序数据需求。

下面将结合附图对本申请各实施例进行详细说明。

本申请的一实施例中，参见图2，其示出了本申请实施例提供的一种分布式时序数据库的结构示意图。如图2所示，分布式时序数据库20可以包括管理节点201和若干个服务节点202；其中，

管理节点(tsmanager)201，用于管理所述若干个服务节点，并将待存储的时序数据按照数据分片策略分配至对应的服务节点；

服务节点(tsnode)202，用于接收所分配的时序数据并执行相应的服务操作。

需要说明的是，在分布式时序数据库20中，管理节点201可以是一个管理节点，也可以是一个管理节点集群(tshouse)。其中，管理节点201用于管理tsnode以及分片元数据，而且多个管理节点可以组成一个管理节点集群，然后通过raft一致性协议保证元数据的一致性和高可用性。这里，管理节点集群中所包括的管理节点数量为奇数个，比如3个管理节点或者5个管理节点，用以实现管理节点自身的高可用性。

还需要说明的是，本申请实施例提供的分布式时序数据库是基于服务节点实现分布式架构，而且还引入了元数据管理节点(即tsmanager)。tsmanager可以管理多个tsnode，但是tsnode的数量与tsmanager的数量之间没有对应关系。这里，管理节点201在将待存储的时序数据按照数据分片策略分配至对应的服务节点后，针对这若干个服务节点，可以用于接收各自分配的时序数据并执行相应的服务操作。

另外，需要注意的是，元数据(metadata)区别于数据，数据通常是指用户使用的数据；而元数据又可称为中介数据、中继数据，是用来描述数据的数据，主要是描述数据属性的信息，用来支持如指示存储位置、历史数据、资源查找、文件记录等功能。简言之，元数据就是描述数据的数据(dataaboutdata)。

在本申请实施例中，针对每一个服务节点，服务节点202可以提供时序数据的写入(write)服务、读取(query)服务和存储服务。也就是说，服务节点202所执行相应的服务操作，这里的服务操作至少包括下述其中一项：写入服务、读取服务和存储服务。

在一些实施例中，服务节点202，还用于在启动后向管理节点201发送注册请求；

管理节点201，还用于在接收到服务节点202的注册请求时，对服务节点202进行心跳检测和服务管理。

也就是说，由于服务节点202可以提供时序数据的读写服务和存储服务，在服务节点202启动后，可以向管理节点201注册，然后由管理节点201对其进行心跳检测和服务管理。

可以理解地，本申请实施例所提供的分布式时序数据库还具有数据分片技术，通过管理节点201可以将待存储的时序数据按照数据分片策略分配至对应的服务节点。

在一些实施例中，管理节点201，具体用于根据预设时间长度对所述待存储的时序数据进行数据分片，并根据所述若干个服务节点创建多个复制组；基于时序数据的特性和预设算法将所得到的各个分片数据对应分配到所述多个复制组；其中，每一个复制组包括至少两个服务节点。

这里，时序数据的特性可以包括时间戳信息，预设算法可以为哈希(hash)算法。

需要说明的是，数据分片是指分布式时序数据库中的数据可以被复制在网络场地的各个物理数据库中。数据分片是通过关系代数的基本运算实现的。在分布式系统中，数据需要分散存储在多台服务器上，数据分片就是用来确定数据在多台服务器上分布的技术。

在本申请实施例中，时序数据可以根据时间段进行分片(称为range)，一个range以一天为单位进行数据分片。也就是说，预设时间长度可以为一天。这样，管理节点201每天零点可以生成新的range，并且根据这若干个服务节点创建多个复制组(replicagroup)，每一个replicagroup中包括有至少两个tsnode。例如，假定副本(replica)的数量为2，当前有4个tsnode，那么可以组成2个replicagroup。

图3示出了本申请实施例提供的一种数据分片方案的结构示意图。如图3所示，按照一天为单位进行切分，可以生成两个range，即range-20190801和range-20190802。对于range-20190801来说，由于副本数为2，且存在有四个服务节点(tsnode-1、tsnode-2、tsnode-3和tsnode-4)，这时候可以创建两个复制组，即20190801-复制组1和20190801-复制组2；在20190801-复制组1中包括有tsnode-1和tsnode-2两个服务节点，在20190801-复制组2中包括有tsnode-3和tsnode-4两个服务节点。如此，在2019.08.02日的零点将会生成range-20190802，对于range-20190801来说，也会创建有2个复制组，即20190802-复制组1和20190802-复制组2，每个复制组包括有两个服务节点，具体如图3所示。

这样，管理节点201在生成range元数据后，客户端可以从任意tsnode进行写入，tsnode从管理节点201同步range元数据信息。并且利用时序数据的特性(比如数据标识、时间戳信息等)，结合哈希算法映射到待写入的复制组，然后再写入到用于数据存储的tsnode。

由于客户端可以通过任意tsnode写入数据，因此，在一些实施例中，所述若干个服务节点，用于在其中一个服务节点发生异常时，通过域名服务器进行服务节点切换，利用切换后的服务节点执行相应的服务操作。

需要说明的是，域名服务器(domainnameserver，dns)是进行域名(domainname)和与之相对应的互联网协议(internetprotocol，ip)地址(ipaddress)转换的服务器。dns中保存了一张域名和与之相对应的ip地址的表，以解析消息的域名。域名是互联网上某一台计算机或计算机组的名称，用于在数据传输时标识计算机的电子方位(有时也指地理位置)。这里，把域名翻译成ip地址的软件可称为域名系统，是一种管理名字的方法。所谓域名服务器(dns)，实际上就是装有域名系统的主机，是一种能够实现名字解析的分层结构数据库，能够使用户更方便地访问互联网。

还需要说明的是，针对这若干个服务节点，当某一个tsnode的节点挂掉或者网络不通时，客户端只需要通过dns服务器将该tsnode切换到其他tsnode进行写入即可。同时由于本申请实施例可以支持多副本写入，也就保证了数据的高可用性。

进一步地，在一些实施例中，所述若干个服务节点，还用于当分布式时序数据库具有服务能力扩展需求时，部署新的服务节点，并在所述新的服务节点启动后向所述管理节点发送注册请求；

所述管理节点，还用于在接收到所述新的服务节点的注册请求时，对所述新的服务节点进行心跳检测和服务管理。

需要说明的是，在分布式时序数据库20中，当存储或者服务能力需要扩展时，只需要部署新的tsnode，并且新的tsnode启动后自动注册到tsmanager即可提供时序数据的读写服务和存储服务。

还需要说明的是，在部署新的服务节点后，管理节点201，还用于在生成新的复制组时，将所述新的服务节点添加到所述新的复制组中。也就是说，在新的tsnode启动后且自动注册到tsmanager，还可以由tsmanager在第二天零点将新的tsnode加入到新的replicagroup中，以便提供存储服务。

在一些实施例中，如图4所示，在图2所示分布式时序数据库20的基础上，每一个服务节点202可以包括存储引擎(storageengine)。其中，

服务节点202，具体用于接收所分配的时序数据，并通过所述存储引擎存储所接收的时序数据。

也就是说，针对服务节点202，在接收到所分配的时序数据后，可以通过内部消息接口(即存储引擎)将时序数据写入到服务节点202中。

进一步地，如图4所示，在图2所示分布式时序数据库20的基础上，分布式时序数据库20还可以包括若干个路由接口203，每一个路由接口与至少两个服务节点连接；其中，

路由接口(proxy)203，用于在通过管理节点201将所述待存储的时序数据进行数据分片后，利用预设算法将所接收到的分片数据均衡分配至所述至少两个服务节点，以保证所述至少两个服务节点的负载均衡性。

需要说明的是，路由接口203可以独立于服务节点，也可以集成在服务节点内部，而图4中所示的路由接口独立于服务节点。这里的预设算法也可以为hash算法。

也就是说，tsnode可以通过提供一个路由接口，将根据客户端的标识信息(如ip、流量等)进行hash计算，然后分散到提供读写服务的至少两个tsnode，用以保证这至少两个tsnode的负载均衡。这时候不再需要额外的前置负载均衡器(loadbalancer，lb)即可实现负载均衡。

在一些实施例中，路由接口203，还用于在其中一个服务节点发生异常时，从所述至少两个服务节点中剔除所述其中一个服务节点，并将所述其中一个服务节点的时序数据均衡分配给剩余服务节点。

进一步地，路由接口203，还用于当所述分布式时序数据库部署新的服务节点时，将所述新的服务节点加入所述路由接口，并从所述至少两个服务节点上分担时序数据给所述新的服务节点。

也就是说，当一个tsnode挂掉或者网络不通时，这时候路由接口可以自动将其剔除，并将发生异常的tsnode上时序数据所对应的流量均衡分配给其他tsnode。同理，当新增一个tsnode时，这时候路由接口可以自动将其加入，并从其他tsnode上分担流量到新的tsnode上。

本申请实施例所提供的一种分布式时序数据库，所述分布式时序数据库包括管理节点和若干个服务节点；其中，所述管理节点，用于管理所述若干个服务节点，并将待存储的时序数据按照数据分片策略分配至对应的服务节点；所述服务节点，用于接收所分配的时序数据并执行相应的服务操作。也就是说，本申请实施例提供的分布式时序数据库采用分布式高可用方案，与目前已有的分布式时序数据库相比，能够更好地满足服务高可用能力、动态可扩展能力和负载均衡能力。而且本申请实施例的关键点在于基于若干个服务节点的分布式架构和基于range及repcliagroup的数据分片技术，从而能够满足大吞吐量写入查询和大容量存储的时序数据需求。

本申请的另一实施例中，参见图5，其示出了本申请实施例提供的一种分布式时序数据库的应用场景示意图。如图5所示，该应用场景可以包括有分布式时序数据库20、收集器(collectors)30和用户页面(users)40。其中，收集器30可以提供待存储的时序数据以写入(write)到时序数据库20中，用户页面40可以读取(query)时序数据库20中所存储的时序数据。

具体来讲，在收集器30中，可以包括有节点代理(nodeagent)、物联网收集器(iotcollector)和软件开发工具包应用(applicationsoftwaredevelopmentkit，appsdk)。

在用户页面40中，可以包括有网络控制台(webconsole)、计费系统(billsystem)和查询应用(appquery)，而且iotcollector和webconsole之间可以由域名服务器(dnsserver)实现。

在分布式时序数据库20中，可以包括管理节点集群501、第一服务节点(tsnode-1)502a、第二服务节点(tsnode-2)502b、第三服务节点(tsnode-3)502c和第四服务节点(tsnode-4)502d。这里，管理节点集群501是有三个管理节点组成，而且管理节点集群501用于管理tsnode-1、tsnode-2、tsnode-3和tsnode-4等四个服务节点。另外，每一个服务节点中包括有存储引擎(storageengine)和路由接口(proxy)，也就是说，路由接口集成在每一个服务节点内部，且不同的路由接口可以连接多个服务节点内的存储引擎；这样，针对待存储的时序数据，在写入到路由接口时，可以由每个路由接口写入到对应服务节点内的存储引擎，以便实现时序数据的存储。

简言之，本申请实施例提供了一种分布式时序数据库，如图5所示。基于服务节点(tsnode)实现分布式架构，而且还引入了元数据管理节点(tsmanager)。tsnode提供时序数据的读写服务和存储服务，tsnode启动后可以向tsmanager注册，然后由tsmanager对其进行心跳检测和服务管理。tsmanager可以管理tsnode以及分片元数据。另外，多个tsmanager可组成一个元数据管理节点集群，通过raft一致性协议保证元数据一致性和高可用性。

需要说明的是，本申请实施例还采用数据分片技术。具体地，时序数据可以根据时间段进行分片(称为range)，一个range以一天为单位进行切分。tsmanager每天零点生成新的range，并根据当前的可用tsnode分配复制组关系(replicagroup)，例如，如图3所示，假定副本数2，当前有4个tsnode，那么可以组成2个replicagroup。

还需要说明的是，本申请实施例还具有服务和存储的高可用能力。tsmanager生成range元数据后，客户端可以从任意tsnode接入进行写入，tsnode从tsmanager同步range元数据信息，然后基于时序数据的特性(如时间戳信息)，利用hash算法将时序数据映射到写入的replicagroup信息，然后通过内部消息接口(存储引擎)写入到用于数据存储的tsnode。这样，客户端可以通过任意tsnode写入数据，任何tsnode节点挂掉或者网络不通时，客户端只需要通过dns服务器切换到其他tsnode写入即可。同时由于支持多副本写入，保证了数据的高可用能力。

还需要说明的是，本申请实施例还具有动态可扩展能力。当存储或者服务能力需要扩展时，只需要部署新的tsnode，而且新的tsnode启动后自动注册到tsmanager即可提供时序数据的读写服务。同时tsmanager还可以在第二天零点将新的tsnode加入到新的replicagroup中，用以提供存储服务。

除此之外，本申请实施例还具有自动负载均衡能力。tsnode通过提供一个路由接口，可以将根据客户端的标识信息(如ip、流量等)进行hash计算，用以分散到提供读写服务的多个tsnode，来保证这多个tsnode的负载均衡。这时候不再需要额外的前置负载均衡器即可实现负载均衡。

另外，当一个tsnode挂掉或者网络不通时，这时候路由接口自动将其剔除，并将不可用的tsnode上的流量均衡分散给其他tsnode。同理，当新增一个tsnode时，这时候路由接口自动将其加入，并从其他tsnode上分担流量到新的tsnode上。

也就是说，本申请实施例实现了时序数据库的分布式高可用方案。而且本申请实施例提供的一种分布式时序数据库为具有高可用能力、动态扩展能力和负载均衡能力的时序数据库系统，能够满足大吞吐量写入查询和大容量存储的时序数据需求。

本申请实施例所提供的一种分布式时序数据库，通过上述实施例对前述实施例的具体实现进行了详细阐述，从中可以看出，本申请实施例提供的分布式时序数据库采用分布式高可用方案，与目前已有的分布式时序数据库相比，能够更好地满足服务高可用能力、动态可扩展能力和负载均衡能力。而且本申请实施例的关键点在于基于若干个服务节点的分布式架构和基于range及repcliagroup的数据分片技术，从而能够满足大吞吐量写入查询和大容量存储的时序数据需求。

本申请的又一实施例中，参见图6，其示出了本申请实施例提供的一种基于分布式时序数据库的存储方法流程示意图。如图6所示，该方法可以包括：

s601：获取待存储的时序数据；

s602：通过所述管理节点将所述待存储的时序数据按照数据分片策略分配至对应的服务节点；

s603：通过所述服务节点接收所分配的时序数据并执行相应的服务操作。

需要说明的是，本申请实施例可以应用于前述实施例中所述的分布式时序数据库20。在该分布式时序数据库中，可以包括有管理节点和若干个服务节点，而且管理节点可以管理这若干个服务节点。

还需要说明的是，在分布式时序数据库中，管理节点可以是一个管理节点，也可以是一个管理节点集群(tshouse)。其中，管理节点用于管理tsnode以及分片元数据，而且多个管理节点可以组成一个管理节点集群，然后通过raft一致性协议保证元数据的一致性和高可用性。

这样，在获取待存储的时序数据后，可以由管理节点将待存储的时序数据按照数据分片策略分配至对应的服务节点，然后对于这若干个服务节点，可以接收各自分配的时序数据并执行相应的服务操作。

在本申请实施例中，服务节点可以提供时序数据的写入(write)服务、读取(query)服务和存储服务。也就是说，服务节点所执行相应的服务操作，这里的服务操作至少包括下述其中一项：写入服务、读取服务和存储服务。

可以理解地，在通过管理节点将待存储的时序数据按照数据分片策略分配至对应的服务节点之前，针对这若干个服务节点，需要向管理节点发送注册请求，以便实现管理节点对其的服务管理。在一些实施例中，该方法还可以包括：

在所述服务节点启动后，通过所述服务节点向所述管理节点发送注册请求；

基于所述注册请求，通过所述管理节点对所述服务节点进行心跳检测和服务管理。

也就是说，由于服务节点可以提供时序数据的读写服务和存储服务，在服务节点启动后，可以向管理节点注册，然后由管理节点对其进行心跳检测和服务管理。

还需要说明的是，在本申请实施例中，分布式时序数据库还具有数据分片技术，通过管理节点可以将待存储的时序数据按照数据分片策略分配至对应的服务节点。具体地，在一些实施例中，所述通过管理节点将所述待存储的时序数据按照数据分片策略分配至对应的服务节点，可以包括：

根据预设时间长度对所述待存储的时序数据进行数据分片，得到多个分片数据；

根据所述若干个服务节点，创建多个复制组；

基于时序数据的特性和预设算法，将所得到的多个分片数据对应分配到所述多个复制组；其中，每一个复制组包括至少两个服务节点。

进一步地，所述时序数据的特性包括时间戳信息，所述预设算法为哈希算法。这时候，所述基于时序数据的特性和预设算法，将所得到的多个分片数据对应分配到所述多个复制组，可以包括：

基于所述多个分片数据各自的时间戳信息，利用哈希算法计算得到多个哈希值；

根据所述多个哈希值，确定所述多个分片数据各自对应的复制组信息，以将所述多个分片数据对应分配到所述多个复制组中。

需要说明的是，时序数据可以根据时间段进行分片(称为range)，一个range以一天为单位进行数据分片。也就是说，预设时间长度可以为一天。这样，管理节点每天零点可以生成新的range，并且根据这若干个服务节点创建多个复制组(replicagroup)，每一个replicagroup中包括有至少两个tsnode。例如，假定副本(replica)的数量为2，当前有4个tsnode，那么可以组成2个replicagroup。

还需要说明的是，不同的分片数据对应有不同的时间戳信息，利用哈希算法可以得到不同的哈希值；这样，根据分片数据对应的哈希值，可以确定出该分片数据对应的复制组信息，用以将该分片数据写入对应的复制组中。

进一步地，管理节点在生成range元数据后，客户端可以从任意tsnode进行写入，tsnode从管理节点同步range元数据信息。在一些实施例中，该方法还可以包括：

当其中一个服务节点发生异常时，通过域名服务器进行服务节点切换，利用切换后的服务节点执行相应的服务操作。

也就是说，针对分布式时序数据库中的若干个服务节点，当某一个tsnode的节点挂掉或者网络不通时，客户端只需要通过dns服务器将该tsnode切换到其他tsnode进行写入即可。

进一步地，在一些实施例中，该方法还可以包括：

当所述分布式时序数据库具有服务能力扩展需求时，部署新的服务节点，并在所述新的服务节点启动后向所述管理节点发送注册请求；

基于所述注册请求，通过所述管理节点对所述新的服务节点进行心跳检测和服务管理。

需要说明的是，在分布式时序数据库中，当存储或者服务能力需要扩展时，只需要部署新的tsnode，并且新的tsnode启动后自动注册到tsmanager即可提供时序数据的读写服务和存储服务。

还需要说明的是，在部署新的服务节点后，该方法还可包括：当通过管理节点生成新的复制组时，将所述新的服务节点添加到所述新的复制组中。也就是说，在新的tsnode启动后且自动注册到tsmanager，还可以由tsmanager在第二天零点将新的tsnode加入到新的replicagroup中，以便提供存储服务。

在一些实施例中，分布式时序数据库还可以包括若干个路由接口，每一个路由接口与至少两个服务节点连接。该方法还可以包括：

在通过所述管理节点将所述待存储的时序数据进行数据分片后，通过所述路由接口将所接收到的分片数据均衡分配至所述至少两个服务节点，以保证所述至少两个服务节点的负载均衡性。

需要说明的是，路由接口可以独立于服务节点，如图4中所示的路由接口，这时候每一个路由接口可以与至少两个服务节点连接；路由接口还可以集成在服务节点内部，如图5中所示的路由接口，这时候每一个路由接口可以与多个服务节点内部的存储引擎连接。另外，这里的预设算法也可以为hash算法。

也就是说，tsnode可以通过提供一个路由接口，将根据客户端的标识信息(如ip、流量等)进行hash计算，然后分散到提供读写服务的至少两个tsnode，用以保证这至少两个tsnode的负载均衡。这时候不再需要额外的前置负载均衡器(loadbalancer，lb)即可实现负载均衡。

进一步地，在一些实施例中，该方法还可以包括：

当其中一个服务节点发生异常时，从所述至少两个服务节点中剔除所述其中一个服务节点，并将所述其中一个服务节点的时序数据均衡分配给剩余服务节点。

进一步地，在一些实施例中，该方法还可以包括：

当所述分布式时序数据库部署新的服务节点时，将所述新的服务节点加入所述路由接口，并从所述至少两个服务节点上分担时序数据给所述新的服务节点。

也就是说，当一个tsnode挂掉或者网络不通时，这时候路由接口可以自动将其剔除，并将不可用的tsnode上的流量均衡分配给其他tsnode。同理，当新增一个tsnode时，这时候路由接口可以自动将其加入，并从其他tsnode上分担流量到新的tsnode上。

本申请实施例所提供的一种基于分布式时序数据库的存储方法，获取待存储的时序数据；通过所述管理节点将所述待存储的时序数据按照数据分片策略分配至对应的服务节点；以及通过所述服务节点接收所分配的时序数据并执行相应的服务操作。这样，该分布式时序数据库基于若干个服务节点实现分布式架构，而且还引入了管理节点，并通过管理节点将待存储的时序数据按照数据分片策略分配至对应的服务节点，使得即使任何一服务节点发生异常(比如挂掉或者网络不通)，这时候可以由其他服务节点执行相应的服务操作而不会导致部分时序数据写入失败；而且在该分布式时序数据库中，无需额外配置负载均衡设备即可实现服务节点的负载均衡；也就是说，本申请的分布式时序数据库不仅可以具备服务高可用能力，而且还可以具备动态可扩展性和负载均衡能力，从而能够满足大吞吐量写入查询和大容量存储的时序数据需求。

可以理解地，本申请实施例的分布式时序数据库可以集成在一个处理单元中，也可以是各个组成部分单独物理存在，也可以两个或两个以上部分集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

所述集成的单元如果以软件功能模块的形式实现并非作为独立的产品进行销售或使用时，可以存储在一个计算机可读取存储介质中，基于这样的理解，本实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或processor(处理器)执行本实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(readonlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。

因此，本实施例提供了一种计算机存储介质，该计算机存储介质存储有基于分布式时序数据库的存储程序，所述基于分布式时序数据库的存储程序被至少一个处理器执行时实现前述实施例中任一项所述的方法的步骤。

基于上述分布式时序数据库20的组成以及计算机存储介质，参见图7，其示出了本申请实施例提供的一种存储设备的具体硬件结构示意图。如图7所示，存储设备70应用于分布式时序数据库，该存储设备70可以包括：通信接口701、存储器702和处理器703；各个组件通过总线系统704耦合在一起。可理解，总线系统704用于实现这些组件之间的连接通信。总线系统704除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图7中将各种总线都标为总线系统704。其中，通信接口701，用于在与其他外部网元之间进行收发信息过程中，信号的接收和发送；

存储器702，用于存储能够在处理器703上运行的计算机程序；

处理器703，用于在运行所述计算机程序时，执行：

获取待存储的时序数据；

通过所述管理节点将所述待存储的时序数据按照数据分片策略分配至对应的服务节点；

通过所述服务节点接收所分配的时序数据并执行相应的服务操作。

可以理解，本申请实施例中的存储器702可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-onlymemory，rom)、可编程只读存储器(programmablerom，prom)、可擦除可编程只读存储器(erasableprom，eprom)、电可擦除可编程只读存储器(electricallyeprom，eeprom)或闪存。易失性存储器可以是随机存取存储器(randomaccessmemory，ram)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的ram可用，例如静态随机存取存储器(staticram，sram)、动态随机存取存储器(dynamicram，dram)、同步动态随机存取存储器(synchronousdram，sdram)、双倍数据速率同步动态随机存取存储器(doubledataratesdram，ddrsdram)、增强型同步动态随机存取存储器(enhancedsdram，esdram)、同步链动态随机存取存储器(synchronouslinkdram，sldram)和直接内存总线随机存取存储器(directrambusram，drram)。本文描述的系统和方法的存储器702旨在包括但不限于这些和任意其它适合类型的存储器。

而处理器703可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器703中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器703可以是通用处理器、数字信号处理器(digitalsignalprocessor，dsp)、专用集成电路(applicationspecificintegratedcircuit，asic)、现场可编程门阵列(fieldprogrammablegatearray，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器702，处理器703读取存储器702中的信息，结合其硬件完成上述方法的步骤。

可以理解的是，本文描述的这些实施例可以用硬件、软件、固件、中间件、微码或其组合来实现。对于硬件实现，处理单元可以实现在一个或多个专用集成电路(applicationspecificintegratedcircuits，asic)、数字信号处理器(digitalsignalprocessing，dsp)、数字信号处理设备(dspdevice，dspd)、可编程逻辑设备(programmablelogicdevice，pld)、现场可编程门阵列(field-programmablegatearray，fpga)、通用处理器、控制器、微控制器、微处理器、用于执行本申请所述功能的其它电子单元或其组合中。

对于软件实现，可通过执行本文所述功能的模块(例如过程、函数等)来实现本文所述的技术。软件代码可存储在存储器中并通过处理器执行。存储器可以在处理器中或在处理器外部实现。

可选地，作为另一个实施例，处理器703还配置为在运行所述计算机程序时，执行前述实施例中任一项所述的方法的步骤。

本领域普通技术人员可以意识到，结合本申请中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

还需要说明的是，在本申请中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

本申请所提供的几个方法实施例中所揭露的方法，在不冲突的情况下可以任意组合，得到新的方法实施例。

本申请所提供的几个产品实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的产品实施例。

本申请所提供的几个方法或设备实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的方法实施例或设备实施例。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。