CN117529714A

CN117529714A - 用于为迁移rdbms推荐存储格式的方法和系统

Info

Publication number: CN117529714A
Application number: CN202280042348.XA
Authority: CN
Inventors: 维沙尔·纳维尼特·潘迪亚; 维内特·库马尔·马赫什瓦里
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2021-06-19
Filing date: 2022-03-04
Publication date: 2024-02-06
Also published as: WO2022262325A1; EP4334823A1

Abstract

本发明提供了一种为将关系型数据库管理系统(relational database management system，RDBMS)从源服务器系统迁移到目标服务器系统推荐存储格式的方法。所述方法包括：从所述源服务器系统的源数据库中提取SQL查询(302)；解析所述SQL查询以识别与列式操作对应的一组查询(304)；确定在所述识别出的一组查询中使用的列数(Cn)(306)；对于所述多列(Cn)中的每一列(C)，确定列记录中的至少部分列记录的值是否相同(308)；在确定时，为所述目标服务器系统中的所述RDBMS推荐列存储格式(310)。

Description

用于为迁移RDBMS推荐存储格式的方法和系统

技术领域

本文中描述的本发明大体上涉及数据库的存储格式，尤其涉及关系型数据库管理系统(Relational Database Management System，RDBMS)的存储优化和工作负载序列优化。

背景技术

关系型数据库管理系统(relational database management system，RDBMS或简称RDB)是一种常见的数据库类型，它将数据存储在表中，因此可以与其他存储的数据集进行关联使用。目前企业使用的大多数数据库都是关系型数据库，而不是平面文件或分层数据库。当前大多数IT系统和应用都基于关系型DBMS。关系型数据库具有处理大量数据和复杂查询的能力。数据通常存储在许多表中，这些表也称为“关系”。

这些表分为行(也称为记录)和列(称为字段)。数据库中可能有数百万行。列由一种特定的数据类型组成，例如，名称或值。关系型数据库有两种组织方式：

·面向行的方式

·面向列的方式(也称为列式或列存储)

面向行的数据库是按记录整理数据的数据库，以将与记录相关联的相互紧挨着的所有数据保存在内存中。面向行的数据库是整理数据的传统方式，在快速存储数据方面仍然提供一些关键优势。优化面向行的数据库，以高效读取和写入行。常见的面向行的数据库有Postgres和MySQL。

面向列的数据库是按字段整理数据的数据库，以将与字段相关联的相互紧挨着的所有数据保存在内存中。列式数据库越来越受欢迎，为查询数据提供了性能优势。优化面向列的数据库，以高效读取和计算列。常见的面向列的数据库有Redshift、BigQuery和Snowflake。

为了了解基于行的存储和基于列的存储的优缺点，以下面的表1为例：

这些数据可以在面向行的数据库(也称为“基于行的存储”)中存储在磁盘上，如下所示逐行存储：

印度

Alpha

1200

中国

Beta

2500

UK

Alpha

700

JP

Alpha

450

如果想要添加一条新记录，只需要将该新纪录附加到当前数据的末尾即可。

面向行的数据库可以很好地管理对数据库的写入，因此仍然常用于联机事务处理(Online Transactional Processing，OLTP)风格的应用。然而，数据库的另一个用例是分析其中的数据。这些联机分析处理(Online Analytical Processing，OLAP)用例需要一个能够支持即席(ad hoc)数据查询的数据库。这就是面向行的数据库比列存储数据库慢的地方。面向行的数据库在检索一行或一组行时速度很快，但在执行聚合时会将额外的数据(列)加载到内存中，这比只选择要执行聚合的列要慢。另外，面向行的数据库可能需要访问的磁盘通常很多。假设想要从表1数据中获取销售额的总和。为此，需要将所有12条数据(参见基于行的存储格式)加载到内存中，然后取出相关数据进行聚合。这就浪费了计算时间。为了了解被访问的磁盘的数量，假设一个磁盘只能容纳足够用于在每个磁盘中存储三列的数据字节。在面向行的数据库中，上述表的存储格式如下：

为了计算所有国家销售额的总和，计算机需要查看所有四个磁盘，并且跨越每个磁盘中的所有三列才能进行此查询。因此，可以看到，虽然向面向行的数据库添加数据既快速又简单，但从中获取数据却需要使用额外的内存和访问多个磁盘。

创建数据仓库是为了支持分析数据。这些类型的数据库都经过读取优化。在列存储、列式或面向列的数据库中，数据的存储方式是，一列的每一行都与同一列的其他行紧挨着。再次查看表1中的相同数据集，看看它在面向列的数据库(也称为“基于列的存储”或“列存储”)中的存储方式：

印度

中国

UK

JP

Alpha

Beta

Alpha

1200

2500

700

450

如果想要添加一条新记录，就必须浏览数据，将每一列插入到它应该在的位置上。

如果数据存储在单个磁盘中，这就会面临与面向行的数据库相同的额外内存问题，因为这需要将所有内容加载到内存中。然而，面向列的数据库存储在单独的磁盘中会带来显著的优势。如果将上表放入数据磁盘的四个受限列中，它们的存储方式如下所示：

为了计算国家销售额的总和，计算机只需要访问一个磁盘(磁盘3)并对其内部的所有值求和。不需要额外的内存加载，并且访问尽可能少的磁盘。虽然这有点过于简化，但它说明了，通过按列整理数据，需要访问的磁盘会变少，必须保存在内存中的额外数据量也会降到最低。这大大提高了计算的整体速度。面向列的数据库还可以通过其他方式提高性能。此外，如果每条数据的比特数相同，则所有数据都可以进一步压缩，压缩后的大小为数据条数乘以单条数据的比特数。假设有一个包括一百万行的表。大多数列可能只有几百或最多几千个唯一值。压缩可确保节省磁盘空间，而索引可确保更快地查找数据。这就为客户优化了云存储成本。因此，行存储格式与列存储格式可以汇总如下：

属性	行存储	列存储
			内存使用率	较高	较低
事务	较快	较慢
			分析	较慢(即使建立了索引)	较快

从目前的市场趋势来看，云数据库的采用率正在上升。作为这一趋势的一部分，数据库供应商的关键机会领域之一是将本地数据库迁移到云数据库。此外，除了传统的关系型数据库系统之外，还出现了KV存储、文档存储以及时间序列和图形数据库等专用数据库管理系统。这些专用数据库系统针对特定问题域都提供了方案，并且具有特定的用例。这些专用数据库管理系统解决了数据量大、数据源(IOT、网络日志等)增多的问题，这些数据源在本质上不一定是事务性的，因此称为大数据源。

关系型数据库供应商为适应这种情况，引入了处理这类数据的能力并且适应这些数据的存储需求，以实现高效的数据检索。具有这些能力的数据库系统现在称为多模态数据库系统。多模型数据库的设计目的是针对单一集成后端支持多个数据模型。文档模型、图形模型、关系型模型和键值模型是多模型数据库可能支持的数据模型的示例。此外，多模型数据库使用高度成熟的SQL帮助查询不同类型的数据模型。云供应商已经为这类专用和多模态数据库系统提供了支持，作为他们方案的一部分(例如，DBaaS)。业务原因是，云数据库系统越来越多地采用云，满足了客户的各种特定需求，特别是他们的数据库迁移和应用迁移需求。

数据库迁移并非易事，需要仔细规划。典型的数据库迁移流程包括：

模式迁移(Schema Migration)

数据迁移

应用迁移

图1是从源数据库迁移到目标数据库的过程的示意图。图1还包括以下过程步骤：

1.源模式和数据评估

数据映射、字段填充不足、要删除的对象/字段、不准确性等。

2.迁移设计和定义

一次性或分阶段

3.迁移方案

开发方案

4.测试

使用真实数据测试迁移设计

5.生产

6.审计

确保迁移的准确性

在现有技术中，参见图1，通过以下方法执行模式和数据库迁移：

1.源数据库结构到选定的目标数据库结构的模式转换

转换机制基于regex或基于语法

在基于解析器的方法中，将源结构提取到数据模型中，然后使用该数据模型形成目标数据库句法。

2.如果需要，还转换一个或多个应用查询以与选定的目标数据库系统兼容，这是应用迁移的一部分。

3.首先执行模式转换/迁移，然后执行应用迁移或工作负载查询转换。

在现有模式迁移方案中发现的技术问题至少包括以下几个方面：

1.在考虑迁移到云数据库系统时，没有专门可用的推荐方法，因为云数据库系统与源系统不同，具有不同的处理引擎和存储引擎或存储格式(行存储格式与列存储格式)、多模型数据库。

2.出于性能考虑，现有方案都没有推荐行存储/列存储或存储与专用数据库系统(例如，多模型)兼容的数据。

3.当前的源系统经过多年发展，当前性能可能不适合目标数据库或要在目标上运行的应用查询。

4.转换大多是一比一进行，没有考虑查询优化和存储优化。

因此，当从源迁移到不同的目标系统时，需要在各个层面提供推荐，特别是在数据的存储层面。

发明内容

本发明内容是为了介绍在从源服务器系统迁移到目标服务器系统时为关系型数据库管理系统(relational database management system，RDBMS)推荐存储格式的相关概念。

本发明的主要目的是为将关系型数据库管理系统(relational databasemanagement system，RDBMS)从源服务器系统迁移到目标服务器系统提供存储格式的推荐。为了实现这个主要目的，分析使用源服务器系统中的RDBMS的应用的工作负载查询。此外，还可以分析源对象的数据定义语言(Data Definitional Language，DDL)。通过对工作负载查询或至少一组工作负载查询以及DDLS进行分析，当RDBMS中的表要从源服务器系统迁移到目标服务器系统时，提供存储格式的推荐，即基于列的存储、列存储或基于行的存储。除了RDBMS中的表的存储格式之外，还可以提供数据库的存储模型的额外推荐，例如，多模型RDBMS，或者目标RDBMS中的纯时间序列模型、键值(KV模型)或者图形模型。本发明公开的方案的许多技术优点之一是，当迁移到目标服务器系统时，可以根据目标服务器系统的能力来提高选择查询的性能。例如，通过在目标中推荐列存储格式，而源中的RDBMS表只支持行存储格式，可以提高性能并且可以优化资源使用。此外，在一些情况下，当工作负载查询和DDL中使用的列只包括几个不同值时，通过推荐列存储可以实现高压缩率。

在第一种实现方式中，本发明提供了一种为将关系型数据库管理系统(relational database management system，RDBMS)从源服务器系统迁移到目标服务器系统推荐存储格式的方法。所述方法包括：从所述源服务器系统的源数据库中提取SQL查询。此外，所述方法还包括：解析所述SQL查询以识别出与基于列的操作对应的一组查询；确定在所述识别出的一组查询中使用的列数(Cn)；对于所述多列(Cn)中的每一列(C)，确定列记录中的至少部分列记录的值是否相同。在确定时，所述方法还包括：为所述目标服务器系统中的所述RDBMS推荐列存储格式。

在第二种实现方式中，公开了一种用于为将关系型数据库管理系统(relationaldatabase management system，RDBMS)从源服务器系统迁移到目标服务器系统推荐存储格式的系统。所述系统包括源服务器系统、目标服务器系统和推荐平台。所述源服务器系统至少包括所述源服务器系统中的RDBMS的源数据库，所述目标服务器系统包括与所述目标服务器系统中的RDBMS的一个或多个存储格式对应的数据存储，所述推荐平台包括用于与所述源服务器系统的所述源数据库连接的第一接口和用于与所述目标服务器系统连接的第二接口。此外，所述推荐平台还包括SQL解析器和推荐引擎。所述SQL解析器用于经由所述第一接口从所述源服务器系统的所述源数据库中提取SQL查询，解析所述SQL查询以识别出与基于列的操作对应的一组查询。所述推荐引擎用于：确定在所述识别出的一组查询中使用的列数(Cn)；对于所述多列(Cn)中的每一列(C)，确定列记录中的至少部分列记录的值是否相同；在确定时，为所述目标服务器系统中的所述RDBMS推荐列存储格式。

附图说明

参考附图描述具体实施方式。在附图中，附图标记中的一个或多个最左边的数字表示附图标记首次出现的附图。所有附图使用相同的数字来表示相似特征和组件。

图1示出了RDBMS从源服务器系统迁移到目标服务器系统的典型数据库迁移过程。

图2是本发明提供的模式迁移流程的示意性图示。

图3示出了本发明提供的一种推荐存储格式的方法。

图4是本发明提供的推荐引擎采用的推荐流程的示意性图示。

图5示出了本发明提供的一种用于推荐存储格式的系统。

应当理解，附图只是为了说明本发明的概念，不应理解为对本发明的限制。

具体实施方式

下面结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚的描述。显然，所描述的实施例仅仅是本发明的一部分实施例，而不是全部实施例。

本发明可以使用多种方式实现为过程、装置、系统、物质组成、计算机可读介质(例如，计算机可读存储介质或计算机网络)，其中，程序指令通过光学或电子通信链路发送。在本说明书中，这些实现方式或本发明可能采取的任何其他形式可以称为技术。一般而言，公开过程的步骤的顺序可以在本发明的范围内进行更改。

下面对本发明一个或多个实施例以及说明本发明原理的附图进行详细描述。本发明结合这些实施例进行描述，但本发明不限于任何实施例。本发明的范围只受限于权利要求书，本发明包括许多替代方案、修改和等效方案。为了提供对本发明的透彻理解，下面的描述中阐述了许多具体细节。提供这些细节是为了举例说明，本发明可以根据权利要求书来实施，而不需要这些具体细节中的一部分或全部。为清楚起见，没有详细描述与本发明有关的技术领域中已知的技术资料，以免对本发明产生不必要的混淆。

在下面的具体实施方式中，为了提供对本发明的透彻理解，阐述了许多具体细节。然而，本领域技术人员将理解，可以在没有这些具体细节的情况下实践本发明。在其他情况下，没有详细描述公知的方法、过程、组件、模块、单元和/或电路，以免混淆本发明。

尽管本发明实施例不限于此，但使用“处理”、“计算”、“确定”、“建立”、“分析”、“检查”、“提取”、“解析”、“推荐”等术语进行的论述可以指计算机、计算平台、计算系统或其他电子计算设备的一个或多个操作和/或一个或多个过程，这些设备操作计算机寄存器和/或存储器内的表示为物理量(例如，电子量)的数据和/或转换为计算机寄存器和/或存储器或可以存储用于执行操作和/或过程的指令的其他信息非瞬时性存储介质内的类似地表示为物理量的其他数据。

尽管本发明的实施例在这方面不受限制，但本文中使用的术语“多个”可以包括“两个或两个以上”等。术语“多个”可以在整个说明书中用于描述两个或两个以上组件、设备、元件、单元、参数等。除非明确说明，本文中描述的方法实施例不限于特定次序或顺序。此外，所描述的方法实施例或其元素中的一些可以在同一时间点同时发生或执行。

本发明提出了推荐存储格式，另外还通过分析工作负载查询和数据定义语言(Data Definition Language，DDL)为源对象推荐目标数据库中的存储模型。这一想法是典型迁移方案中的从源服务器系统中的本地RDBMS迁移到目标服务器系统中的RDBMS的模式迁移步骤的核心。在一个实施例中，目标服务器系统是基于云的目标。在另一个实施例中，云中的RDBMS可以是多模型RDBMS。然而，在一些实施例中，目标服务器系统可以包括纯粹是KV存储的数据库模型、时间序列模型或图形模型。根据本发明的一种实现方式，目标服务器系统中的RDBMS既支持基于列的存储又支持基于行的存储。在一种这样的实现方式中，目标服务器系统中的RDBMS支持混合存储格式。混合数据库表的存储方式既可以是行存储又可以是列存储。在另一种这样的实现方式中，目标服务器系统中的RDBMS单独支持行存储格式和列存储格式。也就是说，目标服务器系统中的一个RDBMS表可以只支持行存储格式，而目标服务器系统中的另一个RDBMS表可以只支持列存储格式。

多年来在典型的RDMBS中使用的数据存储格式基本上是基于行的。多年来，各种组织可能已经使用RDBMS列存储选项(基本上是基于行的存储格式)向数据库逻辑模式添加了多个应用/查询和更改。同样，如果当前模型/DBMS是一个纯KV存储模型/时间序列模型，则可以对其进行分析，以提出在目标数据库中使用行存储、列存储模型。

现有技术方案没有考虑到推荐存储、分区和多模型选项的可能性，而大多数当前已知的RDBMS供应商在云中都支持这些选项。在考虑将源目标系统中的RDBMS表迁移到目标服务器系统时，本发明通过推荐行存储格式或列存储格式改进现有技术。根据目标服务器系统的能力，提出的技术方案的扩展方案还推荐专用数据模型存储(KV、时间序列、图形等)。

例如，图2是本发明中的模式迁移流程的示意性图示。推荐平台可以是第三方供应商或内部方案，推荐平台可以访问源数据库的存储或源数据库反对意见集合，对目标数据库执行分析、推荐后处理和批准，选择目标数据库，在需要时根据目标数据库的兼容性转换DDL，并且执行从源数据库到目标数据库的模式迁移。如图2所示，201所示的源SQL解析器用于从源服务器系统的源数据库的源数据库反对意见集合202中提取并解析结构化查询语言(Structured Query Language，SQL)/工作负载查询和DDL。提取并解析出的数据通常由源SQL解析器201存储在推荐平台的存储库数据库(Repo DB)203中，推荐引擎(图2中未示出)根据后面论述的各种因素分析这些数据。在204中，推荐引擎跨越目标服务器系统中(例如，云中)的所有支持的RDBMS(称为“RDS”)对SQL/DDL执行所有迁移前分析。在205中，推荐引擎选择目标DB。作为典型迁移过程的一部分，可以在206中转换在源中使用的查询/DDL，以便与目标服务器系统中的新数据库结构兼容。在207中，验证转换，将转换应用于目标数据库，最终将转换迁移到目标数据库208。

下面参考图3，本发明一个实施例公开了一种为将关系型数据库管理系统(relational database management system，RDBMS)从源服务器系统迁移到目标服务器系统推荐存储格式的方法。在本发明的一种实现方式中，上述方法由推荐平台执行，该推荐平台可以访问源服务器系统中的源数据库对象集合。源系统托管源中的RDBMS表，这些表将要迁移到目标服务器系统。在一种这样的实现方式中，推荐平台可以托管在远离源服务器系统且与源服务器系统进行通信的第三方服务器中。在另一种这样的实现方式中，推荐平台可以托管在源服务器系统中。如上所述的存储格式包括行存储格式和列存储格式中的至少一种。例如，为迁移到目标服务器系统的RDBMS表推荐的存储格式可以只是列存储格式。又如，为迁移到目标服务器系统的RDBMS表推荐的存储格式可以只是行存储格式。再如，为迁移的RDBMS表推荐的存储格式可以包括该RDBMS表内的多列中的至少部分列使用的列存储，还可以包括同一RDBMS表的其他列使用的行存储。这些决策取决于从上面的论述以及本申请中论述的一些场景/用例中可以了解的因素。

例如，在包括但不限于以下情况的场景中推荐基于列的存储。

情况A：计算通常在单列或少量列上执行。

情况B：表根据几列的值进行搜索。

情况C：表中有大量列。

情况D：表中有大量行，需要进行列式操作(例如，聚合、扫描等)

情况E：由于大多数列只包括几个不同值(与行数相比)，因此可以实现高压缩率。

例如，在包括但不限于以下情况的场景中推荐基于行的存储：

情况F：应用一次只需要处理一条记录(多次选择和/或更新单一记录)。

情况G：应用通常需要访问完整记录。

情况H：列主要包括不同值，因此压缩率低。

情况I：既不需要聚合，也不需要快速搜索。

情况J：表中有少量行(例如，配置表)。

上述示例不应理解为限制，因为根据具体情况以及从应用的使用角度来看，还可能出现其他场景。本发明的推荐方法可以考虑上述一种或多种情况来推荐存储格式。

此外，根据本发明实施例，在推荐存储格式之前，可以考虑与上述列出的情况相关的额外因素。例如，本发明一些实现方式提供的额外因素可以包括但不限于：

1.表中有大量列(C)和/或通常在涉及以下因素的查询中使用，或者表中有大量列，只在涉及以下因素的查询中使用。

2.与大量列式操作(例如，聚合、扫描等)对应的查询(Q)数量

3.不同值较少的列(C)

在本发明的一个示例性实施例中，为推荐存储格式而考虑的列数与为推荐而分析的查询(例如，SQL、DDL)数量有关。例如，如果在50个查询中，发现只有20个查询使用表的列进行列式操作，则这些查询的优化水平没有达到预期，即使这20个查询中的列数较多，也可能不推荐基于列的存储。然而，如果在500个查询中，有200多个查询进行列式操作，则查看在这200多个查询中使用的列数和/或这些列中的唯一值之后，可以考虑基于列的存储。这是因为在后一种情况下，相对较多的查询在优化，因此可以实现存储优化。

根据本发明的又一个实施例，上述推荐存储格式的方法可以包括：为源RDBMS的表内的列中的至少部分列推荐基于列的存储。在这种情况下，列中的部分列可以是在进行列式操作的查询中使用的那些列。这样的列数可以较大，和/或这些列中的每一列可以包括较少的唯一值。另外，上述推荐存储格式的方法还可以包括：除列中已经推荐基于列的存储的部分列之外，为其他列推荐基于行的存储。在一种具体的实现方式中，为未在与列式操作对应的识别出的一组查询中使用的其他列的其他列记录推荐行存储格式。因此，对于源服务器系统中的同一个RDBMS表，可以为一些列推荐基于列的存储，而仍然为其他列推荐基于行的存储。在一种这样的实现方式中，目标RDBMS可以是支持混合存储格式(也就是既支持列存储格式又支持行存储格式)的混合数据库。根据可以在目标服务器系统中既支持基于列的存储又支持基于行的存储的推荐，当从源服务器系统迁移时，源RDBMS表可以在目标服务器系统中重新创建。然而，如果目标RDBMS单独支持行存储格式且单独支持列存储格式，也就是说，目标RDBMS不是混合数据库，但还同时支持两种存储格式，则根据可以在目标服务器系统中既支持基于列的存储又支持基于行的存储的推荐，在迁移时，源RDBMS表可以在目标服务器系统中拆分为两个表。

返回参考图3，上述推荐存储格式的方法包括：在步骤302中，从源服务器系统的源数据库中提取SQL查询。简而言之，结构化查询语言(Structured Query Language，SQL)是一种用于数据库管理的语言。MySQL、MS Access、Oracle、Sybase、Postgres和SQL服务器等所有RDBMS系统都使用SQL作为他们的标准数据库语言。SQL编程语言使用各种命令进行不同的操作。形成SQL查询的这些命令中的一些命令使用(1)数据定义语言(Data DefinitionLanguage，DDL)，例如，CREATE、ALTER、DROP；(2)数据操作语言(Data ManipulationLanguage，DML)，例如，INSERT、UPDATE、DELETE；(3)数据查询语言(Data Query Language，DQL)，例如，SELECT。SELECT命令有助于根据WHERE子句描述的条件选择属性。例如，SELECT命令的SYNTAX如下所示：

SELECT expressions

FROM TABLES

WHERE conditions；

示例：

SELECT First Name

FROM Student

WHERE Roll No>15；

SELECT查询通常可以与SQL聚合函数一起使用。经常将聚合函数与SELECT语句的GROUP BY和HAVING子句一起使用。以下是最常用的SQL聚合函数：

·AVG：计算一组值的平均值。

·COUNT：计算指定表或视图中的行数。

·MIN：计算一组值中的最小值。

·MAX：计算一组值中的最大值。

·SUM：计算值的总和。

第一步，从托管源RDBMS的源服务器系统的源数据库的历史SQL日志、表统计信息中提取包括SQL查询的工作负载查询，一些示例如上所述。这可以理解为在图2所示的步骤202中从源数据库对象集合中提取DDL/SQL。

返回参考图3，上述方法包括：在步骤304中，解析SQL查询以识别与列式操作对应的一组查询。这里的列式操作可以指SELECT工作负载查询，这些工作负载查询还可以包括聚合函数。基本上，在本发明的上下文中，提供若干聚合函数以根据列进行AVG、MAX/MIN、SUM和COUNT等计算的那些SQL查询称为列式操作。例如，列式操作可以包括如下SYNTAX：

SELECT MAX(price)as"__"

FROM"column x"；

SELECT AVG(year)

FROM"column y"；

SELECT SUM(price)AS""

FROM"column x"；

从在步骤302中提取出的数百个SQL查询中，解析每个查询的内容。参考图2所示的示例，可以理解为以下步骤：提取并解析出的数据通常由源SQL解析器201存储在推荐平台的存储库数据库(Repo DB)203中。每个查询的内容都会被解析成一个元数据模型(内存或持久存储)，该模型会为每个查询确定投影列表、谓词、使用的聚合函数、连接(join)、WHERE子句和使用的列，等等。创建和存储元数据模型所在的内存或持久存储属于实现方法300的推荐平台。总之，在这一步骤中，上述方法将工作负载查询作为输入，并且确定查询中的不同子句是否具有在聚合运算、范围表达式、平均值运算等中使用的表列。

在步骤306中，图3所示的方法还包括：确定列数，在本文中也表示为“Cn”。分析在步骤302和步骤304中提取并解析出的信息，以确定在列式操作中使用的列数。在相对较多的SQL查询中，列数多会成为推荐平台在源RDBMS向目标RDBMS迁移时为这些列推荐列存储的因素之一。在延续步骤308中，对于多列(Cn)中的每一列(C)，上述方法还包括：确定列记录(也称为“#记录”)中的至少部分列记录的值是否相同。除了列数之外，上述推荐方法还考虑了表中的列记录数(#记录)和每一列(C)的唯一值数(#唯一值)。关于表统计信息，还可以考虑更多的使用统计信息，例如，定义的索引。然而，这些统计信息并不限制本方法的范围。步骤306和步骤308限定了本发明的核心思想，即，分析并确定与进行列式操作的SQL查询量相关的列数以及#记录和#唯一值等其他因素，从而在RDBMS表要迁移到目标RDBMS时推荐一种存储格式

在步骤310中，图3所示的方法包括：为目标服务器系统中的RDBMS推荐列存储格式。该推荐基于延续步骤306的确定步骤308。通过因素Cn和#记录、#唯一值，在考虑上面通过示例论述的情况A至情况E等场景时可以推荐基于列的存储。

根据又一个实施例，当列(C)的列记录中具有唯一值的部分列记录包括列(C)的列记录中的至少70％至80％的列记录时，如图3所示，推荐列存储格式。

根据又一个实施例，当在识别出的一组查询中使用的列数(Cn)在实际列数的30％至70％之间时，如图3所示，推荐列存储格式。

根据又一个实施例，当与列式操作对应的一组查询(即工作负载查询/SQL查询)包括从源服务器系统的源数据库中提取出的SQL查询中的至少50％至70％的查询时，如图3所示，推荐列存储格式。

根据一个实施例，仅对于在识别出的一组查询中使用的多列(Cn)中的列(C)，为目标服务器系统中的RDBMS推荐列存储格式。尽管如此，在一种实现方式中，虽然为其他列中的一些列Cn推荐列存储格式，但是仍然可以为其他列记录推荐基于行的存储格式。如上所述，目标RDBMS可以通过两种方式实现这一功能。在目标中，如果支持行格式和列格式的混合格式，则可以在目标RDBMS中重新创建相同的表，即源RDBMS表。否则，可能需要在目标中将表(即源RDBMS表)拆分为两个或两个以上表，以既支持行格式又支持列格式。可以理解，目标源系统中的RDBMS仍然必须既支持行格式又支持列格式。这个想法还可以扩展到根据工作负载查询中的使用情况在目标中推荐列分区，以及推荐专用于目标数据库的存储和处理查询的时间序列模型。

在一个替代实施例中，上述方法可以包括：如果基于列的存储使用的因素可能无法实现，为目标服务器系统中的RDBMS推荐行存储格式。例如，如果在图3的步骤308中，对于多列(Cn)中的每一列(C)，上述方法包括：确定列记录中的至少部分列记录的值是否不同，则在步骤310中，上述方法可以包括：为目标服务器系统中的RDBMS推荐行存储格式。这里，列(C)的列记录中的部分列记录(具有不同值)包括列(C)的列记录中的至少50％至70％的列记录。例如，如果在图3的步骤308中，对于多列(Cn)中的每一列C或任何列C，如果列记录中的包括唯一值的部分列记录少于列(C)的列记录中的70％至80％的列记录，则行存储格式可能更适合于表中的那些列。因此，上述方法可以包括：如果列(C)的列记录中的部分列记录(具有唯一值)少于列(C)的列记录中的70％至80％的列记录，则为目标服务器系统中的RDBMS推荐行存储格式。又如，上述方法可以包括：如果在识别出的一组SQL查询(例如，在图3的步骤306中)中使用的列数(Cn)小于表中的实际列数的30％至70％，则为目标服务器系统中的RDBMS推荐行存储格式。总之，如果相对于提取并解析出的SQL查询数，在列式操作中使用的列数较少，和/或如果大多数列记录的值不同，或者换句话说，列的列记录的唯一值的数量很少，则基于行的存储格式实际上可能更适合于目标中的那些列记录。通过因素Cn和#记录、#唯一值，在考虑上面通过示例论述的情况F至情况J等场景时可以推荐基于行的存储。

根据本发明的其他实施例，为将源RDBMS的表迁移到目标RDBMS进行推荐的方法可以扩展到推荐目标服务器系统中的存储模型。在分析源RDBMS的SQL查询时，可能会发现相对较多的工作负载查询适合于时间序列模型、KV模型或多模型格式。在一种这样的可能性中，工作负载查询的条件可能是基于时间范围的分区推荐或云中的多模型目标数据库中的时间序列数据模式。因此，为从源RDBMS迁移到目标RDBMS推荐存储格式的方法还可以包括：为目标服务器系统中的RDBMS推荐多模态存储。多模态存储可以是时间序列模型或KV模型中的至少一种。

根据本发明实施例，公开了一种为将关系型数据库管理系统(relationaldatabase management system，RDBMS)从源服务器系统迁移到目标服务器系统推荐存储格式的系统。该系统大致上至少包括托管待迁移的RDBMS表的源服务器系统、RDBMS表从源服务器系统迁移到的目标服务器系统以及与源服务器系统和目标服务器系统进行通信的推荐平台。虽然图2是从源服务器系统迁移到目标服务器系统的迁移流程的示意图，迁移流程包括分析从源数据库反对意见集合中解析出的SQL查询，但图4是本发明中的推荐引擎采用的推荐流程的示意图，该推荐引擎是推荐平台的一部分，是本发明公开的存储推荐方案的核心部分。在图4中，源数据库402可以视为图2所示的源服务器系统的源数据库对象集合。源数据库402包括SQL查询/DDL/工作负载查询。此外，如图4所示，SQL解析器401也可理解为图2所示的SQL解析器201，从源服务器系统的源数据库的源数据库反对意见集合402中提取并解析结构化查询语言(Structured Query Language，SQL)/工作负载查询和DDL。提取并解析出的数据通常由源SQL解析器201存储在推荐平台的存储库数据库(例如，Repo DB203)中，推荐引擎400分析这些数据。SQL解析器401和推荐引擎400是推荐平台的一部分，该推荐平台通过相应的通信接口与源服务器系统和目标服务器系统进行通信。推荐平台可以是第三方供应商或内部方案，推荐平台访问源数据库的存储或源数据库反对意见集合，执行分析和迁移后处理，根据分析提供目标数据库的推荐和/或批准。图2和图4是迁移流程的示意图。根据本发明的指导，推荐引擎400分析由SQL解析器401提取出的信息以确定列数(#列)、在列式操作中使用的查询数(#查询)、具有较少不同值的列数(#列)等，推荐引擎400根据这些为目标中的表的记录推荐基于列的存储。可替代地，推荐引擎400可以选择基于行的存储格式、分区推荐，即拆分表以单独支持基于行的存储格式或基于列的存储格式。另外，推荐引擎400还可以为目标中的迁移表推荐存储模型，该存储模型可以包括多模型存储(时间序列、KV模型)或纯时间序列模型或纯KV模型，等等。

下面参考图5，图5是本发明一个实施例提供的描述一种用于为将关系型数据库管理系统(relational database management system，RDBMS)从源服务器系统迁移到目标服务器系统推荐存储格式的系统的示意图。在图5中，系统500包括源服务器系统502，源服务器系统502至少包括源服务器系统中的RDBMS的源数据库502-1。在本发明中，源服务器系统中的RDBMS也称为源RDBMS。源数据库或源数据库对象集合(参见图2和图4)包括SQL查询/DDL/工作负载查询。此外，系统500包括目标服务器系统506，目标服务器系统506可以包括与目标服务器系统506中的RDBMS的一个或多个存储格式对应的数据存储506-1。在本发明中，目标服务器系统中的RDBMS也称为目标RDBMS。目标服务器系统可能是从作为源RDBMS的迁移方案提供商的推荐平台已知的几个目标中推荐的目标。目标的几个示例之一可以包括云服务。每个目标可能具有适合于由目标运行和支持的应用的特定配置。在本发明的具体实现方式中，目标支持RDBMS表的列存储格式。在这个上下文中，目标服务器系统的数据存储506-1是混合数据存储，或者至少既支持列存储又支持行存储，其中，源RDBMS表必须根据目标中的存储格式进行拆分。在其他实现方式中，数据存储还支持多模型存储格式、KV模型、时间序列模型等。此外，系统500包括推荐平台504，推荐平台504用于与源数据库系统502进行连接并且与目标服务器系统506进行连接，并且根据本发明实施例具体用于在迁移时为目标服务器系统中的源RDBMS表提供存储格式的推荐。在其他实现方式中，推荐平台还可以用于在迁移时推荐目标服务器系统中的源RDBMS表的存储模型。如本发明所述，存储模型包括但不限于多模型数据库或纯KV存储或纯时间序列存储，等等。

为了实现本发明的推荐方案，参考图5，推荐平台504包括用于与源服务器系统502的源数据库504-1进行连接的第一接口504-1和用于与目标服务器系统506进行连接的第二接口504-2。第一接口504-1和第二接口504-2可以理解为通信接口和/或数据库连接接口和/或编程接口和/或数据访问接口，这样使得推荐平台可以访问源数据库502-1中的SQL/工作负载查询以及访问数据存储506-1的信息和在目标服务器系统506中支持的配置/应用。此外，推荐平台504包括SQL解析器504-3和推荐引擎504-4。应当理解，推荐平台使用SQL解析器504-3和推荐引擎504-4执行上文公开的如图3所示的方法。虽然SQL解析器504-3包括图4所示的SQL解析器401和图2所示的源SQL解析器201，但推荐引擎504-4包括图4所示的推荐引擎400。推荐引擎400还用于图2所示的迁移流程步骤204至步骤207中。

根据一个具体的实施例，SQL解析器504-3用于经由第一接口504-1从源服务器系统502的源数据库502-1中提取SQL查询，并且还用于解析SQL查询/工作负载查询以识别与列式操作对应的一组查询。推荐平台还可以包括存储库数据库，参见图2，其中存储了所有提取出的查询以进行分析。此外，推荐引擎用于确定在与列式操作对应的识别出的一组查询中使用的列数(Cn)；对于多列(Cn)中的每一列(C)，推荐引擎504-4用于确定列记录中的至少部分列记录的值是否相同，在确定时为目标服务器系统中的RDBMS推荐列存储格式。

根据本发明实施例，推荐引擎504-4用于在可以包括但不限于本申请中描述的情况A至情况E的场景中推荐基于列的存储。

根据本发明实施例，推荐引擎504-4用于在可以包括但不限于本申请中描述的情况F至情况J的场景中推荐基于行的存储。

根据又一个实施例，当列(C)的列记录中的部分列记录(具有唯一值)包括列(C)的列记录中的至少70％至80％的列记录时，推荐引擎504-4推荐列存储格式。根据又一个实施例，当在识别出的一组查询中使用的列数(Cn)在实际列数的30％至70％之间时，推荐引擎504-4推荐列存储格式。根据又一个实施例，当与列式操作对应的一组查询(即工作负载查询/SQL查询)包括从源服务器系统的源数据库中提取出的SQL查询中的至少50％至70％的查询时，推荐引擎504-4推荐列存储格式。根据一个实施例，仅对于在识别出的一组查询中使用的多列(Cn)中的列(C)，推荐引擎504-4为目标服务器系统中的RDBMS推荐列存储格式。尽管如此，在一种实现方式中，虽然为其他列中的一些列Cn推荐列存储格式，但是仍然可以在目标RDBMS中推荐并使用基于行的存储格式。

在替代实施例中，如果基于列的存储使用的因素可能无法实现，则推荐引擎504-4为目标服务器系统中的RDBMS推荐行存储格式。例如，如果在图3的步骤308中，对于多列(Cn)中的每一列(C)，上述方法包括：确定列记录中的至少部分列记录的值是否不同，则在步骤310中，上述方法可以包括：为目标服务器系统中的RDBMS推荐行存储格式。这里，列(C)的列记录中的部分列记录(具有不同值)包括列(C)的列记录中的至少50％至70％的列记录。又如，推荐引擎用于：对于在列式操作中使用的多列(Cn)中的每一列(C)，确定列记录中的部分列记录的值是否不同。相应地，推荐引擎用于为目标服务器系统中的RDBMS推荐行存储格式。可替代地，对于在列式操作中使用的多列(Cn)中的每一列C或任何列C，如果列记录中的包括唯一值的部分列记录少于列(C)的列记录中的70％至80％的列记录，则行存储格式可能更适合于表中的那些列。因此，如果列(C)的列记录中的部分列记录(具有唯一值)少于列(C)的列记录中的70％至80％的列记录，则推荐引擎504-4可以为目标服务器系统中的RDBMS推荐行存储格式。再如，如果在识别出的一组SQL查询中使用的列数(Cn)小于表中的实际列数的30％至70％，则推荐引擎504-4可以为目标服务器系统中的RDBMS推荐行存储格式。

根据所公开的实施例，目标服务器系统506的数据存储506-1支持RDBMS使用混合存储格式，相应地，在为要迁移到目标的源RDBMS表推荐列存储时，推荐引擎504-4还用于推荐在目标服务器系统中重新创建表。可替代地，如果数据存储506-1不支持混合存储格式，则推荐引擎504-4还用于在目标服务器系统中对表进行拆分。

根据其他实施例，扩展本发明的指导，以使得推荐引擎504-4能够为目标服务器系统中的RDBMS推荐多模态存储。多模态存储可以包括时间序列模型或KV模型。

在本发明中，源服务器系统和目标服务器系统可以理解为具有RDBMS客户端-服务器系统的架构。源服务器系统可以是服务器，客户端可以是访问源服务器的应用。类似的类比也可以应用于目标服务器系统。在RDBMS表要从源迁移的上下文中，源服务器系统也可以称为源服务器或源中的服务器设备。类似地，在RDBMS表要迁移到目标的上下文中，目标服务器系统也可以称为目标服务器或目标中的服务器设备。推荐平台也可以理解为计算设备，或者客户端-服务器架构的服务器，分别实现为源服务器系统的客户端和目标服务器系统的服务器，视情况而定。本领域技术人员将认识到，本文中使用的术语“服务器”、“计算设备”是为了清晰地论述架构，但绝不意味着将本发明的应用局限于特定的计算机/服务器。本发明中描述的至少一些特征/方法在计算设备中实现为包括通信接口、SQL解析器和推荐引擎的推荐平台。本发明中的推荐引擎、SQL解析器和接口中的组件使用硬件、固件和/或安装在硬件上运行的软件来实现。计算设备可以包括收发器，收发器是发送器、接收器或其组合。处理器可以包括在计算设备中，以处理从另一个服务器源中提取并解析出的信息工作负载查询。处理器可以包括一个或多个多核处理器和/或内存模块。处理器被实现为通用处理器，或者是一个或多个专用集成电路(application specific integrated circuit，ASIC)和/或数字信号处理器(digital signal processor，DSP)的一部分。应当理解，通过将可执行指令编程和/或加载到计算节点中，更改处理器和长期存储中的至少一个，从而部分地将计算节点变换为特定机器或装置，例如，提供用于将源RDBMS迁移到目标RDBMA的存储格式推荐方案，如本发明指导的那样。电气工程和软件工程艺术的基本原理是，通过将可执行软件加载到计算机中来实现的功能可以通过众所周知的设计规则转换为硬件实现。决定在软件还是硬件中实现一个概念通常取决于对设计的稳定性和要生产的单元数量的考虑，而不是从软件域转换到硬件域所涉及的任何问题。一般而言，仍然会频繁更改的设计最好在软件中实现，因为重新设计硬件实现比重新设计软件更昂贵。一般而言，稳定的大批量生产的设计最好在硬件中实现，例如，在ASIC中实现，因为对于大批量生产来说，硬件实现的成本要低于软件实现的成本。通常情况下，一个设计是以软件形式开发和测试的，然后再根据众所周知的设计规则，转换为ASIC中的将软件指令硬连接起来的等效硬件实现。与由新的ASIC控制的机器是特定机器或装置的方式相同，同样，已经编程和/或加载有可执行指令的计算机视为特定机器或装置。

参照本发明中的图3、图4和图5所述，本发明至少提供了以下有益的技术效果，即可以更好地优化工作负载查询。另外，实施本发明还可以获得以下技术效果：

1.数据库管理员(database administrator，DBA)/云管理员可以更好地了解云中的现有源系统和选定的目标系统之间的差异。

2.有助于节省云中的存储成本。

3.有助于优化查询，以利用目标数据库中可用的不同类型的存储格式。

本领域技术人员可以清楚地理解，为了便于和简化描述，上述系统、装置和单元的具体工作过程可以参考上述方法实施例中的对应过程，本文不再赘述。

虽然本发明提供了若干个实施例，但应当理解，所公开的系统和方法也可通过其他多种具体形式体现，而不会脱离本发明的范围。当前的这些示例被认为是说明性的而非限制性的，并且意图不限于本文给出的细节。例如，各种元件或组件可以组合或集成在另一个系统中，或者可以省略或不实现一些特征。

另外，在不脱离本发明的范围的情况下，各种实施例中描述和说明为离散或单独的技术、系统、子系统和方法可以与其他系统、模块、技术或方法组合或集成。示出或描述为彼此耦合、直接耦合或彼此通信的其他项可以通过某种接口、设备或中间组件以电方式、机械方式或其他方式间接耦合或通信。变化、替换、变更的其他示例可由本领域技术人员确定，并可以在不脱离本文中公开的范围的情况下举例。

因此，保护范围不受上述描述的限制，而是由随后的权利要求书界定，该范围包括权利要求书的主题的所有等效物。每项权利要求都作为进一步的公开内容纳入说明书，并且权利要求书是本发明的一个或多个实施例。本发明中对参考文献的论述并不表示其是现有技术，尤其是公开日期在本申请的优先权日期之后的任何参考文献。

最后，说明书中使用的语言主要是出于可读性和指导性目的而选择的，不一定似乎为了界定或限定创造性主题而选择的。因此，本发明的范围不应受限于具体实施方式，而是受限于基于本申请而发出的任何权利要求。因此，本发明实施例的公开内容旨在说明而非限制本发明的范围，该范围在所附权利要求书中阐述。

Claims

1.一种为将关系型数据库管理系统(relational database management system，RDBMS)从源服务器系统迁移到目标服务器系统推荐存储格式的方法，其特征在于，所述方法包括：

从所述源服务器系统的源数据库中提取SQL查询；

解析所述SQL查询以识别出与列式操作对应的一组查询；

确定在所述识别出的一组查询中使用的列数(Cn)；

对于所述多列(Cn)中的每一列(C)，确定列记录中的至少部分列记录的值是否相同；

在确定时，为所述目标服务器系统中的所述RDBMS推荐列存储格式。

2.根据权利要求1所述的方法，其特征在于，所述列(C)的所述列记录中的所述部分列记录包括所述列(C)的所述列记录中的至少70％至80％的列记录。

3.根据权利要求1所述的方法，其特征在于，在所述识别出的一组查询中使用的所述列数(Cn)在实际列数的30％至70％之间。

4.根据权利要求1所述的方法，其特征在于，与所述列式操作对应的所述一组查询包括从所述源数据库中提取的所述SQL查询中的至少50％至70％的查询。

5.根据权利要求1所述的方法，其特征在于，所述方法包括：

对于所述多列(Cn)中的每一列(C)，确定所述列记录中的所述部分列记录的值是否不同；

为所述目标服务器系统中的所述RDBMS推荐行存储格式。

6.根据权利要求1所述的方法，其特征在于，所述方法包括：如果所述列(C)的所述列记录中的所述部分列记录少于所述列(C)的所述列记录中的70％至80％的列记录，为所述目标服务器系统中的所述RDBMS推荐行存储格式。

7.根据权利要求1所述的方法，其特征在于，所述方法包括：如果在所述识别出的一组查询中使用的所述列数(Cn)小于实际列数的30％至70％，为所述目标服务器系统中的所述RDBMS推荐行存储格式。

8.根据权利要求1所述的方法，其特征在于，所述列存储格式被推荐给与所述列式操作对应的所述确定的多列(Cn)中的列的列记录。

9.根据权利要求8所述的方法，其特征在于，所述行存储格式推荐被推荐给未在与所述列式操作对应的所述识别出的一组查询中使用的其他列的其他列记录。

10.根据权利要求8或9所述的方法，其特征在于，所述目标服务器系统支持所述RDBMS使用混合存储格式。

11.根据权利要求10所述的方法，其特征在于，所述方法包括：推荐在所述目标服务器系统中重新创建表。

12.根据权利要求8或9所述的方法，其特征在于，所述方法包括：推荐在所述目标服务器系统中拆分表。

13.根据权利要求1所述的方法，其特征在于，所述方法还包括：为所述目标服务器系统中的所述RDBMS推荐多模态存储。

14.根据权利要求13所述的方法，其特征在于，所述多模态存储是时间序列模型或KV模型中的至少一种。

15.一种用于为将关系型数据库管理系统(relational database managementsystem，RDBMS)从源服务器系统迁移到目标服务器系统推荐存储格式的系统，其特征在于，所述系统包括：

源服务器系统，至少包括所述源服务器系统中的RDBMS的源数据库；

目标服务器系统，包括与所述目标服务器系统中的RDBMS的一个或多个存储格式对应的数据存储；

推荐平台，包括：

第一接口，用于与所述源服务器系统的所述源数据库进行连接；

第二接口，用于与所述目标服务器系统进行连接；

SQL解析器；

推荐引擎；

其中，所述SQL解析器用于：

经由所述第一接口从所述源服务器系统的所述源数据库中提取SQL查询；

解析所述SQL查询以识别出与列式操作对应的一组查询；

所述推荐引擎用于：

确定在所述识别出的一组查询中使用的列数(Cn)；

16.根据权利要求15所述的系统，其特征在于，所述列(C)的所述列记录中的所述部分列记录包括所述列(C)的所述列记录中的至少70％至80％的列记录。

17.根据权利要求15所述的系统，其特征在于，在所述识别出的一组查询中使用的所述列数(Cn)在实际列数的30％至70％之间。

18.根据权利要求15所述的系统，其特征在于，与所述列式操作对应的所述一组查询包括从所述源数据库中提取的所述SQL查询中的至少50％至70％的查询。

19.根据权利要求15所述的系统，其特征在于，所述推荐引擎用于：

为所述目标服务器系统中的所述RDBMS推荐行存储格式。

20.根据权利要求15所述的系统，其特征在于，所述推荐引擎用于：如果所述列(C)的所述列记录中的所述部分列记录少于所述列(C)的所述列记录的70％至80％的列记录，为所述目标服务器系统中的所述RDBMS推荐行存储格式。

21.根据权利要求15所述的系统，其特征在于，所述推荐引擎用于：如果在所述识别出的一组查询中使用的所述列数(Cn)小于实际列数的30％至70％，为所述目标服务器系统中的所述RDBMS推荐行存储格式。

22.根据权利要求15所述的系统，其特征在于，所述列存储格式被推荐给与所述列式操作对应的所述确定的多列(Cn)中的列的列记录。

23.根据权利要求22所述的系统，其特征在于，所述行存储格式推荐被推荐给未在与所述列式操作对应的所述识别出的一组查询中使用的其他列的其他列记录。

24.根据权利要求22或23所述的系统，其特征在于，所述目标服务器系统的所述数据存储支持所述RDBMS使用混合存储格式。

25.根据权利要求24所述的系统，其特征在于，所述推荐引擎还用于推荐在所述目标服务器系统中重新创建表。

26.根据权利要求22或23所述的系统，其特征在于，所述推荐引擎还用于在所述目标服务器系统中拆分表。

27.根据权利要求15所述的系统，其特征在于，所述推荐引擎还用于为所述目标服务器系统中的所述RDBMS推荐多模态存储。

28.根据权利要求27所述的系统，其特征在于，所述多模态存储是时间序列模型或KV模型中的至少一种。