CN107038207B - 一种数据查询方法、数据处理方法及装置 - Google Patents

Abstract

本申请公开了一种数据处理方法，包括：当接收到包含有待存储数据的数据存储请求时，依据预设映射规则，确定待存储数据中的用户字段与数据库字段之间的映射关系，其中，待存储数据为非结构化数据；依据映射关系，将待存储数据转换为索引数据，其中，索引数据体现为数据库字段的形式；将索引数据存储在数据库中。该方法还可以保存映射关系，从而当接收到数据查询请求时进行用户字段与数据库字段之间的转换，实现数据的查询。本申请实施例还提供了相应的数据查询方法和数据处理系统。因此，本申请提供了一种易使用、易扩展、易维护的数据处理解决方案，适用于非结构化数据的处理，从而降低了用户的使用成本，提高了用户体验。

Description

一种数据查询方法、数据处理方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种数据查询方法、数据处理方法及装置。

背景技术

随着互联网数据规模的爆炸式增长，数据在人们的生活中已经扮演着越来越重要的角色。海量的历史、实时数据如何存储，如何从庞大的数据存储系统中快速获取有用信息，变得越来越具有挑战性。在此背景下，与各种数据处理相关的技术和系统应运而生。

以搜索系统为例，由于搜索是获取信息最高效的途径之一，因此也成为各类网站或应用的基础标配功能。开发者想在自己的产品中实现搜索功能一般都是基于某个开源搜索系统(如ElasticSearch、Solr、Sphinx、Lucene等)搭建搜索服务。比如Lucene系统和HA3系统，Lucene系统是一个开放源代码的全文检索引擎工具包，提供了完整的查询引擎和索引引擎以及部分文本分析引擎；HA3系统是一种分布式实时搜索系统，具备自动容灾、动态扩容、秒级实时等能力。但由于Lucene系统和HA3系统本身都不是完整的搜索解决方案，要搭建一套完整的搜索系统，还需要用户进行索引结构定义(Schema)、检索规则配置(ClusterRule))、索引构建与分发(IndexProcess)等操作，这对于非专业人士而言，门槛很高。

在现有技术中，以OpenSearch系统为代表的云搜索可以一定程度上解决上述问题。它可提供搜索托管服务，用户可将数据上传至云端进行数据处理和索引构建，再通过API使用云搜索服务，而不需要进行过于专业化的操作。但是，由于这种系统在开发、使用、扩展和维护等多方面存在不便，因此，提高了用户的使用成本，影响了用户体验。

发明内容

本申请实施例提供一种数据处理方法及装置，旨在解决上述现有技术的缺陷，提供一种易使用、易扩展、易维护的数据处理解决方案，从而降低用户的使用成本，提高用户体验。

本申请实施例采用下述技术方案：

本申请实施例提供的数据处理方法，包括：

当接收到包含有待存储数据的数据存储请求时，依据预设映射规则，确定所述待存储数据中的用户字段与数据库字段之间的映射关系；其中，所述待存储数据为非结构化数据；

依据所述映射关系，将所述待存储数据转换为索引数据；其中，所述索引数据体现为所述数据库字段的形式；

将所述索引数据存储在数据库中。

优选地，本申请实施例提供的数据处理方法中，当接收到包含有待存储数据的数据存储请求时，依据预设映射规则，确定所述待存储数据中的用户字段与数据库字段之间的映射关系，具体包括：

当接收到包含有待存储数据的数据存储请求时，对所述待存储数据进行数据结构分析，确定所述待存储数据中所包含的用户字段；

依据所述用户字段以及所述预设映射规则，确定所述用户字段与所述数据库字段之间的所述映射关系。

优选地，本申请实施例提供的数据处理方法中，依据所述映射关系，将所述待存储数据转换为索引数据，具体包括：

依据所述映射关系，将所述待存储数据中的用户字段映射为数据库字段，依据所述用户字段的写入值确定所述数据库字段的写入值，构成所述索引数据。

优选地，本申请实施例提供的数据处理方法中，在依据预设映射规则，确定所述待存储数据中的用户字段与数据库字段之间的映射关系之后，还包括：

保存所述映射关系，以便当接收到数据查询请求时实现所述用户字段与所述数据库字段之间的转换。

优选地，本申请实施例提供的数据处理方法中，所述方法还包括：

当接收到所述数据查询请求时，依据所述映射关系，将所述数据查询请求映射为数据库查询语句；其中，所述数据查询请求体现为用户字段的形式，所述数据库查询语句体现为数据库字段的形式；

依据所述数据库查询语句，在所述数据库中查询得到第一查询结果；其中，所述第一查询结果体现为所述数据库字段的形式；

依据所述映射关系，将所述第一查询结果转换为第二查询结果；其中，所述第二查询结果体现为所述用户字段的形式。

优选地，本申请实施例提供的数据处理方法中，依据所述映射关系，将所述数据查询请求映射为数据库查询语句，具体包括：

对所述数据查询请求进行解析，得到所述数据查询请求中携带的所述用户字段及所述用户字段的查询值；

依据所述映射关系，将所述数据查询请求中携带的所述用户字段映射为数据库字段，将所述用户字段的查询值作为所述数据库字段的查询值，构成所述数据库查询语句。

优选地，本申请实施例提供的数据处理方法中，对所述数据查询请求进行解析，得到所述数据查询请求中携带的所述用户字段及所述用户字段的查询值，具体包括：

采用语法分析器对所述数据查询请求进行分析，得到所述数据查询请求的语法树；

采用词法分析器对所述语法树进行词法分析，得到所述数据查询请求中携带的所述用户字段及所述用户字段的查询值。

优选地，本申请实施例提供的数据处理方法中，采用分布式数据中心保存所述映射关系；则当所述映射关系发生变更时，所述方法还包括：

通知所述分布式数据中心的各节点更新所保存的映射关系。

优选地，本申请实施例提供的数据处理方法中，所述预设映射规则，具体包括：

当所述用户字段的类型为字符串型、长整型或者双精度型时，将该用户字段映射为倒排索引类型和/或正排索引类型的数据库字段；或

当所述用户字段的类型为文本型时，将该用户字段映射为文本分词类型的数据库字段。

优选地，本申请实施例提供的数据处理方法中，所述待存储数据为JSON格式的非结构化数据。

本申请实施例还提供了一种数据查询方法，包括：

接收所述数据查询请求；其中，所述数据查询请求中包含用户字段；

依据用户字段与数据库字段的映射关系，将所述数据查询请求映射为数据库查询语句；其中，所述数据查询请求体现为所述用户字段的形式，所述数据库查询语句体现为所述数据库字段的形式；

依据所述数据库查询语句，在数据库中查询得到第一查询结果；其中，所述数据库中存储有体现为所述数据库字段的形式的索引数据，所述第一查询结果体现为所述数据库字段的形式；

依据所述映射关系，将所述第一查询结果转换为第二查询结果；其中，所述第二查询结果体现为所述用户字段的形式。

本申请实施例还提供了一种数据处理系统，包括：

请求接收模块，用于接收包含有待存储数据的数据存储请求；

映射关系确定模块，用于当所述请求接收模块接收到包含有待存储数据的数据存储请求时，依据预设映射规则，确定所述待存储数据中的用户字段与数据库字段之间的映射关系；其中，所述待存储数据为非结构化数据；

第一转换模块，用于依据所述映射关系，将所述待存储数据转换为索引数据；其中，所述索引数据体现为所述数据库字段的形式；

存储模块，用于将所述索引数据存储在数据库中。

优选地，在本申请实施例还提供的数据处理系统中，所述装置还包括：

数据中心，用于保存所述映射关系，以便当接收到数据查询请求时实现所述用户字段与所述数据库字段之间的转换。

优选地，在本申请实施例还提供的数据处理系统中，所述请求接收模块，还用于接收所述数据查询请求；且所述装置还包括：

第二转换模块，用于当接收到所述数据查询请求时，依据所述映射关系，将所述数据查询请求映射为数据库查询语句；其中，所述数据查询请求体现为用户字段的形式，所述数据库查询语句体现为数据库字段的形式；

查询模块，用于依据所述数据库查询语句，在所述数据库中查询得到第一查询结果；其中，所述第一查询结果体现为所述数据库字段的形式；

第三转换模块，用于依据所述映射关系，将所述第一查询结果转换为第二查询结果；其中，所述第二查询结果体现为所述用户字段的形式。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

在本申请实施例提供的数据处理方法中，在接收到数据存储请求时，依据预设的映射规则建立用户字段与数据库字段间的映射关系，从而能够在此基础上将待存储数据转换为索引数据进行存储。采用该方案，对待存储数据的数据结构可以不做要求，当待存储数据为非结构化数据时，本申请实施例提供的方法能够根据待存储数据动态地建立用户字段与数据库字段的映射关系，将非结构化的用户数据转换为符合数据库存储结构、体现为数据库字段形式的索引数据进行存储，从而实现了对非结构化数据的存储。因此，相比于现有技术，本申请实施例使得数据库具备了非结构化数据的存储能力，具备了易使用、易扩展、易维护等诸多优点，从而降低了用户的使用成本，提高了用户体验。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的数据处理方法的流程示意图；

图2为本申请实施例提供的数据处理方法中映射关系建立与索引数据构建的实施示例图；

图3为本申请实施例提供的第二种数据处理方法的流程示意图；

图4为本申请实施例提供的数据处理系统的结构示意图；

图5为应用本申请实施例所提供的数据处理方法和系统的一种搜索系统的框架示意图；

图6为图5所示搜索系统中数据写入过程的数据流转示意图；

图7为图5所示搜索系统中数据查询过程的数据流转示意图。

具体实施方式

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

以下结合附图，详细说明本申请各实施例提供的技术方案。

实施例1

如图1所示，本申请实施例提供的数据处理方法，包括：

S101：接收数据存储请求。

在本步骤中，数据存储请求中可以包含有待存储数据。当然，除此之外，该请求中还可包含其他内容，例如用于指示进行数据存储或者索引写入的指令标识符，用于区分不同应用的用户表名，用于区分存储的不同索引数据的唯一标识符等。

数据存储请求中包含的待存储数据可以体现为多种形式，若体现为非结构化数据，优选采用JSON(全称JavaScript Object Notation，是一种基于JavaScript编程语言ECMA-262 3rd Edition-December 1999标准的轻量级的数据交换格式)数据的形式，该数据形式既易于用户阅读和编写，同时也易于机器解析和生成。

现以采用Http RESTful这一设计规范为例，说明数据存储请求的表现形式及其内容。数据存储请求采用HTTP-POST/＄表名/＄主键–d“Json数据”的形式给出，例如，可以表现为POST/mytable/uuid-d“{Json数据…}”，其中“POST”为数据存储指令的标识符，表示要写入数据，“mytable”为表名，“uuid”为该条记录的ID，“{Json数据…}”部分即为待存储数据，该示例中是以JSON数据的形式给出的，参见图2所示。

S102：当接收到包含有待存储数据的数据存储请求时，依据预设映射规则，确定待存储数据中的用户字段与数据库字段之间的映射关系；其中，待存储数据为非结构化数据。

具体地，在执行步骤S102时，在接收到包含有待存储数据的数据存储请求之后，可以先对待存储数据进行数据结构分析，确定待存储数据中所包含的用户字段；然后依据用户字段以及预设映射规则，确定用户字段与数据库字段之间的映射关系。

其中，预设映射规则可以具体包括：当用户字段的类型为字符串型、长整型或者双精度型时，将该用户字段映射为倒排索引类型和/或正排索引类型的数据库字段；当用户字段的类型为文本型时，将该用户字段映射为文本分词类型的数据库字段。

以图2所示为例，JSON数据可以具体包括以下内容：

“title”:“hello world”,

“writer”:“rose”,

“create”:1474992000,

“amount”:12.29,

“body_text”:“Spring Boot……”

对上述待存储数据进行数据结构分析，可知：

用户字段“title”，对应的值为“hello world”；

用户字段“writer”，对应的值为“rose”；

用户字段“create”，对应的值为1474992000；

用户字段“amount”，对应的值为12.29；

用户字段“body_text”，对应的值为“Spring Boot……”

在此基础上，进一步根据用户字段对应的值的数据类型确定该用户字段的类型，进而按照预设映射规则确定与该用户字段建立映射关系的数据库字段的类型。

以图2所示为例，用户字段“title”和用户字段“writer”的值均为字符串，则这两个用户字段的类型为字符串型；用户字段“create”的值为长整型数据，则这个用户字段的类型为长整型；用户字段“amount”的值为双精度型数据，则这个用户字段的类型为双精度型。按照上述预设映射规则所述，可以将“title”、“writer”、“create”、“amount”这几个用户字段映射为倒排索引类型的数据库字段“index_string”，即用户字段“title”、“writer”、“create”、“amount”均与数据库字段“index_string”建立映射关系，以便可以根据字段的值来查找到相应的索引数据，实现精确检索。在设定预设映射规则时，可以将倒排索引类型的数据库字段设定为多值字段，将多个用户字段的值对应映射到同一个数据库字段，以便提高数据库的可扩展性。采用这种方式将用户字段映射到数据库字段，理论上可以无限扩展以满足用户实际需要。

上述字符串型、长整型、双精度型的基础字段也可以映射为正排索引类型的数据库字段，以便进行排序、过滤、统计等数据库操作。待存储数据中的同一用户字段也可以同时映射到倒排索引类型的数据库字段和正排索引类型的数据库字段，以便满足数据库的不同操作需求；映射到倒排索引类型的数据库字段和正排索引类型的数据库字段的用户字段，可以相同也可以不同。由于排序、过滤、统计等数据库操作与字段的值的类型有关，因此，不同数据类型的用户字段可分别映射到不同的正排索引类型的数据库字段。例如，长整型的用户字段“create”可以与正排索引类型的数据库字段“attr_long_1”建立映射关系，双精度型的用户字段“amount”可以与正排索引类型的数据库字段“attr_double_1”建立映射关系。考虑到数据库的容量和稳定性，可以为正排索引类型的数据库字段限定字段数量的上限，例如，可以设定字符串型、长整型、双精度型的用户字段分别映射到最多10个正排索引类型的数据库字段，可采用先到先得的方式占用。当然，可以理解到，根据用户的实际应用需要，可以调整甚至取消该字段数量的上限。

在预设映射规则中也可以约定对文本型字段的识别标准，例如，可约定以“_text”结尾的用户字段的类型为文本型，将该文本型用户字段映射为文本分词类型的数据库字段。例如，上述用户字段“body_text”以_text”结尾，则将该用户字段与文本分词类型的数据库字段“text_1”建立映射关系。

S103：依据映射关系，将待存储数据转换为索引数据；其中，索引数据体现为数据库字段的形式。

在确定用户字段与数据库字段的映射关系之后，需要进一步将待存储数据转换为索引数据存入数据库中。在具体实施时，可依据映射关系，将待存储数据中的用户字段映射为数据库字段，依据用户字段的写入值确定数据库字段的写入值，构成索引数据。

以图2所示为例，待存储数据——JSON数据具体包括以下内容：

“title”:“hello world”,

“writer”:“rose”,

“create”:1474992000,

“amount”:12.29,

“body_text”:“Spring Boot……”

如前举例所述，形成映射关系如下：

(1)用户字段“title”、“writer”、“create”、“amount”均与倒排索引类型的数据库字段“index_string”建立映射关系；

(2)用户字段“create”与正排索引类型的数据库字段“attr_long_1”建立映射关系；

(3)用户字段“amount”与正排索引类型的数据库字段“attr_double_1”建立映射关系；

(4)用户字段“body_text”与文本分词类型的数据库字段“text_1”建立映射关系。

基于第(1)条映射关系，数据库字段“index_string”的写入值依据用户字段“title”、“writer”、“create”、“amount”的写入值确定，例如可确定为“title`helloworld|writer`rose|create`1474992000…”的形式。

基于第(2)条映射关系，数据库字段“attr_long_1”的写入值可以直接取为相对应的用户字段“create”的写入值“1474992000”，在排序、过滤或统计时使用。

基于第(3)条映射关系，数据库字段“attr_double_1”的写入值也直接取为相对应的用户字段“amount”的写入值“12.29”。

基于第(4)条映射关系，数据库字段“text_1”的写入值依据用户字段“body_text”的写入值“Spring Boot……”这段文本的内容确定。具体地，可以对文本“SpringBoot……”进行分词，将每一个分词都作为数据库字段“text_1”的写入值，不同的分词对应同一个数据库字段“text_1”，从而能够实现模糊查询的数据库操作。

在确定好数据库字段及其相应的写入值后，即可相对应地形成如下索引数据：

“index_string”:“title`helloworld|writer`rose|create`1474992000|amount`12.29”,

“attr_long_1”:“1474992000”,

“attr_double_1”:“12.29”,

“text_1”:“Spring|Boot|……”

步骤S104：将索引数据存储在数据库中。

在确定索引数据的基础上，执行步骤S104进行存储。在存储时，可以采用宽表技术(BigTable)实现。BigTable是一种非关系数据库，具有适用性广泛、可扩展、高性能和高可用性等优点。在图2所示举例中，“Big Schema大宽表”就是基于宽表技术构建的：先利用数据库底层预先布设一个大宽表，再将上层各个用户的数据通过规则路由到宽表的不同区域中，从而达到单实例多租户的使用效果。以图2为例，分为“appkey”、“id”、“倒排索引”、“文本字段”、“正排索引”、“摘要索引”几个区域，其中，“appkey”用于存储用户表名，以区分不同应用；“id”用于存储主键，采用＄appkey_id以区别唯一性；“倒排索引”、“文本字段”以及“正排索引”分别对应存储以上阐述的不同类型的数据库字段，此处不再赘述；“摘要索引”可以完整、原始的记录待存储数据，以供查询。

以上详细举例阐述了依据数据存储请求，提取待存储数据，通过建立待存储数据中的用户字段与数据库字段的映射关系，将待存储数据转换为索引数据进而存储在数据库中的过程。

进一步优选地，在依据预设映射规则，确定待存储数据中的用户字段与数据库字段之间的映射关系之后，还包括：

S105：保存映射关系，以便当接收到数据查询请求时实现用户字段与数据库字段之间的转换。

具体地，可以采用分布式数据中心保存映射关系。当映射关系发生变更时，可采用广播等方式通知分布式数据中心的各节点更新所保存的映射关系，从而实现一个分布式的元数据资源中心，以便实现映射关系的备份。具体实现时，可以采用zookeeper技术和分布式内存技术相结合的方式。

进一步地，参见图3所示，本申请实施例提供的数据处理方法还可包括：

S106：接收数据查询请求。

采用本申请实施例，数据查询请求中包含待查询的内容，这一待查询的内容由用户输入，可以是任意形式的自然语言。

S107：当接收到数据查询请求时，依据映射关系，将数据查询请求映射为数据库查询语句；其中，数据查询请求体现为用户字段的形式，数据库查询语句体现为数据库字段的形式。

在执行步骤S107时，优选先对数据查询请求进行解析，得到数据查询请求中携带的用户字段及用户字段的查询值；然后依据映射关系，将数据查询请求中携带的用户字段映射为数据库字段，将用户字段的查询值作为数据库字段的查询值，构成数据库查询语句。

具体地，在对数据查询请求进行解析，得到数据查询请求中携带的用户字段及用户字段的查询值时，可具体包括：

采用语法分析器对数据查询请求进行分析，得到数据查询请求的语法树；

采用词法分析器对语法树进行词法分析，得到数据查询请求中携带的用户字段及用户字段的查询值。

例如，用户输入的数据查询请求为“找出张三为作者的文章”。对包含有这一数据查询请求进行解析，首先进行分词，采用语法分析器进行分析，形成语法树。例如，将上述待查询内容分解为“找出”、“张三”、“为”、“作者”、“的”、“文章”。进行语法分析可知，“找出”体现数据查询的目的——查询检索，“张三”体现查询的关键字——是人的姓名，是字符串型数据，“为”体现查询的要求——等于，“作者”体现查询的关键字所对应的属性——查找出的文章的“作者”这一属性的值应为“张三”，“的”为虚词，无需考虑，“文章”体现查找的对象——查询的最终呈现形式为文本。

在此基础上进行词法分析，确定数据查询请求中携带的用户字段及用户字段的查询值。以上述数据查询请求“找出张三为作者的文章”为例，以用户字段的形式体现该数据查询请求，可表达为：

“writer”:“zhangsan”

结合图2示例，用户字段“writer”与数据库字段“index_string”存在映射关系，该数据库字段为倒排索引类型的字段，可以根据字段的值查找对应的记录。则基于该映射关系，将数据查询请求中携带的用户字段映射为数据库字段，将用户字段的查询值作为数据库字段的查询值，构成数据库查询语句如下：

“index_string”:“zhangsan”

S108：依据数据库查询语句，在数据库中查询得到第一查询结果；其中，第一查询结果体现为数据库字段的形式。

将数据库查询语句“index_string”:“zhangsan”发送到数据库中进行查询，即查找数据库字段的值等于“zhangsan”的记录，得到第一查询结果，这一查询结果体现为数据库字段的形式，用户无法直接识别。

S109：依据映射关系，将第一查询结果转换为第二查询结果；其中，第二查询结果体现为用户字段的形式。

在执行步骤108的基础上，依据用户字段“writer”与数据库字段“index_string”间的映射关系，再将体现为数据库字段形式的第一查询结果转换为体现为用户字段形式的第二查询结果，以便用户识别，从而完成依据数据查询请求进行的查询过程。

需要说明的是，实施例1所提供方法的各步骤的执行主体可以根据系统的整体架构进行划分，可以是同一设备，或者，也可由不同设备作为执行主体。具体的执行主体分配，将在实施例3中详细举例说明。

基于实施例1中给出的具体方案实施，在接收到数据存储请求时，依据预设的映射规则建立用户字段与数据库字段间的映射关系，从而能够在此基础上将待存储数据转换为索引数据进行存储。采用该方案，对待存储数据的数据结构可以不做要求，当待存储数据为非结构化数据时，本申请实施例提供的方法能够根据待存储数据动态地建立用户字段与数据库字段的映射关系，将非结构化的用户数据转换为符合数据库存储结构、体现为数据库字段形式的索引数据进行存储，从而实现了对非结构化数据的存储。因此，相比于现有技术，本申请实施例使得数据库具备了非结构化数据的存储能力，相对于结构化存储系统具备了易使用、易扩展、易维护等诸多优点，能够降低用户的使用成本，提高用户体验，具体如下：

(1)易使用。采用本申请实施例无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式，而结构化存储系统则需要事先定义表结构。

(2)易扩展。本申请实施例支持字段的无限扩展，而结构化系统则有字段限制。

(3)易维护。采用本申请实施例，修改数据结构能动态生效，而不需要修改已有的数据。而在结构化存储系统里，增删字段非常麻烦，如果是非常大数据量的表，通常不允许变更字段。

实施例2

本申请实施例还提供了一种数据查询方法，包括：

接收数据查询请求；其中，数据查询请求中包含用户字段；

依据用户字段与数据库字段的映射关系，将数据查询请求映射为数据库查询语句；其中，数据查询请求体现为用户字段的形式，数据库查询语句体现为数据库字段的形式；

依据数据库查询语句，在数据库中查询得到第一查询结果；其中，数据库中存储有体现为数据库字段的形式的索引数据，第一查询结果体现为数据库字段的形式；

依据映射关系，将第一查询结果转换为第二查询结果；其中，第二查询结果体现为用户字段的形式。

本实施例提供的方法基于已经保存的用户字段与数据库字段的映射关系，完成非结构化查询语句的处理。本实施例中所用到的映射关系的建立过程与实施例1中相关部分相同，此处不再赘述。

实施例3

本申请实施例还提供了一种数据处理系统，参见图4所示，包括：

请求接收模块101，用于接收包含有待存储数据的数据存储请求；

映射关系确定模块102，用于当请求接收模块接收到包含有待存储数据的数据存储请求时，依据预设映射规则，确定待存储数据中的用户字段与数据库字段之间的映射关系；其中，待存储数据为非结构化数据；

第一转换模块103，用于依据映射关系，将待存储数据转换为索引数据；其中，索引数据体现为数据库字段的形式；

存储模块104，用于将索引数据存储在数据库中。

进一步地，该系统还可以包括：

数据中心，用于保存映射关系，以便当接收到数据查询请求时实现用户字段与数据库字段之间的转换。

进一步地，在本申请实施例还提供的数据处理系统中，请求接收模块，还用于接收数据查询请求；且该系统还可包括：

第二转换模块，用于当接收到数据查询请求时，依据映射关系，将数据查询请求映射为数据库查询语句；其中，数据查询请求体现为用户字段的形式，数据库查询语句体现为数据库字段的形式；

查询模块，用于依据数据库查询语句，在数据库中查询得到第一查询结果；其中，第一查询结果体现为数据库字段的形式；

第三转换模块，用于依据映射关系，将第一查询结果转换为第二查询结果；其中，第二查询结果体现为用户字段的形式。

基于此，本实施例提供的数据处理系统，能够自动建立用户字段和数据库字段之间的映射关系，实现非结构化数据的存储和查询。在进行非结构化数据的存储时，能够自动建立映射关系，将非结构化数据转换为索引数据加以存储；在基于非结构化数据进行查询时，能够通过调用用户字段和数据库字段间的映射关系，实现对数据库中索引数据的查询，并将查询结果转换为用户可识别的、以用户字段的形式体现的查询结果，供用户使用。因此，用户访问基于本申请各实施例所提供的数据处理方法或数据处理系统构建的数据库时，可以发送任意格式的文档而不需要事先定义表结构(Free-Schema)，从而能够有效降低用户使用成本，提高产品的用户体验。

需要说明的是，本申请各实施例提供的方法或系统，能够用于现有技术中基于结构化数据的数据系统，使得面向结构化数据的数据库系统具备非结构化数据的存储检索能力。本申请实施例不仅可用于搜索系统，同时适用于关系型数据库、列式数据库、KV等各类存储系统。

实施例4

基于实施例1～3给出的方法和系统，本实施例将以搜索系统为例，详细说明本申请实施例所提供的数据处理方法和系统的在搜索引擎中的实际应用。

图5给出了应用本申请实施例所提供的数据处理方法和系统的一种搜索系统的框架示意图。该搜索系统采用Http RESTful这一设计规范构建。客户编程工具包、软件开发工具包以及浏览器等应用级程序通过调用操作系统的API接口使操作系统去执行应用程序的命令。本申请实施例系统的数据处理系统包含在底层操作系统中，根据用户的指令选择不同的功能模块。若用户发出表示要进行数据存储的“插入”指令，则写模块(Index)基于该指令进行索引数据的存储；若用户发出表示要进行数据查询的“查询”指令，则查询模块(Search)基于该指令进行数据查询检索。为了实现本申请所提供的数据结构的自动映射，基于用户字段和数据库字段的映射关系实现对非结构化数据的存储和查询，在该系统中还包括元数据中心(Meta Center)，用于存储上述映射关系。

下面详细说明写模块(Index)、元数据中心(Meta Center)和查询模块(Search)这三个核心模块在进行数据存储和数据查询时的配合过程。

图6给出了数据写入过程的数据流转示意图，具体过程如下：

第一步，用户发送JSON数据写索引请求到写模块节点(Indexer node)，写模块节点(Indexer node)将该请求路由到包含在索引处理模块(Indexer)中的元数据处理模块(MetaService)；

第二步，元数据处理模块(MetaService)将每次过来的JSON数据进行结构分析，并形成用户字段与引擎字段的映射关系(Mapping)；

第三步，通过用户字段与引擎字段的映射关系(Mapping)将用户数据转换为引擎宽表格式的文档数据(即引擎格式数据，IndexDoc)以发往底层搜索引擎(例如搜索引擎HA3)实现索引的存储。

在第二步形成用户字段与引擎字段的映射关系之后，元数据中心(MetaCenter)可以将Mapping信息保存到分布式元存储模块(MetaStore)中，当Mapping发生变更时也会通知其他所有元存储模块节点更新Meta信息，从而实现了一个分布式的元数据资源中心，以便实现Meta信息的备份。具体地，可以采用zookeeper+分布式内存技术实现。

图7给出了数据查询检索过程的数据流转示意图，具体过程如下：

第一步，用户发送查询语句到查询模块节点(Searcher node)，查询模块节点(Searcher node)将该请求路由到查询分析器(QueryParser)；

第二步，查询分析器(QueryParser)调用语法解析器将用户发送的查询语句翻译成引擎查询语句(Real Query)；

第三步，将引擎查询语句(Real Query)发送到底层搜索引擎(例如HA3)进行搜索，得到引擎字段格式的引擎原始结果(RealQueryResult)；

第四步，将引擎原始结果(RealQueryResult)发送到结果解析器，结果解析器通过调用元数据处理模块(MetaService)进行Mapping，从而将引擎原始结果(RealQueryResult)中的引擎字段转换为用户字段，形成用户字段格式的用户查询结果(UserQueryResult)；

第五步，将用户字段格式的用户查询结果(UserQueryResult)返回给用户，供用户使用。

进行以上第二步时所调用的语法解析器中，可具体包括：

语法分析器Antlr，用于针对用户发送的查询语句产生的语法树；

词法分析器Lexer，用于通过对语法树进行tokens分析得到用户发送的查询语句中所有的用户字段，

元数据Meta，用于提供用户字段与引擎字段的映射信息，

转换器Converter，用于将用户发送的查询语句依据上述映射信息(mapping信息)翻译成引擎字段格式的引擎查询语句(Real Query)。

结合实施例1中给出的数据处理方法，可以理解到，图1所示实施例中，步骤S101可以由本实施例中的写模块节点(Indexer node)具体执行，步骤S102可由本实施例中的元数据处理模块(MetaService)具体执行，步骤S103和步骤S104可由本实施例中的索引处理模块(Indexer)具体执行。图3所示实施例中，步骤S106可由本实施例中的查询模块节点(Searcher node)具体执行，步骤S107可由本实施例中的查询分析器(QueryParser)通过调用语法解析器执行，步骤S108和步骤S109可由本实施例中的查询模块节点(Searchernode)执行图7中的第三步和第四步实现。

基于本实施例给出的具体方案，搜索系统具备了非结构化数据的存储和查询能力，相对于结构化存储系统具备了易使用、易扩展、易维护等诸多优点，能够降低用户的使用成本，提高用户体验，具体如下：

(1)易使用。采用本申请实施例无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式，而结构化存储系统则需要事先定义表结构。

(2)易扩展。本申请实施例支持字段的无限扩展，而结构化系统则有字段限制。

(3)易维护。采用本申请实施例，修改数据结构能动态生效，而不需要修改已有的数据。而在结构化存储系统里，增删字段非常麻烦，如果是非常大数据量的表，通常不允许变更字段。

需要说明的是，本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (13)

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

当接收到包含有待存储数据的数据存储请求时，依据预设映射规则，确定所述待存储数据中的用户字段与数据库字段之间的映射关系；其中，所述待存储数据为非结构化数据，所述预设映射规则包括：当用户字段的类型为字符串型、长整型或者双精度型时，将用户字段映射为倒排索引类型和/或正排索引类型的数据库字段；当用户字段的类型为文本型时，将用户字段映射为文本分词类型的数据库字段；

依据所述映射关系，将所述待存储数据中的用户字段映射为数据库字段，依据所述用户字段的写入值确定所述数据库字段的写入值，所述数据库字段和所述数据库字段的写入值构成索引数据；其中，所述索引数据体现为所述数据库字段的形式；

将所述索引数据存储在数据库中。

2.按照权利要求1所述方法，其特征在于，当接收到包含有待存储数据的数据存储请求时，依据预设映射规则，确定所述待存储数据中的用户字段与数据库字段之间的映射关系，具体包括：

当接收到包含有待存储数据的数据存储请求时，对所述待存储数据进行数据结构分析，确定所述待存储数据中所包含的用户字段；

依据所述用户字段以及所述预设映射规则，确定所述用户字段与所述数据库字段之间的所述映射关系。

3.按照权利要求1所述方法，其特征在于，在依据预设映射规则，确定所述待存储数据中的用户字段与数据库字段之间的映射关系之后，还包括：

保存所述映射关系，以便当接收到数据查询请求时实现所述用户字段与所述数据库字段之间的转换。

4.按照权利要求3所述方法，其特征在于，所述方法还包括：

当接收到所述数据查询请求时，依据所述映射关系，将所述数据查询请求映射为数据库查询语句；其中，所述数据查询请求体现为用户字段的形式，所述数据库查询语句体现为数据库字段的形式；

依据所述数据库查询语句，在所述数据库中查询得到第一查询结果；其中，所述第一查询结果体现为所述数据库字段的形式；

依据所述映射关系，将所述第一查询结果转换为第二查询结果；其中，所述第二查询结果体现为所述用户字段的形式。

5.按照权利要求4所述方法，其特征在于，依据所述映射关系，将所述数据查询请求映射为数据库查询语句，具体包括：

对所述数据查询请求进行解析，得到所述数据查询请求中携带的所述用户字段及所述用户字段的查询值；

依据所述映射关系，将所述数据查询请求中携带的所述用户字段映射为数据库字段，将所述用户字段的查询值作为所述数据库字段的查询值，构成所述数据库查询语句。

6.按照权利要求5所述方法，其特征在于，对所述数据查询请求进行解析，得到所述数据查询请求中携带的所述用户字段及所述用户字段的查询值，具体包括：

采用语法分析器对所述数据查询请求进行分析，得到所述数据查询请求的语法树；

采用词法分析器对所述语法树进行词法分析，得到所述数据查询请求中携带的所述用户字段及所述用户字段的查询值。

7.按照权利要求3所述方法，其特征在于，采用分布式数据中心保存所述映射关系；则当所述映射关系发生变更时，所述方法还包括：

通知所述分布式数据中心的各节点更新所保存的映射关系。

8.按照权利要求1~7之任一所述方法，其特征在于，所述预设映射规则，具体包括：

当所述用户字段的类型为字符串型、长整型或者双精度型时，将该用户字段映射为倒排索引类型和/或正排索引类型的数据库字段；或

当所述用户字段的类型为文本型时，将该用户字段映射为文本分词类型的数据库字段。

9.按照权利要求1~7之任一所述方法，其特征在于，所述待存储数据为JSON格式的非结构化数据。

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

接收数据查询请求；其中，所述数据查询请求中包含用户字段；

依据用户字段与数据库字段的映射关系，将所述数据查询请求映射为数据库查询语句；其中，所述数据查询请求体现为所述用户字段的形式，所述数据库查询语句体现为所述数据库字段的形式，所述映射关系依据预设映射规则确定得到，所述预设映射规则包括：当用户字段的类型为字符串型、长整型或者双精度型时，将用户字段映射为倒排索引类型和/或正排索引类型的数据库字段；当用户字段的类型为文本型时，将用户字段映射为文本分词类型的数据库字段；

依据所述数据库查询语句，在数据库中查询得到第一查询结果；其中，所述数据库中存储有体现为所述数据库字段的形式的索引数据，所述第一查询结果体现为所述数据库字段的形式；

依据所述映射关系，将所述第一查询结果转换为第二查询结果；其中，所述第二查询结果体现为所述用户字段的形式。

11.一种数据处理装置，其特征在于，包括：

请求接收模块，用于接收包含有待存储数据的数据存储请求；

映射关系确定模块，用于当所述请求接收模块接收到包含有待存储数据的数据存储请求时，依据预设映射规则，确定所述待存储数据中的用户字段与数据库字段之间的映射关系；其中，所述待存储数据为非结构化数据，所述预设映射规则包括：当用户字段的类型为字符串型、长整型或者双精度型时，将用户字段映射为倒排索引类型和/或正排索引类型的数据库字段；当用户字段的类型为文本型时，将用户字段映射为文本分词类型的数据库字段；

第一转换模块，用于依据所述映射关系，将所述待存储数据中的用户字段映射为数据库字段，依据所述用户字段的写入值确定所述数据库字段的写入值，所述数据库字段和所述数据库字段的写入值构成索引数据；其中，所述索引数据体现为所述数据库字段的形式；

存储模块，用于将所述索引数据存储在数据库中。

12.按照权利要求11所述装置，其特征在于，所述装置还包括：

数据中心，用于保存所述映射关系，以便当接收到数据查询请求时实现所述用户字段与所述数据库字段之间的转换。

13.按照权利要求12所述装置，其特征在于，

所述请求接收模块，还用于接收所述数据查询请求；

所述装置还包括：

第二转换模块，用于当接收到所述数据查询请求时，依据所述映射关系，将所述数据查询请求映射为数据库查询语句；其中，所述数据查询请求体现为用户字段的形式，所述数据库查询语句体现为数据库字段的形式；

查询模块，用于依据所述数据库查询语句，在所述数据库中查询得到第一查询结果；其中，所述第一查询结果体现为所述数据库字段的形式；

第三转换模块，用于依据所述映射关系，将所述第一查询结果转换为第二查询结果；其中，所述第二查询结果体现为所述用户字段的形式。

Images