搜索数据的构建方法、增量数据的推送方法及装置和设备
技术领域
本申请涉及计算机技术领域,尤其涉及搜索数据的构建方法、增量数据的推送方法及装置和设备。
背景技术
目前互联网上产生的业务种类繁多,各种业务系统在业务发生过程中会产生各种业务数据,比如电商交易订单数据、保险的保单数据等,这些业务数据属于业务的基础数据,由于数据量大,这些基础数据经常会存储在多个数据库或者多个数据库表中。
现实中,对于基础数据,经常存在各种搜索需求,比如全文搜索、按照某一维度聚合搜索、过滤等。开发中经常会基于搜索引擎构建并存储搜索数据,以实现对这些基础数据的搜索。这就需要搜索引擎能在基础数据更新后,及时更新搜索数据。
为了保证搜索引擎能及时更新搜索数据,目前通常采用消息机制异步化来获取增量数据(增量数据是指业务发生过程中实时产生的新的业务数据),以更新搜索数据,即,业务系统产生基础数据并写入数据库后,通常会发送一条异步消息,搜索引擎基于异步消息来构建搜索数据。但是,这种做法使得业务系统和搜索数据具有强耦合性,一方面,如果业务系统不关注异步消息的发送结果,一旦异步消息发送失败,将会使得搜索引擎难以及时更新搜索数据;另一方面,如果业务系统实时关注异步消息的发送结果,构建搜索数据的过程会影响业务系统的业务处理效率。
发明内容
有鉴于此,本申请提供一种搜索数据的构建方法、增量数据的推送方法及装置和设备。
根据本申请实施例的第一方面,提供一种搜索数据的构建方法,包括步骤:
数据库存储增量数据后,在目标日志文件中生成相应的记录;所述目标日志文件通过预先修改相应的配置文件被启用,所述目标日志文件记录有触发事件,所述触发事件为描述所述数据库产生增量数据的事件;
数据推送方获取数据库的目标日志文件并解析;
基于对目标日志文件的解析结果构建预设结构体的数据;所述预设结构体包括操作时间、操作类型和操作对象;所述操作类型与所述触发事件对应,所述操作对象与所述增量数据对应;
将预设结构体的数据推送给搜索引擎;
搜索引擎基于预设结构体的数据构建搜索数据。
根据本申请实施例的第二方面,提供一种增量数据的推送方法,包括以下步骤:
获取数据库的目标日志文件并解析;所述数据库用于存储增量数据,所述目标日志文件记录有触发事件,所述触发事件为描述所述数据库产生增量数据的事件;
基于对目标日志文件的解析结果构建预设结构体的数据;所述预设结构体包括操作时间、操作类型和操作对象,所述操作类型与所述触发事件对应,所述操作对象与所述增量数据对应;
推送预设结构体的数据。
根据本申请实施例的第三方面,提供一种搜索数据的构建系统,包括数据库、数据推送方和搜索引擎,所述数据库用于存储增量数据,并在目标日志文件中生成相应的记录;所述目标日志文件通过预先修改相应的配置文件被启用,所述目标日志文件记录有触发事件,所述触发事件为描述所述数据库产生增量数据的事件;
所述数据推送方包括:
日志解析模块,用于获取数据库的目标日志文件并解析;
数据构建模块,用于基于对目标日志文件的解析结果构建预设结构体的数据;所述预设结构体包括操作时间、操作类型和操作对象;所述操作类型与所述触发事件对应,所述操作对象与所述增量数据对应;
数据推送模块,用于将预设结构体的数据推送给所述搜索引擎;
所述搜索引擎用于基于预设结构体的数据构建搜索数据。
根据本申请实施例的第四方面,提供一种增量数据的推送装置,包括:
日志解析模块,用于获取数据库的目标日志文件并解析;所述数据库用于存储增量数据,所述目标日志文件记录有触发事件,所述触发事件为描述所述数据库产生增量数据的事件;
数据构建模块,用于基于对目标日志文件的解析结果构建预设结构体的数据;所述预设结构体包括操作时间、操作类型和操作对象,所述操作类型与所述触发事件对应,所述操作对象与所述增量数据对应;
数据推送模块,用于推送预设结构体的数据。
根据本申请实施例的第五方面,提供一种计算机设备,包括:
处理器;
存储处理器可执行指令的存储器;
其中,所述处理器耦合于所述存储器,用于读取所述存储器存储的程序指令,并作为响应,执行如下操作:
获取数据库的目标日志文件并解析;所述数据库用于存储增量数据,所述目标日志文件记录有触发事件,所述触发事件为描述所述数据库产生增量数据的事件;
基于对目标日志文件的解析结果构建预设结构体的数据;所述预设结构体包括操作时间、操作类型和操作对象,所述操作类型与所述触发事件对应,所述操作对象与所述增量数据对应;
推送预设结构体的数据。
实施本申请提供的实施例,无需产生增量数据的业务系统发送异步消息和关注异步消息是否发送成功,即可以通过解析数据库的目标日志文件构建含有增量数据的预设结构体的数据,然后推送预设结构体的数据到搜索引擎,搜索引擎即可以根据预设结构体的数据及时更新搜索数据,同时还可以降低对业务系统的影响。
附图说明
图1是本申请一示例性实施例示出的搜索数据的构建系统的架构图;
图2是本申请一示例性实施例示出的搜索数据的构建方法的流程图;
图3是本申请一示例性实施例示出的搜索数据的构建方法的时序图;
图4是本申请一示例性实施例示出的增量数据的推送的流程图;
图5是本申请一示例性实施例示出的增量数据的推送装置的逻辑框图;
图6是本申请一示例性实施例示出的增量数据的推送装置所在的计算机设备的硬件结构图。
具体实施方式
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
在本申请使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解,尽管在本申请可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本申请范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
本申请涉及的搜索数据,可以指搜索引擎应各种搜索需求,基于各种业务系统在业务发生过程中会产生的增量数据构建的数据。为了保证搜索引擎及时根据增量数据更新搜索数据,目前的业务系统产生基础数据并写入数据库后,会发送一条异步消息到搜索引擎,搜索引擎再基于异步消息来构建搜索数据。而网络中断、网络延迟等原因很可能导致异步消息发送失败,进而导致搜索数据缺失,与增量数据不一致。为了避免这种状况发生,业务系统需要与搜索引擎强耦合,即实时关注异步消息的发送结果、根据发送结果确定是否重发异步消息,而业务系统对搜索数据的构建过程的关注程度越高,业务系统对自身业务的处理效率越低,所以,目前构建搜索数据的过程会对业务系统产生极大的负面影响。本申请针对如何降低搜索数据的构建过程对业务系统的负面影响提出解决方案。
为降低搜索数据的构建过程对业务系统的负面影响,本申请的方案,只需业务系统将产生的增量数据存储到数据库,无需再发送异步消息。在构建搜索数据时,利用数据库中记录增量数据产生的目标日志文件,解析出业务系统产生的增量数据,并将增量数据构建更新到搜索引擎中,实现搜索数据的准实时更新,在确保搜索数据的及时性的同时,解除了业务系统与搜索的强耦合,进而降低搜索数据的构建过程对业务系统的负面影响。以下结合附图1,例举一种搜索数据的构建系统,通过该系统构建搜索数据,既能确保搜索数据的及时性,又能解除业务系统与搜索的解耦。
图1所示的系统,可以包括数据库110、数据推送方120和搜索引擎130。数据推送方120分别与数据库110和搜索引擎130对接,用于从数据库110中解析出业务系统的增量数据,并转至搜索引擎130。
应用场景不同时,数据推送方120、数据库110和搜索引擎130的部署位置不同,比如,图1所示系统部署于提供某种业务的企业内部,用于为企业内部人员提供搜索业务数据的服务时,数据推送方120与数据库110和搜索引擎130可以部署于该企业的同一业务服务器上;再比如,图1所示的系统用于为用户提供搜索不同业务的业务数据的服务,数据推送方120、数据库110和搜索引擎130可以分别部署于不同的服务器上,如:数据库110部署于存储各种业务系统的业务数据的数据存储服务器上,数据推送方120部署于分发不同业务数据的数据分发服务器上,搜索引擎130部署于应各种搜索需求提供搜索数据的搜索服务器上。
实际应用中,数据库110用于存储增量数据,并在目标日志文件中生成相应的记录;所述目标日志文件通过预先修改相应的配置文件被启用,所述目标日志文件记录有触发事件,所述触发事件为描述所述数据库产生增量数据的事件。这里的增量数据可以指各种业务系统在业务发生过程中会产生各种业务数据,比如电商交易订单数据、保险的保单数据等等。
某些例子中,为了更全面的记录业务系统对数据库110的操作,本申请设计人员可以采用能够记录选择(SELECT)和展示(SHOW)这类操作的二进制查询日志文件,作为目标日志文件,并在数据库110产生增量数据后,生成相应的记录。
此外,为了便于管理和共享数据,本申请设计人员可以选择关系数据库作为数据库110,这里提到的关系数据库可以是Oracle、Hbase、MySQL等等,在其他例子中,本申请设计人员还可以选择树状数据库(Hierarchical Database)、面向对象数据库(Object-oriented Database)等等,本申请实施例对此不做限制。
在数据库110为关系数据库时,所述目标日志文件可以是binlog文件,所述配置文件为my.cnf。
在数据库110存储增量数据后,数据推送方120即可以从数据库110中解析出业务系统的增量数据,并转换为预设结构体的数据,并转至搜索引擎130。搜索引擎130接收到预设结构体的数据后,可以基于预设结构体的数据构建搜索数据。
具体实现时,数据推送方120可以通过其所包含的日志解析模块121、数据构建模块122和数据推送模块123实现数据推送,其中,日志解析模块121,用于获取数据库的目标日志文件并解析。数据构建模块122,用于基于对目标日志文件的解析结果构建预设结构体的数据,所述预设结构体包括操作时间、操作类型和操作对象;所述操作类型与所述触发事件对应,所述操作对象与所述增量数据对应。数据推送模块123,用于将预设结构体的数据推送给搜索引擎130。在其他例子中,数据推送方可以具体为数据同步中间件,将MySQL、Oracle、Hbase等数据库的数据同步到搜索引擎130,以便能及时根据业务系统产生的增量数据,准实时地构建业务增量搜搜索引数据。
日志解析模块121在解析目标日志文件时,可以按照目标日志文件中记录的标准格式进行解析,解析出产生增量数据的事件的操作时间、操作类型和操作对象,以下以关系数据库MySQL的binlog文件为例,介绍下如何解析目标日志文件。
首先介绍下binlog文件的三种标准格式:
一:binlog日志的标准格式为Statement level时,每一条会修改数据的sql都会记录在binlog文件中,且不需要记录每一行的变化,可以减少binlog文件的日志量。
二:binlog日志的标准格式为Row level,记录时可以不记录执行的sql语句的上下文相关的信息,仅需要记录被修改后的记录内容即可。可以清楚的记录下每一行数据修改的细节,而且不会出现某些特定情况下的存储过程、function以及trigger的调用和触发无法被正确复制的问题。
三:binlog日志的标准格式为Mixed level,是以上两种标准格式的混合使用,一般的语句修改使用Statment格式保存binlog,如一些函数,Statement无法完成主从复制的操作,则采用Row格式保存。实际记录时,MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式,也就是在Statement和Row之间选择一种。
其次,在解析Mysql的Binlog日志时,可以通过MysqlBinlog指令查看具体的Mysql的Binlog日志,指令如下:
//////////////////////////////////////////////////////////////
SET TIMESTAMP=1350355892/*!*/;
BEGIN
/*!*/;
#at 1643330
#121016 10:51:32server id 1 end_log_pos 1643885
Query thread_id=272571 exec_time=0 error_code=0
SET TIMESTAMP=1350355892/*!*/;
Insert into T_test…)
/*!*/;
#at 1643885
#121016 10:51:32server id 1 end_log_pos 1643912 Xid=0
COMMIT/*!*/;
//////////////////////////////////////////////////////////////
其中,开始事物的时间为:
SET TIMESTAMP=1350355892/*!*/;
BEGIN
sqlevent起点为:#at 1643330,指事件的起点,以1643330字节开始。
sqlevent发生的时间点为:#121016 10:51:32,指事件发生的时间。
server id 1为:master的serverId。
事件的终点为:end_log_pos 1643885,以1643885字节结束。
花费的时间为:execTime 0。
错误码为:error_code=0。
事件指示提交的XA事务为:Xid。
某些场景下,由于增量数据异常、网络延迟、网络中断等原因,数据推送方120可能会漏掉目标日志文件中的部分记录,解析所得的数据会漏掉部分增量数据,进而导致搜索引擎130中的搜索数据与数据库110存储的业务数据不一致,发生丢失部分业务数据的状况,为避免该状况的发生,本申请实施例可以在搜索数据的构建系统中增设离线数据仓库140,分别与数据库110和搜索引擎130对接,数据库110可以定时将其之前存储的增量数据同步到离线数据仓库140,离线数据仓库140将同步的数据构建成预设结构体的数据,并将构建的预设结构体的数据推送给搜索引擎130,搜索引擎130再基于离线数据仓库140推送的数据构建搜索数据。从而能够尽快对数据推送方120实时处理过程中遗漏的数据进行补充,在一定的时间内保证搜索数据与业务数据的一致性。
实际应用中,为了数据库110区分已同步或未同步到离线数据仓库140的增量数据,可以在存储增量数据时,为增量数据构建时间戳,然后每天的某个时刻(如早上八点),根据时间戳查找之前一天存储的所有增量数据,将查找到的数据同步到离线数据仓库140。
参见图2,图2是本申请一示例性实施例示出的搜索数据的构建方法的流程图,该实施例结合图1所示系统,通过数据库、数据推送方和搜索引擎这三者间的数据传输,描述了一种搜索数据的构建过程,可以包括步骤S201-S205:
步骤S201、数据库存储增量数据后,在目标日志文件中生成相应的记录;所述目标日志文件通过预先修改相应的配置文件被启用,所述目标日志文件记录有触发事件,所述触发事件为描述所述数据库产生增量数据的事件。
步骤S202、数据推送方获取数据库的目标日志文件并解析。
步骤S203、数据推送方基于对目标日志文件的解析结果构建预设结构体的数据;所述预设结构体包括操作时间、操作类型和操作对象;所述操作类型与所述触发事件对应,所述操作对象与所述增量数据对应。
步骤S204、数据推送方将预设结构体的数据推送给搜索引擎。
步骤S205、搜索引擎基于预设结构体的数据构建搜索数据。
本申请实施例中,所述目标日志文件可以为二进制查询日志文件。所述数据库为关系数据库,当数据库为关系数据库MySQL时,所述目标日志文件可以为binlog文件。
本申请实施例涉及的技术内容,与图1对应的实施例涉及的技术内容相应,在此不再赘述。
实际应用中,本申请实施例的方法,还可以通过以下操作来增强搜索引擎所构建的搜索数据与数据库存储的数据的一致性:
数据库定时将其之前存储的增量数据同步到离线数据仓库。
离线数据仓库将同步的数据构建成预设结构体的数据,并将构建的预设结构体的数据推送给搜索引擎。
搜索引擎基于离线数据仓库推送的数据构建搜索数据。
以下结合附图3例举一个应用实例,本实例中,业务系统为保险系统,增量数据为保险系统产生的保单数据,当用户投保(步骤1)时,业务系统为用户创建保单(步骤1.1),即产生一组保单数据(增量数据),并将该组保单数据保存在数据库中(步骤1.2)。对应存储的保单数据,数据库会记录binlog日志(步骤2)。数据推送方通过监听binlog日志(步骤3)获取binlog日志,之后,数据推送方通过解析binlog日志(步骤4),生成预设结构体的数据,然后将预设结构体的数据推送至搜索引擎(步骤5),搜索引擎根据预设结构体的数据实时构建增量数据(步骤5.1),完成搜索数据的构建和更新。
其中,数据推送方监听时,能够监听数据库产生的binlog日志的变更类型,并根据变更类型(新增/更新/删除/事务提交/事务回滚等),解析变更的数据,生成预设结构体的数据。
此外,为了避免保单数据异常、网络延迟、网络中断等原因,导致数据推送方漏掉部分binlog日志,进而导致搜索引擎中的搜索数据与数据库存储的保单数据不一致,数据库可以定时将含有之前存储保单数据的表(全量数据)同步到离线数据仓库(步骤6),离线数据仓库对同步的数据加工处理(步骤7),构建出预设结构体的数据,并将构建的预设结构体的数据推送给搜索引擎(步骤8),搜索引擎再基于离线数据仓库推送的数据构建搜索数据,定期构建全量数据(步骤8.1),完成搜索数据的及时补充,保持与数据库中存储的保单数据的一致。
请参阅图4,图4是本申请一示例性实施例示出的增量数据的推送方法的流程图,该实施例能应用于图1所示的数据推送方上,可以包括以下步骤S401-S403:
步骤S401、获取数据库的目标日志文件并解析;所述数据库用于存储增量数据,所述目标日志文件记录有触发事件,所述触发事件为描述所述数据库产生增量数据的事件。
步骤S402、基于对目标日志文件的解析结果构建预设结构体的数据;所述预设结构体包括操作时间、操作类型和操作对象,所述操作类型与所述触发事件对应,所述操作对象与所述增量数据对应。
步骤S403、推送预设结构体的数据。
本申请实施例中,所述目标日志文件可以为二进制查询日志文件。所述数据库为关系数据库,当数据库为关系数据库MySQL时,所述目标日志文件可以为binlog文件。
本申请实施例涉及的技术内容,与图1至图3对应的实施例涉及的技术内容相应,在此不再赘述。
与前述方法的实施例相对应,本申请还提供了装置的实施例。
参见图5,图5是本申请一示例性实施例示出的增量数据的推送装置的逻辑框图,该装置可以包括:日志解析模块510、数据构建模块520和数据推送模块530。
其中,日志解析模块510,用于获取数据库的目标日志文件并解析,所述数据库用于存储增量数据,所述目标日志文件记录有触发事件,所述触发事件为描述所述数据库产生增量数据的事件。
数据构建模块520,用于基于对目标日志文件的解析结果构建预设结构体的数据,所述预设结构体包括操作时间、操作类型和操作对象,所述操作类型与所述触发事件对应,所述操作对象与所述增量数据对应。
数据推送模块530,用于推送预设结构体的数据。
一些例子中,所述目标日志文件为二进制查询日志文件。
作为例子,所述数据库为关系数据库,所述目标日志文件为binlog文件。
上述装置中各个单元(或模块)的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程,在此不再赘述。
对于装置实施例而言,由于其基本对应于方法实施例,所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的单元或模块可以是或者也可以不是物理上分开的,作为单元或模块显示的部件可以是或者也可以不是物理单元或模块,即可以位于一个地方,或者也可以分布到多个网络单元或模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
本申请增量数据的推送装置的实施例可以应用在计算机设备上。具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现中,计算机设备为计算机,计算机的具体形式可以是个人计算机、膝上型计算机、个人数字助理、媒体播放器或者这些设备中的任意几种设备的组合。
装置实施例可以通过软件实现,也可以通过硬件或者软硬件结合的方式实现。以软件实现为例,作为一个逻辑意义上的装置,是通过其所在计算机设备的处理器将非易失性存储器等可读介质中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言,如图6所示,为本申请增量数据的推送装置所在计算机设备的一种硬件结构图,除了图6所示的处理器、内存、网络接口、以及非易失性存储器之外,实施例中装置所在的计算机设备通常根据该计算机设备的实际功能,还可以包括其他硬件,对此不再赘述。计算机设备的存储器可以存储处理器可执行程序指令;处理器可以耦合存储器,用于读取所述存储器存储的程序指令,并作为响应,执行如下操作:获取数据库的目标日志文件并解析,所述数据库用于存储增量数据,所述目标日志文件记录有触发事件,所述触发事件为描述所述数据库产生增量数据的事件;基于对目标日志文件的解析结果构建预设结构体的数据,所述预设结构体包括操作时间、操作类型和操作对象,所述操作类型与所述触发事件对应,所述操作对象与所述增量数据对应;推送预设结构体的数据。
在其他实施例中,处理器所执行的操作可以参考上文方法实施例中相关的描述,在此不予赘述。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
以上所述仅为本申请的较佳实施例而已,并不用以限制本申请,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请保护的范围之内。