CN104572856A - 一种服务起源数据的融合存储方法 - Google Patents

Abstract

本发明公开了一种服务起源数据的融合存储方法，该方法包括以下步骤：获得服务起源数据;定义基于文档存储数据库的服务起源数据的存储模式；定义基于图形数据库的服务起源数据的存储模式；读取服务起源日志，根据服务起源日志建立并更新文档存储数据库；按周期读取文档存储数据库中的文档，插入到图形数据库中，建立起源图谱；根据文档存储数据库更新图形数据库。本发明提出的一种服务起源融合存储方法，实现了多类型查询需求和查询效率之间的平衡，并且通过统一的查询分析器，保持了透明性，提升用户的使用体验，便于进行统一的分析和查询操作。

Description

一种服务起源数据的融合存储方法

技术领域

本发明涉及云服务存储技术领域，尤其涉及一种服务起源的融合存储方法。

背景技术

  服务起源不同于普通的系统日志，它描述了服务的详细行为特征，包括服务实时依赖关系，服务的执行的耗时，输入和输出等，详细见专利201410323340.8，常用的存储方式，例如，采用关系数据库存储，大量的服务行为细节数据储存在单表中，无法支持快速、高效的服务查询运算，也无法支持服务追踪。以Mongodb为代表的非关系数据库，具有模式自由等特点，并且通过key-value的方式存储数据，便于数据的聚合运算，但是无法支持追踪查询。以Neo4j为代表的图数据库，可以把服务依赖关系，以图的形式存储在数据库中，便于进行服务依赖的查询，但是大量的服务行为细节信息存储在关系属性中，不利于快速的聚合运算。

发明内容

本发明要解决的技术问题在于针对现有技术中的缺陷，提供一种服务起源数据的融合存储方法。

本发明解决其技术问题所采用的技术方案是：一种服务起源数据的融合存储方法，包括以下步骤：

1)获得服务起源数据,所述服务起源数据规范为一个九元组:

BasicProv(token,InvokingService,ServiceInvoked,location, elapsed time, timestamp, input, output, status);

2)定义基于文档存储数据库的服务起源数据的存储模式,所述每个文档存储一个服务依赖关系对；以服务依赖关系对（S1，S2）为例，这个文档存储了关于S1调用S2的所有记录；在每个文件中，有四个键-值对，分别描述调用InvokingService、被调用ServiceInvoked、内容，调用发生的位置location（实际存储为IP地址）；所述内容为一个子文档，用于描述（token,elapsed time, timestamp, input, output, status）；

3）定义基于图形数据库的服务起源数据的存储模式, 其中节点（顶点）用于表示服务名，边（关系）表示连接的两个顶点之间的服务调用关系，节点属性描述服务名、地点和服务位置（IP地址），用键-值对存储；关系属性描述总共调用次数，最近一次的耗时，最近一次的调用时间和token，用键-值对存储；

4）读取服务起源日志，根据（InvokingService,ServiceInvoked）在文档存储数据库中查询相应的文档，如果存在该文档，则把详细信息写入到内容Content子文档（该信息属于每次调用的详细信息，只写入内容子文档）；如果不存在，创建（InvokingService,ServiceInvoked）文档，然后把详细信息写入到key-value对以及子文档中；

5）    按周期读取文档存储数据库中的文档（InvokingService,ServiceInvoked），插入到图形数据库中，建立起源图谱；

6）根据文档存储数据库更新图形数据库的详细过程为，在内存中建立一个哈希表，每个元素存储服务名称，如果读取的（InvokingService,ServiceInvoked）不在哈希表中，新建元素，并且把该服务插入到图形数据库节点中；如果该服务已经存在哈希表中，则该服务依赖关系插入到图形数据库的关系中，读取该条记录的剩下的其他服务起源信息（服务起源9元组剩下的7元组信息），更新图形数据库的关系属性键-值对。

按上述方案，所述文档存储数据库为mongodb，图形数据库为Neo4j。

按上述方案，所述周期为30秒至300秒。

按上述方案，所述步骤6）中采用服务起源数据代替文档存储数据库更新图形数据库。

按上述方案，该方法还包括步骤7）：数据库的查询步骤，具体如下：

1）设置服务起源查询分析器，所述查询分析器包括3个部分：用户界面接口、查询语义转换、查询执行计划；所述用户界面接口为用户提供了服务名称、时间、统计内容和运算算子作为可选项；

2）用户在用户界面选择后，根据用户选择的运算算子进行自动分类为聚合运算和追踪运算，聚合运算相应的查询分析请求映射到Mongodb的查询语言，追踪运算映射到Neo4j的查询统计语言；

3）按照得到的转换的查询语言，调用配置好的Mongodb和Neo4j的查询服务接口，执行查询计划。

按上述方案，所述用户界面接口为用户提供的可选项具体如下：

服务名称，包括服务调用者（InvokingService）和服务提供者（ServiceInvoked）；

时间，可以选择包括年、月、日、小时作为统计的时间跨度；

统计内容，可以选择调用次数、运行耗时；

运算算子，包括选择平均值avg，汇总求和SUM，最大值Max、最小值Min、服务依赖路径trace。

按上述方案，所述运算算子中avg、SUM、 Max、Min归为聚合运算，trace归为追踪运算。

本发明产生的有益效果是：能够提高海量的服务起源数据的查询和分析效率，满足聚合、追踪等不同类型的查询分析需求，为提高服务故障诊断、服务优化分析的实时性奠定基础，降低大型互联网公司、IT公司的服务运维成本，提高服务质量。本发明提出的一种服务起源融合存储方法，实现了多类型查询需求和查询效率之间的平衡，并且通过统一的查询分析器，保持了透明性，提升用户的使用体验，便于进行统一的分析和查询操作。

附图说明

下面将结合附图及实施例对本发明作进一步说明，附图中：

图1是本发明基于Mongodb的服务起源存储模式结构示意图；

图2是本发明基于Neo4j的图数据存储方式结构示意图；

图3是本发明的方法流程图；

图4是本发明实施例中不同存储模式下服务起源数据入库性能分析；

图5是本发明实施例中源数据库增加不同模式存储方式的性能比较示意图；

图6是本发明实施例中图数据库追踪查询运行时间比较示意图。

具体实施方式

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

服务起源数据是一个9元组，

即BasicProv(token,InvokingService,ServiceInvoked,location, elapsed time, timestamp, input, output, status)）。基于文件的存储是一个典型的NO-SQL数据架构。服务起源数据存储是在一个集合中的，包含多个文档，每个文档存储一个服务依赖关系对，例如（S1，S2），这个文档存储了关于S1调用S2的所有记录。如图1所示，在每个文件中，有四个 键 - 值对，其中描述调用，已调用，调用发生的位置location（实际存储为IP地址）和内容。内容是一个子文档，它描述了调用的细节，其中包括经过时间，调用时间，状态等。

与关系模型相比较，这种方式有一些优势。首先，通过使用key-value存储基本源，容易对任何给定的键进行扩展基本结构源数据，比如按照该键值结构通过简单地添加新的内容作为新的调用值。 基于文件的存储模式也可以提高查询和插入的性能。给定一个服务S1，以便查询有多少服务由S1调用，我们只是想要 S1相关的数据，这些数据被存储在一个文件中，而不是查询整个表S1。

虽然基于关系型模式和文件模式存储系统可以减少查询的空间，提高存储效率，他们不能很容易地实现跟踪操作，因为跟踪操作需要执行迭代。根据服务调用的依赖性的操作，通过存储服务调用源数据图表存储，我们可以很容易计算的服务执行的路径。图2描述了基于Neo4j的图存储模式，其中所述顶点表示服务和边表示的服务调用的关系。该图是指这两个节点的关系属性，它表示存储为键--值对。节点属性描述的名称，地点等，关系属性描述总共调用次数，最近一次的耗时，最近一次的调用时间和token。关系属性不存储大量的细节信息，只存储统计值和最后一次调用信息。这种方式关注服务的依赖关系，最终形成了服务起源关系图，通过存储的基本源记录在图表数据库中，就可以方便地提供复杂的路径操作，如最短路径，连通分量等等。

基于Mongodb的存储实现了按照服务依赖关系对的分片式存储，主要用于存储服务起源的详细信息，便于聚合运算。基于Neo4j主要存储服务依赖关系，便于追踪查询。为了保持信息同步，在获取到服务起源日志以后, 参考专利201410323340.8，插入Mongodb数据库的同时，定时从Mongodb数据库同步服务依赖关系到Neo4j数据库，具体如下，如图3所示：

1、      读取服务起源日志

2、      根据（InvokingService,ServiceInvoked）在Mongodb中查询相应的文档，如果存在该文档，则把详细信息写入到key-value对以及子文档中，如果不存在，创建（InvokingService,ServiceInvoked）文档；

3、      定时读取Mongodb中的文档（InvokingService,ServiceInvoked），插入到Neo4j数据中，建立起源图谱；

4、      更新Neo4j的详细过程为，在内存中建立一个哈希表，每个元素存储服务名称，如果读取的（InvokingService,ServiceInvoked）不再哈希表中，新建元素，并且把该服务插入到Neo4J节点中。如果该服务已经存在哈希表中，则该服务依赖关系插入到Neo4j的关系中，读取该条记录的其他服务起源信息（服务起源9元组剩下的7元组信息），更新Neo4j的关系属性key-value对；

该方法还包括数据库的查询步骤，具体如下：

设置服务起源查询分析器，服务起源查询分析器的作用是实现用户查询需求的形式化，并且映射到不同层次的存储数据库中，实现高速查询以及分析应用。查询分析器包括3个部分：用户界面接口、查询语义转换、查询执行计划。

1、  用户界面接口

用户界面接口包含选取服务名称，运算算子，统计时间，服务路径追踪等部分。详细过程如下：

用户界面提供了服务名称、时间、统计内容和运算算子等选择，具体如下：

用户可以选择需要统计的服务名称，包括服务调用者（InvokingService）和服务提供者（ServiceInvoked）；

时间可以选择年、月、日、小时；

统计内容可以选择调用次数、运行耗时；

运算算子可以选择avg（平均值），SUM（汇总求和），Max（最大值）、Min（最小值）、trace（服务依赖路径）。

2.查询语义转换

当用户在用户界面选择后，系统根据用户选择的运算算子进行自动分类，其中avg、SUM、 Max（最大值）、Min（最小值）归为聚合运算，trace归为追踪运算。聚合运算相应的查询分析请求映射到Mongodb的查询语言，trace运算映射到Neo4j的查询统计语言，系统将自动进行映射转化。

3.查询执行计划

按照第2步得到的转换的查询语言，调用配置好的Mongodb和Neo4j的查询服务接口，执行查询计划。

4.查询效率分析

（1）不同存储模式下服务起源数据入库性能分析

本发明测量了三种不同收集源的运行成本，是通过插入不同源数据在MySQL，MongoDB，Neo4j中，分别是100，200，500，1000，200万行。 MySQL在做插入时比MongDB和Neo4j花更多的时间。相对MySQL，随着越来越多的行插入的数据，该操作运行时间快速增加，而Neo4j的运行时间增加缓慢，MongoDB的运行时间非常稳定。该实验说明，以MondoDB数据库存储服务起源详细信息，具有更高的入库性能。如图4所示。

（2）聚合查询运算效率分析

本发明测量一个典型的聚合的运行时间，由不同大小捕获源记录存储在三个存储中。我们查询了S1调用S2服务的次数。在不同来源数据库大小的情况下,结果表明,随着来源数据库大小的增加MongoDB最稳定,而MYSQL比MongoDB花更多的时间当数据规模达到1000000的时候, 相对于MySQL和MongoDB，当源数据库增加时，Neo4j会花费更多的性能去执行聚合查询。如图5所示。

　（3）追踪运算查询效率分析

本发明测量跟踪操作运行时间的成本，是通过改变路径的长度从1,3,5,7到9依次调用服务。分别以token和服务名称作为条件，追踪查询运行时间。如图6所示。

（4）融合存储查询性能分析

本发明提出的融合存储方法，本质上融合了Mongodb和Neo4j的数据存储，既支持追踪查询，又保持了高效的聚合查询效率。所有的查询请求通过查询分析器映射到Mongodb和Neo4j数据库执行，执行效率上参考上述实验结果。另外，本发明通过数据定周期同步更新，实现从Mongodb到Neo4j数据库的数据更新，该方法将占用一部分资源消耗，但是可以和查询分离，不影响查询分析的效率。

应当理解的是，对本领域普通技术人员来说，可以根据上述说明加以改进或变换，而所有这些改进和变换都应属于本发明所附权利要求的保护范围。

Claims (7)

1.一种服务起源数据的融合存储方法，包括以下步骤：

1)获得服务起源数据,所述服务起源数据规范为一个九元组: BasicProv(token,InvokingService,ServiceInvoked,location, elapsed time, timestamp, input, output, status);

2)定义基于文档存储数据库的服务起源数据的存储模式,所述每个文档存储一个服务依赖关系对；服务依赖关系对（S1，S2）的文档存储了关于S1调用S2的所有记录；在每个文件中，有四个键-值对，分别描述调用InvokingService、被调用ServiceInvoked、内容，调用发生的位置location；所述内容为一个子文档，用于描述（token,elapsed time, timestamp, input, output, status）；

3）定义基于图形数据库的服务起源数据的存储模式, 其中节点用于表示服务名，边表示连接的两个顶点之间的服务调用关系，节点属性描述服务名、地点和服务位置，用键-值对存储；关系属性描述总共调用次数，最近一次的耗时，最近一次的调用时间和token，用键-值对存储；

4）读取服务起源日志，根据（InvokingService,ServiceInvoked）在文档存储数据库中查询相应的文档，如果存在该文档，则把详细信息写入到内容Content子文档；如果不存在，创建（InvokingService,ServiceInvoked）文档，然后把详细信息写入到key-value对以及子文档中；

5)按周期读取文档存储数据库中的文档（InvokingService,ServiceInvoked），插入到图形数据库中，建立起源图谱；

6）根据文档存储数据库更新图形数据库的详细过程为，在内存中建立一个哈希表，每个元素存储服务名称，如果读取的（InvokingService,ServiceInvoked）不在哈希表中，新建元素，并且把该服务插入到图形数据库节点中；如果该服务已经存在哈希表中，则该服务依赖关系插入到图形数据库的关系中，读取该条记录的其他服务起源信息（服务起源9元组剩下的7元组信息），更新图形数据库的关系属性键-值对。

2.根据权利要求1所述的融合存储方法，其特征在于，所述文档存储数据库为Mongodb，图形数据库为Neo4j。

3.根据权利要求1所述的融合存储方法，其特征在于，所述步骤5）中周期根据实际需要进行设置，周期可设置为30秒至300秒。

4.根据权利要求1所述的融合存储方法，其特征在于，所述步骤6）中采用服务起源数据代替文档存储数据库更新图形数据库。

5.根据权利要求2所述的融合存储方法，其特征在于，该方法还包括步骤7）：数据库的查询步骤，具体如下：

1）设置服务起源查询分析器，所述查询分析器包括3个部分：用户界面接口、查询语义转换、查询执行计划；所述用户界面接口为用户提供了服务名称、时间、统计内容和运算算子作为可选项；

2）用户在用户界面选择后，根据用户选择的运算算子进行自动分类为聚合运算和追踪运算，聚合运算相应的查询分析请求映射到Mongodb的查询语言，追踪运算映射到Neo4j的查询统计语言；

3）按照得到的转换的查询语言，调用配置好的Mongodb和Neo4j的查询服务接口，执行查询计划。

6.根据权利要求5所述的融合存储方法，其特征在于，所述用户界面接口为用户提供的可选项具体如下：

服务名称，包括服务调用者（InvokingService）和服务提供者（ServiceInvoked）；

时间，可以选择包括年、月、日、小时作为统计的时间跨度；

统计内容，可以选择调用次数、运行耗时；

运算算子，包括选择平均值avg，汇总求和SUM，最大值Max、最小值Min、服务依赖路径trace。

7.根据权利要求6所述的融合存储方法，其特征在于，所述运算算子中avg、SUM、 Max、Min归为聚合运算，trace归为追踪运算。