CN107851106A

CN107851106A - 用于关系数据库即服务的自动需求驱动的资源缩放

Info

Publication number: CN107851106A
Application number: CN201680025422.1A
Authority: CN
Inventors: S·达斯; 李峰; V·纳拉萨亚; A·C·柯尼格
Original assignee: Microsoft Technology Licensing LLC
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2015-05-01
Filing date: 2016-04-07
Publication date: 2018-03-27
Anticipated expiration: 2036-04-07
Also published as: US11113647B2; EP3805940B1; US20190325370A1; WO2016178781A1; US10410155B2; EP3289485B1; US20160321588A1; EP3289485A1; EP3805940A1; CN107851106B

Abstract

一种使得数据库即服务(DaaS)能够代表租户自动缩放容器大小的架构。提供了一种抽象，其使得租户能够推理货币预算和查询延迟，而不是资源提供。例如，自动缩放模块基于包括延迟(例如，等待)、资源利用率和可用预算的遥测来自动确定针对后续计费间隔的容器大小。一组鲁棒的信号从数据库引擎遥测被得出，并且被结合以显著提高针对数据库工作负载的资源需求估计的准确度。在更具体的实现中，可以对于关系数据库管理系统(RDBMS)中的任意SQL(结构化查询语言)工作负载估计资源需求。

Description

用于关系数据库即服务的自动需求驱动的资源缩放

背景技术

关系数据库即服务(DaaS)平台支持资源容器的抽象，资源容器保证固定量的资源(例如，两个虚拟核、4GB的存储器、100个盘IOPS和1TB的盘空间)和每个计费间隔的成本(例如，每小时50美分)。租户负责选择适合工作负载的容器大小。为了利用云弹性，DaaS平台租户必须估计并且手动改变数据库容器大小。租户对于在计费间隔内使用的最大容器大小被计费，并且支付针对每个计费间隔的费用总和。

由于无法测量资源需求，所以问题是估计针对数据库工作负载的需求。然而，由于数据库引擎的复杂性以及多个资源如何交互而产生了挑战。例如，如果所提供的负载增加，则并不一定表示添加更多资源将显著改善查询延迟，特别是在查询主要等待共享数据项上的锁的情况下。类似地，由于可以高速缓存更多的数据，所以添加更多存储器可能会减少对I/O(输入/输出)的需求并且增加CPU(中央处理器)需求。此外，当容器大小在资源和成本中显著变化时，针对不正确的需求估计的惩罚可能很高——其在需求被低估的情况下导致性能不佳或者在需求被高估的情况下导致更高的货币成本。更进一步地，DaaS的大多数租户无法雇用具有关于是否以及何时缩放资源做出明智的决定的必要的专业知识的富有经验的数据库管理员。

发明内容

以下呈现简化的概述，以便提供对本文中描述的一些新颖实现的基本理解。该概述不是广泛的概括，并且它不是旨在确定关键/重要要素也不是旨在界定其范围。其唯一目的是以简化的形式呈现一些概念作为稍后呈现的更详细描述的序言。

所公开的架构提供了在数据库即服务(DaaS)中的使得能够代表租户来自动缩放容器大小的能力。该架构提供了一种抽象，其使得租户能够推理货币预算和查询延迟，而不是资源提供。自动缩放模块基于来自不久之前的计费间隔中的可用预算、观察延迟和资源利用率来自动确定针对后续计费间隔的容器大小。自动缩放模块的一方面是用于从可测量的数据库引擎遥测(诸如资源利用率、等待资源等)(例如，由数据库服务器或DaaS报告的计数器和统计信息)来估计资源需求的能力。

一组信号从数据库引擎遥测被得出并且被组合以显著提高针对数据库工作负载的需求估计的准确度。在更具体的实现中，可以对于关系数据库管理系统(RDBMS)中的任意SQL(结构化查询语言)工作负载估计资源需求。

更具体地，提供了一种抽象，其使得DaaS服务提供商能够代表租户支持容器资源的自动缩放。租户可以规定用于管理自动缩放逻辑的行为的输入。输入可以是延迟目标、货币预算、粗粒度性能灵敏度等形式。这些输入使得租户能够控制货币成本。服务提供商的责任是自动缩放单个容器的大小，即调节被分配给托管租户数据库的单个容器的资源。这不同于针对虚拟机(VM)的一些现有解决方案(其例如基于用户规定的阈值从集群中添加或去除VM)。相反，所公开的架构对同一容器进行重新大小调整。此外，用户不需要提供用于容器重新大小调整的规则，这也由所公开的架构自动管理。

提供了一种技术，其提高了对各种工作负载(例如，SQL)的资源需求的估计准确度，而没有任何工作负载的先验知识。还提供了一种技术，其用于从关系DaaS的生产遥测来标识一组统计生成的信号。提供了一种决策逻辑，其组合多个信号以提高资源需求估计的准确度。

在关系DaaS中利用抽象和改进的资源需求估计为代表租户的自动化需求驱动的资源缩放提供了端到端的解决方案。

所公开的架构可以被实现为一种数据库即服务系统，其包括：被配置为基于来自数据库服务器的遥测来自动计算针对后续计费间隔的数据库服务器中的容器的大小的自动缩放模块；以及被配置为执行存储器中的计算机可执行指令的至少一个硬件处理器，指令被执行以使能自动缩放模块。

所公开的架构可以被实现为数据库即服务方法，其包括以下动作：基于生产遥测来估计针对数据库的容器的资源需求；以及基于所估计的资源需求的变化来代表租户自动缩放针对计费间隔的容器的容器大小。

所公开的架构可以被实现为一种数据库即服务系统，其包括：用于基于生产遥测来估计针对数据库的容器的资源需求的装置；以及用于基于所估计的资源需求的变化来代表租户自动缩放针对计费间隔的容器的容器大小的装置。

为了实现前述和相关目的，本文中结合以下描述和附图描述某些说明性方面。这些方面指示可以实践本文中公开的原理的各种方式，并且其所有方面和等同物旨在在要求保护的主题的范围内。当结合附图考虑时，从以下详细描述中，其他优点和新颖特征将变得显而易见。

附图说明

图1示出了根据所公开的架构的数据库即服务(DaaS)系统。

图2示出了示出容器大小可以在每个资源维度中或对于所有资源以锁定步进独立地缩放的图表。

图3示出了当使用针对粗粒度性能灵敏度的离散步进时DaaS中的自动缩放抽象。

图4示出了支持资源的自动缩放的DaaS服务的简化架构。

图5示出了用于预算分配的令牌桶算法。

图6示出了根据所公开的架构的方法。

图7示出了根据所公开的架构的备选方法。

图8示出了根据所公开的架构的备选方法。

图9示出了根据所公开的架构的执行DaaS中的自动化需求驱动的资源缩放的计算系统的框图。

具体实施方式

很多企业在数据库即服务(DaaS)环境中部署关键任务数据库。DaaS提供弹性、按使用付费和高可用性。由于DaaS环境是多租户的，因此通过资源隔离的性能可预测性是针对这样的关键任务数据库的要求。商业DaaS产品现在通过逻辑或物理容器来支持资源隔离。容器可以是专用于租户数据库或逻辑容器(例如，SQL数据库)的虚拟机(VM)。不管支持的特定容器抽象，每个容器都保证一组固定资源(这组固定资源称为容器大小)。

关系DaaS平台支持资源容器的抽象，其保证固定量的资源。也就是说，资源容器的设计不弹性。用于DaaS平台支持弹性的一种方法是允许租户随着时间而改变针对租户数据库的容器大小。例如，如果存在散布有低负载时段的高负载时段，则可以在高负载时段期间手动提供较大的容器大小，从而提供更好的性能，而可以在低负载时段期间手动提供较小的容器大小，导致成本节省。

为了从云弹性中受益，租户必须确定何时缩放容器大小。应用无关的方法依赖于资源利用率作为用于缩放决策的主要驱动力。例如，如果资源利用率高(例如，每秒100个I/O操作(IOPS)的当前容器中的80％的I/O(输入/输出)利用率)，则放大容器；类似地，资源利用率低表示缩小。然而，高资源利用率并不一定与对更多资源的需求相对应。当容器大小在资源和成本中显著变化时，针对不正确的需求估计的惩罚在需求被低估的情况下可能是性能不佳并且在需求被高估的情况下可能是更高的货币成本。

所公开的架构使得DaaS能够代表租户自动缩放容器大小(自动地)。在更具体的实现中，可以对于关系数据库管理系统(RDBMS)中的任意SQL(结构化查询语言)工作负载估计资源需求。该架构侧重于自动缩放的“放大(scale-up)”形式，其中单个容器的大小随着时间而改变。这不同于一些现有的自动缩放技术的“横向缩放(scale-out)”方法，这些技术改变容器(例如，VM)的数目。随着容器数目的变化，“横向缩放”方法重新划分工作负载。“放大”方法在DaaS环境中被支持，并且使得单个服务器中包含的数据库能够利用弹性而不划分数据库。

所公开的架构提供了一种抽象，其使得租户能够推理货币预算和查询延迟而不是资源提供，并且利用租户工作负载的通用遥测和执行特性，其可用于所有租户并且不需要租户特定的人类输入。例如，资源等待(其是租户请求等待逻辑或物理资源的时间量)是信号，因为针对资源的大量等待可能表示工作负载将从附加资源中受益。

所公开的架构的一个方面是一种用于自动估计数据库的资源需求并且相应地缩放(放大或缩小)分配给数据库的容器大小的模型。可以从数据库引擎遥测(被称为生产遥测)得出一组统计上鲁棒的信号(为期望目的提供改进的性能和整体准确度的信号)，并且可以组合这些信号以显著提高针对数据库工作负载的需求估计的准确度。获得可以容忍噪声的信号，该噪声在系统遥测中是不可避免的。此外，数据库引擎内部的领域知识用于系统地设计决策逻辑以组合多个信号以大大减少高(或低)需求的不准确估计的数目。

直观地，如果存在对资源的高需求的多个弱信号(诸如利用和等待)，则这增加了需求实际上为高的可能性。此外，DaaS平台可以观察到具有非常不同的工作负载和资源需求的大量租户的遥测的这一事实使得能够分析服务范围的遥测以改善需求估计逻辑(例如，以确定针对输入信号的有意义和合适的阈值)。

此外，租户可以规定针对相关联的租户应用的延迟目标。这些目标可以用于进一步降低成本。如果延迟目标满足，则可以分配较小的容器，即使需要较大的容器。此外，在由于资源以外的问题(诸如编写不良的应用代码)而导致延迟目标可能无法满足的情况下，只有在存在资源需求的情况下才可以增加容器大小，即使在延迟目标不满足的情况下。(注意，租户不需要规定吞吐量目标)。当所提供的负载增加时，未满足的资源需求和查询延迟为自动缩放逻辑提供反馈。该功能通过使得租户能够推理预算和查询延迟而不是资源提供来提升DaaS的抽象。

除了估计资源需求之外，端到端的自动缩放解决方案必须满足很多实际的挑战。所公开的架构实施在线预算分配策略，其允许高资源需求时段(其中预算以高于平均速率的速率被消耗)，同时确保总成本不超过预算。

所公开的架构表现出改进的可用性的技术效果。也就是说，租户不再需要参与针对工作负载的人工容器大小调整，因为这现在可以代表租户自动实现。此外，所公开的架构通过自动实现由租户施加的预算要求来表现出提高的可靠性的技术效果。此外，所公开的架构表现出减少的人为错误的技术效果，因为现在对于租户自动地和在算法上处理自动缩放，并且所公开的架构还表现出在估计高需求时的减少的误差的技术效果。此外，所公开的架构通过更有效地管理针对租户工作负载的存储器分配来表现出数据库服务器场中的存储器保护的技术效果。另一技术效果是通常在数据库服务器上或跨多个服务器的改进的资源分配。

现在参考附图，其中相同的附图标记始终用于指代相同的元件。在下面的描述中，为了解释的目的，阐述了很多具体细节以便提供其透彻的理解。然而，显而易见的是，可以在没有这些具体细节的情况下实践新颖的实现。在其他情况下，以框图形式示出了众所周知的结构和设备，以便支持其描述。本发明在于涵盖落入所要求保护的主题的精神和范围内的所有修改、等同物和替代物。

图1示出了根据所公开的架构的数据库即服务(DaaS)系统100。系统100可以包括被配置为自动确定数据库服务器106中的容器104的容器大小的自动缩放模块102。可以基于来自数据库服务器106的遥测108来确定针对后续计费间隔的容器大小。遥测108可以包括延迟110、资源利用率112和可用预算114。

如下面更详细地并且与其他附图相关联地描述的，自动缩放模块102还可以包括被配置为收集数据库服务器106的租户数据库的遥测108的遥测管理器、和被配置为估计保证较大容器或较小容器的资源需求的资源需求估计器。资源需求估计器可以被配置为将遥测转变成用于估计数据库服务器106的多个工作负载的资源需求的信号。此外，资源需求估计器可以被配置为基于规则的逻辑，基于规则的逻辑对于每个信号具有用于关于每个信号确定租户状态的一个或多个阈值。

自动缩放模块102还可以包括预算管理器，预算管理器被配置为基于预算输入准则来计算针对小于预算时段的每个计费间隔的可用预算。自动缩放模块102还可以包括自动缩放逻辑，自动缩放逻辑被配置为基于原始信号和得出信号(遥测)、可用预算和需求估计的组合来向数据库管理构造输出容器大小调整动作。

图2示出了图表200，其示出了可以在每个资源维度中或对于所有资源以锁定步进独立地缩放容器大小。作为示例，图表200示出了使用两个资源维度(CPU和盘I/O)来缩放容器大小，尽管资源容器可以包括很多附加的资源维度，诸如存储器、网络带宽、和并行线程数。容器大小(S,M,L,…)以相同的比例缩放CPU(在x轴上)和盘I/O(在y轴上)。也就是说，与S相比，对于CPU和盘I/O，M具有2×(倍)的分配，并且L具有3×的分配。S,M_C,L_C,…(针对CPU的C下标)和S,M_D,L_D,…(针对盘I/O的D下标)分别表示沿着CPU和盘I/O维度的容器缩放。例如，在一些现有的DaaS实现中的标准层级按比例地增加资源，而高存储器、高CPU和高I/O实例沿着特定维度缩放资源。如果能够在每个维度上独立地缩放容器，则在一个资源维度中具有需求的工作负载就可以受益。

虽然租户推理用于租户工作负载的资源需求有挑战性，但是租户更容易涉及应用级别的延迟目标和货币约束，诸如针对数据库的每月预算。基于需求的资源自动缩放使得租户能够涉及延迟目标和货币约束。

原则上，自动缩放逻辑可以仅基于需要自动缩放容器大小。然而，客户(也称为租户)可能想要“旋钮”(用户可配置的调节)，其使得能够为客户数据库定制这个自动化逻辑的行为。如前所述，DaaS平台托管各种租户，从具有适度延迟要求的小部门应用到需要交互式查询延迟的行业应用。虽然仅基于需求进行缩放可能对性能关键的应用来说是可取的，但是对于有预算意识的租户来说可能不是成本有效的。因此，所公开的架构提供了一组旋钮，租户可以选择地设置这组旋钮以控制自动缩放逻辑的成本和行为。

关于预算，很多租户对其数据库具有运营预算。这样的租户可以规定针对更长时间段(被称为预算时段，例如一个月)的预算。预算可以被建模为硬约束。当规定预算时，所公开的自动缩放逻辑选择足以满足资源需求并且具有比可用预算少的成本的最小容器。如果预算不受约束，则仅基于需要来选择容器。注意，备选方案是将预算建模为软约束，使得针对预算时段的容器的成本的总和可能超过预算但是仍然在可配置的阈值内。

关于延迟目标，很多应用具有针对数据库后端的延迟目标。这样的租户可以提供针对平均或第95百分位数的延迟的目标。延迟目标使得自动缩放逻辑能够提供足以实现延迟目标的资源，从而在资源需求需要更大的容器大小，但是可以使用更小的容器大小来实现延迟目标时降低成本。例如，涉及交互式用户活动的应用可以规定一百毫秒(ms)的第95百分位数的延迟。另一方面，小部门web应用可以通过一千毫秒的平均延迟来满足，从而在可以通过较小的容器来满足延迟目标的情况下可能降低成本。如前所述，应用的延迟目标可能由于除了资源之外的问题(诸如编写不良的应用代码)而不能满足。因此，延迟目标不是性能的保证，而是用于控制成本的旋钮。

关于粗粒度性能灵敏度，对于没有精确延迟目标的租户，粗粒度旋钮指示针对给定应用的延迟灵敏度。该旋钮可以是连续值(例如，在0到1之间)。然而，为了方便，可以提供一小组离散步进，诸如：HIGH(高)、MEDIUM(中)和LOW(低)，默认值被设置为MEDIUM。直观地说，对于具有LOW灵敏度的租户，自动缩放逻辑在放大方面比对具有HIGH灵敏度的租户更不积极(并且在缩小更积极)，因此可能降低成本。

由所公开的自动缩放抽象支持的输入也可以被扩展到包括客户规定的最小和最大容器大小或者用于选择某些容器大小的调度。例如，假定容量大小以大小和成本增加的顺序为XS(超小，其小于S)、S(小)、M(中)、L(大)和XL(超大，其大于L)，客户可以将最小容器大小规定为S，并且将最大容器大小规定为L。该输入约束自动缩放逻辑，因此逻辑从不选择容器XS和XL。类似地，客户可以规定调度，诸如：星期一上午9点到中午12点(选择M)；每天中午12点到下午5点(选择L)；和其他时间，例如，自动选择容器大小。

图3示出了当使用针对粗粒度性能灵敏度的离散步进时DaaS中的自动缩放抽象300。自动缩放模块102接收变化遥测302和其他输入304(诸如成本预算、容器大小范围、性能目标、灵敏度等)作为输入。自动缩放模块102的输出306因此可以包括例如根据MEDIUM、SMALL和LARGE的离散步进308随着时间的缩放动作、缩放说明等。

图4示出了支持资源的自动缩放的DaaS服务400的简化架构。服务400提高了针对由DaaS服务400服务的各种工作负载(例如，SQL)的资源需求估计的准确度。

服务400包括托管租户数据库并且服务于请求的服务器404的集合。(图4未示出服务300的其他部件，例如诸如管理服务器、网关和负载平衡器)。服务400中的(服务器404的)每个数据库服务器托管一组容器(类似于图1的容器104)，每个租户数据库一个容器。在(服务器404中的)服务器处的特定容器的共同位置由服务400的管理构造406确定。另外，DaaS服务400收集针对每个容器的详细计数器(被称为生产遥测)。

自动缩放模块102包括至少三个主要部件(在右侧以放大图示出)：遥测管理器408，其收集针对每个租户数据库的原始遥测，并且从遥测中的数百个计数器中选择计数器的子集以用作用于估计需求的信号；资源需求估计器410，其使用来自遥测管理器408的原始信号和得出信号来估计针对包含容器的资源中的每个资源的需求；以及预算管理器412，其将针对预算时段的预算明智地转换为针对为其选择容器的每个计费间隔的预算。

所公开的架构包括“在线”技术(即，不知道未来工作负载模式的技术)，其为每个计费间隔分配满足资源需求中的突发的足够的预算，同时确保针对较长预算时段的预算约束。自动缩放逻辑414组合三个部件(遥测管理器408、资源需求估计器410和预算管理器412)的输出以将原始遥测和高级租户规定的(延迟输入和预算输入的)旋钮转变成由DaaS支持的容器大小调整操作，同时随着时变的资源需求而动态地缩放容器大小。

更具体地，关于遥测管理器408，成熟的DBMS(数据库管理系统)监测和报告包括生产遥测的数百个计数器。遥测管理器408将该原始遥测转变成可以用于以高的准确度来估计各种工作负载的资源需求的信号。

首先，标识一小组计数器。数据库引擎领域的知识被用于标识相关信号。第二，由于工作负载中的固有变化和突发性、诸如检查点与工作负载交互等的瞬态系统活动，遥测中可能存在大量的“噪声”。诸如平均值的简单统计度量可以容易地被几个很大的异常值“主导”。因此，作为一般规则，使用对异常值鲁棒(基本上免疫)的统计学度量。对异常值的鲁棒性使用估计器的故障点的概念来定义。直观地，估计器的故障点是在给出不正确结果之前估计器可以处理的不正确观察值(例如，任意大的偏差)的百分比。

示例“故障点”：给定m个独立变量和相关联的实现x₁，...，x_m，使用用于估计平均值。然而，该估计器的故障点为零，因为可以通过改变任何一个x_i来变为任意大。相比之下，分布的中间值的故障点为50％，这是可能的最高故障点。

例如，来自数据库服务器404的遥测的信号可以包括延迟、资源利用率和等待统计。从遥测获得的一些信号是从原始遥测获得的计数器上的鲁棒聚合，而其他信号是在计数器上得出的鲁棒的统计度量。

关于延迟，数据库服务器404对于为租户完成的每个请求跟踪延迟。延迟可以被聚合到在延迟目标中规定的百分位数或平均值。在资源利用率方面，资源利用率是租户的工作负载目前使用的资源为多少的度量，并且是针对资源需求的信号。数据库服务器报告针对每个租户的关键资源(诸如CPU、存储器和盘I/O)的利用率。例如，遥测管理器408以精细粒度(诸如每几秒钟一次)收集这些值，并且在不同的时间粒度(从几分钟到几小时)上计算鲁棒的统计度量，诸如中间值，其包括利用率信号。

关于等待统计，资源利用率提供工作负载是否需要更多的资源的很少的信息。相比之下，如果租户的请求等待具体资源，这表示租户对该资源的需求未满足。大多数成熟的DBMS跟踪租户的请求在数据库服务器中等待所花费的时间量。遥测管理器408跟踪等待时间的大小和百分比等待(即等待资源所花费的时间作为针对一时间间隔的总等待的百分比)。遥测管理器408暴露这些原始等待统计数据的鲁棒聚合作为针对需求估计的信号。注意，大小和百分比等待都可以用于需求估计。例如，可能观察到较大的CPU等待值。然而，如果CPU等待与由于获取应用级锁的等待相比是微不足道的，则即使可能需要更多的CPU，添加更多CPU也不太可能显著改善延迟。类似地，CPU等待可能包含100％的等待。但是，如果大小很小，则对CPU的需求可能不高。

DBMS可以报告被分类为遥测管理器408收集的不同等待类型的等待统计信息。每个等待类型可以与请求等待的(逻辑或物理)资源相关联。使用这些映射规则，可以将等待时间映射到资源，以确定租户的请求等待该资源的总时间。等待可以被分类为用于关键的物理和逻辑资源的广泛类集合：CPU、存储器、盘I/O、日志I/O、锁和系统。例如，DBMS(例如，SQL服务器)可以将工作负载的等待时间分类为多于三百种等待类型。每个等待类型都可以与资源相关联。例如，信号等待时间是线程被发信号通知并且准备好使用CPU的时间到线程实际被分配CPU的时间，并且因此包括CPU等待。

除了(聚合的)“原始”遥测信息之外，还分析延迟中的趋势、资源利用率等、以及信号之间的相关性，诸如具有性能的资源等待。相关性和趋势都可以被跟踪用于不同的目的。趋势标识随着时间的特定度量(例如，资源等待)的变化，其使得能够及早地标识工作负载或其资源需求的变化。对于趋势，趋势的绝对值是重要的(即，增长是快速的相对增长是缓慢的)。相关性表征两个信号(例如，CPU等待和延迟)之间的依赖性。大的相关值有助于标识针对给定工作负载的一个或多个主要瓶颈，而不管这些计数器随着时间总体增加还是减少。如果租户关心尾延迟(诸如第95百分位数)，则这些信号特别有用，因为尾延迟对未满足的需求反应更快。

关于标识随着时间的趋势，所使用的第一类得出信号可以是随着时间的被监测的计数器的子集(诸如延迟、资源利用率、或等待)中的趋势。例如，如果近期历史上有一个趋势是延迟随着时间而劣化，则这可能是一个早期的信号，即延迟目标在不久的将来会被破坏。类似地，与特定资源相关联的等待时间的随着时间的增加趋势可以指示未满足的资源需求。鉴于资源缩放动作的即时时间尺度，重点可以是检测具有充分置信度的短期趋势。因此，与更适合于长期趋势的非线性或时间序列模型相比，简单而鲁棒的线性模型是足够的。

检测趋势中的挑战是在其上计算趋势的基础数据中的噪声。数据本身可能固有地有噪声，并且可能没有统计上显著的趋势，在这种情况下，趋势必须被忽略。此外，趋势度量对于异常值(远离集群的数据点)应当是鲁棒的。

在解决噪声数据问题的一个实现中，Theil-Sen估计器可以被用于趋势线的鲁棒检测。给定n个元组〈X，Y〉，Thiel-Sen估计器计算通过每对元组(x_i，y_i)和(x_i，y_i)的线的斜率为并且使用中间值m_i作为趋势线的斜率。虽然存在具有更高故障点的估计器，但是Theil-Sen估计器具有简单、高效的计算并且不需要附加的调节参数的优点。

O(n²)斜率可以由估计器以两种方式计算地使用。首先，中间值是数据中任何现有趋势的斜率。第二，这组斜率可以用来测试数据中显著趋势的存在。也就是说，如果(非噪声)数据点中确实存在(线性)趋势，则这表示它们之间的(绝大多数)斜率具有相同的符号。因此，趋势仅在至少α％的斜率为正或α％斜率为负的情况下“被接受”。在一个实现中，可以使用α＝70。

关于检测相关性，如果存在对超过分配的资源的需求，使资源成为瓶颈，则在该事件之前的时间间隔中，通常会增加该资源的利用率、或与该资源相关联的等待时间、或两者。劣化延迟与资源利用率和/或等待计数器之间的强相关性指示资源中的需求，如果满足，则可以显著改善延迟。因此，该相关性度量可以用作附加信号。

在一个实现中，可以使用被表示为ρ的Spearman秩系数作为相关性度量。Spearman的秩相关性是两个分等级的数据集的秩或顺序的相关性的统计量度，其评估使用单调函数描述两个变量之间的关系的效果可以如何。也就是说，对于检测它的Spearman系数的依赖性不一定是线性的，这使得它是适合的，因为对于任意的数据库应用，利用率、等待和延迟的相关性通常是非线性的。

给定两个分等级的数据集X和Y，ρ被计算为x和y值的秩上的Pearson系数。ρ的值在-1到1之间；ρ＝1表示完全相关，ρ＝-1表示完美的负相关，并且ρ＝0表示两个顺序之间没有相关性。使用Spearman系数的副作用是，由于数据噪声导致的异常值变得不太是问题，因为每个值首先被映射到秩空间，这限制了异常值可以偏离平均值的程度。

关于资源需求估计器，从遥测管理器408获得的每个信号可以是对资源需求的弱预测，并且因此可以不被隔离地用于以高准确度估计需求。因此，可以组合这些信号以提高需求估计的准确度。如果多个弱预测信号预测对资源的高需求，则需求实际上为高的可能性增加。

一种方法是使用统计学习技术来使用从生产遥测获得的训练数据来推断模型。例如，机器学习技术可以被用于从输入信号估计资源需求。例如，机器学习技术对仔细选择特征、学习者和训练数据可能是有用的。

另一种方法是使用数据库引擎内部的领域知识以及不同的资源如何交互的领域知识来组合这些信号。采用决策逻辑，其包括手动构造的规则层级，其使用多个信号来确定租户的工作负载的资源需求。基于规则的逻辑对于每个信号采用用于隔离地关于每个信号确定租户的状态的一组阈值。每个规则结合从每个信号获得的状态以确定总体资源需求。通过遍历这种规则层级，如果需求很高，则逻辑决定添加更多的资源(即放大)，如果需求很低，则逻辑取走未使用的资源(即缩小)。

回想一下，给定离散的容器大小，并且在任何时刻，租户与容器大小相关联，问题是估计是否需要更大的容器，或者需求可以通过更小的容器来满足。在估计需求时，在每个资源维度中，确定需要增加(或减少)多少容器大小的步进。通过这个过程，可以跨数以千计的租户使用生产遥测作为指导。通过将容器大小分配给租户的资源利用率值，可以观察到，由于资源需求变化而导致的容器大小变化事件总数中，90％导致容器大小变化1个步进，并且步进大小1和2一起包括98％的变化。因此，估计需求可能被约束为将容器大小改变0(无变化)、1或2个步进。

这种基于规则的方法有几个实际的好处。首先，当跨各种非常不同的工作负载进行测试时，发现它是鲁棒的。第二，一旦将阈值应用于信号，信号将从连续值域转变到分类值域，分类值域中每个类别具有易于理解的语义。这使得规则更容易构造、调试、维护、扩展和解释。例如，使用具有明确定义的语义的类别允许自动缩放逻辑提供其动作的“解释”。这些解释为(通常不富有经验)的终端用户提供用于缩放操作的简单推理。容器大小调整决定是由分析数十个信号导致的。然而，该模型对于每个路径遍历具有良好理解的语义的规则层级。说明是简要说明推荐容器大小时模型遍历的路径。例如，如果模型标识CPU瓶颈，其进而放大容器大小，则生成“由于CPU瓶颈导致的放大”形式的说明。如果模型推荐放大，但是预算约束不允许，则模型可以生成“放大被预算约束”形式的说明。对于专家管理员，模型还暴露了原始遥测以及用于支持详细诊断的信号。此外，由于人们可以容易地理解规则，所以规则也可以容易地可扩展，以考虑更多的信号组合以使得模型更加鲁棒并且提高准确度。

资源需求估计可以包括以下步骤：确定针对每个信号的阈值和利用来自DaaS的生产遥测用于确定这些阈值、以及用于检测高和低需求的一些示例规则。

关于确定阈值，模型理解(知识)包括如何确定阈值以及如何为每个信号设置阈值的说明。阈值将连续信号值转变为具有良好理解的语义的类别。这种分类主要是为了易于理解和阐述，并且对于模型来说不是根本的，尽管基础阈值是规则固有的。

设置针对延迟和资源利用率的阈值可以是简单的。如果租户规定了延迟目标，则其成为用于确定延迟是否GOOD(好)(即，满足目标)与延迟是否为BAD(坏)(即，不满足目标)的阈值。类似地，对于DaaS平台利用的基础数据库引擎，已经存在众所周知的阈值和规则，系统管理员使用其将资源利用率分类为LOW、MEDIUM和HIGH。

有益的是，使用系统方法以用于设置针对等待统计数据的阈值以便这些类别是有意义的。跨服务从数千个真实租户数据库收集的生产遥测可以被用于确定这些阈值。原理在于，如果资源需求很高，则针对该资源的等待也会很高。为了解决偶然噪声，通过分析来自数千个租户的数据，可以明显区分针对低需求和高需求利用率的等待分布。

来自这些分布的百分位数值可以用于将等待分类为HIGH(例如，如果CPU等待超过一千五百秒)或LOW(例如，如果CPU等待少于二十秒)。注意，针对每个容器大小、资源类型和群集配置的实际百分位数可以不同。

另外，针对百分比等待的阈值可以被分类为SIGNIFICANT(显著)或NOTSIGNIFICANT(不显著)。再次，生产遥测可以被用于设置针对百分比等待的阈值。在一个实现中，针对CPU和盘I/O的百分比等待的第80百分位数值在20％至30％的范围内，而针对高利用率的对应数值在70％-90％的范围内，这表明值的这种分离。来自这些分布的这些百分位数值可以被用于设置用于对百分比等待进行分类的阈值。

以下描述使用数据库引擎内部的知识来检测高需求以使用这些信号来制定用于估计需求是否足够高以需要放大的一组规则。第一步是标识与高需求相对应的场景。一些说明性场景是：(a)如果利用率为HIGH，并且等待时间为HIGH，其中百分比等待为SIGNIFICANT；(b)如果利用率为HIGH，等待时间为HIGH，百分比等待为NOT SIGNIFICANT，并且利用率和/或等待随着时间具有SIGNIFICANT增长趋势；和(c)如果利用率为HIGH，等待时间为MEDIUM，百分比等待为SIGNIFICANT，并且利用率和/或等待随着时间具有SIGNIFICANT增长趋势。注意，所有场景组合两个或更多个信号。此外，如果信号之一为弱(例如，延迟不为HIGH)，则可以考虑附加信号(例如，趋势)。

注意，在信号和相关联的类别方面来陈述场景。除了易于解释之外，这些方案可以直接被编码为模型中的谓词规则，其如果对于资源为真则表示对该资源的高需求。进一步注意，存储器和盘I/O交互。也就是说，如果存储器是瓶颈，则存储器瓶颈将导致更高的I/O利用率和等待。由于存储器等待和独立于I/O等待被跟踪，如果两个资源都被标识为瓶颈，则该模型推荐放大这两种资源。

估计需求是否为低类似于高需求估计，除了测试是对于信号的类别范围的另一端。例如，规则测试LOW利用率或LOW等待、以及资源等待或利用的非积极趋势。

为了解决对数据库服务器中的低存储器需求的估计，可以使用“气球”技术，其缓慢地减少被分配给租户的存储器以观察其对盘I/O的影响。如果存储器可以一直被减少到下一个更小的容器大小，而不会导致盘I/O需求的显著增加，则存储器需求被确定为低。如果气球导致盘I/O需求增加，则租户将恢复为当前存储器分配。在一个实现中，为了确定什么时候触发气球，以便可以最小化延迟的影响，只有当对所有其他资源的需求为LOW时才会触发气球。这种方法可以最小化不利地影响租户的查询延迟的风险。

关于预算管理器412，租户可以为包括n个计费间隔的预算时段规定预算B。预算管理器412确定大大地小于预算时段的每个计费间隔的可用预算(B_i)，使得令C_min和C_max是针对最便宜和最昂贵的容器的每个计费间隔的相应成本。预算管理器412确保B_i≥C_min，以便在预算内分配最便宜的容器。预算管理问题的类比于计算机网络中的流量整形问题，其中网络路由器形成流，以允许周期性带宽突发，同时提供最小的稳定带宽，并且确保流符合总带宽分配。现在描述管理盈余预算的一种方法(B-n×C_min)。

图5示出了用于预算分配的令牌桶算法500。令牌桶算法500使用深度为D的固定容量桶502来保持令牌504，其中D是最大突发大小。桶502被初始化为具有T_I个令牌并且以固定速率(被称为填充率T_R，其为保证的平均带宽)周期性地被刷新。

预算管理器412通过设置T_R、T_I和D来配置令牌桶502以满足要求。在任何时刻，桶中的令牌504的数目是可用预算B_i。在第i计费间隔结束时，添加T_R个令牌，并且减去C_i个令牌，其中C_i是针对第i间隔的成本。设置T_R＝C_min确保B_i≥C_min。设置D＝B-(n-1)×C_min保证为T_I设置的值确定在高需求期间消耗预算是如何的积极。积极的突发策略设置T_I＝D(即，开始具有完整桶的预算时段)。如果存在持续的高需求使得最大的容器被分配用于m个间隔，则当时，桶502将为空。从第(m+1)间隔到第n间隔，可用预算将为B_i＝C_min，并且租户只能使用最便宜的容器，这可能不足以满足需求。备选方案是设置T_I＝K×C_max，其中K<m并且设置

这种保守的设置确保了最大使用突发被限制在使用C_max的至多K个间隔加上从过去未使用的任何剩余的未使用令牌(即，该设置为预算时段的后期的间隔节省更多，代价是在早期限制了成本)。通过分析来自生产遥测的高需求时段的分布，该值可以被设置为足以满足突发的一定分数(例如，第95百分位数)的K。

自动缩放逻辑414通过监测延迟、估计的资源需求和可用的预算来确定针对下一计费间隔的容器大小。如果租户对资源的需求很高，并且延迟为BAD，或者存在随着时间的SIGNIFICANT趋势增加延迟，则如果有足够的预算可用，则逻辑414推荐放大。如果延迟为GOOD并且没有劣化，并且估计的资源需求为LOW，则逻辑414推荐缩小；否则，不采取任何动作。

资源需求估计器410为每个资源提供期望的设置，包括所需容器大小。自动缩放逻辑414使用可用预算(B_i)和期望的容器大小来在一组DaaS容器之间寻找最便宜的容器，其中资源在所有资源维度大于或等于所需容器并且价格C_i≤B_i。如果所需容器受到可用预算的约束，则选择价格低于B_i的最昂贵的容器。

该过程是对由DaaS支持的容器集合进行的迭代搜索。注意，资源需求估计处于个体资源水平。因此，如果工作负载仅需要一种类型的资源(诸如CPU)，则估计逻辑推荐增加所需容器中的CPU分配。如果DaaS支持在每个资源维度中缩放容器，则该多维缩放可以由自动缩放逻辑414使用。

如果推荐的容器大小不同于当前容器大小，则该模型向DaaS的管理构造406发出容器重新大小调整命令，DaaS的管理构造406然后执行重新大小调整操作。这种容器重新大小调整操作在大多数服务中可以是在线操作。

本文中包括表示用于执行所公开的架构的新颖方面的示例性方法的一组流程图。虽然为了简化说明的目的，例如为流程图表或流程图的形式的本文所示的一种或多种方法被示出和描述为一系列动作，但是应当了解和理解，方法不受动作顺序的限制，因为一些动作可以按照不同的顺序发生和/或与本文所示和所描述的其他动作同时发生。例如，本领域技术人员将了解和理解，方法可以备选地被表示为一系列相互关联的状态或事件，诸如在状态图中。此外，新颖的实现可能不需要在方法中说明的所有动作。

图6示出了根据所公开的架构的DaaS方法。在600，基于生产遥测(例如，图1的遥测108)来为数据库估计容器的资源需求。在602，基于所估计的资源需求的变化来代表租户自动缩放针对计费间隔的容器的容器大小。

该方法还可以包括基于由租户规定的输入来管理自动缩放的行为。该方法还可以包括从生产遥测中标识统计上鲁棒的信号。该方法还可以包括组合多个信号以提高资源需求的估计的准确度。

该方法还可以包括基于货币预算、性能灵敏度和延迟目标来控制货币成本。该方法还可以包括选择能够从其得出用于估计资源需求的信号的生产遥测的计数器的子集。该方法还可以包括跟踪生产遥测中的计数器的趋势度量与信号之间的相关性。

图7示出了根据所公开的架构的备选DaaS方法。在700，收集数据库服务器的遥测。数据库服务器托管针对对应租户数据库的容器，并且容器各个具有对应容器大小。在702，基于遥测的处理来估计容器的资源需求。在704，自动缩放容器大小以用于后续计费间隔，并且与所估计的资源需求的变化相关联地缩放容器大小。

该方法还可以包括基于由租户规定的输入来管理自动缩放的行为。该方法还可以包括组合多个信号以提高资源需求的估计的准确度。该方法还可以包括跟踪遥测中的计数器的趋势度量和信号之间的相关性。该方法还可以包括基于来自遥测的计数器的选择来得出针对容器大小的资源需求估计的信号。

图8示出了根据所公开的架构的备选DaaS方法。在800，接收数据库管理构造的数据库服务器。数据库服务器托管针对对应租户数据库的容器，容器各个具有容器大小。在802，收集数据库管理构造的生产遥测。在804，由需求估计逻辑基于生产遥测的处理来估计容器的资源需求。在806，基于所估计的资源需求的变化来自动缩放容器大小以用于后续计费间隔。

如本申请中使用的，术语“部件”旨在指代计算机相关实体，其是硬件、软件和有形硬件的组合、软件或执行中的软件。例如，部件可以是但不限于有形部件，诸如一个或多个微处理器、芯片存储器、大容量存储设备(例如，光驱、固态驱动器、磁存储介质驱动器等)、计算机、以及便携式计算和计算能力设备(例如，蜂窝电话、平板计算机、智能电话等)。软件部件包括在微处理器上运行的进程、对象(使用方法维护变量和行为的状态的软件实体)、可执行文件、数据结构(存储在易失性或非易失性存储介质中)、模块(程序的一部分)、执行线程(可以独立管理的最小的指令序列)和/或程序。

作为说明，在服务器上运行的应用和服务器两者都可以是部件。一个或多个部件可以驻留在进程和/或执行线程内，并且部件可以被本地化在一个计算机上和/或分布在两个或更多个计算机之间。本文中可以使用词语“示例性”来表示用作示例、实例或说明。本文中描述为“示例性”的任何方面或设计不一定被解释为比其他方面或设计优选或有利。

现在参考图9，示出了根据所公开的架构的在DaaS(例如，关系)中执行自动化需求驱动的资源缩放的计算系统900的框图。备选地或另外地，本文中功能描述可以至少部分地由一个或多个硬件逻辑部件来执行。例如而非限制，可以使用的说明性类型的硬件逻辑部件包括现场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、系统级芯片系统(SOC)、复杂可编程逻辑器件(CPLD)等，其中模拟、数字和/或混合信号和其他功能可以在基底中实现。

为了为其各个方面提供附加的上下文，图9和以下描述旨在提供其中可以实现各个方面的合适的计算系统900的简要的一般描述。虽然以上描述在可以在一个或多个计算机上运行的计算机可执行指令的一般上下文中，但是本领域技术人员将认识到，新颖的实现也可以结合其他程序模块和/或硬件和软件的组合来实现。

用于实现各个方面的计算系统900包括具有以下各项的计算机902：一个或多个微处理单元904(也称为一个或多个微处理器和一个或多个处理器)、诸如系统存储器906的计算机可读存储介质(其中介质是数据可以以电子和/或光学方式在其上被存储和检索的任何物理设备或材料)(计算机可读存储介质还包括磁盘、光盘、固态驱动器、外部存储器系统和闪存驱动器)、和系统总线908。一个或多个微处理单元904可以是各种商业上可获得的微处理器中的任何一个，诸如单处理器、多处理器、处理和/或存储电路的单核单元和多核单元。此外，本领域技术人员将理解，新颖的系统和方法可以用其他计算机系统配置来实践，包括小型计算机、大型计算机以及个人计算机(例如，台式计算机、膝上型计算机、平板PC等)、手持计算设备、基于微处理器或可编程的消费电子产品等，其中的每一个可以可操作地耦合到一个或多个相关联的设备。

计算机902可以是在数据中心和/或计算资源(硬件和/或软件)中使用以支持用于便携式和/或移动计算系统(诸如无线通信设备、蜂窝电话、以及其他支持移动的设备)的云计算服务的若干计算机中的一个。例如，云计算服务包括但不限于基础架构即服务、平台即服务、软件即服务、存储即服务、桌面即服务、数据即服务、安全即服务以及API(应用程序接口)即服务。

系统存储器906可以包括计算机可读存储(物理存储)介质，诸如易失性(VOL)存储器910(例如，随机存取存储器(RAM))和非易失性存储器(NON-VOL)912(例如，ROM、EPROM、EEPROM等)。基本输入/输出系统(BIOS)可以存储在非易失性存储器912中，并且包括支持在计算机902内的部件之间传送数据和信号的基本例程，诸如在启动期间。易失性存储器910还可以包括高速RAM，诸如用于高速缓存数据的静态RAM。

系统总线908提供用于系统部件的接口，包括但不限于到一个或多个微处理单元904的系统存储器906。系统总线908可以是若干类型的总线结构中的任一种，其可以使用各种商业上可获得的总线架构中的任何一种进一步互连到存储器总线(具有或不具有存储器控制器)和外围总线(例如，PCI、PCIe、AGP、LPC等)。

计算机902还包括一个或多个机器可读存储子系统914、和用于将一个或多个存储子系统914对接到系统总线908和其他期望的计算机部件和电路的一个或多个存储接口916。一个或多个存储子系统914(物理存储介质)可以包括硬盘驱动器(HDD)、磁软盘驱动器(FDD)、固态驱动器(SSD)、闪存驱动器和/或光盘存储驱动器(例如，CD-ROM驱动器、DVD驱动器)中的一个或多个。例如，一个或多个存储接口916可以包括接口技术，诸如EIDE、ATA、SATA和IEEE 1394。

一个或多个程序和数据可以存储在存储器子系统906、机器可读和可移除存储器子系统918(例如，闪存驱动器形状因子技术)和/或一个或多个存储子系统914(例如，光学、磁性、固态)中，包括操作系统920、一个或多个应用程序922、其他程序模块924和程序数据926。

例如，操作系统920、一个或多个应用程序922、其他程序模块924和/或程序数据926可以包括图1的系统100的项目和部件、图2的图表200的容器大小和缩放、图3的抽象300的项目和部件、图4的架构400的项目、流程和部件、图5的桶算法500的流程、以及由图6-8的流程图表示的方法。

通常，程序包括执行特定任务、功能或实现特定抽象数据类型的例程、方法、数据结构、其他软件部件等。例如，操作系统920、应用922、模块924和/或数据926的全部或部分也可以被高速缓存在诸如易失性存储器910和/或非易失性存储器的存储器中。应当理解，所公开的架构可以用各种商业上可获得的操作系统或操作系统的组合来实现(例如，作为虚拟机)。

一个或多个存储子系统914和存储器子系统(906和918)用作用于数据、数据结构、计算机可执行指令等的易失性和非易失性存储的计算机可读介质。这样的指令在由计算机或其他机器执行时可以引起计算机或其他机器执行方法的一个或多个动作。计算机可执行指令包括例如引起通用计算机、专用计算机或一个或多个专用微处理器设备执行某个功能或功能组的指令和数据。计算机可执行指令可以是例如二进制文件、诸如汇编语言的中间格式指令、或者甚至源代码。执行动作的指令可以存储在一个介质上，或者可以存储在多个介质上，使得指令集体显示在一个或多个计算机可读存储介质上，而不管所有指令是否在同一介质上。

一个或多个计算机可读存储介质本身排除传播的信号本身，可以由计算机902访问，并且包括可移除和/或不可移除的易失性和非易失性内部和/或外部介质。对于计算机902，各种类型的存储介质容纳以任何合适的数字格式的数据的存储。本领域技术人员应当理解，可以采用其他类型的计算机可读介质，诸如极碟(zip)驱动器、固态驱动器、磁带、闪存卡、闪存驱动器、盒式磁带等，用于存储用于执行所公开的架构的新颖方法(动作)的计算机可执行指令。

用户可以使用诸如键盘和鼠标的外部用户输入设备928以及通过语音识别支持的语音命令与计算机902、程序和数据进行交互。其他外部用户输入设备928可以包括麦克风、IR(红外)遥控器、操纵杆、游戏杆、相机识别系统、触控笔、触摸屏、手势系统(例如，眼睛运动、身体姿势，诸如涉及一个或多个手、一个或多个手指、一个或多个手臂、头等)等。用户可以使用诸如触摸板、麦克风、键盘等板载用户输入设备930来与计算机902、程序和数据进行交互，其中计算机902是便携式计算机。

这些和其他输入设备经由系统总线908通过一个或多个输入/输出(I/O)设备接口932连接到一个或多个微处理单元904，但是可以通过诸如并行端口、IEEE 1394串行端口、游戏端口、USB端口、IR接口、短距离无线(例如，蓝牙)和其他个人局域网(PAN)技术等其他接口来连接。一个或多个I/O设备接口932还支持使用输出外围设备934，诸如打印机、音频设备、相机设备等，诸如声卡和/或板载音频处理能力。

一个或多个图形接口936(通常也称为图形处理单元(GPU))在计算机902与一个或多个外部显示器938(例如，LCD、等离子体)和/或板载显示器940(例如，用于便携式计算机)之间提供图形和视频信号。一个或多个图形接口936也可以被制造为计算机系统板的一部分。

计算机902可以在使用经由有线/无线通信子系统942到一个或多个网络和/或其他计算机的逻辑连接的网络环境(例如，基于IP)中操作。其他计算机可以包括工作站、服务器、路由器、个人计算机、基于微处理器的娱乐设备、对等设备或其他公共网络节点，并且通常包括相对于计算机902描述的很多或全部元件。逻辑连接可以包括到局域网(LAN)、广域网(WAN)、热点等的有线/无线连接。LAN和WAN联网环境在办公室和公司中很常见，并且可以支持企业范围的计算机网络，诸如内联网，所有这些网络都可以连接到全球通信网络，诸如因特网。

当在网络环境中使用时，计算机902经由有线/无线通信子系统942(例如，网络接口适配器、板载收发器子系统等)连接到网络以与有线/无线网络、有线/无线打印机、有线/无线输入设备944等进行通信。计算机902可以包括用于通过网络建立通信的调制解调器或其他装置。在网络环境中，相对于计算机902的程序和数据可以如与分布式系统相关联地存储在远程存储器/存储设备中。应当理解，示出的网络连接是示例性的，并且可以使用在计算机之间建立通信链路的其他手段。

计算机902可操作以使用诸如IEEE 802.xx标准系列的无线电技术与有线/无线设备或实体进行通信，诸如可操作地被部署为与以下各项进行无线通信(例如，IEEE 802.11空中调制技术)的无线设备：例如打印机、扫描仪、桌面和/或便携式计算机、个人数字助理(PDA)、通信卫星、与无线可检测标签相关联的任何设备或位置(例如，报亭、报摊、洗手间)和电话。这至少包括用于热点、WiMax和Bluetooth^TM无线技术的Wi-Fi^TM(用于认证无线计算机网络设备的互操作性)。因此，通信可以是与传统网络一样的预定义结构，或者简单地是至少两个设备之间的自组织通信。Wi-Fi网络使用被称为IEEE 802.11x(a、b、g等)的无线电技术来提供安全、可靠、快速的无线连接。Wi-Fi网络可以用于将计算机彼此连接，连接到因特网，以及连接到有线网络(其使用IEEE 802.3相关技术和功能)。

所公开的架构可以被实现为一种备选的数据库即服务系统，其包括：用于收集数据库服务器的遥测的装置，数据库服务器托管针对对应租户数据库的容器，容器各个具有对应容器大小；用于基于遥测的处理来估计容器的资源需求的装置；以及用于根据所估计的资源需求的变化自动缩放针对后续计费间隔的容器大小的装置。

所公开的架构可以被实现为一种备选的数据库即服务系统，其包括：用于接收数据库管理构造的数据库服务器的装置，数据库服务器托管针对对应租户数据库的容器，容器各个具有容器大小；用于收集数据库管理构造的生产遥测的装置；用于基于由需求估计逻辑对生产遥测的处理来估计容器的资源需求的装置；以及用于基于所估计的资源需求的变化来自动缩放针对后续计费间隔的容器大小的装置。

以上描述的内容包括所公开的架构的示例。当然，不可能描述部件和/或方法的每种可想到的组合，但是本领域普通技术人员可以认识到很多进一步的组合和排列是可能的。因此，新颖的架构旨在包含落在所附权利要求的精神和范围内的所有这样的改变、修改和变化。此外，如果在详细描述或权利要求中使用术语“包含(includes)”，则这样的术语旨在以类似于术语“包括(comprising)”的方式是包含性的，如同“包括(comprising)”当在权利要求中被用作过渡词时所解释的。

Claims

1.一种数据库即服务系统，包括：

自动缩放模块，其被配置为基于来自数据库服务器的遥测来自动计算针对后续计费间隔的所述数据库服务器中的容器的容器大小；以及

至少一个硬件处理器，其被配置为执行存储器中的计算机可执行指令，所述指令被执行以使能所述自动缩放模块。

2.根据权利要求1所述的系统，还包括遥测管理器，其被配置为收集所述数据库服务器的租户数据库的所述遥测。

3.根据权利要求1所述的系统，其中所述遥测包括延迟、资源利用率或可用预算中的至少一项。

4.根据权利要求1所述的系统，还包括资源需求估计器，其被配置为估计保证更大容器或更小容器的资源需求。

5.根据权利要求4所述的系统，其中所述资源需求估计器被配置为将所述遥测转变成用于估计所述数据库服务器的多个工作负载的所述资源需求的信号。

6.根据权利要求5所述的系统，其中所述资源需求估计器被配置为基于规则的逻辑，所述基于规则的逻辑对于所述信号中的每个信号具有用于关于每个信号确定租户状态的一个或多个阈值。

7.根据权利要求1所述的系统，还包括预算管理器，其被配置为基于预算输入准则来计算针对小于预算时段的每个计费间隔的可用预算。

8.根据权利要求1所述的系统，还包括自动缩放逻辑，其被配置为基于原始信号和得出信号、可用预算和需求估计的组合来向数据库管理构造输出容器大小调整动作。

9.一种数据库即服务方法，包括以下动作：

基于生产遥测来估计针对数据库的容器的资源需求；以及

基于所估计的所述资源需求的变化来代表租户自动缩放针对计费间隔的所述容器的容器大小。

10.根据权利要求9所述的方法，还包括基于由租户规定的输入来管理所述自动缩放的行为。

11.根据权利要求9所述的方法，还包括从所述生产遥测标识统计上鲁棒的信号。

12.根据权利要求9所述的方法，还包括组合多个信号以提高所述资源需求的所述估计的准确度。

13.根据权利要求9所述的方法，还包括基于货币预算、性能灵敏度和延迟目标来控制货币成本。

14.根据权利要求9所述的方法，还包括选择所述生产遥测的计数器的子集，信号能够从所述子集被得出以估计资源需求。

15.根据权利要求9所述的方法，还包括跟踪所述生产遥测中的计数器的趋势度量与信号之间的相关性。