CN110019255A - 数据查询方法、装置、服务器及存储介质 - Google Patents

Abstract

本公开实施例提供一种数据查询方法、装置及服务器，所述方法包括：监控数据库中数据的更新情况；根据监控到的更新情况，更新存储在缓存区域中的统计数据，所述统计数据包括利用所述数据统计的符合预设查询需求的数据；接收与所述预设查询需求相关的查询请求，从所述缓存区域中存储的统计数据中，获取符合所述查询请求的统计信息并输出。本公开实施例可以在接收到查询请求中，可以从缓存区域中存储的统计数据中快速获取到符合查询请求的统计数据。

Description

数据查询方法、装置、服务器及存储介质

技术领域

本公开实施例涉及互联网技术领域，尤其涉及数据查询方法、装置、服务器及存储介质。

背景技术

数据库是指长期储存在设备内、按照一定数据结构组织的、可共享的数据集合。大多数情况下，数据库中数据存储于硬盘等持久化的存储介质上，数据处理人员通过配置某些数据库管理系统对数据进行管理，例如MySQL或Oracle等等。在需要查询某些信息时，可以根据查询请求，基于数据库管理系统的查询方式，从存储介质上读取数据，并基于一定运算，最终查询出满足查询请求的信息。当数据库中的数据量达到千万级别或亿级别，往往需要几百毫秒甚至更长时间才能返回结果。

发明内容

为克服相关技术中存在的问题，本公开实施例提供了数据查询方法、装置、服务器及存储介质。

一种数据查询方法，所述方法包括：

监控数据库中数据的更新情况；

根据监控到的更新情况，更新存储在缓存区域中的统计数据，所述统计数据包括利用所述数据统计的符合预设查询需求的数据；

接收与所述预设查询需求相关的查询请求，从所述缓存区域中存储的统计数据中，获取符合所述查询请求的统计信息并输出。

可选的，所述缓存区域包括设置在内存中的缓存区域。

可选的，所述监控数据库中数据的更新情况，包括：

获取所述数据库更新数据后产生的日志，通过所述日志事件监控数据库中数据的更新情况。

可选的，所述获取所述数据库更新数据后产生的日志事件，包括：

模拟一所述数据库的从属数据库，基于数据库交互协议，利用所述模拟的从属数据库获取所述日志事件。

可选的，每条所述统计数据包括数据标识以及至少一类统计信息，所述统计数据采用键值key-value格式进行存储，其中，记录数据标识的字段作为主键，其他字段记录所述至少一类统计信息。

可选的，所述根据监控到的更新情况，更新存储在缓存区域中的统计数据，包括：

根据监控到的更新情况，确定需更新的数据标识和统计信息，从缓存区域中查找所述需更新的数据标识后，在对应的其他字段更新统计信息。

可选的，所述方法应用于网约车服务端，所述预设查询需求包括用户在设定时间段内与订单相关的统计信息。

可选的，所述用户在设定时间段内与订单相关的统计信息包括用户在所述设定时间段内的订单创建数量和/或成交订单数量；

所述根据监控到的更新情况，更新存储在缓存区域中的统计数据，包括如下一种或多种：

若监控到的更新情况包括增加一条订单创建数据，更新存储在缓存区域中所述订单创建数据对应用户的订单创建数量；

若监控到的更新情况包括订单创建数据的完成状态更新，更新存储在缓存区域中所述订单创建数据对应用户的成交订单数量。

可选的，所述更新存储在缓存区域中所述订单创建数据对应用户的订单创建数量，包括：

根据所述订单创建数据中的用户标识，查找缓存区域中与所述用户标识对应的统计数据；根据所述订单创建数据的创建时刻，对所查找到的统计数据中与所述创建时刻对应的设定时间段内的订单创建数量进行增加。

可选的，所述更新存储在缓存区域中所述订单创建数据对应用户的成交订单数量，包括：

根据所述订单创建数据中的用户标识，查找缓存区域中与所述用户标识对应的统计数据；根据所述订单创建数据的更新时刻，对所查找到的统计数据中与所述更新时刻对应的设定时间段内的成交订单数量进行增加。

一种数据查询装置，所述装置包括：

监控模块，用于：监控数据库中数据的更新情况；

更新模块，用于：根据监控到的更新情况，更新存储在缓存区域中的统计数据，所述统计数据包括利用所述数据统计的符合预设查询需求的数据；

请求处理模块，用于：接收与所述预设查询需求相关的查询请求，从所述缓存区域中存储的统计数据中，获取符合所述查询请求的统计信息并输出。

可选的，所述缓存区域包括设置在内存中的缓存区域。

可选的，所述监控模块，还用于：

获取所述数据库更新数据后产生的日志，通过所述日志事件监控数据库中数据的更新情况。

可选的，所述监控模块，还用于：

模拟一所述数据库的从属数据库，基于数据库交互协议，利用所述模拟的从属数据库获取所述日志事件。

可选的，每条所述统计数据包括数据标识以及至少一类统计信息，所述统计数据采用键值key-value格式进行存储，其中，记录数据标识的字段作为主键，其他字段记录所述至少一类统计信息。

可选的，所述更新模块，还用于：

根据监控到的更新情况，确定需更新的数据标识和统计信息，从缓存区域中查找所述需更新的数据标识后，在对应的其他字段更新统计信息。

可选的，所述方法应用于网约车服务端，所述预设查询需求包括用户在设定时间段内与订单相关的统计信息。

可选的，所述用户在设定时间段内与订单相关的统计信息包括用户在所述设定时间段内的订单创建数量和/或成交订单数量；

所述监控模块，还用于：

若监控到的更新情况包括增加一条订单创建数据，更新存储在缓存区域中所述订单创建数据对应用户的订单创建数量；

若监控到的更新情况包括订单创建数据的完成状态更新，更新存储在缓存区域中所述订单创建数据对应用户的成交订单数量。

可选的，所述监控模块，还用于：

根据所述订单创建数据中的用户标识，查找缓存区域中与所述用户标识对应的统计数据；根据所述订单创建数据的创建时刻，对所查找到的统计数据中与所述创建时刻对应的设定时间段内的订单创建数量进行增加。

可选的，所述监控模块，还用于：根据所述订单创建数据中的用户标识，查找缓存区域中与所述用户标识对应的统计数据；根据所述订单创建数据的更新时刻，对所查找到的统计数据中与所述更新时刻对应的设定时间段内的成交订单数量进行增加。

一种服务器，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：

监控数据库中数据的更新情况；

根据监控到的更新情况，更新存储在缓存区域中的统计数据，所述统计数据包括利用所述数据统计的符合预设查询需求的数据；

接收与所述预设查询需求相关的查询请求，从所述缓存区域中存储的统计数据中，获取符合所述查询请求的统计信息并输出。

一种计算机存储介质，所述存储介质中存储有程序指令，所述程序指令包括：

监控数据库中数据的更新情况；

根据监控到的更新情况，更新存储在缓存区域中的统计数据，所述统计数据包括利用所述数据统计的符合预设查询需求的数据；

接收与所述预设查询需求相关的查询请求，从所述缓存区域中存储的统计数据中，获取符合所述查询请求的统计信息并输出。

本公开实施例的实施例提供的技术方案可以包括以下有益效果：

本公开实施例中，可以根据数据使用方对数据的使用需求，设定一个或多个查询需求，根据预设查询需求，预先利用数据库中存储的数据进行统计，获得统计数据，统计数据存储与缓存区域中，可基于数据库中数据的更新情况对统计数据进行更新。因此，当接收到查询请求中，可以从缓存区域中存储的统计数据中快速获取到符合查询请求的统计数据。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开实施例。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开实施例的实施例，并与说明书一起用于解释本公开实施例的原理。

图1是本公开实施例根据一示例性实施例示出的一种数据查询的运行系统架构的示意图。

图2是本公开实施例根据一示例性实施例示出的一种数据查询方法的流程图。

图3是本公开实施例根据一示例性实施例示出的另一种数据查询方法的流程图。

图4是本公开实施例根据一示例性实施例示出的一种数据查询装置的框图。

具体实施方式

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

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

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

首先对本公开实施例实施例方案的一种运行系统架构进行说明。参见图1所示，本公开实施例实施例方案涉及的实体包括：数据提供方、数据处理方和数据使用方。其中，数据处理方中配置有包括常规的存储区域和缓存区域。

其中，本领域技术人员应该了解的是，本实施例的“缓存区域”是一个相对于“常规的数据存储区域”的概念。常规的存储区域包括设置在磁盘或硬盘等持久化存储的存储介质中的存储区域，而缓存区域可以针对不同的场景，可能具有不同的具体含义，或对应不同的硬件资源。例如，CPU内置缓存、硬盘内置缓存等，均属于硬件本身自带资源，而数据库缓存、浏览器缓存等，则是软件在运行时需要操作系统为其分配一部分硬件资源(例如内存空间，或硬盘空间等)等作为缓存。本公开实施例实施例所提供的方案，是针对特定的数据应用需求提出，而并不需要对“缓存”实际对应的硬件资源进行限定。

图1所示系统的基本工作原理是：数据提供方向数据处理方提供数据，所提供的数据可能包含对已有数据的新增、删除或修改等等。在数据处理方侧，数据提供方所提供的大量的数据，可以称为数据库，数据库是指长期储存在计算机内、有组织的、可共享的数据集合。数据处理方可以采用在硬盘等持久化的存储介质上设置常规的存储区域，将数据存储于该常规的存储区域中。数据处理方通常也会采用某些数据库管理系统对数据进行管理，例如MySQL或Oracle等等。数据处理方根据数据提供方提供的数据，可以利用数据库管理系统，对数据进行增、删或改操作，以执行数据更新。

相关技术中，若数据使用方需要查询某些信息时，数据使用方向数据处理方提交查询请求，数据处理方根据查询请求，基于数据库管理系统的查询方式，查询出满足查询请求的信息。当数据库中的数据量达到千万级别或亿级别，往往需要几百毫秒甚至更长时间才能返回结果。

针对上述问题，本公开实施例实施例所提供的方案是，根据数据使用方对数据的使用需求，设定一个或多个查询需求，根据预设查询需求，预先利用数据库中存储的数据进行统计，获得统计数据，统计数据存储与缓存区域中，可基于数据库中数据的更新情况对统计数据进行更新。因此，当接收到查询请求中，可以从缓存区域中存储的统计数据中快速获取到符合查询请求的统计数据。请参见图2所示，是本公开实施例根据一示例性实施例示出的一种数据方法的流程图，包括如下步骤：

在步骤202中，监控数据库中数据的更新情况。

在步骤204中，根据监控到的更新情况，更新存储在缓存区域中的统计数据，所述统计数据包括利用所述数据统计的符合预设查询需求的信息。

在步骤206中，接收与所述预设查询需求相关的查询请求，从所述缓存区域中存储的统计数据中，获取符合所述查询请求的统计数据并输出。

本实施例中的方案可应用于图1所示系统中的数据处理方，数据处理方一方面接收数据提供方提供的数据，在数据库中对数据进行更新，另一方面可以接收数据使用方的查询请求，为数据使用方提供所需的数据。实际应用中，数据处理方可以配置专用于对数据进行更新的服务器或服务器集群，以及配置专用于处理数据使用方的查询请求的服务器或服务器集群，此种方式下，本实施例方案可具体运行于用于处理数据使用方的查询请求的服务器或服务器集群。在其他例子中，“在数据库中对数据进行更新”以及“处理数据使用方的查询请求”的过程，也可以是在同一服务器或服务器集群中执行。另外，数据提供方和数据使用方可以是独立的两方，也可以是同一方。

在一些应用场景中，数据使用方可能经常需要进行某些信息的查询。以网约车场景为例，网约车服务方的数据分析人员常常需要对用户当天、一周或一个月等等情形下的网约车订单数量的统计查询，相关技术中通常在数据库中查询，具体的查询方式可能是，从亿级的数据量中找到该用户的所有订单的数据，基于所有订单的数据，根据数据中的时间属性，筛选出当天、一周或一个月等等满足查询需求的数据，之后进行统计，得到符合查询需求的统计结果。

而本实施例中，可以预先收集数据使用方的查询需求，基于查询需求，数据处理方可以从数据库中数据预先查询出符合预设查询需求的统计数据，并可以将统计数据存储于缓存区域中。相对于常规的存储区域，缓存区域的数据读写速度较快。本实施例的缓存区域，可以包括设置在内存中的缓存区域，也即是以内存作为硬件资源，将统计数据放在内存中直接操作的数据库。相对于持久化存储介质，内存的数据读写速度要高出几个数量级，将统计数据保存在内存中相比从磁盘或硬盘等持久化存储介质上访问能够极大地提高应用的性能，数据处理速度比传统数据库的数据处理速度更快。

其中，预设查询需求可以根据实际需要，向数据使用方收集得到。举例来说，对于物流场景，物流方侧可能对订单数量较为关注，比如数据分析部门可能需要经常查询某些地区在一些时间段(例如每天、每周、每月、某些网购活动期间或节假日等等)的用户下单的数量，数据统计部门可能经常需要查询快递员当天的配送数量等等。对于网约车场景，数据分析人员可能经常需要分析用户在一定时间段内发起多少订单，成交多少订单等等。具体的预设查询需求可以结合所应用场景及数据使用方的需求而灵活配置，本实施例对此不作限定。

对于这些预设查询需求，可以预先利用数据库中数据获得统计数据。可以理解，数据库中数据可能会由于更新而发生变动，相应地统计数据也需要随着数据库中数据的更新而更新。因此本实施例可以监控数据库中数据的更新情况，从而对缓存区域中的统计数据进行更新。具体的监控手段，可以有多种实现方式。在某些例子中，数据处理方可以接收到数据提供方所提供的数据，假设数据库更新和统计数据更新的处理过程都由同一服务器执行，并且服务器性能较好，可以基于数据提供方所提供的数据，在进行数据库中数据更新的同时进行统计数据的更新。在其他例子中，数据处理方可能配置了不同的服务器进行数据库的更新和统计数据的更新，可以在数据库更新后，基于数据库的更新情况对统计数据进行更新。其中，对数据库中数据更新情况的监控过程，可以持续不间断地进行，也可以是每隔一定时间周期进行。

对于海量数据应用场景，数据处理方可能经常在短时间内面临较多新数据的更新，数据库中数据的更新情况也较为频繁，此种情况下，为了更为快速、高效率地进行数据库中数据更新情况的监控，可以利用数据库更新数据后产生的日志事件进行监控。通过读取日志事件中记录的更新信息，可以批量地进行统计数据的更新。

在另一些例子，为了实现数据库中数据更新后能快速地进行统计数据的更新，本实施例还可以利用主从同步的特点，及时地获取得到日志事件。具体的，

所述获取所述数据库更新数据后产生的日志事件，包括：

模拟一所述数据库的从属数据库，基于数据库交互协议，利用所述模拟的从属数据库获取所述日志事件。

本实施例中，已有的大部分数据库为了数据备份，可以构建有从属数据库，基于主数据库与从属数据库的交互协议，主数据库的任何操作，都可以对应生成日志事件，并基于交互协议传输给从属数据库，从而从属数据库可以与主数据库同步，复制主数据库中的数据。为了更为快速地获得日志事件，可以模拟一所述数据库的从属数据库，基于与从属数据库的交互协议，从而利用所述从属数据库获取所述日志事件。本实施例模拟了从属数据库，因此可以不需要配置大量的硬件资源构建真实的从属数据库，而是可以通过较小的资源配置一物理节点，根据主数据库的权限信息，修改该物理节点的相关属性，将物理节点封装为从属数据库，之后根据主数据库与从属数据库的交互协议，利用该模拟的从属数据库快速地获得主数据库数据更新后产生的日志事件，从而实现统计数据的快速更新。实际应用中，可以采用基于数据库日志增量订阅和消费的中间件进行实现，例如Canal server等等。

由前述实施例可知，本实施例可应用于任意海量数据下，需要进行某些数据查询的场景。作为一个例子，本实施例方案可应用于网约车服务端，所述预设查询需求包括一个或多个用户在设定时间段内与订单相关的统计信息。在网约车场景下，涉及较多的数据包括用户的订单数据，数据分析人员可能经常需要面临一定时间段内订单数量的统计。基于此，通过预先收集一个或多个用户在设定时间段内与订单相关的统计信息的查询需求，应用本实施例方案，可以为数据分析人员快速提供统计信息。

为了提高数据查询速度，本实施例中每条所述统计数据可以包括数据标识以及至少一类统计信息，所述统计数据采用键值key-value格式进行存储，其中，记录数据标识的字段作为主键，其他字段记录所述至少一类统计信息。key-value格式下，数据可以按照键值对的形式进行组织、索引和存储。key-value存储适合不涉及过多数据关系业务关系的业务数据，同时能有效减少读写次数，比关系型数据库存储拥有更好的读写性能。本实施例中，统计数据中可以包括数据标识以及至少一类统计信息，统计数据以数据标识作为区分，数据标识作为主键，而其他一类或多类统计信息则由其他字段进行记录。数据标识用于唯一区分统计数据，实际应用中可以结合具体场景而灵活配置统计数据的数据标识。

基于此，所述根据监控到的更新情况，更新存储在缓存区域中的统计数据，可以包括：根据监控到的更新情况，确定需更新的数据标识和统计信息，从缓存区域中查找所述需更新的数据标识后，在对应的其他字段更新统计信息。采用key-value格式，对于需要更新的统计数据，可以快速查找到所述需更新的数据标识后，在对应的其他字段更新统计信息。

针对网约车场景，乘客用户发起了网约车订单后会创建订单数据，在该网约车行程成功结束后，该订单数据的状态会被更新为订单成交。实际应用中，数据分析人员可能需要统计一定时间段内一个或多个用户的发起多少网约车订单、最终成交多少网约车订单，以进行用户行为分析或订单数据分析等等。基于此，在一个可选的实现方式中，用户在设定时间段内与订单相关的统计信息可以包括用户在所述设定时间段内的订单创建数量和/或成交订单数量。

基于上述两类统计信息，根据监控到的更新情况，更新存储在缓存区域中的统计数据，包括如下一种或多种：

若监控到的更新情况包括增加一条订单创建数据，更新存储在缓存区域中所述订单创建数据对应用户的订单创建数量。本实施例中，当用户发起一个新订单，则相对应地会创建针对本次订单的订单数据，创建的订单数据会需要在数据库中写入，因此对于数据处理方，若监控到的更新情况包括增加一条订单创建数据，则表示用户发起了一个网约车订单，而该用户对应的订单创建数量可以相应地进行增加。具体的，由前述实施例可知，缓存区域中存储有根据预设查询需求而确定统计数据，统计数据中的统计信息至少包括有用户的订单订单创建数量。具体的更新过程，可以是根据所述订单创建数据中的用户标识，查找缓存区域中与所述用户标识对应的统计数据；根据所述订单创建数据的创建时刻，对所查找到的统计数据中与所述创建时刻对应的设定时间段内的订单创建数量进行增加。

若监控到的更新情况包括订单创建数据的状态更新，更新存储在缓存区域中所述订单创建数据对应用户的成交订单数量。本实施例中，在用户发起一个网约车订单后，该网约车订单从发起、分配给司机用户至最终行程完成需要一定时间，因此订单数据中通常包括有该网约车订单的状态。当该行程完成后，数据提供方会对该订单数据更新状态，因此对于数据处理方，若监控到的更新情况包括订单创建数据的完成状态更新，则表示该用户的网约车订单成功完成，该用户对应的成交订单数量可以相应地进行增加。具体的更新过程，可以是根据所述订单创建数据中的用户标识，查找缓存区域中与所述用户标识对应的统计数据；根据所述订单创建数据的更新时刻，对所查找到的统计数据中与所述更新时刻对应的设定时间段内的成交订单数量进行增加。

接下来对本公开实施例实施例再次进行详细说明。如图3所示，是本公开实施例根据一示例性实施例示出的数据查询方案的示意图。

图3中，数据库以MySQL为例进行说明。数据处理方将数据存储于MySQL中。MySQL数据库每做一次增删改的操作，均会生成一条针对本次操作的binlog(日志事件)数据。

数据处理方使用Canal Server产品，由Canal Server伪装为一个MySQL的从属数据库，由Canal Server收集MySQL的binlog数据。

高并发场景下，由于binlog数据可能很多，数据处理方可以配置Kafka分布式消息处理系统，以并行处理大量的高并发的binlog数据。Canal Server将收到的MySQL binlog数据传输至Kafka。

采用Apache Samza流处理系统对Kafka中的binlog数据进行预处理，例如数据过滤、去重等等预处理，减少后续处理的数据量。

Apache Samza将处理后的binlog数据传输至Kafka。数据处理方根据实际场景需要，开发统计程序，由Kafka根据统计程序对binlog数据进行聚合，确定出新的统计数据，并将更新的统计数据存储与内存数据库中，内存数据库可以包括Redis数据库等等。

举例来说，当收到一条针对创建订单的binlog，说明这条binlog对应的用户发起了一个订单，该用户的当天订单量要在之前的基础上+1。内存数据库中，统计数据可以根据需要而灵活设置数据格式，作为一个例子，统计数据可以利用用户标识和月份作为唯一标识，如key:pid_MM(pid为乘客ID，MM为月份)，其中，key表示主键，pid_MM即该条统计数据的数据标识，统计数据中还可以包括多种不同含义的字段，例如状态字段、订单数量字段等等。比如，cnt_DD字段可以记录在MM月DD日的订单量。可选的，字段的数值还可以采用哈希格式，从而提高数据安全性。在其他例子中，还可以统计用户的成交订单数量，当接收到一条针对订单的update操作，订单的状态字段由“新建”改完“成交”，相应地对统计数据中的状态字段进行更新。

当数据处理方接收到数据查询请求，可以直接访问内存数据库，获得统计信息。以内存数据库为Redis数据库为例，数据查询请求为pidx在1月1日的订单量，按照Redis数据库的语法格式，调用Redis命令：hget pidx_01cnt_01即可。由于内存数据库的查询性能可以达到10W+的吞吐量，且一般查询都可以在1ms内返回结果，较原来的MySQL查询，查询速度有了上百倍的提升。

与前述数据查询方法的实施例相对应，本公开实施例还提供了数据查询装置及其所应用的服务器的实施例。

如图4所示，图4是本公开实施例根据一示例性实施例示出的一种数据查询装置的框图，所述数据查询装置包括：

监控模块41，用于：监控数据库中数据的更新情况；

更新模块42，用于：根据监控到的更新情况，更新存储在缓存区域中的统计数据，所述统计数据包括利用所述数据统计的符合预设查询需求的数据；

请求处理模块43，用于：接收与所述预设查询需求相关的查询请求，从所述缓存区域中存储的统计数据中，获取符合所述查询请求的统计信息并输出。

本实施例中的方案可应用于图1所示系统中的数据处理方，数据处理方一方面接收数据提供方提供的数据，在数据库中对数据进行更新，另一方面可以接收数据使用方的查询请求，为数据使用方提供所需的数据。实际应用中，数据处理方可以配置专用于对数据进行更新的服务器或服务器集群，以及配置专用于处理数据使用方的查询请求的服务器或服务器集群，此种方式下，本实施例方案可具体运行于用于处理数据使用方的查询请求的服务器或服务器集群。在其他例子中，“在数据库中对数据进行更新”以及“处理数据使用方的查询请求”的过程，也可以是在同一服务器或服务器集群中执行。另外，数据提供方和数据使用方可以是独立的两方，也可以是同一方。

在一些应用场景中，数据使用方可能经常需要进行某些信息的查询。以网约车场景为例，网约车服务方的数据分析人员常常需要对用户当天、一周或一个月等等情形下的网约车订单数量的统计查询，相关技术中通常在数据库中查询，具体的查询方式可能是，从亿级的数据量中找到该用户的所有订单的数据，基于所有订单的数据，根据数据中的时间属性，筛选出当天、一周或一个月等等满足查询需求的数据，之后进行统计，得到符合查询需求的统计结果。

而本实施例中，可以预先收集数据使用方的查询需求，基于查询需求，数据处理方可以从数据库中数据预先查询出符合预设查询需求的统计数据，并可以将统计数据存储于缓存区域中。相对于常规的存储区域，缓存区域的数据读写速度较快。本实施例的缓存区域，可以包括设置在内存中的缓存区域，也即是以内存作为硬件资源，将统计数据放在内存中直接操作的数据库。相对于持久化存储介质，内存的数据读写速度要高出几个数量级，将统计数据保存在内存中相比从磁盘或硬盘等持久化存储介质上访问能够极大地提高应用的性能，数据处理速度比传统数据库的数据处理速度更快。

其中，预设查询需求可以根据实际需要，向数据使用方收集得到。举例来说，对于物流场景，物流方侧可能对订单数量较为关注，比如数据分析部门可能需要经常查询某些地区在一些时间段(例如每天、每周、每月、某些网购活动期间或节假日等等)的用户下单的数量，数据统计部门可能经常需要查询快递员当天的配送数量等等。对于网约车场景，数据分析人员可能经常需要分析用户在一定时间段内发起多少订单，成交多少订单等等。具体的预设查询需求可以结合所应用场景及数据使用方的需求而灵活配置，本实施例对此不作限定。

对于这些预设查询需求，可以预先利用数据库中数据获得统计数据。可以理解，数据库中数据可能会由于更新而发生变动，相应地统计数据也需要随着数据库中数据的更新而更新。因此本实施例可以监控数据库中数据的更新情况，从而对缓存区域中的统计数据进行更新。具体的监控手段，可以有多种实现方式。在某些例子中，数据处理方可以接收到数据提供方所提供的数据，假设数据库更新和统计数据更新的处理过程都由同一服务器执行，并且服务器性能较好，可以基于数据提供方所提供的数据，在进行数据库中数据更新的同时进行统计数据的更新。在其他例子中，数据处理方可能配置了不同的服务器进行数据库的更新和统计数据的更新，可以在数据库更新后，基于数据库的更新情况对统计数据进行更新。其中，对数据库中数据更新情况的监控过程，可以持续不间断地进行，也可以是每隔一定时间周期进行。

对于海量数据应用场景，数据处理方可能经常在短时间内面临较多新数据的更新，数据库中数据的更新情况也较为频繁，此种情况下，为了更为快速、高效率地进行数据库中数据更新情况的监控，可以利用数据库更新数据后产生的日志事件进行监控。通过读取日志事件中记录的更新信息，可以批量地进行统计数据的更新。

在另一些例子，为了实现数据库中数据更新后能快速地进行统计数据的更新，本实施例还可以利用主从同步的特点，及时地获取得到日志事件。具体的，

所述所述监控模块，还用于：

模拟一所述数据库的从属数据库，基于数据库交互协议，利用所述模拟的从属数据库获取所述日志事件。

本实施例中，已有的大部分数据库为了数据备份，可以构建有从属数据库，基于主数据库与从属数据库的交互协议，主数据库的任何操作，都可以对应生成日志事件，并基于交互协议传输给从属数据库，从而从属数据库可以与主数据库同步，复制主数据库中的数据。为了更为快速地获得日志事件，可以模拟一所述数据库的从属数据库，基于与从属数据库的交互协议，从而利用所述从属数据库获取所述日志事件。本实施例模拟了从属数据库，因此可以不需要配置大量的硬件资源构建真实的从属数据库，而是可以通过较小的资源配置一物理节点，根据主数据库的权限信息，修改该物理节点的相关属性，将物理节点封装为从属数据库，之后根据主数据库与从属数据库的交互协议，利用该模拟的从属数据库快速地获得主数据库数据更新后产生的日志事件，从而实现统计数据的快速更新。实际应用中，可以采用基于数据库日志增量订阅和消费的中间件进行实现，例如Canal server等等。

由前述实施例可知，本实施例可应用于任意海量数据下，需要进行某些数据查询的场景。作为一个例子，本实施例方案可应用于网约车服务端，所述预设查询需求包括一个或多个用户在设定时间段内与订单相关的统计信息。在网约车场景下，涉及较多的数据包括用户的订单数据，数据分析人员可能经常需要面临一定时间段内订单数量的统计。基于此，通过预先收集一个或多个用户在设定时间段内与订单相关的统计信息的查询需求，应用本实施例方案，可以为数据分析人员快速提供统计信息。

为了提高数据查询速度，本实施例中每条所述统计数据包括数据标识以及至少一类统计信息，所述统计数据采用键值key-value格式进行存储，其中，记录数据标识的字段作为主键，其他字段记录所述至少一类统计信息。key-value格式下，数据可以按照键值对的形式进行组织、索引和存储。key-value存储非常适合不涉及过多数据关系业务关系的业务数据，同时能有效减少读写次数，比关系型数据库存储拥有更好的读写性能。本实施例中，统计数据中可以包括数据标识以及至少一类统计信息，统计数据以数据标识作为区分，数据标识作为主键，而其他一类或多类统计信息则由其他字段进行记录。

基于此，所述根据监控到的更新情况，更新存储在缓存区域中的统计数据，可以包括：根据监控到的更新情况，确定需更新的数据标识和统计信息，从缓存区域中查找所述需更新的数据标识后，在对应的其他字段更新统计信息。采用key-value格式，对于需要更新的统计数据，可以快速查找到所述需更新的数据标识后，在对应的其他字段更新统计信息。

针对网约车场景，乘客用户发起了网约车订单后会创建订单数据，在该网约车行程成功结束后，该订单数据的状态会被更新为订单成交。实际应用中，数据分析人员可能需要统计一定时间段内一个或多个用户的发起多少网约车订单、最终成交多少网约车订单，以进行用户行为分析或订单数据分析等等。基于此，在一个可选的实现方式中，用户在设定时间段内与订单相关的统计信息可以包括用户在所述设定时间段内的订单创建数量和/或成交订单数量。

基于上述两类统计信息，所述监控模块，还用于：

若监控到的更新情况包括增加一条订单创建数据，更新存储在缓存区域中所述订单创建数据对应用户的订单创建数量。本实施例中，当用户发起一个新订单，则相对应地会创建针对本次订单的订单数据，创建的订单数据会需要在数据库中写入，因此对于数据处理方，若监控到的更新情况包括增加一条订单创建数据，则表示用户发起了一个网约车订单，而该用户对应的订单创建数量可以相应地进行增加。具体的，由前述实施例可知，缓存区域中存储有根据预设查询需求而确定统计数据，统计数据中的统计信息至少包括有用户的订单订单创建数量。具体的更新过程，可以是根据所述订单创建数据中的用户标识，查找缓存区域中与所述用户标识对应的统计数据；根据所述订单创建数据的创建时刻，对所查找到的统计数据中与所述创建时刻对应的设定时间段内的订单创建数量进行增加。

若监控到的更新情况包括订单创建数据的状态更新，更新存储在缓存区域中所述订单创建数据对应用户的成交订单数量。本实施例中，在用户发起一个网约车订单后，该网约车订单从发起、分配给司机用户至最终行程完成需要一定时间，因此订单数据中通常包括有该网约车订单的状态。当该行程完成后，数据提供方会对该订单数据更新状态，因此对于数据处理方，若监控到的更新情况包括订单创建数据的完成状态更新，则表示该用户的网约车订单成功完成，该用户对应的成交订单数量可以相应地进行增加。具体的更新过程，可以是根据所述订单创建数据中的用户标识，查找缓存区域中与所述用户标识对应的统计数据；根据所述订单创建数据的更新时刻，对所查找到的统计数据中与所述更新时刻对应的设定时间段内的成交订单数量进行增加。

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

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

相应的，本公开实施例还提供一种服务器，所述装置包括有处理器；用于存储处理器可执行指令的存储器；其中，所述处理器被配置为：

监控数据库中数据的更新情况；

根据监控到的更新情况，更新存储在缓存区域中的统计数据，所述统计数据包括利用所述数据统计的符合预设查询需求的数据；

接收与所述预设查询需求相关的查询请求，从所述缓存区域中存储的统计数据中，获取符合所述查询请求的统计信息并输出。

相应的，本公开实施例还提供一种计算机存储介质，所述存储介质中存储有程序指令，所述程序指令包括：

监控数据库中数据的更新情况；

根据监控到的更新情况，更新存储在缓存区域中的统计数据，所述统计数据包括利用所述数据统计的符合预设查询需求的数据；

接收与所述预设查询需求相关的查询请求，从所述缓存区域中存储的统计数据中，获取符合所述查询请求的统计信息并输出。

本申请实施例可采用在一个或多个其中包含有程序代码的存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。计算机可用存储介质包括永久性和非永久性、可移动和非可移动媒体，可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括但不限于：相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

本领域技术人员在考虑说明书及实践这里申请的发明后，将容易想到本公开实施例的其它实施方案。本公开实施例旨在涵盖本公开实施例的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开实施例的一般性原理并包括本公开实施例未申请的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开实施例的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开实施例并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开实施例的范围仅由所附的权利要求来限制。

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

Claims (20)

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

监控数据库中数据的更新情况；

根据监控到的更新情况，更新存储在缓存区域中的统计数据，所述统计数据包括利用所述数据统计的符合预设查询需求的数据；

接收与所述预设查询需求相关的查询请求，从所述缓存区域中存储的统计数据中，获取符合所述查询请求的统计信息并输出。

2.根据权利要求1所述的方法，其特征在于，所述缓存区域包括设置在内存中的缓存区域。

3.根据权利要求1所述的方法，其特征在于，所述监控数据库中数据的更新情况，包括：

获取所述数据库更新数据后产生的日志，通过所述日志事件监控数据库中数据的更新情况。

4.根据权利要求3所述的方法，其特征在于，所述获取所述数据库更新数据后产生的日志事件，包括：

模拟一所述数据库的从属数据库，基于数据库交互协议，利用所述模拟的从属数据库获取所述日志事件。

5.根据权利要求1所述的方法，其特征在于，每条所述统计数据包括数据标识以及至少一类统计信息，所述统计数据采用键值key-value格式进行存储，其中，记录数据标识的字段作为主键，其他字段记录所述至少一类统计信息。

6.根据权利要求5所述的方法，其特征在于，所述根据监控到的更新情况，更新存储在缓存区域中的统计数据，包括：

根据监控到的更新情况，确定需更新的数据标识和统计信息，从缓存区域中查找所述需更新的数据标识后，在对应的其他字段更新统计信息。

7.根据权利要求1所述的方法，其特征在于，所述方法应用于网约车服务端，所述预设查询需求包括用户在设定时间段内与订单相关的统计信息。

8.根据权利要求7所述的方法，其特征在于，所述用户在设定时间段内与订单相关的统计信息包括用户在所述设定时间段内的订单创建数量和/或成交订单数量；

所述根据监控到的更新情况，更新存储在缓存区域中的统计数据，包括如下一种或多种：

若监控到的更新情况包括增加一条订单创建数据，更新存储在缓存区域中所述订单创建数据对应用户的订单创建数量；

若监控到的更新情况包括订单创建数据的完成状态更新，更新存储在缓存区域中所述订单创建数据对应用户的成交订单数量。

9.根据权利要求8所述的方法，其特征在于，所述更新存储在缓存区域中所述订单创建数据对应用户的订单创建数量，包括：

根据所述订单创建数据中的用户标识，查找缓存区域中与所述用户标识对应的统计数据；根据所述订单创建数据的创建时刻，对所查找到的统计数据中与所述创建时刻对应的设定时间段内的订单创建数量进行更新；

或，

所述更新存储在缓存区域中所述订单创建数据对应用户的成交订单数量，包括：

根据所述订单创建数据中的用户标识，查找缓存区域中与所述用户标识对应的统计数据；根据所述订单创建数据的更新时刻，对所查找到的统计数据中与所述更新时刻对应的设定时间段内的成交订单数量进行更新。

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

监控模块，用于：监控数据库中数据的更新情况；

更新模块，用于：根据监控到的更新情况，更新存储在缓存区域中的统计数据，所述统计数据包括利用所述数据统计的符合预设查询需求的数据；

请求处理模块，用于：接收与所述预设查询需求相关的查询请求，从所述缓存区域中存储的统计数据中，获取符合所述查询请求的统计信息并输出。

11.根据权利要求10所述的装置，其特征在于，所述缓存区域包括设置在内存中的缓存区域。

12.根据权利要求10所述的装置，其特征在于，所述监控模块，还用于：

获取所述数据库更新数据后产生的日志，通过所述日志事件监控数据库中数据的更新情况。

13.根据权利要求12所述的装置，其特征在于，所述监控模块，还用于：

模拟一所述数据库的从属数据库，基于数据库交互协议，利用所述模拟的从属数据库获取所述日志事件。

14.根据权利要求10所述的装置，其特征在于，每条所述统计数据包括数据标识以及至少一类统计信息，所述统计数据采用键值key-value格式进行存储，其中，记录数据标识的字段作为主键，其他字段记录所述至少一类统计信息。

15.根据权利要求14所述的装置，其特征在于，所述更新模块，还用于：

根据监控到的更新情况，确定需更新的数据标识和统计信息，从缓存区域中查找所述需更新的数据标识后，在对应的其他字段更新统计信息。

16.根据权利要求10所述的装置，其特征在于，所述方法应用于网约车服务端，所述预设查询需求包括用户在设定时间段内与订单相关的统计信息。

17.根据权利要求16所述的装置，其特征在于，所述用户在设定时间段内与订单相关的统计信息包括用户在所述设定时间段内的订单创建数量和/或成交订单数量；

所述监控模块，还用于：

若监控到的更新情况包括增加一条订单创建数据，更新存储在缓存区域中所述订单创建数据对应用户的订单创建数量；

若监控到的更新情况包括订单创建数据的完成状态更新，更新存储在缓存区域中所述订单创建数据对应用户的成交订单数量。

18.根据权利要求17所述的装置，其特征在于，所述监控模块，还用于：

根据所述订单创建数据中的用户标识，查找缓存区域中与所述用户标识对应的统计数据；根据所述订单创建数据的创建时刻，对所查找到的统计数据中与所述创建时刻对应的设定时间段内的订单创建数量进行增加；

或，

所述监控模块，还用于：根据所述订单创建数据中的用户标识，查找缓存区域中与所述用户标识对应的统计数据；根据所述订单创建数据的更新时刻，对所查找到的统计数据中与所述更新时刻对应的设定时间段内的成交订单数量进行增加。

19.一种服务器，其特征在于，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：

监控数据库中数据的更新情况；

根据监控到的更新情况，更新存储在缓存区域中的统计数据，所述统计数据包括利用所述数据统计的符合预设查询需求的数据；

接收与所述预设查询需求相关的查询请求，从所述缓存区域中存储的统计数据中，获取符合所述查询请求的统计信息并输出。

20.一种计算机存储介质，其特征在于，所述存储介质中存储有程序指令，所述程序指令包括：

监控数据库中数据的更新情况；

根据监控到的更新情况，更新存储在缓存区域中的统计数据，所述统计数据包括利用所述数据统计的符合预设查询需求的数据；

接收与所述预设查询需求相关的查询请求，从所述缓存区域中存储的统计数据中，获取符合所述查询请求的统计信息并输出。