CN108241758A - 数据查询方法及相关设备 - Google Patents

Abstract

本申请提供了一种数据查询方法，该方法在接收到对用户数据的查询请求后，并非仅在搜索引擎的非易失性存储装置中查询符合查询请求的用户数据集合，还需要在临时内存中查询符合查询请求的用户数据集合。临时内存中存储有搜索引擎中被执行变更操作的用户数据，且用户数据具有变更操作的操作类型，根据操作类型对查询到的两个用户数据集合进行处理，得到查询结果。因此相较于现有技术而言，本申请并不需要等待搜索引擎的更新操作，可以直接从临时内存及搜索引擎的存储装置中查询到用户数据，数据查询效率较高。另外，本申请还提供了数据查询装置及相关存储介质，用以保证所述方法在实际中的应用及实现。

Description

数据查询方法及相关设备

技术领域

本申请涉及搜索技术领域，更具体地，是数据查询方法及相关设备。

背景技术

搜索引擎，作为一种数据查询工具，可以根据查询条件从海量的数据中检索出需要的数据。为了实现快速检索，搜索引擎可以预先对海量的数据进行预先处理，预先处理包括但不局限于：将原始数据预先读取至搜索引擎中、将原始数据按照一定数据格式进行整理并存储、为整理后的数据建立索引等。

在实际应用中，原始数据可能会发生变化，一旦原始数据发生变化，搜索引擎便需要基于原始数据的变化来更新其内部存储的对应数据，并为更新后的数据重新建立索引。搜索引擎依据需要查询数据时，在更新后的数据中进行检索，以保证查询结果的准确性。但是，该种数据查询过程不够及时快速。

发明内容

有鉴于此，本申请提供了一种数据查询方法，用于提高从搜索引擎中查询数据的效率。

为实现所述目的，本申请提供的技术方案如下：

第一方面，本申请提供了一种数据查询方法，包括：

接收对用户数据的查询请求；

在预先设置的临时内存中，查询符合所述查询请求的第一用户数据集合；其中所述临时内存中存储有所述用户数据中被执行变更操作的用户数据，以及所述变更操作的操作类型；

在搜索引擎的非易性存储装置中，查询符合所述查询请求的第二用户数据集合；

根据所述第一用户数据集合中用户数据的操作类型，对所述第一用户数据集合及所述第二用户数据集合执行所述操作类型表示的处理操作，得到查询结果。

第二方面，本申请提供了一种数据查询装置，包括：

查询请求接收单元，用于接收对用户数据的查询请求；

第一数据查询单元，用于在预先设置的临时内存中，查询符合所述查询请求的第一用户数据集合；其中所述临时内存中存储有所述用户数据中被执行变更操作的用户数据，以及所述变更操作的操作类型；

第二数据查询单元，用于在搜索引擎的非易性存储装置中，查询符合所述查询请求的第二用户数据集合；

数据集合处理单元，用于根据所述第一用户数据集合中用户数据的操作类型，对所述第一用户数据集合及所述第二用户数据集合执行所述操作类型表示的处理操作，得到查询结果。

第三方面，本申请提供了一种存储介质，其特征在于，所述存储介质存储有多条指令，所述指令适于处理器进行加载，以执行权利要求1至9任一项所述的数据查询方法中的步骤。

由以上技术方案可知，本申请提供了一种数据查询方法，该方法在接收到对用户数据的查询请求后，并非仅在搜索引擎的非易失性存储装置中查询符合查询请求的用户数据集合，还需要在临时内存中查询符合查询请求的用户数据集合。临时内存中存储有搜索引擎中被执行变更操作的用户数据，且用户数据具有变更操作的操作类型，根据操作类型对查询到的两个用户数据集合进行处理，得到查询结果。因此相较于现有技术而言，本申请并不需要等待搜索引擎的更新操作，可以直接从临时内存及搜索引擎的存储装置中查询到用户数据，数据查询效率较高。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为现有技术中搜索引擎对存储单元中的数据的修改流程图；

图2为本申请提供的数据查询方法的一个流程图；

图3为本申请提供的数据查询方法的一种场景示意图；

图4为本申请提供的临时内存存储用户数据的一种场景示意图；

图5为本申请提供的数据查询装置的一种结构示意图；

图6为本申请提供的数据查询装置的另一种结构示意图；

图7为本申请提供的数据查询装置的又一种结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

搜索引擎在接收到查询请求后，可以根据查询请求中的查询条件，从海量的原始用户数据中查询符合查询条件的用户数据。需要说明的是，原始用户数据存储在数据库服务器中，为了实现快速查询，搜索引擎会将原始用户数据读取至搜索引擎中，将原始用户数据按照自身规定的数据格式进行转换，并将转换后的用户数据存储至搜索引擎的存储单元中。该存储单元为非易失性存储单元，因此该存储动作即将用户数据在搜索引擎中持久化。

原始用户数据可能基于用户请求等原因需要被修改，因此搜索引擎的存储单元中的用户数据也需要被修改，才能保证所查询的用户数据的准确性。但如果接收到查询请求需要根据查询请求查询数据时，搜索引擎有更新需要执行，则需要等待搜索引擎将更新执行完毕才能进行搜索。并且基于搜索引擎中数据存储方式的原因，搜索引擎对存储单元中数据的更新方式也较为繁琐复杂，从而导致更新过程较慢，进而降低了数据查询的效率。

具体来看，搜索引擎中数据存储方式为，将多条用户数据作为一个整体存储在存储单元中，且一条用户数据中可能包含多个信息项，如果需要对整体中的某个信息项进行修改时，需要将多条用户数据整体全部从存储单元中读取出来，再从中查找到该信息项对应的用户数据，再从该用户数据中查找到该信息项，修改该信息项后，再将该多条用户数据重新写入存储单元中。

以下结合具体应用场景说明搜索引擎在数据查询方面的问题。在即时通信的应用场景中，一即时通信服务器内存储有大量的通信群组，每个通信群组包括多个用户，每个用户可能包含用户标识、所在群组号、用户昵称、个人信息等多项信息。为了快速搜索，搜索引擎将即时通信服务器中的用户数据整理后存储至自身的存储单元中，其中同一通信群组的用户数据作为一个整体保存在一个数组中，不同的通信群组的用户数据保存在不同的数组中。

例如图1所示，搜索引擎的存储单元中存储有通信群组1，通信群组1中包括N个用户。如果通信群组1中的用户A修改了用户昵称，则搜索引擎需要将存储单元中该用户所在的通信数组1中的用户数据全部读取出来，查找到该成员的用户数据，修改其中的用户昵称字段，再将修改之后的多条用户数据存储至搜索引擎的存储单元，并重新对存储单元建立索引。如果此期间正好有某用户请求查询该通信群组中的成员信息，则需要等待上述更新过程完成后，搜索引擎才能依据更新之后的信息进行查询，从而导致查询效率较低。

因此，为了提高搜索引擎的数据查询效率，本申请提供了一种数据查询方法。见图2，其示出了数据查询方法的具体流程，包括如下步骤S201～S204。

S201：接收对用户数据的查询请求。

其中，该查询请求可以是由用户发送的，也可以由其他设备发送的，也可以是由搜索引擎自身生成的。

S202：在预先设置的临时内存中，查询符合查询请求的第一用户数据集合；其中临时内存中存储有用户数据中被执行变更操作的用户数据，以及变更操作的操作类型。

其中，本申请预先设置有临时内存，临时内存中保存有对用户数据的变更操作以及变更操作的具体类型。其中变更操作包括但不局限于：增加、删除及修改。具体地，如果需要对搜索引擎的存储单元内的用户数据进行修改，首先将修改关联的用户数据存储在临时内存中。

具体地，接收用户数据变更请求；在数据库服务器存储的用户数据中，查询与该用户数据变更请求对应的用户数据；将该用户数据存储至临时内存中，并将该用户数据变更请求中的操作类型存储至临时内存中。

用户数据的变更请求可以是由用户设备生成的，变更请求用于请求对用户数据进行修改，对用户数据的修改可以包括但不局限于：增加、删除及修改。例如某个用户申请进入群组，又如群组中的某个用户发送退出群组的指令，再如某个用户发送修改用户昵称的指令，等等。用户的操作指令中包含有用户标识，根据用户的操作指令可以生成用户数据变更请求，用户数据变更请求中也包含有用户标识。

例如若用户申请进入群组，则用户数据变更请求中包含有该用户的标识；又如若用户退出群组，则用户数据变更请求中包含有该用户的标识；再如若用户修改昵称，则用户数据变更请求中包含有该用户的标识以及用户修改之后的昵称。

当本方法接收到该用户数据变更请求后，提取用户数据变更请求中的用户标识。用户的原始数据存储在数据库服务器中，本方法根据用户标识从数据库服务器存储的用户数据中，查询用户标识所对应的用户数据，并将这些用户数据存储到临时内存中。这样，临时内存中便包含有该用户的完整用户信息，后续根据用户数据查询请求在临时内存中查询用户数据时，可以查询到该用户的各项信息。

需要说明的是，本方法是在用户数据变更请求的操作类型为非增加类型时，才会从数据库服务器中获得用户数据保存至临时内存中。若用户数据变更请求的操作类型为增加，则用户数据变更请求中会包含有用户数据，此种情况下只需将用户数据变更请求中的用户数据存储至临时内存即可。

可见，临时内存中保存的是需要被执行变更操作的用户数据，这些用户数据并未直接被变更至搜索引擎的存储单元中，而是先存储至临时内存中。需要说明的是，临时内存中除了包含有用户数据，还包含有对用户数据的操作类型。用户数据及变更操作类型可以以元信息的结构存储在数组中，数组存储在临时内存中。

临时内存中保存有被变更的用户数据，本方法在接收到用户数据的查询请求后，在临时内存中查询符合查询请求的用户数据。具体地，查询请求中包含有查询条件，本步骤在查询请求中提取查询条件，根据查询条件在临时内存进行检索。检索到的用户数据集合可能为空，可能包含有一条用户数据，也可能包含有多条用户数据。为了便于与步骤S203中查询到的用户数据集合区分，可以将该用户数据集合称为第一用户数据集合。

为了便于理解，结合具体的应用场景进行说明。以应用场景为即时通信为例，即时通信群组中包含有多个成员，成员具有用户昵称。用户可以在搜索栏中输入某个成员昵称，根据用户的检索操作，生成包含该成员昵称的查询请求，其中成员昵称作为查询条件，查询条件也可以称为查询对象。临时内存包含的用户数据中可以包括查询条件对应的信息项，依据查询条件在信息项中进行检索，检索到符合查询条件的信息项，将该信息项对应的用户数据作为第一用户数据集合。

S203：在搜索引擎的非易性存储装置中，查询符合查询请求的第二用户数据集合。

其中，除了在临时内存中检索用户数据，还需要在搜索引擎自身的存储装置中进行检索。需要说明的是，搜索引擎的存储装置与内存不同，为非易失性存储装置，用于永久存储从数据库服务器中复制出来的用户数据，这些用户数据为了便于搜索引擎进行快速检索。

与在临时内存中检索的方式相同，本步骤在查询请求中提取查询条件，在搜索引擎自身的存储装置中，查询符合查询条件的用户数据集合，为了与上述查询到的第一用户数据集合进行区分，可以将此处的用户数据集合称为第二用户数据集合。

需要说明的是，步骤S202与本步骤的检索方式可以为精确检索，也可以为模糊检索。精索检索指的是，查询条件并非与用户数据的信息项完全匹配，例如查询条件为用户昵称为“卡拉是条狗”，昵称与该查询条件完全相同的用户数据才能被确定为满足条件的用户数据。相反，模糊查询指的是，查询条件并非与用户数据的信息项完全匹配，仍以上述示例为例，昵称“卡拉是条狗”可以划分为多个单词，只要包含其中任意多个单词的用户数据均可以被确定为满足条件的用户数据。模糊查询方式中，查询条件可以并不包含检索项所归属的信息项，即“卡拉是条狗”并不一定是用户昵称，这种情况下只要用户数据的某信息项中包含“卡拉是条狗”，该条用户数据均可以被确定为满足条件的用户数据。

相对于精确检索，针对同一查询请求模糊检索的方式可以确定出数量更多的用户数据。

S204：根据第一用户数据集合中用户数据的操作类型，对第一用户数据集合及第二用户数据集合执行操作类型表示的处理操作，得到查询结果。

其中，临时内存中的用户数据具有操作类型，操作类型具体指的是对搜索引擎的存储装置中的用户数据所执行的变更操作类型。

由于从临时内存中检索到的用户数据，可能与从搜索引擎的存储装置检索到的用户数据之间存在重复、多余、错误等情况，因此需要根据操作类型，对从临时内存及搜索引擎的存储装置中检索到的用户数据进行处理。

具体地，操作类型可以包括：增加、删除或修改中的任意一项或多项。在处理时，首先合并第一用户数据集合及第二用户数据集合。例如，假设第一用户数据集合包括用户数据D、用户数据A、用户数据B及用户数据B’，假设第二用户数据集合包括用户数据A、用户数据B及用户数据C。在第一用户数据集合中，用户数据D对应的操作类型为增加，用户数据A对应的操作类型为删除，用户数据B及用户数据B’对应的操作类型为修改，将用户数据B修改为B’。需要说明的是，用户数据的修改可以并非完全修改，可以仅修改用户数据中的某一项或多项信息。合并以上两个用户数据集合后得到的集合中包括有用户数据A、用户数据A、用户数据B、用户数据B’、用户数据C、用户数据D。需要说明的是，第一用户数据集合中，用户数据对应的操作类型可以并非包括增加、删除及修改全部三种类型。

由于合集中可能包含有重复的用户数据，因此需要对合集中的用户进行去重操作。具体地，若合集中包含有删除的操作类型对应的用户数据，则删除合集中删除的操作类型对应的用户数据；若合集中包含有修改的操作类型对应的用户数据，则删除合集中删除的操作类型对应的修改前的用户数据。

例如，上述第一用户数据集合中包含的用户数据A对应的操作类型为删除，则需要删除合集中的用户数据A。又如，上述第一用户数据集合中包含的用户数据B及用户数据B’对应的操作类型为修改，则删除修改之前的用户数据B。删除后的合集中包括有用户数据B’、用户数据C、用户数据D。

对合集进行上述处理后，便可以得到查询结果。

由以上技术方案可知，本申请提供了一种数据查询方法，该方法在接收到对用户数据的查询请求后，并非仅在搜索引擎的非易失性存储装置中查询符合查询请求的用户数据集合，还需要在临时内存中查询符合查询请求的用户数据集合。临时内存中存储有搜索引擎中被执行变更操作的用户数据，且用户数据具有变更操作的操作类型，根据操作类型对查询到的两个用户数据集合进行处理，得到查询结果。因此相较于现有技术而言，本申请并不需要等待搜索引擎的更新操作，可以直接从临时内存及搜索引擎的存储装置中查询到用户数据，数据查询效率较高。

并且可以理解的是，临时内存是内存单元，相较于搜索引擎的非易失性存储装置而言在读取速度上具有优势，从临时内存进行检索的效率较高。

为了便于理解本申请提供的技术方案，结合具体的系统架构图进行说明。如图3所示，数据查询装置可以接收到用户设备发送的对用户数据的查询请求，数据查询装置一方面从预设设置的临时内存中，根据查询请求查询第一用户数据集合，另一方面在搜索引擎的存储装置中，根据查询请求查询第二用户数据集合。然后，数据查询装置根据第一用户数据集合中用户数据的操作类型，对两个用户数据集合进行与操作类型对应的操作处理，得到查询结果。需要说明的是，在一种实现方式中，数据查询装置可以部署在应用服务器上。搜索引擎可以具体为但不局限于elasticSearch搜索引擎。

前已述及，临时内存中存储的是搜索引擎中需要被执行变更操作的用户数据，因此需要根据临时内存中的用户数据及用户数据的变更操作类型，对搜索引擎的非易失性存储单元中的用户数据进行处理。

例如假设临时内存中，某条用户数据对应的变更操作类型为增加，则将临时内存中的该条用户数据添加至搜索引擎的非易失性存储装置中。又假设临时内存中，某条用户数据对应的变更操作类型为删除，则该条用户数据从搜索引擎的非易失性存储装置中删除。再假设临时内存中，某条用户数据对应的变更操作类型为修改，则将搜索引擎的非易失性存储装置中的该条用户数据进行修改。

更进一步地，在根据临时内存中的用户数据及用户数据的变更操作类型，对搜索引擎的非易失性存储单元中的用户数据进行处理之前，还可以判断临时内存中的用户数据是否满足预设条件，若满足才执行根据临时内存中的用户数据及用户数据的变更操作类型，对搜索引擎的非易失性存储单元中的用户数据进行处理的步骤。

其中，预设条件可以包括时长条件或数据量条件。时长条件可以具体为第一条用户数据存储的时间点到当前时间点的时长阈值如1小时，则当临时内存中第一条用户数据存储的时间点到当前时间点的时长达到该时长阈值时，表示临时内存中的用户数据满足时长条件。存储量条件可以具体为临时内存中存储数据的数据量阈值如1M，则当临时内存中存储数据的数据量达到该数据量阈值时，表示临时内存中的用户数据满足数据量条件。

为保证临时内存中数据的安全性，可以将临时内存中的内容存储至非易失性存储单元中，也即表示需要将临时内存中的数据进行持久化。如图4所示，数据查询装置接收到用户设备发送的用户数据变更请求后，在数据库服务器存储的用户数据中，查询与用户数据变更请求对应的用户数据，将用户数据存储至临时内存中，并将用户数据变更请求中的操作类型存储至临时内存中，然后将临时内存中的用户数据及操作类型存储至非易失性存储单元如数据库中。这样，若临时内存出现故障，可以从数据库中查询到临时内存中的用户数据，保证临时内存中的用户数据不会丢失。

见图5，其示出了本申请提供的一种数据查询装置的结构，具体包括：查询请求接收单元501、第一数据查询单元502、第二数据查询单元503及数据集合处理单元504。

查询请求接收单元501，用于接收对用户数据的查询请求；

第一数据查询单元502，用于在预先设置的临时内存中，查询符合查询请求的第一用户数据集合；其中临时内存中存储有用户数据中被执行变更操作的用户数据，以及变更操作的操作类型；

第二数据查询单元503，用于在搜索引擎的非易性存储装置中，查询符合查询请求的第二用户数据集合；

数据集合处理单元504，用于根据第一用户数据集合中用户数据的操作类型，对第一用户数据集合及第二用户数据集合执行操作类型表示的处理操作，得到查询结果。

在一种实现方式中，操作类型包括：增加、删除或修改中的任意一项或多项。则数据集合处理单元504可以包括：合并子单元、删除子单元及修改子单元。

合并子单元，用于合并第一用户数据集合及第二用户数据集合；

删除子单元，用于若合集中包含有删除的操作类型对应的用户数据，则删除合集中删除的操作类型对应的用户数据；

修改子单元，用于若合集中包含有修改的操作类型对应的用户数据，则删除合集中删除的操作类型对应的修改前的用户数据。

见图6，其示出了本申请提供的数据查询装置的另一种结构。如图6所示，该数据查询装置在图5所示的基础上，还包括临时内存处理单元505。临时内存处理单元505，用于存储临时内存中的用户数据。

临时内存处理单元505具体包括：请求接收子单元、数据查询子单元及数据存储子单元。

请求接收子单元，用于接收用户数据变更请求；

数据查询子单元，用于在数据库服务器存储的用户数据中，查询与用户数据变更请求对应的用户数据；

数据存储子单元，用于将用户数据存储至临时内存中，并将用户数据变更请求中的操作类型存储至临时内存中。

见图7，其示出了本申请提供的数据查询装置的另一种结构。如图7所示，该数据查询装置在图5所示的基础上，还包括用户数据处理单元506及处理条件判断单元507。

用户数据处理单元506，用于依据临时内存中的用户数据及用户数据的变更操作的操作类型，对搜索引擎中非易失性存储单元中的用户数据进行处理。

处理条件判断单元507，用于在依据临时内存中的用户数据及用户数据的变更操作的操作类型，对搜索引擎中非易失性存储单元中的用户数据进行处理之前，判断临时内存中的用户数据是否满足预设条件，其中预设条件包括时长条件或数据量条件；若满足，则触发用户数据处理单元。

另外，本申请还提供了一种存储介质，所述存储介质存储有多条指令，所述指令适于处理器进行加载，以执行以上与数据查询方法相关的步骤。具体来看，与数据查询方法相关的步骤包括以下：

查询请求接收步骤，用于接收对用户数据的查询请求；

第一数据查询步骤，用于在预先设置的临时内存中，查询符合查询请求的第一用户数据集合；其中临时内存中存储有用户数据中被执行变更操作的用户数据，以及变更操作的操作类型；

第二数据查询步骤，用于在搜索引擎的非易性存储装置中，查询符合查询请求的第二用户数据集合；

数据集合处理步骤，用于根据第一用户数据集合中用户数据的操作类型，对第一用户数据集合及第二用户数据集合执行操作类型表示的处理操作，得到查询结果。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括上述要素的过程、方法、物品或者设备中还存在另外的相同要素。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种数据查询方法，其特征在于，包括：

接收对用户数据的查询请求；

在预先设置的临时内存中，查询符合所述查询请求的第一用户数据集合；其中所述临时内存中存储有所述用户数据中被执行变更操作的用户数据，以及所述变更操作的操作类型；

在搜索引擎的非易性存储装置中，查询符合所述查询请求的第二用户数据集合；

根据所述第一用户数据集合中用户数据的操作类型，对所述第一用户数据集合及所述第二用户数据集合执行所述操作类型表示的处理操作，得到查询结果。

2.根据权利要求1所述的数据查询方法，其特征在于，所述操作类型包括：增加、删除或修改中的任意一项或多项；

所述根据所述第一用户数据集合中用户数据的操作类型，对所述第一用户数据集合及所述第二用户数据集合执行所述操作类型表示的处理操作，得到查询结果，包括：

合并所述第一用户数据集合及所述第二用户数据集合；

若合集中包含有删除的操作类型对应的用户数据，则删除所述合集中所述删除的操作类型对应的用户数据；

若合集中包含有修改的操作类型对应的用户数据，则删除所述合集中所述删除的操作类型对应的修改前的用户数据。

3.根据权利要求1所述的数据查询方法，其特征在于，所述临时内存中用户数据的存储过程包括：

接收用户数据变更请求；

在数据库服务器存储的用户数据中，查询与所述用户数据变更请求对应的用户数据；

将所述用户数据存储至临时内存中，并将所述用户数据变更请求中的操作类型存储至所述临时内存中。

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

依据所述临时内存中的用户数据及用户数据的变更操作的操作类型，对所述搜索引擎中非易失性存储单元中的用户数据进行处理。

5.根据权利要求4所述的数据查询方法，其特征在于，在依据所述临时内存中的用户数据及用户数据的变更操作的操作类型，对所述搜索引擎中非易失性存储单元中的用户数据进行处理之前，还包括：

判断所述临时内存中的用户数据是否满足预设条件，其中所述预设条件包括时长条件或数据量条件；

若满足，则执行依据所述临时内存中的用户数据及用户数据的变更操作的操作类型，对所述搜索引擎中非易失性存储单元中的用户数据进行处理的步骤。

6.一种数据查询装置，其特征在于，包括：

查询请求接收单元，用于接收对用户数据的查询请求；

第一数据查询单元，用于在预先设置的临时内存中，查询符合所述查询请求的第一用户数据集合；其中所述临时内存中存储有所述用户数据中被执行变更操作的用户数据，以及所述变更操作的操作类型；

第二数据查询单元，用于在搜索引擎的非易性存储装置中，查询符合所述查询请求的第二用户数据集合；

数据集合处理单元，用于根据所述第一用户数据集合中用户数据的操作类型，对所述第一用户数据集合及所述第二用户数据集合执行所述操作类型表示的处理操作，得到查询结果。

7.根据权利要求6所述的数据查询装置，其特征在于，所述操作类型包括：增加、删除或修改中的任意一项或多项；

所述数据集合处理单元包括：

合并子单元，用于合并所述第一用户数据集合及所述第二用户数据集合；

删除子单元，用于若合集中包含有删除的操作类型对应的用户数据，则删除所述合集中所述删除的操作类型对应的用户数据；

修改子单元，用于若合集中包含有修改的操作类型对应的用户数据，则删除所述合集中所述删除的操作类型对应的修改前的用户数据。

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

临时内存处理单元，用于存储临时内存中的用户数据；

临时内存处理单元包括：

请求接收子单元，用于接收用户数据变更请求；

数据查询子单元，用于在数据库服务器存储的用户数据中，查询与所述用户数据变更请求对应的用户数据；

数据存储子单元，用于将所述用户数据存储至临时内存中，并将所述用户数据变更请求中的操作类型存储至所述临时内存中。

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

用户数据处理单元，用于依据所述临时内存中的用户数据及用户数据的变更操作的操作类型，对所述搜索引擎中非易失性存储单元中的用户数据进行处理。

10.一种存储介质，其特征在于，所述存储介质存储有多条指令，所述指令适于处理器进行加载，以执行权利要求1至9任一项所述的数据查询方法中的步骤。