CN108664516A - 查询优化方法及相关装置 - Google Patents

查询优化方法及相关装置 Download PDF

Info

Publication number
CN108664516A
CN108664516A CN201710210122.7A CN201710210122A CN108664516A CN 108664516 A CN108664516 A CN 108664516A CN 201710210122 A CN201710210122 A CN 201710210122A CN 108664516 A CN108664516 A CN 108664516A
Authority
CN
China
Prior art keywords
plan
inquiry
data
target query
index
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.)
Pending
Application number
CN201710210122.7A
Other languages
English (en)
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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies 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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN201710210122.7A priority Critical patent/CN108664516A/zh
Priority to EP18774545.0A priority patent/EP3591547A4/en
Priority to PCT/CN2018/077425 priority patent/WO2018177060A1/zh
Publication of CN108664516A publication Critical patent/CN108664516A/zh
Priority to US16/579,209 priority patent/US20200019552A1/en
Pending legal-status Critical Current

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/2452—Query translation
    • G06F16/24524—Access plan code generation and invalidation; Reuse of access plans
    • 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/24539—Query rewriting; Transformation using cached or materialised query results
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • 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/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G06F16/24552—Database cache management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • Operations Research (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请实施例公开了查询优化技术。在一种由数据访问节点执行的查询优化方法中，包括接收用于查询租户数据的查询请求；搜索缓存的、针对查询请求的最优查询计划；若搜索出最优查询计划，将最优查询计划作为目标查询计划；若未搜索出最优查询计划，生成与查询请求相对应的目标查询计划；向数据库提交目标查询计划，目标查询计划用于数据库查询租户数据。相较于现有技术，本申请提供的方案中，由数据访问节点将逻辑访问(查询请求)转化为查询计划(物理数据访问)，而不再由数据库节点将逻辑访问转化为查询计划。并且，利用最优查询计划进行查询，可尽量减少查询成本，提高查询性能。

Description

查询优化方法及相关装置
技术领域
本申请涉及计算机领域，更具体地说，涉及查询优化技术。
背景技术
近年来，随着网络技术的发展和应用软件的成熟，软件即服务(Software As AService，SaaS)作为一种新的软件应用模式，得到越来越多的关注。SaaS厂商统一部署应用软件，租户根据实际需求，通过互联网向厂商订购应用软件服务并支付费用。租户不再需要额外构建企业的IT基础设置、有效节省运行维护成本。
在基于多租单实例架构实现的SaaS应用中，会使用宽表作为租户数据(即租户的自定义对象)的存储空间。
在现有方式中，当使用者需要查询租户数据时，会向数据库节点发送SQL查询请求(即逻辑SQL访问)，由数据库节点将逻辑SQL访问最终需转化为包括一个或多个物理SQL的查询计划(物理数据访问)。
但是，宽表中存储了多个租户的租户数据，而数据库节点并不支持表级数据多租的场景，即不能感知宽表某一字段中存储的数据来自不同租户，具有不同的数据类型和分布特征，如整形、字符串、NULL值等。因此，数据库节点得到的查询计划可能并不是最优的查询计划，甚至可能极大影响查询性能。
发明内容
有鉴于此，本申请实施例的目的在于提供查询优化方法及相关装置，以解决现有方式无法适应多租户场景的问题。
为实现上述目的，本申请实施例提供如下技术方案：
一方面，本申请的实施例提供一种查询优化方法，应用于数据访问节点，该方法包括：接收查询请求；上述查询请求用于查询租户数据；搜索针对上述租户数据的最优查询计划；若搜索出最优查询计划，将搜索出的最优查询计划作为目标查询计划；若未搜索出最优查询计划，生成针对上述租户数据的目标查询计划；向数据库提交上述目标查询计划，上述目标查询计划用于上述数据库查询上述租户数据。本申请提供的方案中，由数据访问节点将逻辑SQL访问(SQL查询请求)转化为查询计划(物理数据访问)，而不再由数据库节点将逻辑SQL访问转化为查询计划。并且，若数据访问节点搜索出针对租户数据的最优查询计划，则将该最优查询计划作为目标查询计划提交至数据库；若未搜索出最优查询计划，则生成目标查询计划提交于数据库。而利用最优查询计划进行查询，可尽量减少查询成本，提高查询性能。
在一个可能的设计中，上述查询方法还可包括启动异步查询任务。该异步查询任务可包括：确定针对上述查询请求的备选查询计划；其中，上述备选查询计划包括上述目标查询计划；若针对上述查询请求的备选查询计划的数量为多个，向上述数据库查询各备选查询计划的查询成本；缓存查询成本最小的备选查询计划，作为针对上述租户数据的最优查询计划。在一个示例中，上述异步查询任务还可包括调高最优查询计划所使用的索引的优先级。调高优先级的方式有多种。例如，可设计令优先级最初均为统一初始数值(例如0)，每次被最优查询计划使用，则将优先级增加a(例如1)。此外，可设计在满足触发条件时，启动异步查询任务。触发条件可包括：定期空闲时刷新，如：***空闲时；表数据大量变更，如：大量数据导入后；查询性能发生大的下降。在本实施例中，启动异步查询任务可确定针对租户数据的最优查询计划，在下一次接收到同一查询请求时，针对上述租户数据的最优查询计划将作为目标查询计划，这样可尽量减少查询成本，提高查询性能。同时，在本实施例中，在存在多个备选查询计划时，数据访问节点会利用数据库基于成本优化(Cost-BasedOptimization，CBO)的能力得到各查询计划的查询成本，并选择查询成本最小的备选计划作为最优查询计划。并且，可基于数据宽表和索引Pivot表进行关联查询，有效解决通用数据库的索引技术在多租场景和宽表模型下的失效问题，充分利用了索引Pivot表的索引能力。并且，本实施例不在数据访问服务中完整实现CBO优化，因此需要保存的统计信息有限，且部分已经在租户的对象元数据中体现。因此，可简化应用层实现、减少数据库查询压力，并可减少统计信息的存储空间。
在一个可能的设计中，上述确定针对上述SQL查询请求的备选查询计划的步骤，位于上述向数据库提交上述目标查询计划的步骤之后。这样，备选查询计划的生成，要晚于目标查询计划的确定；或者，可设计令确定针对上述SQL查询请求的备选查询计划的步骤，位于上述接收SQL查询请求的步骤之后。这样，备选查询计划的生成要早于目标查询计划的确定。也即，备选查询计划可早于目标查询计划生成，也可晚于目标查询计划生成，为实现查询优化提供了不同的实现方式。
在一个可能的设计中，上述“生成针对租户数据的目标查询计划”的步骤可进一步包括：根据上述租户数据的统计信息，生成针对上述租户数据的目标查询计划，上述统计信息包括上述租户数据的元数据及上述租户数据对应的索引元数据，上述索引元数据至少包括索引的优先级。其中：若查询请求对应唯一的索引，则根据唯一的索引生成上述目标查询计划；而若上述查询请求对应多个索引，根据优先级最高的索引生成上述目标查询计划；若优先级相同，从上述多个索引中随机选取一个索引生成上述目标查询计划。本实施例提供了生成目标查询计划的一种具体实现方式，根据索引优先级生成目标查询计划。可令生成的目标查询计划也更接近最优查询计划。
在一个可能的设计中，上述“生成针对租户数据的目标查询计划”的步骤可进一步包括：当所述SQL查询请求涉及关联查询多张表格时，所述确定针对所述SQL查询请求的目标查询计划包括：选择具有索引的表格作为驱动表生成目标查询计划。其中，若仅一张表格具有索引，将该具有索引的表格作为驱动表；若至少两张表格具有索引，从所述至少两张表格中选择具有小数据量的表格作为驱动表。这样可令生成的目标查询计划更接近最优查询计划。
又一方面，本申请实施例提供了一种数据访问节点，该数据访问节点具有实现上述方法实际中数据访问节点行为的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。
又一方面，本申请实施例提供了一种软件即服务SaaS应用***，包括应用节点、数据库节点以及上述的数据访问节点，该数据访问节点具有实现上述方法实际中数据访问节点行为的功能。所述功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。
又一方面，本申请提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述各方面所述的方法。
又一方面，本申请提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述各方面所述的方法。
相较于现有技术，本申请提供的方案中，由数据访问节点将逻辑SQL访问(SQL查询请求)转化为查询计划(物理数据访问)，而不再由数据库节点将逻辑SQL访问转化为查询计划。并且，若数据访问节点搜索出针对租户数据的最优查询计划，则将该最优查询计划作为目标查询计划提交至数据库；若未搜索出最优查询计划，则生成目标查询计划提交于数据库。而利用最优查询计划进行查询，可尽量减少查询成本，提高查询性能。
附图说明
图1a和图1b为本申请实施例提供的SaaS应用***示例性结构图；
图2a为本申请实施例提供的数据访问节点的示例性结构图；
图2b和图2c为本申请实施例提供的查询装置的示例性结构图；
图3-4为本申请实施例提供的查询优化方法的示例性结构图。
具体实施方式
为了引用和清楚起见，下文中使用的技术名词、简写或缩写总结解释如下：
SQL：Structured Query Language,结构化查询语言；
DDL：Data Definition Language,数据定义语言，用于描述数据库管理***中存储的现实世界实体的语言；
DML：Data Manipulation Language，数据操作语言，用于实现对数据库管理***中数据进行操作的语言；
Index：索引，数据库管理***中排序的数据结构，辅助快速查询、更新数据库表中数据；
Query Plan：查询计划，数据库管理***中用于访问数据的一组有序执行步骤；
CBO：Cost-Based Optimization，基于成本优化，一种数据库***查询计划的优化方法；
ID：标识。
为方便理解本申请提供的技术方案，本文先对宽表模型、对象元数据表、字段元数据表进行介绍。
宽表模型如下表1所示。宽表模型预留了若干(例如100个、500个等)无类型字段作为租户数据的存储字段。例如，下表中的value 0-value499，即为上述无类型字段。同时，宽表模型中还包括描述租户数据基本信息的字段，例如：租户ID(tenant_id)、对象类型ID(obj_id)、全局唯一标识符(Globally Unique Identifier，GUID)等。
表1
另外，还需通过一组元数据表，定义租户数据。
主要的元数据表包括对象元数据表和字段元数据表。其中：
对象元数据表模型如下表2所示。对象元数据表用于保存租户数据的基本元数据信息，包括：租户ID、名称(obj_name)、对象类型ID等；
objects 说明
obj_id 对象类型ID
tenant_id 租户ID
obj_name 对象名称
表2
字段元数据表模型如下表3所示。字段元数据表用于保存租户数据的字段详细信息，包括：字段ID(field_id)、名称(field_name)、类型(data_type)、大小(data_size)、字段在宽表中的列号等。
Fields 说明
field_id 字段ID
tenant_id 租户ID
obj_id 对象类型ID
field_name 字段名
data_type 字段类型
data_size 字段大小
field_num 字段在宽表中的列号
表3
假设租户101自定义了ACCOUNT对象，其对象元数据表示例性得如下表4所示，其字段元数据表示例性得如下表5所示：
obj_id tenant_id obj_name
201 101 ACCOUNT
表4
field_id tenant_id obj_id field_name data_type data_size field_num
301 101 201 ACCOUNT_ID int 4 0
302 101 201 ACCOUNT_NAME varchar 16 1
303 101 201 ADDRESS varchar 256 2
表5
可以看出，租户对数据对象的定制，例如字段的增删、类型改动等，可不再基于对物理数据库的实体表的DDL操作，而是可通过对元数据的DML操作实现。租户可以任意修改其对象定义，而不影响到其他租户。
当使用者需要查询租户数据时，SaaS应用需要通过元数据描述信息，将租户基于自定义数据对象的逻辑SQL访问最终转化为基于数据宽表的物理SQL访问。
例如，在现有方式中，当使用者需要查询数据时，会向数据库节点发送SQL查询请求(即逻辑SQL访问)，由数据库节点将逻辑SQL访问最终需转化为包括一个或多个物理SQL的查询计划(物理数据访问)。
但是，宽表中存储了多个租户的租户数据，而现有的数据库节点并不支持对表级数据多租的支持，即不能感知宽表某一字段中存储的数据来自不同租户，具有不同的数据类型和分布特征。因此，数据库节点生成的查询计划的方式，并不适用于多租户场景。
为此，本申请实施例提供了查询优化方法及相关装置(查询装置、数据访问节点、SaaS应用***)，以适用宽表中存储多租户数据的情况，并减少查询成本，提高查询性能。
上述查询优化方法的思路是：
由数据访问节点将逻辑SQL访问(SQL查询请求)转化为查询计划(物理数据访问)，而不再由数据库节点将逻辑SQL访问转化为查询计划。
具体的，数据访问节点在接收到查询租户数据的SQL请求后，会确定目标查询计划。在得到目标查询计划后，数据访问节点向数据库提交目标查询计划。后续数据库会基于该目标查询计划查询并返回租户数据。
目标查询计划的确定可包括如下步骤：
搜索缓存的、针对上述SQL查询请求的最优查询计划；
若搜索出最优查询计划，将搜索出的最优查询计划作为目标查询计划；而若未搜索出最优查询计划，生成与SQL查询请求相对应的目标查询计划；
本申请提供的方案中，由数据访问节点将逻辑SQL访问(SQL查询请求)转化为查询计划(物理数据访问)，而不再由数据库节点将逻辑SQL访问转化为查询计划。由于不同由数据库节点将逻辑SQL访问转换为查询计划，因此可解决数据库节点不支持表级数据多租场景的问题。同时，在搜索到最优查询计划时，利用最优查询计划进行查询，可尽量减少查询成本，提高查询性能。
下面介绍上述SaaS应用***、数据访问节点和查询装置。
请参见图1a，上述SaaS应用***可包括应用节点101、数据访问节点102和数据库节点103(存储租户数据)。其中：
应用节点101主要负责运行SaaS应用***的业务服务。在大容量场景下，请参见图1b，可采用集群部署；
数据访问节点102主要负责运行SaaS应用***的数据库访问服务，提供标准的SQL接口，可接受应用节点101的数据库访问请求，向数据库节点103提交数据库查询(查询计划)，并返回结果给应用节点101。在大容量场景下，请参见图1b，可采用集群部署；
此外，数据访问节点102还可执行本申请提供的查询优化方法，例如下述图3-4所示实施例提供的查询优化方法。
数据库节点103主要负责SaaS应用***的数据存储访问服务，可采用商用数据库，例如：Oracle，MySql等。在大容量场景下，请参见图1b，可采用集群部署。在多租场景下，各租户数据存储在指定数据库节点，可通过部署配置信息来指定数据库节点。
在集群场景下，上述SaaS应用***还可包括负载均衡器104，负载均衡器104主要负责接受SaaS应用客户端的请求(例如逻辑SQL请求)，根据各应用节点101的负载情况，将请求分发给应用节点集群中的应用节点。
ZooKeeper：ZooKeeper为分布式、开放源码的分布式应用程序协调服务，完成统一命名服务、状态同步服务、集群管理、分布式应用配置项管理等工作。
图2a示出了上述数据访问节点102的一种示例性结构，包括：
SQL解析器21：负责解析应用节点101发送的SQL查询请求，生成语法树。
这里的SQL查询请求可包括DDL SQL语句和DML SQL语句。
需要说明的是，本申请着重对DML SQL语句的执行，因此，如无特殊声明，后续的SQL查询请求均指DML SQL语句。
元数据和统计信息缓存22：负责数据访问节点102上的元数据和统计信息缓存，其中，元数据在数据库访问服务启动时从数据库加载，统计信息由数据访问服务实时收集保存。
查询分析器23：负责基于语法树、元数据和统计信息缓存进行查询分析，得到查询分析结果。
查询计划生成器24：可负责确定前述提及的目标查询计划。更具体的，可在未搜索到最优查询计划时，可根据查询分析结果，生成目标查询计划。
此外，查询计划生成器24还可确定针对SQL查询请求的备选查询计划，在存在多个备选查询计划时，向所述数据库查询各备选查询计划的查询成本，缓存查询成本最小的备选查询计划，作为针对该SQL查询请求的最优查询计划。
DML执行器25，负责执行目标查询计划，接收处理数据库返回的查询结果，并向应用节点101返回查询结果。
DDL执行器26，负责执行应用节点101发送的DDL SQL语句(DDL请求)。
数据库访问接口27，提供对各异构数据库的访问接口。
上述查询装置可以硬件或软件的形式部署于数据访问节点102中。
图2b示出了上述查询装置的一种示例性结构，包括接收单元201、处理单元202和提交单元203。其中：
接收单元201可用于接收SQL查询请求；该SQL查询请求用于查询租户数据；
接收单元201可实现SQL解析器21的功能。
处理单元202，用于：
搜索缓存的、针对上述SQL查询请求的最优查询计划；
若搜索出最优查询计划，将该最优查询计划作为目标查询计划；
若未搜索出最优查询计划，生成与该SQL查询请求相对应的目标查询计划。
处理单元202可实现前述查询分析器23和查询计划生成器24的功能。
提交单元203，用于向数据库提交目标查询计划，并向应用节点101返回查询结果。
提交单元203可实现前述DML执行器25的功能。
图2c示出了上述查询装置的另一种示例性结构，包括：
总线、控制器/处理器1、存储器2、通信接口3。
可选地，上述控制终端设备还可以包括输入设备4和输出设备5。
处理器1、存储器2、输入设备4和输出设备5通过总线相互连接。其中：
总线可包括一通路，在计算机***各个部件之间传送信息。
控制器/处理器1可以是通用处理器，例如通用中央处理器(CPU)、网络处理器(Network Processor，NP)、微处理器等，也可以是特定应用集成电路(application-specific integrated circuit，ASIC)，或一个或多个用于控制本申请方案程序执行的集成电路。还可以是数字信号处理器(Digital Signal Processor，DSP)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。控制器/处理器1也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等等。
处理器1可用于实现前述处理单元202的功能。
存储器2中保存有执行本申请技术方案的程序，还可以保存有操作***和其他应用程序。具体地，程序可以包括程序代码，程序代码包括计算机操作指令。更具体的，存储器2可以是只读存储器(read-only memory，ROM)、可存储静态信息和指令的其他类型的静态存储设备、随机存取存储器(random access memory，RAM)、可存储信息和指令的其他类型的动态存储设备、磁盘存储器等等。
输入设备4可包括接收用户输入的数据和信息的终端设备，例如键盘、鼠标、摄像头、扫描仪、光笔、语音输入终端设备、触摸屏等。
输出设备5可包括允许输出信息给用户的终端设备，例如屏幕单元。
通信接口3可包括使用任何收发器一类的终端设备，以便支持控制终端设备与其他设备或通信网络通信。通信接口3可用于实现前述接收单元201和提交单元203的功能。
可以理解的是，图2b仅仅示出了控制终端设备的简化设计。在实际应用中，控制终端设备可以包含任意数量的发射器，接收器，处理器，控制器，存储器，通信接口等，而所有可以实现本申请的控制终端设备都在本申请的保护范围之内。
处理器1执行存储器2中所存放的程序，以及调用其他设备，可用于实现下述图3-4所示实施例提供的查询优化方法。
索引作为数据库***中的关键数据结构，在数据库***的查询优化中发挥重要作用。通过使用索引,可以实现快速访问物理数据库表中的记录。
实际中，一个逻辑SQL访问可能会对应多个查询计划，例如，存在多个索引时，会对应多个查询计划。
而如何确定最优的查询计划，是查询优化技术需要重点解决的一个问题。
目前，主流通用数据库***，如：Oracle，通过基于成本的CBO实现查询优化。其实现原理是：基于一系列的数据库内部统计信息，为不同的查询计划计算成本，并从中选择最小成本的查询计划作为最优查询计划。
但是，宽表中存储了多个租户的租户数据，而现有的数据库节点并不支持表级数据多租场景，即不能感知宽表某一字段中存储的数据来自不同租户，具有不同的数据类型和分布特征。
因此，现有方式虽可以建立数据库索引以提高查询性能，但数据库索引只能针对全量表数据进行创建，不能满足对于多租场景下只希望在某个租户数据上创建索引的需求。
为此，引入索引Pivot表，以满足在某个租户数据上创建索引的需求。
索引Pivot表结构如下表6和表7所示，分别支持非唯一性索引和唯一性索引。
其中，Index Pivot表的string_value、num_value、date_value字段分别存储字符串、数值、日期类字段值，且其上均创建非唯一性索引；而Unique Index Pivot表的这些字段上则创建唯一性索引。
Index Pivot 说明
tenant_id 租户ID
obj_id 对象类型ID
field_num 字段在宽表中的列号
Guid 记录全局Guid
string_value 字符串值
num_value 数字值
date_value 日期值
表6
表7
另外，还需通过一组元数据表，定义索引Pivot表中的数据，包括索引元数据表(indexes)和索引字段表(index_fields)。其中：
索引元数据表的模型如下表8所示，索引字段表的模型如下表9所示。
Indexes 说明
index_id 索引ID
tenant_id 租户ID
obj_id 对象类型ID
index_name 索引名
index_type 索引类型
status 索引状态
create_time 创建时间
update_time 更新时间
表8
index_fields 说明
index_id 索引ID
tenant_id 租户ID
obj_id 对象类型ID
field_id 字段ID
表9
示例性的，假定宽表中存储的租户101的ACCOUNT数据对象如下表10所示。假设租户指定在ACCOUNT对象的ACCOUNT_NAME字段(value0字段)创建非唯一性索引。则索引元数据表(indexes)如下表11所示，而索引Pivot表如下表12所示。
tenant_id obj_id Guid version delete_time value0 value1 value2
101 201 1000001 V1 null ACCID_1 Tom Nanjing
101 201 1000002 V1 null ACCID_2 Jack Shanghai
101 201 1000003 V1 null ACCID_3 Mary Beijing
101 201 1000004 V1 null ACCID_4 Penny Hongkong
表10
表11
tenant_id obj_id field_num Guid string_value num_value date_value
101 201 0 1000001 ACCID_1 Null Null
101 201 0 1000002 ACCID_2 Null Null
101 201 0 1000003 ACCID_3 Null Null
101 201 0 1000004 ACCID_4 Null Null
表12
虽然索引Pivot表可满足多租场景下只希望在某个租户数据上创建索引的需求，但是，数据库节点自身无法感知应用层的索引Pivot表机制。
为解决这一问题，在一种现有方式中，可由SaaS***在其应用层实现一套统计信息收集维护和查询优化机制。具体的，SaaS***基于租户、用户组(用户隶属于租户)、用户级别维护一套完整的优化统计信息。上述优化统计信息能够反映一个特定的查询可能访问的记录行数。同时也维护了各租户创建的索引的统计信息，能够体现索引字段的非空值、不同值的数量直方图分布等。
计算各种可能物理SQL(查询计划)的成本，选择具有最小成本的物理SQL(查询计划)作为最终的物理SQL(查询计划)提交给数据库。
然而，上述现有方式并没有充分利用数据库自身的CBO能力(包括统计信息、成熟的成本评估算法等)，对数据库能力是一种浪费。
此外，还存在如下缺点：
完全在应用层实现各类统计信息收集维护和CBO，增加***的实现复杂度；
优化统计信息收集频率过高将增加数据库自身的压力，过低可能导致统计信息长期失效；
面对中小租户场景，在租户、用户和自定义对象较多时，大量统计数据存储空间较大。
为解决现有方式并没有充分利用数据库自身的CBO能力的问题，图3示出了上述查询优化方法的一种示例性流程。在本实施例中，以第1次接收SQL查询请求和第i次接收到同一SQL查询请求为例，进行了介绍。
上述示例性流程包括：
300：数据访问节点首次接收查询租户数据的某SQL请求(即DML SQL语句)。
该SQL查询请求，是用户通过前述应用节点的数据库访问服务发送的。
需要说明的是，虽然租户数据存储在宽表中，但对于用户而言，其看到的却不是宽表，而是逻辑表。例如前述提及的宽表中租户101的ACCOUNT数据对象，对于用户而言，是一张逻辑的ACCOUNT表。
举例来讲，用户欲查询查询逻辑ACCOUNT表中，名字为“ABC”的所有记录中的ID、名称(name)和地址(address)。则其逻辑SQL语句如下所示：
SELECT ACCOUNT_ID,ACCOUNT_NAME,ADDRESS
FROM ACCOUNT
WHERE ACCOUNT_NAME＝‘ABC’。
更具体的，可由前述的接收单元201执行步骤300。
301：数据访问节点查询装置搜索缓存的、针对SQL查询请求的最优查询计划；若未搜索出，进入步骤302，若搜索出，进入步骤311；
若非首次接收到SQL查询请求，则可能会缓存有针对该SQL查询请求的最优查询计划。但是，300部分是第一次接收到上述SQL请求，所以无法搜寻到最优查询计划，在本步骤之后将进入步骤302。
更具体的，可由前述查询装置的处理单元202执行步骤301。
302：数据访问节点生成与上述SQL查询请求相对应的目标查询计划，并缓存；
数据访问节点可根据租户数据的统计信息生成目标查询计划。
可令数据访问节点的数据访问服务维护租户级别的基本统计信息，包括：
表信息(包括租户数据的元数据)，例如字段类型、大小、数据量等；
索引信息(包括索引元数据)，例如索引类型(唯一性或非唯一性)、索引字段类型、索引优先级等；
需要说明的是，本实施例不在数据访问服务中完整实现CBO优化，因此需要保存的统计信息有限，且部分已经在租户的对象元数据中体现。
上述统计信息可持久化保存在物理数据库中，同时在数据访问服务的内存中缓存，以助于访问加速。
更具体的，数据访问节点可根据元数据和统计信息缓存进行查询分析，得到查询分析结果，并根据查询分析结果确定前述的目标查询计划。
上述查询分析结果可包括：逻辑表待查询字段，对应物理数据库中的哪张表中的哪个字段，上述物理数据库中的字段所对应的索引等。
例如，以步骤300中的逻辑SQL语句为例，并假定表10-12中的ACCID_4即ABC，则可得到查询分析结果包括：
ID为101的租户的逻辑表ACCOUNT中的ACCOUNT_ID字段，对应宽表(DATA D)中的value 0字段，以及字段对应的GUID；
ID为101的租户的逻辑表ACCOUNT中的ACCOUNT_NAME字段，对应宽表的value1字段；
ID为101的租户的逻辑表ACCOUNT中的ADDRES字段，对应宽表的value 2字段；
同时，还可得知，租户ID为101、obj_id为201的租户数据对应索引表INDEXES I。并且，宽表中的租户ID，即为INDEXES I中的租户ID；宽表中的obj_id，即为INDEXES I中的obj_id；宽表中的GUID，即为INDEXES I中的GUID；
此外，假设在逻辑表ACCOUNT中的ACCOUNT_NAME字段上创建了索引，则上述查询分析结果还可包括该索引的索引优先级等。
在一个示例中，在得到查询分析结果后，可按照如下规则确定目标查询计划：
一，若上述SQL查询请求对应唯一的索引，则根据该唯一的索引生成目标查询计划；
二，若上述SQL查询请求对应多个索引，根据优先级最高的索引生成目标查询计划；而若优先级相同，随机选取一个索引生成目标查询计划。
举例来讲，SQL查询请求对应索引A和B，如果索引A的优先级高，则根据索引A生成目标查询计划。而如果两个索引优先级相同，则随机选取一个生成目标查询计划。
三，当涉及关联查询多张表格时，选择具有索引的表格作为驱动表生成目标查询计划。
其中，若仅一张表格具有索引，将该具有索引的表格作为驱动表；而若至少两张表格具有索引，选择具有小数据量的表格作为驱动表。
举例来讲，涉及关联查询表A和表B，表A具有索引，而表B不具有索引，则选择表A作为驱动表生成目标查询计划。
而如果表A和表B都具有索引，而表A的数据量小于表B，则选择表A作为驱动表。
更具体的，上述小数据量可指表包含的数据量小，也可指符合查询条件的数据量小。
以表包含的数据量小为例，假定表A包括100条记录，而表B包括1000条记录，则选择表A为驱动表。
以符合查询条件的数量量小为例，假定表A符合查询条件的记录为10条，而表B符合查询条件的记录为1000条，则选择表A为驱动表。
在一个示例中，可由前述查询装置的处理单元202执行步骤302。
303：数据访问节点向数据库提交生成的目标查询计划。
更具体的，可由前述查询装置的提交单元203执行步骤303。
数据库节点在接收到目标查询计划后，会基于目标查询计划在宽表中查询租户数据。
前述提及，目标查询计划包括一条或多条物理SQL。数据库节点会基于自身的CBO能力对物理SQL进行优化，最终确定出数据库内部执行路径。
304：数据访问节点接收数据库节点返回的查询结果，并返回相应的应用节点。
更具体的，可由前述查询装置的提交单元203或处理单元202执行步骤304。
305：数据访问节点确定针对SQL查询请求的备选查询计划。
更具体的，可由前述查询装置的处理单元202执行步骤305。
数据访问节点会根据统计信息，确定备选查询计划(上述目标查询计划也会作为备选查询计划)。
当租户数据存在多个索引时，会生成多个备选查询计划。
沿用步骤302的例子，假设在租户数据的“num_value”和“string_value”两个字段上创建了索引，则会基于这两个索引生成两个备选查询计划。这两个备选查询计划一个为：
另一个为：
306：若针对SQL查询请求的备选查询计划的数量为多个，数据访问节点向数据库查询各备选查询计划的查询成本。
可由前述查询装置的处理单元202执行步骤306。
沿用步骤305中的例子，数据访问节点会向数据库逐个查询上述两备选查询计划的查询成本。这里的查询成本可为：综合了时间、资源消耗等方面的综合成本。
一般情况下，数据访问节点会先查询一个备选查询计划的查询成本，在数据库返回了查询成本后，再接着查询下一个备选计划的查询成本。
其中，针对第一个备选查询计划的SQL查询语句为：
针对第二个备选查询计划的SQL查询语句为：
在得到两备选查询计划的查询成本后，则可对查询成本进行比较。
假定，两备选查询计划的查询成本分别为Cost1和Cost2。假设Cost2<Cost1，说明基于数据库的CBO分析，第二备选查询计划查询成本更低，基于第二备选查询计划可得到更优的数据库内部执行计划。
307：数据访问节点缓存查询成本最小的备选查询计划，作为针对SQL查询请求的最优查询计划；
同时，若前述的目标查询计划与最优查询计划不同时，可将目标查询计划置为失效。
当再次接收到同一SQL查询请求时，缓存的、针对该SQL查询请求的最优查询计划将作为目标查询计划，以在下次查询时，获得更好的查询性能。
可见，在存在多个备选查询计划时，本实施例将利用数据库基于成本优化(Cost-Based Optimization，CBO)的能力，得到最优查询计划。与现有方式相比，其充分利用了数据库自身的CBO能力。
可由前述查询装置的处理单元202执行步骤307。
308：数据访问节点调高最优查询计划所使用的索引的优先级。
假定备选查询计划A基于索引A生成，备选查询计划B基于索引B生成。备选查询计划A作为最优查询计划，则调高索引A的优先级。
调高优先级的方式有多种。例如，可设计令优先级最初均为统一初始数值(例如0)，每次被最优查询计划使用，则将优先级增加a(例如1)。
可由前述查询装置的处理单元202执行步骤308。
需要说明的是，步骤305-308可合称为异步查询优化任务。
在一个示例中，可在触发条件满足时，启动异步查询优化任务。
触发条件可包括：
A：定期空闲时刷新，如：***空闲时；
B：表数据大量变更，如：大量数据导入后；
C：查询性能发生大的下降。
309：数据访问节点第i次(非首次)接收到该SQL请求；
步骤309与步骤300相类似，在此不作赘述。
310：数据访问节点数据访问节点查询装置搜索缓存的、针对该SQL查询请求的最优查询计划；若未搜索出，进入步骤302，若搜索出，进入步骤311；
由于已经是第i次，而不是首次接收到同一SQL请求，则在310步骤后，将进入步骤311。
步骤310与前述步骤301相类似，在此不作赘述。
311：数据访问节点将搜索到的最优查询计划作为目标查询计划，返回步骤303。
在一个示例中，可由前述查询装置的处理单元202执行步骤311。
可见，在本实施例中，在存在多个备选查询计划时，数据访问节点会利用数据库基于成本优化(Cost-Based Optimization，CBO)的能力得到各查询计划的查询成本，并选择查询成本最小的备选计划作为最优查询计划。并且，可基于数据宽表和索引Pivot表进行关联查询，有效解决通用数据库的索引技术在多租场景和宽表模型下的失效问题，充分利用了索引Pivot表的索引能力。
并且，本实施例不在数据访问服务中完整实现CBO优化，因此需要保存的统计信息有限，且部分已经在租户的对象元数据中体现。因此，可简化应用层实现、减少数据库查询压力，并可减少统计信息的存储空间。
图4示出了上述查询优化方法的另一种示例性流程。
在本实施例中，介绍了确定备选查询计划的另一时机。
上述示例性流程包括：
400：数据访问节点接收查询租户数据的SQL请求；
相关描述请参见前述实施例的步骤300的记载，在此不作赘述。
401：数据访问节点确定针对该SQL查询请求的备选查询计划；
步骤401与前述步骤305相类似，在此不作赘述。
402：数据访问节点查询装置搜索缓存的、针对SQL查询请求的最优查询计划；若未搜索出，进入步骤403，若搜索出，进入步骤404；
步骤402与前述实施例的步骤301相类似，在此不作赘述。
403：数据访问节点从备选查询计划中确定目标查询计划，并缓存；
在一个示例中，可按照如下方式确定目标查询计划：
一，若仅有一个备选查询计划使用索引，则选择该备选查询计划作为目标查询计划；
二，若有多个备选查询计划使用索引，将使用优先级最高的索引的备选查询计划，作为目标查询计划；而若优先级相同，随机选取一个作为目标查询计划。
三，当涉及关联查询多张表格时，选择驱动表具有索引的查询计划作为目标查询计划。
其中，若仅一个备选查询计划的驱动表具有索引，则将该备选查询计划作为目标查询计划；
而若至少两个备选查询计划的驱动表具有索引，选择以小数据量的表格作为驱动表的备选查询计划，作为目标查询计划。
本部分类似于前述实施例中的“确定目标查询计划”的方式，在此不作赘述。
404：数据访问节点将搜索到的最优查询计划作为目标查询计划。
步骤404与前述实施例中的步骤311相类似，在此不作赘述。
405：数据访问节点向数据库提交目标查询计划，接收数据库节点返回的查询结果，并返回相应的应用节点。
可参见前述303-304部分的记载，在此不作赘述。
406：若针对SQL查询请求的备选查询计划的数量为多个，数据访问节点向数据库查询各备选查询计划的查询成本。
可参见前述306部分的记载，在此不作赘述。
并且，406可在满足前述触发条件时执行。
407：数据访问节点缓存查询成本最小的备选查询计划，作为针对SQL查询请求的最优查询计划。
可参见前述307部分的记载，在此不作赘述。
408：数据访问节点调高最优查询计划所使用的索引的优先级。
可参见前述308部分的记载，在此不作赘述。
在本实施例中，备选查询计划的生成，要早于目标查询计划的确定，提供了另一种实现查询优化的方法。
结合本申请公开内容所描述的方法或者算法的步骤可以硬件的方式来实现，也可以是由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成，软件模块可以被存放于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、移动硬盘、CD-ROM或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。另外，该ASIC可以位于用户设备中。当然，处理器和存储介质也可以作为分立组件存在于用户设备中。
本领域技术人员应该可以意识到，在上述一个或多个示例中，本申请所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。
以上所述的具体实施方式，对本申请的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本申请的具体实施方式而已，并不用于限定本申请的保护范围，凡在本申请的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本申请的保护范围之内。

Claims (12)

1.一种查询优化方法，其特征在于，应用于数据访问节点，包括：
接收查询请求；所述查询请求用于查询租户数据；
搜索针对所述租户数据的最优查询计划；
若搜索出最优查询计划，将搜索出的最优查询计划作为目标查询计划；
若未搜索出最优查询计划，生成针对所述租户数据的目标查询计划；
向数据库提交所述目标查询计划，所述目标查询计划用于所述数据库查询所述租户数据。
2.如权利要求1所述的方法，其特征在于，还包括：
确定针对所述查询请求的备选查询计划；其中，所述备选查询计划包括所述目标查询计划；
若针对所述查询请求的备选查询计划的数量为多个，向所述数据库查询各备选查询计划的查询成本；
缓存查询成本最小的备选查询计划，作为针对所述租户数据的最优查询计划；
当再次接收到所述查询请求时，针对所述租户数据的最优查询计划将作为目标查询计划。
3.如权利要求2所述的方法，其特征在于，在缓存查询成本最小的备选查询计划之后，还包括：调高所述查询成本最小的备选查询计划所使用的索引的优先级。
4.如权利要求3所述的方法，其特征在于，所述生成针对所述租户数据的目标查询计划包括：
根据所述租户数据的统计信息，生成针对所述租户数据的目标查询计划，所述统计信息包括所述租户数据的元数据及所述租户数据对应的索引元数据，所述索引元数据至少包括索引的优先级。
5.如权利要求4所述的方法，其特征在于，所述根据所述租户数据的统计信息，生成针对所述租户数据的目标查询计划包括：
若所述查询请求对应多个索引，根据优先级最高的索引生成所述目标查询计划；若优先级相同，从所述多个索引中随机选取一个索引生成所述目标查询计划。
6.一种查询优化装置，其特征在于，包括：
接收单元，用于接收查询请求；所述查询请求用于查询租户数据；
处理单元，用于：
搜索针对所述租户数据的最优查询计划；
若搜索出最优查询计划，将所述最优查询计划作为目标查询计划；
若未搜索出最优查询计划，生成针对所述租户数据的目标查询计划；
提交单元，用于向数据库提交所述目标查询计划，所述目标查询计划用于所述数据库查询所述租户数据。
7.如权利要求6所述的装置，其特征在于，所述处理单元还用于：
确定针对所述查询请求的备选查询计划；其中，所述备选查询计划包括所述目标查询计划；
若针对所述查询请求的备选查询计划的数量为多个，向所述数据库查询各备选查询计划的查询成本；
缓存查询成本最小的备选查询计划，作为针对所述租户数据的最优查询计划；
当再次接收到所述查询请求时，针对所述租户数据的最优查询计划将作为目标查询计划。
8.如权利要求7所述的装置，其特征在于，所述处理单元还用于：
在缓存查询成本最小的备选查询计划之后，调高所述查询成本最小的备选查询计划所使用的索引的优先级。
9.如权利要求8所述的装置，其特征在于，在生成所述针对所述租户数据的目标查询计划的方面，所述处理单元具体用于：
根据所述租户数据的统计信息，生成针对所述租户数据的目标查询计划，所述统计信息包括所述租户数据的元数据及所述租户数据对应的索引元数据，所述索引元数据至少包括索引的优先级。
10.如权利要求9所述的装置，其特征在于，在根据所述租户数据的统计信息，生成针对所述租户数据的目标查询计划的方面，所述处理单元具体用于：
若所述查询请求对应多个索引，根据优先级最高的索引生成所述目标查询计划；若优先级相同，从所述多个索引中随机选取一个索引生成所述目标查询计划。
11.一种数据访问节点，其特征在于，包括如权利要求6-10任一项所述的查询优化装置。
12.一种软件即服务SaaS应用***，包括应用节点、数据库节点以及如权利要求12所述的数据访问节点。
CN201710210122.7A 2017-03-31 2017-03-31 查询优化方法及相关装置 Pending CN108664516A (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN201710210122.7A CN108664516A (zh) 2017-03-31 2017-03-31 查询优化方法及相关装置
EP18774545.0A EP3591547A4 (en) 2017-03-31 2018-02-27 REQUEST OPTIMIZATION METHOD AND ASSOCIATED DEVICE
PCT/CN2018/077425 WO2018177060A1 (zh) 2017-03-31 2018-02-27 查询优化方法及相关装置
US16/579,209 US20200019552A1 (en) 2017-03-31 2019-09-23 Query optimization method and related apparatus

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710210122.7A CN108664516A (zh) 2017-03-31 2017-03-31 查询优化方法及相关装置

Publications (1)

Publication Number Publication Date
CN108664516A true CN108664516A (zh) 2018-10-16

Family

ID=63675223

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710210122.7A Pending CN108664516A (zh) 2017-03-31 2017-03-31 查询优化方法及相关装置

Country Status (4)

Country Link
US (1) US20200019552A1 (zh)
EP (1) EP3591547A4 (zh)
CN (1) CN108664516A (zh)
WO (1) WO2018177060A1 (zh)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111311329A (zh) * 2020-02-20 2020-06-19 口碑(上海)信息技术有限公司 标签数据获取方法、装置、设备及可读存储介质
CN111382174A (zh) * 2018-12-28 2020-07-07 百度在线网络技术（北京）有限公司 多方数据联合查询方法、装置、服务器和存储介质
CN111435351A (zh) * 2019-01-15 2020-07-21 阿里巴巴集团控股有限公司 数据库查询优化方法、设备及存储介质
CN111506559A (zh) * 2020-04-21 2020-08-07 北京同邦卓益科技有限公司 数据存储方法、装置、电子设备及存储介质
CN111666279A (zh) * 2020-04-14 2020-09-15 阿里巴巴集团控股有限公司 查询数据处理方法、装置、电子设备及计算机存储介质
CN111797116A (zh) * 2019-04-09 2020-10-20 埃森哲环球解决方案有限公司 利用优化提示的查询调整
CN112181704A (zh) * 2020-09-28 2021-01-05 京东数字科技控股股份有限公司 一种大数据任务处理方法、装置、电子设备及存储介质
CN114297224A (zh) * 2021-12-22 2022-04-08 重庆邮电大学 一种基于rdf的异构数据集成与查询***及方法
WO2023237120A1 (zh) * 2022-06-10 2023-12-14 华为技术有限公司 一种数据处理***及装置

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11675788B2 (en) * 2019-04-01 2023-06-13 Sap Se Generation of query execution plans
CN112052255B (zh) * 2020-09-02 2022-05-03 福建天晴在线互动科技有限公司 一种自上而下拆分多表慢查询的sql解释方法及其装置
CN113886416A (zh) * 2021-09-24 2022-01-04 广州辰创科技发展有限公司 一种基于rbca模型构建的数据库的快速检索方法
US11893015B2 (en) * 2021-11-18 2024-02-06 International Business Machines Corporation Optimizing query performance in virtual database
CN115964374B (zh) * 2023-02-22 2023-09-26 深圳计算科学研究院 一种基于预计算场景的查询处理方法及其装置
CN116578583B (zh) * 2023-07-12 2023-10-03 太平金融科技服务（上海）有限公司 异常语句识别方法、装置、设备、存储介质
CN117688104B (zh) * 2024-02-01 2024-06-21 腾讯科技（深圳）有限公司 请求处理方法、装置、电子设备及存储介质

Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6021405A (en) * 1996-08-23 2000-02-01 Tandem Computers, Inc. System and method for optimizing database queries with improved performance enhancements
CN101174267A (zh) * 2006-10-30 2008-05-07 国际商业机器公司 集成数据库的***、方法和程序产品
CN102388374A (zh) * 2011-09-28 2012-03-21 华为技术有限公司 存储数据的方法和装置
US20120173513A1 (en) * 2010-12-31 2012-07-05 Microsoft Corporation Allocation of tenants to database services
CN102760167A (zh) * 2012-06-13 2012-10-31 上海方正数字出版技术有限公司 基于粒子群优化算法的XQuery查询路径优化方法
US20120330924A1 (en) * 2011-06-21 2012-12-27 Salesforce.Com, Inc. Method and system for querying an on demand database service
CN103064955A (zh) * 2012-12-28 2013-04-24 华为技术有限公司 查询规划方法及装置
CN103324724A (zh) * 2013-06-26 2013-09-25 华为技术有限公司 数据处理方法及装置
CN103399942A (zh) * 2013-08-14 2013-11-20 山大地纬软件股份有限公司 一种支持SaaS多租户的数据引擎***及其工作方法
CN103605698A (zh) * 2013-11-06 2014-02-26 广东电子工业研究院有限公司 一种用于分布异构数据资源整合的云数据库***
US8775413B2 (en) * 2008-06-30 2014-07-08 Teradata Us, Inc. Parallel, in-line, query capture database for real-time logging, monitoring and optimizer feedback
US20150112966A1 (en) * 2012-04-27 2015-04-23 The University Of Tokyo Database management system, computer, and database management method
CN105005606A (zh) * 2015-07-03 2015-10-28 华南理工大学 基于MapReduce的XML数据查询方法和***
CN105279286A (zh) * 2015-11-27 2016-01-27 陕西艾特信息化工程咨询有限责任公司 一种交互式大数据分析查询处理方法

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7529728B2 (en) * 2003-09-23 2009-05-05 Salesforce.Com, Inc. Query optimization in a multi-tenant database system
CN102609451B (zh) * 2012-01-11 2014-12-17 华中科技大学 面向流式数据处理的sql查询计划生成方法
KR101432700B1 (ko) * 2012-10-10 2014-08-25 (주)티베로 쿼리의 최적화를 위한 방법
CN103729471B (zh) * 2014-01-21 2017-03-08 华为软件技术有限公司 数据库查询方法和装置
JP6628455B2 (ja) * 2015-11-30 2020-01-08 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． データ照会方法および装置ならびにデータベースシステム

Patent Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6021405A (en) * 1996-08-23 2000-02-01 Tandem Computers, Inc. System and method for optimizing database queries with improved performance enhancements
CN101174267A (zh) * 2006-10-30 2008-05-07 国际商业机器公司 集成数据库的***、方法和程序产品
US8775413B2 (en) * 2008-06-30 2014-07-08 Teradata Us, Inc. Parallel, in-line, query capture database for real-time logging, monitoring and optimizer feedback
US20120173513A1 (en) * 2010-12-31 2012-07-05 Microsoft Corporation Allocation of tenants to database services
US20120330924A1 (en) * 2011-06-21 2012-12-27 Salesforce.Com, Inc. Method and system for querying an on demand database service
CN102388374A (zh) * 2011-09-28 2012-03-21 华为技术有限公司 存储数据的方法和装置
US20150112966A1 (en) * 2012-04-27 2015-04-23 The University Of Tokyo Database management system, computer, and database management method
CN102760167A (zh) * 2012-06-13 2012-10-31 上海方正数字出版技术有限公司 基于粒子群优化算法的XQuery查询路径优化方法
CN103064955A (zh) * 2012-12-28 2013-04-24 华为技术有限公司 查询规划方法及装置
CN103324724A (zh) * 2013-06-26 2013-09-25 华为技术有限公司 数据处理方法及装置
CN103399942A (zh) * 2013-08-14 2013-11-20 山大地纬软件股份有限公司 一种支持SaaS多租户的数据引擎***及其工作方法
CN103605698A (zh) * 2013-11-06 2014-02-26 广东电子工业研究院有限公司 一种用于分布异构数据资源整合的云数据库***
CN105005606A (zh) * 2015-07-03 2015-10-28 华南理工大学 基于MapReduce的XML数据查询方法和***
CN105279286A (zh) * 2015-11-27 2016-01-27 陕西艾特信息化工程咨询有限责任公司 一种交互式大数据分析查询处理方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ARIC红尘醉: "SqlServer执行计划", 《HTTPS://BLOG.CSDN.NET/ARICZHOU/ARTICLE/DETAILS/50377831》 *
王金全: "一种多租户数据管理方法及其在智能交通中的应用", 《中国优秀硕士学位论文全文数据库 信息科技辑》 *

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111382174A (zh) * 2018-12-28 2020-07-07 百度在线网络技术（北京）有限公司 多方数据联合查询方法、装置、服务器和存储介质
CN111382174B (zh) * 2018-12-28 2023-10-17 百度在线网络技术（北京）有限公司 多方数据联合查询方法、装置、服务器和存储介质
CN111435351B (zh) * 2019-01-15 2023-05-26 阿里巴巴集团控股有限公司 数据库查询优化方法、设备及存储介质
CN111435351A (zh) * 2019-01-15 2020-07-21 阿里巴巴集团控股有限公司 数据库查询优化方法、设备及存储介质
CN111797116A (zh) * 2019-04-09 2020-10-20 埃森哲环球解决方案有限公司 利用优化提示的查询调整
CN111311329A (zh) * 2020-02-20 2020-06-19 口碑(上海)信息技术有限公司 标签数据获取方法、装置、设备及可读存储介质
CN111311329B (zh) * 2020-02-20 2023-07-25 口碑(上海)信息技术有限公司 标签数据获取方法、装置、设备及可读存储介质
CN111666279A (zh) * 2020-04-14 2020-09-15 阿里巴巴集团控股有限公司 查询数据处理方法、装置、电子设备及计算机存储介质
CN111506559A (zh) * 2020-04-21 2020-08-07 北京同邦卓益科技有限公司 数据存储方法、装置、电子设备及存储介质
CN111506559B (zh) * 2020-04-21 2024-04-05 北京同邦卓益科技有限公司 数据存储方法、装置、电子设备及存储介质
CN112181704A (zh) * 2020-09-28 2021-01-05 京东数字科技控股股份有限公司 一种大数据任务处理方法、装置、电子设备及存储介质
CN114297224A (zh) * 2021-12-22 2022-04-08 重庆邮电大学 一种基于rdf的异构数据集成与查询***及方法
WO2023237120A1 (zh) * 2022-06-10 2023-12-14 华为技术有限公司 一种数据处理***及装置

Also Published As

Publication number Publication date
US20200019552A1 (en) 2020-01-16
EP3591547A1 (en) 2020-01-08
WO2018177060A1 (zh) 2018-10-04
EP3591547A4 (en) 2020-02-12

Similar Documents

Publication Publication Date Title
CN108664516A (zh) 查询优化方法及相关装置
US10713248B2 (en) Query engine selection
JP7130600B2 (ja) ファーストクラスデータベース要素としての半構造データの実装
US8732163B2 (en) Query optimization with memory I/O awareness
CN109144994A (zh) 索引更新方法、***及相关装置
CN102638584B (zh) 数据分布缓存方法及***
CN108628986A (zh) 数据查询方法、装置、计算机设备和存储介质
CN103631911B (zh) 基于数组存储和向量处理的olap查询处理方法
US11216474B2 (en) Statistical processing of natural language queries of data sets
US9930113B2 (en) Data retrieval via a telecommunication network
US11762775B2 (en) Systems and methods for implementing overlapping data caching for object application program interfaces
CN108733727A (zh) 一种查询处理方法、数据源注册方法及查询引擎
US11366811B2 (en) Data imprints techniques for use with data retrieval methods
CN114443680A (zh) 数据库管理***、相关装置、方法和介质
Kuzochkina et al. Analyzing and Comparison of NoSQL DBMS
CN114443615A (zh) 数据库管理***、相关装置、方法和介质
CN108241709A (zh) 一种数据集成方法、装置和***
CN111259062A (zh) 一种能够保证分布式数据库全表查询语句结果集顺序的方法和装置
US11379485B2 (en) Inferred predicates for query optimization
CN115168389A (zh) 请求处理方法以及装置
CN114238374A (zh) 数据查询方法、装置、服务器和存储介质
EP2990960A1 (en) Data retrieval via a telecommunication network
Xu et al. A unified computation engine for big data analytics
CN112286995B (zh) 一种数据分析方法、装置、服务器、***及存储介质
US11841857B2 (en) Query efficiency using merged columns

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
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20181016