CN111026747A - 一种分布式的图数据管理系统、方法及存储介质 - Google Patents
一种分布式的图数据管理系统、方法及存储介质 Download PDFInfo
- Publication number
- CN111026747A CN111026747A CN201911022943.3A CN201911022943A CN111026747A CN 111026747 A CN111026747 A CN 111026747A CN 201911022943 A CN201911022943 A CN 201911022943A CN 111026747 A CN111026747 A CN 111026747A
- Authority
- CN
- China
- Prior art keywords
- data
- node module
- node
- query
- fragment
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000013523 data management Methods 0.000 title claims abstract description 41
- 238000000034 method Methods 0.000 title claims abstract description 34
- 238000013500 data storage Methods 0.000 claims abstract description 38
- 239000012634 fragment Substances 0.000 claims description 197
- 230000011218 segmentation Effects 0.000 claims description 6
- 238000004590 computer program Methods 0.000 claims description 4
- 238000007726 management method Methods 0.000 description 10
- 238000010586 diagram Methods 0.000 description 4
- 230000008569 process Effects 0.000 description 3
- 239000000284 extract Substances 0.000 description 2
- 238000013467 fragmentation Methods 0.000 description 2
- 238000006062 fragmentation reaction Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000018109 developmental process Effects 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000035515 penetration Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
- G06F16/2228—Indexing structures
- G06F16/2237—Vectors, bitmaps or matrices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
- G06F16/24553—Query execution of query operations
- G06F16/24554—Unary operations; Data partitioning operations
- G06F16/24557—Efficient disk access during query execution
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/284—Relational databases
- G06F16/288—Entity relationship models
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computational Linguistics (AREA)
- Computing Systems (AREA)
- Software Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种分布式的图数据管理系统,包括客户端和一个或多个数据节点模块;用户通过客户端向任意一个数据节点模块发送待写入的三元组数据,数据节点模块根据三元组数据的关系元素将对应三元组数据存储于对应的数据节点模块的数据存储引擎中,实现数据的快速存储;用户通过客户端向任意一个数据节点模块发送查询请求,该数据节点模块将查询请求转发给相应的数据节点模块进行查询,并将所有的数据节点模块的查询结果汇总并返回给客户端,实现数据的快速查询。通过本发明可实现大数据环境下图关系数据的快速存储、快速查询,大大提高了数据存储、查询的效率。本发明还提供了一种分布式的图数据管理方法及存储介质。
Description
技术领域
本发明涉及大数据的存储管理,尤其涉及一种分布式的图数据管理系统、方法及存储介质。
背景技术
随着现代社会的快速发展、互联网的深入渗透、计算机存储能力的提升,各个行业之间产生大量的数据,并且数据量呈指数级增长,而产生的数据按着各种不同类型的关系而彼此联系在一起。比如社交网络中人与人之间的好友关系、企业与员工的雇佣关系、供应商与客户的合作关系等。
当利用传统的关系型数据库存储这类数据时,关系通常都是利用外键来表现,并且通过关联表保持它们直接的关系。这主要是因为关系型数据库是以实体建模这一基础理念设计的,并没有对这些实体间的关系提供直接支持,因此需要另外创建一个关联表以记录这些数据之间的关联关系。随着关系数量和层次的增加,数据库尺寸的增加,传统关系数据库的性能会急剧降低。
但在现实生活中,我们仍对数据之间关系的存储和分析存在着迫切的需求,比如通过对社交网络的好友关系进行分析,向用户推荐可能感兴趣的人。
因此,急需一种能够处理复杂多样的关系数据的数据存储管理系统,来实现对关系数据的存储管理。
发明内容
为了克服现有技术的不足,本发明的目的之一在于提供一种分布式的图数据管理系统,能够解决传统数据库不能够满足大数据情况下海量数据的快速存储与查询的要求的问题。
本发明的目的之二在于提供一种分布式的图数据管理方法,能够解决传统数据库不能够满足大数据情况下海量数据的快速存储与查询的要求的问题。
本发明的目的之三在于提供一种存储介质,能够解决传统数据库不能够满足大数据情况下海量数据的快速存储与查询的要求的问题。
本发明的目的之一采用如下技术方案实现:
一种分布式的图数据管理系统,所述图数据管理系统包括客户端、和一个或多个数据节点模块;客户端与任意一个数据节点模块进行通讯;
数据节点模块,用于接收客户端发送的写入请求并解析得出所有的三元组数据,然后对每个三元组数据进行提取并得出每个三元组数据的关系元素,再查询出每个关系元素对应的数据分片所在的数据节点模块并将相同关系元素的待写入数据转发给对应的数据节点模块,使得对应的数据节点模块将待写入数据存储于数据分片中,并为数据分片建立索引信息以及将数据分片和对应索引信息保存在对应数据节点模块的数据存储引擎中;
数据节点模块,用于接收客户端发送的查询请求,并将查询请求转发给其他的数据节点模块进行查询,最终将所有的数据节点模块得出的查询结果进行汇总后返回给客户端;其中,每个三元组数据均包括第一节点元素、第二节点元素和一个关系元素;数据分片中存储了第一节点元素所对应的第二节点元素的集合,并且第一节点元素和第二节点元素之间具有关系元素的关联关系。
进一步地,每个数据节点模块与其他的数据节点模块定时通过rpc请求的方式进行通讯;数据节点模块定时向其他的数据节点模块发送rpc请求,进而向其他的数据节点模块通知自身所存储的数据分片的元信息,进而使得每个数据节点模块中均存储有所有数据分片的元信息;其中,数据分片的元信息包括数据分片的大小、数据分片的关系元素、数据分片所在的数据节点模块。
进一步地,所述图数据管理系统包括协调节点模块,协调节点模块与每个数据节点模块进行通讯,定时从每个数据节点模块获取数据分片的元信息,并根据配置策略调整每个数据节点模块上的数据分片的分布。
本发明的目的之二采用如下技术方案实现:
一种分布式的图数据管理方法,应用于分布式的图数据管理系统,所述图数据管理方法包括:数据写入步骤和数据查询步骤;
其中,数据写入步骤,用于接收客户端发送的写入请求并解析得出所有的三元组数据,并根据每个三元组数据的关系元素查找对应的数据分片所在的数据节点模块,然后根据关系元素将三元组数据发送给对应的数据节点模块,使得每个数据节点模块根据三元组数据生成数据分片,并为数据分片建立索引信息,最后将数据分片和对应索引信息保存在对应数据节点模块的数据存储引擎中;
数据查询步骤,用于接收客户端发送的查询请求并根据查询请求中的每个关系元素查询得到每个关系元素对应的数据分片所在的数据节点模块,然后将查询请求发送给对应的数据节点模块进行查询,最终将所有的查询结果进行汇总后返回给客户端;其中,每个三元组数据均包括第一节点元素、第二节点元素和一个关系元素;每个数据节点模块的数据存储引擎中存储相同关系元素的一个或多个数据分片,每个数据分片存储第一节点元素所对应的第二节点元素的集合。
进一步地,所述数据写入步骤包括:
获取步骤:获取并解析客户端发送的写入请求得出所有的三元组数据;
查找步骤:提取每个三元组数据的关系元素,并根据关系元素查找得出每个关系元素对应的数据分片所在的数据节点模块;
存储步骤:将相同关系元素的三元组数据转发给对应的数据节点模块,使得每个数据节点模块根据三元组数据生成对应数据分片,并为每个数据分片建立索引信息,以及将每个数据分片和对应索引信息保存在对应数据节点模块的数据存储引擎中;
所述数据查询步骤包括:
获取步骤:获取并解析客户端发送的查询请求得出查询请求所涉及的每个关系元素;
查找步骤:根据查询请求所涉及的每个关系元素查找出关系元素对应的数据分片所存储的数据节点模块,并将查询请求转发给对应的数据节点模块进行查询;
结果返回步骤:将每个数据节点模块的查询结果进行汇总后返回给客户端。
进一步地,所述图数据管理方法包括:分割步骤:定时获取每个数据分片的大小,并且当数据分片的大小超过预设值时,根据系统预设分割规则对数据分片进行分割处理。
进一步地,所述图数据管理方法包括:协调步骤:定时获取每个数据节点模块的数据分片的元信息,然后根据配置策略控制每个数据节点模块中数据分片的分布;所述数据分片的元信息包括数据分片的大小、数据分片对应的关系元素、数据分片所在的数据节点模块。
进一步地,所述三元组数据的格式为:<第一节点元素><关系元素><第二节点元素>。
进一步地,所述数据分片以键值对的形式存储于对应数据节点模块的数据存储引擎中,其中,键值对的形式为:<第一节点元素,关系元素>=[第二节点元素1,第二节点元素2,第二节点元素3,…]。
本发明的目的之三采用如下技术方案实现:
一种存储介质,所述存储介质为计算机可读存储介质,其上存储有图数据管理程序,所述图数据管理程序为计算机程序,所述图数据管理程序被处理器执行时实现如本发明目的之二采用的分布式的图数据管理方法的步骤。
相比现有技术,本发明的有益效果在于:
本发明通过采用图数据的结构来表示实体以及实体之间的关联关系,可实现对各种场景的数据进行建模并形成三元组数据,三元组数据包括两个节点元素和一个关系元素;通过建立多个数据节点模块,将三元组数据根据关系元素的不同将其划分为对应的数据分片并以键值对的方式存储于对应的数据节点模块的数据存储引擎中,进而实现数据的快速存储以及快速查询,满足了海量数据的要求,同时提高了数据处理的性能。
附图说明
图1为本发明提供一种分布式的图数据管理系统模块图;
图2为本发明提供的协调节点模块与数据节点模块的连接示意图;
图3为本发明提供的现有技术中数据查询流程图;
图4为本发明提供的一种分布式的图数据管理系统的查询流程图;
图5为本发明提供的数据写入步骤流程图;
图6为本发明提供的数据查询步骤流程图。
具体实施方式
下面,结合附图以及具体实施方式,对本发明做进一步描述,需要说明的是,在不相冲突的前提下,以下描述的各实施例之间或各技术特征之间可以任意组合形成新的实施例。
实施例一
本发明提供了一种图数据库的方式来实现大数据的存储管理,本发明中的图数据库是相对于传统数据库来说,图数据库是用图数据的结构来描述数据和数据间的关联关系。
其中,图数据一般是由两个元素组成:节点元素和关系元素。每个节点元素代表一个实体,比如人、地、类别或其他数据。每个关系元素代表两个节点元素之间的关联关系。比如,北京属于中国,其中北京、中国均为节点元素,属于为关系元素。
通过上述这种图数据的结构方式可以实现对各种应用场景中的数据进行建模,比如从道路系统到设备网络、人口的病史或由关系定义的任何其他事物,将其涉及到的数据均以上述图数据的方式进行存储。例如:以“张三是李四的朋友”为例,其中,张三、李四为节点元素,朋友为这两个节点元素之间的关联关系。
本发明是基于上述图数据的结构方式来实现对各种应用场景中的数据进行存储,相对于传统数据库来说,更便于处理大量复杂、互链接、低结构化等的数据,这些数据变化速度快,需要频繁的查询等,这类数据若存储于传统的关系式数据库中,由于在数据频繁的查询中会涉及到大量的数据表的连接,进而导致性能急剧下降。
另外,本发明还利用了分布式的数据存储方式来实现对图数据进行数据存储管理,进一步提高了数据的存储、查询速度,可以大大方便数据的存储、提高数据的查询速度以及系统效率。
如图1所示,本发明提供了一优选实施例,一种分布式的图数据管理系统,包括客户端和数据节点模块。
其中,数据节点模块可以有一个或多个。一般来说,数据节点模块设于服务器上。理论上,一个服务器上可以设置多个数据节点模块。在实际应用中,为了保持系统性能,一般一个服务器上设置一个数据节点模块。
其中,客户端与数据节点模块连接,用于向数据节点模块发送写入请求或查询请求,进而实现数据写入或数据查询。另外,根据需求不同,本系统中的客户端可以有多个,每个客户端均可以与任一数据节点模块进行通讯,实现数据的存储以及查询等操作。
(一)数据写入
首先用户通过客户端向数据节点模块发送写入请求,然后客户端将该写入请求转发给数据节点模块进行解析,数据节点模块根据写入请求中需要写入的数据进行相应的写入操作。
其中,写入请求包括待写入的数据,该数据采用上述的图数据的结构。本实施例优选采用三元组数据来描述。三元组数据包括第一节点元素、第二节点元素和一个关系元素,并且关系元素代表第一节点元素和第二节点元素之间的关联关系。
具体地,本实施例中的三元组数据采用以下格式:<第一节点元素><关系元素><第二节点元素>。由于节点元素均表示一个实体,因此,为了区分第一节点元素与第二节点元素的不同,本实施例中的三元组格式还可以表示为:<主体><连接><客体>。其中,“主体”为第一节点元素、“客体”为第二节点元素,“连接”为关系元素。
例如:部门1包含员工1:
主体:部门1,
客体:员工1,
连接:包含。
再例如:部门2包含员工4:
主体:部门2,
客体:员工4,
连接:包含。
再例如:员工1喜欢书籍1:
主体:员工1,
客体:书籍1,
连接:喜欢。
在进行数据写入时,用户通过客户端输入的数据均为三元组数据。另外,对于三元组数据的格式并不仅仅限于本实施例所给出的格式,其也可以是其他的能够表现这种图数据的各种形式。在数据写入时,用户可通过客户端向系统中任意一个数据节点模块发送写入请求,不需要对三元组数据进行预先分类,可直接输入到任意一个数据节点模块就可以实现三元组数据的存储,大大方便了用户的使用,写入效率更高,有利于海量数据的存储。
数据节点模块,接收客户端发送的写入请求并对写入请求进行解析得出所有的三元组数据,然后对三元组数据进行分片处理和建立索引,最终存储于数据节点模块的数据存储引擎中。本发明支持用户的批量写入,也即是说用户通过客户端可一次性输入多个三元组数据,比如以特定格式形式的文本通过客户端输入待写入的数据,数据节点模块接收到写入请求后对文本进行解析得出文本中存储的所有的三元组数据。
其中,本发明规定一个数据节点模块用于存储同一种类型的数据分片,也即是存储同一个关系元素所对应的数据分片,可以有一个或多个,比如存储于关系元素为部门所对应的所有数据分片,由于企业的部门可能会包括一个或多个,因此,数据分片的类型相应会有一个或多个,数据分片的类型可根据第一节点元素进行区分,比如部门1对应的数据分片,部门2对应的数据分片。
也即是说,在对三元组数据进行分片处理时,通过对三元组数据中的关系元素进行提取,然后根据关系元素的不同将三元组数据进行分片处理,比如将同一个关系元素的三元组数据生成相应的一个或多个数据分片,然后存储于对应的数据节点模块中。在生成数据分片时,根据提取出的相同关系元素中的第一节点元素来区分生成对应数据分片。
例如,以上述三元组为例说明:连接为“包含”的数据分片会存放于数据节点模块1中,连接为“喜欢”的数据分片会存放于数据节点模块2中。其中,对于连接等于“包含”的数据分片又根据主体的不同分为数据分片1和数据分片2,其中,数据分片1用于存储部门1所包含的员工,数据分片2用于存储部门2所包含的员工。
针对本实施例提供的三元组数据的格式:<主体><连接><客体>:在解析得出所有的三元组数据后,可针对每个三元组数据提取出相应的“连接”,然后根据“连接”的不同,将相同“连接”的三元组根据主体的不同生成一个或多个数据分片,并存储于对应的数据节点模块中。
因此,当客户端向数据节点模块发送写入请求时,数据节点模块对待写入的所有的三元组数据进行解析并对应数据分片,并将数据分片存储于相应的数据节点模块中,进而实现数据的存储。
进一步地,本发明中的不同的数据节点模块之间还进行通讯。由于客户端向数据节点模块发送数据写入请求时,一次性会同步写入很多数据,并且一次性写入的三元组数据的连接未必完全相同;而客户端也未必知道哪些数据节点模块存储哪些连接。因此,为了方便用户数据写入操作,用户只需要向任意一个数据节点模块发送写入请求,然后通过数据节点模块向其他的数据节点模块发送转发写入请求即可实现数据的存储。
例如,首先用户通过客户端向系统中的一个数据节点模块发送写入请求;然后数据节点模块接收并解析写入请求得出所有的三元组数据,并对三元组数据进行提取得出对应关系元素。
数据节点模块再根据关系元素查找到对应数据分片所存储的数据节点模块,并将同一关系元素对应的三元组数据转发到对应数据节点模块进行相应的存储即可。
在进行存储时,每个数据节点模块首先根据三元组数据存储于数据分片中形成新的数据分片,然后保存到每个数据节点模块的数据存储引擎中。
另外,为了方便数据节点模块查询每个关系元素所在的数据节点模块,进一步地,本发明中的每个数据节点模块还定时与其他的数据节点模块通过rpc(Remote ProcedureCall,远程过程调用)请求的方式进行通讯。比如每个数据节点模块定时向其他的数据节点模块发送rpc请求,查询其他的数据节点模块所存储的数据分片的元信息,进而向其他的数据节点模块说明自身所存储的数据分片的元信息。这样,不同的数据节点模块可以定期同步自身的数据分片的元信息到其他的数据节点模块,使得每个数据节点模块均存储有其他数据节点模块的数据分片的元信息,也即是在整个系统集群中形成了数据分片元信息。其中,数据分片的元信息包括数据分片的大小、数据分片的关系元素、数据分片所在的数据节点模块等信息。
为了便于数据的快速查询,在将三元组数据存储于数据分片中时,还为数据分片建立相应的索引信息。当每次对数据分片进行更新后,对新形成的数据分片建立相应的索引信息。该索引信息记录数据在数据分片的位置信息,以加快数据的定位。
每个数据分片均为第一节点元素对应的第二节点元素的集合,以键值对的形式存储数据,键值对的形式表示为:<第一节点元素,关系元素>=[第二节点元素1,第二节点元素2,…]。
具体地,结合前述例子可知,本实施例的数据分片的键值对的形式还可表示为:<主体,连接>=[客体1,客体2,…]。以下事例均以该三元组格式进行描述,其中,这里的主体为第一节点元素,客体为第二节点元素,连接为关系元素。
例如:用户通过客户端输入的三元组数据分别为:<部门1><包含><员工1>、<部门1><包含><员工2>。数据节点模块1接收三元组数据后,首先对三元组数据进行提取并生成“包含”的数据分片,然后查找到该“包含”的数据分片存储于数据节点模块1上。由于数据节点模块1中“包含”的数据分片中并未有任何的数据,因此,根据上述三元组数据生成相应的数据分片,并以<部门1,包含>=[员工1,员工2]键值对的形式表示,同时为新形成的数据分片建立索引信息,然后将数据分片以及索引信息保存在数据节点模块1的数据存储引擎中。
再例如,用户通过客户端输入的三元组数据为:<部门1><包含><员工3>,则基于上述同样的原理,查询到“包含”的数据分片存储于数据节点模块1中,因此将该三元组数据存储于数据节点模块1中。具体为:将该三元组数据存储于前述的数据分片中,此时新形成的数据分片以键值对的形式表示为:<部门1,包含>=[员工1,员工2,员工3],同时建立索引信息,然后将数据分片以及对应索引信息保存在数据节点模块1的数据存储引擎中。
再例如,用户通过客户端输入的三元组数据为<部门2><包含><员工4>、<部门2><包含><员工5>。基于上述同样的原理,查询到“包含”的数据分片存储于数据节点模块1中,因此,将三元组数据存储于数据节点模块1中的数据分片中。由于此时三元组数据中的主体为:部门2,与前述的数据分片的主体不同,因此根据此时的三元组数据生成新的数据分片,具体以键值对的形式表示为:<部门2,包含>=[员工4,员工5],同时建立索引信息,然后将数据分片以及对应索引信息保存在数据节点模块1的数据存储引擎中。
此时,数据节点模块1中的数据分片包括两个,分别为:<部门1,包含>=[员工1,员工2,员工3]、<部门2,包含>=[员工4,员工5]。很明显,该数据节点模块1上存储了两个数据分片,并且这两个数据分片的关系元素均为:包含,前一个数据分片的主体为:部门1,后一个数据分片的主体为部门2。另外,为了保证数据批量写入的性能,当系统中存在多个数据节点模块时,客户端可同时向多个数据节点模块发送写入请求,进而使得多个数据节点模块同时根据写入请求执行相应的操作,可大幅度提升数据写入性能。具体为:将写入的所有三元组数据分成几个部分,同时通过客户端向不同的数据节点模块发送相应的写入请求,每个写入请求中包含了一部分待写入的三元组数据。比如:现需要写入100万条三元组数据,系统中存在5个数据节点模块。在写入数据时,可简单地将1-20万条三元组数据发送到数据节点模块1进行写入操作,将20-40万条三元组数据发送到数据节点模块2中进行写入操作,以此类推。
(二)数据查询
通过上述数据写入方式将数据存储于系统中,在数据查询时:同样地,用户通过客户端向数据节点模块发送查询请求。数据节点模块接收并解析客户端的查询请求中涉及到的相应的关系元素,然后根据关系元素查找到对应数据分片所存储的数据节点模块并将查询请求分别转发给对应的数据节点模块,使得数据节点模块根据查询请求进行查询,最终将所有的查询结果汇总返回给客户端。在查询时,由于查询请求中可能会涉及到多个不同的关系元素,而一个数据节点模块只是存储相同关系元素的数据分片,由于数据节点模块之间可以相互通讯,因此,用户可通过客户端向系统中的任意一个数据节点模块发送查询请求来实现数据查询功能。
也即是说,只要当系统中的一个数据节点模块在接收到客户端发送的查询请求时,该数据节点模块根据查询请求在自身的数据存储引擎中进行查询的同时,还会将查询请求发送到其他的数据节点模块进行相应查询,最终将查询结果汇总后返回给客户端。
由于数据节点模块之间定时进行相互通讯,会在系统集群中形成数据分片的元信息,数据分片的元信息包括数据分片的大小、数据分片的关系元素、数据分片所在的数据节点模块等信息。因此,当系统中的数据节点模块A接收到查询请求后,首先根据语法分析得出该查询请求中涉及到的所有关系元素,然后根据数据分片元信息查询得到每个关系元素所对应的数据节点模块,进而将查询请求转发到相应的数据节点模块,使得相应的数据节点模块根据查询请求在自身的数据存储引擎中进行查询。最终,数据节点模块A将所有的查询结果进行汇总后返回给客户端。
通过本发明提供的数据存储管理系统,能够实现对海量数据的存储、查询等,满足了大数据的海量数据的需求,同时还可以提高数据存储、查询的效率以及系统性能。
由于每个数据分片为同一主体所对应的客体的集合。比如对于一个员工较多的集团来说,随着一个部门的员工数量的增加时,相应将其存储于系统中时,在数据节点模式上存储的该部门所对应的数据分片中的员工数也会增加,也即是数据分片的大小也会整加,比如关于部门1的员工数量急剧整加,存储到数据节点模块上的相应的数据分片,以键值对的形式表示为:<部门1,包含>=[员工1,员工2,员工3,员工7,员工10、员工12,….]。从上可知,由于部门1的员工数量较多,则键值对“=”右边的数据,也即是员工数量也会增多,则在针对该数据分片进行查询遍历时由于数据量大,查询性能会下降,同时,也会造成系统的内存不足等问题。因此,本发明对数据节点模块的数据分片的大小进行限定,当数据分片的大小超过一定值,对数据分片中的键值对进行分割处理,方便数据查询、提高系统性能。
优选地,本实施例提供了一种分割规则,具体如下:
假设,某个数据节点模块上存储的某一个数据分片,以键值对的形式表示为:<部门1,包含>=[员工1,员工2,员工3,员工7,员工10、员工12]。
当数据分片的大小超过系统预设值时,查询需要遍历的数据过多,导致查询的效率下降。因此,对上述数据分片进行分割,也即是将数据分片中客体的部分进行分割,将该数据分片划分为多个新的数据分片。具体为:将员工1,员工2,员工3划分到一个数据分片中,将员工7,员工10、员工12划分到一个数据分片中。
也即是说,将上述数据分片分割为两个数据分片,分别以键值对的形式表示为:<部门1,包含>=[员工1,员工2,员工3]、<部门1,包含>=[员工7,员工10,员工12]。由于分割后的数据分片的大小满足系统要求,也即是其中所存储的客体数量相对较少,在查询时遍历的数据量较少,查询的效率更高、系统性能更好。
另外,在实际的应用过程中,数据节点模块设在服务器上,而每个服务器的存储空间有限。若当某个数据分片的大小足够大,相应的数据节点模块的存储空间不足以存储数据分片时,可能会造成数据的丢失。
因此,本系统还包括协调节点模块,协调节点模块与每个数据节点模块进行通讯,用于对每个数据节点模块中存储的数据分片进行周期性的移动,使得系统中的数据分片能够均匀分布在整个系统集群中。
如图2所示,协调节点模块,定期向各个数据节点模块发送控制请求,获取每个数据节点模块的数据分片的元信息,然后根据配置策略控制系统中的数据分片在各个数据节点模块上的分布。
其中,数据分片的元信息包括数据分片的大小、数据分片的关系元素、数据分片所在的数据节点模块等信息。
例如,配置策略采用空间均衡策略:协调节点模块会比较各个数据节点模块上数据分片所占空间的大小,进而控制一些数据分片从所在服务器空间较小的数据节点模块移动到所在服务器空间较大的数据节点模块中。也即是:当某个数据节点模块的服务器空间较小,而其所存储的连接的数据分片的大小足够大时,可将该连接的数据分片移动到服务器空间较大的数据节点模块中,便于存储足够大的数据分片。本发明通过协调节点模块可使得各个数据节点模块上的数据分片能够均匀分布到整个系统中,使得整个系统的资源能够得到合理利用。
另外,为了便于说明本发明提供的一种分布式的图数据管理系统的具体实现方案,以下举例说明:
假设现有三台机器,每台机器上设置有一数据节点模块,即:数据节点模块node1、数据节点模块node2、数据节点模块node3,要存储一份企业员工关系数据,比如部门包含员工、员工喜欢书籍,如表1和表2,对上述企业员工关系数据进行存储。在查询时:想要查询部门X中喜欢看书籍Y的员工。
主体 | 连接 | 客体 |
部门1 | 包含 | 员工1 |
部门1 | 包含 | 员工2 |
… | … | … |
表1
主体 | 连接 | 客体 |
员工1 | 喜欢 | 书籍1 |
员工2 | 喜欢 | 书籍1 |
… | … | … |
表2
针对现有的传统数据存储时建立各种数据表,比如员工表、部门表、书籍表,同时还需要建立各个表之间的关联关系,并将上述数据对应存储于数据库表中。
1、在查询时,根据查询条件需要针对多个数据表进行连接查询,导致其查询时间较长,给用户带来不好的体验。
2、另外,即使采用现有的基于分布式数据存储方式将数据表分散存储于系统的各个服务器上。但是,在查询时,一般根据查询条件将查询任务根据执行的先后顺序划分为多个子任务,然后依次调用每个子任务将其分配到系统集群中的每个服务器进行数据查询。例如,以广播的方式向系统中所有服务器发送第一次查询请求,查询得出部门X的员工,然后再以广播的方式向系统中所有的服务器发送第二次查询请求,查询得出喜欢看书籍Y的员工,最终根据两次的查询结果来得出部门X喜欢看书籍Y的员工。
对于每个子任务来说,由于系统集群中机器一般都会存在延迟性;并且,每次查询都要遍历所有的服务器,因此,当查询涉及到海量机器时,查询延迟就会大大增加。
如图3所示为查询的过程图,具体为:
步骤a、通过客户端分别对系统集群中的三台机器发出第一次广播查询,查询部门X的所有员工;
步骤b、根据第一次广播查询的查询结果得到部门X的员工集;
步骤c、根据部门X的员工集,通过客户端分别对系统集群中的三台机器再次发出第二次广播查询,查询部门X员工喜欢看的书籍;
步骤d、然后再根据“喜欢书籍Y的员工”这个条件过滤得出部门X中喜欢书籍Y的员工,并返回给客户端完成查询。
从上可知,往往需要对系统集群中所有的机器进行两次、三次甚至更多次遍历查询,并且每次查询都会将系统集群中所有的机器进行遍历,当查询涉及到海量机器时,延迟就会大大整加,超出用户所接受的范围,给用户带来了不好的体验。
采用本发明提供的分布式的图数据管理方法时:
首先本发明需要将上述表1和表2中的数据存储于对应的数据节点模块中。首先对不同的主体或客体均赋予全局唯一的uid,用于代表该节点元素。例如,部门1的id为deparment1_uid、员工1的id为employee1_uid,以此类推。
将“连接”(关系元素)相同的数据以数据分片的形式存放于同一个数据节点模块内。例如:假设“连接”=“包含”的数据分片会存放于数据节点模块node1、“连接”=“喜欢”的数据分片会存放于数据节点模块node2中。
比如以键值对形式将表1的数据存储于数据节点模块node1的数据分片中。
其中,键值对表示为:
<deparment1_uid,包含>=[employee1_uid,employee2_uid,…]。
同理,以键值对形式将表2的数据存储于数据节点模块node2的数据分片中。其中,键值对表示为:
<employee1_uid,喜欢>=[书籍1]、<employee2_uid,喜欢>=[书籍1]。
同时,系统分别为每个数据分片建立对应的索引信息,并将其存储于对应的数据节点模块的数据存储引擎中。
在查询时,如图4所示,查询部门X中喜欢看书籍Y的员工时,客户端只需向系统集群中任一台机器(假设为数据节点模块node1)发出查询请求。
此时,数据节点模块node1对查询请求解析得出涉及到的连接:“包含”、“喜欢”,然后该数据节点模块node1根据系统集群中的数据分片元信息查询得到“包含”的数据分片存储于数据节点模块node1中、“喜欢”的数据分片存储于数据节点模块node2中,因此:
步骤A:数据节点模块node1根据查询请求进行第一次查询,也即是在数据节点模块node1的数据存储引擎中查找出:部门X的所有员工。
步骤B、同时,数据节点模块node1将查询请求转发给另一台机器,对数据节点模块node2发出第二次查询,在数据节点模块node2的数据存储引擎中查找出:喜欢书籍Y的员工。
另外,数据节点模块node1在将查询请求转发给数据节点模块node2时,还可将自身根据查询请求查询得出的结果转发给数据节点模块node2,这样在查询喜欢书籍Y的员工时,可快速定位为部门X的员工。
步骤C、数据节点模块node1收集自身的查询结果以及数据节点模块node2的查询结果并进行汇总后返回给客户端,实现“部门X中喜欢看书籍Y的员工”的查询。
很明显,本发明提供的分布式的图数据管理系统,在数据查询时,由于每次查询时只是涉及到对应的机器,而不像现有技术中一样,每次查询时都会遍历所有的机器导致查询效率低下。本发明在数据存储、查询时其效率更高,基本上不存在延迟,查询更为高效。
实施例二
基于实施例一,本发明还提供了一种分布式的图数据管理方法,应用于实施例一的分布式的图数据管理系统,管理方法包括:
步骤S1、数据写入步骤,用于接收客户端发送的写入请求并解析得出所有的三元组数据,并根据每个三元组数据的关系元素查找对应的数据分片所存储的数据节点模块,然后根据关系元素将三元组数据发送给对应的数据节点模块使得每个数据节点模块根据三元组数据生成数据分片,并为数据分片建立索引信息,最后将数据分片和对应索引信息保存在数据节点模块的数据存储引擎中。
每个三元组数据均包括第一节点元素、第二节点元素和一个关系元素,第一节点元素与第二节点元素之间根据关系元素进行关联。每个数据节点模块上存储了同一关系元素对应的所有数据分片,数据分片根据第一节点元素的不同进行区分。
例如客户端输入的三元组数据包括:部门1包含员工1、部门1包含员工2、部门1包含员工3,此时,由于上述三个三元组数据的关系元素均为包含,并且该三个三元组数据的第一节点元素相同。因此,根据上述关系元素生成一个数据分片,该数据分片则表明:部门1包含员工1、员工2以及员工3。
再例如,客户端输入的三元组数据为:部门2包含员工3,此时,由于其关系元素也为包含,但是其第一节点元素与之前的不同。因此,根据该三元组数据生成新的数据分片,该数据分片表明:部门2包含员工3。
如图5所示,数据写入步骤包括:
步骤S11:获取并解析客户端发送的写入请求得出所有的三元组数据。本实施例中的三元组数据采用三元组的形式,具体表示为:<主体><连接><客体>,主体为第一节点元素,客体为第二节点元素,连接为关系元素,主体与客体之间具有连接的关联关系。
步骤S12:提取每个三元组数据的关系元素,并根据关系元素查找得出每个关系元素对应的数据分片所在的数据节点模块。
步骤S13:将相同关系元素的三元组数据转发给对应的数据节点模块,使得每个数据节点模块根据三元组数据生成对应数据分片,并为每个数据分片建立索引信息,以及将每个数据分片和对应索引信息保存在对应数据节点模块的数据存储引擎中。
进一步地,管理方法包括步骤S2、数据查询步骤,用于接收客户端发送的查询请求并根据查询请求中的每个关系元素查询得到每个关系元素对应的数据分片所存储的数据节点模块,然后将查询请求发送给对应的数据节点模块进行查询,最终将所有的查询结果进行汇总返回给客户端。
如图6所示,步骤S2具体包括:
步骤S21:获取并解析客户端发送的查询请求,得出查询请求所涉及的每个关系元素。比如查询部门X中喜欢书籍Y的员工,其涉及到的关系元素,即“连接”,为“包含”、“喜欢”。
步骤S22:根据查询请求所涉及的每个关系元素查找出关系元素对应的数据分片所存储的数据节点模块,并将查询请求转发给对应的数据节点模块进行查询。由于每个数据节点模块中所存储的数据分片不同,因此,根据查询请求中涉及到的关系元素,查找到每个关系元素所对应的数据分片所在的数据节点模块。每个数据节点模块接收到查询请求时,都在自身的数据存储引擎的索引信息中查找到相应的数据。在查询时,由于每个数据节点模块上存储有多个数据分片,可针对多个数据分片的索引信息进行遍历查询。
另外,在接收查询请求时,是系统中任意一个数据节点模块接收的,因此转发查询请求是在数据节点模块之间进行转发。每个数据节点模块在将查询请求转发给其他的数据节点模块时,还可以将自身的查询结果转发给其他的数据节点模块。
步骤S23:将每个数据节点模块的查询结果进行汇总后返回给客户端。
进一步地,管理方法还包括:步骤S3:定时获取每个数据分片的大小,并且当数据分片的大小超过预设值时,根据系统预设分割规则对数据分片进行分割处理。通过对数据分片进行分割,可大大提高系统处理性能以及查询效率。例如,在分割时按照预设规定对数据分片中存储的第二节点元素进行分割,使得原有的数据分片分成为满足系统要求的数据分片。
进一步地,管理方法包括:步骤S4:定时获取每个数据节点模块的数据分片的元信息,然后根据配置策略将每个数据分片移动到其他的数据节点模块中。比如,通过周期性地将每个数据分片移动到其他的数据节点模块中,使得数据节点模块的存储空间得到合理运用。
实施例三
一种分布式的图数据管理装置,包括存储器和处理器,所述存储器上存储有可在处理器上运行的图数据管理程序,所述图数据管理程序为计算机程序,所述处理器执行所述图数据管理程序时实现如实施例二提供的一种分布式的图数据管理方法的步骤。
实施例四
一种存储介质,所述存储介质为计算机可读存储介质,其上存储有图数据管理程序,所述图数据管理程序为计算机程序,其特征在于:所述图数据管理程序被处理器执行时实现如实施例二提供的分布式的图数据管理方法的步骤。
上述实施方式仅为本发明的优选实施方式,不能以此来限定本发明保护的范围,本领域的技术人员在本发明的基础上所做的任何非实质性的变化及替换均属于本发明所要求保护的范围。
Claims (10)
1.一种分布式的图数据管理系统,其特征在于,所述图数据管理系统包括客户端、和一个或多个数据节点模块;客户端与任意一个数据节点模块进行通讯;
数据节点模块,用于接收客户端发送的写入请求并解析得出所有的三元组数据,然后对每个三元组数据进行提取并得出每个三元组数据的关系元素,再查询出每个关系元素对应的数据分片所在的数据节点模块并将相同关系元素的待写入数据转发给对应的数据节点模块,使得对应的数据节点模块将待写入数据存储于数据分片中,并为数据分片建立索引信息以及将数据分片和对应索引信息保存在对应数据节点模块的数据存储引擎中;
数据节点模块,用于接收客户端发送的查询请求,并将查询请求转发给其他的数据节点模块进行查询,最终将所有的数据节点模块得出的查询结果进行汇总后返回给客户端;其中,每个三元组数据均包括第一节点元素、第二节点元素和一个关系元素;数据分片中存储了第一节点元素所对应的第二节点元素的集合,并且第一节点元素和第二节点元素之间具有关系元素的关联关系。
2.根据权利要求1所述的一种分布式的图数据管理系统,其特征在于,每个数据节点模块与其他的数据节点模块定时通过rpc请求的方式进行通讯;数据节点模块定时向其他的数据节点模块发送rpc请求,进而向其他的数据节点模块通知自身所存储的数据分片的元信息,进而使得每个数据节点模块中均存储有所有数据分片的元信息;其中,数据分片的元信息包括数据分片的大小、数据分片的关系元素、数据分片所在的数据节点模块。
3.根据权利要求1所述的一种分布式的图数据管理系统,其特征在于,所述图数据管理系统包括协调节点模块,协调节点模块与每个数据节点模块进行通讯,定时从每个数据节点模块获取数据分片的元信息,并根据配置策略调整每个数据节点模块上的数据分片的分布。
4.一种分布式的图数据管理方法,应用于一种分布式的图数据管理系统,其特征在于,所述图数据管理方法包括:数据写入步骤和数据查询步骤;
其中,数据写入步骤,用于接收客户端发送的写入请求并解析得出所有的三元组数据,并根据每个三元组数据的关系元素查找对应的数据分片所在的数据节点模块,然后根据关系元素将三元组数据发送给对应的数据节点模块,使得每个数据节点模块根据三元组数据生成数据分片,并为数据分片建立索引信息,最后将数据分片和对应索引信息保存在对应数据节点模块的数据存储引擎中;
数据查询步骤,用于接收客户端发送的查询请求并根据查询请求中的每个关系元素查询得到每个关系元素对应的数据分片所在的数据节点模块,然后将查询请求发送给对应的数据节点模块进行查询,最终将所有的查询结果进行汇总后返回给客户端;其中,每个三元组数据均包括第一节点元素、第二节点元素和一个关系元素;每个数据节点模块的数据存储引擎中存储相同关系元素的一个或多个数据分片,每个数据分片存储第一节点元素所对应的第二节点元素的集合。
5.根据权利要求4所述的一种分布式的图数据管理方法,其特征在于,所述数据写入步骤包括:
获取步骤:获取并解析客户端发送的写入请求得出所有的三元组数据;
查找步骤:提取每个三元组数据的关系元素,并根据关系元素查找得出每个关系元素对应的数据分片所在的数据节点模块;
存储步骤:将相同关系元素的三元组数据转发给对应的数据节点模块,使得每个数据节点模块根据三元组数据生成对应数据分片,并为每个数据分片建立索引信息,以及将每个数据分片和对应索引信息保存在对应数据节点模块的数据存储引擎中;
所述数据查询步骤包括:
获取步骤:获取并解析客户端发送的查询请求得出查询请求所涉及的每个关系元素;
查找步骤:根据查询请求所涉及的每个关系元素查找出关系元素对应的数据分片所存储的数据节点模块,并将查询请求转发给对应的数据节点模块进行查询;
结果返回步骤:将每个数据节点模块的查询结果进行汇总后返回给客户端。
6.根据权利要求4所述的分布式的图数据管理方法,其特征在于,所述图数据管理方法包括:分割步骤:定时获取每个数据分片的大小,并且当数据分片的大小超过预设值时,根据系统预设分割规则对数据分片进行分割处理。
7.根据权利要求4所述的一种分布式的图数据管理方法,其特征在于,所述图数据管理方法包括:协调步骤:定时获取每个数据节点模块的数据分片的元信息,然后根据配置策略控制每个数据节点模块中数据分片的分布;所述数据分片的元信息包括数据分片的大小、数据分片对应的关系元素、数据分片所在的数据节点模块。
8.根据权利要求4所述的一种分布式的图数据管理方法,其特征在于,所述三元组数据的格式为:<第一节点元素><关系元素><第二节点元素>。
9.根据权利要求8所述的一种分布式的图数据管理方法,其特征在于,所述数据分片以键值对的形式存储于对应数据节点模块的数据存储引擎中,其中,键值对的形式为:<第一节点元素,关系元素>=[第二节点元素1,第二节点元素2,第二节点元素3,…]。
10.一种存储介质,所述存储介质为计算机可读存储介质,其上存储有图数据管理程序,所述图数据管理程序为计算机程序,其特征在于:所述图数据管理程序被处理器执行时实现如权利要求4-9中任一项所述的一种分布式的图数据管理方法的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201911022943.3A CN111026747A (zh) | 2019-10-25 | 2019-10-25 | 一种分布式的图数据管理系统、方法及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201911022943.3A CN111026747A (zh) | 2019-10-25 | 2019-10-25 | 一种分布式的图数据管理系统、方法及存储介质 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN111026747A true CN111026747A (zh) | 2020-04-17 |
Family
ID=70200593
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201911022943.3A Pending CN111026747A (zh) | 2019-10-25 | 2019-10-25 | 一种分布式的图数据管理系统、方法及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111026747A (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112015820A (zh) * | 2020-09-01 | 2020-12-01 | 杭州欧若数网科技有限公司 | 分布式图数据库实现的方法、系统、电子装置和存储介质 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105608228A (zh) * | 2016-01-29 | 2016-05-25 | 中国科学院计算机网络信息中心 | 一种高效的分布式的rdf数据存储方法 |
CN106709006A (zh) * | 2016-12-23 | 2017-05-24 | 武汉科技大学 | 一种对查询友好的关联数据压缩方法 |
CN107038234A (zh) * | 2017-04-17 | 2017-08-11 | 天津大学 | 一种基于rdf图数据和关系数据的路径查询框架 |
CN107291807A (zh) * | 2017-05-16 | 2017-10-24 | 中国科学院计算机网络信息中心 | 一种基于图遍历的sparql查询优化方法 |
CN108027818A (zh) * | 2015-09-18 | 2018-05-11 | 微软技术许可有限责任公司 | 基于图的查询 |
-
2019
- 2019-10-25 CN CN201911022943.3A patent/CN111026747A/zh active Pending
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108027818A (zh) * | 2015-09-18 | 2018-05-11 | 微软技术许可有限责任公司 | 基于图的查询 |
CN105608228A (zh) * | 2016-01-29 | 2016-05-25 | 中国科学院计算机网络信息中心 | 一种高效的分布式的rdf数据存储方法 |
CN106709006A (zh) * | 2016-12-23 | 2017-05-24 | 武汉科技大学 | 一种对查询友好的关联数据压缩方法 |
CN107038234A (zh) * | 2017-04-17 | 2017-08-11 | 天津大学 | 一种基于rdf图数据和关系数据的路径查询框架 |
CN107291807A (zh) * | 2017-05-16 | 2017-10-24 | 中国科学院计算机网络信息中心 | 一种基于图遍历的sparql查询优化方法 |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112015820A (zh) * | 2020-09-01 | 2020-12-01 | 杭州欧若数网科技有限公司 | 分布式图数据库实现的方法、系统、电子装置和存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11816126B2 (en) | Large scale unstructured database systems | |
CN106528717B (zh) | 数据处理方法和系统 | |
CN101727465B (zh) | 分布式列存储数据库索引建立、查询方法及装置与系统 | |
CN103020204B (zh) | 一种对分布式顺序表进行多维区间查询的方法及其系统 | |
CN102667761B (zh) | 可扩展的集群数据库 | |
US8676951B2 (en) | Traffic reduction method for distributed key-value store | |
US7174345B2 (en) | Methods and systems for auto-partitioning of schema objects | |
US8965941B2 (en) | File list generation method, system, and program, and file list generation device | |
CN107451208B (zh) | 一种数据搜索方法与装置 | |
US9600501B1 (en) | Transmitting and receiving data between databases with different database processing capabilities | |
US20220083618A1 (en) | Method And System For Scalable Search Using MicroService And Cloud Based Search With Records Indexes | |
CN108509437A (zh) | 一种ElasticSearch查询加速方法 | |
US9430525B2 (en) | Access plan for a database query | |
US11803572B2 (en) | Schema-based spatial partitioning in a time-series database | |
CN107665246B (zh) | 基于图数据库的动态数据迁移方法及图数据库集群 | |
CN105224636A (zh) | 一种数据访问方法和装置 | |
CN111258978A (zh) | 一种数据存储的方法 | |
US11151081B1 (en) | Data tiering service with cold tier indexing | |
CN105893542A (zh) | 一种云存储系统中的冷数据文件重分布方法及系统 | |
CN111026709B (zh) | 基于集群访问的数据处理方法及装置 | |
US20140019454A1 (en) | Systems and Methods for Caching Data Object Identifiers | |
CN111723161A (zh) | 一种数据处理方法、装置及设备 | |
CN103365987A (zh) | 一种基于共享磁盘架构的集群数据库系统及数据处理方法 | |
CN111026747A (zh) | 一种分布式的图数据管理系统、方法及存储介质 | |
CN108319604A (zh) | 一种hive中大小表关联的优化方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20200417 |
|
RJ01 | Rejection of invention patent application after publication |