一种图-关系数据库混合存储的方法和装置与流程

【技术领域】

本发明涉及数据库领域，特别是涉及一种图-关系数据库混合存储的方法和装置。

背景技术：

关系数据库基于实体-关系模型实现，但是在关系数据库的具体实现中，关系和实体被人为分割开，只能通过主、外键进行关联，导致查询基于大量关系是性能无法忍受，直接导致了图数据库的出现。图数据库直接基于现实世界的实体和关系建模，相较于传统的关系数据库更简单一定，且更使用与分析多层次的复杂关系，更能适应当今海量的数据处理形式。

但是，对于基于关系数据库或键值数据库实现的非原生图数据库，不能直接以图的数据结构进行存储，而需要使用关系数据库或键值数据库的存储方式来保存图信息，将图结构转换为关系数据库或键值数据库的数据行结构，存储在关系数据库的文件页中，将图形数据存储在关系表或键值表中，将图查询转换为基于关系表查询或键值查询。对于这种非原生图数据库的存储方式和查询方式，如果要处理连续、复杂或不断变化的数据会有很大难度，并且还会有一些功能缺陷，以及性能、完整性、易用性和可扩展性方面的风险。

鉴于此，如何克服该现有技术所存在的缺陷，解决非原生图数据库在进行大数据量查询时性能和应用程序响应速度降低的现象，是本技术领域待解决的问题。

技术实现要素：

针对现有技术的以上缺陷或改进需求，本发明解决了图数据结构存储至关系数据库或键值数据库时存储效率、插入效率、查询效率较低的问题。

本发明实施例采用如下技术方案:

第一方面，本发明提供了一种图-关系数据库混合存储的方法，具体为：根据图对象的顶点数据或边数据产生行记录，行记录包含顶点和边的连接关系；根据图类型获得行记录的标签id，每一个图标签对应唯一一个标签id；为行记录分配行id，行id在每个标签id下唯一；根据行记录的标签id和行id将行记录的索引保存在相应的b+tree中，每个b+tree对应一种图标签；根据行记录的在b+tree中的逻辑顺序，获得行记录所在的数据库文件页；将行记录存储至相应的数据库文件页。

优选的，行记录具体为：包括顶点行记录和关系行记录；顶点行记录根据图对象的顶点数据产生，包含该顶点所在关系链表中的头节点，每个顶点行记录拥有至少一个数据库外部主键构建的辅助索引；关系行记录根据图对象的边数据产生，包含该边的起点和终点数据，以及起点的上一个关系的数据，和终点的下一个关系的数据。

优选的，若行记录为顶点行记录，根据行记录的标签id和行id将行记录的索引保存在相应的b+tree中，具体为：以顶点行记录的外部主键为主键，标签id和行id为值建立顶点索引；根据标签id确定顶点索引所在的b+tree；以外部主键作为b+tree中的键值，确定顶点索引在b+tree中的位置，将顶点索引插入b+tree中。

优选的，若行记录为关系行记录，根据行记录的标签id和行id将行记录的索引保存在相应的b+tree中，具体为：以关系行记录的外部主键为主键，标签id和行id为值建立关系索引行记录，根据标签id确定关系索引所在的b+tree；根据行id确定关系索引在b+tree中的位置，将关系索引插入b+tree中；根据关系行记录中一个顶点的辅助索引，通过顶点索引查找关系起点和终点的标签id和行id；根据起点和终点的信息，将行记录起点的前一个关系、起点的后一个关系、终点的前一个关系、终点的后一个关系赋值给行记录；将关系行记录中相应的关系信息赋值给起点和终点所在的顶点行记录。

优选的，将关系行记录中相应的关系信息赋值给起点和终点所在的顶点行记录之前，还包括：根据关系行记录的起点和终点的标签id和行id得到起点和终点的顶点行记录；根据起点和终点所在的关系链表，对起点和终点相关的关系头节点进行更新。

优选的，获得行记录所在的数据库文件页，具体为：根据行记录的行id查找行记录在b+tree中的位置，根据行记录在b+tree中的存放位置，获得行记录在文件页中的具体插入位置，行记录在文件页中的逻辑顺序与行记录的索引在b+tree的子节点中的排列顺序相对应。

优选的，还包括：每个文件页中保存文件中每个空闲空间的首地址列表，插入行记录时根据空闲空间的首地址列表获得行记录的插入地址。

优选的，若行记录所在的文件页没有足够的空间供当前行记录插入，还包括：申请新一个的文件页；将当前文件页中的行记录按照外部主键大小排序，并按顺序平均分为两部分，外部主键值较大的行记录保存在当前文件页中，外部主键值较小的行记录插入新申请的文件页中；根据当前行记录的外部主键值判断当前行记录应插入的文件页和插入位置；根据拆分后的两个文件页的外部主键值，更新b+tree中当前行记录所在节点的父节点信息。

优选的，还包括：每个文件页都保存该文件页保存的所有行记录的目录，插入行记录前，先将行记录在文件页中的偏移位置存入目录中的相应位置。

另一方面，本发明提供了一种图-关系数据库混合存储的装置，具体为：包括至少一个处理器和存储器，至少一个处理器和存储器之间通过数据总线连接，存储器存储有可被至少一个处理器执行的指令，指令在被处理器执行后，用于完成权利要求1-9任一的图-关系数据库混合存储的方法。

与现有技术相比，本发明实施例的有益效果在于：通过b+tree的数据结构对图结构的点、边进行存储，并且将图结构中的关系作为点、边存储的一部分附着其上。通过该存储方法，可以减少存储空间和对数据结构的额外维护，并使得查询时能够以点为中心进行搜索，提高查询效率。

本发明提供了一种图-关系数据库混合存储的方法和装置，其目的在于使用特定的数据结构将图数据库的数据结构存储进非原生图数据库文件中，以提高非原生图数据库的插入、查询效率和响应速度。

【附图说明】

为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图作简单地介绍。显而易见地，下面所描述的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种图-关系数据库混合存储的方法流程图；

图2为本发明实施例提供的一种图-关系数据库混合存储的方法实施例中使用的图模型的示意图；

图3为本发明实施例提供的一种图-关系数据库混合存储的方法实施例中使用的关联关系结构的示意图；

图4为本发明实施例提供的一种图-关系数据库混合存储的方法中b+tree数据结构的示意图；

图5为本发明实施例提供的另一种图-关系数据库混合存储的方法的流程图；

图6为本发明实施例提供的一种图-关系数据库混合存储的方法文件和文件页数据结构示意图；

图7为本发明实施例提供的一种图-关系数据库混合存储的方法文件页数据结构示意图；

图8为本发明实施例提供的一种图-关系数据库混合存储的方法行记录数据结构示意图；

图9为本发明实施例提供的另一种图-关系数据库混合存储的方法数据结构示意图；

图10为本发明实施例提供的另一种图-关系数据库混合存储的方法数据结构示意图；

图11为本发明实施例提供的另一种图-关系数据库混合存储的方法的流程图；

图12为本发明实施例提供的一种图-关系数据库混合存储的装置结构示意图。

【具体实施方式】

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

本发明是一种特定功能系统的体系结构，因此在具体实施例中主要说明各结构模组的功能逻辑关系，并不对具体软件和硬件实施方式做限定。

此外，下面所描述的本发明各个实施方式中所涉及到的技术特征只要彼此之间未构成冲突就可以相互组合。下面就参考附图和实施例结合来详细说明本发明。

对本发明实施例中使用到的一些术语解释如下：

(1)b+tree：b+tree为一种树类型的数据结构，叶子节点存储具体数据，其它节点都仅储存数据索引。b+tree的所有叶子节点按照索引大小排序，并构成双向链表，便于通过索引查询行记录所在的逻辑位置。在本发明实施例中，叶子节点存储图数据转换后的行记录，非叶子节点储存行记录的外部主键key，key和进行存储的数据库文件页页号pageid对应，从小到大依次对比，当前行记录的key小于等于索引页的某一个位置的key时，则表示当前行记录存在的位置为对应位置的页号所表示的文件页。

(2)顶点模型：记录图结构中的顶点相关信息，在不影响理解的情况下简称为顶点。在本发明实施例中，顶点模型的相关属性信息以顶点行记录的形式保存在数据库文件中。

(3)关系模型：记录图结构中的边相关信息，以及边连接的两个顶点的下一个关系信息，以便于继续进行查找，在不影响理解的情况下简称为关系。在本发明实施例中，关系模型的相关属性信息以关系行记录的形式保存在数据库文件中。

(4)关联关系：顶点模型、关系模型之间联系。关联关系包括两种：顶点模型的关联关系、关系模型的关联关系。顶点模型的关联关系就是顶点的关系模型链表的头节点。关系模型的关联关系是当前关系模型起始顶点模型的前一个关系模型、起始顶点模型的后一个关系模型、终止顶点模型的前一个关系模型、终止顶点的后一个关系模型。在本实施例中，关联关系使用双向链表存储，用于对各顶点的下一个关系进行查找。

(5)关系链表：图中多个相互连续的关联关系的链表。如：关系l1的起点为n1终点为n2，关系l2的起点为n2终点为n3，则可以以关系链表表示为：l1->l2，或n1->n2->n3。在本实施例中，关联关系的链表即为一种关系链表。

(6)文件：数据库进行数据存储的位置，每个文件内可以包括多个文件页。本发明实施例中，每个文件存储一个b+tree中的所有叶子节点对应的行记录，文件与标签id(lableid)一一对应，每个pageid中包含多个key对应的行记录。

实施例1：

图数据库中使用图数据结构对数据进行整合，图结构具有顶点和边，分别存储数据和数据间的关系。因此，在使用非图原生图结构的数据库对图结构的数据进行存储时，需要对图结构的顶点和边，即数据本身和数据之间的关系进行存储。

如图1所示，本发明实施例提供的图-关系数据库混合存储的方法具体步骤如下：

步骤101：根据图对象的顶点数据或边数据产生行记录，行记录包含顶点和边的关联关系。

图具有顶点和边两种表示信息的对象，顶点表示具体数据，边表示顶点之间的连接关系。一般情况下，图数据库使用有向图结构，因此每个边都具有确定的起点和终点。为了将图的结构转换为为关系数据库的形式进行存储，因此需要将顶点和边的数据都转换为相应的关系数据库行记录进行存储，每一个顶点或一条边对应一条行记录。为了便于进行数据库存储，在本实施例的具体实施场景中，行记录中除了顶点或边本身包含的数据外，还可以增加其它辅助信息，如：属性值列表、外部主键、外部主键的枚举类型等。在本实施例中，可以使用标签id和行id共同组成全局的联合主键作为全局的外部主键使用。

步骤102：根据图类型获得行记录的标签id，每一个图标签对应唯一一个标签id。

在本发明实施例中，为了便于查找，使用b+tree对图中顶点和边的索引进行组织，每一种图类型对应一棵b+tree。因此，根据图结构产生行记录时，为了区别不同图类型，即确定不同的行记录索引所在的b+tree，因此在行记录中保存相应图类型的标签id(lableid)。同时，由于每一个不同的图类型对应一个不同的数据库文件，因此也使用lableid对行记录所在的文件进行查找和插入。

步骤103：为行记录分配行id，行id在每个标签id下唯一。

为了区别同一个lableid下不同的行记录，因此还需要为同一个labelid下的行记录分配行id(rowid)。rowid并非全局唯一，而是仅在同一labelid下唯一，lableid和rowid的组合可以视为行记录在数据库全局中的联合主键。在本发明实施例中，使用rowid在某一图类型下的b+tree内和文件内进行行记录的查找和插入。

步骤104：根据行记录的标签id和行id将行记录的索引保存在相应的b+tree中，每个b+tree对应一种图标签。

为了便于对行记录进行查找，提高查找效率，因此本发明实施例选择查找效率较高的b+tree的形式对顶点和边的行记录进行组织。在b+tree中保存行记录的索引，根据行记录的索引在b+tree中的排列顺序对行记录进行存储，即可方便的利用b+tree较高的查找效率，通过行记录的索引在b+tree中的位置确定相应的行记录在数据库文件中的偏移地址。在同一棵b+tree内，不同的行记录通过rowid进行唯一标识。

步骤105：根据行记录的在b+tree中的逻辑顺序，获得行记录所在的数据库文件页。

在本发明实施例中，为了便于利用b+tree对行记录的位置进行高效查找，因此行记录的存储顺序与通过b+tree组织的行记录的索引顺序相互对应。在进行存储时，先通过步骤104将行记录的索引插入b+tree中，即对行记录根据键值进行排序，确定存储顺序，再根据通过b+tree确定的存储顺序将行记录存入数据库文件的相应位置。以本实施例提供的存储方式对行记录进行存储后，由于行记录的存储顺序和b+tree中行记录索引的存储顺序一致，因此可以通过b+tree对行记录的存储位置进行查找，快速定位行记录的存储位置。

步骤106：将行记录存储至相应的数据库文件页。

本发明实施例中，每个类型的图结构中的数据使用一个b+tree进行组织，每个b+tree使用一个数据库文件进行存储。因此，每个图结构的labelid可以用于确定其保存的文件，作为b+tree键值的外部主键可以用于确定需要保存的具体文件页(pageid)位置。

经过本实施例中提供的步骤101-步骤106后，即可将图数据库中以图结构保存的数据，在保留图结构关联关系的前提下，以关系数据库的行结构文件进行存储。由于使用了b+tree对图结构中的顶点和边的存储顺序进行组织，并在将图的顶点和边数据转换为行记录时预留了固定大小的存储空间，因此可以方便的利用b+tree确定行记录的存储位置，并在存储后方便的利用b+tree对已插入的行记录进行查找定位，便于后续的修改、删除等操作。

本实施例提供的图-关系数据库混合存储的方法提高了将非原生图数据库存储时的存储效率、插入效率、查找效率，从而提高数据库整体的操作执行效率。

实施例2：

基于实施例1提供的图-关系数据库混合存储的方法，在不同的具体应用场景中，还可以根据使用需求或实际场景的不同进行补充和调整。

在本实施例的具体实施场景中，如图2所示，图模型中包含4个顶点：n1、n2、n3、n4，每个点的顶点行记录的数据结构如图中顶点数据模型所示。图模型中还包含4条边：l1(n3-n4)、l2(n2-n3)、l3(n1-n3)、l4(n1-n2)，每个边的关系行记录的数据结构如图中关系数据模型所示。如图3所示，这些边又组成了关联关系的关系链表：l4-l2-l1(以顶点表示为n1-n2-n3-n4),l3-l1(以顶点表示为n1-n3-n4)，这些关联关系不单独存储，而是通过关系数据模型中的“起点上一个关系”、“起点下一个关系”、“终点上一个关系”、“终点下一个关系”相互关联，以双向链表形式进行顺序查找。

如图2所示的顶点数据模型和关系数据模型中，为了便于对相应的顶点行记录和关系行记录在b+tree中进行查找，每个行记录还包括数据库外部主键构建的辅助索引。如图4所示的b+tree结构，使用数据库外部主键作为行记录的索引在b+tree中的键值进行b+tree的构建，将行记录的lableid和rowid构成的索引值保存在b+tree的叶子节点中。构建b+tree结构的索引后，用户即可方便快速的使用数据库外部主键、或lableid和rowid组成的联合主键，对行记录的存储位置进行查找。

进一步的，存储一个关系行记录时，除了要存储关系行记录本身，还要对该关系行记录相关的所有连接关系进行存储。如果行记录为关系行记录，那么在插入之前，需要维护当前关系起点、终点关系的双向链表。因为初始状态的关系行记录，起点的前一个关系、起点的后一个关系、终点的前一个关系、终点的后一个关系，在行记录中相应的值都为空。由于关系链表采用的是头插法，为了保证能够通过双向链表获得所有的关联关系，需要通过行记录中起点和终点的lableid和rowid查找起点和终点的顶点行记录，如当前关系行记录所表示的关系为顶点的头关系，将当前关系的信息赋值给相应的顶点。再通过起点和终点记录的关系信息，将起点的上一个关系和终点的下一个关系赋值给当前关系行记录，将起始顶点的关系头节点信息，赋值给当前关系起始顶点的后一个关系；将终止顶点的关系头节点信息，赋值给当前关系终止顶点的后一个关系。

具体的，以插入图2的图模型中n3相关的l1、l2、l3三条边相应的关系行记录为例，如图5所示，插入各关系行记录后更新关系链表的过程如下：

步骤201：n3顶点的头关系数据初始化为空(null)。

步骤202：插入关系l1。

步骤203：更新n3关系头节点为l1。

步骤204：更新n4关系头节点为l1。

步骤205：插入关系l2。

步骤206：维护l2起始顶点n2的关系链表，获取n2的关系起始节点为null，赋值n2关系的头节点为l2。

步骤207：维护l2终止顶点n3的关系链表，获取n3的关系起始节点l1，n3在l2中为终止顶点，将l2中终止顶点的下一个关系赋值为l1。n3在l1中为起始顶点，将l1起始顶点的上一个关系赋值为l2，更新n3关系的头节点为l2，将l2中起始顶点的下一个关系，赋值为l1。

步骤208：插入关系l3。

步骤209：维护l3起始顶点n1的关系链表，获取n1的关系起始节点为null。赋值n1关系的头节点为l3。

步骤210：维护l3终止顶点n3的关系链表，获取n3的关系起始节点l2，n3在l3中为终止顶点，将l3中终止顶点的下一个关系赋值为l2。n3在l2中为终止顶点，将l2终止顶点的上一个关系赋值为l3，更新n3关系的头节点为l3。

进一步的，在文件页中插入、删除行记录，或对行记录的关联关系进行更新后，都会触发文件页的刷盘机制，将数据库的变更信息保存至长期存储介质中。

经步骤201-步骤210，即可将所有顶点间连接关系赋值给相应的顶点行记录和关系行记录，在不额外对关联关系进行存储的前提下，通过在顶点行记录和关系行记录中存储和更新顶点间的连接关系。既节省了存储空间，又在关系数据库中还原了图数据库的查找模式，避免了关系数据库中多级查找时效率过低的问题。

实施例3：

基于实施例1和实施例2提供的图-关系数据库混合存储的方法，在不同的具体应用场景中，还可以根据使用需求或实际场景的不同进行补充和调整。

在关系数据库中，每一条记录都以行记录的形式存在，本实施例中即顶点行记录和关系行记录。具体的，行记录存储在文件中，在本实施例中，每一个图类型对应一个lableid，每个lableid下的行记录的索引存放在于一个b+tree中，每个lableid下的行记录存储在同一个文件中。

为了便于数据库管理工具的存取，如图6所示，一个文件中可以包含多个文件页，每个文件页大小固定。每个文件页中存储多个行记录，行记录按照b+tree中组织的顺序排列，即按照外部主键的顺序排列，因此当行记录的外部键值小于等于该文件页中最大的外部主键页时，行记录位于该文件页内。文件页包括存储行记录的数据文件页(data_page)和存放索引的索引文件页(index_page)。

在一个数据文件页中，行记录的具体存储结构如图7所示。行记录(records)块中存储行记录数据，一般按照b+tree中组织的顺序按照key的大小依次自文件头向文件尾插入。文件的页头(pageheader)中保存有本页的空闲空间列表(page_free)，即对应每个行记录的地址块的空闲空间的首地址列表，空闲空间列表的首指针即顺序插入的下一条行记录时，该行记录的插入位置。在本实施例的具体使用场景中，为了更方便的对某个文件页内的行记录进行查找，文件页还包含页目录(pagedirectory)，页目录中保存每一条行记录在当前文件页中的偏移地址。为了避免页目录和行记录的存储空间，并方便查找最新插入的行记录存储位置，页目录从文件页尾部开始，按照行记录的逆序进行排序。

图6和图7中文件页各部分名称的对应关系如下：

fileheader+pageheader–head；

records--user_data；

freespace–free_space；

pagedirectory--page_directory；

filetrailer–tail。

在本实施例的某些具体实施方案中，行记录的具体格式如图8所示。其中，行记录的记录头信息(row_head_info)中记录该行记录的唯一标识(row_id)，唯一标识对应行记录的rowid。图对象关联id(row_relation)项的值为图对象关联id对应的lableid。图对象关联信息与表示该图顶点或边的关联关系。如果此行记录为顶点行记录，那么此行记录的图对象关联信息中就将存储其关系链表头节点的信息。如果此行记录为关系行记录，那么图对象关联信息中就将存储起止顶点前后关系的信息。

进一步的，在本实施例的某些具体实施场景中，不同lableid的行记录属性数量不同，相同lableid的行记录中某个属性值也可能为空(null)，为了减少行记录的存储空间，行记录采用变长空间进行存储。具体的，如图8所示，在行记录中使用变长字段列表var_field_slots存储当前行记录中每个变长字段在行记录中的偏移值，var_field_slots中每个元素占用2byte，每个元素表示一个变长字段的偏移，占用的总大小为该类型下的变长字段数量*2byte。同时，使用null标志位null_flag属性指示行记录的每一个属性值是否被使用。null_flag占用大小根据行记录的lableid决定。该lableid有多少个属性字段，则占用多少位。占用大小向上取整字节数(0表示为null，1表示不为null，为null的属性字段值除了标志位不占用存储空间)。例如：假设标签类型为“人”，该类型有12个属性字段，则至少需要12个二进制数标识其是否为null，像上取整字节数则需要2个字节＝16位。0000000000000101表示第一个、第三个属性值不为null，其余属性都为null。

进一步的，在本实施例的某些具体实施方案中，向文件页中插入行记录时，若当前文件页中没有足够的空闲空间来来存储需要插入的行记录，那么触发文件页的分裂。申请一个新文件页，将当前文件页上保存的行记录根据外部主键值分配至当前文件页和新申请的文件页中。当前文件页的行记录数量一分为二，行记录按照外部主键key的值排序，并平均分为key值较大的一部分和key值较小的一部分。将key值较大的行记录数据保留在当前页号表示的文件页块中，将key值较小的行记录数据插入到新申请的页号表示的文件块中，那么理论上第一块文件页的key永远是当前文件中key值最大的那部分，且行记录的排列顺序不会发生变化。将一个文件页分裂为两个文件页后，产生了新的空闲空间，可以再根据待插入行记录的key值判断该插入的文件页。

进一步的，在本实施例的某些具体实施方案中，为了提高删除效率，减少磁盘读写带来的时间损失和磁盘寿命损失，因此，行记录头信息中还设置删除标志(delete_flag)，对行记录进行删除时，仅删除页目录中，而不删除实际存储的行记录数据，仅修改行记录的删除标志为“已删除”：。对于删除标志为“已删除”的行记录，其存储空间视为空间存储空间。如图9和图10所示，删除行记录c时，仅删除页目录中行记录c的相应项，并将行记录c的删除标志设置为“已删除”，再将空闲空间列表中的空闲空间首指针改为行记录c存储空间的首指针地址。需要向行记录c位置插入新的行记录时，将存储行记录c的存储空间作为空闲空间进行判断和使用。

经上述存储过程，如图11所示，可以对各顶点的间的关联关系进行快速查找和遍历。假设顶点n类型为人，关系l类型为朋友，查找n1所有朋友的过程如下。其中，在b+tree中查找索引的过程与一般的b+tree查找算法一致。

步骤301：通过顶点索引文件定位顶点n1的rowid。

步骤302：根据n1的rowid查找存储n1的顶点索引的索引文件页，在中索引文件页中存储的b+tree结构中通过rowid在b树中查找定位节点对象n1。

步骤303：根据n1行记录中的关系头结点定位到关系对象l1，根据l1行记录中的终点数据找到n1的第一个朋友n2。

步骤304：由n2行记录的头关系查找n2的朋友n3，也即n1的二度关联朋友n3。

步骤305：根据n3的顶点行记录数据可知由l1向后遍历结束，回到l1的起点继续遍历，得到l1起点n1的第二个关系l2。

步骤306：在关系索引文件中获得l2的关系行记录存储位置。

步骤307：通过l2的关系行记录找到n3对象下一个关系l3。

步骤308：在关系索引文件中获得l3的关系行记录存储位置，l3的顶点不是n3，因此继续遍历l3终点的下一个关系，找到关系l4。

步骤309：在关系索引文件中获得l4的关系行记录存储位置，通过l4的关系行记录数据找到n3的朋友n4，也即n1的三度关联朋友n4。

步骤310：在节点索引文件中获得n4的顶点行记录存储位置，l4的顶点已无下一个关系，遍历结束。

由步骤301-步骤310可知，通过本发明实施例1至实施例3中提供的图-关系数据库混合存储的方法，可以将图结构中各顶点的连接关系完整的保留在关系数据库中，并通过b+tree对存储顺序和查找方式进行优化。既可以利用关系型数据库简单的存储结构减少存储空间占用，又可以利用行记录中保存的图结构实现多度关联关系的快速查找，提高数据库增删查改操作的效率。

实施例4：

在上述实施例1至实施例3提供的图-关系数据库混合存储的方法的基础上，本发明还提供了一种可用于实现上述方法的图-关系数据库混合存储的装置，如图12所示，是本发明实施例的装置架构示意图。本实施例的图-关系数据库混合存储的装置包括一个或多个处理器21以及存储器22。其中，图12中以一个处理器21为例。

处理器21和存储器22可以通过总线或者其他方式连接，图12中以通过总线连接为例。

存储器22作为一种图-关系数据库混合存储的方法非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块，如实施例1至实施例3中的图-关系数据库混合存储的方法。处理器21通过运行存储在存储器22中的非易失性软件程序、指令以及模块，从而执行图-关系数据库混合存储的装置的各种功能应用以及数据处理，即实现实施例1至实施例3的图-关系数据库混合存储的方法。

存储器22可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实施例中，存储器22可选包括相对于处理器21远程设置的存储器，这些远程存储器可以通过网络连接至处理器21。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

程序指令/模块存储在存储器22中，当被一个或者多个处理器21执行时，执行上述实施例1至实施例3中的图-关系数据库混合存储的方法，例如，执行以上描述的图1、图5和图11所示的各个步骤。

本领域普通技术人员可以理解实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器(rom，readonlymemory)、随机存取存储器(ram，randomaccessmemory)、磁盘或光盘等。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。