CN111630497A - 在数据库系统中的增量特征开发和工作负荷捕获 - Google Patents

Abstract

公开了用于在数据库系统中的增量特征开发和工作负荷捕获的系统、方法和设备。该方法包括确定具有将被重新运行用于测试该特征的一个或更多个历史客户端查询的工作负荷，其中该特征包括过程逻辑。该方法还包括执行工作负荷的、不实现该特征的基线运行以及执行工作负荷的、同时实现该特征的目标运行。该方法还包括比较基线运行和目标运行以识别在目标运行中是否存在性能退化。该方法还包括响应于识别出该性能退化，重新运行目标运行以识别该性能退化是否仍然存在。

Description

在数据库系统中的增量特征开发和工作负荷捕获

相关申请的交叉引用

本申请要求于2018年3月22日提交的标题为“SNOWTRAIL：TESTING WITHPRODUCTION QUERIES ON A CLOUD DATABASE”的美国临时申请序列号62/646,817的利益，该临时申请的公开通过引用以其整体并入本文。

技术领域

本公开涉及数据库，且更具体地涉及在数据库系统中的特征开发和工作负荷(workload)捕获。

背景

本公开总体上涉及用于在数据库系统中的特征实现和工作负荷捕获的系统、方法和设备。数据库是使数据能够容易被访问、操纵和更新的有组织的数据集合。数据库充当以高效的方式存储、管理和检索信息的方法。传统的数据库管理需要公司供应基础设施和资源来管理数据中心中的数据库。传统数据库的管理可能是非常昂贵的，且需要由具有宽范围的技术技能集的多个人进行监督。

传统的关系数据库管理系统(RDMS)需要大规模的计算和存储资源，并且具有有限的可扩展性。大量数据可以跨多个计算设备被存储，并且服务器可以管理数据，使得客户可以使用本地部署的(on-premises)操作对其进行访问。对于希望拥有内部数据库服务器的实体，该实体必须在硬件和数据库的基础设施的资本投资上、以及用于存储数据库基础设施的相当大的物理空间上花费相当多的资源。此外，在断电或其他灾难情况期间，数据库可能非常容易遭受数据丢失。这种传统的数据库系统具有显著的缺点，这些缺点可以通过基于云的数据库系统来减轻。

云数据库系统可以通过云平台被部署和交付，该云平台允许组织和最终用户存储、管理和检索来自云的数据。一些云数据库系统包括通过在计算云之上安装数据库软件来实现的传统数据库架构。数据库可以通过Web浏览器或应用编程接口(API)来访问，用于应用和服务整合。一些云数据库系统由代表客户端直接管理数据库安装、部署和资源分配任务的后端过程的供应商操作。客户端可能有通过Web浏览器和/或API访问数据库的多个最终用户。云数据库可以通过减轻丢失数据库数据的风险和允许数据由跨多个地理区域的多个用户访问来向一些客户端提供显著的好处。

对于传统数据库系统和云数据库系统，存在多种架构。一个示例架构是共享磁盘系统。在共享磁盘系统中，所有数据都被存储在从数据群集中的所有处理节点可访问的共享存储设备上。在这种类型的系统中，所有数据更改被写到共享存储设备以确保数据群集中的所有处理节点访问一致版本的数据。当在共享磁盘系统中处理节点的数量增加时，共享存储设备(以及在处理节点和共享存储设备之间的通信链路)成为减慢数据读取和数据写入操作的瓶颈。随着更多处理节点的添加，这一瓶颈进一步加重。因此，由于这个瓶颈问题，现有的共享磁盘系统具有有限的可扩展性。

另一个现有的数据存储和检索系统被称为“无共享架构”。在这种架构中，数据跨多个处理节点分布，使得在整个数据库中每个节点存储该数据的子集。当新的处理节点被添加或删除时，无共享架构必须跨多个处理节点重新布置数据。数据的这种重新布置可能是耗时的，并且对在数据重新布置期间执行的数据读取和写入操作是破坏性的。而且，数据与特定节点的密切关系可以在数据集群上为热门数据创建“热点(hot spot)”。此外，因为每个处理节点也执行存储功能，所以这种架构需要至少一个处理节点来存储数据。因此，如果所有处理节点被移除，则无共享架构无法存储数据。此外，由于数据跨许多不同的处理节点而分布，在无共享架构中的数据的管理是复杂的。

特别地，在数据库即服务(DBaaS)实现(其中在基于云的环境中提供数据库管理)中，可能期望持续向数据库客户端发布新的特征或程序。这些新程序可以改进数据库的功能，可以向数据库客户端提供新的特征，可以提供增加的安全性，可以提供更快的运行时间，等等。然而，总是存在与发布没有在真实世界环境中被严格测试的新程序相关的风险。在数据库技术的实例中，存在与发布没有在实际数据库数据上被测试的新程序或者与对数据库数据的实际客户端查询相关的固有风险。该程序可能有会引起对数据库数据的损坏、引起性能或运行时间问题、使在数据库系统中的所有其他功能中的额外错误永久存在等的错误(error)或缺陷(bug)。

然而，存在与测试快速运转的云数据库服务相关的许多挑战。例如，大规模基于云的数据库服务每天将运行数千万个客户端查询，并且可能具有在线升级过程以确保连续可用性。特征或程序可能被不断地发布，且客户端可能预期新功能的快速周转(turnaround)。这个快速周转可能意味着在发布之前存在用于测试特征或程序的短时间窗口。本文公开了用于测试特征或程序以及用于在数据库系统中捕获客户端工作负荷的改进的系统、方法和设备。本文的公开实现对程序开发周期的实质性改进，使得新的特征或程序只有在经历严格的真实世界测试之后才可以发布给客户端。

附图简述

参考下面的附图描述了本公开的非限制性的和非穷尽的实现。本公开的优点将关于下面的描述和附图变得更好理解，附图中：

图1是根据本公开的教导和原理的用于测试特征的过程流程的示意图；

图2是根据本公开的教导和原理的用于通过流播(streaming)实现来测试特征的过程流程的示意图；

图3是根据本公开的教导和原理的检索和数据存储系统的部件的框图；

图4是根据本公开的教导和原理的资源管理器的实施例的框图；

图5是根据本公开的教导和原理的执行平台的框图；

图6是根据本公开的教导和原理的操作环境的示意性框图；

图7是根据本公开的教导和原理的用于测试数据库上的特征的方法的示意性流程图；以及

图8是根据本公开的教导和原理的示例计算设备。

详细描述

本公开扩展到用于在数据库系统中的增量特征开发和工作负荷捕获的系统、方法和设备。本公开的实现可以在基于云的数据库设计中实现，并且可以被称为数据库即服务(DBaaS)架构。基于云的数据库系统的面向服务的架构提供了用于生成新功能和新程序的机会。在一些实例中，新特征和/或程序在被发布到客户端或在客户端的数据库数据上被操作之前被严格地测试可能是势在必行的。程序测试可以揭露可能损坏数据库数据、增加运行时间或引起性能的其他问题的错误或缺陷。在一些实例中，在特征或程序被发布到生产服务器之前在实际数据库数据上或使用实际数据库查询测试特征或程序可能是有益的。本文公开了用于捕获在数据库系统中的客户端工作负荷以在客户端的实际数据库数据上和/或使用客户端的实际数据库查询测试特征或程序的系统、方法和设备。这样的系统、方法和设备提供了数据库特征或程序的改进的测试，以使开发者能够在程序被发布到生产服务器之前修复错误或缺陷。使用客户端生产查询进行测试可以提供程序对客户端的查询的影响的确切知识，且因此在该程序被发布到任何客户端之前允许反馈被收集以及对该程序的改进被做出。

在一个实施例中，实现了一种用于测试在数据库上的特征的方法。该方法包括确定包括将被重新运行用于测试该特征的一个或更多个历史客户端查询的工作负荷，其中该特征包括过程逻辑。该方法包括执行工作负荷的、不实现该特征的基线运行。该方法包括执行工作负荷的、同时实现该特征的目标运行。该方法包括比较基线运行和目标运行以识别在目标运行中是否存在性能退化。该方法包括，响应于识别出性能退化而在隔离的资源约束下重新运行目标运行以识别性能退化是否仍然存在。

可以通过获得存储在数据仓库中的历史数据来实现如本文公开的改进的测试和增量特征开发。历史数据可以包括所有客户端发出的查询的历史、以及这些查询的配置和相关统计信息。历史数据还可以包括被用来执行那些客户端发出的查询的实际数据库数据和元数据。如本文公开的多租户基于云的数据库架构使历史数据能够被安全地存储，并通过资源管理器或全局服务被安全地访问。可以运用历史数据来实现工作负荷分析和新特征或程序的增量开发。本文公开的系统、方法和设备创建了运行实际历史客户端查询以测试可由数据库本身提供的特征或程序的独特能力。

在一个实施例中，程序或特征的开发者可以重新运行实际客户端查询以使用实际的数据库数据来在真实世界场景中测试该程序。在一些实例中，因为实际客户端查询为了测试目的而被运用，所以确保客户端查询被模糊(obfuscated)并且在测试过程期间不能被开发者读取可能是势在必行的。如本文所公开的，可以使用单独的专用虚拟仓库116在隔离的云服务上重新运行客户端查询以确保客户端的安全性被维护。

在一个实施例中，可以在不影响被分配用于客户端任务的任何处理或执行资源的情况下实现用于测试特征或其他过程逻辑的系统和方法。在一个实施例中，部署了多租户基于云的数据库系统。数据库系统可以为多个数据库客户端提供数据库存储和处理服务。数据库客户端可以跨多个共享存储设备存储数据库数据，并且可以利用具有多个执行节点的一个或更多个执行平台。数据库系统可以被组织成使得存储和计算资源可以被有效地无限扩展。可以在不影响或减慢任何客户端功能的情况下部署用于测试特征(例如改进或改动数据库功能的过程逻辑)的系统和方法。客户端功能可以包括直接从客户端接收的查询和/或可以包括“内部”任务，例如使表重新聚集(re-clustering)、生成或更新物化视图、更新元数据等。在一个实施例中，特征测试系统和方法被部署在与用于执行内部或外部客户端任务的任何资源分离的执行/处理资源上。

在快速运转的云数据库服务中存在与测试程序相关的许多挑战。例如，大规模数据库提供商可能每天运行数千万个客户端查询，并具有在线升级过程以确保连续可用性。数据库提供商可以为新的特征或程序采用连续的发布周期，其使快速的特征交付成为可能，但是引起用于在发布人工制品(release artifact)上测试的相对短的时间窗口。例如，数据库提供商可以在每周的某个时间发布新特征。当第一特征在第一周被发布时，该特征可以在第二特征在第二周被发布之前在真实世界使用中仅被测试一周。第二特征的发布干扰第一特征的任何有价值的测试。因此，对于快速发布周期，在程序被发布或迁移到实际客户端工作负荷之前使用实际客户端查询来测试程序是合乎需要的。这种测试提供程序的稳定性和成功的保证。

然而，在涉及大规模数据库提供商的一些实现中，重新运行被提交到数据库提供商的所有客户端查询是极其昂贵的。具体地，在快速发布周期中，在新程序被发布之前重新运行客户端查询可能是成本高昂的。因此，本文的公开的一个方面包括工作负荷采样和选择以确保测试消耗合理数量的时间和资源，同时仍然提供可靠的结果。

可以用基于云的数据库技术来实现用于增量特征开发和工作负荷捕获的系统、方法和设备。数据库数据可以存储在跨地理区域可访问的基于云的存储中。这个基于云的存储指的是存储在异地(off-site)存储系统处的数据库数据，异地存储系统在一些实现中可以由第三方维护。例如，客户端可以选择用云存储提供商存储数据，而不是将数据存储在客户端所拥有的本地计算机硬盘驱动器或其他本地存储设备上。客户端可以通过在客户端的计算资源和存储客户端的数据的异地存储资源之间的互联网连接来访问数据。

数据库数据的云存储可以提供优于传统的现场(on-site)本地存储的几个优点。当数据库数据被存储在云存储中时，可以在具有互联网连接的任何位置处访问信息。因此，数据库客户端不需要移动物理存储设备或使用同一计算机来保存、更新或检索数据库信息。此外，数据库信息可以由在不同地理位置处的多个用户同时访问、更新和保存。客户端可以通过互联网将文件的副本发送到与云存储提供商相关联的、记录这些文件的数据服务器。客户端可以通过借助于基于Web的接口或其他用户接口访问与云存储提供商相关联的数据服务器来检索数据。然后，与云存储提供商相关联的数据服务器可以将文件发送回客户端，或者允许客户端访问和操纵在数据服务器本身上的文件。

数据库表可以响应于数据操纵(DML)语句例如插入命令、删除命令、合并命令等而被改动。这样的修改可以被称为出现在数据库表上的事务(该修改可以可选地在本文被称为“更新”)。在一个实施例中，每个事务包括指示事务何时被接收到和/或事务何时被完全执行的时间戳。在一个实施例中，事务包括对表进行的多个改动，并且这样的改动可能影响在表中的一个或更多个微分区。

在一个实施例中，表中的所有数据被自动划分到被称为微分区的不可变存储设备内。微分区可以被考虑为批处理单元，其中每个微分区具有连续的存储单元。作为示例，每个微分区可以包含在50MB和500MB之间的未压缩数据(注意，在存储区中的实际大小可能更小，因为数据可能被压缩地存储)。表中的行的组可以被映射为以多栏式(columnar)方式组织的单独微分区。这种大小和结构允许对非常大的表进行极细粒度的修剪，这些表可以由数百万或甚至数亿个微分区组成。可以自动收集关于存储在微分区中的所有行的元数据，包括：在微分区中的每个列的值的范围；不同值的数量；和/或用于优化和高效查询处理的附加属性。在一个实施例中，可以在所有表上自动执行微分区划分。例如，可以使用当数据被插入/加载时出现的排序来透明地划分表。

在一个实施例中，元数据可以存储在不可变存储区中的元数据微分区中。在一个实施例中，系统可以针对数据库表的每次修改将元数据微分区写到云存储。在一个实施例中，系统可以下载和读取元数据微分区以计算扫描集。元数据微分区可以并行地被下载并在它们被接收到时被读取，以改进扫描集计算。在一个实施例中，系统可以周期性地在后台中合并元数据微分区。在一个实施例中，可以包括性能改进，包括预取、缓存、多栏式布局等。此外，使用具有多栏式布局的元数据文件，安全性改进(包括加密和完整性检查)也是可能的。

在本公开的下面的描述中，参考形成本文的一部分的随附附图，并且，在附图中通过例证的方式示出了本公开可被实践的特定实现。应理解，可以利用其他实现，并且可以做出结构改变而不偏离本公开的范围。

在描述和主张本公开时，将根据下面阐述的定义来使用以下术语。

必须注意，如在这个说明书和所附权利要求书中使用的，单数形式“a”、“an”和“the”包括复数所指对象，除非上下文另外明确地规定。

在整个该说明书中对“一个实施例(one embodiment)”、“一个实施例(anembodiment)”、“一个实现(one implementation)”、“一个实现(an implementation)”、“一个示例(one example)”或“一个示例(an example)”的提及意味着关于该实施例、实现或示例所描述的特定的特征、结构或特性被包括在本公开的至少一个实施例中。因此，上述短语在整个本说明书的各个地方中的出现并不一定都指同一实施例、实现或示例。此外，应当认识到，随此提供的附图是出于对本领域中的普通技术人员的解释目的。

如在本文使用的，术语“包括(comprising)”、“包括(including)”、“包含”及其语法等同物是不排除额外的、未列举的元素或方法步骤的包括界限的或开放式的术语。

如在本文使用的，“表”被定义为记录(行)的集合。每条记录包含表属性(列)的值的集合。表通常物理地存储在多个较小(变化的大小或固定大小)的存储单元例如文件或块中。

根据本公开的实施例可以被体现为装置、方法或计算机程序产品。因此，本公开可采用完全包括硬件的实施例、完全包括软件的实施例(包括固件、驻留软件、微代码等)或组合软件和硬件方面的实施例的形式，在本文中这些实施例通常可以全部被称为“电路”、“模块”或“系统”。此外，本公开的实施例可采用体现在表达的任何有形介质中的计算机程序产品的形式，有形介质具有在介质中体现的计算机可用程序代码。

可以利用一个或更多个计算机可用或计算机可读介质的任何组合。例如，计算机可读介质可包括便携式计算机磁盘、硬盘、随机存取存储器(RAM)设备、只读存储器(ROM)设备、可擦除可编程只读存储器(EPROM或快闪存储器)设备、便携式光盘只读存储器(CDROM)、光学存储设备和磁存储设备中的一个或更多个。可以用一种或更多种编程语言的任何组合来写用于执行本公开的操作的计算机程序代码。可以将这样的代码从源代码编译成计算机可读汇编语言或适合于该代码将在其上被执行的设备或计算机的机器代码。

还可在云计算环境中实现实施例。在本描述和随附的权利要求中，“云计算”可以被定义为用于实现对可配置计算资源(例如，网络、服务器、存储、应用和服务)的共享池的普遍、方便、按需网络访问的模型，该共享池可经由虚拟化被快速提供，并以最小管理努力或服务提供商交互被发布，然后相应地扩展。云模型可由各种特性(例如，按需自助式服务、广泛的网络访问、资源池化(resource pooling)、快速弹性、以及所测量的服务)、服务模型(例如软件即服务(“SaaS”)、平台即服务(“PaaS”)和基础设施即服务(“IaaS”))以及部署模型(例如私有云、社区云、公共云和混合云等)组成。

在所附的附图中的流程图和框图示出了根据本公开的各种实施例的系统、方法和计算机程序产品的可能实现的架构、功能和操作。在这点上，在流程图或框图中的每个块可代表包括用于实现指定的逻辑功能的一个或更多个可执行指令的代码的模块、段或部分。还将注意，框图和/或流程图的每个块以及在框图和/或流程图中的块的组合可由执行指定功能或行动的专用的基于硬件的系统、或专用硬件和计算机指令的组合实现。这些计算机程序指令还可存储在计算机可读介质中，该计算机可读介质可指导计算机或其他可编程数据处理装置以特定方式起作用，使得存储在计算机可读介质中的指令产生包括实现在流程图和/或框图的一个或多个块中所指定的功能/行动的指令模块的制造物品。

本文描述的系统和方法可以使用新的数据处理平台在灵活和可扩展的数据仓库上操作。在一些实施例中，所描述的系统和方法运用支持基于云的存储资源、计算资源等的云基础设施。示例基于云的存储资源以低成本提供按需可用的相当大的存储容量。此外，这些基于云的存储资源可以是容错的和高度可扩展的，这在私有数据存储系统中实现起来可能是昂贵的。示例基于云的计算资源是按需可用的，并且可以基于资源的实际使用水平来定价。通常，云基础设施以快速方式动态地被部署、重新配置和退出运行。

在所描述的系统和方法中，数据存储系统利用基于SQL(结构化查询语言)的关系数据库。然而，这些系统和方法可应用于任何类型的数据库和任何类型的数据存储和检索平台，使用任何数据存储架构并使用任何语言来在数据存储和检索平台内存储和检索数据。本文描述的系统和方法还提供了支持在不同客户/客户端之间以及在同一客户/客户端内的不同用户之间的计算资源和数据的隔离的多租户系统。

现在参考附图，图1是用于在数据库系统中的特征测试的过程流程100的示意图。过程流程100提供了用于运行生产查询并检测退化的工具。过程流程100可以将查询组织成工作负荷，工作负荷可以在不同的设置下运行并且稍后被比较以分析运行之间的差异。工作负荷可以由客户端所请求的、并在实际数据库数据上针对客户端被执行的实际历史客户端查询组成。过程流程100提供多种功能，包括：工作负荷选择、工作负荷运行和结果分析。工作负荷选择包括为了当前测试的目的而从历史客户端查询的储存库对适当的工作负荷采样。工作负荷运行包括使用指定的设置运行选定的工作负荷。结果分析包括消耗多次运行的结果，并比较这些结果以生成关于差异或退化的报告。作为过程流程100的结果而确定的有用数据可以作为数据库数据被存储在一个或更多个表中。

图1所示的过程流程100可以代表用于特征测试的过程流程。过程流程100可以由意图在数据库系统102上实现的特征或程序的开发者112来实现。数据库系统102包括工作负荷储存库104、查询统计信息106、模糊结果108和测试运行元数据110。开发者112可以通过在132指定工作负荷选择配置或者在130直接导入工作负荷来构建要运行的查询的工作负荷118。在132的工作负荷选择配置包括用于选择最佳适合于测试目标特征的查询的标准。然后，基于由开发者112设置的给定配置来生成工作负荷118。

在工作负荷118被生成之后，开发者112在128指定运行设置。运行设置用于运行工作负荷118。在一个实施例中，需要至少两组运行设置，其中一组是基线运行124，一组是目标运行126。对于特征测试，除了特征标志之外，这两个设置(即基线运行124和目标运行126)可以是相同的。特征测试运行可以与工作负荷118分离，因此工作负荷118可以用不同的设置运行任何次数。

开发者112在专用虚拟仓库116上发起基线运行124和目标运行126以确保资源隔离。当基线运行124和/或目标运行126完成时，在120执行结果的验证以消除假阳性(falsepositive)。在120的验证由针对退化生成的报告122运行。假阳性最典型地会出现在性能比较中，且可能由在云数据库环境中的变化引起。包括查询历史、查询统计信息106、模糊结果108和运行的元数据的所有相关数据存储在数据库系统102中。该相关数据可能可以使用结构化查询语言(SQL)来查询。开发者112可以根据测试的目标，向下切入以调查来自报告122的特定查询，或者选择使用自定义SQL查询来执行更深入的分析。

工作负荷

给定在工作负荷118中的查询的数量(即，样本大小)，可以基于由开发者112提供的一组标准来自动选择工作负荷118。多种多样的选择标准可以用于确定工作负荷118。选择标准可以包括发出历史查询的帐户和用户、历史查询的数据库和范式(schema)、运行历史查询的时间窗口、匹配查询文本片段(fragment)、匹配执行配置等。

在对满足开发者提供的标准的历史查询去重之后，可以应用进一步修剪搜索空间的一组启发法。在系统中的相当大百分比的历史查询可能是非常简单的，或者可能不呈现重要的测试价值。例如，“select1”查询频繁地由一些工具发出以验证是否存在到数据库的有效连接。这种历史查询不提供重要的测试价值。此外，可以优化被选择用于测试的历史查询以确保它们消耗合理数量的资源。因此，被选择用于测试的历史查询应该被优化，使得所选择的历史查询不是太简单而不能提供有价值的信息的，并且不是太昂贵的。对于没有因太简单或太昂贵而被剔除的剩余历史查询，选择可根据多样性测量来实现最大覆盖的历史查询的子集。许多生产范式可能具有固定的使用模式(pattern)。在一些实现中，为每个查询模式选择少量的代表性查询可能就足够了。

在一个实施例中，使用Query2Vec算法来选择多样的工作负荷118。Query2Vec算法将历史SQL查询映射到高维向量空间。因此，历史查询可以以保留语义的方式嵌入到高维向量空间内，使得在向量之间的余弦距离表现得和专用特征向量上的专用距离函数一样。此外，在一个实施例中，为了概括工作负荷118，使用Query2Vec算法来嵌入所有历史查询，且然后使用K-均值来找到K个查询集群。在每个集群中最接近质心的历史查询可以被选择为在概括中该集群的代表性查询。可以使用肘部方法(Elbow method)通过在具有增加的K的循环中运行K-均值算法直到离质心“肘部”的平方距离之和的变化率达到稳定水平为止来确定最佳的K值。该方法可以确保所创建的子样本包括来自所有查询集群的至少一个查询，其中特定类型的客户端查询在每个查询集群中被表示。

所选择的工作负荷在数据库系统102中的工作负荷储存库104中继续存在。工作负荷储存库104存储过去选择的工作负荷连同一些相关上下文，例如编译环境和原始查询的开始时间。这些相关上下文可能对于重新运行查询是有用的。工作负荷储存库104可以存储先前选择的工作负荷，使得这些工作负荷可以被重新运行以选取满足选择标准的最新的一组客户端查询。可以直接从查询文本或其他结构格式如逗号分隔值(CSV)或JavaScript对象表示(JSON)导入所选择的工作负荷。这通常可以在先前选择的工作负荷是固定的时使用，并且开发者112对要运行哪些历史查询有确切的了解。所选择的查询可以不仅包括生产查询，而且包括开发者112希望在生产环境上测试的任何查询。

历史查询运行

可以采用几种机制以实现以安全、可靠和可配置的方式运行客户端查询。这样的机制包括例如结果模糊、查询重定向、可配置的查询编译环境和时间旅行。

在数据安全很重要的实例中，可以使用结果模糊。在某些实例中，以及对于某些数据库数据或数据库客户端，确保数据库数据和查询结果是安全的可能是势在必行的。可以实现结果模糊以确保重新运行客户端查询不会暴露客户端的数据。在编译阶段期间，可以将散列聚合运算符添加到查询计划的顶部。这些散列聚合运算符将模糊查询的结果减少到单个散列值，并保证开发者112将不能够看到由重新运行历史客户端查询返回的结果。散列函数可以计算稳定的散列聚合，其确保结果对于同一历史客户端查询的不同运行是可比较的。稳定的散列聚合可以确保开发者112仅能够看到重新运行的查询结果是否与原始查询结果相同，以及开发者112不能够看到查询结果的实际值。

查询重定向允许两个或更多个版本的云服务和虚拟仓库的比较。可以实现查询重定向机制，以将查询重定向为在具有测试版本的指定云服务实例上运行。查询重定向包括指定运行查询的一组云服务资源，例如一组执行平台和/或在该组执行平台内的特定执行节点。查询重定向可用于实现隔离以及对特定版本的编程逻辑或代码的测试。例如，运行编程逻辑的测试的一种方式是提供具有特定的包版本的专用云实例，并将测试查询重定向为在所提供的实例上运行。

对于作为查询文本导入的工作负荷，可以指定可配置的查询编译环境(例如，帐户、数据库和范式)以成功地运行工作负荷。也可以配置其他环境设置，例如特征标志]。特征标志包括用于控制和/或启用特征的参数(即旋钮)。配置查询编译环境包括从由数据库管理器或提供商控制的内部帐户执行查询的手段。可以实现可配置的查询编译环境以利用在多租户基于云的数据库系统中的多租户能力。在可配置的查询编译环境中，在编译的名称解析阶段期间，可以允许特殊角色选取数据库客户查询的“名称空间”并解析相关对象。

在一个实施例中，历史查询测试被配置为以时间旅行时间戳运行，使得在工作负荷中的所有历史查询将从历史查询的原始运行的指定时间戳时起运行。两次运行的查询结果可能只在它们具有相同的时间旅行版本时才是可比较的，因为数据库数据可以在历史查询测试运行期间通过数据操纵语言(DML)语句的方式被同时更新。

在一个实施例中，对照历史客户端查询运行特征或程序。历史客户端查询的运行旨在测试客户端查询而不影响客户端的生产工作负荷。因此，在一个实施例中，历史客户端查询的运行(即，测试运行)在单独的所配置的云服务114和单独的专用虚拟仓库116上进行。所配置的云服务114和专用虚拟仓库116可以由开发者112配置。根据可用的资源(例如，专用虚拟仓库116的大小)，开发者112可以指定用于运行工作负荷118的并发性。高并发运行也可以用作专用虚拟仓库116的良好压力测试机制。本文公开的系统还可以实现超时限制，以对历史查询在被取消之前可以运行的最大时间进行限制。这可以避免恶意查询占用太多资源。

在一个实施例中，本文公开的系统保持历史客户端查询的原始开始时间。在一个实施例中，系统提供“重放”模式以运行工作负荷118。重放模式以与原始开始时间相同的时间间隔运行历史查询。这可能对模拟所捕获的客户端工作负荷对系统的确切影响是有用的。此外，本文公开的系统可以提供“解释”模式，该“解释”模式编译在工作负荷118中的查询用于检测计划变化和编译错误。

验证和分析

在工作负荷118在不同设置下生成多个运行(例如，基线运行124和目标运行126)之后，特征测试系统可以执行在120的验证和对结果的分析以生成报告122。在120的验证步骤可能对性能比较以降低假阳性率是有益的。当比较基线运行124和目标运行126时，特征测试系统在120通过使用目标运行126的设置多次重新运行被报告为比在基线运行124中的相同查询慢的查询来验证在目标运行126中的性能退化。这可能在剔除由于云环境的变化、或虚拟仓库中的数据或云服务层中的元数据的不同缓存状态造成的在性能比较中的假阳性时是有益的。只有在查询在几次验证运行之后一致地显示相当大百分比的性能退化之后，特征测试系统才将特征或程序报告为实际性能问题。此外，例如对于加载有数据、经过处理且然后被截短的分段表(staging table)，对基础表的数据改变可能使性能比较变得与客户端的使用情况无关。

除了检测性能退化以外，特征测试系统还检测错误的结果以及新的用户错误或内部错误。特征测试系统自动生成报告122。特征测试系统确保报告122确保比较总是有效的。例如，非确定性查询被排除在性能和结果比较之外。达到由运行设置的超时限制的查询不针对性能差异被比较。在两次运行(即基线运行124和目标运行126)中以相同错误代码失败的查询不被报告为退化。

在一个实施例中，确保报告122简明且对于开发者112来说容易消化可能是有益的。因为工作负荷和运行的所有元数据(包括每个查询的详细统计信息)存储在特征测试系统中，所以经验丰富的用户可以容易写他们自己的分析查询以执行适合于他们自己的测试需要的更详细的分析。

现在参考图2，示出了特征测试系统流播运行的过程流程200。在一个实施例中，特征测试系统的默认模式是面向批处理的，其中工作负荷118被预先选择且然后在不同的设置下运行用于比较。这种面向批处理的模式对于小型至中型大小的工作负荷118可能工作良好，但是对于较大的工作负荷可能工作得不好。较大的工作负荷提出几个问题。较大的工作负荷提出的一个问题是它们花费较长时间来运行，且随着时间的推移，许多原始历史查询由于范式变化(例如丢掉的表)将不再是有效的。额外的问题是，甚至在没有范式变化的情况下，客户端也不断地将新数据摄取到数据库内。为了实现结果比较，特征测试系统对于每次运行使用固定的时间旅行版本，该固定的时间旅行版本通常在运行开始时被设置。额外的问题是，因为工作负荷118是预先固定的，所以错失了选择最新查询集合以满足搜索标准的机会。

流播模式的过程流程200解决了图1所示的面向批处理的过程流程100的上述问题。在流播模式过程流程200中，开发者212提供与在批处理模式(见100)中提供的工作负荷配置和运行设置类似的工作负荷配置和运行设置。然而，不是预先选择工作负荷中的所有查询，而是开发者212现在控制流播速度，该流播速度指定对于每个单位时间周期要选择多少个查询。

在流播模式中，工作负荷微成批地(in micro-batches)由工作负荷选择器202递增地选择，并被添加到查询队列204，查询队列204然后向查询运行器206提交查询。查询运行器206接受每个查询，并在执行验证和比较以生成报告214之前将它多路复用以用不同的设置运行。查询运行器206将根据可以由查询运行器206确定或由开发者212输入的不同参数来运行基线运行208和目标运行210。流播运行的结果可以被周期性地刷新到数据库系统中的共享存储设备，使得用户可以轮询来自正在进行的流播运行的最新结果。

因为查询被单独地提交到查询运行器206，所以查询可以使用不同的时间旅行版本来运行。在流播模式过程流程200中，每个查询使用它们提交到查询运行器206的当前时间戳作为时间旅行版本，并且不需要时间旅行到很遥远的过去。此外，因为工作负荷被递增地选择，所以保证工作负荷只包含非常近的历史查询。这意味着与图1所示的面向批处理的模式相比，当运行这些历史查询时，存在更少的数据变化或范式变化。这导致较少的无效查询。利用流播模式过程流程200，当与面向批处理的模式相比时，特征测试系统可以以更高的成功率支持时间更长的运行。

流播模式过程流程200可用于特征发布测试，以选取最新的客户端查询并提高那些查询的成功率。运行可用于在特征或程序迁移到客户端工作负荷之前确保特征或程序的稳定性。

在某些实例中，可能期望最小化在新的发布人工制品是可用的时和客户端开始迁移到最新发布的特征或程序时之间的时间窗口。为了实现这一点，发布运行可以使用高并发性，并在专用多集群仓库上运行查询，该专用多集群仓库可以自动扩展和缩减以处理查询工作负荷。

工作负荷选择器202确保所选择的历史查询的样本覆盖多样的一组使用情况。使用Query2Vec选择的样本可能使查询选择分散和多样化，因为Query2Vec算法保证从每个查询集群选取一个查询样本，并因而确保所有类型的查询的覆盖。

特征测试

在将新的特征或程序(例如与SQL相关的改进)发布到数据库客户端之前，使用特征测试系统在生产查询上测试新的特征或程序。测试新的特征或程序以深入了解变化(即新特征或程序的实现)对数据库客户端的影响。为了测试新的特征和程序，开发者可以设置特征标志并遵循如在图1-2中描述的过程流程100、200。

现在参考图3，示出了用于运行本文公开的方法的计算机系统300。计算机系统300可以被配置成在开发阶段期间通过在实际数据库数据上执行特征或程序来测试这些特征或程序。计算机系统300可以用于执行从用户接收的真实客户端查询和/或用于在稍后的时间为了特征测试的目的而重新运行那些真实客户端查询。

如图3所示，资源管理器302可以耦合到多个用户304、306和308。在特定的实现中，资源管理器302可以支持期望访问数据处理平台300的任何数量的用户。例如，用户304、306、308可以包括例如提供数据存储和检索请求的最终用户、管理本文所描述的系统和方法的系统管理员和与资源管理器302交互的其它部件/设备。用户304、306和308在本文可以被称为“客户端”，并且可以具有到如本文公开的一个或更多个部署的直接连接。用户304、306和308中的每一个可以连接到初级部署，并且具有将连接从初级部署转换到次级部署的能力。

资源管理器302提供支持在数据处理平台300内的所有系统和部件的操作的各种服务和功能。资源管理器302可以耦合到元数据310，元数据310与整个数据处理平台300中存储的全部数据相关联。在一些实施例中，元数据310可以包括存储在远程数据存储系统中的数据以及从本地高速缓存可得到的数据的概要。另外，元数据310可以包括关于数据在远程数据存储系统和本地高速缓存中如何被组织的信息。元数据310可以允许系统和服务确定一段数据是否需要在不加载或访问来自存储设备的实际数据的情况下被处理。

资源管理器302还可以耦合到执行平台312，执行平台312提供执行各种数据存储和数据检索任务的多个计算资源，如下面更详细讨论的。在一个实施例中，存在用于执行客户端任务(例如数据库查询和/或“内部”数据库任务，例如更新元数据、聚集表、生成物化视图等)的一个或更多个执行平台312。在这样的实施例中，还可以存在用于增量特征开发和/或测试的一个或更多个执行平台312，并且这些执行平台312与客户端执行平台312分离，使得客户端处理不受特征开发任务影响。执行平台312可以耦合到作为存储平台314的一部分的多个数据存储设备316、318和320。尽管在图3中示出了三个数据存储设备316、318和320，但是执行平台312能够与任何数量的数据存储设备通信。在一些实施例中，数据存储设备316、318和320是位于一个或更多个地理位置上的基于云的存储设备。例如，数据存储设备316、318和320可以是公共云基础设施或私有云基础设施的一部分。数据存储设备316、318和320可以是硬盘驱动器(HDD)、固态驱动器(SSD)、存储集群或任何其它数据存储技术。另外，存储平台314可以包括分布式文件系统(例如Hadoop分布式文件系统(HDFS))、对象存储系统等。

在特定的实施例中，经由一个或更多个数据通信网络来实现在资源管理器302与用户304、306和308、元数据310和执行平台312之间的通信链路。类似地，经由一个或更多个数据通信网络来实现在执行平台312与存储平台314中的数据存储设备316、318和320之间的通信链路。这些数据通信网络可以利用任何通信协议和任何类型的通信介质。在一些实施例中，数据通信网络是耦合到彼此的两个或更多个数据通信网络(或子网络)的组合。在替代实施例中，使用任何类型的通信介质和任何通信协议来实现这些通信链路。

如图3所示，数据存储设备316、318和320从与执行平台312相关联的计算资源解耦。在一个实施例中，多个数据库部署中的每一个可以包括具有多个数据存储设备316、318和320的存储平台314。跨多个部署的每个存储平台314可以存储数据库数据的副本，使得多个部署中的每一个能够充当初级部署，其中更新和查询在数据库数据上被执行。该架构基于变化的数据存储/检索需要以及访问数据处理平台300的用户和系统的变化的需要来支持对数据处理平台300的动态改变。动态改变的支持允许数据处理平台300响应于对在数据处理平台300内的系统和部件的变化的需求而快速扩缩。计算资源与数据存储设备的解耦支持大量数据的存储而不需要相应的大量计算资源。类似地，资源的这个解耦支持在特定时间利用的计算资源的显著增加而不需要可用的数据存储资源的相应增加。

资源管理器302、元数据310、执行平台312和存储平台314在图3中被示为单独的部件。然而，资源管理器302、元数据310、执行平台312和存储平台314中的每一个可以被实现为分布式系统(例如，跨在多个地理位置处的多个系统/平台分布)。此外，资源管理器302、元数据310、执行平台312和存储平台314中的每一个都可以根据从用户304、306和308接收的请求的改变以及数据处理平台300的变化的需要而被扩展或缩减(独立于彼此)。因此，数据处理平台300是动态的，并且支持定期改变以满足当前的数据处理需要。

图4是描绘资源管理器302的实施例的框图。如图3所示，资源管理器302包括耦合到数据存储设备406的访问管理器402和密钥管理器404。访问管理器402可以为本文所描述的系统处理认证和授权任务。密钥管理器404可以管理在认证和授权任务期间使用的密钥的存储和认证。请求处理服务408管理接收到的数据存储请求和数据检索请求。管理控制台服务410支持由管理员和其他系统管理器对各种系统和过程的访问。

资源管理器302还可以包括SQL编译器412、SQL优化器414和SQL执行器210。SQL编译器412解析SQL查询并为查询生成执行代码。SQL优化器414基于需要被处理的数据来确定执行查询的最佳方法。SQL执行器416针对由资源管理器302接收的查询执行查询代码。查询调度器和协调器418将接收到的查询发送到适当的服务或系统用于编译、优化和分派到执行平台312。虚拟仓库管理器420管理在执行平台中实现的多个虚拟仓库的操作。

此外，资源管理器302包括配置和元数据管理器422，其管理与存储在远程数据存储设备中和本地高速缓存中的数据相关的信息。监视器和工作负荷分析器424监督由资源管理器302执行的过程，并管理任务(例如，工作负荷)跨在执行平台中的虚拟仓库和执行节点的分配。配置和元数据管理器422以及监视器和工作负荷分析器424耦合到数据存储设备426。

资源管理器302还包括管理根据历史客户端查询的特征和/或程序测试的特征测试管理器428。特征测试管理器428可以被配置为确定工作负荷和/或用于历史客户端查询的基线运行或目标运行的参数。特征测试管理器428可以执行验证步骤以确保测试数据的可靠性，并且可以进一步生成指示特征和/或程序当用实际历史客户端查询来实现时如何被执行的报告。

图5是描绘执行平台312的实施例的框图。基线运行和/或目标运行(以及被认为必要的任何其他附加运行)的执行可以在执行平台312上被执行。在一个实施例中，特征测试运行只在仅用于特征测试而不用于由数据库客户端发出的生产查询的专用虚拟仓库上运行。使用专用虚拟仓库进行特征测试可以确保客户端的性能和运行时间不受特征开发过程影响。

如图5所示，执行平台312包括多个虚拟仓库502、504和506。每个虚拟仓库包括多个执行节点，每个执行节点包括高速缓存和处理器。尽管图3中所示的每个虚拟仓库502、504和506包括三个执行节点，但是特定的虚拟仓库可以包括任何数量的执行节点而不偏离本公开的范围。此外，在虚拟仓库中的执行节点的数量是动态的，使得当存在额外需求时新的执行节点被创建，并且当现有执行节点不再是必要的时它们被删除。

每个虚拟仓库502、504和506能够访问图3所示的数据存储设备316、318、320中的任何一个。因此，虚拟仓库302、304、306不一定被分配到特定的数据存储设备316、318、320，且替代地，它们可以访问来自数据存储设备316、318、320中的任何一个的数据。类似地，图5所示的每个执行节点可以访问来自数据存储设备316、318、320中的任何一个的数据。在一些实施例中，特定的虚拟仓库或特定的执行节点可以临时被分配到特定的数据存储设备，但是该虚拟仓库或执行节点可以稍后访问来自任何其他数据存储设备的数据。

在图5的示例中，虚拟仓库502包括三个执行节点508、510和512。执行节点508包括高速缓存514和处理器516。执行节点510包括高速缓存518和处理器520。执行节点512包括高速缓存522和处理器524。每个执行节点508、510、512与处理一个或更多个数据存储和/或数据检索任务相关联。例如，特定的虚拟仓库可以处理与特定用户或客户相关联的数据存储和数据检索任务。在其他实现中，特定虚拟仓库可以处理与特定数据存储系统或特定类别的数据相关联的数据存储和数据检索任务。

类似于上面讨论的虚拟仓库502，虚拟仓库504包括三个执行节点526、528和530。执行节点526包括高速缓存532和处理器534。执行节点528包括高速缓存536和处理器538。执行节点530包括高速缓存540和处理器542。另外，虚拟仓库506包括三个执行节点544、546和548。执行节点544包括高速缓存550和处理器552。执行节点546包括高速缓存554和处理器556。执行节点548包括高速缓存558和处理器560。

尽管图5所示的执行节点各自包括一个高速缓存和一个处理器，但是替代实施例可以包括包含任何数量的处理器和任何数量的高速缓存的执行节点。此外，高速缓存在不同的执行节点当中可能在大小上不同。图5所示的高速缓存在本地执行节点中存储从在存储平台314(见图3)中的一个或更多个数据存储设备检索的数据。因此，高速缓存减少或消除了在一贯地从远程存储系统检索数据的平台中出现的潜在瓶颈问题。不是重复地从远程存储设备访问数据，本文描述的系统和方法而是从在执行节点中的高速缓存访问数据，这明显更快并且避免了瓶颈问题。在一些实施例中，使用提供对所缓存的数据的快速访问的高速存储器设备来实现高速缓存。每个高速缓存可以存储来自在存储平台314中的任何存储设备的数据。

此外，高速缓存资源和计算资源可以在不同的执行节点之间有所不同。例如，一个执行节点可以包含相当多的计算资源和最少的高速缓存资源，使该执行节点对需要相当多的计算资源的任务有用。另一个执行节点可以包含相当多的缓存资源和最少的计算资源，使该执行节点对需要缓存大量数据的任务有用。在一些实施例中，当创建特定执行节点时，基于将由该执行节点执行的预期任务来确定与该执行节点相关联的高速缓存资源和计算资源。

此外，与特定执行节点相关联的高速缓存资源和计算资源可以基于由该执行节点执行的变化的任务随着时间的推移而改变。例如，如果由特定执行节点执行的任务变得更处理器密集的，则该执行节点可以被分配更多的处理资源。类似地，如果由执行节点执行的任务需要更大的高速缓存容量，则该执行节点可以被分配更多的高速缓存资源。

尽管虚拟仓库502、504、506与图3的相同执行平台312相关联，但是虚拟仓库可以使用在多个地理位置处的多个计算系统来实现。例如，虚拟仓库502可以由在第一地理位置处的计算系统实现，而虚拟仓库504和506由在第二地理位置处的另一计算系统实现。在一些实施例中，这些不同的计算系统是由一个或更多个不同实体维护的基于云的计算系统。

另外，在图5中每个虚拟仓库被示为具有多个执行节点。可以使用在多个地理位置处的多个计算系统来实现与每个虚拟仓库相关联的多个执行节点。例如，虚拟仓库502的特定实例在特定地理位置处的一个计算平台上实现执行节点508和510，并且在另一地理位置处的不同计算平台处实现执行节点512。选择特定计算系统来实现执行节点可以取决于各种因素，例如特定执行节点所需的资源的水平(例如，处理资源要求和高速缓存要求)、在特定计算系统处可用的资源、在地理位置内或在地理位置之间的网络的通信能力以及哪些计算系统已经实现在虚拟仓库中的其他执行节点。执行平台312也是容错的。例如，如果一个虚拟仓库失败，则快速地用在不同地理位置处的不同虚拟仓库替代该虚拟仓库。

特定的执行平台312可以包括任何数量的虚拟仓库502、504、506。此外，在特定执行平台中的虚拟仓库的数量是动态的，使得当需要额外的处理和/或缓存资源时新的虚拟仓库被创建。类似地，当与现有的虚拟仓库相关联的资源不再是必要的时，现有的虚拟仓库可以被删除。

图6是描绘操作环境600的实施例的框图，其中多个用户通过负载平衡器和在虚拟仓库组中包含的多个虚拟仓库来访问多个数据库。操作环境600可以应用于由用户或客户端执行的生产查询，并且还可以应用于特征测试，其中用户(见602、604、606)可以指使用实际数据库数据来生成和测试新特征或程序的开发者112。

环境600包括虚拟仓库资源管理器608和布置在虚拟仓库组616中的多个虚拟仓库610、612和614。虚拟仓库资源管理器608可以被包含在资源管理器302中。具体地，多个用户602、604和606通过虚拟仓库资源管理器608和虚拟仓库组616来访问多个数据库618、620、622、624、626和628。在一些实施例中，用户602-606通过资源管理器302(图1)来访问虚拟仓库资源管理器608。在一些实施例中，在资源管理器302内实现虚拟仓库资源管理器608。

用户602-606可以向虚拟仓库资源管理器608提交数据检索和数据存储请求，虚拟仓库资源管理器608将数据检索和数据存储请求路由到在虚拟仓库组616中的适当的虚拟仓库610-614。在一些实现中，虚拟仓库资源管理器608提供用户602-606到虚拟仓库610-614的动态分配。当提交数据检索或数据存储请求时，用户602-606可以指定虚拟仓库组616来处理该请求而不指定将处理该请求的特定虚拟仓库610-614。这种安排允许虚拟仓库资源管理器608基于效率、可用资源和在虚拟仓库610-614内的所缓存的数据的可用性来跨虚拟仓库610-614分配多个请求。在确定如何路由数据处理请求时，虚拟仓库资源管理器608考虑可用资源、当前资源负荷、当前用户的数量等。

在一些实施例中，容错系统响应于虚拟仓库的故障而创建新的虚拟仓库。新的虚拟仓库可以在同一虚拟仓库组中，或者可以在不同地理位置处的不同虚拟仓库组中被创建。

每个虚拟仓库610-614被配置成与所有数据库618-628的子集通信。例如，在环境600中，虚拟仓库610被配置成与数据库618、620和622通信。类似地，虚拟仓库612被配置成与数据库620、624和626通信。而且，虚拟仓库614被配置成与数据库622、626和628通信。在替代实施例中，虚拟仓库610-614可以与数据库618-628中的任何一个(或全部)通信。

尽管环境600示出了一个虚拟仓库组616，但是替代实施例可以包括任何数量的虚拟仓库组，每个虚拟仓库组与任何数量的虚拟仓库相关联。例如，可以为每个客户或用户组创建不同的虚拟仓库。此外，可以为不同的实体或访问不同数据集的任何其他组创建不同的虚拟仓库。多个虚拟仓库组可以具有不同的大小和配置。在特定环境中的虚拟仓库组的数量是动态的，且可以基于在该环境中的用户和其他系统的变化的需要而改变。

图7是用于测试在数据库上的特征的方法700的示意性流程图。方法700可以由任何合适的计算资源(例如如本文公开的资源管理器302或特征测试管理器428)执行。

方法700开始，计算资源在702确定包括将被重新运行用于测试特征的一个或更多个历史客户端查询的工作负荷，其中该特征包括过程逻辑。计算资源在704执行工作负荷的、不实现该特征的基线运行。计算资源在706执行工作负荷的、同时实现该特征的目标运行。计算资源在708比较基线运行和目标运行以识别在目标运行中是否存在性能退化。计算资源响应于识别出性能退化而在710重新运行目标运行，以识别性能退化是否仍然存在。在710的重新运行可以包括以更隔离的资源运行和/或运行多次以免遭受在基于云的数据库环境内的变化、和/或以更慢的速度运行。

可以执行方法700以在基于云的数据库系统中实现增量特征开发。可以通过快速发布周期与跟踪特征的使用的能力的组合来实现增量特征开发，该跟踪特征的使用的能力与比较在特征标志打开或关闭的情况下的运行的结果的能力组合。当在基于云的数据库系统中实现新特征时，方法700可以作为在线升级过程的一部分被自动执行。在一个实施例中，方法700可以与生产工作负荷的使用跟踪的方法组合。生产工作负荷的使用跟踪的方法可以集成在测试框架内，使得工作负荷选择可以基于期望的测试工作负荷来确定。

在一个实施例中，增量特征开发过程被部署在基于云的数据库系统中，该过程包括新编程逻辑或特征的快速在线升级、在测试框架内的使用跟踪集成以及可以在周期中组合以实现增量特征开发的性能验证。

图8是描绘示例计算设备800的框图。在一些实施例中，计算设备800用于实现本文讨论的系统和部件中的一个或更多个。例如，计算设备800可以允许用户或管理员访问资源管理器802。此外，计算设备800可以与本文描述的任何系统和部件进行交互。因此，计算设备800可以用于执行各种过程和任务，例如在本文中所讨论的那些过程和任务。计算设备800可以起服务器、客户端或任何其他计算实体的作用。计算设备800可以是各种各样的计算设备(例如台式计算机、笔记本计算机、服务器计算机、手持计算机、平板计算机等)中的任何一个。

计算设备800包括一个或更多个处理器802、一个或更多个存储器设备804、一个或更多个接口806、一个或更多个大容量存储设备808以及一个或更多个输入/输出(I/O)设备810，它们全部都耦合到总线812。处理器802包括执行在存储器设备804和/或大容量存储设备808中存储的指令的一个或更多个处理器或控制器。处理器802还可以包括各种类型的计算机可读介质，例如高速缓存存储器。

存储器设备804包括各种计算机可读介质，例如易失性存储器(例如随机存取存储器(RAM))和/或非易失性存储器(例如只读存储器(ROM))。存储器设备804还可以包括可重写ROM，例如快闪存储器。

大容量存储设备808包括各种计算机可读介质，例如磁带、磁盘、光盘、固态存储器(例如快闪存储器)等。在大容量存储设备808中还可以包括各种驱动器以使从各种计算机可读介质读取和/或写到各种计算机可读介质成为可能。大容量存储设备808包括可移动介质和/或不可移动介质。

I/O设备810包括允许数据和/或其他信息被输入到计算设备800或从计算设备800被检索的各种设备。示例I/O设备810包括光标控制设备、键盘、小键盘、麦克风、监视器或其他显示设备、扬声器、打印机、网络接口卡、调制解调器、透镜、CCD或其他图像捕获设备等。

接口806包括允许计算设备800与其他系统、设备或计算环境交互的各种接口。示例接口806包括任何数量的不同的网络接口，例如到局域网(LAN)、广域网(WAN)、无线网络和互联网的接口。

总线812允许处理器802、存储器设备804、接口806、大容量存储设备808和I/O设备810与彼此通信以及与耦合到总线812的其他设备或部件通信。总线812代表若干类型的总线结构(例如系统总线、PCI总线、IEEE 1394总线、USB总线等)中的一种或更多种。

为了说明的目的，程序和其他可执行程序部件在本文中被示为分立的块，但是应当理解，这样的程序和部件可以在不同时间驻留在计算设备800的不同存储部件中，并且由处理器802执行。替代地，在本文中描述的系统和过程可以以硬件、或硬件、软件和/或固件的组合来实现。例如，一个或更多个专用集成电路(ASIC)可被编程来执行本文所描述的系统和过程中的一个或更多个。如本文所使用的，术语“模块”意欲传达为了执行查询操作的全部或部分的目的用于例如通过硬件、或硬件、软件和/或固件的组合来完成过程的实现装置。

示例

以下示例涉及另外的实施例。

示例1是用于测试在数据库上的特征的系统。该系统包括用于确定包括将被重新运行用于测试该特征的一个或更多个历史客户端查询的工作负荷的装置，其中，该特征包括过程逻辑。该系统包括用于执行工作负荷的、不实现该特征的基线运行的装置。该系统包括用于执行工作负荷的、同时实现该特征的目标运行的装置。该系统包括用于比较基线运行和目标运行以识别在目标运行中是否存在性能退化的装置。该系统包括用于响应于识别出性能退化而重新运行目标运行以识别性能退化是否仍然存在的装置。

示例2是如在示例1中的系统，其中，用于确定工作负荷的装置被配置为基于包括由用户输入的一个或更多个参数的工作负荷选择配置来确定以滤除不需要的历史客户端查询，其中，该一个或更多个参数包括下列项中的一项或更多项：查询样本大小；查询发起者，例如请求历史客户端查询的帐户或用户；查询范式；数据库的表或微分区；已被请求和/或执行的历史查询的时间窗口；查询文本片段；或者查询执行配置。

示例3是如在示例1-2中的任一项中的系统，其中，用于确定工作负荷的装置被配置为：对满足工作负荷选择配置的历史客户端查询去重以确定历史客户端查询的分组；修剪历史客户端查询的分组以消除消耗大于阈值量的资源来执行的查询；以及选择历史客户端查询的所修剪的分组的子集以确定多样的样本，其中，所述选择包括应用Query2Vec算法来将历史客户端查询的所修剪的分组映射到高维向量空间。

示例4是如在示例1-3中的任一项中的系统，其中，基线运行的参数和目标运行的参数是相同的，除了在目标运行中存在特征以外。

示例5是如在示例1-4中的任一项中的系统，还包括用于响应于识别出当目标运行用剔除假阳性的技术重新运行时性能退化不再存在而将性能退化标记为假阳性的装置。

示例6是如在示例1-5中的任一项中的系统，其中，用于比较基线运行和目标运行的装置还被配置成识别包括下列项的一个或更多个错误：在目标运行中执行的一个或更多个历史客户端查询的错误结果；在目标运行中的内部错误；或者在目标运行中的用户错误。该系统使得用于重新运行目标运行的装置还被配置成识别该一个或更多个错误中的任何错误是否仍然存在。该系统使得用于将性能退化标记为假阳性的装置还被配置为响应于识别出当目标运行重新运行时该一个或更多个错误中的任何错误不再存在而将该一个或更多个错误中的任何错误标记为假阳性。

示例7是如在示例1-6中的任一项中的系统，还包括用于生成包括关于目标运行的数据的报告的装置，其中，该报告不包括被标记为假阳性的任何性能退化或错误的指示。

示例8是如在示例1-7中的任一项中的系统，还包括用于使基线运行和目标运行的结果模糊的装置，使得用户不能看到与工作负荷的一个或更多个历史客户端查询相关联的任何数据库数据。

示例9是如在示例1-8中的任一项中的系统，其中，用于执行基线运行的装置和用于执行目标运行的装置被配置为在专用于执行特征测试运行的、云数据库服务的专用虚拟仓库上执行。

示例10是如在示例1-9中的任一项中的系统，还包括用于确定当一个或更多个历史客户端查询中的历史客户端查询由客户端运行时存在的客户端的数据库数据的版本的装置，并且其中，用于执行基线运行的装置和用于执行目标运行的装置被配置为在当一个或更多个历史客户端查询中的历史客户端查询由客户端运行时存在的客户端的数据库数据的版本上执行。

示例11是用于测试在数据库上的特征的方法。该方法包括确定工作负荷，该工作负荷包括将被重新运行用于测试该特征的一个或更多个历史客户端查询，其中，该特征包括过程逻辑。该方法包括执行工作负荷的、不实现该特征的基线运行。该方法包括执行工作负荷的、同时实现该特征的目标运行。该方法包括比较基线运行和目标运行以识别在目标运行中是否存在性能退化。该方法包括响应于识别出性能退化而重新运行目标运行以识别性能退化是否仍然存在。

示例12是如在示例11中的方法，其中，确定工作负荷包括基于包括由用户输入的一个或更多个参数的工作负荷选择配置来确定以滤除不需要的历史客户端查询，其中，该一个或更多个参数包括下列项中的一项或更多项：查询样本大小；查询发起者，例如请求历史客户端查询的帐户或用户；查询范式；数据库的表或微分区；已被请求和/或执行的查询的时间窗口；查询文本片段；或者查询执行配置。

示例13是如在示例11-12中的任一项中的方法，其中，确定工作负荷包括：对满足工作负荷选择配置的历史客户端查询去重以确定历史客户端查询的分组；修剪历史客户端查询的分组以消除消耗大于阈值量的资源来执行的查询；以及选择历史客户端查询的所修剪的分组的子集以确定多样的样本，其中，所述选择包括应用Query2Vec算法来将历史客户端查询的所修剪的分组映射到高维向量空间。

示例14是如在示例11-13中的任一项中的方法，其中，基线运行的参数和目标运行的参数是相同的，除了在目标运行中存在特征以外。

示例15是如在示例11-14中的任一项中的方法，还包括响应于识别出当目标运行用剔除假阳性的技术重新运行时性能退化不再存在而将性能退化标记为假阳性。

示例16是可编程以执行存储在非暂时性计算机可读存储介质中的指令的处理器，所述指令包括：确定包括将被重新运行用于测试该特征的一个或更多个历史客户端查询的工作负荷，其中，该特征包括过程逻辑；执行工作负荷的、不实现该特征的基线运行；执行工作负荷的、同时实现该特征的目标运行；比较基线运行和目标运行以识别在目标运行中是否存在性能退化；以及响应于识别出性能退化，使用剔除假阳性的技术重新运行目标运行，以识别性能退化是否仍然存在。

示例17是如在示例16中的处理器，其中，确定工作负荷包括基于包括由用户输入的一个或更多个参数的工作负荷选择配置来确定以滤除不需要的历史客户端查询，其中，该一个或更多个参数包括下列项中的一项或更多项：查询样本大小；查询发起者，例如请求历史客户端查询的帐户或用户；查询范式；数据库的表或微分区；已被请求和/或执行的历史查询的时间窗口；查询文本片段；或者查询执行配置。

示例18是如在示例16-17中的任一项中的处理器，其中，确定工作负荷包括：对满足工作负荷选择配置的历史客户端查询去重以确定历史客户端查询的分组；修剪历史客户端查询的分组以消除消耗大于阈值量的资源来执行的查询；以及选择历史客户端查询的所修剪的分组的子集以确定多样的样本，其中，所述选择包括应用Query2Vec算法来将历史客户端查询的所修剪的分组映射到高维向量空间。

示例19是如在示例16-18中的任一项中的处理器，其中，所述指令还包括响应于识别出当目标运行重新运行时性能退化不再存在而将性能退化标记为假阳性。

示例20是如在示例16-19中的任一项中的处理器，其中，比较基线运行和目标运行还包括识别包括下列项的一个或更多个错误：在目标运行中执行的一个或更多个历史客户端查询的错误结果；在目标运行中的内部错误；或者在目标运行中的用户错误。所述指令使得所述指令还包括识别当目标运行重新运行时该一个或更多个错误中的任何错误是否仍然存在。所述指令使得所述指令还包括响应于识别出当目标运行重新运行时该一个或更多个错误中的任何错误不再存在而将该一个或更多个错误中的任何错误标记为假阳性。

Claims (20)

1.一种用于测试在数据库上的特征的系统，所述系统包括：

用于确定工作负荷的装置，所述工作负荷包括将被重新运行用于测试所述特征的一个或更多个历史客户端查询，其中，所述特征包括过程逻辑；

用于执行所述工作负荷的、不实现所述特征的基线运行的装置；

用于执行所述工作负荷的、同时实现所述特征的目标运行的装置；

用于比较所述基线运行和所述目标运行以识别在所述目标运行中是否存在性能退化的装置；以及

用于响应于识别出所述性能退化而重新运行所述目标运行以识别所述性能退化是否仍然存在的装置。

2.根据权利要求1所述的系统，其中，用于确定所述工作负荷的所述装置被配置为基于工作负荷选择配置来确定以滤除不需要的历史客户端查询，所述工作负荷选择配置包括由用户输入的一个或更多个参数，其中，所述一个或更多个参数包括下列项中的一项或更多项：

查询样本大小；

查询发起者，例如请求历史客户端查询的帐户或用户；

查询范式；

能够由查询访问的数据库的表或微分区；

已被请求和/或执行的历史查询的时间窗口；

查询文本片段；

查询执行配置；或

查询的执行时间。

3.根据权利要求2所述的系统，其中，用于确定所述工作负荷的所述装置被配置为：

对满足所述工作负荷选择配置的历史客户端查询去重以确定历史客户端查询的分组；

修剪历史客户端查询的所述分组以消除消耗大于阈值量的资源来执行的查询；以及

选择历史客户端查询的所修剪的分组的子集以确定多样的样本，其中，所述选择包括应用Query2Vec算法来将历史客户端查询的所修剪的分组映射到高维向量空间。

4.根据权利要求1所述的系统，其中，所述基线运行的参数和所述目标运行的参数是相同的，除了在所述目标运行中存在所述特征以外。

5.根据权利要求1所述的系统，其中，用于重新运行所述目标运行的所述装置被配置为使用单独的隔离资源以较低并发性来重新运行，以及其中，所述系统还包括用于响应于识别出当所述目标运行重新运行时所述性能退化不再存在而将所述性能退化标记为假阳性的装置。

6.根据权利要求5所述的系统，其中，用于比较所述基线运行和所述目标运行的所述装置还被配置成识别包括下列项的一个或更多个错误：

在所述目标运行中执行的一个或更多个历史客户端查询的错误结果；

在所述目标运行中的内部错误；或

在所述目标运行中的用户错误；以及

其中，用于重新运行所述目标运行的所述装置还被配置成识别所述一个或更多个错误中的任何错误是否仍然存在；以及

其中，用于将所述性能退化标记为假阳性的所述装置还被配置为响应于识别出当所述目标运行重新运行时所述一个或更多个错误中的任何错误不再存在，将所述一个或更多个错误中的任何错误标记为假阳性。

7.根据权利要求6所述的系统，还包括用于生成包括关于所述目标运行的数据的报告的装置，其中，所述报告不包括被标记为假阳性的任何性能退化或错误的指示。

8.根据权利要求1所述的系统，还包括用于使所述基线运行和所述目标运行的结果模糊的装置，使得用户不能看到与所述工作负荷的所述一个或更多个历史客户端查询相关联的任何数据库数据。

9.根据权利要求1所述的系统，其中，用于执行所述基线运行的所述装置和用于执行所述目标运行的所述装置被配置为在专用于执行特征测试运行的云数据库服务的专用虚拟仓库上执行。

10.根据权利要求1所述的系统，还包括用于确定当所述一个或更多个历史客户端查询中的历史客户端查询由客户端运行时存在的所述客户端的数据库数据的版本的装置，以及其中，用于执行所述基线运行的所述装置和用于执行所述目标运行的所述装置被配置为在当所述一个或更多个历史客户端查询中的所述历史客户端查询由所述客户端运行时存在的所述客户端的数据库数据的所述版本上执行。

11.一种用于测试在数据库上的特征的方法，所述方法包括：

确定包括将被重新运行用于测试所述特征的一个或更多个历史客户端查询的工作负荷，其中，所述特征包括过程逻辑；

执行所述工作负荷的、不实现所述特征的基线运行；

执行所述工作负荷的、同时实现所述特征的目标运行；

比较所述基线运行和所述目标运行以识别在所述目标运行中是否存在性能退化；以及

响应于识别出所述性能退化，重新运行所述目标运行以识别所述性能退化是否仍然存在。

12.根据权利要求11所述的方法，其中，确定所述工作负荷包括基于工作负荷选择配置来确定以滤除不需要的历史客户端查询，所述工作负荷选择配置包括由用户输入的一个或更多个参数，其中，所述一个或更多个参数包括下列项中的一项或更多项：

查询样本大小；

查询发起者，例如请求历史客户端查询的帐户或用户；

查询范式；

数据库的表或微分区；

已被请求和/或执行的历史查询的时间窗口；

查询文本片段；或

查询执行配置。

13.根据权利要求12所述的方法，其中，确定所述工作负荷包括：

对满足所述工作负荷选择配置的历史客户端查询去重以确定历史客户端查询的分组；

修剪历史客户端查询的所述分组以消除消耗大于阈值量的资源来执行的查询；以及

选择历史客户端查询的所修剪的分组的子集以确定多样的样本，其中,所述选择包括应用Query2Vec算法来将历史客户端查询的所修剪的分组映射到高维向量空间。

14.根据权利要求11所述的方法，其中，所述基线运行的参数和所述目标运行的参数是相同的，除了在所述目标运行中存在所述特征以外。

15.根据权利要求11所述的方法，还包括响应于识别出当所述目标运行重新运行时所述性能退化不再存在，将所述性能退化标记为假阳性。

16.一种处理器，其可编程以执行存储在非暂时性计算机可读存储介质中的指令，所述指令包括：

确定包括将被重新运行用于测试所述特征的一个或更多个历史客户端查询的工作负荷，其中，所述特征包括过程逻辑；

执行所述工作负荷的、不实现所述特征的基线运行；

执行所述工作负荷的、同时实现所述特征的目标运行；

比较所述基线运行和所述目标运行以识别在所述目标运行中是否存在性能退化；以及

响应于识别出所述性能退化，重新运行所述目标运行以识别所述性能退化是否仍然存在。

17.根据权利要求16所述的处理器，其中，确定所述工作负荷包括基于工作负荷选择配置来确定以滤除不需要的历史客户端查询，所述工作负荷选择配置包括由用户输入的一个或更多个参数，其中，所述一个或更多个参数包括下列项中的一项或更多项：

查询样本大小；

查询发起者，例如请求历史客户端查询的帐户或用户；

查询范式；

数据库的表或微分区；

已被请求和/或执行的历史查询的时间窗口；

查询文本片段；或

查询执行配置。

18.根据权利要求17所述的处理器，其中，确定所述工作负荷包括：

对满足所述工作负荷选择配置的历史客户端查询去重以确定历史客户端查询的分组；

修剪历史客户端查询的所述分组以消除消耗大于阈值量的资源来执行的查询；以及

选择历史客户端查询的所修剪的分组的子集以确定多样的样本，其中，所述选择包括应用Query2Vec算法来将历史客户端查询的所修剪的分组映射到高维向量空间。

19.根据权利要求16所述的处理器，其中，所述指令还包括响应于识别出当所述目标运行重新运行时所述性能退化不再存在，将所述性能退化标记为假阳性。

20.根据权利要求19所述的处理器，其中，比较所述基线运行和所述目标运行还包括识别包括下列项的一个或更多个错误：

在所述目标运行中执行的一个或更多个历史客户端查询的错误结果；

在所述目标运行中的内部错误；或

在所述目标运行中的用户错误；以及

其中，所述指令还包括识别当所述目标运行重新运行时所述一个或更多个错误中的任何错误是否仍然存在；以及

其中，所述指令还包括响应于识别出当所述目标运行重新运行时所述一个或更多个错误中的任何错误不再存在，将所述一个或更多个错误中的任何错误标记为假阳性。

Images