图数据的查询方法及装置与流程

1.本公开涉及图数据库技术领域，并且更为具体地，涉及一种图数据的查询方法及装置。


背景技术：

2.大数据时代，图数据库中的一个节点（或称顶点）可能会包括大量的边。例如，在社交网络上，一个明星或主播可能有几千万的粉丝量。如果需要对此类具有对某个节点的边进行检索（如筛选或过滤出满足某种条件的边），则边数据的检索效率显得非常重要。
3.为了提高边数据的检索效率，相关技术为边数据引入全局索引。边数据的全局索引存在诸多问题。一方面，全局索引的构建需要重复存储部分甚至全部的边数据。另一方面，基于全局索引通常只能定位找到边数据的主键（edge key），在得到边数据的主键之后，接下来还需要基于边数据的主键重新查找边数据，计算过程复杂，中央处理单元（central processing unit，cpu）开销大。


技术实现要素：

4.针对上述问题，本公开提供一种图数据的查询方法及装置。
5.第一方面，提供一种图数据的查询方法，所述图数据包括第一节点的点数据以及所述第一节点的邻边的边数据，且所述点数据和所述边数据均存储在所述第一节点对应的单点数据块中，所述单点数据块还包括所述边数据的索引数据，所述索引数据用于对所述边数据的第一属性进行索引，所述索引数据记录有所述第一属性的属性值，所述索引数据还记录有所述第一属性的属性值对应的边在所述单点数据块中的存储位置，所述方法包括：接收查询请求，所述查询请求包含所述第一属性的属性值的过滤条件，所述查询请求用于查询所述第一节点的邻边中的满足所述过滤条件的目标边；根据所述索引数据和所述过滤条件，确定所述目标边在所述单点数据块中的存储位置；根据所述目标边在所述单点数据块中的存储位置，获取所述目标边的数据。
6.可选地，所述索引数据位于第一索引块中，所述第一索引块为所述单点数据块包含的多个索引块中的任意一个索引块，所述多个索引块分别用于对所述边数据的多种属性进行索引。
7.可选地，所述单点数据块还包含定位数据，所述定位数据记录有所述多个索引块中的每个索引块在所述单点数据块中的存储位置，在所述根据所述索引数据和所述过滤条件，确定所述目标边在所述单点数据块中的存储位置之前，还包括：根据所述定位数据，查询所述第一索引块在所述单点数据块中的存储位置。
8.可选地，所述定位数据存储在所述点数据和所述边数据之间。
9.可选地，所述边数据存储在多个边数据块中。
10.可选地，所述单点数据块中的数据属于同一文件的数据，且所述单点数据块中的数据在所述文件的存储位置中连续存储。
11.可选地，所述索引数据的索引名为所述第一属性的属性名，所述第一索引的索引值为所述第一属性的属性值。
12.第二方面，提供一种图数据的查询装置，所述图数据包括第一节点的点数据以及所述第一节点的邻边的边数据，且所述点数据和所述边数据均存储在所述第一节点对应的单点数据块中，所述单点数据块还包括所述边数据的索引数据，所述索引数据用于对所述边数据的第一属性进行索引，所述索引数据记录有所述第一属性的属性值，所述索引数据还记录有所述第一属性的属性值对应的边在所述单点数据块中的存储位置，所述装置包括：接收模块，用于接收查询请求，所述查询请求包含所述第一属性的属性值的过滤条件，所述查询请求用于查询所述第一节点的邻边中的满足所述过滤条件的目标边；确定模块，用于根据所述索引数据和所述过滤条件，确定所述目标边在所述单点数据块中的存储位置；获取模块，根据所述目标边在所述单点数据块中的存储位置，获取所述目标边的数据。
13.可选地，所述索引数据位于第一索引块中，所述第一索引块为所述单点数据块包含的多个索引块中的任意一个索引块，所述多个索引块分别用于对所述边数据的多种属性进行索引。
14.可选地，所述单点数据块还包含定位数据，所述定位数据记录有所述多个索引块中的每个索引块在所述单点数据块中的存储位置，所述装置还包括：查询模块，用于在所述根据所述索引数据和所述过滤条件，确定所述目标边在所述单点数据块中的存储位置之前，根据所述定位数据，查询所述第一索引块在所述单点数据块中的存储位置。
15.可选地，所述定位数据存储在所述点数据和所述边数据之间。
16.可选地，所述边数据存储在多个边数据块中。
17.可选地，所述单点数据块中的数据属于同一文件的数据，且所述单点数据块中的数据在所述文件的存储位置中连续存储。
18.可选地，所述索引数据的索引名为所述第一属性的属性名，所述第一索引的索引值为所述第一属性的属性值。
19.第三方面，提供一种图数据的查询装置，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如第一方面或第一方面中任一实现方式所述的方法。
20.第四方面，提供一种计算机可读存储介质，其上存储有可执行代码，当所述可执行代码被执行时，能够实现如第一方面或第一方面中任一实现方式所述的方法。
21.第五方面，提供一种计算机程序产品，包括可执行代码，当所述可执行代码被执行时，能够实现如第一方面或第一方面中任一实现方式所述的方法。
22.本公开实施例将一单点的点数据以及该单点的邻边的边数据均存储在单点数据块中，同时该单点数据块还包括边数据的索引数据。该索引数据记录有边数据在单点数据块中的位置信息。在边数据的查询过程中，可以先根据过滤条件定位索引数据中对应的边数据的位置信息，然后根据该位置信息获取到目标边数据。由于索引数据中直接存储的是边数据的位置信息，因此减少了数据冗余。同时，也省略了计算查询边数据位置信息的步骤，从而降低了cpu开销。
附图说明
23.图1是本公开实施例提供的一种单点数据块的示意性结构图。
24.图2是本公开实施例提供的一种图数据的查询方法的示意性流程图。
25.图3是本公开实施例提供的另一种单点数据块的示意性结构图。
26.图4是本公开实施例提供的一种图数据的查询装置的示意性结构图。
27.图5是本公开实施例提供的另一种图数据的查询装置的示意性结构图。
具体实施方式
28.下面将结合本公开实施例的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本公开一部分实施例，而不是全部的实施例。
29.随着零售、金融、电商、互联网、物联网等行业的兴起，基础数据量成几何状增长，为了将日益增长的庞大数据量组织成一个关系网，传统的关系数据库已经很难应对了。由此业界上出现了一批专门针对关系网数据存储、计算的数据库
‑‑
图数据库。
30.实际上，图数据库源起欧拉和图理论，也可称为面向/基于图的数据库，对应的英文是graph database。图数据库的基本含义是以“图”这种数据结构存储和查询数据，而不是存储图片的数据库。它的数据模型主要是以节点和关系(边)来体现，也可处理键值对。它的优点是快速解决复杂的关系问题。图数据库善于处理大量的、复杂的、互联的、多变的网状数据，其效率远远高于传统的关系型数据库的百倍、千倍甚至万倍。相关技术中，比较有代表性的图数据库是janusgraph、neo4j、hbase和rocksdb等。
31.可以理解的是，图可以由节点（node）的有穷非空集合和节点之间相连的边的集合组成。图数据可以包括图的拓扑结构、节点和/或边的信息。图中的节点有时也可以被称为顶点（vertex）或点。任意两个节点之间可能存在关系，这种关系可以用边（edge）表示。由边相连的两个节点可以称为邻居节点，例如第一节点通过边与第二节点直接相连，则第二节点为第一节点的邻居节点。或者，第二节点也可以被称为第一节点的一度邻居。该边可以被称为第一节点或第二节点的邻边或一度边（即与节点直接相连的边）。同理，如果两个节点之间间隔一个节点（即两个节点并非直接相连，而是间接相连），则该两个节点中的一个节点可以称为另一节点的二度邻居。以此类推。
32.节点和边均可以有各自对应的一种或多种属性。节点或边的属性可用于描述节点或边在某个方面的性质。以社交网络为例，节点可以表示参与社交网络的用户，边可以表示用户之间相互关注。节点对应的属性例如可以包括用户身份的创建时间、用户的年龄、性别、粉丝数量等。边对应的属性例如可以包括该边的两个端节点的标识、边的创建时间等。节点的属性可以记录在该节点对应的点数据中；边的属性可以记录在该边对应的边数据中。节点或边的属性可以根据实际的应用场景设定，本公开实施例对此不作具体限定。无论是点数据还是边数据，均具有主键。基于点数据或边数据的主键，能够在点数据或边数据中唯一标识某个节点或某条边。以边数据为例，边数据的主键可以称为edge key。edgekey可以由边数据的部分属性构成（构成edgekey的属性需要能够唯一标识各条边）。例如，edgekey可以包括边数据的如下属性数据“该边的两个端节点的标识、边的类型、出节点的标识”。这是因为，针对同一类型的边而言，边的两个端节点通常是不同的，所以能够唯一标识各条边。
33.可以理解的是，图数据中的边可以是有方向的，也可以是没方向的。有方向的边可以被称为有向边，没有方向的边可以被称为无向边。有向边可以是指由源节点（source，或简称src）指向目标节点（destination，或简称dst）的边。包括有向边的图可以被称为有向图，包括无向边的图可以被称为无向图。本公开实施例可以应用于有向图，也可以应用于无向图。
34.很多场景中的数据均可以表达成图数据。而且，在不同场景下，基于图数据可以实现很多不同的应用。例如，基于图数据，可以实现金融风险评估、广告推荐、社交关系预测以及交通调度等应用。
35.以图数据用于金融信用评估为例。节点可以是用户或金融机构等，节点的信息可以包括用户信息、用户的信用评分或金融机构信息等数据。边可以表示用户之间的关系或用户与金融机构之间的关系，例如边可以表示好友关系或合作关系等。或者，边可以表示一个节点对另一节点的操作或行为，例如边可以表示：转账、借贷、消费或储蓄等。基于该图，可以通过某一用户已知的信用评分，评估或预测与该用户存在好友关系的另一用户的信用评分。或者，可以基于该图，通过用户转账或贷款等金融行为评估该用户的信用评分。
36.或者，以图数据用于广告推荐为例。节点可以是用户、广告或商品等。节点的信息可以包括用户的信息、商品介绍、广告点击率等。边可以是用户的行为，例如购买或点击等。基于该图，根据用户历史购买商品的记录或者点击广告的行为，可以预测用户点击某一广告的概率，从而针对不同用户实现个性化的广告推荐。
37.随着基础数据量的增长，针对关系网数据存储、计算的图数据的规模也越来越大。在以上图数据库的应用场景中，图数据可能会包括海量的点数据和边数据。一些图数据的节点的邻边数量甚至达到了数千万个（这样的节点也可称为超大点）。例如，在金融系统中，金融机构可能拥有几千万的关系用户。又如，在社交网络上，一个名人明星或主播可能也有几千万的粉丝。虽然这样的点并不见得多，但是因为它们的邻居非常多，导致在查询路径上很容易遇到这样的点。作为一个示例，根据转账关系查询涉及到主播的网络诈骗就可能会遇到超大点等。如果对这样的点的边进行遍历查询，对处理器或内存的性能影响可能会非常严重，但是在几乎所有的查询场景里，通常不会需要某个超大点的所有边（或称全量边），而是需要从超大点的边中找出符合某种条件的边。以社交网络为例，可能需要查询某个主播的粉丝中的男性粉丝或年龄在20
‑
40岁的粉丝的数量。以金融场景为例，可能需要查询某个金融机构的用户中的日转账数额在20万元以上的用户。
38.可以理解的是，在以上图数据库的应用场景中，如何提高对边数据的检索效率几乎是每个图数据库必须要面对的问题。随着基础数据量的不断增长，该问题也变得越来越突出。
39.面对上述问题，一种最糟糕的方案就是对点边数据不作任何处理，此时就需要将该点的所有边数据都读出来，在内存中进行处理。这样一来，待处理边数据量比较大，就会占用较大内存。在遇到超大点的情况下，可能导致需要处理的数据超过内存的容量，此时则需要将数据写到磁盘上，从而导致数据处理过程需要频繁地访问。与内存输入输出（input output，io）相比，磁盘io的时延较长，大量的磁盘io也可能会成为系统瓶颈，甚至导致查询超时或查询失败。
40.为了提高边数据的检索效率，一些相关技术提出了为边数据建立索引的方案。但
是，针对边数据的检索，目前使用的主流索引为全局索引。全局索引通常是基于边数据的部分或全部属性数据建立的。例如，全局索引一般包括键和值两部分，全局索引的值一般至少会包含边数据的主键（edge key），甚至会包含边数据中的除主键之外的其他属性数据。在基于全局索引进行边数据查询的过程中，可以先根据过滤条件定位到全局索引中的值（即定位到边数据的主键），然后基于边数据的主键从边数据中找到该主键对应的边。
41.全局索引的存储或实现方式需要重复存储部分甚至全部的边数据。此外，基于全局索引通常只能定位找到边数据的主键，在得到边数据的主键之后，接下来还需要基于边数据的主键重新查找边数据，计算过程复杂，cpu开销大。由此可见，全局索引存在诸多问题。
42.为了解决全局索引存在的问题，一些相关技术对单个点对应的邻边的边数据建立单点索引，该单点索引可以将边按照索引值排序，多个索引之间的排序可以根据优先级按树形进行排列，以提升查询效率。索引值相同的边会被排列到一起，这种情况下，索引和边之间是一对多的关系。可以理解的是，当出现多对多的情况时，索引数据整体上只能围绕一种排序规则进行排序，无法同时围绕多种排序规则进行整体排序。作为一个示例，假设索引数据包含转账时间、转账金额、转账的货币类型等多种索引值，则该索引数据可以先按照转账时间排序，只有当转账时间相同时再按照转账金额进行排序，当转账金额相同时再按照转账的货币类型进行排序。无论如何，该索引数据整体上不可能按照转账时间、转账金额和转账的货币类型同时进行排序。在这种情况下，只有按照索引数据的排序规律查询才能获得较好的性能提升。例如，在上面的示例中，如果希望查找符合如下过滤条件的边数据：<转账时间，转账金额，转账的货币类型>，则由于该过滤条件符合存储排序规则，通过一次io即可快速查找到目标边数据。但是，如果过滤条件是希望找到转账货币类型的边数据，则由于边数据整体上并非以转账的货币类型进行排序，需要通过多次io才能找到期望的目标边数据。从上述描述内容可以看出，这样的索引是不够灵活的。
43.由上文可知，相关技术中提供的边数据的索引方式存在诸多缺陷。随着图数据的数据量越来越大，亟需寻找一种更为有效的边数据索引方式。
44.下面结合附图1，对本公开实施例提出的图数据库存储结构进行详细描述。
45.图数据库可以存储图的数据。图可以包括多个节点，其中每个节点可以包括一个或多个边。为了便于描述，后文主要以图中的第一节点为例进行描述。应理解，第一节点可以为图中的任意一个节点。图中的其他节点的数据也可以按照与第一节点类似的方式在图数据库中进行存储。
46.图1示出了第一节点在图数据库中的存储结构。从图1可以看出，图数据库以单点数据块的形式存储第一节点的数据。第一节点对应单点数据块10。该单点数据块10存储有第一节点的点数据和第一节点的邻边的边数据。也就是说，本公开实施例将点数据和其邻边的边数据存储在一起。
47.如果第一节点所在的图为无向图，则第一节点的邻边可以包括与第一节点相连的任意邻边。如果第一节点所在的图为有向图，则第一节点的邻边可以包括以第一节点为起始节点（或源节点）的邻边。当然，在一些实施例中，第一节点的邻边也可以包括以第一节点为目标节点的邻边。
48.在一些实施例中，第一节点的邻边可以指第一节点的一度邻边，即图中的与第一
节点直接相邻的边。在另一些实施例中，第一节点的邻边也可以包括与第一节点的n度邻边（n为大于1的整数）。n的取值可以根据实际场景或实际的查询需求设定。
49.在不同场景下，第一节点及其点数据的内容可以有不同的含义。例如，第一节点可以是一个人，也可以是一个账户或平台等，第一节点的点数据可以包含标识（identity，id）编号，也可以包含其他属性信息。示例性地，在社交网络中，当第一节点为一个人时，第一节点的点数据可以包括年龄、性别、身高等属性信息。在资金网络中，当第一节点为一个账户时，该节点的属性信息例如可以为账户名、账户的创建时间、账户余额等。本公开对第一节点的类别和属性信息不做具体限制。
50.同理，在不同场景下，第一节点的边数据可以包括不同的属性数据。示例性地，在社交网络中，当边表示好友关系时，边数据可以包括聊天时长、点赞次数等属性。在资金网络中，当边表示转账关系时，边数据可以包括转账时间和转账金额等属性。
51.进一步地，在一些实施例中，该单点数据块10还可以包括边数据的索引数据。该索引数据可以用于对第一节点的边数据的第一属性进行索引。该第一属性可以是边数据中的所有属性中的任意一种属性，第一属性的具体内容可以根据实际的检索需求设定。以边数据的属性包括转账时间、转账金额、转账的货币类型为例，则第一属性可以是转账时间、转账金额、转账的货币类型中的任意一种。
52.在一些实施例中，上述边数据的索引数据例如可以记录有该边数据对应的位置信息。边数据对应的位置信息可用于定位第一节点的各个邻边的边数据在整个边数据中的位置。某个边对应的位置信息例如可以包括偏移值（offset）和长度（length）。偏移值可用于指示该边对应的数据相对于单点数据块的起始存储位置的偏移量。长度可用于指示该边对应的数据所占的存储空间的大小。基于偏移值和长度，即可推算出该边对应的数据在单点数据块中的存储位置。
53.与前文提到的边数据的全局索引不同，本公开实施例提供的索引数据中存储的是边数据的位置信息（而不是重复存储边数据的主键），因此该索引数据并不会产生数据冗余。由于位置信息所占的存储空间通常非常小（如前文提到的“偏移值 长度”所需要的存储空间非常小），会极大地降低索引数据的数据量，从而可以从整体上降低图数据的数据量。
54.在一些实施例中，索引数据可以包括索引名称和索引值。该索引名称可以为第一属性的属性名。该索引值可以为第一属性的属性值。以第一属性为转账金额为例，则索引数据的索引名称可以为转账金额，索引数据的索引值可以为具体的转账金额值（如200元）。以第一属性为转账的货币类型为例，则索引数据的索引名称可以为转账的货币类型，索引数据的索引值可以为人民币或者美元。
55.可选地，该索引块还可以包括索引数据的数据类型。索引数据的数据类型例如可以为字符型、布尔型、整型等，本公开实施例对此不做具体限制，可以根据需要自行设置。
56.单点数据块可以存储在一个文件中。例如，可以将单点数据块的数据在一个文件对应的存储位置中连续存储，以方便索引和查找。而且，一个文件的数据通常不会分布在多个服务器中，因此，即使在分布式存储场景中，边数据和边数据的索引数据也不会被存储在不同的服务器，从而可以降低服务器之间的通信开销。
57.基于如图1所示的图数据存储结构，本公开实施例还提出了一种图数据的查询方法。下面结合附图2，对本公开实施例提出的图数据查询方法20进行详细描述。
58.参见图2，在步骤s21，接收查询请求。该查询请求可以包含第一属性的属性值的过滤条件，该查询请求用于查询第一节点的邻边中的满足过滤条件的目标边。查询请求例如可以由图数据库的用户向数据库发送。该查询请求例如可以是sql命令。
59.以第一属性为转账的货币类型为例，则第一属性的属性值可以包括人民币和美元。第一属性的属性值的过滤条件可以为人民币。
60.以第一属性为转账金额为例，则第一属性的属性值可以是0~200元之间的任意值。第一属性的属性值的过滤条件可以为0~200元。
61.在一些实施例中，查询请求除了包括第一属性的属性值的过滤条件之外，还可以包括其他过滤条件。第一属性的属性值的过滤条件与其他过滤条件可以按照任意逻辑关系（如且、或、异或）进行组合。
62.步骤s23，根据索引数据和过滤条件，确定目标边在单点数据块中的存储位置。
63.例如，可以根据过滤条件从索引数据中找到索引值满足该过滤条件的部分索引数据。然后，获取该部分索引数据中存储的位置信息。这些位置信息记录的即为目标边在单点数据块中的存储位置。
64.步骤s25，根据目标边在单点数据块中的存储位置，获取目标边的数据。例如，可以将目标边的数据读取到内存中。然后，可以将该目标边的数据发送给提交查询请求的用户。
65.前文提到的针对第一属性的索引数据可以是单点数据块中存储的索引数据中的一种。单点数据块还可以存储更多种类的索引数据。如图3所示，单点数据块30可以包括多个索引块（针对属性a的索引块和针对属性b的索引块等等）。前文提到的针对第一属性的索引数据可以存储在该单点数据块30中的任意一个索引块中。在单点数据块30中设置多个索引块可以分别用于对边数据的多种属性进行索引，由此可以增加对单点数据块30中边数据索引的灵活性。以边数据包括转账时间、转账金额、转账的货币类型为例，则可以分别针对转账时间、转账金额、转账的货币类型建立索引块，并将这些索引块均存储在单点数据块中。这样一来，图数据库的用户就可以分别针对转账时间、转账金额和转账的货币类型进行查询，且针对每种属性的查询均具有较好的查询性能。此外，通过将索引数据按属性分块查找，每个属性名对应一个索引块，在查询的过程中，可以单线程查询，也可以做并发查询，以提高对边数据查找的灵活性和快速性。
66.在一些实施例中，如图3所示，单点数据块30还包括定位数据。该定位数据可用于对索引块进行定位（参见图2中的步骤s22）。例如，该定位数据可以记录多个索引块各自在单点数据块30中的位置。示例性地，该定位数据记录有属性与索引块（用于索引该属性）的存储位置的映射关系。当存在多个索引块时，利用该定位数据可以方便快速找到所需的索引块。例如，假设接收的查询请求包含针对属性a的过滤条件，则可以先利用该定位数据找到用于索引属性a的索引块，然后再根据该索引块找到符合该过滤条件的目标边的存储位置。
67.在一些实施例中，如图3所示，该定位数据可以存储在第一节点的点数据和边数据之间。当接收到查询请求之后，可以首先通过一次io从单点数据块中读取点数据和定位数据，从而确定索引块的位置。
68.前文提到，图数据中可能存在超大点。这种点的边数据的数据量可能较大，因此，在一些实施例中，可以将边数据划分成多个边数据块进行存储。对边数据进行分块存储，可
以便于管理边数据。
69.为了能精准定位到图数据库中的边数据，同时避免在查找过程中产生网络开销、cpu开销、数据冗余等问题，本公开中图数据库将一单点的点数据以及该单点的邻边的边数据均存储在单点数据块中，同时该单点数据块还包括边数据的索引数据。该索引数据记录有边数据在单点数据块中的位置信息。在边数据的查询过程中，可以先根据过滤条件查询索引数据中对应的边数据的位置信息，然后根据该位置信息直接定位到目标边数据。由于索引数据和边数据同时存储在一个模块中，且索引数据中存储的是边数据的位置信息（省略了计算查询的步骤），因此降低了网络开销、cpu开销以及数据冗余的问题。
70.在一些实施例中，在数据构建的时候可以根据用户指定的索引构建规则，在单点的边属性上建立二级索引，本公开对此不做具体限制。
71.通过本公开的图数据存储结构和图数据查询方法，可以快速读取边数据。示例性地，在对边数据查询过程中，根据节点（node）id可以常数级时间复杂度查找到单点数据块的存储位置，即，通过一次io可以拿到单点数据块的点数据、边数据的属性名以及边对应索引数据的位置，并解析出来。然后，通过遍历全部属性名，可以获取该属性名对应的索引数据块位置，一次io读取并解析。接着，根据过滤规则和上一步拿到的索引数据，过滤出符合要求的边的数据位置。最后，根据边数据位置，可以直接读取边数据并解析。
72.可以理解的是，上述内容所提及的数据存储结构和数据查询方法可以但不限于应用在基于完美哈希的储存系统（perfecthashstore，phstore）。
73.可以理解的是，上述内容所提及的数据存储结构和数据查询方法不仅适用于数据存储在磁盘上的系统，也同样适用数据存储在内存中的系统。
74.可以理解的是，上述内容所提及的数据存储结构和数据查询方法不仅适用于图数据系统，同样也适用于键值系统。
75.可以理解的是，上述内容所提及的数据存储结构和数据查询方法不仅可以在边属性上建立索引，同样也可以在点数据上建立索引。
76.可以理解的是，上述所提及的数据查询方法不限于对异步输入输出（asynchronous input output，aio）查询，同样也可以对同步输入输出（synchronous input output，sio）查询。
77.上文结合图1至图3，详细描述了本公开中的图数据存储结构和图数据的查询方法的实施例，下面结合图4和图5，详细描述本公开的装置实施例。应理解，装置实施例的描述与方法实施例的描述相互对应，因此，未详细描述的部分可以参见前面方法实施例。
78.图4是本公开实施例提供的图数据的查询装置的示意性结构图。所述图数据包括第一节点的点数据以及所述第一节点的邻边的边数据，且所述点数据和所述边数据均存储在所述第一节点对应的单点数据块中，所述单点数据块还包括所述边数据的索引数据，所述索引数据用于对所述边数据的第一属性进行索引，所述索引数据记录有所述第一属性的属性值，所述索引数据还记录有所述第一属性的属性值对应的边在所述单点数据块中的存储位置，该装置40可以包括：接收模块41、确定模块43以及获取模块45。
79.接收模块41可以用于接收查询请求，所述查询请求包含所述第一属性的属性值的过滤条件，所述查询请求用于查询所述第一节点的邻边中的满足所述过滤条件的目标边。
80.确定模块43可以用于根据所述索引数据和所述过滤条件，确定所述目标边在所述
单点数据块中的存储位置。
81.获取模块45可以根据所述目标边在所述单点数据块中的存储位置，获取所述目标边的数据。
82.可选地，所述索引数据位于第一索引块中，所述第一索引块为所述单点数据块包含的多个索引块中的任意一个索引块，所述多个索引块分别用于对所述边数据的多种属性进行索引。
83.可选地，所述单点数据块还包含定位数据，所述定位数据记录有所述多个索引块中的每个索引块在所述单点数据块中的存储位置，所述装置还包括：查询模块42，用于在所述根据所述索引数据和所述过滤条件，确定所述目标边在所述单点数据块中的存储位置之前，根据所述定位数据，查询所述第一索引块在所述单点数据块中的存储位置。
84.可选地，所述定位数据存储在所述点数据和所述边数据之间。
85.可选地，所述边数据存储在多个边数据块中。
86.可选地，所述单点数据块中的数据属于同一文件的数据，且所述单点数据块中的数据在所述文件的存储位置中连续存储。
87.可选地，所述索引数据的索引名为所述第一属性的属性名，所述第一索引的索引值为所述第一属性的属性值。
88.本公开实施例还提供了一种图数据的查询装置，例如可以是计算机、服务器等。图5为本公开实施例中图数据的查询装置50的结构示意图。图数据的查询装置50可以包括处理器51、存储器52、总线53。处理器51和存储器52通过总线53连接，处理器51用于执行存储器52中存储的可执行模块，例如计算机程序。
89.处理器51例如可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，图数据的查询方法的各步骤可以通过处理器51中的硬件的集成逻辑电路或者软件形式的指令完成。处理器51也可以是通用处理器，包括cpu、网络处理器（network processor，np）等；还可以是数字信号处理器（digital signal processor，dsp）、专用集成电路（application specific integrated circuit，asic）、现场可编程门阵列（field programmable gate array，fpga）或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
90.存储器52例如可以包含高速随机存取存储器（random access memory，ram），也可以包括非不稳定的存储器（non
‑
volatile memory），例如至少一个磁盘存储器。
91.总线53可以是工业标准结构（industry standard architecture，isa）总线、外围设备互连（peripheral component interconnect，pci）总线或扩充的工业标准结构（extended industry standard architecture，eisa）总线等。图5中仅用一个双向箭头表示，但并不表示仅有一根总线53或一种类型的总线53。
92.存储器52用于存储程序，例如图数据的查询装置对应的程序。图数据的查询装置50可以包括至少一个软件或固件（firmware）的形式存储于存储器52中或固化在图数据的查询装置50的操作系统（operating system，os）中的软件功能模块。处理器51在接收到执行指令后，执行所述程序以实现上述图数据的查询方法。
93.在一些实施例中，本公开提供的图数据的查询装置50还可以包括通信接口54。通信接口54通过总线与处理器51连接。
94.应当理解的是，图5所示的结构仅为图数据的查询装置50的部分的结构示意图，图
数据的查询装置50还可包括比图5中所示更多或者更少的组件，或者具有与图5所示不同的配置。图5中所示的各组件可以采用硬件、软件或其组合实现。
95.本公开实施例提供的图数据方法可以但不限于应用于图5所示的图数据的查询装置。
96.应理解，在本公开的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本公开实施例的实施过程构成任何限定。
97.在本公开所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
98.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
99.另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
100.在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本公开实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线（例如同轴电缆、光纤、数字用户线（digital subscriber line，dsl））或无线（例如红外、无线、微波等）方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够读取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，（例如，软盘、硬盘、磁带）、光介质（例如，数字通用光盘（digital video disc，dvd））或者半导体介质（例如，固态硬盘（solid state disk，ssd））等。
101.以上所述，仅为本公开的具体实施方式，但本公开的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应以所述权利要求的保护范围为准。