YugabyteDB 2.15：通过动态工作负载优化支持任何工作负载

2022年6月29日

YugabyteDB 2.15中发布的几个关键创新不仅可以帮助您在变化面前生存，还可以帮助您茁壮成长。新的YugabyteDB功能更轻松地支持多种应用程序及其固有的不可预测性。通过利用灵活、统一的数据库，您可以避免重新设计应用程序，避免使用新数据库扩充您的环境。

预测您的应用程序及其需求将如何随时间变化几乎是不可能的。我们生活在一个老客户消失、惊喜客户快速增长、新服务需要不同应用程序架构的世界。例如，今天的一组应用程序可能主要依赖于NoSQL，而在未来，SQL可能会变得更加重要。你需要为任何未来做好准备。

YugabyteDB 2.15:分布式SQL的未来

YugabyteDB 2.15提供了以下关键新功能，以支持动态工作负载优化：

服务质量（QoS）和多租户
动态应用感知分片

我们将在其他博客中对YugabyteDB 2.15的其他主要模块和功能进行分解介绍。现在，让我们稍微详细地探讨这些功能中的每一个…

服务质量（QoS）和多租户

随着YugabyteDB上部署的应用程序数量和多样性的增加，我们希望发布一些专注于服务质量（QoS）和多租户的功能。这些新功能有助于确保您的关键服务（或SQL语句）达到性能目标，并且我们能够顺利处理重负载情况。

QoS变得重要的两种情况包括：

集群利用率严重偏高：在这种情况下，您需要保持集群运行，同时确保更高优先级的事务。准入控制处理这一点。
多租户：如果多个租户或服务使用集群，则必须限制任何一个租户和服务的资源使用。限制每个租户资源使用率可以实现这一点。

使用准入控制管理高负载的集群

YugabyteDB实施准入控制，以确保高负载的集群能够保持正常运行。准入控制在连接身份验证和授权后生效。它可以在查询处理和执行的各个阶段工作。以下控制措施可用于确保服务质量。

使用准入控制管理重负载集群

使用QoS确定事务执行的优先级

新的YugabyteDB事务优先级可确保始终首先满足应用程序的最重要请求。应用程序可以设置单个事务的优先级。使用乐观并发控制时，高优先级事务将获得比低优先级事务更高的优先级。在这种情况下，如果这些事务发生冲突，则会中止低优先级事务。此行为可通过设置如下两个会话变量开启：

yb_transaction_priority_lower_bound（值介于0.0和1.0之间）
yb_transaction_priority_upper_bound（值介于0.0和1.0之间）

系统为该会话中的每个事务计算并分配一个在上述下限和上限之间随机数。如果此事务与另一事务冲突，则冲突事务将与该事务优先级的值进行比较。优先级值较高的事务获胜。

例如，假设一个金融服务应用程序需要处理同一帐户同时发生的存款和取款交易。您希望对存款交易给予更高的优先级（与取款相比）。为了实现这一点，您需要为这两个事务设置以下事务优先级。使用QoS确定事务执行的优先级

存款交易在取款开始后开始，但在另外会话提款交易完成之前发生。

限制每个节点/租户/数据库的连接速率

每个到YugabyteDB集群的连接都使用CPU和内存。这意味着必须考虑应用程序所需的连接数。YugabyteDB使用max_connections设置来限制集群中每个节点的连接数（从而限制消耗资源的连接数）。这样做是为了防止失控连接行为过度占用部署资源。

您可以与管理员用户和ysqlsh命令一起检查max_connections的值。

SHOW max_connections;

max_connections 

-----------------

300

同样，限制每个租户的连接数也很重要。为了实现这一点，将租户映射到数据库和用户（或服务帐户），并对用户的每个数据库的连接数进行速率限制。如下所示设置数据库的连接限制：

alter database test_connection CONNECTION LIMIT 1;.

如下脚本显示连接限制:

select datname, datconnlimit from pg_database where datname =’test_connection’;

      datname     | datconnlimit

 -----------------+--------------

  test_connection |            1

为高写操作工作负载实施准入控制

YugabyteDB具有广泛的控制功能，当(DockDB)的刷新或压缩无法跟上进入的写操作的速率时，可以降低写入速度。如果没有这一点，如果用户继续写入超出硬件处理能力，数据库将：

增加空间放大，这可能会导致磁盘空间不足
增加读取放大，显著降低读取性能

YugabyteDB 2.15中的新功能可以将进入的写操作降低到可管理的速度，从而避免上述问题。在这些场景中，YugabyteDB通过拒绝部分或全部写入请求，优雅地降低了进入的写操作速度。

写入暂停并因此需要更多时间来处理的原因主要有两种情况：低CPU环境或低性能磁盘。发生这种情况时，数据库层会出现以下症状：

刷新无法跟上：超过系统处理能力的写入可能会导致创建太多的 memtable，这些memtable 都需要刷新。
压缩无法跟上：数据库因写操作过载也可能导致压缩无法跟上。
WAL写入太慢：如果WAL写入很慢，则写入会经历更高的延迟，这会产生一种自然形式的准入控制。
有限的磁盘IOPS或带宽：在许多云环境中，磁盘IOPS和/或网络带宽都会被限流。

为了优雅地降低进入的写操作的速度，YugabyteDB结合了停止写入触发器和减慢写入触发器。让我们进一步了解这些触发器何时被激活。

停止写入触发器

在停止写入触发场景中，当YugabyteDB获得写入请求时，会拒绝进入的写操作请求。进入写操作按每个tablet计算。如果数据库已经处理了写入请求（表示接受而不是拒绝），则将处理该写入。但是，如果写入请求最终需要触发后续写入（例如，需要更新索引的某些类型的写入），那么这些后续请求本身可能会失败。停止写入触发器在以下任一情况下激活：

SST文件太多： SST（排序序列表）文件的数量超过了参数 sst_files_hard_limit之值，默认值为48。一旦达到硬限制，就不会再进行写入，所有进入的写操作都会被拒绝。
memstore 刷新过于频繁：

如果存在大量tablet，所有tablet都会写入。则会出现这种情况。在这种情况下，memstore频繁刷新，导致SST文件过多。在这种情况下，您可以调节分配的 memstore 总大小。 memstore 总大小是两个参数中的较小值：

global_memstore_size_mb_max（默认值为2GB）
global_memstore_size_percentage（默认为TServer总内存的10%）

您有两个不同的选项来控制YB TServer如何分配内存量：

设置default_memory_limit_to_ram_ratio来控制进程应使用的实例总RAM的百分比
也可以通过memory_limit_hard_bytes设置一个绝对值。例如，要给YB TServer 32GB的RAM，请使用 –memory_limit_hard_bytes 34359738368
排队等待刷新的memstore太多： 要刷新到磁盘的memstore队列超过一个。此触发器激活的memstore队列设置为2（因此，需要2个或更多memstore列进行刷新）。

慢写触发器

当SST文件的数量超过参数sst_files_soft_limit设定的值时，会激活慢写触发器。但是，它不会超过sst_files_hard_limit值。sst_files_soft_limit默认值为24。写入速度减慢以概率X拒绝一定百分比进入的写操作，其中X计算如下：

X=（<num SST文件>-soft_limit）/（hard_llimit-soft_limit）

动态应用感知分片

如果您在一家大型或成长中的公司工作，那么您可能有多种事务性应用程序。这些应用程序在单个数据库上同时满足不同的需求。

通过将现有的YugabyteDB功能与围绕QoS和多租户的新2.15增强功能相结合，您可以管理不同类型和大小的工作负载，而不会过度增加资源。此外，您可以处理可变和冲突的工作负载，而无需相应的响应时间差异。您还可以管理工作负载以满足定义的服务级别。

扩展的灵活性和应用程序支持在许多情况下都是可取的，包括以下情况：

需要HA或地理分布的小型数据集：具有较小数据集的应用程序可能属于以下模式，即它们需要在单个数据库中创建大量小型表、索引和其他关系。整个数据集的大小很小，但需要高可用性和/或地理数据分布。在这种情况下，扩展数据集或IOPS的数量不是一个直接的问题。此外，不希望小数据集分布在多个节点上，因为这可能会由于更多的网络跃点（例如连接）而影响某些查询的性能。
具有大表和小表的大型数据集：其他应用程序可能有几个大表和许多小表，其中大型数据集需要许多表和索引。应用程序可能会有一些表预期会增长到很大的规模，而其余的表将继续保持较小。在这种情况下，只有少数几个大表需要进行分片和扩展。所有其他表都因为位置相同受益，因为除了较大的表之外，涉及所有表的查询都不需要网络跃点。

YugabyteDB 动态工作负载

YugabyteDB 2.15：通过动态工作负载优化支持任何工作负载