认识动态 PostgreSQL：云数据库的自然演变

从今天开始，您可以在 Timescale 上创建动态 PostgreSQL 数据库。

动态PostgreSQL是云数据库的自然演变，解决了配置数据库和无服务器数据库的问题。它由动态计算提供支持，这是一项 Timescale 创新，可根据您的负载在预定义的最小/最大范围内即时扩展您的可用计算。您现在可以选择一个计算范围，而不是针对峰值进行配置（并始终为其付费）：您的数据库将以基本容量运行，并且仅在需要时立即访问其峰值。买基础，租高峰。

这带来了无与伦比的性价比：运行生产工作负载的客户从 AWS RDS for PostgreSQL 迁移时可节省 10-20%，从 AWS Aurora Serverless 迁移时可节省 50-70%。

您今天可以尝试动态 PostgreSQL。我们提供免费试用（无需信用卡），让您可以在 30 天内完全访问该平台。

要创建动态 PostgreSQL 服务，只需在登录 Timescale 时选择 PostgreSQL 选项：

您的应用程序始终处于打开状态，为什么您的数据库不应该处于打开状态？

欢迎来到未来。

问题 1：开发人员提供的计算量远远超过他们的需要

在过去的几年里，自从我们首次推出 Timescale 以来，我们在开发人员如何使用数据库方面一直处于领先地位。例如，就在最近几个月， 我们分析了超过一万亿个查询作为我们的 Insights 产品的一部分。

我们了解到的一件事是，开发人员通常提供的计算量远远超过他们实际需要的量。

一方面，这是有道理的：您永远不想担心您的数据库。大多数数据库工作负载是连续的，通常具有一定的可变性或突发性。例如，晚上使用量较多的游戏、白天使用量较多的业务应用程序或周末使用量多于工作日的联网家庭设备。

您永远不希望数据库耗尽资源。如果您的数据库达到最大容量，则会导致糟糕的客户体验（或没有客户体验！）。因此，大多数开发人员最终都会为高峰期进行配置，并加上一个缓冲区。这导致开发人员支付的计算费用远远超过他们实际需要的费用。

另一方面，这对我们来说似乎很疯狂。组织可以接受哪些其他业务资源的支出远远超出其需要？浪费计算就等于浪费金钱。

问题 2：无服务器数据库无法满足生产工作负载

有些人可能会问，“无服务器数据库怎么样？”

无服务器的概念起源于无状态工作负载。在云中的虚拟机取得成功之后，用户可以不再需要担心硬件，他们接下来会问为什么还要担心运行应用程序服务器呢？毕竟，许多用户只想运行功能，并且只需按这些功能运行的时间付费。根据需要可以轻松无缝地启动函数，几乎正是因为它们是无状态的。无服务器以及函数即服务或 FaaS 成为热门，AWS Lambda 占据了主导地位。

然后，开发人员问自己：“当我不使用数据库时，为什么要为它付费？”实际问题很好：资源浪费是一个巨大的数据库问题。在特定服务器实例（例如 db.m6gd.2xlarge）上配置 AWS RDS 数据库的做法肯定感觉不现代或灵活：固定 CPU、固定内存、固定本地磁盘。其中大部分在大多数时间都没有得到充分利用。

但这就是事情变得棘手的地方：数据库与 Lambda 函数非常不同。

如今，无服务器数据库对于大多数生产工作负载来说都是错误的，主要原因有两个：

• 无服务器数据库专注于扩展和缩小的极端情况，甚至为零。

• 无服务器数据库引入了更高的定价，以考虑为满足不断变化的需求而保留的资源“空间”（更糟糕的是，通常采用难以理解或预测的定价模型）。

  
  

我们先来讨论一下“规模归零”这个热门话题。现实情况是，大多数生产数据库不需要也不会真正从扩展到零中受益。

现在，在某些用例中，“缩放到零”是有意义的。例如，概念验证演示或更多业余爱好者应用程序。偶尔对数据集运行临时查询的能力（AWS Athena 和 Google BigQuery 为低成本、无服务器云数据仓库提供了强有力的理由，适合间歇性使用）。另一个合适的用例是避免忘记在完成后关闭云开发实例——“自动暂停”非生产数据库是有价值的（尽管这需要比无服务器设想的简单得多的功能）。

但是对于您的生产数据库和更多操作设置呢？您不想缩放到零。

缩放到零意味着重新启动时“冷启动”：空数据库共享缓冲区、空操作系统缓存、空目录缓存（对于 PostgreSQL）。

（是的，一些无服务器数据库降低了启动数据库运行所需的时间，但它们是从空状态开始的。在像 PostgreSQL 这样的关系数据库中，可能需要几分钟（或更长时间！）才能再次构建一个热工作集，特别是对于较大的数据库。）

由于许多无服务器数据库采用不同的云存储架构，冷启动性能受到的影响更大，其中将数据库页面从远程存储提取到内存的成本和延迟更大。这些开销再次导致性能下降或迫使平台提供商通过使用更大的物理资源（例如，Amazon Aurora 数据库的内存是 RDS 的两倍）来进行补偿，而这一成本最终会转嫁给用户。

因此，在许多情况下，无服务器数据库最终会获得更高且不可预测的定价。

例如，如果将 Aurora Serverless 与 Amazon RDS 进行比较，您会发现 Serverless 上的 8 个 vCPU 计算和 500 GB 存储比 RDS 贵 85%（1,097 美元对 593 美元）。这是使用 Aurora I/O Optimized 及其更可预测的存储价格，该产品于六个月前推出。 （尽管如此，我们仍然必须推断其实际计算容量，因为 Aurora Serverless 的价格是通过混淆不透明的“Aurora 容量单位”来定价的，据我们最了解情况的估计，该单位为 1 ACU = 0.25 vCPU。）

此前，使用 Aurora Standard，用户还需要为每个内部 I/O 操作付费，这几乎无法预测或预算。许多无服务器数据库继续对此类读写收费。事实上，当我们对无服务器 AWS Timestream 进行基准测试时，我们看到最终成本高出 100 倍以上由于所有这些更高的边际成本，与 Timescale 相比。成本的不可预测性和可变性与无忧相反。

简而言之，随着工作负载的扩展，无服务器数据库很容易出现性能较差、账单不可预测以及成本较高的情况。它们仅非常适合仅偶尔旋转的间歇性工作负载，并且由于缺乏内存数据缓存而可以容忍冷启动。

开发商的困境

这就是我们最终的结果：

• 由于可靠的性能、控制力和可理解性，许多开发人员仍然选择为生产应用程序提供配置的传统 DBaaS 服务，但讨厌因过度配置而产生的浪费。

  
  

• 一些开发人员选择无服务器数据库是因为其明显的成本节约、灵活性和易用性，但讨厌性能下降和不可预测、模糊的定价（这通常会导致账单神秘地高于预配置实例）。

  
  

作为开发人员我们自己，这些选项都不是很有吸引力！有机会变得更好。

解决方案：引入动态 PostgreSQL

这就是我们开发动态 PostgreSQL 的原因。

动态 PostgreSQL 始终如一地支持您的基准，并在您需要时无缝扩展计算，最高可达定义的最大值。这使得它非常适合您在生产环境中通常看到的连续工作负载范围（无论是均匀、可变还是突发）。

Dynamic PostgreSQL 是 100% PostgreSQL，具有 PostgreSQL 社区和生态系统的所有优势，以及Timescale数据库平台的成熟度。为了构建动态 PostgreSQL，我们对 PostgreSQL 基础设施的操作方式进行了创新，而不是修改 PostgreSQL 的内部结构。这使您可以访问 PostgreSQL 和 Timescale 平台提供的所有内容，而不必担心在分叉的 PostgreSQL 查询或存储引擎上运行。

使用 Dynamic PostgreSQL，您可以选择与您的工作负载需求相对应的计算范围（最小和最大 CPU）。此计算范围还配备了有效内存，相当于大多数 DBaaS 服务传统上在计算范围的“最大”端提供的内存。

CPU 系列的基础（最小）与预配置的 DBaaS 模型完全相同：最小 CPU 始终专用于您的服务来运行您的应用程序。随着负载的增加（无论是由于外部应用程序的需求，还是由于偶尔的内部数据库任务（例如增量备份或表自动清理）），您的数据库可以以零延迟的方式使用 CPU 范围的峰值（最大）。

如何实现零延迟？动态计算的工作方式与其他一些无服务器或自动扩展数据库产品不同，因此它不涉及您通常在远程迁移中看到的缓慢扩展（和性能影响）。相反，我们的基础设施配置和工作负载放置算法可确保数据库可以在其底层节点上扩展，而无需重新启动或重新配置。您的实例始终可以根据需要访问其最大计算量。

最好的部分是，您只需支付基本费用加上您在其之上使用的费用。我们将这种选择计算范围并在其之间进行缩放的模型称为“购买基础，租用峰值”。

例如，如果您选择 4-8 个 CPU 选项，则您将始终拥有 4 个专用于您的服务的 CPU 和 32 GB 的有效内存。这始终确保良好的基础性能。当负载增加时，您的应用程序可以根据需要立即使用最多 8 个 CPU（按 CPU 的分数进行计量和计费），并且如果这是您的最大限制，则永远不会超过 8 个 CPU。

动态模型使您能够更经济高效且无忧地“调整”数据库的大小。您可以选择符合最低标准需求的计算范围，但也可以根据需要增长或飙升至峰值（最大值）。此最大值对高于基本计算的任何使用量创建了固有上限，从而形成易于理解的成本上限。此外，我们对您的基本使用量和超出此范围的任何计量使用量收取相同的每（小数）CPU 小时费率：超出您的基本使用量不会产生额外费用，因此扩展时不会产生价格损失。

最后，如果您发现您配置的大小范围太低或太高，您可以轻松地将计算范围调整为更适合您的应用程序需求的大小。

专为您省钱而设计

目前，我们根据您的工作负载大小提供五种不同的计算范围，以及您在该范围内获得的相应有效内存，无论您的瞬时使用情况如何。

Dynamic PostgreSQL 还使用 Timescale 的基于使用情况的存储，您只需为存储的数据量（以 GB 小时为单位）付费，而不是为预配置的磁盘大小付费。不必担心因过度配置的磁盘而浪费金钱，也不必担心磁盘空间不足。 Timescale 的动态云基础设施可确保您在需要时拥有足够的存储容量，并且只需按使用量付费。

我们特意开发了 Dynamic PostgreSQL 来为您省钱。运行生产工作负载的客户从 AWS RDS for PostgreSQL 迁移时通常可节省 10-20%，从 AWS Aurora Serverless 迁移时可节省 50-70%。

在月底，您的账单包含两个简单、易于理解的指标：(1) 您的计算成本，按每小时基本计算加上高于其但不超过峰值的任何 CPU 使用率进行计费； (2) 您的存储成本，按 GB 小时的数据消耗计费。没有新的指标或派生单位可供测量或理解。

只需为您使用的内容付费即可。零额外成本或隐藏费用。

• 计算：可预测，基于定义的范围

• 存储：只需为您存储的内容付费

  
  

没有浪费资源。没有多付钱。晚上不失眠。您可以向老板解释的法案。

今天尝试一下

您今天就可以尝试动态 PostgreSQL！ Timescale 提供免费试用- 无需信用卡 - 让您可以在 30 天内完全访问该平台。要创建动态 PostgreSQL 服务，只需在登录 Timescale 时选择 PostgreSQL 选项：

该平台现在提供两种服务类型来满足您数据库的特定需求：

• 时间序列服务旨在提高要求最苛刻的工作负载的查询速度和可扩展性，提供关键的 Timescale 功能，例如超表、列式压缩、连续聚合和分层存储。使用它们来托管传感器数据、能源指标、财务数据、事件和其他数据密集型工作负载。

  
  

• PostgreSQL 服务是动态 Postgres 服务，针对成本效益和易用性进行了优化。将它们用于仅关系数据库，例如业务记录。

  
  

选择“PostgreSQL”后，配置动态 PostgreSQL 服务就变得非常简单。选择您的区域、动态计算范围以及高可用性和连接池选项 — 繁荣！ 💥 现在您已经有了一个可以在生产中使用的动态 PostgreSQL 数据库。

如有任何问题，联系我们。我们很乐意听到您的反馈并帮助您解决 PostgreSQL 用例（时间序列或非时间序列）！

这仅仅是个开始。我们正处于连续三个发布周的中间，这只是第二周：动态基础设施周的开始。请继续关注本周、本月、今年以及未来许多年的更多内容。 🙂

- 由迈克·弗里德曼和格兰特·戈德克撰写。