postgresql - 亚马逊极光 PostgreSQL : clone capability: down sides?

Question

我有一个与 Amazon Aurora PostgreSQL 兼容的数据库，作为“实时”试点实例运行。

我计划在明年初进行正式的生产过渡，我曾设想这将包括创建开发和测试实例、开始快照恢复等。此外，我迫切需要制作一些数据模型改进，这对现有 View 和程序有潜在影响，并且我不愿意在“实时”实例中这样做，尽管目前停机没有直接影响。

我已阅读有关 Aurora 克隆的 Amazon 文档，但未能找到任何关于在实践中使用它的“真实世界”文章或帖子。我看到一篇非亚马逊文章，实际上只是重述了亚马逊摘要。

有没有人直接体验过此功能？还是内部的力学知识？具体来说:

1. 您能否独立地对每个实例进行 DDL(架构)更改？文档中没有提到这一点。我不确定使用“克隆”一词是否意味着它们在结构上保持相同，但考虑到引用的用例，我无法想象您基本上是通过克隆来卡住数据库结构。
2. 是否有任何性能影响(考虑到“卡住”共享页面和特定于实例的页面之间的存储分布？
3. 如果您创建数据库的克隆，然后删除该克隆，您是否不可逆转地更改了原始数据库的存储模式(包括该过程的任何性能影响)？
4. 它是否会改变幕后的删除行为？我对 Aurora 存储的工作方式一无所知(通常对数据库存储只有零星的了解)，但在过去，可以为已删除的数据回收存储。在此模型中，如果您克隆数据库，然后从表中删除几行，会发生什么情况？

我将通过创建“老式克隆”(将快照恢复到新实例)然后克隆它来测试它，但在此期间收到的任何见解都非常感谢!

Answer 1

1. 是的，您可以对克隆进行架构更改，它们根本不会影响基础数据库。它们将导致克隆需要复制表格中的每一页，因为原始页面都需要为克隆进行更改。
2. 这取决于 - 我们已经看到，如果您修改大表的架构，克隆可能会非常慢 - 我没有官方解释，但我认为这是因为克隆必须通过原始链接用于获取其副本的页面指针，这对于小表或大表中相对较少的页面来说很好，但是一旦整个表由于模式更改而基本上被复制，我们就会看到一个子-second SELECT 查询在克隆上需要 80 秒。我要说的是，实际的模式更改并没有比预期的时间长。
3. 不，原始数据库的页面永远不会被克隆触及，它们会被使用，直到克隆修改它们，此时它们被复制仅供克隆使用。如果您稍后删除整个原始数据库或整个克隆数据库也没关系，这两个数据库的工作方式就好像它们完全独立于彼此一样，它们只共享未更改的页面。
4. 不，答案与 3 基本相同。如果您删除克隆中的行，包含这些行的页面将被复制到克隆中，而原始页面将保持不变。

正如您所描述的那样，我们正在使用克隆进行开发和暂存生产副本，并且效果很好，但正如我所说，在一种情况下(架构更改为大表)我们会看到一些非常糟糕的性能。一般来说，性能一直很好，我们没有发现常规 INSERT、UPDATE 或 DELETE 的性能有任何显着差异 - 如果您运行一个触及大表中大部分行的巨大 UPDATE，它可能会更明显，但对于常规应用工作它表现良好。