CN105824957A - 分布式内存列式数据库的查询引擎***及查询方法 - Google Patents
分布式内存列式数据库的查询引擎***及查询方法 Download PDFInfo
- Publication number
- CN105824957A CN105824957A CN201610193220.XA CN201610193220A CN105824957A CN 105824957 A CN105824957 A CN 105824957A CN 201610193220 A CN201610193220 A CN 201610193220A CN 105824957 A CN105824957 A CN 105824957A
- Authority
- CN
- China
- Prior art keywords
- query engine
- subtask
- state
- query
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2453—Query optimisation
- G06F16/24534—Query rewriting; Transformation
- G06F16/24542—Plan optimisation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
- G06F16/221—Column-oriented storage; Management thereof
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
- G06F16/24553—Query execution of query operations
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
- G06F16/24553—Query execution of query operations
- G06F16/24554—Unary operations; Data partitioning operations
- G06F16/24556—Aggregation; Duplicate elimination
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
- G06F16/24553—Query execution of query operations
- G06F16/24558—Binary matching operations
- G06F16/2456—Join operations
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
- G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/50—Indexing scheme relating to G06F9/50
- G06F2209/5017—Task decomposition
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Software Systems (AREA)
- Computational Linguistics (AREA)
- Computing Systems (AREA)
- Operations Research (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种分布式内存列式数据库的查询引擎***及查询方法,查询方法包括:资源管理模块确定一个主查询引擎负责与用户之间的会话;主查询引擎将用户发送的SQL语言转换为查询计划;资源管理模块为主查询引擎分配从查询引擎;主查询引擎将查询计划分割成至少两个子任务,并为每个子任务分配从查询引擎;在当前子任务的前驱子任务全部执行完成后执行当前子任务,将当前子任务执行完成产生的中间数据传输至后继子任务所在的从查询引擎,并将当前子任务完成状态发送至主查询引擎;主查询引擎通知客户在从查询引擎获取最终结果数据。本发明提供的分布式内存列式数据库的查询引擎***及查询方法,可以得到良好的查询效率。
Description
技术领域
本发明涉及数据库技术领域,具体涉及一种分布式内存列式数据库的查询引擎***及查询方法。
背景技术
NewSQL是对各种新的可扩展、高性能数据库的简称,这类数据库不仅具有NoSQL对海量数据的存储管理能力,还保持了传统数据库支持ACID和SQL等特性。一般来说,NewSQL大致分为三类:新架构,采用全新的数据库平台,采取不同的设计方法,例如GoogleSpanner、Clustrix、VoltDB以及MemSQL;SQL查询引擎,高度优化的SQL存储引擎,提供了MySQL相同的编程接口,但扩展性比内置的引擎InnoDB更好;透明分片,提供分片的中间件层,数据库自动分割在多个节点运行。随着时间的推移,这三种类型的NewSQL数据库已经逐渐融合,诞生了面向联机分析处理(OLAP,OnlineAnalyticalProcessing)的大规模分布式内存列式数据库。
查询引擎是数据库***的核心部分,负责整个数据库***查询计算任务的执行调度。一条用户输入的SQL语句,在数据库***中首先会进行SQL语句词法语法解析生成语法树,再经过数据库查询优化器对语法树进行变形,最后转化成数据库查询引擎可以识别的查询计划。查询计划告诉查询引擎怎样执行,怎样从数据库底层存储引擎中提取数据,对数据进行变形最后转换成用户想要的结果。
HIVE是基于Hadoop的一个数据仓库工具,并提供简单的SQL查询功能,可以将SQL语句转换成MapReduce任务进行运行。对于SQL语句SELECTc_custkeyFROMcustomerJOINnationONcustomer.C_NATIONKEY=nation.N_NATIONKEYJOINlineitemONlineitem.L_PARTKEY=customer.C_CUSTKEY,HIVE对一次SQL查询计划和任务执行流程如图1所示。HIVE真正执行的是MapReduce任务,所以会把查询计划转化为MapReduce任务集合,原查询计划被转化成两个MapReduce任务。其中,JOB1负责计算Join1,也就是lineitem表和customer表的Join运算;JOB2负责计算Join2,也就是计算Join1结果和nation表的Join运算,最终输出结果。JOB1执行完成之后,会把中间结果数据写入外部存储***,JOB2才可以开始执行,并且JOB2会从外部存储***读取JOB1产生的中间结果然后进行计算工作。HIVE的缺点显而易见,其底层采用MapReduce计算模型,对于每两个MapReduce计算任务之间的数据共享,只能将其中一个计算任务的结果输出到外部存储***(分布式文件***或者本地文件***),后一个计算任务从外部存储***读取数据进行计算,导致大量的磁盘I/O,以至于整个查询过程延迟较高。
Spark-SQL是另外一种数据仓库工具,和HIVE功能类似,但是Spark-SQL底层采用Spark计算模型而不是MapReduce计算模型。对于SQL语句SELECTc_custkeyFROMcustomerJOINnationONcustomer.C_NATIONKEY=nation.N_NATIONKEYJOINlineitemONlineitem.L_PARTKEY=customer.C_CUSTKEY,Spark-SQL对一次SQL查询计划和任务执行流程如图2所示。Stage1主要用来处理查询计划中的ScanTable(lineitem)和ScanTable(customer),分别对应RDD1和RDD2。由于RDD为分布式弹性数据集,对应多个物理节点,每个物理节点会执行对应的任务,所以一个RDD由多个并行执行的Task(任务)得到,例如RDD1就由Task1-1、Task1-2计算得到。读取完lineitem表和customer表内容后,Stage2主要用来处理Join1操作和ScanTable(nation)操作,分别生成RDD3和RDD4。最后,Stage3用来完成Join2操作。Spark-SQL在计算延迟上相对于HIVE要快很多,但是依然存在一些缺点。
其一在于Spark-SQL底层采用scala语言实现,整体运行在Java虚拟机上,其内存管理机制依赖于Java虚拟机。而Java虚拟机内存管理机制是一种通用的内存管理机制,在数据库查询引擎中,没有针对数据库查询引擎做定制化的内存优化,导致Spark-SQL在计算过程中消耗大量的内存空间。
其二在于Spark-SQL任务执行过程中按照阶段顺序执行,如Stage2开始执行的前提条件是Stage1执行完成,Stage3执行的前提条件是Stage2执行完成。每个Stage包含若干个可并行执行的Task(任务),每个Stage的执行延迟由该Stage中执行时间最长的Task决定。由此产生一个问题,执行快的Task完成之后会等待同一Stage中其他未执行完成的Task,待同一Stage中所有任务执行完成之后,下一Stage中的Task才可以开始执行。例如,Task1-1、Task1-2、Task2-1以及Task2-2在Stage1中,Task3-1和Task3-2在Stage2中,Task3-2依赖于Task1-1、Task1-2以及Task2-1的计算结果。如果Task1-1、Task1-2以及Task2-1任务执行完成而Task2-2未执行完成,那么即使Task3-1满足执行条件,在Spark计算框架的约束条件下,Task3-1仍然不能开始执行,需要等到Task2-2执行完成之后才开始执行。若Task2-2执行时间太长,则会影响整个计算过程的计算延迟。
发明内容
本发明所要解决的是现有数据库查询引擎计算效率低的问题。
本发明通过下述技术方案实现:
一种分布式内存列式数据库的查询引擎***,包括资源管理模块、至少一个主查询引擎以及至少一个从查询引擎;所述主查询引擎用于将SQL语言转换为查询计划,将查询计划分割成至少两个子任务,并负责监控和调度查询计划的执行过程;所述从查询引擎用于执行所述主查询引擎分配的子任务;所述资源管理模块用于负责***资源的管理和分配。
可选的,所述***资源包括CPU计算资源和内存资源。
基于上述分布式内存列式数据库的查询引擎***,本发明还提供一种分布式内存列式数据库的查询方法,包括:资源管理模块确定一个主查询引擎负责与用户之间的会话;主查询引擎将用户发送的SQL语言转换为查询计划;资源管理模块为主查询引擎分配从查询引擎,并建立从查询引擎与主查询引擎之间的通信;主查询引擎将查询计划分割成至少两个子任务,并为每个子任务分配从查询引擎;从查询引擎将子任务添加到任务队列,在当前子任务的前驱子任务全部执行完成后执行当前子任务,将当前子任务执行完成产生的中间数据传输至后继子任务所在的从查询引擎,并将当前子任务完成状态发送至主查询引擎;在整个查询计划完成后,主查询引擎通知客户在从查询引擎获取最终结果数据。
本发明将查询计划分割为若干有依赖关系的子任务,并将子任务分配至相应的从查询引擎的任务队列中,由从查询引擎依次执行任务队列中的子任务,而不会出现在Spark-SQL中,后一阶段中某个任务虽然满足可执行条件,却由于Spark-SQL执行框架的限制,而不能开始执行计算任务的缺点。因此,采用本发明提供的分布式内存列式数据库的查询方法,可以得到良好的查询效率。
可选的,子任务采用物理算子表示,所述物理算子包括提取列数据操作、连接操作、条件过滤操作、分组操作、聚合函数操作、排序操作以及将最终结果数据还原成行表的操作中的至少一种。
可选的,主查询引擎根据代价模型为每个子任务分配从查询引擎。采用代价模型为每个子任务分配从查询引擎,可以为每个子任务分配执行代价最小的从查询引擎,从而进一步提高查询效率。
可选的,主查询引擎根据代价模型为每个子任务分配从查询引擎包括:根据从查询引擎的元数据信息获取从查询引擎所在节点的IP以及该节点存储的数据库表信息和列信息;根据数据本地化原则分配查询计划中每项提取列数据操作的执行节点IP;采用贪心算法选取非提取列数据操作的执行节点。
可选的,每个子任务的状态包括等待执行状态、正在计算状态、分发数据状态、执行完毕状态以及执行失败状态。
可选的,当前子任务的初始状态为等待执行状态,在当前子任务所在从查询引擎收到当前子任务所有前驱子任务执行完成产生的中间数据后,将当前子任务的状态改为正在计算状态;当前子任务计算完成后,将当前子任务的状态改为分发数据状态,并将计算产生的中间数据发送至后继子任务所在的从查询引擎;若中间数据发送成功,将当前子任务的状态改为执行完毕状态;若等待执行状态与正在计算状态之间、正在计算状态与分发数据状态之间或者分发数据状态与执行完毕状态之间出现故障,将当前子任务的状态改为执行失败状态;在当前子任务的状态发生改变时,异步通知主查询引擎。
可选的,从查询引擎之间传输的中间数据为经过压缩处理的列数据。在传统数据库执行引擎中,中间数据按表的形式出现,数据存储按照行来存储,然而在大部分分析型业务场景下,用户仅关系一个关系表中的若干属性,采用行存储的方式在计算过程中会额外加载用户所不关心的属性数据,从而造成内存的浪费,采用列存储的方式很好地解决了这一问题。
可选的,所述压缩处理包括位压缩处理和字典压缩处理。采用字典压缩处理以及位压缩处理的方式可以进一步降低内存开销,提高内存的使用效率。
本发明与现有技术相比,具有如下的优点和有益效果:
本发明提供的分布式内存列式数据库的查询引擎***及查询方法,通过异步调度每个子任务的执行提高整体运算效率,即将查询计划分割为若干有依赖关系的子任务,并将子任务分配至相应的从查询引擎的任务队列中,由从查询引擎依次执行任务队列中的子任务。进一步,从查询引擎之间传输的数据为经过压缩处理的列数据,解决采用行存储的方式在计算过程中额外加载用户所不关心的属性数据而造成内存的浪费问题。
附图说明
此处所说明的附图用来提供对本发明实施例的进一步理解,构成本申请的一部分,并不构成对本发明实施例的限定。在附图中:
图1是HIVE的一次SQL查询计划和任务执行流程示意图;
图2是Spark-SQL的一次SQL查询计划和任务执行流程示意图;
图3是本发明实施例的分布式内存列式数据库的查询引擎***的部分结构示意图;
图4是本发明实施例的一次SQL查询计划示意图;
图5是本发明实施例的任务执行流程示意图;
图6是本发明实施例的子任务的执行状态转换示意图;
图7是本发明实施例的从查询引擎之间传输数据的示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚明白,下面结合实施例和附图,对本发明作进一步的详细说明,本发明的示意性实施方式及其说明仅用于解释本发明,并不作为对本发明的限定。
实施例
本实施例提供一种分布式内存列式数据库的查询引擎***,所述分布式内存列式数据库的查询引擎***包括资源管理模块、至少一个主查询引擎以及至少一个从查询引擎。
具体地,所述主查询引擎通过解析SQL语言将SQL语言转换为查询计划,将查询计划分割成至少两个子任务后分发给所述从查询引擎执行,并负责监控和调度查询计划的执行过程以及容错处理。与现有技术中类似,查询计划用树状结构表示。所述从查询引擎用于执行所述主查询引擎分配的子任务,所述资源管理模块用于负责***资源的管理和分配。进一步,所述***资源包括CPU计算资源和内存资源。图3是本实施例的分布式内存列式数据库的查询引擎***的部分结构示意图,主查询引擎31对应三个从查询引擎:从查询引擎32、从查询引擎33以及从查询引擎34。
本实施例还提供基于上述分布式内存列式数据库的查询引擎***的分布式内存列式数据库的查询方法,包括:
步骤S1,资源管理模块确定一个主查询引擎负责与用户之间的会话。具体地,在用户有查询需求时,资源管理模块在资源池中创建一个主查询引擎负责与用户之间的会话。
步骤S2,主查询引擎将用户发送的SQL语言转换为查询计划。主查询引擎通过词法解析和语法解析,并基于规则的查询优化,将SQL语言转换成为查询计划。与现有技术中类似,查询计划用树状结构表示。
步骤S3,资源管理模块为主查询引擎分配从查询引擎,并建立从查询引擎与主查询引擎之间的通信。在将SQL语言转换成为查询计划后,主查询引擎向资源管理模块申请计算资源,资源管理模块分配从查询引擎给主查询引擎,并建立从查询引擎和主查询引擎之间的网络连接。
步骤S4,主查询引擎将查询计划分割成至少两个子任务,并为每个子任务分配从查询引擎。由于本实施例中查询引擎面向的是分布式内存列式数据库,数据表在分布式列数据库中按列存储,并且每一列根据值范围被切割成若干分片。针对这一特性,本实施例抽象出了若干物理算子,用来表示查询计划中某一个具体的子任务。所述物理算子包括提取列数据操作、连接操作、条件过滤操作、分组操作、聚合函数操作、排序操作以及将最终结果数据还原成行表的操作中的至少一种。
提取列数据操作:即GetColumn算子,负责提取列数据库中某一列的数据,GetColumn算子本身可以附加限制条件,例如GetColumn(Teacher.ageTeacher.age>1),表示提取Teacher表的age列,并且age值大于1。
连接操作:即Join算子,负责执行Join运算,包括LeftJoin,RightJoin,FullJoin等。
条件过滤操作:即Filter算子,负责执行条件过滤操作,主要包括AND和OR等逻辑运算。
分组操作:即GroupBy算子,负责执行GroupBy分组操作,用于满足SQL语句中GroupBy关键字的功能。
聚合函数操作:即AGG算子,包括Max(求最大值),Avg(求平均值)等数据库常用操作。
排序操作:即Order算子,用于对需要排序的列进行排序操作。
最终结果数据还原成行表的操作:即BuildRow算子,用于将列数据库最终结果数据还原成用户可以理解的行表,将最终结果以关系表的形式展现给用户。
举例说明,一条具体的SQL语句SELECTc_custkeyFROMcustomerJOINnationONcustomer.C_NATIONKEY=nation.N_NATIONKEYJOINlineitemONlineitem.L_PARTKEY=customer.C_CUSTKEY,经过主查询引擎解析生成的查询计划如图4所示,分割成的子任务如图5所示,包括六个从查询引擎:从查询引擎Slave-QE1、从查询引擎Slave-QE2、从查询引擎Slave-QE3、从查询引擎Slave-QE4、从查询引擎Slave-QE5以及从查询引擎Slave-QE6。
假设每个列均有两个分片,那么针对每一个列的分片上都有一个GetColumn算子,由于每个列的分片有值域范围,那么针对每个分片也会产生基于该分片范围的Join算子。参考图5,Join1节点表示列L_PARTKEY与C_CUSTKEY的等值连接操作,在实际的子任务中,Join1被拆分成两个具体的物理算子,Join1-1和Join1-2,分别负责值域范围在1-100和值域范围在101-150的等值Join操作。依次类推,查询计划中Join2也被拆分为两个具体的Join算子。
进一步,本实施例中主查询引擎是根据代价模型为每个子任务分配从查询引擎。具体地,主查询引擎根据从查询引擎的元数据信息获取从查询引擎所在节点的IP以及该节点存储的数据库表信息和列信息。根据数据本地化原则分配查询计划中每项提取列数据操作的执行节点IP。例如在图5中,从查询引擎Slave-QE1所在物理节点存储L_PARTKEY列的分片数据,那么针对该分片数据的GetColumn算子就分配到从查询引擎Slave-QE1所在物理节点上执行。依次类推,每一个分片的GetColumn算子的执行节点均在对应数据所在的节点执行。对于非GetColumn算子执行节点的选取采用贪心算法,非GetColumn算子执行节点在其儿子算子节点的执行节点中选取,分别计算在每个儿子算子节点物理节点上执行的执行代价,选择执行代价最小的物理节点执行。原则依据代价计算公式:执行代价=网络代价+计算代价=节点间网络负载×传输数据量+节点任务负载×计算数据量。在图5中,Join1-1算子执行节点要么在从查询引擎Slave-QE1,要么在从查询引擎Slave-QE3,这里选择从查询引擎Slave-QE1作为执行节点的依据就是通过分别计算Join1-1算子在从查询引擎Slave-QE1节点上的执行代价和在从查询引擎SlaveQE-3节点上的执行代价,计算确定在从查询引擎Join1-1上执行代价更小,所以最终的执行物理节点选择为从查询引擎Slave-QE1。
步骤S5,从查询引擎将子任务添加到任务队列,在当前子任务的前驱子任务全部执行完成后执行当前子任务,将当前子任务执行完成产生的中间数据传输至后继子任务所在的从查询引擎,并将当前子任务完成状态发送至主查询引擎。具体地,每个子任务包括等待执行状态、正在计算状态、分发数据状态、执行完毕状态以及执行失败状态这五种状态,并且每个子任务会维护该子任务的前驱子任务列表和后继子任务列表,每个子任务的执行状态转换图如图6所示。
以图4所示的Join1-1算子为例,其前驱算子列表为GetColumn(L_PARTKEYSlice1[1-100]),GetColumn(C_CUSTKEYSlice1[1-150]),其后继算子列表为Join2-1算子。Join1-1算子初始状态为等待执行,当Join1-1算子所在物理节点收到其所有前驱算子发送来的数据之后,Join1-1算子状态改为正在计算,Join1-1算子计算完成之后,将当前算子改为分发数据,并且将计算结果数据通过网络发送给后继算子所在的从查询引擎。数据发送成功,当前算子任务执行完成。若其中某一步出现故障,即等待执行状态与正在计算状态之间、正在计算状态与分发数据状态之间或者分发数据状态与执行完毕状态之间出现故障,算子状态会被置为执行失败。当然,Join1-1算子状态每发生一次变化,都会实时的向主查询引擎汇报当前算子状态。每个算子的执行是相互独立的,每个算子执行过程中,状态一旦发生改变,就会异步通知主查询引擎,并将结果数据推送给后继算子所在的执行物理节点。通过这种方式,子任务的执行完全依赖于前驱子任务是否完成,而不需要像Spark或者MapReduce一样,分阶段去执行任务。
在步骤S5中,从查询引擎与从查询引擎之间传输的中间数据为经过压缩处理的列数据,采用压缩处理方法包括位压缩处理与字典压缩处理,以图7所示的数据结构为例,中间数据包含三个向量,即字典向量、偏移量向量和位置向量。字典向量对原始数据进行排序,然后去重处理,将冗余的数据丢弃,节省内存存储空间。至于偏移量向量和位置向量,由于这两个向量里面存储的均为整数,这里采用位压缩策略。在计算机中,一个INT型占四个字节,即32bit,可表示的数据范围在-2147483648~2147483647,对于图7所示的偏移量向量和位置向量,向量中整数的最大值可以确定下来。所以在大多数情况下,存储一个数字用不了32bit。假设偏移量向量或者位置向量中整数的最大值为A,那么存储一个数字所用的比特数为log2A向上取整,对比传统采用INT型或者LONG型变量来存储整数,采用这种方式更加节省内存。
步骤S6,在整个查询计划完成后,主查询引擎通知客户在从查询引擎获取最终结果数据。至此,完成整个查询工作。
以上所述的具体实施方式,对本发明的目的、技术方案和有益效果进行了进一步详细说明,所应理解的是,以上所述仅为本发明的具体实施方式而已,并不用于限定本发明的保护范围,凡在本发明的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (10)
1.一种分布式内存列式数据库的查询引擎***,其特征在于,包括资源管理模块、至少一个主查询引擎以及至少一个从查询引擎;
所述主查询引擎用于将SQL语言转换为查询计划,将查询计划分割成至少两个子任务,并负责监控和调度查询计划的执行过程;
所述从查询引擎用于执行所述主查询引擎分配的子任务;
所述资源管理模块用于负责***资源的管理和分配。
2.根据权利要求1所述的分布式内存列式数据库的查询引擎***,其特征在于,所述***资源包括CPU计算资源和内存资源。
3.一种基于权利要求1或2所述的分布式内存列式数据库的查询引擎***的分布式内存列式数据库的查询方法,其特征在于,包括:
资源管理模块确定一个主查询引擎负责与用户之间的会话;
主查询引擎将用户发送的SQL语言转换为查询计划;
资源管理模块为主查询引擎分配从查询引擎,并建立从查询引擎与主查询引擎之间的通信;
主查询引擎将查询计划分割成至少两个子任务,并为每个子任务分配从查询引擎;
从查询引擎将子任务添加到任务队列,在当前子任务的前驱子任务全部执行完成后执行当前子任务,将当前子任务执行完成产生的中间数据传输至后继子任务所在的从查询引擎,并将当前子任务完成状态发送至主查询引擎;
在整个查询计划完成后,主查询引擎通知客户在从查询引擎获取最终结果数据。
4.根据权利要求3所述的分布式内存列式数据库的查询方法,其特征在于,子任务采用物理算子表示,所述物理算子包括提取列数据操作、连接操作、条件过滤操作、分组操作、聚合函数操作、排序操作以及将最终结果数据还原成行表的操作中的至少一种。
5.根据权利要求4所述的分布式内存列式数据库的查询方法,其特征在于,主查询引擎根据代价模型为每个子任务分配从查询引擎。
6.根据权利要求5所述的分布式内存列式数据库的查询方法,其特征在于,主查询引擎根据代价模型为每个子任务分配从查询引擎包括:
根据从查询引擎的元数据信息获取从查询引擎所在节点的IP以及该节点存储的数据库表信息和列信息;
根据数据本地化原则分配查询计划中每项提取列数据操作的执行节点IP;
采用贪心算法选取非提取列数据操作的执行节点。
7.根据权利要求3所述的分布式内存列式数据库的查询方法,其特征在于,每个子任务的状态包括等待执行状态、正在计算状态、分发数据状态、执行完毕状态以及执行失败状态。
8.根据权利要求7所述的分布式内存列式数据库的查询方法,其特征在于,当前子任务的初始状态为等待执行状态,在当前子任务所在从查询引擎收到当前子任务所有前驱子任务执行完成产生的中间数据后,将当前子任务的状态改为正在计算状态;当前子任务计算完成后,将当前子任务的状态改为分发数据状态,并将计算产生的中间数据发送至后继子任务所在的从查询引擎;若中间数据发送成功,将当前子任务的状态改为执行完毕状态;若等待执行状态与正在计算状态之间、正在计算状态与分发数据状态之间或者分发数据状态与执行完毕状态之间出现故障,将当前子任务的状态改为执行失败状态;在当前子任务的状态发生改变时,异步通知主查询引擎。
9.根据权利要求3所述的分布式内存列式数据库的查询方法,其特征在于,从查询引擎之间传输的中间数据为经过压缩处理的列数据。
10.根据权利要求9所述的分布式内存列式数据库的查询方法,其特征在于,所述压缩处理包括位压缩处理和字典压缩处理。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610193220.XA CN105824957B (zh) | 2016-03-30 | 2016-03-30 | 分布式内存列式数据库的查询引擎***及查询方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201610193220.XA CN105824957B (zh) | 2016-03-30 | 2016-03-30 | 分布式内存列式数据库的查询引擎***及查询方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN105824957A true CN105824957A (zh) | 2016-08-03 |
CN105824957B CN105824957B (zh) | 2019-09-03 |
Family
ID=56524572
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201610193220.XA Active CN105824957B (zh) | 2016-03-30 | 2016-03-30 | 分布式内存列式数据库的查询引擎***及查询方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN105824957B (zh) |
Cited By (29)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106326387A (zh) * | 2016-08-17 | 2017-01-11 | 电子科技大学 | 一种分布式数据存储架构及数据存储方法和数据查询方法 |
CN106445645A (zh) * | 2016-09-06 | 2017-02-22 | 北京百度网讯科技有限公司 | 用于执行分布式计算任务的方法和装置 |
CN106649503A (zh) * | 2016-10-11 | 2017-05-10 | 北京集奥聚合科技有限公司 | 一种基于sql的查询方法及*** |
CN107329814A (zh) * | 2017-06-16 | 2017-11-07 | 电子科技大学 | 一种基于rdma的分布式内存数据库查询引擎*** |
CN107450972A (zh) * | 2017-07-04 | 2017-12-08 | 阿里巴巴集团控股有限公司 | 一种调度方法、装置以及电子设备 |
CN107818100A (zh) * | 2016-09-12 | 2018-03-20 | 杭州海康威视数字技术股份有限公司 | 一种sql语句执行方法及装置 |
WO2018058707A1 (zh) * | 2016-09-30 | 2018-04-05 | 北京百度网讯科技有限公司 | 任务处理方法和分布式计算框架 |
CN108520011A (zh) * | 2018-03-21 | 2018-09-11 | 哈工大大数据(哈尔滨)智能科技有限公司 | 一种确定任务的执行方案的方法及装置 |
CN109471893A (zh) * | 2018-10-24 | 2019-03-15 | 上海连尚网络科技有限公司 | 网络数据的查询方法、设备及计算机可读存储介质 |
CN109547512A (zh) * | 2017-09-22 | 2019-03-29 | ***通信集团浙江有限公司 | 一种基于NoSQL的分布式Session管理的方法及装置 |
CN110020006A (zh) * | 2017-07-27 | 2019-07-16 | 北京国双科技有限公司 | 查询语句的生成方法及相关设备 |
CN110083441A (zh) * | 2018-01-26 | 2019-08-02 | 中兴飞流信息科技有限公司 | 一种分布式计算***及分布式计算方法 |
CN110119275A (zh) * | 2019-05-13 | 2019-08-13 | 电子科技大学 | 一种分布式内存列式数据库编译执行器架构 |
CN110263105A (zh) * | 2019-05-21 | 2019-09-20 | 北京百度网讯科技有限公司 | 查询处理方法、查询处理***、服务器和计算机可读介质 |
CN110300332A (zh) * | 2019-06-18 | 2019-10-01 | 南京科源信息技术有限公司 | 一种基于iptv的游戏加载方法及*** |
CN110851452A (zh) * | 2020-01-16 | 2020-02-28 | 医渡云(北京)技术有限公司 | 数据表连接处理方法及装置、电子设备和存储介质 |
CN110968579A (zh) * | 2018-09-30 | 2020-04-07 | 阿里巴巴集团控股有限公司 | 执行计划的生成与执行方法、数据库引擎及存储介质 |
CN110990430A (zh) * | 2019-11-29 | 2020-04-10 | 广西电网有限责任公司 | 一种大规模数据并行处理*** |
CN111382156A (zh) * | 2020-02-14 | 2020-07-07 | 石化盈科信息技术有限责任公司 | 一种数据采集方法、***、装置、电子设备及存储介质 |
CN111552689A (zh) * | 2020-03-30 | 2020-08-18 | 平安医疗健康管理股份有限公司 | 一种基金审计的去重指标计算方法、装置及设备 |
CN111723112A (zh) * | 2020-06-11 | 2020-09-29 | 咪咕文化科技有限公司 | 数据任务执行方法、装置、电子设备及存储介质 |
CN112000688A (zh) * | 2020-08-14 | 2020-11-27 | 杭州数云信息技术有限公司 | 一种基于通用查询语言的查询方法及查询*** |
CN112269835A (zh) * | 2020-11-10 | 2021-01-26 | 浪潮云信息技术股份公司 | 一种分布式数据库异步读取并处理批量数据的方法 |
CN112416926A (zh) * | 2020-11-02 | 2021-02-26 | 浙商银行股份有限公司 | 支持国产cpu simd指令的分布式数据库高性能执行器设计方法 |
CN112650561A (zh) * | 2019-10-11 | 2021-04-13 | 中兴通讯股份有限公司 | 事务管理方法、***、网络设备和可读存储介质 |
CN113792079A (zh) * | 2021-11-17 | 2021-12-14 | 腾讯科技(深圳)有限公司 | 数据查询方法、装置、计算机设备和存储介质 |
CN113934763A (zh) * | 2021-12-17 | 2022-01-14 | 北京奥星贝斯科技有限公司 | 分布式数据库的sql查询方法及装置 |
CN113946600A (zh) * | 2021-10-21 | 2022-01-18 | 北京人大金仓信息技术股份有限公司 | 数据查询方法、装置、计算机设备和介质 |
CN114036245A (zh) * | 2021-11-29 | 2022-02-11 | 广州海量数据库技术有限公司 | OpenGauss中实现rownum表达式的向量计算方法 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103123652A (zh) * | 2013-03-14 | 2013-05-29 | 曙光信息产业(北京)有限公司 | 数据查询方法和集群数据库*** |
CN103324765A (zh) * | 2013-07-19 | 2013-09-25 | 西安电子科技大学 | 一种基于列存储的多核并行数据查询优化方法 |
-
2016
- 2016-03-30 CN CN201610193220.XA patent/CN105824957B/zh active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103123652A (zh) * | 2013-03-14 | 2013-05-29 | 曙光信息产业(北京)有限公司 | 数据查询方法和集群数据库*** |
CN103324765A (zh) * | 2013-07-19 | 2013-09-25 | 西安电子科技大学 | 一种基于列存储的多核并行数据查询优化方法 |
Cited By (42)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106326387B (zh) * | 2016-08-17 | 2019-06-04 | 电子科技大学 | 一种分布式数据存储结构及数据存储方法和数据查询方法 |
CN106326387A (zh) * | 2016-08-17 | 2017-01-11 | 电子科技大学 | 一种分布式数据存储架构及数据存储方法和数据查询方法 |
CN106445645A (zh) * | 2016-09-06 | 2017-02-22 | 北京百度网讯科技有限公司 | 用于执行分布式计算任务的方法和装置 |
CN107818100A (zh) * | 2016-09-12 | 2018-03-20 | 杭州海康威视数字技术股份有限公司 | 一种sql语句执行方法及装置 |
CN107818100B (zh) * | 2016-09-12 | 2019-12-20 | 杭州海康威视数字技术股份有限公司 | 一种sql语句执行方法及装置 |
US11709894B2 (en) | 2016-09-30 | 2023-07-25 | Beijing Baidu Netcom Science And Technology Co., Ltd. | Task processing method and distributed computing framework |
WO2018058707A1 (zh) * | 2016-09-30 | 2018-04-05 | 北京百度网讯科技有限公司 | 任务处理方法和分布式计算框架 |
CN106649503A (zh) * | 2016-10-11 | 2017-05-10 | 北京集奥聚合科技有限公司 | 一种基于sql的查询方法及*** |
CN107329814B (zh) * | 2017-06-16 | 2020-05-26 | 电子科技大学 | 一种基于rdma的分布式内存数据库查询引擎*** |
CN107329814A (zh) * | 2017-06-16 | 2017-11-07 | 电子科技大学 | 一种基于rdma的分布式内存数据库查询引擎*** |
CN107450972B (zh) * | 2017-07-04 | 2020-10-16 | 创新先进技术有限公司 | 一种调度方法、装置以及电子设备 |
CN107450972A (zh) * | 2017-07-04 | 2017-12-08 | 阿里巴巴集团控股有限公司 | 一种调度方法、装置以及电子设备 |
CN110020006A (zh) * | 2017-07-27 | 2019-07-16 | 北京国双科技有限公司 | 查询语句的生成方法及相关设备 |
CN109547512A (zh) * | 2017-09-22 | 2019-03-29 | ***通信集团浙江有限公司 | 一种基于NoSQL的分布式Session管理的方法及装置 |
CN110083441B (zh) * | 2018-01-26 | 2021-06-04 | 中兴飞流信息科技有限公司 | 一种分布式计算***及分布式计算方法 |
CN110083441A (zh) * | 2018-01-26 | 2019-08-02 | 中兴飞流信息科技有限公司 | 一种分布式计算***及分布式计算方法 |
CN108520011A (zh) * | 2018-03-21 | 2018-09-11 | 哈工大大数据(哈尔滨)智能科技有限公司 | 一种确定任务的执行方案的方法及装置 |
CN110968579A (zh) * | 2018-09-30 | 2020-04-07 | 阿里巴巴集团控股有限公司 | 执行计划的生成与执行方法、数据库引擎及存储介质 |
CN110968579B (zh) * | 2018-09-30 | 2023-04-11 | 阿里巴巴集团控股有限公司 | 执行计划的生成与执行方法、数据库引擎及存储介质 |
CN109471893A (zh) * | 2018-10-24 | 2019-03-15 | 上海连尚网络科技有限公司 | 网络数据的查询方法、设备及计算机可读存储介质 |
CN110119275B (zh) * | 2019-05-13 | 2021-04-02 | 电子科技大学 | 一种分布式内存列式数据库编译执行器架构 |
CN110119275A (zh) * | 2019-05-13 | 2019-08-13 | 电子科技大学 | 一种分布式内存列式数据库编译执行器架构 |
CN110263105A (zh) * | 2019-05-21 | 2019-09-20 | 北京百度网讯科技有限公司 | 查询处理方法、查询处理***、服务器和计算机可读介质 |
CN110263105B (zh) * | 2019-05-21 | 2021-09-10 | 北京百度网讯科技有限公司 | 查询处理方法、查询处理***、服务器和计算机可读介质 |
US11194807B2 (en) | 2019-05-21 | 2021-12-07 | Beijing Baidu Netcom Science And Technology Co., Ltd. | Query processing method, query processing system, server and computer readable medium |
CN110300332A (zh) * | 2019-06-18 | 2019-10-01 | 南京科源信息技术有限公司 | 一种基于iptv的游戏加载方法及*** |
CN112650561A (zh) * | 2019-10-11 | 2021-04-13 | 中兴通讯股份有限公司 | 事务管理方法、***、网络设备和可读存储介质 |
CN110990430A (zh) * | 2019-11-29 | 2020-04-10 | 广西电网有限责任公司 | 一种大规模数据并行处理*** |
CN110851452A (zh) * | 2020-01-16 | 2020-02-28 | 医渡云(北京)技术有限公司 | 数据表连接处理方法及装置、电子设备和存储介质 |
CN111382156A (zh) * | 2020-02-14 | 2020-07-07 | 石化盈科信息技术有限责任公司 | 一种数据采集方法、***、装置、电子设备及存储介质 |
CN111552689A (zh) * | 2020-03-30 | 2020-08-18 | 平安医疗健康管理股份有限公司 | 一种基金审计的去重指标计算方法、装置及设备 |
CN111552689B (zh) * | 2020-03-30 | 2022-05-03 | 平安医疗健康管理股份有限公司 | 一种基金审计的去重指标计算方法、装置及设备 |
CN111723112B (zh) * | 2020-06-11 | 2023-07-07 | 咪咕文化科技有限公司 | 数据任务执行方法、装置、电子设备及存储介质 |
CN111723112A (zh) * | 2020-06-11 | 2020-09-29 | 咪咕文化科技有限公司 | 数据任务执行方法、装置、电子设备及存储介质 |
CN112000688A (zh) * | 2020-08-14 | 2020-11-27 | 杭州数云信息技术有限公司 | 一种基于通用查询语言的查询方法及查询*** |
CN112416926A (zh) * | 2020-11-02 | 2021-02-26 | 浙商银行股份有限公司 | 支持国产cpu simd指令的分布式数据库高性能执行器设计方法 |
CN112269835A (zh) * | 2020-11-10 | 2021-01-26 | 浪潮云信息技术股份公司 | 一种分布式数据库异步读取并处理批量数据的方法 |
CN113946600A (zh) * | 2021-10-21 | 2022-01-18 | 北京人大金仓信息技术股份有限公司 | 数据查询方法、装置、计算机设备和介质 |
CN113792079B (zh) * | 2021-11-17 | 2022-02-08 | 腾讯科技(深圳)有限公司 | 数据查询方法、装置、计算机设备和存储介质 |
CN113792079A (zh) * | 2021-11-17 | 2021-12-14 | 腾讯科技(深圳)有限公司 | 数据查询方法、装置、计算机设备和存储介质 |
CN114036245A (zh) * | 2021-11-29 | 2022-02-11 | 广州海量数据库技术有限公司 | OpenGauss中实现rownum表达式的向量计算方法 |
CN113934763A (zh) * | 2021-12-17 | 2022-01-14 | 北京奥星贝斯科技有限公司 | 分布式数据库的sql查询方法及装置 |
Also Published As
Publication number | Publication date |
---|---|
CN105824957B (zh) | 2019-09-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN105824957A (zh) | 分布式内存列式数据库的查询引擎***及查询方法 | |
US11068439B2 (en) | Unsupervised method for enriching RDF data sources from denormalized data | |
CN110032604B (zh) | 数据存储装置、转译装置及数据库访问方法 | |
CN111344693B (zh) | 动态和分布式计算***中的聚合 | |
EP3285178B1 (en) | Data query method in crossing-partition database, and crossing-partition query device | |
KR101621137B1 (ko) | 아파치 하둡을 위한 로우 레이턴시 쿼리 엔진 | |
Zhao et al. | Modeling MongoDB with relational model | |
US9298774B2 (en) | Changing the compression level of query plans | |
CN107515878B (zh) | 一种数据索引的管理方法及装置 | |
CN109491989B (zh) | 数据处理方法及装置、电子设备、存储介质 | |
US9135647B2 (en) | Methods and systems for flexible and scalable databases | |
CN106897411A (zh) | 基于Spark技术的ETL***及其方法 | |
CN109241159B (zh) | 一种数据立方体的分区查询方法、***及终端设备 | |
CN103440303A (zh) | 一种异构云存储***及其数据处理方法 | |
CN103631870A (zh) | 一种用于大规模分布式数据处理的***及其方法 | |
CN111562885A (zh) | 数据处理方法、装置、计算机设备及存储介质 | |
CN105550351B (zh) | 旅客行程数据即席查询***及方法 | |
CN114969441A (zh) | 基于图数据库的知识挖掘引擎*** | |
CN117056303B (zh) | 适用于军事行动大数据的数据存储方法及装置 | |
US20140379691A1 (en) | Database query processing with reduce function configuration | |
CN108319604B (zh) | 一种hive中大小表关联的优化方法 | |
Azez et al. | JOUM: an indexing methodology for improving join in hive star schema | |
CN116756150A (zh) | 一种Mpp数据库大表关联加速方法 | |
CN113568931A (zh) | 一种数据访问请求的路由解析***及方法 | |
CN111046054A (zh) | 一种电力营销业务数据分析的方法和*** |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |