原文链接：https://www.percona.com/blog/working-with-large-postgresql-databases/
作者： Robert Bernier
当数据库大小的话题出现时，这是一件有趣的事情。小型、中型、大型，甚至是巨大，但是这并不像你想象的那么简单。区分数据库的大小基于许多因素，这些因素的特征可以分为“有形”（以客观方式衡量的事物）或“无形”，这些属性最好使用包罗万象的短语“这取决于”。例如，对于许多人来说，一个 2TB 的数据库就是一个大型数据库。另一方面，当 PostgreSQL 数据库集群进入 Peta-Bytes 领域时，经验丰富的 DBA 可以将其描述为大。
以下是 PostgreSQL 一些基本功能的回顾：
| 数据库大小 | 无限 |
|---|---|
| 数据库数量 | 4,294,950,911 |
| 每个数据库的关系 | 1,431,650,303 |
| 表大小 | 32TB |
| 每个表的行数 | 由数字定义 |
| 可以放入页面的元组 | 4,294,967,295 页 |
| 每个表的字段 | 1,600 |
| 字段大小 | 1GB |
| 标识符长度 | 63 字节 |
| 每个表的索引 | 无限 |
| 每个索引的列 | 32 |
| 分区键 | 32 |
注意：尽管在创建大量模式时可能面临物理限制，但在 postgreSQL中创建的数量没有理论上的限制。
我已经使用以下警告来区分小型数据库和大型数据库。虽然大型数据库的一些注意事项确实可以应用于小型数据库，反之亦然，但事实是，大多数野外设置都遵循以下观察：
- 小型数据库通常由一个人管理
- 小型数据库可以手动管理。
- 小型数据库进行了最低限度的调整。
- 小型数据库通常比大型数据库更能容忍生产效率低下。
- 大型数据库使用自动化工具进行管理。
- 大型数据库必须不断受到监控并经历一个积极的调整生命周期。
- 大型数据库需要对迫在眉睫的和持续的生产问题做出快速响应，以保持最佳性能。
- 大型数据库对技术欠缺特别敏感。
大型数据库通常会提出以下问题和问题：
- 系统性能是否对生产负载的变化特别敏感？
- 系统性能是否对较小的调整效果特别敏感？
- 是否存在大量数据流失？
- 数据库负载系统是否使您的硬件功能饱和？
- 逻辑备份和重新打包表等维护活动是否需要几天甚至一周以上的时间？
- 您的灾难恢复协议是否需要非常小的恢复点目标 (RPO) 或恢复时间目标 (RTO)？
小型数据库与大型数据库之间的主要区别在于它们的管理方式：
- 尽管手动管理小型数据库很常见，尽管这不是最佳实践，但在大型数据库的许多此类情况下，使用自动化是行业默认的操作模式。
- 由于环境变化很快，大型数据库对生产问题特别敏感。
- 调音不断发展；诚然，新安装的架构通常都经过了很好的调整，但随着时间的推移， 情况会发生变化，而且大型数据库尤其容易受到攻击。
好的计划是您的朋友：通过预测未来条件来解决大型数据库的潜在问题是目标，即在整个基础设施投入生产之前对其进行测试。
使用 Ansible、Puppet、Terraform 等工具为您的构建环境编写脚本，可以减少配置底层基础设施时的人为错误，能够以一致且可重复的方式进行构建非常重要。
一旦数据库投入生产，就必须对其进行监控，并针对各种关键阈值发出警报。除了标准错误，考虑配置您的监控解决方案以遵循“三法则”。只选择并观察三个跟踪和提醒特定“状态变化”的指标。这不应与关注特定问题相混淆，而是旨在告知您应该注意您的系统，以便了解某些事情已经与被认为是正常的行为发生了变化。根据您的偏好，您可能希望关注已知的生产问题，或者当系统稳定时，您可能对趋势警报更感兴趣，例如查询性能已低于预定义阈值。
关于系统调优：虽然小型数据库可以在某种程度上使用大型数据库无法使用的默认值以令人满意的方式执行。配置初始调整参数（例如 shared_buffers 等）是必要的，但您还应该监控环境以发现诸如膨胀和长期查询性能等问题的趋势。请记住，其他稳定且经过深思熟虑的架构遇到的最常见问题是表和索引膨胀。通过调整 autovacuum 特性来解决膨胀是必不可少的。
需要进行监控，尤其是在维护窗口之前和之后，因为它们可以在成为生产问题之前发现更新的潜在问题。
密切关注在系统生命周期内的定期维护活动：
- 逻辑备份和其他数据库冗余
- 架构演变：
应用程序堆栈更新、升级和回滚
应用程序/数据库扩展 - PostgreSQL 服务器升级：
次要的
重大的 - 数据库迁移
- 硬件升级
- 通过添加和删除服务器节点来扩展集群
定期执行逻辑备份和 PostgreSQL 次要升级等维护活动。
规划逻辑转储和 WAL 归档的空间使用要求。
关于逻辑备份：如果备份整个数据库可能需要一周时间，就很难证明它是合理的。或者，差异备份是一种潜在的解决方案。定期更新和删除的备份表可以以更快的频率存档，而不是更慢的更改表，后者可以存储更长的时间而不进行更改。然而，这种方法需要适当的架构设计考虑，例如使用表分区。
逻辑备份的替代方法是考虑写入时复制 (COW) 或堆叠文件系统，例如 ZFS 和 BTRFS。例如，容器内的环境可以利用快照和克隆，从而在灾难恢复场景中实现近乎即时的恢复。
复杂的操作（例如硬件和数据库扩展）包含许多子活动，并且通常可能涉及同时与多个团队合作。在这种情况下，维护参考文档至关重要。此类活动最好在看板或 Scrum 环境中进行跟踪和计划。
关于灾难恢复 (DR)，请考虑自动化以下操作：
- 通过逻辑备份恢复
- 将 PRIMARY 故障转移到 REPLICA
- 删除/建立一个新的副本
- 时间点恢复 (PITR)：将集群重建到某个时间点
作为 PITR 的旁白：与其从头开始将整个数据集群重建到特定时间点，不如创建一个延迟复制的 STANDBY 主机，并且可以恢复到特定时间点或在当前时间点升级状态。有关详细信息，请参阅运行时参数 recovery_min_apply_delay。
总之，虽然可以通过临时方式管理小型数据库，但必须始终使用更严格和认真的方法来管理大型数据库。您从管理大型数据库中学到的知识可以用于管理小型数据库。
