一种高度关联大数据的存储方法及管理系统与流程

本发明属于大数据存储领域，具体涉及了一种高度关联大数据的存储方法及管理系统。

背景技术：

在大数据时代，企业或组织机构越来越重视数据的价值，并逐步开始了大数据的采集、存储和分析利用。在这些大数据集中，数据之间的关联是普遍存在的。尤其是在社交网络大数据、医疗大数据等与个体用户密切相关的应用场景中，数据对象之间更是呈现出高度关联的特点。而这些高度关联数据集中存在的数据之间的复杂联系往往具备巨大的分析价值。例如，社交用户之间的朋友关系、药品与病人之间的关联等等。同时，这些高度关联的大数据集也具备大规模、高速性和多样性的特点，因此为了更好地分析和利用它们，就需要对此类数据集的高效存储和管理等问题展开研究。

为了应对大数据的存储需求，通常会有针对性地采用结构化关系数据库存储结构化数据，采用NoSQL数据库存储半结构化或非结构化数据。在这些存储方法中，关系型数据库和大多数NoSQL数据库(例如，键值数据库、文档数据库、列数据库)对于数据之间联系的存储和管理都非常低效。它们存储的都是无关联的记录、值、文档、列，在需要进行数据之间关联性的查询和分析时，需要采用索引、外键、表连接等额外的机制来实现。

与之相对的是，图数据库则专注于数据之间联系的存储和查询，其多层关联查询和反向查询效率远远高于关系数据库和其他NoSQL数据库。多层关联查询是指在数据之间的联系上进行多层查询。例如查询“某个人的朋友的朋友的朋友的朋友”就是在朋友关系上进行多层查询。而反向查询则是指查询的方向与索引建立的方向是相反的。例如，存在索引“病人->药品”，那么查询某个病人买了哪些药品是非常快捷的，但是反向查询买了某个药品的病人有哪些，就要效率低很多。即使为了应对上面的反向查询，建立了“药品->病人”的索引，那么在面对查询“有哪些病人买了药品A，还买了药品B”时，仍然需要进行多次查询，效率较低。图数据库能够解决这些关注数据之间关联关系的查询问题。然而，图数据库无法满足大数据集的规模大和多样化的存储特点。

目前，已经出现了一些混合应用NoSQL数据库和文件系统来存储大数据集的方法。这些方法根据大数据集中不同数据的各自特点，将它们分别存放在了合适的数据库或文件系统中。例如采用结构化关系数据库存储结构化数据，采用NoSQL数据库存储半结构化或非结构化数据。然而由于缺少针对高度关联大数据集中数据之间复杂关联的考虑，也没有与之匹配的数据模型、存储方法和查询方法，所以这些存储在不同数据库或文件系统中的数据集往往相互独立，存在大量冗余，同时在进行复杂关联关系查询时也较为低效。

总之，目前大数据存储领域尚缺乏一种针对存在高度关联关系的大数据集的高效存储和管理方法，无法同时满足大数据的存储需求和对其中复杂联系的高效分析需求。

技术实现要素：

针对上述技术问题，本发明的目的是提供一种针对高度关联大数据的存储方法及管理系统，实现对这类大数据集的存储和管理，同时能够支持高效的关联查询分析。

该技术的基本原理为：基于图数据模型、关系模型、Hashmap模型提出一种以数据实体之间关联关系为核心的混合数据模型，即采用图数据模型描述数据实体之间的关联关系，采用关系模型描述数据实体的结构化属性，采用Hashmap模型描述实体的内容；并分别采用图数据库、关系数据库、键值数据库或分布式文件系统来实现上述数据模型；并采用恰当的策略优化数据实体的关系查询、属性查询和内容查询的优先顺序来提高数据的查询检索效率。

具体地，为了实现上述技术目的，本发明采用以下技术方案：

一种针对高度关联大数据的存储方法及管理系统包括：

1)建立针对高度关联大数据集的混合数据模型；

进一步地，所述混合数据模型包括图数据模型、关系模型、Hashmap模型。

进一步地，所述图数据模型是指用节点表示数据实体，用连接节点的边表示数据实体之间的联系的数据模型。

进一步地，所述关系模型是指关系数据库中采用的规范化模型，即用二维表的形式表示实体和实体间联系的数据模型。本技术方案中只采用二维表来描述实体的属性。即关系模型一般是用来存实体和实体之间联系的，但是本发明在混合数据模型中仅将其用来描述实体的属性。

进一步地，所述Hashmap模型是指采用键来存储和检索后面的值的数据模型。Hashmap模型的实现形式可以是键值数据库或分布式文件系统，两者都可以。

进一步地，混合数据模型的构建方法如图1所示：每个数据实体都具有一个实体类型和一个唯一的ID号；数据实体的属性则采用关系模型中的二维表的形式来描述，即每种实体类型将对应一个形如[数据实体ID|属性A|属性B......]的二维表；Hashmap模型中的键为数据实体的ID号，而值为数据实体的原始内容；数据实体之间的关联通过图数据模型表示，即图数据模型中的一个节点就表示一个数据实体，该节点将被标识上对应数据实体的类型和ID号，而节点之间的边则表示数据实体之间的关联关系；而同一个实体的属性和内容之间的关联则通过实体ID号的映射来表示。

2)与上述混合数据模型匹配的高度关联大数据的存储方法和管理系统；

进一步地，所述高度关联大数据的存储方法和管理系统如图2所示，包括：存储模块、统一数据管理模块和辅助索引机制。

进一步地，所述存储模块是指存储数据实体的多个数据库或文件系统，即用以存储数据实体之间联系的图数据库，用以存储数据实体原始内容的键值数据库或分布式文件系统，用以存储数据实体属性的关系数据库。其中，

所述图数据库实现了图数据模型，即每个数据实体被存储为图数据库中的一个节点，该节点具有实体ID的标识和实体类型的标识。

所述键值数据库或分布式文件系统实现了Hashmap模型。可以但不限于用实体ID作为键。当采用非实体ID作为键时(例如，若干个实体存储在一起时，可以用存储时间或实体ID的组合作为键)，则需要构建一个辅助索引来提高查询效率，即通过实体ID索引到实体内容对应的键。该辅助索引可以实现为关系数据库中的一个表。

所述关系数据库实现了关系数据模型及辅助索引机制，即为每个实体类型构建一张数据表[实体ID|属性A|属性B......]，实体ID是其主键。

进一步地，所述统一数据管理模块，主要实现了数据实体的关联关系、属性、数据内容在不同数据库或文件系统中的增加、删除、更新、查询功能，并采用恰当的策略优化数据实体的关系查询、属性查询和内容查询的优先顺序来提高数据的查询检索效率。

进一步地，所述辅助索引机制，主要用以提高常见查询的效率，即为经常作为查询条件的属性或属性组合构建索引，以实现对实体ID的快速检索。此外，还包括采用非实体ID作为键值数据库或分布式文件系统的键时构建的辅助索引表。

进一步地，所述数据增加流程如下：

步骤A1：将新增数据实体的原始内容存入键值数据库或分布式文件系统，其键设为实体ID或其他唯一标识。若采用非实体ID的其他唯一标识，则在关系数据库中应事先建立好用于辅助索引的表[实体ID|其他唯一标识]，而在新增数据实体时，向该表插入“新增数据实体ID,新的其他唯一标识”的对应关系记录。

步骤A2：提取新增数据实体的属性值，并将这些属性值插入该数据实体的类型所对应的关系表中，新增记录形如“实体ID|属性A|属性B......”。

步骤A3：提取新增数据实体与其他数据实体的关联关系，在图数据库中插入新的节点表示新增数据实体，同时为其设置两个节点属性分别记录实体ID和实体类型，最后根据新增数据实体与其他数据实体的关联关系建立边。当新增数据实体所关联的另一数据实体已在图数据库中存在，则将表示两个实体的节点用边连接即可。若新增数据实体所关联的另一数据实体还没有在图数据库中存在，则应该先在图数据库中建立代表另一个数据实体的节点，然后再用边连接它们。

进一步地，所述数据删除流程如下：

步骤B1：将要删除的数据实体从键值数据库或分布式文件系统中删除，若关系数据库中存在用于辅助索引的表[实体ID|其他唯一标识]，则同时需要删除该数据实体对应的记录。

步骤B2：将要删除的数据实体从关系数据库对应的关系表中删除。

步骤B3：将要删除的数据实体所代表的节点从图数据库中删除，同时将该节点作为端点之一的边也全部删除。

进一步地，所述数据查询流程如下：

步骤C1：根据查询条件中的数据实体之间的关联关系约束，在图数据库中进行匹配查找，获得符合条件的结果集R1。若查询条件不含对数据实体之间的关联关系的约束，则不执行步骤C1，R1直接为空。

步骤C2：根据查询条件中的数据实体的属性约束，在关系数据库中进行匹配查找，获得结果集R2。若查询条件中不含对数据实体的属性约束，则不执行步骤C2，R2直接为空。

步骤C3：根据R1和R2中的实体ID构成的集合来设置结果集R3。若R1和R2都为空，则R3为空。若R1或R2其中任意一个为空，则R3等于其中非空的一个结果集中的实体ID构成的集合。若R1与R2都非空，则设置R3为R1与R2中实体ID集合的交集(可能交集为空)。

步骤C4：若数据查询的结果要求有数据的原文内容，则根据R3中的实体ID，在键值数据库或分布式文件系统中查找到对应的实体内容。若R3为空，即表示R3中没有数据实体，则步骤C4不执行，直接进入步骤C5。

步骤C5：若R 3不为空，则返回查询结果R1、R2、R3及R3中数据实体的内容。若R3为空，则返回R1、R2、R3。

进一步地，所述数据更新流程如下：

步骤D1：基于所述数据查找流程，根据查询条件获取要更新的数据实体的ID集合R3。

步骤D2：若需要更新某数据实体的内容，则根据R3中数据实体ID在键值数据库或分布式文件系统中查找到对应的实体内容，将其替换为新内容。

步骤D3：若需要更新某数据实体的属性，则根据R3中数据实体ID在关系数据库对应的关系表中更新该实体对应的记录。

步骤D4：若需要更新R3中某数据实体与其他数据实体的一些关联关系，则将根据该实体ID定位到表示它的节点，将该节点作为查询的起点，接着从该起点开始按照要更新的关联关系的模式在图数据库中进行匹配查找，当发现需要修改的关联关系时将其更新。

进一步地，所述的优化查询顺序的策略如下：当对关系数据库的查询不含复杂的表连接时，优先进行关系数据库的查询，即交换查询步骤C2与C1的次序，将C2执行的结果集R2中的实体ID作为C1图数据库查询的起始节点，然后再从这些起始节点开始图数据库的路径匹配查询；而当对关系数据库的查询含有复杂表连接时，则优先进行图数据库的查询，即保持步骤C1和C2的次序，通过图数据库的关联查询获得R1，然后再在R1中的实体ID范围内进行复杂的关系数据库的查询，从而提高查询效率。

本发明的有益效果如下：

(一)大数据集中的数据实体之间的关联关系采用了图模型进行建模，并使用了图数据库进行存储，因此能够支持高效地复杂关联查询，即同样软硬件环境下，在图模型上进行复杂关联数据(节点和边构成的路径的长度为3或以上)查找时，性能平均在秒级；而其他采用关系模型、Hashmap模型表达关联关系时，其复杂关联数据查询大多在几十秒，甚至几百秒级别。

(二)大数据集中的数据实体的属性和原始内容被恰当地关联在一起存储，因此能够同时满足对大数据属性和原始内容的查询。

(三)采用了统一数据管理模块，能够根据查询条件的特点对查询顺序进行优化，从而提高查询效率。

附图说明

图1是本发明提出的混合数据模型；

图2是本发明提出的数据管理系统的技术架构；

图3是本发明展示的一个社交网站的数据集的建模示例。

具体实施方式

下面将对发明内容中的关键技术和方法的实施方式进行示例性解释，但不以这种解释限制发明的范围。

1)数据集

以某社交网站的数据为例，数据主要包括用户信息数据，微博信息数据两大类。用户信息数据包括了用户帐号、性别、年龄、爱好、注册时间、用户关注的其他用户的列表、关注此用户的其他用户的列表。微博信息数据则包括了微博的ID、发布的用户帐号、转发微博的ID、微博的内容、发布时间、发布地点、发布微博的设备、@的用户帐号。在这个数据集中存在大量的数据之间的关系：用户之间的关注关系、用户与微博的发布关系、微博之间的转发关系、微博中@的关系。

2)数据建模

如图3所示，先将用户信息中的结构化属性信息建模为关系表UserInfo[用户帐号|性别|年龄|爱好|注册时间]，主键为用户帐号。再将微博信息中的结构化属性信息也建立为关系表Weibo[微博ID|发布时间|发布地点|发布微博的设备]，主键为微博ID。接着将微博的原始文本内容建模为Hashmap模型，将微博的ID作为键。然后将用户帐号、微博ID作为图模型的节点，并将用户之间的关注关系、用户与微博的发布关系、微博之间的转发关系、微博与用户的@关系用节点之间的边进行描述。最后，关系表UserInfo与图模型的用户节点通过用户帐号进行映射关联；关系表Weibo、图模型的微博节点、Hashmap模型通过微博ID进行映射关联。

此外，为了提高查询效率，通常情况下可以允许适当的冗余存在。例如，将关系表Weibo[微博ID|发布时间|发布地点|发布微博的设备]，修改为Weibo[微博ID|发布时间|发布地点|发布微博的设备|发布的用户帐号]。虽然用户与微博的发布关系在图模型中已经描述，修改后增加了数据的冗余，但是这种冗余在进行查询“用户A上个月发布的所有微博”时，具有更高的效率。因为这种无需复杂表连接操作的关系查询是关系数据库所擅长的，所以就无需再去图数据库中查询了，总的数据库查询操作只需要一次。这种建模时对数据冗余的考虑需要根据实际的业务需求而定。

3)存储方法

首先，采用传统关系数据库来实施数据模型中的关系表UserInfo和Weibo的构建，完成对用户和微博两种数据实体的属性的存储；接着，采用键值数据库来实施Hashmap模型，完成对微博原文内容的存储；然后，采用图数据库实施图模型的构建，完成对用户之间的关注关系、用户与微博的发布关系、微博之间的转发关系、微博中@的关系的存储；最后，由于本例子直接采用了微博数据实体的ID作为了键值数据库的键，所以就不需要建立辅助索引了。如果需要加速一些常用的属性条件查询，可适当地在关系数据库中建立其他辅助索引。而上述数据存储方法将由统一数据管理模块来实施，即将采集到的用户信息数据，微博信息数据两类数据按照上面的数据模型进行组织，分别存放在不同数据库中进行管理。