CN107016027A - 实现业务信息快速搜索的方法和装置 - Google Patents

Abstract

本申请提供一种实现业务信息快速搜索的方法和装置。所述方法包括：监听到业务数据库生成新的操作日志，所述业务数据库中业务数据的存储结构为分表存储；根据所述操作日志更新中间数据库中的业务数据，所述中间数据库中业务数据的存储结构为单表存储；将所述中间数据库中的业务数据更新到搜索数据库中，所述搜索数据库中业务数据的存储结构与所述中间数据库中业务数据的存储结构相同，所述搜索数据库为业务信息的搜索提供数据库服务。本申请采用单表存储结构的搜索数据库提供业务信息的搜索服务，可以大大提高业务信息的搜索效率，同时，无需修改业务数据库的存储结构，方便业务数据的处理与维护。

Description

实现业务信息快速搜索的方法和装置

技术领域

本申请涉及通信技术领域，尤其涉及一种实现业务信息快速搜索的方法和装置。

背景技术

随着互联网技术的快速发展，越来越多的业务可以通过网络实现，比如：购买保险、购买理财产品等。以保险业务为例，服务提供方通常会将保险相关的数据存储在数据库中，由于保险基础数据的模型较为复杂，在进行理赔、核算等操作时，保险信息的搜索速度较慢，导致操作效率低下。

发明内容

有鉴于此，本申请提供一种实现业务信息快速搜索的方法和装置。

具体地，本申请是通过如下技术方案实现的：

一种实现业务信息快速搜索的方法，所述方法包括：

监听到业务数据库生成新的操作日志，所述业务数据库中业务数据的存储结构为分表存储；

根据所述操作日志更新中间数据库中的业务数据，所述中间数据库中业务数据的存储结构为单表存储；

将所述中间数据库中的业务数据更新到搜索数据库中，所述搜索数据库中业务数据的存储结构与所述中间数据库中业务数据的存储结构相同，所述搜索数据库为业务信息的搜索提供数据库服务。

一种实现业务信息快速搜索的装置，所述装置包括：

日志监听单元，监听到业务数据库生成新的操作日志，所述业务数据库中业务数据的存储结构为分表存储；

第一更新单元，根据所述操作日志更新中间数据库中的业务数据，所述中间数据库中业务数据的存储结构为单表存储；

第二更新单元，将所述中间数据库中的业务数据更新到搜索数据库中，所述搜索数据库中业务数据的存储结构与所述中间数据库中业务数据的存储结构相同，所述搜索数据库为业务信息的搜索提供数据库服务。

由以上描述可以看出，本申请通过对业务数据库操作日志的监听，可以在业务数据库中业务数据更新时，及时将更新的数据同步到单表存储结构的中间数据库中，进而及时同步到单表存储结构的搜索数据库中。由单表存储结构的搜索数据库提供业务信息的搜索服务，可以大大提高业务信息的搜索效率，同时，无需修改业务数据库的存储结构，方便业务数据的处理与维护。

附图说明

图1是本申请一示例性实施例示出的一种实现业务信息快速搜索的方法的流程示意图。

图2是本申请一示例性实施例示出的一种实现业务信息快速搜索的方法的组网架构图。

图3是本申请一示例性实施例示出的一种用于实现业务信息快速搜索的装置的一结构示意图。

图4是本申请一示例性实施例示出的一种实现业务信息快速搜索的装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

图1是本申请一示例性实施例示出的一种实现业务信息快速搜索的方法的流程示意图。

请参考图1，所述实现业务信息快速搜索的方法可以应用在服务提供商部署的服务器或者服务器集群中，包括有以下步骤：

步骤101，监听到业务数据库生成新的操作日志，所述业务数据库中业务数据的存储结构为分表存储。

在本实施例中，所述业务数据库为服务提供方部署的用于存储业务数据的数据库，所述业务数据库中业务数据的存储结构通常为分表存储，方便业务的处理与维护。以保险业务为例，业务数据库中的保险信息可分别存储在多张不同的表中，比如：以投保人为维度的表1，以保险机构为维度的表2等。举例来说，假设新增一笔保单，该保单对应的信息会以投保人为维度存储到表1中，表1通常还会包括受益人、保单号等信息，此外，该保单对应的信息还会以保险机构为维度存储到表2中，表2通常也会包括保单号，另外还会包括保险机构的地址、电话、负责人等信息。

在本实施例中，服务器可以对业务数据库的操作日志进行监听，以MYSQL为例，所述操作日志可以为binlog，用于描述数据的更改。换言之，当业务数据库中的数据更新时，会对应生成一条binlog。在本步骤中，通过对业务数据库binlog的监听，以及时获知业务数据的更新。

步骤102，根据所述操作日志更新中间数据库中的业务数据，所述中间数据库中业务数据的存储结构为单表存储。

基于前述步骤101，在监听到新的操作日志后，可以根据所述操作日志更新中间数据库中的业务数据。其中，所述中间数据库可用于存储业务数据，所述中间数据库中业务数据的存储结构是单表存储，即所有业务数据均可以存储到一张表中。

具体地，在本实施例中，在监听到新的操作日志后，可以先解析所述操作日志，并生成对应所述操作日志的数据操作记录，比如：可以按照行的维度生成一行或多行单条数据record，其中，每条数据record均可标注数据的操作类型(insert、update或delete)。根据所述数据操作记录，服务器可以更新中间数据库中的业务数据。

在本实施例中，由于业务数据库可能存在并发的更新操作，为确保数据一致性，可以在业务数据库的数据库表中设置一个特定的字段，用于存储更新顺序标识，所述更新顺序标识的初始值可以为0，每次数据更新，均可将对应的更新顺序标识加1。在本例中，在根据操作日志更新中间数据库中的业务数据时，可以先获取操作日志中携带的更新顺序标识，进而可以按照更新顺序标识从小到大的顺序依次进行中间数据库中的业务数据的更新操作，以确保业务数据的一致性。

需要说明的是，本申请执行实现业务信息快速搜索的方法的服务器通常与所述业务数据库属于同一业务平台，以保险业务为例，可均属于保险平台。所述服务器可以理解业务的相关逻辑，基于业务数据库中的操作日志，可以将业务数据由分表的业务数据库更新到单表的中间数据库中。

步骤103，将所述中间数据库中的业务数据更新到搜索数据库中，所述搜索数据库中业务数据的存储结构与所述中间数据库中业务数据的存储结构相同，所述搜索数据库为业务信息的搜索提供数据库服务。

在本实施例中，所述搜索数据库可为业务搜索提供数据库服务，换言之，当用户搜索业务相关的数据时，搜索请求会被发送至所述搜索数据库中，而非原始的业务数据库。其中，所述搜索数据库中业务数据的存储结构与中间数据库中业务数据的存储结构相同，均为单表存储。

在本实施例中，当中间数据库中的业务数据更新时，可以实时将对应的数据同步更新到所述搜索数据库中，以确保业务信息搜索的实时性与准确性，比如：也可以根据中间数据库的操作日志更新搜索数据库，具体地，可以在监听到中间数据库生成新的操作日志时，根据该新的操作日志更新搜索数据库中的业务数据。

由以上描述可以看出，本申请通过对业务数据库操作日志的监听，可以在业务数据库中业务数据更新时，及时将更新的数据同步到单表存储结构的中间数据库中，进而及时同步到单表存储结构的搜索数据库中。由单表存储结构的搜索数据库提供业务信息的搜索服务，可以大大提高业务信息的搜索效率，同时，无需修改业务数据库的存储结构，方便业务数据的处理与维护。

下面结合具体的应用场景来描述本申请的实现过程。

请参考图2所示的组网架构，以保险业务为例，保险数据库是保险业务类信息的源数据库，用于存储保单的相关信息。具体地，当新增保单、保单修改时，所述保单相关的数据会被存储到保险数据库中。所述保险数据库的存储结构为分表存储结构，与保险相关的数据会被存放在多张数据表中。较为典型的，可以包括以人为维度的数据库表，比如：可以以投保人为维度，也可以以被保人、受益人等人为维度，还可以包括以保险机构为维度的数据库表，比如：中国人寿保险表、中国平安保险表等。假设，新增了一份保单，那么该保单对应的保险相关数据会被存储到多张数据库表中。采用分表形式的存储结构，可以方便保险业务的处理与维护，比如：在修改保险机构信息时，相应修改与该保险机构对应的数据库表即可，无需全局进行修改。然而，采用这样的存储方式，在面临实时的保险信息搜索时，由于要在多张表中反复搜索，导致搜索速度较慢，搜索效率低下。

针对上述问题，请继续参考图2，执行实现业务信息快速搜索的方法的服务器可以监听保险数据库中的操作日志，当监听到新的操作日志时，可以解析所述操作日志，生成对应的数据操作记录，并基于所述数据操作记录以增量的方式更新中间数据库中的保险数据。其中，所述中间数据库中保险数据的存储结构为单表存储，换言之，在中间数据库中，保险数据均可存储到一张数据库表中。

接着，服务器还可以在中间数据库中的保险数据更新时，通过增量的方式将保险数据同步更新到搜索数据库中，所述搜索数据库中保险数据的更新基本上可以做到与保险数据库中保险数据的同步实时更新。所述搜索数据库中保险数据的存储结构也是单表存储，搜索速度较快。对于搜索数据库而言，无需理解保险业务，根据中间数据库保险数据的更新同步更新即可。

在本例中，当用户通过客户端查询保险数据时，查询请求可以被发送至所述搜索数据库，比如：用户想要查询16年度中国人寿的保单总量，搜索数据库根据索引信息“16年度”“保单总量”可以在数据库表中快速搜索到对应的数据，进而返回给客户端，实现保险数据的快速搜索。

可选的，请继续参考图2，在同步增量更新的基础上，为确保搜索数据库与保险数据库中保险数据的一致性，还可以按照预设的时间周期，以全量的方式更新搜索数据库中的保险数据，比如：可以在每天0时，将保险数据库中的保险数据全量同步到搜索数据库中。

可选的，在另一个例子中，也可以通过异步操作将中间数据库中的保险数据更新到搜索数据库中，比如：可以监听中间数据库的binlog，当监听到中间数据库生成新的一条binlog时，可以将该binlog发送给搜索数据库，以供搜索数据库异步更新保险数据。采用异步更新的方式，可以实现与搜索数据库的解耦，减少对搜索数据库的依赖。

可选的，本例还支持保险数据的补偿更新。在实际应用中，由于网络故障、服务器故障等原因，可能会导致保险数据无法及时更新，甚至丢失等问题。在本例中，管理员可以监控搜索数据库中的保险数据更新时间，但确定保险数据没有及时更新时，可以通过补偿更新指令进行报销数据的补偿更新。举例来说，假设在某天上午10时，管理员发现搜索数据库中保险数据仅更新至9:55分，管理员进而可以下发补偿更新指令，并在该补偿更新指令中指定补偿时段“当天9:55至10:00”，基于该补偿更新指令，服务器可以从保险数据库中获取匹配所述补偿时段的操作日志，进而可以根据该操作日志进行保险数据的补偿更新。

在另一个例子中，服务器还可以缓存操作日志对应的数据操作记录，当接收到补偿更新指令时，可以从缓存中获取匹配所述补偿时段的数据操作记录，进而可以根据所述数据操作记录进行报销数据的补偿更新，无需再次进行操作日志的解析，提高了补偿更新的效率。

在实际应用中，对于实时性搜索要求较高的业务，还可以设置专门的进程来监控搜索数据库中业务数据的更新，当确定搜索数据库中业务数据的未更新的时长到达预设的时长时，可以自动触发补偿更新指令的发送，本申请对此不作特殊限制。

需要说明的是，本申请提供的实现业务信息快速搜索的方案不仅局限于保险信息的搜索，还可以应用到电子交易的账单搜索、专利信息的搜索等应用场景，本申请对此也不作特殊限制。

与前述实现业务信息快速搜索的方法的实施例相对应，本申请还提供了实现业务信息快速搜索的装置的实施例。

本申请实现业务信息快速搜索的装置的实施例可以应用在服务器上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在服务器的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图3所示，为本申请实现业务信息快速搜索的装置所在服务器的一种硬件结构图，除了图3所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的服务器通常根据该服务器的实际功能，还可以包括其他硬件，对此不再赘述。

图4是本申请一示例性实施例示出的一种实现业务信息快速搜索的装置的框图。

请参考图4，所述实现业务信息快速搜索的装置300可以应用在前述图3所示的服务器中，包括有：日志监听单元301、第一更新单元302、第二更新单元303、缓存单元304、补偿更新单元305以及全量同步单元306。

其中，日志监听单元301，监听到业务数据库生成新的操作日志，所述业务数据库中业务数据的存储结构为分表存储；

第一更新单元302，根据所述操作日志更新中间数据库中的业务数据，所述中间数据库中业务数据的存储结构为单表存储；

第二更新单元303，将所述中间数据库中的业务数据更新到搜索数据库中，所述搜索数据库中业务数据的存储结构与所述中间数据库中业务数据的存储结构相同，所述搜索数据库为业务信息的搜索提供数据库服务。

可选的，所述第一更新单元302，具体解析所述操作日志，并生成对应所述操作日志的数据操作记录；根据所述数据操作记录更新中间数据库中的业务数据。

缓存单元304，缓存所述数据操作记录；

补偿更新单元305，在接收到补偿更新指令时，获取所述补偿更新指令指定的补偿时段；获取匹配所述补偿时段的数据操作记录；根据获取到的所述数据操作记录对中间数据库中的业务数据进行补偿更新。

全量同步单元306，按照预设的时间周期将所述业务数据库中的业务数据全量同步到所述搜索数据库中。

可选的，所述第一更新单元302，具体按照所述操作日志中的更新顺序标识从小到大的顺序依次进行中间数据库中的业务数据的更新操作。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

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

Claims (10)

1.一种实现业务信息快速搜索的方法，其特征在于，所述方法包括：

监听到业务数据库生成新的操作日志，所述业务数据库中业务数据的存储结构为分表存储；

根据所述操作日志更新中间数据库中的业务数据，所述中间数据库中业务数据的存储结构为单表存储；

将所述中间数据库中的业务数据更新到搜索数据库中，所述搜索数据库中业务数据的存储结构与所述中间数据库中业务数据的存储结构相同，所述搜索数据库为业务信息的搜索提供数据库服务。

2.根据权利要求1所述的方法，其特征在于，所述根据所述操作日志更新中间数据库中的业务数据，包括：

解析所述操作日志，并生成对应所述操作日志的数据操作记录；

根据所述数据操作记录更新中间数据库中的业务数据。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

缓存所述数据操作记录；

在接收到补偿更新指令时，获取所述补偿更新指令指定的补偿时段；

获取匹配所述补偿时段的数据操作记录；

根据获取到的所述数据操作记录对中间数据库中的业务数据进行补偿更新。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

按照预设的时间周期将所述业务数据库中的业务数据全量同步到所述搜索数据库中。

5.根据权利要求1所述的方法，其特征在于，所述根据所述操作日志更新中间数据库中的业务数据，包括：

按照所述操作日志中的更新顺序标识从小到大的顺序依次进行中间数据库中的业务数据的更新操作。

6.一种实现业务信息快速搜索的装置，其特征在于，所述装置包括：

日志监听单元，监听到业务数据库生成新的操作日志，所述业务数据库中业务数据的存储结构为分表存储；

第一更新单元，根据所述操作日志更新中间数据库中的业务数据，所述中间数据库中业务数据的存储结构为单表存储；

第二更新单元，将所述中间数据库中的业务数据更新到搜索数据库中，所述搜索数据库中业务数据的存储结构与所述中间数据库中业务数据的存储结构相同，所述搜索数据库为业务信息的搜索提供数据库服务。

7.根据权利要求6所述的装置，其特征在于，

所述第一更新单元，具体解析所述操作日志，并生成对应所述操作日志的数据操作记录；根据所述数据操作记录更新中间数据库中的业务数据。

8.根据权利要求7所述的装置，其特征在于，所述装置还包括：

缓存单元，缓存所述数据操作记录；

补偿更新单元，在接收到补偿更新指令时，获取所述补偿更新指令指定的补偿时段；获取匹配所述补偿时段的数据操作记录；根据获取到的所述数据操作记录对中间数据库中的业务数据进行补偿更新。

9.根据权利要求6所述的装置，其特征在于，所述装置还包括：

全量同步单元，按照预设的时间周期将所述业务数据库中的业务数据全量同步到所述搜索数据库中。

10.根据权利要求6所述的装置，其特征在于，

所述第一更新单元，具体按照所述操作日志中的更新顺序标识从小到大的顺序依次进行中间数据库中的业务数据的更新操作。