CN110019310A - 数据处理方法及***、计算机***、计算机可读存储介质 - Google Patents

数据处理方法及***、计算机***、计算机可读存储介质 Download PDF

Info

Publication number
CN110019310A
CN110019310A CN201711477730.0A CN201711477730A CN110019310A CN 110019310 A CN110019310 A CN 110019310A CN 201711477730 A CN201711477730 A CN 201711477730A CN 110019310 A CN110019310 A CN 110019310A
Authority
CN
China
Prior art keywords
database
data
change data
stored
state
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
Application number
CN201711477730.0A
Other languages
English (en)
Inventor
马文军
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Jingdong Century Trading Co Ltd
Beijing Jingdong Shangke Information Technology Co Ltd
Original Assignee
Beijing Jingdong Century Trading Co Ltd
Beijing Jingdong Shangke Information Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Beijing Jingdong Century Trading Co Ltd, Beijing Jingdong Shangke Information Technology Co Ltd filed Critical Beijing Jingdong Century Trading Co Ltd
Priority to CN201711477730.0A priority Critical patent/CN110019310A/zh
Publication of CN110019310A publication Critical patent/CN110019310A/zh
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/242Query formulation
    • G06F16/2433Query languages
    • G06F16/244Grouping and aggregation

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Mathematical Physics (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本公开提供了一种数据处理方法,该方法包括:获取数据操作产生的变更数据;将变更数据存入第一数据库中,其中,第一数据库支持数据聚合查询;以及将变更数据存入第二数据库中,其中,第二数据库也支持数据聚合查询,用于作为第一数据库的备用数据库。本公开还提供了一种数据处理***、一种计算机***和一种计算机可读存储介质。

Description

数据处理方法及***、计算机***、计算机可读存储介质
技术领域
本公开涉及数据处理领域,更具体地,涉及一种数据处理方法及***、计算机***、计算机可读存储介质。
背景技术
互联网发展迅猛的今天,数据的增长量超乎想像,已经在几何性的飞速扩张,而无论什么***,随着时间和业务的发展,***所涉及的数据也在逐渐的增加。以往的Oracle或者Sqlserver等付费数据库,随着数据库存储数据的增加,资源成本也相应增加着。并且每台机器的CPU、磁盘、内存都是有限的,数据量非常大时,数据库性能会非常差。因此越来越多的企业都采用了分库分表的分布式存储方式。
由于数据通过分库分表的分布式存储形式,打散地存储在多个数据库机器上,因此无法满足一些多维度查询的需求,但是往往有某些大数据需要对外提供查询,且查询的维度也需要多元化,甚至包括分页需求。
目前,数据分库分表存储后,现有技术提供的聚合查询一般有两种:一、通过定时调度的方式,根据一定时间范围内将分库分表中的数据存储至单表中,如每月一张表,用户查询时通过筛选月份来进行单表的聚合查询;二、通过定时调度的方式,将一定时间范围内的数据存储至一数据库中,用于聚合查询。
然而,在实现本公开构思的过程中,发明人发现相关技术中至少存在如下问题:查询服务存在无法支持的风险。
发明内容
有鉴于此,本公开提供了一种能够降低聚合查询服务存在无法支持的风险的数据处理方法和数据处理***。
本公开的一个方面提供了一种数据处理方法,包括:获取数据操作产生的变更数据;将上述变更数据存入第一数据库中,其中,上述第一数据库支持数据聚合查询;以及将上述变更数据存入第二数据库中,其中,上述第二数据库也支持数据聚合查询,用于作为上述第一数据库的备用数据库。
根据本公开的实施例,上述方法还包括:通过第一线程将上述变更数据存入上述第一数据库中;以及通过不同于上述第一线程且与上述第一线程同步的第二线程将上述变更数据存入上述第二数据库中。
根据本公开的实施例,上述方法还包括:通过Kafka消息将上述变更数据发送给上述第一数据库的第一接收服务器,以使上述第一接收服务器将上述Kafka消息发送的数据存入上述第一数据库中;以及通过上述Kafka消息同时将上述变更数据发送给上述第二数据库的第二接收服务器,以使上述第二接收服务器将上述Kafka消息发送的数据存入上述第二数据库中。
根据本公开的实施例,上述方法还包括:在获取上述变更数据后,将上述变更数据作为一条任务记录写入任务表中;在存储上述变更数据的过程中,查看上述第一数据库和上述第二数据库的状态值是否都是已完成状态;以及在上述第一数据库和/或上述第二数据库的状态值不是已完成状态的情况下,通过上述Kafka消息将写入上述任务表中的上述任务记录中的上述变更数据发送给上述第一数据库的上述第一接收服务器和/或上述第二数据库的上述第二接收服务器,以保证状态值不是已完成状态的数据库能够成功存入上述变更数据。
根据本公开的实施例,上述方法还包括:将上述第一数据库中早于预设时间存入的历史数据删除。
根据本公开的实施例,上述方法还包括:在获取上述变更数据后,将上述变更数据分库分表存入一分布式数据库集群中。
本公开的另一个方面提供了一种数据处理***,包括:获取模块,用于获取数据操作产生的变更数据;第一存储模块,用于将上述变更数据存入第一数据库中,其中,上述第一数据库支持数据聚合查询;以及第二存储模块,用于将上述变更数据存入第二数据库中,其中,上述第二数据库也支持数据聚合查询,用于作为上述第一数据库的备用数据库。
根据本公开的实施例,上述第一存储模块,还用于通过第一线程将上述变更数据存入上述第一数据库中;以及上述第二存储模块,还用于通过不同于上述第一线程且与上述第一线程同步的第二线程将上述变更数据存入上述第二数据库中。
根据本公开的实施例,上述第一存储模块,还用于通过Kafka消息将上述变更数据发送给上述第一数据库的第一接收服务器,以使上述第一接收服务器将上述Kafka消息发送的数据存入上述第一数据库中;以及上述第二存储模块,还用于通过上述Kafka消息同时将上述变更数据发送给上述第二数据库的第二接收服务器,以使上述第二接收服务器将上述Kafka消息发送的数据存入上述第二数据库中。
根据本公开的实施例,上述***还包括:第三存储模块,用于在获取上述变更数据后,将上述变更数据作为一条任务记录写入任务表中;查询模块,用于在存储上述变更数据的过程中,查看上述第一数据库和上述第二数据库的状态值是否都是已完成状态;上述第一存储模块,还用于在上述第一数据库和上述第二数据库的状态值不是已完成状态或者上述第一数据库的状态值不是已完成状态的情况下,通过上述Kafka消息将写入上述任务表中的上述任务记录中的上述变更数据发送给上述第一数据库的上述第一接收服务器,以保证状态值不是已完成状态的上述第一数据库能够成功存入上述变更数据;以及上述第二存储模块,还用于在上述第一数据库和上述第二数据库的状态值不是已完成状态或者上述第二数据库的状态值不是已完成状态的情况下,通过上述Kafka消息将写入上述任务表中的上述任务记录中的上述变更数据发送给上述第二数据库的上述第二接收服务器,以保证状态值不是已完成状态的上述第二数据库能够成功存入上述变更数据。
根据本公开的实施例,上述***还包括:删除模块,用于将上述第一数据库中早于预设时间存入的历史数据删除。
根据本公开的实施例,上述***还包括:第四存储模块,用于在获取上述变更数据后,将上述变更数据分库分表存入一分布式数据库集群中。
本公开的另一方面提供了一种计算机***,包括:一个或多个处理器;存储器,用于存储一个或多个程序,其中,当上述一个或多个程序被上述一个或多个处理器执行时,使得上述一个或多个处理器实现上述任一项所述的数据处理方法。
本公开的另一方面提供了一种计算机可读存储介质,其上存储有可执行指令,该指令被处理器执行时使处理器实现上述任一项所述的数据处理方法。
通过本公开实施例,因为采用了两个互为备用的且都支持数据聚合查询服务的数据库(如第一数据库和第二数据库)来存储变更数据的技术手段,所以至少部分地克服了查询服务不稳地,存在不可用的风险的技术问题,进而达到了提高查询服务的可用性的技术效果。例如,第一数据库为Elasticsearch数据库,用于保存热点数据,第一数据库为MongoDB数据库,用于保存全量数据,这样可以保证在任一数据库出现宕机情况时,仍然可以提供聚合查询服务,因而通过Elasticsearch数据库和MongoDB数据库互备,能够提高聚合查询服务的可用性。
附图说明
通过以下参照附图对本公开实施例的描述,本公开的上述以及其他目的、特征和优点将更为清楚,在附图中:
图1示意性示出了可以应用本公开的数据处理方法和***的示例性***架构;
图2示意性示出了根据本公开实施例的数据处理方法和***的应用场景;
图3示意性示出了根据本公开实施例的数据处理方法的流程图;
图4A示意性示出了根据本公开另一实施例的数据处理方法的示意图;
图4B示意性示出了根据本公开另一实施例的数据处理方法的示意图;
图4C示意性示出了根据本公开另一实施例的数据处理方法的示意图;
图4D示意性示出了根据本公开另一实施例的数据处理方法的流程图;
图4E示意性示出了根据本公开另一实施例的数据处理方法的流程图;
图4F示意性示出了根据本公开另一实施例的数据处理方法的示意图;
图5示意性示出了根据本公开实施例的数据处理***的框图;
图6A示意性示出了根据本公开实施例的数据处理***的框图;
图6B示意性示出了根据本公开实施例的数据处理***的框图;以及
图7示意性示出了根据本公开实施例的适于实现数据处理方法和***的计算机***的框图。
具体实施方式
以下,将参照附图来描述本公开的实施例。但是应该理解,这些描述只是示例性的,而并非要限制本公开的范围。此外,在以下说明中,省略了对公知结构和技术的描述,以避免不必要地混淆本公开的概念。
在此使用的术语仅仅是为了描述具体实施例,而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在,但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。
在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义,除非另外定义。应注意,这里使用的术语应解释为具有与本说明书的上下文相一致的含义,而不应以理想化或过于刻板的方式来解释。
在使用类似于“A、B和C等中至少一个”这样的表述的情况下,一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如,“具有A、B和C中至少一个的***”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的***等)。在使用类似于“A、B或C等中至少一个”这样的表述的情况下,一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如,“具有A、B或C中至少一个的***”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的***等)。本领域技术人员还应理解,实质上任意表示两个或更多可选项目的转折连词和/或短语,无论是在说明书、权利要求书还是附图中,都应被理解为给出了包括这些项目之一、这些项目任一方、或两个项目的可能性。例如,短语“A或B”应当被理解为包括“A”或“B”、或“A和B”的可能性。
本公开的实施例提供了一种能够降低聚合查询服务存在无法支持的风险数据处理方法以及能够应用该方法的数据处理***。该方法包括获取数据操作产生的变更数据;将上述变更数据存入第一数据库中,其中,上述第一数据库支持数据聚合查询;以及将上述变更数据存入第二数据库中,其中,上述第二数据库也支持数据聚合查询,用于作为上述第一数据库的备用数据库。
图1示意性示出了可以应用本公开的数据处理方法和***的示例性***架构。
如图1所示,根据该实施例的***架构100可以包括终端设备101、102、103,网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型,例如有线和/或无线通信链路等等。
用户可以使用终端设备101、102、103通过网络104与服务器105交互,以接收或发送消息等。终端设备101、102、103上可以安装有各种通讯客户端应用,例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端和/或社交平台软件等(仅为示例)。
终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种电子设备,包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。
服务器105可以是提供各种服务的服务器,例如对用户利用终端设备101、102、103所浏览的网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的用户请求等数据进行分析等处理,并将处理结果(例如根据用户请求获取或生成的网页、信息、或数据等)反馈给终端设备。
需要说明的是,本公开实施例所提供的数据处理方法一般可以由服务器105执行。相应地,本公开实施例所提供的数据处理***一般可以设置于服务器105中。本公开实施例所提供的数据处理方法也可以由不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群执行。相应地,本公开实施例所提供的数据处理***也可以设置于不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群中。
应该理解,图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要,可以具有任意数目的终端设备、网络和服务器。
互联网发展迅猛的今天,数据的增长量超乎想像,已经在几何性的飞速扩张,而无论什么***,随着时间和业务的发展,***所涉及的数据也在逐渐的增加。以往的Oracle或者Sqlserver等付费数据库,随着数据库存储数据的增加,资源成本也相应增加着。并且每台机器的CPU、磁盘、内存都是有限的,数据量非常大时,数据库性能会非常差。因此越来越多的企业都采用了分库分表的分布式存储方式,如图2所示,将数据源204产生的数据存储在多个不同的Mysql数据库201中。
由于数据通过分库分表的分布式存储形式,打散地存储在多个数据库机器上,因此无法满足一些多维度查询的需求,但是往往有某些大数据需要对外提供查询,且查询的维度也需要多元化,甚至包括分页需求。
目前,数据分库分表存储后,现有技术提供的聚合查询一般有两种:一、通过定时调度的方式,根据一定时间范围内将分库分表中的数据存储至单表中,如每月一张表,用户查询时通过筛选月份来进行单表的聚合查询;二、通过定时调度的方式,将一定时间范围内的数据存储至一数据库中,用于聚合查询。
然而,在实现本公开构思的过程中,发明人发现相关技术中至少存在如下问题:查询服务存在无法支持的风险,基于此,如图2所示,在将数据源204产生的数据存储在多个不同的Mysql数据库201中的同时,还可以将其分别存储在一个热点数据库202和一个全量数据库203中。其中,该热点数据库202和该全量数据库203都支持数据聚合查询,且在数据查询时优先使用热点数据库202,在热点数据库202不可用时,可以使用全量数据库203代替热点数据库202提供数据聚合查询服务。这样,可以尽量避免热点数据库202不可用而导致的查询服务得不到支持的风险。
需要说明的是,Mysql是一个关系型数据库管理***。关系型数据库将数据保存在不同的数据表中,而不是将所有数据放在一个大仓库内,这样就提高了数据查询速度并提高了数据查询的灵活性。
图3示意性示出了根据本公开实施例的数据处理方法的流程图。
如图3所示,该***包括操作S301~S303,其中:
在操作S301,获取数据操作产生的变更数据;
在操作S302,将变更数据存入第一数据库中,其中,第一数据库支持数据聚合查询;以及
在操作S303,将变更数据存入第二数据库中,其中,第二数据库也支持数据聚合查询,用于作为第一数据库的备用数据库。
在本公开实施例中,对数据操作不做限定,它可以包括但不限于数据新增、修改、删除等操作。此外,虽然第一数据库和第二数据库都能够提供数据聚合查询服务,但是优选的,可以将第一数据库设置为主用数据库,将第而数据库设置为备用数据库,正常情况下由第一数据库提供数据聚合查询服务,在第一数据库由于异常或者宕机而导致不可用时,由第二数据库提供数据聚合查询服务。基于此,一般希望第一数据库具有更高的查询速度,且支持多维度查询和分页查询,因此,第一数据库可以是ElasticSearch数据库,第二数据库可以是MongoDB数据库。
ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎,基于RESTful web接口。Elasticsearch是用Java开发的,并作为Apache许可条款下的开放源码发布,是当前流行的企业级搜索引擎。设计用于云计算中,能够达到实时搜索,具有稳定,可靠,快速,安装、使用方便等特点。
MongoDB是一个基于分布式文件存储的数据库。由C++语言编写。旨在为WEB应用提供可扩展的高性能数据存储解决方案。
在本开实施例中,当数据源有数据产生时,可以将其存储在一个分布式的数据库集群中,以实现数据的分库分表存储,同时,为了实现多维度甚至分页数据聚合查询,还可以将这些数据分别存储在两个互为备用的数据库中,即第一数据库和第二数据库。这样,当一个数据库如第一数据库不可用时,可以启用另一个数据库如第二数据库来提供数据聚合查询服务。
而在相关技术中,对于分库分表存储的数据,在实现数据聚合查询时,一种方式是按时间再次分表,通过定时调度的方式,根据一定时间范围内将分库分表中的数据存储至单表中,如每月一张表,用户查询时通过筛选月份来进行单表的聚合查询。对于这种方式,由于跨时间度的查询操作繁琐,并且当数据量很大的情况下,单表依然会存在查询性能问题,因此用户体验不好。另一种方式是通过Elasticsearch数据库提供数据聚合查询服务。虽然Elasticsearch数据库能提供更好的查询性能,但是无法保证很好的高可用性,一旦搜索服务宕机,对外查询服务就不可用,并且这种方式占用资源很多,无法存储大量数据,此外Elasticsearch数据库本身存在数据丢失的情况,等等。
基于此,上述两种现有的解决方案都存在如下问题:由于定时调度的方式,数据信息实时性较低,无法满足对实时性有要求的需求;单一的存储空间无法满足大数据的存储需求;查询服务不稳地,存在不可用的风险。
而通过本公开实施例,因为采用了两个互为备用的且都支持数据聚合查询服务的数据库(如第一数据库和第二数据库)来存储变更数据的技术手段,所以至少部分地克服了查询服务不稳地,存在不可用的风险的技术问题,进而达到了提高查询服务的可用性的技术效果。例如,第一数据库为Elasticsearch数据库,用于保存热点数据,第一数据库为MongoDB数据库,用于保存全量数据,这样可以保证在任一数据库出现宕机情况时,仍然可以提供聚合查询服务,因而通过Elasticsearch数据库和MongoDB数据库互备,能够提高聚合查询服务的可用性。
下面参考图4A~图4F,结合具体实施例对图3所示的***做进一步说明。
作为一种可选的实施例,上述方法还包括:通过第一线程将变更数据存入第一数据库中;以及通过不同于第一线程且与第一线程同步的第二线程将变更数据存入第二数据库中。
如图4A所示,将需要存储的数据401分别通过第一线程存入第一数据库402中,通过第二线程存入第二数据库403中。
由于第一线程和第二线程是不同的线程且互相同步,因此使用多线程可以提高存储数据的速度,从而可以满足数据查询时对时效性的需求,而多线程同步则可以保证第一数据库402和第二数据库403能够存储同样的数据,使得无论使用第一数据库402还是第二数据库403进行数据查询时都能获得一致的准确的查询结果。
需要说明的是,多线程是指从软件或者硬件上实现多个线程并发执行的技术。
通过本公开实施例,通过多线程将数据保存至多维度数据库中,可以提高数据存储的时效性,从而能够提供一种实时性准确性较高的聚合查询服务。
作为一种可选的实施例,上述方法还包括:通过Kafka消息将变更数据发送给第一数据库的第一接收服务器,以使第一接收服务器将Kafka消息发送的数据存入第一数据库中;以及通过Kafka消息同时将变更数据发送给第二数据库的第二接收服务器,以使第二接收服务器将Kafka消息发送的数据存入第二数据库中。
如图4B所示,可以通过多线程和Kafka消息406将数据分别存入第一数据库402和第二数据库403中。如图4C所示,可以通过Kafka消息将数据分别存入第一数据库402和第二数据库403中。以通过多线程和Kafka消息存储数据为例,具体地,如图4B所示,首先将需要存储的数据401输入Kafka消息406(即Kafka消息队列中),再由Kafka消息406将这些数据分别通过第一线程发送给第一接收服务器404,通过第二线程发送给第二接收服务器405,然后由第一接收服务器404将这些数据写入第一数据库402,由第二接收服务器405将这些数据写入第二数据库403。
需要说明的是,Kafka是一个分布式、分区的、多副本的、多订阅者,基于zookeeper协调的分布式日志***(也可以当做MQ***)。
通过本公开实施例,可以通过多线程和Kafka消息将数据保存至多维数据库中,由于不同的数据使用不同的线程进行存储操作,且Kafka消息能提供更好的吞吐量以及更高的性能,因此能满足对数据实时性的要求。
作为一种可选的实施例,上述方法还包括:在获取变更数据后,将变更数据作为一条任务记录写入任务表中;在存储变更数据的过程中,查看第一数据库和第二数据库的状态值是否都是已完成状态;以及在第一数据库和/或第二数据库的状态值不是已完成状态的情况下,通过Kafka消息将写入任务表中的任务记录中的变更数据发送给第一数据库的第一接收服务器和/或第二数据库的第二接收服务器,以保证状态值不是已完成状态的数据库能够成功存入变更数据。
如图4D所示,在存储需要存储的数据401的过程中,可以同时在任务表407中添加一条任务记录,用于记录当前正在存储的数据,这样,当第一数据库402和第二数据库403中任一一个或者两个出现数据存储失败的情况时,如第一数据库402存储失败时,可以通过Kafka消息将任务表407中记载的这条任务记录中的数据发送给第一接收服务器404,进而由第一接收服务器404对第一数据库402再执行一次数据写入操作,如此循环,直到数据写入成功为止。优选的,在数据写入成功后,需要同步更新任务表407中的对应数据库的任务完成状态。
具体地,可以基于定时调度框架Quartz等工具,定时扫描同步任务表,实时查询同步任务表中的每一条记录,判断每条记录的E项任务(即第一数据库的存储任务)和M项任务(即第二数据库的存储任务)是否为已完成状态。如果任务记录S2的E项未完成,则通过Kafka消息将S2所代表的数据A2发送给Elasticsearch接收服务器(即第一接收服务器),Elasticsearch接收服务器接收到数据A2,将其更新至Elasticsearch数据库中,更新完成后,将S2中的E列更新为已完成状态。同样,如果记录S2的M项未完成,则通过Kafka消息将S2所代表的数据A2发送给MongoDB接收服务器(即第二接收服务器),MongoDB接收服务器接收到数据A2,将其更新至MongoDB数据库中,更新完成后,将S2中的M列更新为已完成状态。
通过本公开实施例,增加同步任务表,通过实时处理同步任务表,能够保证所有的数据都能完整以及准确地写入到Elasticsearch数据库和MongoDB数据库中,并对外提供准确地查询服务。
作为一种可选的实施例,如图4E所示,上述方法还包括:
在操作S304,将第一数据库中早于预设时间存入的历史数据删除。
具体地,在本公开实施例中,以第一数据库为Elasticsearch数据库且第二数据库为MongoDB数据库为例,可以基于查询热度和查询时间,将数据存储在Elasticsearch数据库和MongoDB数据库中,同时对外提供多维度查询服务。其中,可以通过Elasticsearch数据库保存热点数据,通过MongoDB数据库保存全量数据,这样,Elasticsearch数据库和MongoDB数据库互为备用,可以保证在任一数据库宕机情况下,仍然可以对外提供查询服务,并且定期清理Elasticsearch数据库中过期的历史数据,可以保证Elasticsearch数据库查询服务的高性能,提供查询效率高的查询服务,使得Elasticsearch数据库和MongoDB数据库能够提供不同热度的查询服务。
作为一种可选的实施例,如图4F所示,上述方法还包括:在获取变更数据后,将变更数据分库分表存入一分布式数据库集群408中,以实现大数据分库分表存储。
以下通过一个具体实施例详细阐述本公开:
一般地,正常的数据库信息存储是将新增、修改、删除的数据通过分库分表的规则更新进相应的Mysql数据库中,如新增A数据。通过本公开提供的技术方案,可以基于多线程,在同步任务表中异步的快速新增一条数据同步任务记录S1,此同步任务表用于保证数据库中所存数据的完整性和准确性。同步任务表有两个任务列,E和M列分别代表存储Elasticsearch数据库和存储MongoDB数据库的两个任务项。与此同时,基于Kafka消息队列将新增的A数据发送给这两个数据库的接收服务器。由于Kafka消息能提供更好的吞吐量以及更高的性能,因此能满足对数据实时性的要求。
Elasticsearch接收服务器是用于实时抓取Kafka中的消息并进行数据写入处理的服务,当该接收服务器实时地抓取到新增的A数据的消息后,将A数据存储至Elasticsearch数据库中,存储成功后,更新同步任务表S1记录的E列为已完成状态。
MongoDB接收服务器是用于实时抓取Kafka中的消息并进行数据写入处理的服务,当该接收服务器实时地抓取到新增的A数据的消息后,将A数据存储至MongoDB数据库中,存储成功后,更新同步任务表S1记录的M列为已完成状态。
根据用户的使用特性以及存储数据库的特性,Elasticsearch数据库提供常用时间段内的热点数据查询服务。MongoDB数据库存储全量的数据信息,用于在必要时做历史数据的聚合查询,以及当Elasticsearch数据库服务宕机时,接替Elasticsearch数据库提供查询服务,保证聚合查询服务的高可用性。
通过本公开实施例,可以基于多线程和Kafka消息进行数据信息的同步,根据查询数据的特点将数据分别存储至Elasticsearch和MongoDB中,不仅可以满足时效性的要求,而且还可以保证聚合查询服务的高可用性。
图5示意性示出了根据本公开实施例的数据处理***的框图。
如图5所示,该数据处理***500包括获取模块510、第一存储模块520和第二存储模块530。
获取模块510,用于获取数据操作产生的变更数据;第一存储模块520,用于将变更数据存入第一数据库中,其中,第一数据库支持数据聚合查询;以及第二存储模块530,用于将变更数据存入第二数据库中,其中,第二数据库也支持数据聚合查询,用于作为第一数据库的备用数据库。
通过本公开实施例,因为采用了两个互为备用的且都支持数据聚合查询服务的数据库(如第一数据库和第二数据库)来存储变更数据的技术手段,所以至少部分地克服了查询服务不稳地,存在不可用的风险的技术问题,进而达到了提高查询服务的可用性的技术效果。例如,第一数据库为Elasticsearch数据库,用于保存热点数据,第一数据库为MongoDB数据库,用于保存全量数据,这样可以保证在任一数据库出现宕机情况时,仍然可以提供聚合查询服务,因而通过Elasticsearch数据库和MongoDB数据库互备,能够提高聚合查询服务的可用性。
作为一种可选的实施例,上述第一存储模块,还用于通过第一线程将变更数据存入第一数据库中;以及第二存储模块,还用于通过不同于第一线程且与第一线程同步的第二线程将变更数据存入第二数据库中。
通过本公开实施例,通过多线程将数据保存至多维度数据库中,可以提高数据存储的时效性,从而能够提供一种实时性准确性较高的聚合查询服务。
作为一种可选的实施例,上述第一存储模块,还用于通过Kafka消息将变更数据发送给第一数据库的第一接收服务器,以使第一接收服务器将Kafka消息发送的数据存入第一数据库中;以及第二存储模块,还用于通过Kafka消息同时将变更数据发送给第二数据库的第二接收服务器,以使第二接收服务器将Kafka消息发送的数据存入第二数据库中。
通过本公开实施例,可以通过多线程和Kafka消息将数据保存至多维数据库中,由于不同的数据使用不同的线程进行存储操作,且Kafka消息能提供更好的吞吐量以及更高的性能,因此能满足对数据实时性的要求。
作为一种可选的实施例,上述***还包括:第三存储模块,用于在获取变更数据后,将变更数据作为一条任务记录写入任务表中;查询模块,用于在存储变更数据的过程中,查看第一数据库和第二数据库的状态值是否都是已完成状态;第一存储模块,还用于在第一数据库和第二数据库的状态值不是已完成状态或者第一数据库的状态值不是已完成状态的情况下,通过Kafka消息将写入任务表中的任务记录中的变更数据发送给第一数据库的第一接收服务器,以保证状态值不是已完成状态的第一数据库能够成功存入变更数据;以及第二存储模块,还用于在第一数据库和第二数据库的状态值不是已完成状态或者第二数据库的状态值不是已完成状态的情况下,通过Kafka消息将写入任务表中的任务记录中的变更数据发送给第二数据库的第二接收服务器,以保证状态值不是已完成状态的第二数据库能够成功存入变更数据。
通过本公开实施例,增加同步任务表,通过实时处理同步任务表,能够保证所有的数据都能完整以及准确地写入到Elasticsearch数据库和MongoDB数据库中,并对外提供准确地查询服务。
作为一种可选的实施例,如图6A所示,上述***还包括:删除模块540,用于将第一数据库中早于预设时间存入的历史数据删除。
通过本公开实施例,可以通过Elasticsearch数据库保存热点数据,通过MongoDB数据库保存全量数据,这样,Elasticsearch数据库和MongoDB数据库互为备用,可以保证在任一数据库宕机情况下,仍然可以对外提供查询服务,并且定期清理Elasticsearch数据库中过期的历史数据,可以保证Elasticsearch数据库查询服务的高性能,提供查询效率高的查询服务,使得Elasticsearch数据库和MongoDB数据库能够提供不同热度的查询服务。
作为一种可选的实施例,如图6B所示,上述***还包括:第四存储模块550,用于在获取变更数据后,将变更数据分库分表存入一分布式数据库集群中。
通过本公开实施例,可以基于多线程和Kafka消息进行数据信息的同步,根据查询数据的特点将数据分别存储至Elasticsearch和MongoDB中,不仅可以满足时效性的要求,而且还可以保证聚合查询服务的高可用性。
可以理解的是,获取模块510、第一存储模块520和第二存储模块530等可以合并在一个模块中实现,或者其中的任意一个模块可以被拆分成多个模块。或者,这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合,并在一个模块中实现。根据本发明的实施例,获取模块510、第一存储模块520和第二存储模块530等中的至少一个可以至少被部分地实现为硬件电路,例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上***、基板上的***、封装上的***、专用集成电路(ASIC),或可以以对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现,或以软件、硬件以及固件三种实现方式的适当组合来实现。或者,获取模块510、第一存储模块520和第二存储模块530等中的至少一个可以至少被部分地实现为计算机程序模块,当该程序被计算机运行时,可以执行相应模块的功能。
图7示意性示出了根据本公开实施例的适于实现数据处理方法的计算机***的框图。图7示出的计算机***仅仅是一个示例,不应对本公开实施例的功能和使用范围带来任何限制。
如图7所示,根据本公开实施例的计算机***700包括处理器701,其可以根据存储在只读存储器(ROM)702中的程序或者从存储部分708加载到随机访问存储器(RAM)703中的程序而执行各种适当的动作和处理。处理器701例如可以包括通用微处理器(例如CPU)、指令集处理器和/或相关芯片组和/或专用微处理器(例如,专用集成电路(ASIC)),等等。处理器701还可以包括用于缓存用途的板载存储器。处理器701可以包括用于执行参考图3,图4A~图4F描述的根据本公开实施例的***流程的不同动作的单一处理单元或者是多个处理单元。
在RAM 703中,存储有***700操作所需的各种程序和数据。处理器701、ROM 702以及RAM 703通过总线704彼此相连。处理器701通过执行ROM 702和/或RAM 703中的程序来执行以上参考图3,图4A~图4F描述的各种操作。需要注意,所述程序也可以存储在除ROM 702和RAM 703以外的一个或多个存储器中。处理器701也可以通过执行存储在所述一个或多个存储器中的程序来执行以上参考图3,图4A~图4F描述的各种操作。
根据本公开的实施例,***700还可以包括输入/输出(I/O)接口705,输入/输出(I/O)接口705也连接至总线704。***700还可以包括连接至I/O接口705的以下部件中的一项或多项:包括键盘、鼠标等的输入部分706;包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分707;包括硬盘等的存储部分708;以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分709。通信部分709经由诸如因特网的网络执行通信处理。驱动器710也根据需要连接至I/O接口705。可拆卸介质711,诸如磁盘、光盘、磁光盘、半导体存储器等等,根据需要安装在驱动器710上,以便于从其上读出的计算机程序根据需要被安装入存储部分708。
根据本公开的实施例,上文参考流程图描述的***可以被实现为计算机软件程序。例如,本公开的实施例包括一种计算机程序产品,其包括承载在计算机可读存储介质上的计算机程序,该计算机程序包含用于执行流程图所示的***的程序代码。在这样的实施例中,该计算机程序可以通过通信部分709从网络上被下载和安装,和/或从可拆卸介质711被安装。在该计算机程序被处理器701执行时,执行本公开实施例的***中限定的上述功能。根据本公开的实施例,上文描述的***、设备、装置、模块、单元等可以通过计算机程序模块来实现。
需要说明的是,本公开所示的计算机可读存储介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的***、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于:具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行***、装置或者器件使用或者与其结合使用。而在本公开中,计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读存储介质,该计算机可读存储介质可以发送、传播或者传输用于由指令执行***、装置或者器件使用或者与其结合使用的程序。计算机可读存储介质上包含的程序代码可以用任何适当的介质传输,包括但不限于:无线、电线、光缆、RF等等,或者上述的任意合适的组合。根据本公开的实施例,计算机可读存储介质可以包括上文描述的ROM 702和/或RAM 703和/或ROM 702和RAM 703以外的一个或多个存储器。
附图中的流程图和框图,图示了按照本公开各种实施例的***、***和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分,上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图或流程图中的每个方框、以及框图或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的***来实现,或者可以用专用硬件与计算机指令的组合来实现。
作为另一方面,本公开还提供了一种计算机可读存储介质,该计算机可读存储介质可以是上述实施例中描述的设备中所包含的;也可以是单独存在,而未装配入该设备中。上述计算机可读存储介质承载有一个或者多个程序,当上述一个或者多个程序被一个该设备执行时,使得该设备执行:获取数据操作产生的变更数据;将变更数据存入第一数据库中,其中,第一数据库支持数据聚合查询;以及将变更数据存入第二数据库中,其中,第二数据库也支持数据聚合查询,用于作为第一数据库的备用数据库。
以上对本公开的实施例进行了描述。但是,这些实施例仅仅是为了说明的目的,而并非为了限制本公开的范围。尽管在以上分别描述了各实施例,但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围,本领域技术人员可以做出多种替代和修改,这些替代和修改都应落在本公开的范围之内。

Claims (14)

1.一种数据处理方法,包括:
获取数据操作产生的变更数据;
将所述变更数据存入第一数据库中,其中,所述第一数据库支持数据聚合查询;以及
将所述变更数据存入第二数据库中,其中,所述第二数据库也支持数据聚合查询,用于作为所述第一数据库的备用数据库。
2.根据权利要求1所述的方法,其中,所述方法还包括:
通过第一线程将所述变更数据存入所述第一数据库中;以及
通过不同于所述第一线程且与所述第一线程同步的第二线程将所述变更数据存入所述第二数据库中。
3.根据权利要求1或2所述的方法,其中,所述方法还包括:
通过Kafka消息将所述变更数据发送给所述第一数据库的第一接收服务器,以使所述第一接收服务器将所述Kafka消息发送的数据存入所述第一数据库中;以及
通过所述Kafka消息同时将所述变更数据发送给所述第二数据库的第二接收服务器,以使所述第二接收服务器将所述Kafka消息发送的数据存入所述第二数据库中。
4.根据权利要求3所述的方法,其中,所述方法还包括:
在获取所述变更数据后,将所述变更数据作为一条任务记录写入任务表中;
在存储所述变更数据的过程中,查看所述第一数据库和所述第二数据库的状态值是否都是已完成状态;以及
在所述第一数据库和/或所述第二数据库的状态值不是已完成状态的情况下,通过所述Kafka消息将写入所述任务表中的所述任务记录中的所述变更数据发送给所述第一数据库的所述第一接收服务器和/或所述第二数据库的所述第二接收服务器,以保证状态值不是已完成状态的数据库能够成功存入所述变更数据。
5.根据权利要求1所述的方法,其中,所述方法还包括:
将所述第一数据库中早于预设时间存入的历史数据删除。
6.根据权利要求1所述的方法,其中,所述方法还包括:
在获取所述变更数据后,将所述变更数据分库分表存入一分布式数据库集群中。
7.一种数据处理***,包括:
获取模块,用于获取数据操作产生的变更数据;
第一存储模块,用于将所述变更数据存入第一数据库中,其中,所述第一数据库支持数据聚合查询;以及
第二存储模块,用于将所述变更数据存入第二数据库中,其中,所述第二数据库也支持数据聚合查询,用于作为所述第一数据库的备用数据库。
8.根据权利要求7所述的***,其中:
所述第一存储模块,还用于通过第一线程将所述变更数据存入所述第一数据库中;以及
所述第二存储模块,还用于通过不同于所述第一线程且与所述第一线程同步的第二线程将所述变更数据存入所述第二数据库中。
9.根据权利要求7或8所述的***,其中:
所述第一存储模块,还用于通过Kafka消息将所述变更数据发送给所述第一数据库的第一接收服务器,以使所述第一接收服务器将所述Kafka消息发送的数据存入所述第一数据库中;以及
所述第二存储模块,还用于通过所述Kafka消息同时将所述变更数据发送给所述第二数据库的第二接收服务器,以使所述第二接收服务器将所述Kafka消息发送的数据存入所述第二数据库中。
10.根据权利要求9所述的***,其中,所述***还包括:
第三存储模块,用于在获取所述变更数据后,将所述变更数据作为一条任务记录写入任务表中;
查询模块,用于在存储所述变更数据的过程中,查看所述第一数据库和所述第二数据库的状态值是否都是已完成状态;
所述第一存储模块,还用于在所述第一数据库和所述第二数据库的状态值不是已完成状态或者所述第一数据库的状态值不是已完成状态的情况下,通过所述Kafka消息将写入所述任务表中的所述任务记录中的所述变更数据发送给所述第一数据库的所述第一接收服务器,以保证状态值不是已完成状态的所述第一数据库能够成功存入所述变更数据;以及
所述第二存储模块,还用于在所述第一数据库和所述第二数据库的状态值不是已完成状态或者所述第二数据库的状态值不是已完成状态的情况下,通过所述Kafka消息将写入所述任务表中的所述任务记录中的所述变更数据发送给所述第二数据库的所述第二接收服务器,以保证状态值不是已完成状态的所述第二数据库能够成功存入所述变更数据。
11.根据权利要求7所述的***,其中,所述***还包括:
删除模块,用于将所述第一数据库中早于预设时间存入的历史数据删除。
12.根据权利要求7所述的***,其中,所述***还包括:
第四存储模块,用于在获取所述变更数据后,将所述变更数据分库分表存入一分布式数据库集群中。
13.一种计算机***,包括:
一个或多个处理器;
存储器,用于存储一个或多个程序,
其中,当所述一个或多个程序被所述一个或多个处理器执行时,使得所述一个或多个处理器实现权利要求1至6中任一项所述的数据处理方法。
14.一种计算机可读存储介质,其上存储有可执行指令,该指令被处理器执行时使处理器实现权利要求1至6中任一项所述的数据处理方法。
CN201711477730.0A 2017-12-29 2017-12-29 数据处理方法及***、计算机***、计算机可读存储介质 Pending CN110019310A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201711477730.0A CN110019310A (zh) 2017-12-29 2017-12-29 数据处理方法及***、计算机***、计算机可读存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201711477730.0A CN110019310A (zh) 2017-12-29 2017-12-29 数据处理方法及***、计算机***、计算机可读存储介质

Publications (1)

Publication Number Publication Date
CN110019310A true CN110019310A (zh) 2019-07-16

Family

ID=67187175

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201711477730.0A Pending CN110019310A (zh) 2017-12-29 2017-12-29 数据处理方法及***、计算机***、计算机可读存储介质

Country Status (1)

Country Link
CN (1) CN110019310A (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111680063A (zh) * 2020-05-25 2020-09-18 泰康保险集团股份有限公司 Elasticsearch分页查询数据的方法及装置
CN112950345A (zh) * 2021-03-05 2021-06-11 北京健康之家科技有限公司 业财数据处理方法、装置及计算机设备
CN113268488A (zh) * 2020-02-14 2021-08-17 北京京东振世信息技术有限公司 数据持久化的方法和装置
CN113961580A (zh) * 2021-12-22 2022-01-21 联通智网科技股份有限公司 数据查询方法、业务***以及电子设备
CN115952200A (zh) * 2023-01-17 2023-04-11 安芯网盾(北京)科技有限公司 一种基于mpp架构的多源异构数据聚合查询方法及装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070124348A1 (en) * 2005-11-30 2007-05-31 Oracle International Corporation Database system configured for automatic failover with no data loss
CN102299904A (zh) * 2010-06-23 2011-12-28 阿里巴巴集团控股有限公司 一种实现业务数据备份的***及方法
CN103744906A (zh) * 2013-12-26 2014-04-23 乐视网信息技术(北京)股份有限公司 一种数据同步***、方法及装置
CN104834558A (zh) * 2015-05-19 2015-08-12 北京京东尚科信息技术有限公司 一种数据处理的方法及***
CN106294672A (zh) * 2016-08-08 2017-01-04 杭州玳数科技有限公司 一种日志实时展现和查询的方法与***
CN106326469A (zh) * 2016-08-31 2017-01-11 无锡雅座在线科技发展有限公司 数据的同步方法和装置

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070124348A1 (en) * 2005-11-30 2007-05-31 Oracle International Corporation Database system configured for automatic failover with no data loss
CN102299904A (zh) * 2010-06-23 2011-12-28 阿里巴巴集团控股有限公司 一种实现业务数据备份的***及方法
CN103744906A (zh) * 2013-12-26 2014-04-23 乐视网信息技术(北京)股份有限公司 一种数据同步***、方法及装置
CN104834558A (zh) * 2015-05-19 2015-08-12 北京京东尚科信息技术有限公司 一种数据处理的方法及***
CN106294672A (zh) * 2016-08-08 2017-01-04 杭州玳数科技有限公司 一种日志实时展现和查询的方法与***
CN106326469A (zh) * 2016-08-31 2017-01-11 无锡雅座在线科技发展有限公司 数据的同步方法和装置

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113268488A (zh) * 2020-02-14 2021-08-17 北京京东振世信息技术有限公司 数据持久化的方法和装置
CN113268488B (zh) * 2020-02-14 2023-11-03 北京京东振世信息技术有限公司 数据持久化的方法和装置
CN111680063A (zh) * 2020-05-25 2020-09-18 泰康保险集团股份有限公司 Elasticsearch分页查询数据的方法及装置
CN111680063B (zh) * 2020-05-25 2023-08-18 泰康保险集团股份有限公司 Elasticsearch分页查询数据的方法及装置
CN112950345A (zh) * 2021-03-05 2021-06-11 北京健康之家科技有限公司 业财数据处理方法、装置及计算机设备
CN113961580A (zh) * 2021-12-22 2022-01-21 联通智网科技股份有限公司 数据查询方法、业务***以及电子设备
CN115952200A (zh) * 2023-01-17 2023-04-11 安芯网盾(北京)科技有限公司 一种基于mpp架构的多源异构数据聚合查询方法及装置
CN115952200B (zh) * 2023-01-17 2023-06-27 安芯网盾(北京)科技有限公司 一种基于mpp架构的多源异构数据聚合查询方法及装置

Similar Documents

Publication Publication Date Title
CN110019310A (zh) 数据处理方法及***、计算机***、计算机可读存储介质
US10162874B2 (en) Related table notifications
AU2018204273B2 (en) Auto discovery of configuration items
CN109413127A (zh) 一种数据同步方法和装置
CN110209677A (zh) 更新数据的方法和装置
US11386264B2 (en) Configuring complex tables in a client experience framework
CN109388654A (zh) 一种查询数据表的方法和装置
US20130085895A1 (en) High throughput global order promising system
CN110019062A (zh) 数据同步方法和***
CN109241033A (zh) 创建实时数据仓库的方法和装置
CN111125107A (zh) 数据处理方法、装置、电子设备和介质
CN110221829A (zh) 信息处理方法及其***、计算机***及计算机可读介质
CN111258988B (zh) 资产管理方法、装置、电子设备以及介质
CN109960212A (zh) 任务发送方法和装置
CN110399397A (zh) 一种数据查询方法和***
CN110020271A (zh) 用于缓存管理的方法和***
CN110020373A (zh) 静态页面存储、浏览的方法和装置
US10942866B1 (en) Priority-based cache
CN111984686A (zh) 一种数据处理的方法和装置
CN110879818B (zh) 一种获取数据的方法、装置、介质和电子设备
CN110019525A (zh) 一种数据库扩容的方法和装置
CN104715349A (zh) 一种电子商务运费计算的方法和***
CN111695749A (zh) 一种分组任务的生成方法和装置
CN113127416A (zh) 数据查询方法和装置
US10769027B1 (en) Queued scheduler

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
RJ01 Rejection of invention patent application after publication

Application publication date: 20190716