CN115114354A - 一种分布式数据存储及查询系统 - Google Patents

Abstract

本申请公开了一种分布式数据存储及查询系统，包括运行模块包括查询优化器、查询调度器和存储优化器；存储模块包括优化元信息、列式存储数据和行式存储数据；查询优化器内置多种查询优化引擎，用于根据优化元信息对传入的SQL语句进行优化，并调度执行请求；查询调度器用于执行实际的调度请求，并将调度请求分发列式存储数据或行式存储数据中进行查询；存储优化器用于分析优化元信息，以平衡查询性能与存储空间生成最优解，并执行优化迁移。本申请提供了多层优化器，包括静态分析、由周期分析、业务分析和权重匹配组成的动态解析，解决了复杂多变的企业应用中的查询效率问题；通过提前迁移数据，在保证业务性能的同时，降低存储成本和硬件成本。

Description

一种分布式数据存储及查询系统

技术领域

本申请涉及分布式数据处理技术领域，尤其涉及一种分布式数据存储及查询系统。

背景技术

企业应用软件HTAP，是一款需要对数据操作存储和决策分析的情况下运用的软件。在HTAP领域通常会将事务和分析的处理方式混合，由于这两种方式的差异，需要针对性能做特殊处理，因此主要可以分为存储和查询2个部分。其中，存储通常包括列式存储和行式存储，查询则包括统计分析类查询和非统计分析类查询。

然而，现有的方法在进行存储和查询时往往存在以下缺点：第一，使用内存去冗余数据，虽然性能有所提升，但是成本相对更高；第二，在存储方面通过复制数据，冗余到列式存储和行式存储，成倍增加了存储成本。第三，在查询方面，虽然通过查询分析器判断sql语句的性能最优解，但是这种静态分析方法，在事务和分析混合的场景下，无法适应企业软件复杂多变的业务的性能要求。例如业务周期可分为日常业务及高峰期业务，如月底的报表上报，节假日的活动促销，都属于高峰期业务。而这种静态分析方法忽视了这种动态业务特点，无法满足偶发的高峰业务带来的性能问题。

发明内容

本申请的目的在于提供一种分布式数据存储及查询系统，以解决现有HTAP领域中针对分布式数据存储和查询时，无法兼顾性能和占用空间，从而导致存储方法不合理、存储成本高以及查询性能无法满足业务动态变化的问题。

为实现上述目的，本申请提供一种分布式数据存储及查询系统，包括：

运行模块包括查询优化器、查询调度器和存储优化器；存储模块包括优化元信息、列式存储数据和行式存储数据；其中，

查询优化器内置多种查询优化引擎，用于根据优化元信息对传入的SQL语句进行优化，并调度执行请求；

查询调度器，用于执行实际的调度请求，并将调度请求分发列式存储数据或行式存储数据中进行查询；

存储优化器，用于分析优化元信息，以平衡查询性能与存储空间生成最优解，并执行优化迁移。

作为优选地，所述查询优化器包括：

SQL静态分析引擎，用于将SQL查询语句解析为语法树，根据语法节点的特性静态预测执行效率，生成静态最优解；

历史效率分析引擎，用于根据历史执行情况和历史执行周期，预测当前时间下的历史最优解；

业务类别分析引擎，用于根据本次执行的业务类别，预测执行同类业务最优解；

优化器权重引擎，用于根据SQL静态分析引擎、历史效率分析引擎及业务类别分析引擎的预测结果，按照各引擎的最优权重确定最优执行策略。

作为优选地，所述SQL静态分析引擎，还用于：

将SQL查询语句解析为语法树，查询静态解析缓存获得静态解析缓存结构，包括语法关键字、建议存储类别和对应权重；

若语法树在静态解析缓存中存在关键字，分别获取行、列权重之和，将其中较大值对应的存储类型确定为静态最优解；

若语法树在静态解析缓存中不存在关键字，确定是否存在聚合语法，若是则将列存储类别确定为静态最优解。

作为优选地，所述历史效率分析引擎，还用于：

在历史周期范围内查找SQL语句；所述历史周期范围包括预设的长周期历史和短周期历史范围；

若SQL语句的当前时间处于历史周期范围内，则将对应历史周期范围内推荐的存储类别确定为历史最优解；

若SQL语句的当前时间不处于历史周期范围内，则忽略历史最优解。

作为优选地，所述业务类别分析引擎，还用于：

在业务标签与SQL语句的关系表中查询SQL语句，获得业务标签；

在业务标签库中查询与所述业务标签对应的存储类别，作为同类业务最优解。

作为优选地，所述优化器权重引擎，还用于：

根据SQL静态分析引擎、历史效率分析引擎及业务类别分析引擎的预测结果，分别确定行、列存储的权重之和；

将权重值较大的存储类别作为最优执行策略。

作为优选地，所述查询调度器，还用于：

根据查询优化器执行的调度类别，在对应的存储类别中查询语句；

记录当前执行效率，并返回给查询优化器以使得查询优化器进行权重优化。

作为优选地，所述存储优化器，还用于：

获取预设的长周期范围内的数据迁移时长阈值，遍历待迁移的长周期范围内的信息；

从遍历结果中解析长周期查询语句，预测优化时间；

判断优化时间是否达到数据迁移时长阈值；若是，则执行优化结果；若否，则返回遍历待迁移的长周期范围内的信息步骤。

作为优选地，所述存储优化器，还用于：

当执行数据迁移时，若当前执行存储类别为行存储，则将列存储的数据全部移除；若当前执行存储类别为列存储，则将行存储的数据全部移除。

相对于现有技术，本申请的有益效果在于：

1）本申请提供了多层优化器，包含静态分析以及由周期分析、业务分析和权重匹配形成的动态解析，将技术的静态分析，结合业务周期特性，解决了复杂多变的企业应用中的查询效率问题，更加能够适应大型企业应用复杂多变的情况。

2）本申请提供了存储优化器，通过结合多层优化器，动态的调整业务特征和权重特征；相比现有技术，例如SAP-HANA的全内存模式方案的成本高，TiDB冗余数据方案，负担双倍成本和存储空间浪费的情况；本申请根据业务周期，提前迁移数据，数据存储依然使用低成本的磁盘存储，在最大限度保证业务性能的同时，降低存储成本和硬件成本。

附图说明

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

图1是本申请某一实施例提供的分布式数据存储及查询系统的结构示意图；

图2是本申请某一实施例提供的查询优化器的功能引擎和逻辑结构示意图；

图3是本申请某一实施例提供的查询优化器查询优化流程示意图；

图4是本申请某一实施例提供的查询优化器和查询调度器的查询存储调度流程示意图；

图5是本申请某一实施例提供的存储优化器存储优化流程示意图。

具体实施方式

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

应当理解，文中所使用的步骤编号仅是为了方便描述，不对作为对步骤执行先后顺序的限定。

应当理解，在本申请说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本申请。如在本申请说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。

术语“包括”和“包含”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

为了帮助理解，首先对于本申请涉及的相关术语进行解释：

HTAP：Hybrid Transaction and Analytical Process，混合事务和分析处理，是一种将事务处理和分析处理引擎混合的技术。

行存储：按照行存储的方式，把一行中的数据值串在一起存储起来，然后再存储下一行的数据；擅长随机读操作，适合事务处理及条件查询。

列存储：数据是按照列为基础逻辑存储单元进行存储的，一列中的数据在存储介质中以连续存储形式存在；擅长统计分析型查询。

查询优化器：将输入的查询的语句拆解、分析并重组为功能等价但性能最优的查询语句。

需要说明的是，数据存储需要关注存储格式和存储介质两方面。存储格式方面，行式存储适用于事务处理，列式存储适用于分析处理；现有技术通常会在行式存储和列式存储中二选一，如Oracle，或者同时支持列式存储和行式存储，如TiDB；存储介质方面，大多数产品采用磁盘存储；部分系统，如HANA需要借助内存的高性能，将一些数据映射到内存中。数据查询方面，对于一些统计分析类查询，列式存储性能较好。对于非统计分析类查询，行式存储性能更优。为了适应2种存储格式，现有技术有多种方案，大致分为以下几种：Oracle，提供多个入口，区分列式和行式的查询；TiDB，在存储层之前有一个统一入口，将查询的sql语句解析后，通过查询分析器判断性能最优解，再进入不同的存储引擎去查询；HANA，则将数据映射到内存中，提高查询性能。

然而，针对现有的存储和查询方法，其往往无法兼顾性能和存储空间，不仅成本相对高，且查询方式无法适应业务的动态变化需求，因此，本申请旨在提供一种分布式数据存储和查询方法：存储时，在列式存储和行式存储的选择方法上，能够在性能和空间上做出权衡；查询时，采用非行列完全冗余数据的方式，以准确定位到适合的存储；同时，能适应业务的动态变化，获得最优的查询性能。

请参阅图1，本申请某一个实施例提供了一种分布式数据存储及查询系统。如图1所示，该分布式数据存储及查询系统包括以下功能模块：

运行模块包括查询优化器、查询调度器和存储优化器；

存储模块包括优化元信息、列式存储数据和行式存储数据；其中，

查询优化器内置多种查询优化引擎，用于根据优化元信息对传入的SQL语句进行优化，并调度执行请求；

查询调度器，用于执行实际的调度请求，并将调度请求分发列式存储数据或行式存储数据中进行查询；

存储优化器，用于分析优化元信息，以平衡查询性能与存储空间生成最优解，并执行优化迁移。

需要说明的是，查询优化器为该分布式数据存储及查询系统的核心模块，作用是实现静态与动态结合，并将技术与业务结合的综合性评估优化引擎。

在一个具体地实施例中，查询优化器包括SQL静态分析引擎、历史效率分析引擎、业务类别分析引擎和优化器权重引擎。如图2所示。其中，各优化器有对应的优化元信息，用于存储优化所需的信息。具体地，各引擎的功能如下：

SQL静态分析引擎，用于将SQL查询语句解析为语法树，根据语法节点的特性静态预测执行效率，生成静态最优解；

历史效率分析引擎，用于根据历史执行情况和历史执行周期，预测当前时间下的历史最优解；该引擎通过分析以往的实际执行效率，根据日常执行及周期性执行情况，可预测本次执行效率。

业务类别分析引擎，用于根据本次执行的业务类别，预测执行同类业务最优解；该引擎通过分析本次执行的业务类别，可预测本次执行效率。

优化器权重引擎，用于根据SQL静态分析引擎、历史效率分析引擎及业务类别分析引擎的预测结果，按照各引擎的最优权重确定最优执行策略。该引擎综合以上几个分析引擎的预测结果，按照不断优化的最优权重获得最终的最优执行策略，即定位列式存储还是行式存储。

在一个具体地实施例中，基于上述查询优化器，还提供了对应的查询优化流程，如图3所示。其中，图3展示了SQL语句进入查询优化器转换为优化后的语句及调度执行请求的内部流程。下面将结合附图3用一个示例去展开整个过程：

假设1：有一张数据表为产品订单日统计表tb_product_order_day_stat，如下表1所示：

表1

字段名	说明
		product_code	订单产品编号
submit_count	产品日订单数量
		submit_yearmonth	订单统计时间（月）
submit_yearmonthday	订单统计时间（日）

假设2：当前数据存储并未做任何优化，即数据在行式存储和列式存储中各存一份。

假设3：要统计“月订单总数”，传入的查询语句（标准SQL语法）如下：

SELECT COUNT(submit_count) AS month_count，submit_yearmonth ；

FROM tb_product_order_day_stat；

GROUP BY submit_yearmonth；

基于上述假设，结合图3对于查询优化器执行步骤，包括SQL静态分析引擎、历史效率分析引擎、业务类别分析引擎和优化器权重引擎各个执行流程进行说明：

在一个具体实施例中，SQL静态分析引擎，还用于：

将SQL查询语句解析为语法树，查询静态解析缓存获得静态解析缓存结构，包括语法关键字、建议存储类别和对应权重；

若语法树在静态解析缓存中存在关键字，分别获取行、列权重之和，将其中较大值对应的存储类型确定为静态最优解；

若语法树在静态解析缓存中不存在关键字，确定是否存在聚合语法，若是则将列存储类别确定为静态最优解。

本实施例中，执行流程包括以下步骤：

1.1）SQL语法解析，将传入的查询语句解析为语法树。

1.2）查询静态解析缓存，静态解析缓存结构示例如下表2所示：

表2

语法关键字	建议存储类别	权重
			SELECT	行	0.8
SUM	列	0.6
			AVG	列	0.6
GROUP BY	列	0.8
			COUNT	列	0.6
…	…	…

1.3）若语法树中在静态解析缓存中存在关键字，则直接使用静态解析缓存中的建议存储类别，静态最优解为：行权重之和与列权重之和中较大值对应的存储类别。

例如，本例中存在关键字SELECT，COUNT，GROUP BY，行权重之和为0.8 <列权重之和为0.6+0.8=1.4，则静态最优解为：列存储。

1.4）若语法树中在静态解析缓存中不存在关键字，则根据是否存在聚合语法（GROUP BY关键字）选择行列优先，需要说明的是，该方法默认聚合语法适用于列式存储查询，仅在没有执行过查询时处理。

假设在本例中没有静态解析缓存，查询语句存在GROUP BY关键字，则静态最优解为：列存储。

以上就完成了SQL静态分析，接下来进入动态分析过程，即根据历史执行情况和历史周期预测当前时间周期的最优解。具体地，动态分析分别由历史效率分析引擎、业务类别分析引擎和优化器权重引擎执行。

在一个具体地实施例中，历史效率分析引擎，还用于：

在历史周期范围内查找SQL语句；所述历史周期范围包括预设的长周期历史和短周期历史范围；

若SQL语句的当前时间处于历史周期范围内，则将对应历史周期范围内推荐的存储类别确定为历史最优解；

若SQL语句的当前时间不处于历史周期范围内，则忽略历史最优解。

本实施例中，历史效率分析引擎的执行流程包括：

2.1）在长周期历史和短周期历史中查找SQL语句，其中周期历史表结构示例如下表3所示：

表3

SQL语句	历史周期	周期类型	推荐存储类别
				SELECT * FROM aaa	每月30日执行	长	行
SELECT COU…	每日执行	短	列
				SELECT COUNT(submit_count) AS month_count，submit_yearmonth FROM tb_product_order_day_stat GROUPBY submit_yearmonth	每周1执行	短	行
…	…		…

2.2）在本例中，在周期列表中存在该语句，历史周期为“每周1执行”，推荐类别为“行存储”。

假设当前时间为2022年7月11日（星期一），表示在这个周期范围内，推荐存储类别为“行存储”，则历史最优解为：行存储。

如果当前时间不在周期范围内，或者周期列表中不存在语句，则表示查询周期不明确，则历史最优解可被忽略。

在一个具体实施例中，业务类别分析引擎，还用于：

在业务标签与SQL语句的关系表中查询SQL语句，获得业务标签；

在业务标签库中查询与所述业务标签对应的存储类别，作为同类业务最优解。

当结束了历史效率分析步骤，接下来进入业务类别分析步骤，即根据业务类别的推荐方式，与其它方法不同的是，由于在企业软件领域，执行效率与企业的业务本身存在必然联系，业务越复杂，列式存储模式的执行效率和迁移效率越低，可能导致即使是统计分析类业务可能使用行存效率更高，因此在本方法定义业务标签作为参考依据。

3.1）在业务标签与SQL语句关系表中查询SQL语句，获得业务标签；其中，业务标签与SQL语句关系表示例如下表4所示：

表4

SQL语句	业务标签
		SELECT x FROM yyy	财务类
SELECT COUNT(submit_count) AS month_count，submit_yearmonth FROM tb_product_order_day_stat GROUP BY submit_yearmonth	订单类
		SELECT b FROM ccc	财务类

3.2）在业务标签库中查询该标签推荐的存储类别，业务标签库结构示例如下表5所示：

表5

业务标签	推荐存储类别
		财务类	列
订单类	行
		…	…

3.3）在本例中，SQL语句对应的业务标签为“订单类”，订单类标签推荐存储类别为“行存储”。

3.4）得出同类业务最优解为：行存储。

当以上各优化器都完成了效率分析，得到各自的最优解之后，接下来对各优化器结论做综合评估。

在一个具体实施例中，优化器权重引擎，还用于：

根据SQL静态分析引擎、历史效率分析引擎及业务类别分析引擎的预测结果，分别确定行、列存储的权重之和；

将权重值较大的存储类别作为最优执行策略。

具体地，本实施例中优化器权重引擎的执行步骤包括：

4.1）查各优化器权重表，权重表结构示例如下表6所示：

表6

优化器	权重
		SQL静态分析引擎	0.4
历史效率分析引擎	0.8
		业务类别效率分析引擎	0.3
…	…

4.2）在本例中，SQL静态分析引擎结果为“列存储”；历史效率分析引擎结果为“行存储”；业务类别效率分析引擎结果为“行存储”，

计算最终结果为：列*0.4 ：行*(0.8+0.3=1.1)，因此最终结果为“行存储”，即查询将调度到行式存储数据。

在一个示例性地实施例中，查询调度器，还用于：

根据查询优化器执行的调度类别，在对应的存储类别中查询语句；

记录当前执行效率，并返回给查询优化器以使得查询优化器进行权重优化。

需要说明的是，本实施例中查询存储调度的过程，包含了上面一步的查询优化，即查询优化分析和查询调度分析的过程。其中，该查询存储调度流程重点描述调度器与优化器之间调度与反馈的流程。

继续上面的示例，请参阅图4，查询存储调度流程包括以下步骤：

5.1）查询优化器获得了最终优化结果即最终的调度类别，即将查询调度到行式存储。

5.2）查询调度器，通过行存API，在行式存储中执行查询语句：

SELECT COUNT(submit_count) AS month_count，submit_yearmonth ；

FROM tb_product_order_day_stat；

GROUP BY submit_yearmonth；

5.3）执行完成后，记录当前执行效率（当前执行效率 =执行时间×涉及数据量×涉及数据大小），当前效率表结构如下表7所示：

表7

SQL语句	历史执行效率	当前执行效率
			SELECT aaa from bbb	1	2
SELECT COUNT(submit_count) AS month_count，submit_yearmonth FROM tb_product_order_day_stat GROUP BY submit_yearmonth	30	29
			…	…	…

5.4）将执行效率传给查询优化器，做权重优化：

权重值=（历史执行效率+ 当前执行效率）/ 2 * 优化系数；

其中，历史执行效率为上一次优化时传入的效率值；优化系数为系统的全局配置，可手工调整。

5.5）将新的权重，更新到各优化器的权重表，如下表8所示：

表8

优化器	权重
		SQL静态分析引擎	0.5
历史效率分析引擎	0.7
		业务类别效率分析引擎	0.2
…	…

在一个具体实施例中，存储优化器，还用于：

获取预设的长周期范围内的数据迁移时长阈值，遍历待迁移的长周期范围内的信息；

从遍历结果中解析长周期查询语句，预测优化时间；

判断优化时间是否达到数据迁移时长阈值；若是，则执行优化结果；若否，则返回遍历待迁移的长周期范围内的信息步骤。

作为优选地实施方式，当执行数据迁移时，若当前执行存储类别为行存储，则将列存储的数据全部移除；若当前执行存储类别为列存储，则将行存储的数据全部移除。

需要说明的是，存储优化的目的是解决行列数据冗余造成的存储空间浪费，尽可能地权衡性能与空间，形成最优平衡。存储优化触发时机与现有的技术类似，多数采用定时触发和运行后触发，触发机制本方案就不进一步描述，仅描述优化的过程。当优化被触发时，存储优化器内部流程如附图5所示：

6.1）从全局设置中获取长周期数据迁移阈值，假设为“一周后执行”。

6.2）遍历待迁移的长周期范围内的信息，假设周期范围信息表如下9所示：

表9

SQL语句	历史周期	周期类型	推荐存储类别
				SELECT * FROM aaa	每月30日执行	长	行
SELECT COUNT(aa) FROM bbb	每月5日执行	长	行
				SELECT COUNT(cc) FROM ddd	每月6日执行	长	列
…	…		…

6.3）假设触发优化的当前时间是：2022年7月1日。则示例中，每月5日执行的语句将在一周内执行。因此将对SELECT COUNT(aa) FROM bbb的数据做适当迁移优化。

6.4）解析SELECT COUNT(aa) FROM bbb 语法树得出，数据将存储于bbb表。

6.5）假设bbb表的数据量为10亿，假设迁移数据速度每行1ms，迁移10亿数据，则需要100万秒。

6.6）假设全局设置的数据迁移时长阈值为1分钟，即迁移预测时间低于1分钟的才进行迁移。在本例中，预测迁移时间需要100万秒，则不做迁移处理。

6.7）如每月6日执行的也将在一周内执行，因此对SELECT count(cc) FROM ddd的数据做迁移优化。

6.8）解析语句获得数据将存储与ddd表；假设ddd表数据量为2000条，预测需要30秒，低于1分钟，则将做迁移处理。

6.9）数据迁移优化的过程较为简单，即将冗余在行和列存储中的数据，仅保留在常用的一方，获得合理的利用率。当前示例推荐执行存储类别为“列存储”，则将行存储中的数据移除，即节省当前表一半的空间。

综上所述，本申请实施例提供的分布式数据存储及查询系统，至少可以实现以下功能：

1）通过多层优化器，包含静态分析以及由周期分析、业务分析和权重匹配形成的动态解析，将技术的静态分析结合业务周期特性，解决了复杂多变的企业应用中的查询效率问题，更加能够适应大型企业应用复杂多变的情况。

2）提供了存储优化器，通过结合多层优化器，动态的调整业务特征和权重特征；相比现有技术，如全内存方案或行列冗余方案；本申请根据业务周期，提前迁移数据，数据存储依然使用低成本的磁盘存储，在最大限度保证业务性能的同时，降低存储成本和硬件成本。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统和方法，可以通过其它的方式实现。例如，以上所描述的系统实施例仅仅是示意性的，例如，所述单元的划分仅仅为一种逻辑功能划分，在实际应用中对其实现时可以有另外的划分方式，例如多个单元或页面组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性、机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）或处理器（processor）执行本申请各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（Read-Only Memory，ROM）、随机存取存储器（Random Access Memory，RAM）、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (9)

1.一种分布式数据存储及查询系统，其特征在于，包括：

运行模块包括查询优化器、查询调度器和存储优化器；存储模块包括优化元信息、列式存储数据和行式存储数据；其中，

查询优化器内置多种查询优化引擎，用于根据优化元信息对传入的SQL语句进行优化，并调度执行请求；

查询调度器，用于执行实际的调度请求，并将调度请求分发列式存储数据或行式存储数据中进行查询；

存储优化器，用于分析优化元信息，以平衡查询性能与存储空间生成最优解，并执行优化迁移。

2.根据权利要求1所述的分布式数据存储及查询系统，其特征在于，所述查询优化器包括：

SQL静态分析引擎，用于将SQL查询语句解析为语法树，根据语法节点的特性静态预测执行效率，生成静态最优解；

历史效率分析引擎，用于根据历史执行情况和历史执行周期，预测当前时间下的历史最优解；

业务类别分析引擎，用于根据本次执行的业务类别，预测执行同类业务最优解；

优化器权重引擎，用于根据SQL静态分析引擎、历史效率分析引擎及业务类别分析引擎的预测结果，按照各引擎的最优权重确定最优执行策略。

3.根据权利要求2所述的分布式数据存储及查询系统，其特征在于，所述SQL静态分析引擎，还用于：

将SQL查询语句解析为语法树，查询静态解析缓存获得静态解析缓存结构，包括语法关键字、建议存储类别和对应权重；

若语法树在静态解析缓存中存在关键字，分别获取行、列权重之和，将其中较大值对应的存储类型确定为静态最优解；

若语法树在静态解析缓存中不存在关键字，确定是否存在聚合语法，若是则将列存储类别确定为静态最优解。

4.根据权利要求2所述的分布式数据存储及查询系统，其特征在于，所述历史效率分析引擎，还用于：

在历史周期范围内查找SQL语句；所述历史周期范围包括预设的长周期历史和短周期历史范围；

若SQL语句的当前时间处于历史周期范围内，则将对应历史周期范围内推荐的存储类别确定为历史最优解；

若SQL语句的当前时间不处于历史周期范围内，则忽略历史最优解。

5.根据权利要求2所述的分布式数据存储及查询系统，其特征在于，所述业务类别分析引擎，还用于：

在业务标签与SQL语句的关系表中查询SQL语句，获得业务标签；

在业务标签库中查询与所述业务标签对应的存储类别，作为同类业务最优解。

6.根据权利要求2所述的分布式数据存储及查询系统，其特征在于，所述优化器权重引擎，还用于：

根据SQL静态分析引擎、历史效率分析引擎及业务类别分析引擎的预测结果，分别确定行、列存储的权重之和；

将权重值较大的存储类别作为最优执行策略。

7.根据权利要求1所述的分布式数据存储及查询系统，其特征在于，所述查询调度器，还用于：

根据查询优化器执行的调度类别，在对应的存储类别中查询语句；

记录当前执行效率，并返回给查询优化器以使得查询优化器进行权重优化。

8.根据权利要求1所述的分布式数据存储及查询系统，其特征在于，所述存储优化器，还用于：

获取预设的长周期范围内的数据迁移时长阈值，遍历待迁移的长周期范围内的信息；

从遍历结果中解析长周期查询语句，预测优化时间；

判断优化时间是否达到数据迁移时长阈值；若是，则执行优化结果；若否，则返回遍历待迁移的长周期范围内的信息步骤。

9.根据权利要求8所述的分布式数据存储及查询系统，其特征在于，所述存储优化器，还用于：

当执行数据迁移时，若当前执行存储类别为行存储，则将列存储的数据全部移除；若当前执行存储类别为列存储，则将行存储的数据全部移除。

Images