CN110727656A

CN110727656A - 一种数据的分表方法、装置、电子设备以及可读存储介质

Info

Publication number: CN110727656A
Application number: CN201910911518.3A
Authority: CN
Inventors: 赵志强
Original assignee: Beike Technology Co Ltd
Current assignee: Beike Technology Co Ltd
Priority date: 2019-09-25
Filing date: 2019-09-25
Publication date: 2020-01-24

Abstract

本发明公开了一种数据的分表方法、装置、电子设备以及可读存储介质，该方法包括：接收待分表数据和具有预设参数的基表，根据所述预设参数按预定规则得到所述待分表数据的不同预置分表策略，根据分配的所述预置分表策略对所述待分表数据按照所述基表的所述数据结构和所述基表名称建立分表。根据不同的预置分表策略对所述待分表数据按照所述基表建立分表。提供了一种数据分表的方法，以便于快速对不同需求业务进行快速的分表，以使用户可以通过自动建立分表和对应的索引进行查询。解决了现有技术中每次新业务查询都需要重新进行开发的技术问题。

Description

一种数据的分表方法、装置、电子设备以及可读存储介质

技术领域

本发明涉及数据处理领域，尤其是指一种分表方法、装置、电子设备以及可读存储介质。

背景技术

目前，在大数据环境下，根据用户的请求对数据实现分表存在着系统处理压力大，被迫进行重新的数据架构设计，每一次新的业务请求都会对应不同的新设计，简言之，都需要重新开发对应数据的查询功能，大幅降低了工作效率，开发人员需要对数据的查询功能花费大量的时间进行底层技术的设计。

所以发明人发现现有技术中至少存在如下问题，对不同用户请求的需要重新开发对应的分表和查询功能，开发人员需要对数据的查询功能花费大量的时间进行底层技术的设计，进而导致工作效率大幅降低。

发明内容

本申请提供了一种数据的分表方法，其目的在于将待分表数据按基表重新汇总进行分表，解决了现有技术需要不断根据不同的业务开发不同分表功能的技术问题。

该方法包括：

接收待分表数据和基表，其中，所述基表具有预建分表的数据结构以及用于数据分类的基表名称，以及预设参数；

根据所述预设参数按预定规则得到所述待分表数据的不同预置分表策略，其中，所述预定规则为不同所述预设参数分配不同所述预置分表策略的对应规则；

根据分配的所述预置分表策略对所述待分表数据按照所述基表的所述数据结构和所述基表名称建立分表。

可选地，所述根据分配的所述预置分表策略对所述待分表数据按照所述基表的所述数据结构和所述基表名称建立分表步骤后，该方法包括：

判断所述分表是否存在，

如果所述分表存在，对所述分表进行保存；

如果所述分表不存在，对所述待分表数据按照预定的后续分表配置建立后续分表，且将所述后续分表保存。

可选地，所述接收待分表数据和基表，其中，所述基表具有预建分表的数据结构以及用于数据分类的基表名称，以及预设参数步骤前，该方法还包括：

接收用户请求；

根据用户请求从预建的数据源中获取所述待分表数据和对应的所述基表。

可选地，所述分表策略包括不分表和按数据类型分表，以及按时间分表。

可选地，所述根据不同的预置分表策略对所述待分表数据按照所述基表建立分表步骤后，该方法还包括：

接收多项用户查询请求；

根据多项所述用户请求对所述分表进行并行查询。

本申请提供了一种数据的分表装置，该装置包括：

接收模块，用于接收待分表数据和基表，其中，所述基表具有预建分表的数据结构和用于数据分类的基表名称，以及预设参数；

判断模块，用于根据所述预设参数按预定规则得到所述待分表数据的不同预置分表策略，其中，所述预定规则为不同所述预设参数分配不同所述预置分表策略的对应规则；

分表模块，用于根据分配的所述预置分表策略对所述待分表数据按照所述基表的所述数据结构和所述基表名称建立分表。

可选地，该装置包括：

所述判断模块，还用于判断所述分表是否存在，

如果所述分表存在，对所述分表进行保存；

可选地，该装置包括：

所述接收模块，还用于接收用户请求；

获取模块，用于根据用户请求从预建的数据源中获取对应的所述待分表数据和所述基表。

可选地，该装置包括：

所述接收模块，还用于接收多项用户查询请求；

查询模块，用于根据多项所述用户请求对所述分表进行并行查询。

本申请提供了一种电子设备，所述装置包括：处理器和存储器；

所述存储器中存储有可被所述处理器执行的应用程序，用于使得所述处理器执行任一项所述的数据的分表方法的步骤。

本申请还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现任一项所述的数据的分表方法的步骤。

如上可见，基于上述实施例，接收待分表数据和基表，根据预定条件判断得到不同基表对应的分表策略，根据得到的分表策略对待分表数据进行分表，解决了现有技术中针对每次的业务需要重新开发建表和查询功能的技术问题。

附图说明

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

图1为本申请一种实施例中数据的分表方法流程100的示意图；

图2为本申请一种实施例中分表的示意图；

图3为一种实施例中数据的分表方法流程200的示意图；

图4为一种实施例中数据的分表方法流程300的示意图；

图5为一种实施例中数据的分表装置的架构示意图。

具体实施方式

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

本申请属于大数据领域中的分表查询，其目的主要在于提升系统性能。本申请可以应用于基础信息、网络监控两个子系统中。

基础信息和网络监控系统的主要目标是实时监控APP端的运行情况，如APP启动慢、崩溃、响应慢等问题，网络监控的特点在于数据量大、数据复杂且多变、数据查询及保存实时性要求高，基于以上特点及项目的迫切性，最终可以选择MongoDB作为存储引擎。(MongoDB是一个基于分布式文件存储的数据库。)

MongoDB作为大数据存储领域的流行的文档型数据库之一，应用场景较多，MongoDB的Replica-Set集群模式兼具高可用和高可扩展性，目前MongoDB的主要现状如下：

第一、社区活跃，但与MySQL不同的是，目前MongoDB尚无一款分表策略组件；

第二、数据量增大后，用户迫于系统压力，被迫进行拆表设计，导致用户重新开发现有业务查询语句，大大降低了工作效率；

第三、用户需关注MongoDB底层技术细节，无法将精力集中于业务开发上，降低用户工作效率。

鉴于以上问题，同时考虑到系统中多个模块会使用分表查询汇总的功能，便急需一种进行分表、汇总查询的工具封装，旨在提升开发效率，降低用户的技术难度，使用户更关注于业务需求上。

下面以具体实施例对本发明的技术方案进行详细说明。下面几个具体实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

图1为本申请一种实施例中数据的分表方法流程100的示意图，图2为本申请一种实施例中分表的示意图。如图1和图2所示，在一实施例中，本申请提供了一种数据的分表方法，该方法包括：

S101，接收待分表数据和基表，其中，所述基表具有预建分表的数据结构以及用于数据分类的基表名称，以及预设参数；

在本步骤中，接收待分表数据和基表，基表其本质为具有基表名称的数据表格，也可以理解为一个数据结构，所谓的数据表格即为分表的表框架，基表名称则可以是一个标识。比如A-第一业务，那么在后续的分表中，则会将第一业务的待分表数据分到该基表中。所述预设参数可以理解为一个传递参数。

S102，根据所述预设参数按预定规则得到所述待分表数据的不同预置分表策略，其中，所述预定规则为不同所述预设参数分配不同所述预置分表策略的对应规则；

在本步骤中，不同的传递参数对应着不同的预置分表策略。那么，根据接收基表中不同的传递参数得到不同的预置分表策略。

S103，根据分配的所述预置分表策略对所述待分表数据按照所述基表的所述数据结构和所述基表名称建立分表。

在本步骤中，根据得到的不同预置分表策略对待分表数据按照基表的数据结构建立分表。此处需要指出的建立分表不一定会成功，这里只是执行根据不同分表策略。

在本实施例中，提供了一种数据分表的方法，以便于快速对不同需求业务进行快速的分表，以使用户可以通过分表建立对应的索引进行查询。首选，接收待分表数据和基表，其中的基表具有后续建立分表的数据结构，以及用于数据分类的基表名称。需要指出的是所谓的基表名称可以理解为一个业务需求的标识，当用户提出请求时，系统则会从数据库中选取出与该业务对应的基表，选取的依据则可以理解为基表名称。比如，基表名称为A-第一业务，那么当用户想查询第一业务相关的内容时，则通过预定用户操作则可以选取出A-第一业务基表名称对应的基表。需要指出的是，上述方式不但可以基于用户的预定操作，也可以基于系统本身的自动配置。然后，判断所述基表的预设参数得到不同的预置分表策略，其中，不同的所述预设参数对应不同的预置分表策略；可以将基表的预设参数理解为在基表中设置的传递参数，具有不同的传递参数则会对应不同的预置分表策略，当然也可以用过其他方式建立分表策略与基表的对应关系。最后根据分表策略对待分表数据按照基表的数据结构建立分表，建立分表的过程则是将待分表数据按照基表中的数据结构进行对应的赋值。需要指出的是此处的分表只是执行分表的步骤，并非一定会生成分表。在分表的过程中，其本质是将原先的待分表数据从原先的数据框架中打破，再根据新的基表进行数据重组，是一种数据拆分并重组的具体实施方式。拆分后如果建立了分表，则可以建立查询汇总的索引，用于用户的查询使用。比如，所述根据不同的预置分表策略对所述待分表数据按照所述基表建立分表步骤后，接收具有关键字的查询指令，根据所述查询指令调用所述分表中与所述关键字对应的待分表数据作为查询结果。如图2所示，提供了一种基表，该基表中示出了基表中的数据结构和基表名称。

在一实施例中，所述根据分配的所述预置分表策略对所述待分表数据按照所述基表的所述数据结构和所述基表名称建立分表步骤后，该方法包括：

判断所述分表是否存在，

如果所述分表存在，对所述分表进行保存；

在本实施例中提供了一种后续进行数据保存的具体实施方式。根据之前的步骤，已经对待分表数据进行了分表的操作，正如前文所述，分表操作未必一定会生成分表，其原因包括有两种，第一是分表策略中本身就包括不分表的策略，第二是待分表数据并不与基表的基表名称具有对应的数据关系，或者由于某种人为的配置原则，导致待分表数据无法进行分表。那么，对于建立分表的待分表数据则直接进行数据存储，对于未分表的待分表数据根据后续分表配置建立后续分表。此处的后续分表配置可以是在创建表时进行的配置，也可以是后期保存步骤中现行配置，但不管是何种情况，都会对未建立分表的待分表数据进行再次分表，得到后续分表并予以保存。另外，需要指出的是本实施例中的保存数据可以应用MongoDB进行分布式存储。

图3为本申请一种实施例中数据的分表方法流程200的示意图，如图3所示，在一实施例中，所述接收待分表数据和基表，其中，所述基表具有预建分表的数据结构和用于数据分类的基表名称，以及预设参数步骤前，该方法还包括：

S201，接收用户请求；

在本步骤中，接收用户请求，以作为获取调用待分表数据和基表的依据。

S202，根据用户请求从预建的数据源中获取对应的所述待分表数据和所述基表。

在本步骤中，用户请求对应着基表名称中的标识，比如，基表名称为A-第一业务，而用户请求对应第一业务的标识，因此会将数据源中具有第一业务标识基表名称的基表获取出来，待分表数据可以和第一业务有关，也可能无关，需要进行配置。

在本实施例中提供了一种根据用户请求获取待分表数据和对应基表的具体实施方式，通过基表名称和用户请求的对应关系获取基表。

在一实施例中，所述分表策略包括不分表和按数据类型分表，以及按时间分表。

在本实施例中，提供了分表策略的三种类型，即不分表、按数据类型分表，以及按时间分表。

其中，不分表的情况是因为基表的业务类型对应的情况，比如域名信息表、版本信息表，该类型的表数据较少，分表反而不利于数据存储和查询。

按数据类型分表的情况主要体现在按APP端的类型划分请求的URL，出现该情况的原因主要在于业务的需求，目前APP端要求查看各APP的所有请求URL，而各APP端访问的接口服务有很大区别，因此该工具提供了此种类型的分表策略。

按时间分表的情况主要体现在网络请求数据按天分表，分表的原因在于用户在查询数据的时候查询请求很少跨天且拆分后单表数据量降低，有利于数据的快速查询和保存。

以上均是对三种分表策略的示例性解释，并非对本实施例的具体限定。

图4为申请一种实施例中数据的分表方法流程300的示意图。如图4所示，在一实施例中，所述根据不同的预置分表策略对所述待分表数据按照所述基表建立分表步骤后，该方法还包括：

S301，接收多项用户查询请求；

在本步骤中经过之前的分表步骤后，可以接收多项的用户请求，对应多项的用户请求可以得到多项的业务，这些业务会与基表名称同时对应。比如基表名称为A-第一业务、第二业务。

S302，根据多项所述用户请求对所述分表进行并行查询。

在本步骤中如果多项的用户请求和基表名称可以同时对应，那么可以在建立分表后实行并行查询。

在本实施例中提供了一种数据分表后进行并行查询的具体实施方式。

本申请还可以理解为在设计通用型流式数据查分及查询汇总工具，主要考虑以下两点：

第一、简单易用，屏蔽底层查分、查询的技术细节。

工具应做到即插即用，提供简单易用的接口，此外可针对不同的数据采取不同的拆分策略，做到无人干预(即不需用户手动建表、建索引等)。

第二、分表查询与单表查询效率接近。

工具在拆分后，用户在查询时，工具应能主动识别查询的数据源，通过采用并行操作，达到分表查询与单表查询相近的效率。

第三、用户无感知。

即用户在拆分前和拆分后的查询、保存语句不需要修改或少量修改，且查询出的结果相同。

另外，本申请所述的方法步骤除了可以用数据处理程序来实现，还可以由硬件来实现，例如，可以由逻辑门、开关、专用集成电路(ASIC)、可编程逻辑控制器和嵌微控制器等来实现。因此这种可以实现本申请所述方法的硬件也可以构成本申请。

本申请附图中的流程图和框图，示出了按照本申请公开的各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或者代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应该注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同附图中所标准的顺序发生。例如，两个连接地表示的方框实际上可以基本并行地执行，它们有时也可以按照相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或者流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，即使这样的组合或结合没有明确记载于本申请中。特别地，在不脱离本申请精神和教导的情况下，本申请的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，所有这些组合和/或结合均落入本申请公开的范围。

本文中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思路，并不用于限制本申请。对于本领域的技术人员来说，可以依据本发明的思路、精神和原则，在具体实施方式及应用范围上进行改变，其所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

基本原理和工作过程：

以下通过房屋买卖中的实际业务对本申请进行进一步的解释说明。需要指出的是以下只是对本申请的解释说明，并非是对本申请的具体限定。

接收多项用户请求；

首先，接收用户请求，比如用户想查询三环上价格在300到400万的房源。此时，三环是地理位置的业务需求，而300到400万是价格上的业务需求。需要指出的是用户的请求未必一定是多项的，也可以是单项的，本步骤只是以多项业务为例进行说明。

根据用户请求从数据源中获取所述待分表数据和对应的所述基表；

此时地理位置和价格区间可以理解为不同的业务需求，在基表中以基表名称的方式体现，基表名称可以理解为具体业务需求的标识，比如A-三环-300至400，也就是说，该基表的数据是在三环地理位置，价格在300万至400万之间。

待分表数据可以理解为按房源进行分类，并具有业务需求的具体数据。

比如，第一房源，地理位置四环，价格600万。

第二房源，地理位置三环，328万。

对于基表来说，其基表名称就是对业务进行的分类，当然基表是预建具有数据结构以表格形成存在的分类集合。

接收待分表数据和基表，其中，所述基表具有预建分表的数据结构和用于数据分类的基表名称，以及预设参数；

基于前面步骤的铺垫，接收待分表数据和基表，以准备进行后续步骤的处理。

判断所述基表的预设参数得到不同的预置分表策略，其中，不同的所述预设参数对应不同的预置分表策略；

此时，判断所述基表的预设参数，不同的所述预设参数对应不同的预置分表策略，此处可以理解为基表中设置的预设参数具有传递参数k，通过传递参数k的值来判断采用何种不同的分表策略。分表策略可以分为不分表，按数据类型分表，以及按时间分表，分表策略的配置取决于不同业务需求相关待分表数据的特性。

基表的基表名称会将业务需求对应的进行标识。比如，地理位置和价格。那么地理位置和价格对应的传递参数k为何值，就决定了后面采用那种预置分表策略。上文中对于何种业务需求对应的待分表数据采用何种分表策略进行了阐述，在此就不再赘述了。

根据不同的预置分表策略对所述待分表数据按照所述基表的数据结构建立分表。

得到具体的预置分表策略后，则根据预置分表策略对待分表数据建立分表。需要指出的是此时的分表只是执行相应步骤，并非是一定会生成分表，因为显然分表策略中具有不分表的可能，另外也不一定有对应的待分表数据可供分表。

判断所述分表是否存在，

如果所述分表存在，对所述分表进行保存；

在执行完分表步骤后，要对分表或者未被分表的待分表数据进行保存，如果已经分表则保存分表即可，如果没有分表，将待分表数据按照预定的配置建立后续分表，并将后续分表进行保存，保存前无论是分表还是后续分表都需要进行建立索引，以便后续的查询工作。

接收多项用户查询请求；

比如上述的地理位置和价格，输入三环和300至400万的查询请求。

根据多项所述用户查询请求对所述分表进行并行查询。

本申请提供对于多项用户查询请求的并行查询功能。如果同时进行查询，则可以得到在三环上300至400万的房源。

图5为一种实施例中数据的分表装置的架构示意图。如图5所示，在一实施例中，本申请还提供了一种数据的分表装置，该装置包括：

接收模块101，用于接收待分表数据和基表，其中，所述基表具有预建分表的数据结构和用于数据分类的基表名称，以及预设参数；

判断模块102，用于根据所述预设参数按预定规则得到所述待分表数据的不同预置分表策略，其中，所述预定规则为不同所述预设参数分配不同所述预置分表策略的对应规则；

分表模块103，用于根据分配的所述预置分表策略对所述待分表数据按照所述基表的所述数据结构和所述基表名称建立分表。

在一实施例中，该装置包括：

所述判断模块102，还用于判断所述分表是否存在，

如果所述分表存在，对所述分表进行保存；

在一实施例中，该装置包括：

所述接收模块101，还用于接收用户请求；

获取模块104，用于根据用户请求从预建的数据源中获取对应的所述待分表数据和所述基表。

在一实施例中，该装置包括：

所述接收模块101，还用于接收多项用户查询请求；

查询模块105，用于根据多项所述用户请求对所述分表进行并行查询。

在一实施例中，本申请提供了一种数据的分表装置，所述装置包括：处理器和存储器；

所述存储器中存储有可被所述处理器执行的应用程序，用于使得所述处理器执行如任一项所述的数据的分表方法的步骤。

在一实施例中，本申请提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现任一项所述的数据的分表方法的步骤。

实际应用中，所述的计算机可读介质可以是上述实施例中描述的设备/装置/系统中所包含的，也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或多个程序被执行时，实现所描述的数据的分表装置进行数据的分表方法。

根据本申请公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件，或者上述的任意合适的组合，但不用于限制本申请保护的范围。在本申请公开的实施例中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

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

Claims

1.一种数据的分表方法，其特征在于，该方法包括：

2.根据权利要求1所述的数据的分表方法，其特征在于，所述根据分配的所述预置分表策略对所述待分表数据按照所述基表的所述数据结构和所述基表名称建立分表步骤后，该方法包括：

判断所述分表是否存在，

如果所述分表存在，对所述分表进行保存；

3.根据权利要求1所述的数据的分表方法，其特征在于，所述接收待分表数据和基表，其中，所述基表具有预建分表的数据结构和用于数据分类的基表名称，以及预设参数步骤前，该方法还包括：

接收用户请求；

4.根据权利要求1所述的数据的分表方法，其特征在于，所述分表策略包括不分表和按数据类型分表，以及按时间分表。

5.根据权利要求1所述的数据的分表方法，其特征在于，所述根据不同的预置分表策略对所述待分表数据按照所述基表建立分表步骤后，该方法还包括：

接收多项用户查询请求；

根据多项所述用户查询请求对所述分表进行并行查询。

6.一种数据的分表装置，其特征在于，该装置包括：

7.根据权利要求6所述的数据的分表装置，其特征在于，该装置包括：

所述判断模块，还用于判断所述分表是否存在，

如果所述分表存在，对所述分表进行保存；

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

所述接收模块，还用于接收用户请求；

9.一种电子设备，其特征在于，所述电子设备包括：处理器和存储器；

所述存储器中存储有可被所述处理器执行的应用程序，用于使得所述处理器执行如权利要求1至5中任一项所述的数据的分表方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现权利要求1至5任一项所述的数据的分表方法的步骤。