CN114969110B - 查询方法和装置 - Google Patents

查询方法和装置 Download PDF

Info

Publication number
CN114969110B
CN114969110B CN202210856875.6A CN202210856875A CN114969110B CN 114969110 B CN114969110 B CN 114969110B CN 202210856875 A CN202210856875 A CN 202210856875A CN 114969110 B CN114969110 B CN 114969110B
Authority
CN
China
Prior art keywords
partition
query
sub
target
tables
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.)
Active
Application number
CN202210856875.6A
Other languages
English (en)
Other versions
CN114969110A (zh
Inventor
孙建华
冯遵宝
张广舟
李飞飞
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alibaba Cloud Computing Ltd
Original Assignee
Alibaba China Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Alibaba China Co Ltd filed Critical Alibaba China Co Ltd
Priority to CN202210856875.6A priority Critical patent/CN114969110B/zh
Publication of CN114969110A publication Critical patent/CN114969110A/zh
Application granted granted Critical
Publication of CN114969110B publication Critical patent/CN114969110B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2453Query optimisation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2455Query execution
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请公开了查询方法和装置。其中所述方法通过将共享存储架构的分区表转换为无共享架构的分布表,利用分布表的群集感知(cluster aware)特点,使得在横向上多个并行查询进程共同扫描一张分区父表,在纵向上多个并行查询进程扫描各自负责的分区子表,实现对分区表混合扫描(Hybrid Scan)的方式,基于此使得并行执行引擎从底层同时支持分区表的各项优化。这样,既可以消除分区表的多个并行查询进程的数据重分布开销,因此可以有效提升查询性能;又支持不同分区数的分区表连接加速,因此可以有效提升分区表加速查询的鲁棒性;再者,由于从底层同时支持分区表的各项优化,因此还可以有效提升查询加速方式的可扩展性。

Description

查询方法和装置
技术领域
本申请涉及数据库技术领域,具体涉及查询方法和装置,电子设备,以及数据库系统。
背景技术
随着5G、分布式技术、云计算技术的不断发展,数据库云化、数据库云原生架构已成为趋势。云原生数据库的架构通过计算、存储分离(以下简称存算分离),采用共享存储的方式,支持分布式跨机并行执行,可实现资源价值的最大化。
一方面,数据库通常采用表分区技术,将一张大表(分区表,分区父表)按照约定逻辑拆分成若干个小表(分区子表),以在特定的SQL操作中减少数据读写的总量以缩减响应时间。同时,数据库还会通过分区表查询优化技术来加速分区表的查询。另一方面,数据库在进行表查询处理时,通常是先进行扫描表数据,再基于扫描结果生成查询结果。为了实现对数据扫描的并行加速,数据库通常会采用分布式跨机并行执行技术(ParallelExecution, PX),使用多个工作进程(并行查询进程,worker)执行一个 SQL查询。因此,存储计算分离架构下的并行执行引擎需要支持上述分区表查询优化方法。目前,一种典型的实现并行执行引擎支持分区表查询优化方法的方式是混合的智能并行连接(HybridPartition-Wise Join)。该实现方式支持全分区表的查询加速的各种方法,支持多个worker共同扫描同一对分区子表,且无需所有节点进行数据重分布。
然而,在实现本发明过程中,发明人发现上述方案至少存在如下问题:1)限制进行连接查询处理的成对分区表必须具有相同的分区数,但在实际应用中存在大量分区数并不相同的成对分区表,无法对该类分区表进行连接查询加速处理;2)针对分区表的多个并行查询进程需要进行数据重分布,系统开销较大。
发明内容
本申请提供查询方法,以解决现有技术存在的存算分离架构下的并行执行引擎不支持对不同分区数的成对分区表进行连接加速、及需要进行数据重分布的问题。本申请另外提供查询装置,电子设备,以及数据库系统。
本申请提供一种查询方法,包括:
针对目标查询语句相关的共享存储的目标分区表,构建分区子表与计算节点之间的第一对应关系、分区子表与并行查询进程之间的第二对应关系;
根据所述第一对应关系,通过计算节点上的并行查询进程扫描目标分区表;
根据所述第二对应关系,通过不同的查询进程扫描不同的分区子表;
根据各进程的扫描结果,获取与目标查询语句对应的查询结果。
可选的,所述目标查询语句包括针对第一分区表和第二分区表进行连接查询的语句,所述目标分区表包括第一分区表和第二分区表,第一分区表与第二分区表的分区数不同。
可选的,还包括:
获取目标分区表的分区方式信息;
根据所述分区方式信息,判断是否执行所述方法。
可选的,所述目标分区表包括哈希分区表;
所述方法还包括:
获取计算节点的第一进程数阈值;
所述获取目标分区表的分区方式信息,包括:
获取各分区表的哈希定义取模值;
所述根据所述分区方式信息,判断是否执行所述方法,包括:
根据各分区表的哈希定义取模值,确定所有分区表的哈希定义取模值的公约数;
根据所述公约数和所述第一进程数阈值,确定第二进程数阈值;
若计算节点的进程数大于第二进程数阈值,则判定执行所述方法。
可选的,所述目标分区表包括哈希分区表;
所述第二对应关系采用如下方式构建:
根据分区子表的哈希值、分区数和并行查询进程数,确定分区子表与并行查询进程之间的对应关系。
可选的,所述第一对应关系采用如下方式构建:
获取计算节点数和分区子表标识;
根据分区子表标识与计算节点数相除的余数,确定分区子表和计算节点之间的对应关系。
可选的,所述第二对应关系采用如下方式构建:
根据计算节点数、并行查询进程数、进程标识和分区子表标识,确定分区子表与并行查询进程之间的对应关系。
可选的,还包括:
构建并行查询进程与计算节点之间的对应关系。
本申请还提供一种查询装置,包括:
映射单元,用于针对目标查询语句相关的共享存储的目标分区表,构建分区子表与计算节点之间的第一对应关系、分区子表与并行查询进程之间的第二对应关系;
横向扫描单元,用于根据所述第一对应关系,通过计算节点上的并行查询进程扫描目标分区表;
纵向扫描单元,用于根据所述第二对应关系,通过不同的查询进程扫描不同的分区子表;
查询结果获取单元,用于根据各进程的扫描结果,获取与目标查询语句对应的查询结果。
本申请还提供一种电子设备,包括:
处理器和存储器;
存储器,用于存储实现上述任一项查询方法的程序,该设备通电并通过所述处理器运行该方法的程序。
本申请还提供一种计算机可读存储介质,所述计算机可读存储介质中存储有指令,当其在计算机上运行时,使得计算机执行上述各种方法。
本申请还提供一种包括指令的计算机程序产品,当其在计算机上运行时,使得计算机执行上述各种方法。
本申请还提供一种数据库系统,包括:共享存储节点,多个计算节点。所述计算节点可执行如下处理: 针对目标查询语句相关的共享存储的目标分区表,构建分区子表与计算节点之间的第一对应关系、分区子表与并行查询进程之间的第二对应关系;根据所述第一对应关系,通过计算节点上的并行查询进程扫描目标分区表;根据所述第二对应关系,通过不同的查询进程扫描不同的分区子表;根据各进程的扫描结果,获取与目标查询语句对应的查询结果。
与现有技术相比,本申请具有以下优点:
本申请实施例提供的查询方法,通过将共享存储架构的分区表转换为无共享架构的分布表, 利用分布表的群集感知(cluster aware)特点,使得在横向上多个并行查询进程共同扫描一张分区父表,在纵向上多个并行查询进程扫描各自负责的分区子表,实现对分区表混合扫描(Hybrid Scan)的方式,基于此使得并行执行引擎从底层同时支持分区表的各项优化。这样,既可以消除分区表的多个并行查询进程的数据重分布开销,因此可以有效提升查询性能;又支持不同分区数的分区表连接加速,因此可以有效提升分区表加速查询的鲁棒性;再者,由于从底层同时支持分区表的各项优化,因此还可以有效提升查询加速方式的可扩展性。
附图说明
图1本申请提供的查询方法的实施例的应用场景图;
图2本申请提供的查询方法的实施例的流程示意图;
图3现有技术下的普通联合查询的流程示意图;
图4本申请提供的查询方法的实施例的普通联合查询的流程示意图;
图5现有技术下的聚合查询的流程示意图;
图6本申请提供的查询方法的实施例的聚合查询的流程示意图;
图7现有技术下的对分区表连接非分区表的流程示意图;
图8本申请提供的查询方法的实施例的对分区表连接非分区表的流程示意图;
图9本申请提供的查询装置的实施例的结构示意图。
具体实施方式
在本申请中,提供了查询方法和装置,以及电子设备。为了清楚地说明本申请实施例提供的方法,下面先对存算分离架构下的共享数据的存储特点和查询特点、及相关问题进行说明。然后,在下面的实施例中逐一对各种方案进行详细说明。
本申请实施例提供的方法可用于采用存储计算分离(存算分离)架构的数据库,如PolarDB,Aurora,GaussDB for MySQL等数据库。存算分离是数据库的一种架构形式,在动态“资源池”基础上,通过数据库内部计算与存储分离,将存储管理放到下层共享存储中,数据库各个节点存储共享,计算各自分离,没有数据分布的概念。采用存储计算分离架构的数据库,可解决数据同步带来的延时问题,并同时增加了计算能力的横向扩展性。而非存储计算分离的架构,数据库的存储和计算是在同一个机器上,具有数据分布的概念,如随机分布、HASH分布、Range分布、Replica分布等。
如图1所示,存算分离架构的数据库包括多个计算节点(如计算节点1和2),以及至少一个共享存储节点。计算节点包括中央处理器CPU和内存,这些硬件资源用于执行数据库(DB)的计算功能。计算节点本地可存储临时的暂态数据,在需要的时候这些数据可以从持久化存储中恢复和重建。共享存储节点存储持久化的数据,这些持久化数据可供多个计算节点读取。具体实施时,可将需要持久化的数据存储在远端的NAS(Network AttachedStorage)、对象存储或分布式文件系统中,或者其他具备高可用能力的分布式存储系统中。
在存算分离架构下,共享数据具有如下存储特点和查询特点:
1)数据存储特点
在持久化数据存储方面,表数据通常比较大,为了避免单表容量超过存储系统限制,加速大表的查询,因此将大表拆分为多个分区子表组成的分区表。分区表是根据指定分区键和分区方式,将数据实际存储在不同子表中,对外统一暴露分区父表。分区表的分区方式包括但不限于:Hash、Range、Interval、List等,使用Hash分区方式的分区表称为Hash分区表。
2)数据查询特点
在数据查询方面,数据库对表的查询处理包括但不限于:投影(Project)、聚合(Aggregate)、连接(Join)。这三种方式都会先扫描(Scan)表数据,然后再上层根据需要做对应投影(包括:扫描表,输出每行数据的指定列)、聚合(包括:扫描表,按指定列分组,输出每组数据的最大最小等统计值)、连接(包括:扫描多张表,多张表按照指定的列作为join条件连接,输出满足join条件的数据)。
一方面,可借助分区表查询优化的方式来加速分区表的查询。分区表查询优化的方式包括但不限于:分区优化聚合(Partition Wise Agg)、分区优化连接(Partition WiseJoin)、部分分区优化连接(Partial Partition Wise Join)。
另一方面,存算分离架构的数据库支持分布式跨机并行执行(ParallelExecution,PX),以实现对数据扫描的并行加速。并行查询是使用多个工作进程(worker)执行一个 SQL查询。非并行查询是指使用一个工作进程(worker)执行一个SQL查询,串行执行。并行执行的原理是对待扫描的共享存储的表按照物理块(block)进行划分,不同的worker扫描各自负责block。每个worker扫描的数据实际依赖存储的block划分,而与具体的数据值无关。
由上述内容可见,存储计算分离架构下的并行执行引擎并没有利用表的分区属性,而是直接将已经逻辑划分的分区表降维成了没有任何逻辑的非分区表,也就无法利用各个分区子表逻辑分布特点,无法对分区表查询进行加速,更不支持上述各类分区表加速方法。在通过并行查询方式扫描分区表数据时,由于每个worker扫描的数据与具体的数据值无关,因此,每个worker读取的数据等价于随机分布的数据。这样就导致一个明显的限制,扫描出来的是随机数据,后续在做Join使用时需要重新进行shuffle(重分布)才能用,否则无法保证每个worker拿到指定部分的数据,因此实际会引入额外的shuffle开销。
针对存储计算分离架构,本申请实施例提供的方法采用如下技术构思:将共享存储的分区表转换为无共享结构的分布表, 利用分布表的自身群集感知(cluster aware)特点实现各类分区优化工作。
第一实施例
请参考图2,其为本申请的查询方法的实施例的流程示意图。在本实施例中,所述方法可包括如下步骤:
步骤S201:针对目标查询语句相关的共享存储的目标分区表,构建分区子表与计算节点之间的第一对应关系、分区子表与并行查询进程之间的第二对应关系。
本申请实施例提供的方法,存算分离的数据库针对目标查询语句(如join查询语句,agg查询语句等)涉及的共享存储的目标分区表,通过构建目标分区表的子表与计算节点之间的对应关系,使得在计算层将共享的目标分区表数据映射为随机分布的表数据。
分布表是在分布式计算出现后,将一张表的数据按照某些规则保存到多个节点上,通过将数据分散到多态机器上,可充分利用多个硬件并行处理。需要说明的是,本实施例中将分区表映射为分布表并不是要将分区子表存储在各个计算节点上,而只是形成了一种分区子表与计算节点之间的映射关系,分区表仍然存储在共享存储节点中。具体实施时,可通过分布式并行执行引擎将目标分区表映射为多个计算节点上的分布表,将执行所述方法的装置称为PX优化器。
所述目标分区表是指要进行查询处理的分区表。目标分区表的数量与查询方式有关,可以是一个分区表,也可以是多个分区表。
例如,查询方式为表连接(join),目标分区表包括两张表,要根据连接键将两张表的具有相同连接键的数据连接在一起。例如,查询语句为: select * from t1_hash t1,t2_hash t2 where t1.id=t2.id;该语句是将t1和t2两张表中具有相同id的数据连接起来。
再例如,查询方式为聚合(agg),目标分区表为一张表。例如,查询语句为: selectid, sum(id) from t1_hash t1 group by id;该语句是将t1表的id字段进行分组汇总。
在一个示例中,所述第一对应关系可采用如下方式构建:获取计算节点数和分区子表标识;根据分区子表标识与计算节点数相除的余数,确定分区子表和计算节点之间的对应关系。该处理方式可形式化表示为如下公式:分区标识 % 节点数== 节点标识。
在一个示例中,所述第二对应关系可采用如下方式构建:根据计算节点数、并行查询进程数、进程标识和分区子表标识,确定分区子表与并行查询进程( px worker)之间的对应关系。具体实施时,可采用如下方式确定分区子表与并行查询进程之间的对应关系:(分区标识 / 节点数) % (进程数 / 节点数)) == (进程标识 / 节点数)。
在一个示例中,所述目标分区表包括哈希分区表;所述第二对应关系可采用如下方式构建:根据分区子表的哈希值、分区数和并行查询进程数,确定分区子表与并行查询进程之间的对应关系。具体实施时,并行执行引擎进行Hash重分布时进程绑定,可采用如下方式实现:进程标识= 哈希值 % 分区数 % 进程数。
在一个示例中,所述方法还可包括如下步骤:构建并行查询进程与计算节点之间的对应关系。该处理方式可形式化表示为如下公式:进程标识 % 节点数== 节点标识。
例如, 在2个计算节点、13个分区、12个进程的情况下,绑定方式如下:节点node0上,扫描子分区0,2,4,6,8,10,12;节点 node1上,扫描子分区1,3,5,7,9,11。
当使用单机并行度dop=1, 总共使用2x1=2个进程扫描时,节点node0上分布进程worker 0,worker0 与子分区0,2,4,6,8,10,12相对应;节点 node1上分布worker 1,worker1与子分区1,3,5,7,9,11相对应。
当使用dop=2, 使用4个进程扫描时,node0上分布worker 0和2,worker0 与子分区0、4、8和12相对应,worker2 与子分区2、6和10相对应;node1上分布worker 1和3,worker1 与子分区1、5和9相对应,worker3 与子分区3、7和11相对应。
当使用dop=3, 使用6个进程扫描时,node0上分布worker 0、2、 4, worker0 与子分区0、6、12相对应,worker2与子分区2、8相对应,worker4 与子分区4、10相对应;node1上分布worker 1、3、5,worker1与子分区1、7相对应,worker3 与子分区3、9相对应,worker5与子分区5,11相对应。
在一个示例中,所述方法还可包括如下步骤:获取目标分区表的分区方式信息;根据所述分区方式信息,判断是否执行所述方法。所述分区方式信息包括但不限于:Hash分区表的哈希定义取模值。具体实施时,可遍历目标查询语句中单个SQL的所有表, 检查是否执行所述方法,如果检查结果为是,则执行所述方法,可以开启混合扫描(Hybrid Scan)模式。
在本实施例中,所述目标分区表包括哈希分区表;所述方法还可包括如下步骤:获取计算节点的第一进程数阈值;所述获取目标分区表的分区方式信息,包括:获取各分区表的哈希定义取模值;所述根据所述分区方式信息,判断是否执行所述方法,包括:根据各分区表的哈希定义取模值,确定所有分区表的哈希定义取模值的公约数;根据所述公约数和所述第一进程数阈值,确定第二进程数阈值;若计算节点的进程数大于第二进程数阈值,则判定执行所述方法。
例如,分区表为Hash分区表,对于目标查询语句涉及的每个Hash分区表, 记录其Hash定义的取模值modulus(哈希定义取模值)。在正常情况下,同一个Hash分区表的分区子表具有相同的分区modulus值。在特殊情况下,如果同一个hash分区表的分区子表具有不同的分区modulus值, 则视为该Hash分区表的modulus为1。统计目标查询语句涉及的所有Hash分区表的modulus的最大公约数, 记为当前查询约定的Hash分布modulus值(所有分区表的哈希定义取模值的公约数), 可以用agreed_modulus表示。
计算分区表分区扫描允许的最大单机px worker数(第一进程数阈值), 即当前已约定的agreed_modulus除以节点数node_count的向上取整值, 记为agreed_max_workers(第二进程数阈值),即:
agreed_max_workers = ceil(agreed_modulus / node_count)。
检查当前PX执行单机进程数(计算节点的进程数)是否大于agreed_max_workers,如果是, 则更新agreed_modulus值为1。如果最终agreed_modulus大于1, 则意味着当前SQL会开启Hybrid Scan。
在计划生成阶段, 对于目标查询语句相关的每个Hash分区表, 如果全局的agreed_modulus(上述最终更新的agreed_modulus)大于1, 则可将Hash分区表标记为Hash分布表, 同时标记扫描该表的扫描方式为hybrid scan,否则不支持hybrid scan。在本实施例中,标记后的数据如下表所示:
分区表 是否为分布表 是否开启混合扫描
T1
T2
T3
在计划执行阶段,对于混合扫描(hybrid scan),px根据自身的进程标识(workerid)、进程数(worker count)、节点标识(node_id)、节点数(node count)、分区子表标识(part_id),计算出当前进程是否需要扫描当前Hash分区子表,从而实现分区扫描+并行扫描的混合扫描。
在计划执行阶段,对于Hash重分布,如果发现agreed_modulus大于1, 采用agreed_modulus作为重分布hash modulus。使用Hash分区的计算函数作为Hash重分布的计算函数。
步骤S203:根据所述第一对应关系,通过计算节点上的并行查询进程扫描目标分区表。
存算分离的数据库的分布式并行执行引擎本身支持数据分布的概念, 支持群集感知(cluster aware)的工作。分布式架构下的分布表具有群集感知能力。分布表的群集感知是指在对分布表进行各类查询(如扫描scan、连接join、聚合agg)时, 可以先在各个节点上做本地scan、join、agg, 上层再汇合。这种处理方式与分区表的分区优化类似。
在本实施例中,针对要进行查询处理的目标分区表,由分布式跨机并行执行引擎通过多个进程共同并行扫描由分区表映射的分布表。以Hash分区表为例, PX可以将数据映射为Hash分布的数据,然后再通过PX弹性调度逻辑的配合, 实现不同计算节点承担独立的分区子表扫描计算。
步骤S205:根据所述第二对应关系,通过不同的查询进程扫描不同的分区子表。
本申请实施例提供的方法,将并行查询进程也拆分到各个计算节点, 实现每个计算节点上的进程只负责扫描当前节点上分区表。
由步骤S203和步骤S205可见,本申请实施例提供的方法是一种混合扫描(HybridScan)的方式,对于分区表即可以横向按照block拆分进行并行扫描,使得多个进程扫描同一张表;也可以纵向按照分区表子表拆分进行分区扫描,使得扫描每张表的进程是独立不相同的。
例如, 在2个计算节点、13个分区、12个进程的情况下,绑定方式如下:节点node0上,扫描子分区0,2,4,6,8,10,12;节点 node1上,扫描子分区1,3,5,7,9,11。
当使用单机并行度dop=1, 总共使用2x1=2个进程扫描时,节点node0上分布进程worker 0,worker0 负责扫描子分区0,2,4,6,8,10,12;节点 node1上分布worker 1,worker1负责扫描子分区1,3,5,7,9,11。
当使用dop=2, 使用4个进程扫描时,node0上分布worker 0和2,worker0 负责扫描子分区0、4、8和12, worker2 负责扫描子分区2、6和10;node1上分布worker 1和3,worker1 负责扫描子分区1、5和9,worker3 负责扫描子分区3、7和11。
当使用dop=3, 使用6个进程扫描时,node0上分布worker 0、2、 4, worker0 负责扫描子分区0、6、12,worker2 负责扫描子分区2、8,worker4 负责扫描子分区4、10;node1上分布worker 1、3、5,worker1 负责扫描子分区1、7,worker3 负责扫描子分区3、9,worker5负责扫描子分区5,11。
在本实施例中,对于分区表Join的场景,当待连接的分区表都满足Hybrid Scan时,就会触发Hybrid Join的连接方式,从而实现分区优化连接和部分分区优化连接功能。对于分区表聚合Agg的场景,当待聚合的分区表Hybrid Scan时,就会触发Hybrid Agg的聚合方式,从而实现分区优化聚合功能。
对于分区表连接非分区表的场景, 现有技术只能实现部分分区优化连接。在这种场景下,本申请实施例提供的方法,通过将不同分区数的分区表降维为相同分区数、且限制单机并行度不大于单机最大分区的方式,解决不同分区数的Hash分区表的连接查询。
在一个示例中,对不同分区数的分区表进行连接查询处理,实现分区优化连接。在这种情况下,目标分区表包括第一分区表和第二分区表,针对第一分区表和第二分区表进行连接查询处理,第一分区表与第二分区表的分区数不同,如第一分区表t1有5个分区,第二分区表t2有3个分区。
前面提到Hybrid Join依赖PX PARTITION重分布,PX PARTITION依赖px_part_count, 不同分区数的分区表px_part_count各不一样,在join时需要统一到相同px_part_count上, 即前面说的agreed_modulus。
假设A表的是模a余b的hash 分区,B表示模c余d的hash分区,PX这里使用a和c的最大公约数作为协调的agreed_modulus,这样的话就能保证PX PARTITION重分布后的数据仍然能准确分发到对应px worker上。公式证明略。
例如, 在2个计算节点、分区A有3个分区(c1_pkey, c2)、分区表B有6个分区(c1_pkey, c2的情况下,绑定方式如下:node0上,扫描A的子分区0、2,B的子分区0、2、4;node1上,扫描A的子分区1, B的子分区1、3、5。协调出来的约定模值agreed_modulus为3,进程数最大为4。当取单机并行度dop=2, 使用4个进程扫描时,node0上分布worker 0、2, worker0负责扫描A的子分区0,B的子分区0、4,worker2 负责扫描A的子分区2,B的子分区2;node1上分布worker 1、3,worker1 负责扫描A的子分区1,B的子分区1、5,worker3 负责扫描B的子分区3。
假设是连接键joinkey是A.c1=B.c2,B表扫描需要做PX PARTITION重分布,重分布公式为:进程标识 = 哈希值% 分区数 % 进程数。因此,B分区子分区0会归属到0 % 3 % 4= 0 worker上,B分区子分区4会归属到4 % 3 % 4 = 1 worker上,B分区子分区2会归属到2% 3 % 4 = 2 worker上,B分区子分区1会归属到1 % 3 % 4 = 1 worker上, B分区子分区5会归属到5 % 3 % 4 = 2 worker上,B分区子分区3会归属到3 % 3 % 4 = 0 worker上,B分区的数据最终会均匀重分布(shuffle)到A子分区所在的woker上进行Hybrid Join,这也等价于Partial Partition Wise Join。
步骤S207:根据各进程的扫描结果,获取与目标查询语句对应的查询结果。
在各个节点上通过各进程对各分区子表做本地扫描(scan)、连接(join)、聚合(agg), 上层再汇合各节点的处理结果,获得与目标查询语句对应的查询结果。
本申请实施例提供的方法,通过引入新的分区表扫描算子--Hybrid Scan,从扫描(scan)底层实现了对分区表Join、Agg的加速效果,直接支持分区优化聚合、部分分区优化连接、分区优化连接。而现有技术只是针对分区优化连接, 不具备其他算子的扩展性。
下面对本申请实施例提供的方法的技术效果进行说明。
在本实施例中,可采用如下过程构建哈希分区表t1和t2:
1)删除表t1_hash(可选步骤);
2)创建分区表t1_hash,包括两个字段:id和value。根据分区键(id)和哈希分区方式,将数据实际存储在不同子表中;
3)创建分区子表t1_hash_p1和t1_hash_p2,根据模2(表示分区数量为2)取余的结果分区。例如,将id=‘aaaadadfasdlfjasljg’数据插入到数据库,先计算该字符串的hashcode(id)得到一个整数,然后对这个整数求模2的余数,如果余数是0就进入第一个分区,余数是1就进入第二个分区。这样,当通过where id=‘aaaadadfasdlfjasljg’查询时,会先计算数据是在哪个分区,过程同上。然后,在分区范围内,按照索引查询,数据量少了1倍,查询速度会提升;
4)向分区表t1_hash插入模拟数据;
5)创建分区表t2_hash及其子表,并插入模拟数据,处理方式与表t1_hash相同;
6)创建非分区表t3,包括两个字段:id和value;
7)向分区表t3插入模拟数据;
例如,对上述表t1和t2的常规分区表进行联合查询(join)的处理,即:通过分区键id,连接哈希分区表t1和t2。假设在两个计算节点上,单机并行度设置为1, 对上述两张表t1和t2的常规分区表进行联合查询,结构化查询语句(sql)为:select * from t1_hasht1, t2_hash t2 where t1.id=t2.id。
在没有任何优化情况下,现有技术下的并行执行引擎的执行图如下3所示。其中,需要对表t2进行全表扫描,然后通过并行执行广播重分布(PX Broadcast算子)广播到所有节点上,这样每个节点就能创建t2全量表的哈希表。然后,每个节点共同扫描t1表,读到的数据去t2哈希表中查询满足t1.id=t2.id条件的数据进行输出,上层再进行两个节点数据的汇合输出。在这个流程中,t1/t2表都进行了并行扫描, 但缺点是每个节点都需要内存t2全表的数据。
在开启了本申请实施例提供的混合扫描(hybrid scan)算子后,就自然而然的支持了partition wise join,数据库的并行执行引擎的执行图4如示。其中,每个计算节点只需要扫描t1/t2分区表的一个子表。比如,计算节点1会扫描t2的分区子表1并构建哈希表,然后扫描t1的分区子表1,读到的数据去本地t2哈希表中查询满足t1.id=t2.id条件的数据进行输出;计算节点2会扫描t2的分区子表2并构建哈希表, 然后扫描t1的分区子表2,读到的数据去本地t2哈希表中查询满足t1.id=t2.id条件的数据进行输出,上层再进行两个节点数据的汇合输出。在这个流程中,每个计算节点上的进程(worker)各自扫描了不同分区子表,没有扫描全量的数据,也没有构建全量表的哈希表,没有额外的Broadcast广播数据。
再例如,在两个计算节点上, 单机并行度设置为1, 将t1表的id字段进行分组汇总, sql为:select id, sum(id) from t1_hash t1 group by id。
在没有任何优化情况下,现有技术下的并行执行引擎的执行图如图5所示。其中,需要对表t1进行全表扫描,然后通过并行哈希重分布(PX Hash算子)进行哈希重分布到所有节点上,每个节点再根据收到的数据先进行本地聚合, 上层再进行两个节点数据的汇合输出。在这个流程中,t1表进行了并行扫描, 但缺点是数据需要重分布一次后才能进行聚合。
在开启本申请实施例提供的混合扫描(hybrid scan)算子后, 就自然而然的支持了partition wise agg,执行图如图6所示。其中,每个计算节点只需要扫描t1分区表的一个子表. 比如计算节点1会扫描t1的分区子表1, 然后直接进行聚合操作; 计算节点2会扫描t1的分区子表2, 然后直接进行聚合操作, ,上层再进行两个节点数据的汇合输出。在这个流程中, 每个计算节点上worker各自扫描了不同分区子表, 没有额外的重分布数据。
又例如,在两个计算节点上,单机并行度设置为1,对上述两张表t1和t3的常规联合查询, sql为:select * from t1_hash t1, t3 where t1.id=t3.id。
对表t1和t3的常规联合查询属于对分区表连接非分区表的场景,可采用partialpartition wise join的加速查询方式,现有技术下的并行执行引擎的执行流程图如图7所示。其中,需要对表t1进行全表扫描,然后通过PX Hash算子重分布到所有节点上,这样每个节点就能创建t1表哈希重分布后的哈希表。然后,每个节点共同扫描t3表,并同样通过PXHash算子重分布到所有节点上。 每个节点根据收到的t3数据去t1 hash表中查询满足t1.id=t3.id条件的数据进行输出,上层再进行两个节点数据的汇合输出。在这个流程中,对t1/t3表都进行了并行扫描, 但缺点是t1/t3表都进行了PX Hash的重分布开销。
在开启了本申请实施例提供的混合扫描(hybrid scan)算子后,也就自然而然的支持了partial partition wise join,执行流程图如图8所示。其中,t3表会被每个节点并行共同扫描,通过PX Hash算子重分布到所有节点上。而计算节点1只会扫描t1的分区子表1并构建哈希表,然后根据收到的t3的数据, 去本地t1哈希表中查询满足t1.id=t3.id条件的数据进行输出;计算节点2会扫描t1的分区子表2并构建哈希表,然后根据收到的t3的数据,去本地t1 h哈希表中查询满足t1.id=t3.id条件的数据进行输出,上层再进行两个节点数据的汇合输出。在这个流程中, 只有分区表t3进行了重分布, 而分区表t1不用重分布。
从上述实施例可见,本申请实施例提供的查询方法,通过将共享存储架构的分区表转换为无共享架构的分布表, 利用分布表的自身群集感知(cluster aware)特点,使得在横向上多个并行查询进程共同扫描一张分区父表,在纵向上多个并行查询进程扫描各自负责的分区子表,实现对分区表混合扫描(Hybrid Scan)的方式,基于此使得并行执行引擎从底层同时支持分区表的各项优化。这样,既可以消除分区表的多个并行查询进程的数据重分布开销,因此可以有效提升查询性能;又支持不同分区数的分区表连接加速,因此可以有效提升分区表加速查询的鲁棒性;再者,由于从底层同时支持分区表的各项优化,因此还可以有效提升查询加速方式的可扩展性。
第二实施例
在上述的实施例中,提供了一种查询方法,与之相对应的,本申请还提供一种查询装置。该装置是与上述方法的实施例相对应。本实施例与第一实施例内容相同的部分不再赘述,请参见实施例一中的相应部分。
本申请提供的一种查询装置包括:映射单元901,横向扫描单元903,纵向扫描单元905,查询结果获取单元907。
映射单元,用于针对目标查询语句相关的共享存储的目标分区表,构建分区子表与计算节点之间的第一对应关系、分区子表与并行查询进程之间的第二对应关系;横向扫描单元,用于根据所述第一对应关系,通过计算节点上的并行查询进程扫描目标分区表;纵向扫描单元,用于根据所述第二对应关系,通过不同的查询进程扫描不同的分区子表;查询结果获取单元,用于根据各进程的扫描结果,获取与目标查询语句对应的查询结果。
所述目标查询语句包括针对第一分区表和第二分区表进行连接查询的语句,所述目标分区表包括第一分区表和第二分区表,第一分区表与第二分区表的分区数不同。
在一个示例中,所述装置还可包括:分区方式获取单元,判断单元。分区方式获取单元,用于获取目标分区表的分区方式信息;判断单元,用于根据所述分区方式信息,判断是否执行所述方法。
在一个示例中,所述目标分区表包括哈希分区表;所述装置还可包括:阈值获取单元,用于获取计算节点的第一进程数阈值;所述分区方式获取单元,具体用于获取各分区表的哈希定义取模值;所述判断单元,具体用于根据各分区表的哈希定义取模值,确定所有分区表的哈希定义取模值的公约数;根据所述公约数和所述第一进程数阈值,确定第二进程数阈值;若计算节点的进程数大于第二进程数阈值,则判定执行所述方法。
在一个示例中,所述目标分区表包括哈希分区表;所述第二对应关系采用如下方式构建:根据分区子表的哈希值、分区数和并行查询进程数,确定分区子表与并行查询进程之间的对应关系。
在一个示例中,所述第一对应关系采用如下方式构建:获取计算节点数和分区子表标识;根据分区子表标识与计算节点数相除的余数,确定分区子表和计算节点之间的对应关系。
在一个示例中,所述第二对应关系采用如下方式构建:根据计算节点数、并行查询进程数、进程标识和分区子表标识,确定分区子表与并行查询进程之间的对应关系。
在一个示例中,所述装置还可包括:第三对应关系构建单元,用于构建并行查询进程与计算节点之间的对应关系。
第三实施例
本申请还提供一种电子设备。由于设备实施例基本相似于方法实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。下述描述的设备实施例仅仅是示意性的。
本实施例的一种电子设备,该电子设备包括:处理器和存储器;存储器,用于存储实现查询方法的程序,该设备通电并通过所述处理器运行该方法的程序后,执行下述步骤:针对目标查询语句相关的共享存储的目标分区表,构建分区子表与计算节点之间的第一对应关系、分区子表与并行查询进程之间的第二对应关系;根据所述第一对应关系,通过计算节点上的并行查询进程扫描目标分区表;根据所述第二对应关系,通过不同的查询进程扫描不同的分区子表;根据各进程的扫描结果,获取与目标查询语句对应的查询结果。
第四实施例
本申请还提供一种数据库系统。由于数据库系统实施例基本相似于方法实施例,所以描述得比较简单,相关之处参见方法实施例的部分说明即可。下述描述的数据库系统实施例仅仅是示意性的。
本实施例的一种数据库系统,包括:存储节点,多个计算节点。
所述数据库系统采用存储计算分离(存算分离)架构,如PolarDB,Aurora,GaussDBfor MySQL等数据库。将存储管理放到下层共享存储节点中,数据库各个计算节点存储共享,计算各自分离。
如图1所示,存算分离架构的数据库包括多个计算节点(如计算节点1和2),以及至少一个共享存储节点。计算节点包括中央处理器CPU和内存,这些硬件资源用于执行数据库(DB)的计算功能。计算节点本地可存储临时的暂态数据,在需要的时候这些数据可以从持久化存储中恢复和重建。共享存储节点存储持久化的数据,这些持久化数据可供多个计算节点读取。具体实施时,可将需要持久化的数据存储在远端的NAS(Network AttachedStorage)、对象存储或分布式文件系统中,或者其他具备高可用能力的分布式存储系统中。
所述计算节点可执行如下处理: 针对目标查询语句相关的共享存储的目标分区表,构建分区子表与计算节点之间的第一对应关系、分区子表与并行查询进程之间的第二对应关系;根据所述第一对应关系,通过计算节点上的并行查询进程扫描目标分区表;根据所述第二对应关系,通过不同的查询进程扫描不同的分区子表;根据各进程的扫描结果,获取与目标查询语句对应的查询结果。
本申请虽然以较佳实施例公开如上,但其并不是用来限定本申请,任何本领域技术人员在不脱离本申请的精神和范围内,都可以做出可能的变动和修改,因此本申请的保护范围应当以本申请权利要求所界定的范围为准。
在一个典型的配置中,计算设备包括一个或多个处理器 (CPU)、 输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器 (RAM) 和/或非易失性内存等形式,如只读存储器 (ROM) 或闪存(flash RAM)。内存是计算机可读介质的示例。
1、计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、 程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存 (PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器 (DRAM)、 其他类型的随机存取存储器 (RAM)、只读存储器(ROM)、电可擦除可编程只读存储器 (EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器 (CD-ROM)、数字多功能光盘 (DVD) 或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括非暂存电脑可读媒体 (transitory media),如调制的数据信号和载波。
2、本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

Claims (12)

1.一种查询方法,包括:
针对目标查询语句相关的共享存储的目标分区表,构建分区子表与计算节点之间的第一对应关系,使得将共享存储的目标分区表数据映射为分布表数据,以及,构建分区子表与并行查询进程之间的第二对应关系;
根据所述第一对应关系,通过计算节点上的并行查询进程扫描目标分区表;
根据所述第二对应关系,通过不同的查询进程扫描不同的分区子表;
根据各进程的扫描结果,获取与目标查询语句对应的查询结果。
2.根据权利要求1所述的方法,
所述目标查询语句包括针对第一分区表和第二分区表进行连接查询的语句,所述目标分区表包括第一分区表和第二分区表,第一分区表与第二分区表的分区数不同。
3.根据权利要求1所述的方法,还包括:
获取目标分区表的分区方式信息;
根据所述分区方式信息,判断是否执行所述方法。
4.根据权利要求3所述的方法,
所述目标分区表包括哈希分区表;
所述方法还包括:
获取计算节点的第一进程数阈值;
所述获取目标分区表的分区方式信息,包括:
获取各分区表的哈希定义取模值;
所述根据所述分区方式信息,判断是否执行所述方法,包括:
根据各分区表的哈希定义取模值,确定所有分区表的哈希定义取模值的公约数;
根据所述公约数和所述第一进程数阈值,确定第二进程数阈值;
若计算节点的进程数大于第二进程数阈值,则判定执行所述方法。
5.根据权利要求1所述的方法,
所述目标分区表包括哈希分区表;
所述第二对应关系采用如下方式构建:
根据分区子表的哈希值、分区数和并行查询进程数,确定分区子表与并行查询进程之间的对应关系。
6.根据权利要求1所述的方法,所述第一对应关系采用如下方式构建:
获取计算节点数和分区子表标识;
根据分区子表标识与计算节点数相除的余数,确定分区子表和计算节点之间的对应关系。
7.根据权利要求1所述的方法,所述第二对应关系采用如下方式构建:
根据计算节点数、并行查询进程数、进程标识和分区子表标识,确定分区子表与并行查询进程之间的对应关系。
8.根据权利要求1所述的方法,还包括:
构建并行查询进程与计算节点之间的对应关系。
9.一种查询装置,包括:
映射单元,用于针对目标查询语句相关的共享存储的目标分区表,构建分区子表与计算节点之间的第一对应关系,使得将共享存储的目标分区表数据映射为分布表数据,以及,构建分区子表与并行查询进程之间的第二对应关系;
横向扫描单元,用于根据所述第一对应关系,通过计算节点上的并行查询进程扫描目标分区表;
纵向扫描单元,用于根据所述第二对应关系,通过不同的查询进程扫描不同的分区子表;
查询结果获取单元,用于根据各进程的扫描结果,获取与目标查询语句对应的查询结果。
10.一种电子设备,包括:
处理器和存储器;
存储器,用于存储实现根据权利要求1-8任一项所述的查询方法的程序,该设备通电并通过所述处理器运行该方法的程序。
11.一种计算机可读存储介质,所述计算机可读存储介质中存储有指令,当其在计算机上运行时,使得计算机执行根据权利要求1-8任一项所述的方法。
12.一种数据库系统,包括:
存储节点,计算节点;
所述计算节点执行如下处理:
针对目标查询语句相关的共享存储的目标分区表,构建分区子表与计算节点之间的第一对应关系,使得将共享存储的目标分区表数据映射为分布表数据,以及,构建分区子表与并行查询进程之间的第二对应关系;
根据所述第一对应关系,通过计算节点上的并行查询进程扫描目标分区表;
根据所述第二对应关系,通过不同的查询进程扫描不同的分区子表;
根据各进程的扫描结果,获取与目标查询语句对应的查询结果。
CN202210856875.6A 2022-07-21 2022-07-21 查询方法和装置 Active CN114969110B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210856875.6A CN114969110B (zh) 2022-07-21 2022-07-21 查询方法和装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210856875.6A CN114969110B (zh) 2022-07-21 2022-07-21 查询方法和装置

Publications (2)

Publication Number Publication Date
CN114969110A CN114969110A (zh) 2022-08-30
CN114969110B true CN114969110B (zh) 2022-10-21

Family

ID=82969377

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210856875.6A Active CN114969110B (zh) 2022-07-21 2022-07-21 查询方法和装置

Country Status (1)

Country Link
CN (1) CN114969110B (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117633024B (zh) * 2024-01-23 2024-04-23 天津南大通用数据技术股份有限公司 一种基于预处理优化join的数据库优化方法

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102201010A (zh) * 2011-06-23 2011-09-28 清华大学 无共享架构的分布式数据库系统及其实现方法
CN105247513A (zh) * 2013-03-13 2016-01-13 华为技术有限公司 用于使用固定表在无共享关系型数据库集群中进行分布式sql连接处理的系统和方法
CN105975617A (zh) * 2016-05-20 2016-09-28 北京京东尚科信息技术有限公司 一种多分区表查询处理的方法和装置
US9652496B1 (en) * 2014-06-25 2017-05-16 Pivotal Software, Inc. Dynamic partition selection
CN111352950A (zh) * 2020-03-04 2020-06-30 上海达梦数据库有限公司 数据库表等值连接的优化方法、装置、服务器及存储介质
CN112364021A (zh) * 2020-11-10 2021-02-12 中国平安人寿保险股份有限公司 业务数据处理方法、装置及存储介质
CN114254005A (zh) * 2021-12-21 2022-03-29 北京人大金仓信息技术股份有限公司 分区表的分组聚集查询方法、装置、计算机设备和介质

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9607044B2 (en) * 2011-03-31 2017-03-28 Tibco Software Inc. Systems and methods for searching multiple related tables
US10380108B2 (en) * 2015-06-22 2019-08-13 International Business Machines Corporation Partition access method for query optimization
CN111427887A (zh) * 2020-03-17 2020-07-17 中国邮政储蓄银行股份有限公司 一种快速扫描HBase分区表的方法、装置、系统

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102201010A (zh) * 2011-06-23 2011-09-28 清华大学 无共享架构的分布式数据库系统及其实现方法
CN105247513A (zh) * 2013-03-13 2016-01-13 华为技术有限公司 用于使用固定表在无共享关系型数据库集群中进行分布式sql连接处理的系统和方法
US9652496B1 (en) * 2014-06-25 2017-05-16 Pivotal Software, Inc. Dynamic partition selection
CN105975617A (zh) * 2016-05-20 2016-09-28 北京京东尚科信息技术有限公司 一种多分区表查询处理的方法和装置
CN111352950A (zh) * 2020-03-04 2020-06-30 上海达梦数据库有限公司 数据库表等值连接的优化方法、装置、服务器及存储介质
CN112364021A (zh) * 2020-11-10 2021-02-12 中国平安人寿保险股份有限公司 业务数据处理方法、装置及存储介质
CN114254005A (zh) * 2021-12-21 2022-03-29 北京人大金仓信息技术股份有限公司 分区表的分组聚集查询方法、装置、计算机设备和介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
无线网络优化平台数据库性能优化设计思路;王志海;《移动通信》;20150130(第02期);全文 *

Also Published As

Publication number Publication date
CN114969110A (zh) 2022-08-30

Similar Documents

Publication Publication Date Title
Floratou et al. Sql-on-hadoop: Full circle back to shared-nothing database architectures
US9177025B2 (en) Hash-join in parallel computation environments
CN110837585B (zh) 多源异构的数据关联查询方法及系统
US9507875B2 (en) Symbolic hyper-graph database
CN103678520A (zh) 一种基于云计算的多维区间查询方法及其系统
US20140351239A1 (en) Hardware acceleration for query operators
US8510280B2 (en) System, method, and computer-readable medium for dynamic detection and management of data skew in parallel join operations
CN102129458A (zh) 关系型数据库的存储方法及装置
KR101951999B1 (ko) 낮은 데이터 중복으로 빠른 쿼리 처리를 지원하는 관계형 데이터베이스 저장 시스템, 저장 방법 및 관계형 데이터베이스 저장 방법에 기초한 쿼리를 처리하는 방법
WO2016191995A1 (zh) 一种分布式数据库中关联表分区的方法和设备
US11782924B2 (en) Distributed join index for shared-nothing and log-structured databases
US10936606B2 (en) Method and system for processing data in a parallel database environment
CN114969110B (zh) 查询方法和装置
US11086872B2 (en) Method and system for outer join of database tables
CN105447112A (zh) 一种实现关系数据库Hash分区高效扩展的方法
US8131711B2 (en) System, method, and computer-readable medium for partial redistribution, partial duplication of rows of parallel join operation on skewed data
US10289723B1 (en) Distributed union all queries
Bakli et al. Distributed spatiotemporal trajectory query processing in SQL
US11580103B2 (en) System and method for disjunctive joins using a lookup table
Nam et al. A parallel query processing system based on graph-based database partitioning
CN108595482B (zh) 一种数据索引方法及装置
US20220215021A1 (en) Data Query Method and Apparatus, Computing Device, and Storage Medium
US11429605B2 (en) System and method for disjunctive joins
US9183255B1 (en) Spool management and checkpointing in a multi-database system
CN111241102B (zh) 数据存储方法、数据检索方法、数据库访问方法及装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20230724

Address after: Room 1-2-A06, Yungu Park, No. 1008 Dengcai Street, Sandun Town, Xihu District, Hangzhou City, Zhejiang Province, 310030

Patentee after: Aliyun Computing Co.,Ltd.

Address before: 310012 room 554, floor 5, building 3, No. 969, Wenyi West Road, Wuchang Street, Yuhang District, Hangzhou City, Zhejiang Province

Patentee before: Alibaba (China) Co.,Ltd.