CN106471489A - 管理具有灵活模式的数据 - Google Patents

Abstract

本文中描述的主题涉及管理具有灵活模式的数据。提供了一种用于管理具有灵活模式的数据的方法、计算机存储介质和系统。该方法包括：提供针对数据库的逻辑表的逻辑视图；以及根据预定义映射约束来管理在逻辑表与物理表之间的映射，逻辑表中的每个被映射为物理表的一部分。该映射约束至少规定：(i)逻辑表中的逻辑列被映射到物理表中的至少一个物理列，并且(ii)逻辑表中的一个中的不同逻辑列被映射到物理表中的不同物理列。作为结果，模式演变可以利用最小化的数据迁移完成。

Description

管理具有灵活模式的数据

背景技术

数据库的模式是规定义如何构建数据库的数据的组织。例如，在关系数据库中，模式规定如何通过定义表、字段、关系、视图、索引、函数、队列、触发器、类型和其他方面来存储和管理数据。对于半结构化数据、多租户数据库以及许多其他情形期望管理具有灵活模式的数据。

目前，具有灵活模式的各种应用遭遇模式常常未被良好定义并且可能随时间演变的问题。诸如结构化查询语言(SQL)数据库的传统数据库具有支持有效模式演变的困难。如已知的，模式演变可以例如当将一对一关系演变为多对一关系时要求重新规范化和表重新分区。由于从旧表到新表的数据迁移，表重新分区是耗时的。额外地，该过程由于在旧表和新表上的互斥锁，常常需要阻断事务。为了避免这些问题，应用通常不允许在线重新规范化和表重新分区，由此在存在模式演变时引入相当多的停机时间。

针对灵活模式的传统解决方案常常在键值对的基础上进行工作，以避免在模式演变时的重新规范化和表重新分区。例如，已经提出了用于灵活模式的关联数组。关联数组是表示实体的原子字段以及稍后用于重新构建数据的内部/外部关系的键值对的集合。关联数组可以将数据引擎从重新规范化和表重新分区解除。然而，在没有数据规范化的情况下，将任何两个实体或属性进行连接必须要求连接操作。作为结果，对关联数组的使用将引入过多的连接操作，并且因此降低数据库的查询性能。具体地，已发现当查询超出简单谓词选择时查询性能动态地下降，并且它们的运行计划涉及在键值存储上的大量连接。另外，键值对在数据规范化不能够被省略的情况下不适用于那些应用。

发明内容

本文中描述的主题的实施例大体涉及管理具有用于使模式演变中的数据迁移最小化的模式的数据。

一个实施例提供至少部分地由计算机实现的方法。该方法包括：提供针对数据库的逻辑表的逻辑视图；以及根据预定义映射约束来管理在逻辑表与物理表之间的映射，逻辑表中的每个被映射为物理表的一部分。映射约束至少规定：(i)逻辑表中的逻辑列被映射到物理表中的至少一个物理列，并且(ii)逻辑表中的一个中的不同逻辑列被映射到物理表中的不同物理列。

另一实施例提供一种计算机可读介质。该计算机存储介质具有计算机可执行指令，该计算机可执行指令当运行时执行包括以下各项的动作：提供针对数据库的逻辑表的逻辑视图；以及根据预定义映射约束来管理在逻辑表与物理表之间的映射，逻辑表中的每个被映射为物理表的一部分，映射约束至少规定：(i)逻辑表中的逻辑列被映射到物理表中的至少一个物理列，并且(ii)逻辑表中的一个中的不同逻辑列被映射到物理表中的不同物理列。

又一实施例提供一种计算环境中的系统。该系统包括：逻辑视图管理器，其被配置为提供针对数据库的逻辑表的逻辑视图；以及映射管理器，其被配置为根据预定义映射约束来管理在逻辑表与物理表之间的映射，逻辑表中的每个被映射为物理表的一部分，映射约束至少规定：(i)逻辑表中的逻辑列被映射到物理表中的至少一个物理列，并且(ii)逻辑表中的一个中的不同逻辑列被映射到物理表中的不同物理列。

根据本文中描述的主题的实施例，针对数据库的逻辑表的逻辑视图被呈现给应用。在内部，这些逻辑表在某些约束下作为子表被映射到物理表中。以这种方式，对逻辑表的查询可以就像表被存储在传统数据库一样以相同数目的物理连接来运行。在本公开的上下文中，术语“查询”包括检索操作和更新操作两者。逻辑表的模式演变可以容易地通过具有最小化的数据迁移的一系列映射更新来实现。作为结果，模式演变的效率与传统物理表重新分区相比较被显著地改进。此外，在没有数据和查询引擎的重大重新设计的情况下，实现具有已知数据库和应用的良好兼容性。

要理解，本发明内容被提供从而以简化的形式介绍构思的选择。下面在具体实施方式中进一步描述这些构思。本发明内容不旨在标识要求保护的主题的关键特征或必要特征，也不旨在用于限制要求保护的主题的范围。

附图说明

图1图示了本文中描述的主题的实施例可以被实现在其中的计算环境的框图；

图2图示了根据本文中描述的主题的实施例的数据库系统的框图；

图3图示了根据本文中描述的主题的实施例的逻辑表和物理表的示例；

图4图示了根据本文中描述的主题的实施例的表示映射函数的表的示例；

图5图示了根据本文中描述的主题的实施例的垂直分区的示例；

图6图示了根据本文中描述的主题的实施例的在具有引用的垂直分区之后的物理表和映射函数的示例；

图7图示了根据本文中描述的主题的实施例的两个重叠的事务的示例；

图8图示了根据本文中描述的主题的实施例的用于管理具有灵活模式的数据的方法的流程图；以及

图9图示了根据本文中描述的主题的实施例的用于管理具有灵活模式的数据的系统的框图。

具体实施方式

现在将参考几个示例实施例讨论本文中描述的主题。将理解，这些实施例仅仅出于使得本领域技术人员能够更好地理解并且因此实现本文中描述的主题的目的来讨论，而非暗示对本主题的范围的任何限制。

如本文中所使用的，术语“包括”及其变型要被理解为意指“包括但不限于”的开放式术语。术语“或者”要被理解为“和/或”，除非上下文另行清楚指示。术语“基于”要被理解为“至少部分地基于”。术语“一个实施例”和“实施例”要被理解为“至少一个实施例”。术语“另一实施例”要被理解为“至少一个其他实施例”。下面可以包含显式的和隐式的其他定义。

图1图示了所描述的主题的一个或多个实施例可以被实现在其中的计算环境100的示例。计算环境100不旨在暗示对本文中描述的主题的使用或功能的范围的任何限制，因为各种实施例可以被实现在各种各样的通用或专用计算环境中。

参考图1，计算环境100包括至少一个处理单元(或处理器)110和存储器120。处理单元110运行计算机可执行指令并且可以为真实处理器或虚拟处理器。在多处理系统中，多个处理单元运行计算机可执行指令以提高处理功率。存储器120可以为易失性存储器(例如，寄存器、高速缓存、RAM)、非易失性存储器(例如，ROM、EEPROM、闪存)或这两者的某种组合。存储器120至少存储用于管理具有灵活模式的数据的软件170的部分。

计算环境100可以具有额外的组件或特征。在图1中示出的示例中，计算环境100包括存储装置130、一个或多个输入设备140、一个或多个输出设备150以及一个或多个通信连接160。诸如总线、控制器或网络的互连机构(未示出)将计算环境100的组件相互连接。通常，操作系统软件(未示出)提供针对在计算环境100中运行的其他软件的操作环境，并且协同计算环境100的组件的活动。

存储装置130可以为可移除的或不可移除的，并且可以包括诸如闪速驱动器、磁盘、磁带或磁带盒、CD-ROM、CD-RW、DVD的计算机可读存储介质、或者能够被用于存储信息并且能够在计算环境100内被访问的任何其他介质。存储装置130可以至少存储针对软件170的指令的部分。

(多个)输入设备140可以为各种不同的输入设备中的一个或多个。例如，(多个)输入设备140可以包括用户设备，例如鼠标、键盘、轨迹球、等等。(多个)输入设备140可以实现一种或多种自然用户接口技术，例如语音识别、触摸和触笔识别、与(多个)输入设备140相接触并且与(多个)输入设备140相邻的手势的识别、空中手势的识别、头和眼跟踪、声音和语音识别、感测用户大脑活动以及机器智能。作为其他示例，(多个)输入设备140可以包括扫描设备；网络适配器；CD/DVD阅读器；或者提供到计算环境100的输入的另一设备。(多个)输出设备150可以为显示器、打印机、扬声器、CD/DVD刻录机、网络适配器、或提供来自计算环境100的输出的另一设备。(多个)输入设备140和(多个)输出设备150可以被并入在单个系统或设备(例如触摸屏或虚拟显示系统)中。

(多个)通信连接160使能通过通信介质到另一计算实体的通信。额外地，计算环境100的组件的功能可以被实现在单个计算机器中或者被实现在能够通过通信连接进行通信的多个计算机器中。因此，计算环境100可以操作于使用到一个或多个远程计算设备的逻辑连接的网络化环境中，一个或多个远程计算设备例如为手持计算设备、个人计算机、服务器、路由器、网络PC、对等设备或另一公共网络节点。通信介质传达诸如经调制的数据信号中的数据或计算机可执行指令或请求的信息。经调制的数据信号是具有以使得在信号中编码信息的方式设置或改变其特性中的一个或多个的信号。通过举例而非限制的方式，通信介质包括利用电气载体、光学载体、RF载体、红外载体、声学载体或其他载体实现的有线或无线技术。

本主题的实施例能够在计算机可读介质的总体上下文中进行描述，计算机可读介质可以为存储介质或通信介质。计算机可读存储介质是能够在计算环境内被访问的任何可用存储介质，但是术语计算机可读存储介质不指代传播的信号本身。通过举例而非限制的方式，在计算环境100内，计算机可读存储介质包括存储器120、存储装置130及其组合。

本主题的实施例能够在计算机可读指令的总体上下文中进行描述，计算机可读指令例如为包含于程序模块中的在计算环境中被运行在目标真实或虚拟处理器上的那些。总体上，程序模块包括例程、程序、库、对象、类、组件、数据结构、等等，其执行特定任务或实现特定抽象数据类型。程序模块的功能可以根据期望在各种实施例中在程序模块之间被组合或被拆分。针对程序模块的计算机可执行指令可以被运行在本地或分布式计算环境内。在分布式计算环境中，程序模块可以被定位在本地和远程计算机存储介质两者中。

图2图示了根据本文中描述的主题的实施例的示例数据库系统200。数据库系统200可以被实现在任何底层数据库之上，无论是当前已知的还是未来开发的。尽管将在下文中结合SQL数据库讨论一些实施例，但是这仅仅是出于说明的目的而不暗示对本文中描述的主题的范围的任何限制。本文中描述的主题可以以任何适当的数据库来体现。

参考图2，数据库系统200包括一个或多个逻辑表210₁、210₂、…、210_n(统称为(多个)逻辑表210)和物理表220。为了调和在数据规范化/表重新分区与模式演变之间的紧张，数据库系统200将逻辑表210的逻辑视图230提供到高级应用。从应用的视角，逻辑表210可以就像它们被物理地存储在数据库系统200中一样地操作。(多个)应用可以通过逻辑视图230对逻辑表210进行操作。在数据库系统200内部，多个逻辑表210被映射到物理表220中，使得这些逻辑表210中的每个被映射为物理表220的一部分或“子表”。在操作时，对逻辑表210的查询将至少部分地基于在逻辑表210与物理表220之间的映射240而被转化为对物理表220的查询。

在数据库系统200中，根据预定义映射约束的集合来创建、维持和/或更新在逻辑表210与物理表220之间的映射240。在一个实施例中，映射约束可以是：逻辑表210中的每个逻辑列被映射到物理表220中的至少一个物理列，其中逻辑列和所映射的物理列具有相同的数据类型。在映射240上的另一约束可以是：在逻辑表210中的任何一个中的不同逻辑列应当被映射到物理表220中的不同物理列。即，一个逻辑表210中的任何两列必须被映射到物理表220中的分开的物理列。

要理解，在本文中描述的主题的上下文中，逻辑表或物理表的“列”可以被定义在表的垂直维度或水平维度上。即，尽管传统上在垂直维度上定义列，但是如所讨论的将表的水平维度定义为列并对列进行映射也落入本文中描述的主题的范围内。

将认识到，在逻辑表210与物理表220之间的映射240不必是单射的，因为来自两个不同逻辑表210的相同数据类型的两列可以被映射到物理表220中的单个物理列中。因此，逻辑表可以容易地被重建用于稍后将讨论的模式演变。

图3示出了逻辑表210和物理表220的示例。在该示例中，存在用于客户关系管理(CRM)应用的两个逻辑表210₁和210₂。如所示出的，逻辑表“R_cust”210₁利用主键CustID存储客户数据，并且逻辑表“R_cont”210₂利用主键ContID和引用逻辑表210₁的外键CustID存储合同数据。外键CustID呈现在合同与客户之间的多对一关系。在该示例中，逻辑表R_cust 210₁和R_cont 210₂中的每个被映射为具有五个物理列的物理表“T”220中的一部分。能够看出，映射符合如以上所讨论的约束。即，每个逻辑列被映射到物理列，并且来自一个逻辑表的任何两个逻辑列被映射到两个分开的物理列。具体地，能够看出，在该示例中，来自逻辑表R_cust210₁的逻辑列310和来自逻辑表R_cont210₂的逻辑列320(其具有相同数据类型)被映射到物理表220中的单个物理列330，即使逻辑列310和320在语义上不相关。

在图3中示出的示例中，逻辑表210中的每个逻辑列被映射到物理表220中的单个物理列。要理解，本文中描述的主题在这一点上不受限制。在备选实施例中，逻辑列能够被映射到不止一个物理列以便更好地支持将在稍后讨论的模式演变。

物理表220中的物理列的数目可以基于逻辑表210中的逻辑列的数目和逻辑列的不同数据类型的数目来确定。例如，在一个实施例中，物理列的数目由TypeCount×max{width(R₁),..,width(R_n)}限制，其中R_i表示第i个逻辑表210，TypeCount表示在逻辑表210中声明的不同数据类型的数目，并且width(R_i)表示在逻辑表R_i中的列的数目。例如，在一个实施例中，物理列的数目的上限可以被确定为：

其中，ColumnCount(R_i，datatype)表示在类型datatype的逻辑表R_i中的列的数目。因此，物理表220的宽度可以由数据类型的数目及其在单个逻辑表210中的最大出现而非逻辑表210的数目限制。这将是有益的，因为具有灵活模式的应用通常需要在数据被规范化的情况下维持大量逻辑表。

另外，随着在逻辑表210中声明的不同数据类型的数目增加，在物理表220中的物理列的数目将增加。当在逻辑表210中存在许多不同数据类型时，物理表220可以很宽。将认识到，在物理表220变得太宽的情况下，可能影响操作效率。此外，数据库系统200可以具有关于物理表220的宽度的上限。为了防止物理列的数目变得太大，可以应用类型转换。例如，在一个实施例中，类型投射可以被用于将多个不同的类型转换成一种类型。通过举例的方式，所有基于字符串的类型可以被投射为可变字符(max)。任何额外的或备选的类型转换技术也是可能的。

限制物理列的数目的另一可能方式是要使用多个物理表来托管逻辑表，使得一些逻辑列被映射到一个物理表，并且其他逻辑列被映射到另一物理表。在一个实施例中，两个物理表可以被配置为两者都将列填充为物理记录的物理标识符。以这种方式，来自两个物理表的两条记录能够被连接为一条记录。

为了支持查询处理和逻辑表重建，根据本文中描述的主题的实施例，在物理表220中的记录与它们的原始逻辑表210之间的关联可以例如基于逻辑表的标识符来维持。标识符可以是下面被描述为数字的适当的标识符。备选地或额外地，标识符可以是任何参考字符、符号或其组合。具体地，仍然参考图3，物理表220具有列“col_tid”340。在一个实施例中，列340的每个字段被填充有从其映射对应的记录的逻辑表210的标识符。通过举例的方式，在记录350中，列340的值“1”指示记录350从其标识符为“1”的逻辑表R_cust 210₁被映射。基于映射和记录关联，每个逻辑表210可以被完全重建。

具体地，在图3的示例中，每个逻辑表210具有单个标识符。然而，要理解，本文中描述的主题在这一点上不受限制。在备选实施例中，记录关联使得逻辑表210能够具有不止一个标识符。备选地或额外地，在一个实施例中，两个或更多个逻辑表可以共享单个标识符。作为结果，物理记录可以包含来自不止一个逻辑表210的元素。以这种方式，模式演变可以在没有数据迁移的情况下来完成。例如，当将逻辑表分区成两个或更多个新逻辑表时，映射使得新逻辑表中的每个在继承初始逻辑表的旧标识符的同时具有它自己的新标识符。以这种方式，能够避免数据迁移。将在稍后讨论示例实施例。

在下文中，将参考图3中示出的其中“col_tid”340被用于将物理记录与它们的原始逻辑表210相关联的示例讨论一些实施例。这仅仅出于说明的目的，而不暗示对本文中描述的主题的任何限制。代替使用物理表220中的专门的列，这样的关联可以以任何其他适当的方式来体现。例如，在一个实施例中，在物理表220中的物理记录与原始逻辑表210之间的关联可以被维持在与物理表220分开的文件中，或者基于物理表220中的不为空的列的集合来推断。

在实现方式中，在逻辑表210与物理表220之间的映射240可以以不同的方式来体现。通过举例的方式，在一个实施例中，映射240通过两个映射函数来实现。被表示为φ的第一映射函数将逻辑表210中的逻辑列映射到物理表220中的一个或多个物理列。被表示为ψ的第二映射函数返回给定逻辑表210的(多个)标识符。例如，在图3中示出的示例中，被存储在列“col_tid”340中的值可以由第二映射函数ψ获得。

在一个实施例中，一起形成映射240的映射函数φ和ψ可以分别由如图4中示出的两个表M_φ和M_ψ表示。如所示出的，表M_φ410被用于存储第一映射函数φ，并且表M_ψ420被用于表示第二映射函数ψ。在该示例中，表420呈现其中逻辑表210中的每个具有一个标识符的一对一关系。然而，如以上所讨论的，本文中描述的主题不限于此。随着针对逻辑表210的模式演变，这样的关系可以被改变使得每个逻辑表具有两个或更多个标识符。

在一些实施例的下面的讨论中，映射240将被描述为包括第一映射函数φ和第二映射函数ψ。要理解，这仅仅出于说明的目的，而不暗示对本文中描述的主题的任何限制。映射240可以以任何其他适当的方式来表示和/或存储。为讨论起见，术语φ和M_φ能够被互换地使用，并且术语ψ和M_ψ能够被互换地使用。

通过根据如以上所讨论的约束将逻辑表210映射到物理表220中，得到的物理表220可以在一些情况下是稀疏的。将认识到，针对物理表220中的任何物理记录，非空字段的数目不多于其原始逻辑表210的宽度，其能够比在物理表220中声明的物理列的数目少得多。这样宽的稀疏的物理表220不能够在一些关系数据库中得到有效地支持。例如，当在物理列中存在大量空字段时，将浪费存储空间。

为了更好地支持稀疏物理列，在一个实施例中，用于物理列的存储空间可以基于物理列的密度来控制。如本文中所使用的，术语物理列的术语“密度”是指物理列中的非空值的百分比或数目。在一个实施例中，如果物理系列的密度被确定为在预定义阈值以下，则用于物理列的存储空间可以被减少。为此，在一个实施例中，物理表220中的一个或多个物理列可以取决于它们的密度而被声明为稀疏列或常规列。即，如果物理列的密度在预定义阈值以下，则物理列可以被声明为稀疏，使得没有存储空间被分配给其中的空值。针对稀疏列，属性值对被物理地用于表示每个非空值，并且空值被自动省略，由此节省存储资源。当记录被检索时，未出现的列可以被假设为空值。

声明稀疏列具有相关联的处理开销。例如，与传统列相比，稀疏列要求针对那些非空值的更多存储空间。为了避免这样的开销，在另一实施例中，物理表220可以通过复用物理列来管理。例如，在一个实施例中，当逻辑列被映射到物理表220时，能够首先尝试使用现有物理列，代替在物理表220中分配新物理列。以这种方式，更多的物理列能够被保持致密并且因此可以被声明为常规列。

在一个实施例中，为了加速查询处理，过滤的索引可以被用于物理表220。通过举例的方式，过滤的索引被构建为使用WHERE子句来索引物理表220中的行的仅仅一部分的索引结构。当应用例如通过以下来子句创建在逻辑表R的逻辑列A_i上的索引时：

CREATE INDEX indexName on R(A_i)，

过滤的索引如下地排除物理表220中的属于其他逻辑表210的那些记录：

CREATE INDEX indexName on T(φ(A_i))

WHERE col_tid＝ψ(R)AND A_i IS NOT NULL

其中T表示物理表220。这样的过滤的索引可以用于创建统计信息。过滤的索引和统计信息提供就像逻辑表被物理地创建一样地将查询优化器引导到运行计划的机制。

如以上所讨论的，应用可以就像(多个)逻辑表210被物理地存储在数据库系统200中一样地在(多个)逻辑表210上进行操作。在数据库系统200内部，对逻辑表的查询将至少部分地基于映射240来处理。具体地，响应于通过逻辑视图接收到对一个或多个逻辑表210的查询，数据库系统200至少部分地基于映射240来将接收到的逻辑查询转化为对物理表220的查询。

一般地，查询转化通过经由到其对应物理表的引用替换到逻辑表的每个引用来完成。例如，在一个实施例中，针对查询框中的每个逻辑表R 210，映射被用于利用物理表220的别名T_k来替换R。例如借助于WHERE子句确定R的记录被映射到其的物理行来添加连接条件。之后，查询中的逻辑列的引用利用其对应的物理列来替换。

通过举例的方式，考虑如图3所示的对逻辑表210的逻辑查询，其检索与“James”相关联的账单的总量。查询包括在R_cust.Name上的选择、在R_cust与R_cont之间的外键连接以及在R_cont.Bill上的聚合。对逻辑表210的原始查询可以为如下：

SELECT COUNT(R_cont.Bill)

FROM R_custJOIN R_cont on R_cust.CustlD＝R_cont.CustlD

WHERE R_cust.Name＝`James′

在一个实施例中，该原始查询如下地被转化为对物理表220的查询：

SELECT COUNT(R_cont.col₂)

FROM T AS R_cust JOIN T AS R_cont ON R_cust.col₁＝R_contcol₃

WHERE R_cust.col_tid＝1 AND R_cont.col_tid＝2AND

R_custcol₄＝`James′

涉及DELETE和UPDATE的查询可以与SELECT查询类似地被转化。针对INSERT查询，转化可以通过指示所查询的逻辑表的记录被映射到其的物理行来完成。例如，如在下面所示出的，列col_tid可以被添加以将(以上的)原始语句转化为物理查询：

VALUES(ψ(R)，v₁，...，v_m)

数据库系统200允许具有最小的数据迁移的逻辑表210的有效模式演变。一般而言，至少部分地通过修改在逻辑表210与物理表220之间的映射240来使逻辑表210的模式演变。更具体地，当通过逻辑视图接收到的事务包括针对一个或多个逻辑表210的模式的演变的请求时，仅仅有必要更新映射(并且可能地在一些情况下更新物理表220本身)。利用如以上所讨论的映射机制，在大多数情况下可以避免由模式演变引起的数据迁移。具体地，已知应用可以请求使用模式演变原语的集合来使模式演变。在这样的实施例中，模式演变原语被转化为更新映射240的一组语句。以这种方式，模式能够在确保与现有数据库的良好兼容性的同时被有效地演变。

出于说明的目的，现在将讨论模式演变的一些示例。在一个实施例中，模式演变包括将(多个)列添加到逻辑表210。在数据库系统200中，通过将物理列分配到物理表并且通过更新用于根据映射约束来将所添加的逻辑列映射到物理列的映射来完成对(多个)列的添加。当没有物理列可用时，新物理列被添加到物理表220并被分配用于该新逻辑列。在一个实施例中，新列仅仅具有默认未被填充在解释的存储中的空值。仅仅当查询更新列中的值时，经更新的物理记录被扩展。因此，将新物理列添加到物理表220不会引起物理扩展。

通过举例的方式，当数据库系统200被构建在SQL数据库上时，应用可以请求使用下面的原语将列A_m+1添加到逻辑表R：

ALTER TABLERADD A_m+1 dataType；

在一个实施例中，该原语被转化为用于更新映射的下面的语句：

ALTER TABLE T ADDcol_M+1 dataType；

INSERT INTO TABLEM_φ VALUES(A_m+1，R，col_M+1)；

另一种类的模式演变是从逻辑表210移除(多个)列。在一个实施例中，通过移除关于该逻辑列的映射来从逻辑表移除逻辑列。例如，应用可以请求使用以下原语从逻辑表R移除列A_m+1：

ALTER TABLE R DROP A_m+1；

在一个实施例中，关于所移除的逻辑列和对应的物理列的映射可以如下地从映射函数φ被删除：

DELETE FROM TABLE M_φ

WHERE logCol＝A_m+1 AND logTab＝`R′；

只要该DELETE语句提交，则可以使逻辑列A_m+1被映射到其的物理列对应用不可见。将认识到，来自逻辑表的物理记录可以在记录在移除的列中具有非空值的情况下占用更多的空间。为此，在一个实施例中，如果数据库未经历高工作负载量，则另一语句被发出以清除这些记录。

模式演变还包括将一个逻辑表拆分成两个或更多个逻辑表的垂直分区。在传统数据库中，垂直分区是代价非常高的，因为要被分区的表R中的物理记录必须从盘被读取，被拆分成两个记录，并且之后分开地被插入到两个得到的表R₁和R₂中。该过程尤其当表具有较大大小时是耗时的。相反，如以上所讨论的，本文中描述的主题的实施例使得逻辑表210能够具有不止一个标识符。在分区的情况下，该能力使得垂直分区能够具有引用现有物理模式的一个标识符和引用新物理模式的另一标识符。其还使得两个或更多个逻辑表能够共享使得两个分区能够引用现有物理模式的单个标识符。此外，物理表220中的每个物理列可以对所有逻辑表210可见。这样的映射机制使得能够在没有数据迁移的情况下进行垂直分区。

更具体地，逻辑表210可以通过逻辑表标识符的继承来分区。在一个实施例中，这样的继承通过更新映射函数ψ来实现。在这样的实施例中，当逻辑表R要被垂直地分区成两个新逻辑表R₁和R₂时，新表R₁和R₂中的每个可以具有两个标识符。即，ψ(R₁)和ψ(R₂)两者引用R的旧标识符以及它们自己的新标识符。因此，在对R₁的查询中，R₁的选择可以被转化为选择满足col_tid＝ψ(R₁)的物理记录。例如，应用可以发出用于如下地从R₁选择列A₁的查询：

SELECT A₁

FROM R₁

在一个实施例中，该查询被转化为下面的语句，其返回属于旧表R的物理记录以及在分区之后被插入到R₁中的记录。

通过举例的方式，参考图3，其中地址被原始地存储在逻辑表R_cust中，假设应用例如使用以下原语请求将逻辑表R_cust分区成两个新表和R_addr：

PARTITION R_cust(CustlD，Name，Address)INTO

R_addr(Address)

在分区之后，和R_addr单独地演变。之后，假设新客户和新地址被插入到两个表中。如图5所示，在物理表T220中，新插入的元组(在图中突出显示)被标注有两个表的新标识符“3”和“4”。图5中的经更新的表M_ψ 420示出了对应的经更新的映射函数ψ。如所示出的，和R_addr两者继承旧表R_cust的标识符“1”并且分别具有它们自己的新标识符“3”和“4”。以这种方式，没有数据需要被迁移。

在一个实施例中，新表可以使用以下语句来重建：

在操作时，应用可以例如使用以下原语请求将表R分区成R₁和R₂：

PARTITION R(A₁，A₂)INTO R₁(A₁)，R₂(A₂)；

在一个实施例中，从以上原语转化的并且更新映射的完整SQL语句被示出如下：

其中第一查询q1针对R₁复制R的(多个)现有标识符(继承)，并且q2将新标识符分配到R₁。查询q3针对R₂复制R的(多个)现有标识符(继承)，并且q4将新标识符分配到R₂。查询q5将R从M_ψ移除，并且查询q6和q7将M_φ中的R改变为R₁或R₂。

另一模式演变是利用引用的垂直分区。考虑具有一对一关系的两个实体。通过规范化，它们被存储在一个表中。当这样的关系演变为多对一相关时，有必要在多侧上将实体分区成单独的表，其中外键列引用一侧表。应用可以例如使用以下原语请求这样的利用引用的垂直分区：

PARTITIONR(A₁，A₂)INTO R₁(A₁)，R₂(A₂，fk REFERENCES R₁(A₁))

该原语涉及将逻辑表R垂直分区成两个表的步骤，将列fk添加到R₂并且填充列fk中的外键值。头两个步骤可以通过更新映射240(例如，映射函数φ和ψ)来有效地完成。然而，最后的步骤必须填充外键值，其可能引起相当大的记录扩展。为了改进效率并减少成本，在一个实施例中，外键值未被填充。作为结果，列fk在分区之后立即是空值，并且仅仅在其后插入的元组显式地维持外键。

缺失的外键可以被重建。要理解，尽管在逻辑层处A₁是逻辑表R₁的列并且对逻辑表R₂不可见，但是物理列φ(A₁)对物理表220中的R₂的物理记录可见。因此，如果R₂的物理元组缺失它的外键，则该元组必须引用共同位于物理表220中的相同物理行的R₁元组。因此，缺失的外键可以根据相同物理记录中的列φ(A₁)来导出。在操作时，应用可以如下地发出查询：

SELECT A₂，fk

FROM R₂

在一个实施例中，在分区之后重建R₂(A₂，fk)的语句可以为如下：

将认识到，通过使用CASE子句，针对具有空外键值的R₂的元组，它的外键值将从物理表220中的相同物理行中的列φ(A₁)提取。在分区之后插入的元组具有被直接检索的非空外键。

将认识到，当使用CASE子句时，真实外键可以被隐藏。难以从子句推断逻辑列的值分布。为了更好地支持列统计信息，在备选实施例中，查询重建可以通过使用其他适当的子句来实现。在一个实施例中，查询R₂(A₂，fk)可以通过WHERE子句来重建。例如，针对两个子查询的两个WHERE子句可以被串联如下：

SELECT φ(A₂)AS A₂，φ(A₁)AS fk

FROM T

WHERE col_tid INψ(R₂)AND φ(fk)IS NULL

UNION ALL

SELECT φ(A₂)AS A₂，φ(fk)AS fk

FROM T

WHERE col_tid IN ψ(R₂)AND φ(fk)IS NOT NULL

以这种方式，当重建的R₂在外键上与R₁连接时，φ(A₁)和φ(fk)的统计信息可以被用于选择物理计划。

通过举例的方式，仍然对图3进行参考。合同和客户最初具有多对一关系。即，一个合同具有仅仅一个客户，并且一个客户可以具有多个合同。该关系由外键列R_cont(CustID)捕获。假设应用使该关系演变为多对多相关，使得一个合同可以具有不止一个客户。在一个实施例中，应用可以使用以下原语来请求这样的演变：

PARTITION R_cont(ContlD，Bill.Cust1D)INTO

新逻辑表R_ref将客户和合同连接，并且表示在客户与合同之间的多对多关系。在演变之后，假设应用将额外的客户添加到现有合同102。在图6中示出了在演变之后的物理表T220。T(col₃，col₆)对应于R_ref，其中ψ(R_ref)＝{2，5}，并且列“col₆”为外键列。能够看出，列“col₆”大多数为空值，除了在演变之后插入的元组。假设应用发出检索多于$1，500的合同中的客户的查询，例如如下：

SELECT DISTINCTR_ref.CustID

在一个实施例中，该逻辑查询被转化为如下语句：

数据库系统200使得能够进行其他模式演变操作，例如逻辑表的垂直合并，将逻辑表分区成具有相同主键的多个表，逻辑表的联合，等等。通过更新在逻辑表210与物理表220之间的映射240并且可能地在一些情况下更新物理表220本身，在模式演变期间的数据迁移可以在大多数情况下被避免。因此，与模式演变相关联的开销被显著减少。

根据本文中描述的主题的实施例，数据库系统200可操作用于管理事务，尤其是重叠的或交错的事务的并发性。通过举例的方式，图7示出了两个重叠的事务710和720。第一事务710和第二事务720中的每个包括两个阶段，查询转化(被标记为“QT”)和物理运行(被标记为“Exec”)。假设第一事务710涉及在时刻730处针对(多个)逻辑表210的模式演变。如所示出的，第二事务720在第一事务710之前被启动并且与第一事务710重叠，并且由第一事务710的模式演变在第二事务720完成之前发生。

如果第一事务710不使由第二事务720访问的任何逻辑表210的模式演变，则事务710和720不干扰彼此并且它们的并发性可以例如使用底层数据库机制照常控制。相反，如果第一事务710使由第二事务720访问的逻辑表210的模式演变，则数据冲突和不一致性可能发生。

在数据库200中，一般而言，可以取决于模式演变是否引起数据迁移来控制事务并发性。仍然参考图7，如果由第一事务710的模式演变不引起数据迁移，则事务710和720的并发性可以例如基于隔离的各自的水平来控制。例如，通过允许针对查询转化的快照隔离，每个事务仅仅在它自己的模式快照上进行操作。作为结果，重叠的事务的所有经转化的物理语句在演变之前处于旧模式上。

具体地，假设第一事务将逻辑表R_old演变为新表R_new。当第二事务720访问R_old时，R_old的物理元组由谓词col_tid IN ψ(R_old)定位，并且ψ(R_old)在第二事务720的生命周期期间是恒定值。额外地，当使逻辑表R_old演变时，第一事务710将不改变物理表220中的col_tid的值。因此，第二事务720可以继续在旧物理元组上进行操作。假定第一事务710不会当从R_old演变到新表R_new时引起数据迁移，来自R_old的物理元组是R_new的一部分。尽管由第一事务710在这些元组上的更新可以对第二事务720可见，但是R_new的任何新填充的元组对第二事务720不可见。作为结果，将不会引起数据冲突，并且因此第一事务710和第二事务720能够都提交。

另一方面，如果由第一事务710的模式演变引起从在第二事务720中涉及的逻辑表R 210的数据的迁移，则在一个实施例中，可以通过防止第二事务720(以及除了第一事务710的任何事务)在数据迁移期间修改或迁移逻辑表R中的数据来控制并发性。在一些情况下，这能够借助于底层数据库并发性控制机制来完成。通过举例的方式，假设第一事务710利用数据迁移将逻辑表R_old演变到新表R_new。模式演变包括两个步骤。在第一步骤处，来自R_old的数据被读出并被写入到R_new。之后，在第二步骤处从R_old删除数据。如果第二事务720在数据迁移开始之前写入逻辑表R_old，则在一个实施例中，能够针对模式演变的第一步骤和第二步骤设置“可串行化”，使得第一步骤被阻断直到第二事务720提交。

然而，在一些情况下，由底层数据库提供的并发性控制机制可能是不够的，例如当由第一事务710的模式演变较早地开始时。因此，并发性管理可以通过使用逻辑表210上的一个或多个锁来实现。通过举例的方式，在一个实施例中，逻辑查询中的逻辑语句中的每个可以在该逻辑语句(i)不迁移来自R的数据并且(ii)修改R或处于可串行化或可重复读取的隔离水平下的情况下，在要被演变的逻辑表R上放置共享锁。在该逻辑语句(i)不引起来自R的数据迁移并且(ii)不修改R或处于读取未提交、读取提交或快照的隔离水平下的情况下，不在R上发出锁。另外，每个逻辑语句可以在逻辑语句将引起来自R的数据迁移的情况下，在R上放置互斥锁。

对锁的使用创建针对模式演变的“可串行化”语义。以这种方式，一次仅仅允许一个事务迁移来自逻辑表R的数据，并且在该时间段期间逻辑表R不能够被修改。如果隔离水平允许，则一些读取操作能够在数据迁移期间访问表R。将认识到，在表R上具有共享锁的事务在转化阶段中不阻断彼此时，它们的并发性行为将例如在运行阶段中通过底层SQL数据库来进一步控制。

通过以上讨论，要理解，根据本文中描述的主题的实施例，不涉及数据迁移的模式演变的大多数实例可以与其他事务共存。仅仅在迁移不可避免或存在数据冲突的情况下，阻断发生。与通常放置互斥锁来阻断并发事务的传统模式演变相比，提高并发性。

图8示出了用于管理具有灵活模式的数据的至少部分地由计算机实现的方法的流程图。要理解，步骤不必按图8中示出的顺序来执行。相反，那些步骤可以以任何其他适当的顺序或并行地被执行。

方法800在步骤810处进入，其中提供针对逻辑表的逻辑视图。在步骤820处根据预定义映射约束来管理在逻辑表与物理表之间的映射。管理映射包括创建、维持和/或更新映射。逻辑表中的每个被映射为物理表的一部分。该映射约束至少规定：(i)逻辑表中的逻辑列被映射到物理表中的一个或多个物理列，并且(ii)一个逻辑表中的不同逻辑列被映射到物理表中的不同物理列。

在一个实施例中，管理映射包括基于逻辑表的标识符来管理在物理表中的记录与逻辑表之间的关联。具体地，关联可以使得逻辑表能够具有不止一个标识符。备选地或额外地，关联可以使得不止一个逻辑表能够共享标识符。

在一个实施例中，物理表的宽度至少部分地基于逻辑表中的逻辑列的数目和逻辑列的不同数据类型的数目来确定。

在一个实施例中，在步骤825处，管理物理表。在一个实施例中，响应于确定物理列的密度在预定义阈值以下而减少用于物理表中的物理列的存储空间。例如，这可以通过将物理列声明为稀疏列来完成。备选地或额外地，当逻辑表的逻辑列被映射到物理表中时，能够首先尝试复用(多个)现有物理列，代替直接分配新物理列。

在一个实施例中，在步骤830处，至少部分地基于映射来处理对逻辑表的一个或多个查询。例如，在一个实施例中，响应于接收到对(多个)逻辑表的查询，接收到的查询至少部分地基于映射而被转化到对物理表的查询。

在一个实施例中，在步骤840处，至少部分地基于用于使模式演变中的数据迁移最小化的映射来使针对一个或多个逻辑表的(多个)模式演变。在一个实施例中，响应于接收到包括针对模式演变的请求的事务，模式可以通过更新映射来演变以避免数据迁移。例如，在一个实施例中，由应用发出的演变原语可以被转化为更新映射的一组语句，例如SQL语句。

在一个实施例中，在步骤850处控制事务的并发性。例如，在一个实施例中，并发性控制包括确定模式演变是否引起数据迁移。如果是的话，则防止演变的逻辑表中的数据在数据迁移期间被任何其他事务修改或迁移。否则，可以例如基于快照隔离来控制并发性。

图9示出了计算环境(例如计算环境100)中的系统900的框图。如所示出的，系统900包括逻辑视图管理器910，其被配置为提供针对逻辑表的逻辑视图。系统900还包括映射管理器920，其被配置为根据预定义映射约束来管理在逻辑表与物理表之间的映射。如以上所讨论的，逻辑表中的每个被映射为物理表的一部分。该映射约束至少规定：(i)逻辑表中的逻辑列被映射到物理表中的一个或多个物理列，并且(ii)逻辑表中的一个中的不同逻辑列被映射到物理表中的不同物理列。

在一个实施例中，映射管理器920被配置为基于逻辑表中的标识符来管理在物理表中的记录与逻辑表之间的关联。在一个实施例中，关联可以使得逻辑表能够具有不止一个标识符。备选地或额外地，关联可以使得不止一个逻辑表能够共享标识符。

在一个实施例中，系统900还包括物理表管理器925，其被配置为管理物理表。在一个实施例中，物理表管理器925可以被配置为响应于确定物理列的密度在预定义阈值以下而减少用于物理表中的物理列的存储空间。备选地或额外地，物理表管理器925可以被配置为当逻辑表的逻辑列被映射到物理表中时复用物理列。

在一个实施例中，系统900包括查询管理器930，其被配置为至少部分地基于映射来处理对逻辑表的一个或多个查询。例如，在一个实施例中，响应于接收到对(多个)逻辑表的查询，接收到的查询至少部分地基于映射而被转化到对物理表的查询。

在一个实施例中，系统900包括模式管理器940。模式管理器940被配置为至少部分地基于用于使模式演变中的数据迁移最小化的映射来使针对一个或多个逻辑表的(多个)模式演变。在一个实施例中，响应于接收到包括针对模式演变的请求的事务，模式可以通过更新映射来演变以避免数据迁移。例如，在一个实施例中，由应用发出的演变原语可以被转化为更新映射的一组语句，例如SQL语句。

在一个实施例中，系统900包括事务管理器950，其被配置为控制在各事务之间的并发性。例如，在一个实施例中，事务管理器950被配置为确定模式演变是否引起数据迁移。如果是的话，则防止演变的逻辑表中的数据在数据迁移期间被任何其他事务修改或迁移。否则，可以例如基于快照隔离来控制并发性。

所描述的主题的实施例可应用于许多情形。例如，数据库200可以被体现为多租户数据库以将来自不同租户的数据整合成一个实例以减少每个租户的拥有成本。在这样的实施例中，每个租户的表是逻辑表210，并且表的数据被物理地维持在物理表220中。由于仅仅维持物理表220和映射240是必要的，所以避免每个租户的表的存储器和缓冲池开销。此外，不同的租户不需要共享任何共性，并且物理数据库能够扩展到大量租户。额外地，在一个实施例中，数据库200可以被构建在云数据库之上以提供云多租户数据库。

作为另一示例，本文中描述的主题的实施例可以被应用于处理半结构化数据，例如JavaScript对象表示(JSON)数据。给定规范化的模式，在一个实施例中，JSON文档被切碎成被存储为逻辑表210的表。整数列可以被添加到每个逻辑表以表示文档的标识符。文档的列的所有标识符可以被映射到物理表220中的相同的物理列。假设该列被命名为“col_objID”。之后，在物理层处，聚集的索引可以被构建在T(col_objID,col_tid)上。聚集的索引克服文档重建的问题，其是传统的基于SQL的半结构化的数据库的主要缺陷。此外，在一个实施例中，当从非数组值到数组演变时可以使用具有引用的垂直分区。因此，当模式演变时，JSON数据库免于数据迁移。额外地，只要底层数据库能够自动地向外扩展，其就能够支持分片。

尽管已经以对结构特征和/或方法动作特定的语言描述了本主题，但是应理解在权利要求中限定的主题不必限于以上描述的特定特征或动作。相反，以上描述的特定特征和动作被公开为实施权利要求的示例形式。

Claims (20)

1.一种至少部分地由计算机实现的方法，包括：

提供针对数据库的逻辑表的逻辑视图；以及

根据预定义映射约束来管理在所述逻辑表与物理表之间的映射，所述逻辑表中的每个逻辑表被映射到所述物理表的一部分，

所述映射约束至少规定：(i)所述逻辑表中的逻辑列被映射到所述物理表中的至少一个物理列，并且(ii)所述逻辑表中的一个逻辑表中的不同逻辑列被映射到所述物理表中的不同物理列。

2.根据权利要求1所述的方法，其中管理所述映射包括：

基于所述逻辑表的标识符来管理在所述物理表中的记录与所述逻辑表之间的关联，

所述关联允许以下至少一项：逻辑表具有不止一个标识符，以及不止一个逻辑表共享一个标识符。

3.根据权利要求1所述的方法，还包括：

至少部分地基于所述逻辑表中的逻辑列的数目与所述逻辑列的不同数据类型的数目，来确定所述物理表的宽度。

4.根据权利要求1所述的方法，还包括管理所述物理表，包括以下至少一项：

响应于确定所述物理表中的物理列的密度在预定义阈值以下，减少用于所述物理列的存储空间；以及

当所述逻辑表的逻辑列被映射到所述物理表中时，复用所述物理列。

5.根据权利要求1所述的方法，还包括：

通过所述逻辑视图来接收对所述逻辑表中的至少一个逻辑表的查询；以及

至少部分地基于所述映射来将接收到的所述查询转化为对所述物理表的查询。

6.根据权利要求1所述的方法，还包括：

通过所述逻辑视图来接收包括针对模式的演变的请求的第一事务，所述模式针对所述逻辑表中的至少一个逻辑表；以及

至少部分地基于所述映射来使所述模式演变，使得所述至少一个逻辑表中的数据的迁移在所述演变期间被最小化。

7.根据权利要求6所述的方法，其中针对所述演变的所述请求包括针对所述演变的原语，并且其中使所述模式演变包括：

将所述原语转化为更新所述映射的至少一个语句。

8.根据权利要求6所述的方法，还包括：

确定所述至少一个逻辑表是否由第二事务访问，所述第二事务在所述第一事务之前被启动并且与所述第一事务重叠；以及

响应于确定所述至少一个逻辑表由所述第二事务访问，取决于所述模式的所述演变是否引起所述至少一个逻辑表中的所述数据的迁移，来控制在所述第一事务与所述第二事务之间的并发性。

9.根据权利要求8所述的方法，其中控制在所述第一事务与所述第二事务之间的所述并发性包括：

响应于确定所述模式的所述演变引起所述数据的所述迁移，防止所述至少一个逻辑表中的所述数据由所述第二事务在所述数据的所述迁移期间修改或迁移。

10.一种在计算环境中的系统，包括：

逻辑视图管理器，其被配置为提供针对数据库的逻辑表的逻辑视图；以及

映射管理器，其被配置为根据预定义映射约束来管理在所述逻辑表与物理表之间的映射，所述逻辑表中的每个逻辑表被映射为所述物理表的一部分，

所述映射约束至少规定：(i)所述逻辑表中的逻辑列被映射到所述物理表中的至少一个物理列，并且(ii)所述逻辑表中的一个逻辑表中的不同逻辑列被映射到所述物理表中的不同物理列。

11.根据权利要求10所述的系统，其中所述映射管理器被配置为基于所述逻辑表的标识符来管理在所述物理表中的记录与所述逻辑表之间的关联，

所述关联允许以下至少一项：逻辑表具有不止一个标识符，以及不止一个逻辑表共享一个标识符。

12.根据权利要求10所述的系统，其中所述物理表的宽度至少部分地基于所述逻辑表中的逻辑列的数目与所述逻辑列的不同数据类型的数目被确定。

13.根据权利要求10所述的系统，还包括物理表管理器，其被配置为通过以下至少一项来管理所述物理表：

响应于确定所述物理表中的物理列的密度在预定义阈值以下，减少用于所述物理列的存储空间；以及

当所述逻辑表的逻辑列被映射到所述物理表中时，复用所述物理列。

14.根据权利要求10所述的系统，还包括查询管理器，其被配置为：

通过所述逻辑视图来接收对所述逻辑表中的至少一个逻辑表的查询；以及

至少部分地基于所述映射来将接收到的所述查询转化为对所述物理表的查询。

15.根据权利要求10所述的系统，还包括模式管理器，其被配置为：

通过所述逻辑视图来接收包括针对模式的演变的请求的第一事务，所述模式针对所述逻辑表中的至少一个逻辑表；以及

至少部分地基于所述映射来使所述模式演变，以使所述至少一个逻辑表中的数据的迁移最小化。

16.根据权利要求15所述的系统，其中针对所述演变的所述请求包括针对所述演变的原语，并且其中所述模式管理器被配置为：

将所述原语转化为更新所述映射的至少一个语句。

17.根据权利要求15所述的系统，还包括事务管理器，其被配置为：

确定所述至少一个逻辑表是否由第二事务访问，所述第二事务在所述第一事务之前被启动并且与所述第一事务重叠；以及

响应于确定所述至少一个逻辑表由所述第二事务访问，取决于所述模式的所述演变是否引起所述至少一个逻辑表中的所述数据的迁移，来控制在所述第一事务与所述第二事务之间的并发性。

18.根据权利要求17所述的系统，其中所述事务管理器被配置为：

响应于确定所述模式的所述演变引起所述数据的所述迁移，防止所述至少一个逻辑表中的所述数据由所述第二事务在所述数据的所述迁移期间修改或迁移。

19.一种具有计算机可执行指令的计算机存储介质，所述计算机可执行指令当被运行时执行包括以下各项的动作：

提供针对数据库的逻辑表的逻辑视图；以及

根据预定义映射约束来管理在所述逻辑表与物理表之间的映射，所述逻辑表中的每个逻辑表被映射为所述物理表的一部分，

所述映射约束至少规定：(i)所述逻辑表中的逻辑列被映射到所述物理表中的至少一个物理列，并且(ii)所述逻辑表中的一个逻辑表中的不同逻辑列被映射到所述物理表中的不同物理列。

20.根据权利要求19所述的计算机存储介质，其中管理所述映射包括：

基于所述逻辑表的标识符来管理在所述物理表中的记录与所述逻辑表之间的关联，

所述关联允许以下至少一项：逻辑表具有不止一个标识符，以及不止一个逻辑表共享一个标识符。