Postgres扩展建议

因此，您正在建立下一个独角兽创业公司，并热衷于考虑一种能适应未来发展的PostgreSQL架构来容纳您的字节吗？在过去的5年中，作为数据库顾问，我看到了数十种无可救药的过度设计/超大型解决方案，但我的建议是简短而直截了当的：不要过度思考，并在数据库方面保持简单！与其花哨的数据库，不如专注于您的应用程序。只是在实际需要时才将显微镜转到数据库。那天到来时，首先，尝试所有常见的垂直放大方法和技巧。尽量避免使用衍生的Postgres产品，或采用分布式方法，或不惜一切代价进行自制的分片–直到您拥有不到一年的呼吸空间。

哇，这对2021年有何建议？我说的是大数据时代和超扩展性时代的一种简单的单节点方法……我肯定一定是Luddite或只是对过多的除夕香槟感到头晕。好吧，也许是这样，但让我们从更远的地方开始……

在假期中，我终于有一点时间赶上我的技术阅读/观看TODO列表（虽然还剩下几十个项目，啊！）……关于分布式MySQL体系结构的过去和当前状态，有一个很好的演讲。由Percona的Peter Zaitsev撰写。哦，MySQL ？？？不，不，我们并没有突然改变“马”，PostgreSQL仍然是我们的主要重点🙂只是在与扩展有关的许多关键点中，相同的约束实际上也适用于PostgreSQL。毕竟，它们都被设计为单节点关系数据库管理引擎。

简而言之，我正在总结演讲中的一些想法，并添加一些我自己的想法。对于那些过于担心数据库性能的人，我想提供一些思考的东西-因此过早地使用了一些过于复杂的架构。这样，“担忧者”会牺牲单节点数据库的其他一些良好属性，例如可用性和防弹性。

如果您是这个领域的新手，请相信我，好吗？有许多废弃的或陈旧的项目试图提供一些完全或半自动可伸缩的，高度可用的，易于使用和易于管理的DBMS，但是失败了！尝试这样做并不是一件坏事，因为我们可以从中学到东西。实际上，某些产品已经非常接近分布式SQL数据库的圣杯（首先想到的是CockroachDB）。但是，恐怕我们仍然必须遵循CAP定理。此外，请记住，从覆盖99.9％的复杂体系结构的极端情况到覆盖99.99％的问题，不是线性复杂度/成本问题，而是指数复杂度/成本问题！

尽管经过一定时间后，像Facebook这样的公司肯定需要某种水平扩展，但也许您还没有到此为止，也许Postgres股票仍然可以为您提供数年无忧的同居生活。考虑：您是否有这么长的跑道？

*单个PostgreSQL实例每秒可以轻松完成数十万笔交易

例如，在我的（相当平均）的工作站上，我可以执行ca。在“内存中” pgbench数据集中，每1个CPU内核25k个简单的读取事务…具有Postgres v13的默认配置！通过一些调优（顺便说一下，Postgres中的调优读要比调优写难！），我能够将其提高到每个内核约32k TPS，这意味着：顶级的专用硬件服务器可以完成大约一百万次短读！使用读取功能时，通常还可以使用副本–如果需要，可以将其乘以10！然后，您需要以某种方式解决查询路由问题，但是有解决此问题的工具。在某些情况下，可以使用新的标准LibPQ连接字符串语法（target_session_attrs）–进行一些改组。顺便说一下，尽管我个人从未见过10个以上的副本，但Postgres并没有限制副本的数量。经过一定的级联，我相信您可以运行数十个而不会遇到更大的问题。

*一个节点通常每秒可以完成数万次写入事务

在我拥有6个核心（12个逻辑CPU）和NVMe SSD存储的不起眼的工作站上，默认的非常重写入（3 UPD，1 INS，1 SEL）默认的“ pgbench”测试向我问候了大约45,000 TPS –例如，经过一些检查点调整后–还有更多可用的调整技巧。

假设您已经分离了“热”和“冷”数据集，并且对索引进行了一些考虑，等等，那么一个Postgres实例可以处理很多数据。备份和备用服务器配置等会很麻烦，因为即使在最好的硬件上，您也一定会遇到一些物理限制。但是，这些问题对于所有数据库系统都是常见的。从查询性能的角度来看，没有理由为什么应该突然迫使它变慢！

*就数据一致性而言，单节点实例实际上是防弹的

假设1）您正确声明了约束，2）不要随意使用某些“ fsync”或异步提交设置，以及3）您的磁盘没有爆炸，则单个节点实例可提供坚如磐石的数据一致性。同样，最后一项适用于任何数据存储，因此希望您在某处具有“某些”备份…

意思是：即使发生非常糟糕的情况并且主节点已关闭，最糟糕的结果是您的应用程序当前不可用。一旦您做好恢复魔术（或更妙的是，让Patroni这样的机器人来照做），您就可以回到原来的位置。现在，将其与分布式环境中的部分故障场景或数据哈希错误进行比较！相信我，在处理关键数据时，在许多情况下，停机时间短于在几天或几周内必须整理掉一些失控的数据集会更好，这会让您自己和您的客户感到困惑。

在文章的开头，我说过，刚开始时，您不必过多担心从体系结构方面进行扩展。这并不意味着您应该忽略一些常见的最佳做法，以防以后理论上可能需要扩展。其中一些可能是：

这可能是列表上最重要的事情-借助现代的实际硬件（或某些金属云实例）以及配置和文件系统调优以及扩展的全部功能，您通常可以在单个节点上运行数年之久。请记住，如果您厌倦了运行自己的设置，那么如今，您随时可以通过Logical Replication迁移到某些云提供商，而停机时间最少。如果您想知道如何，请参阅此处。请注意，我在上面特别提到了“真正的”硬件，这是因为人们普遍误解为单个云vCPU几乎等于一个真正的vCPU……现实远非如此。多年来，我对自己的印象一直是大约有2-3倍的性能差异，具体取决于提供者/地区/运气因素。

*尽量避免将数据“架构”集中在一个大表上的严重错误

您会惊奇地发现我们经常看到这种情况，因此请尽早切片和切块，或进行一些分区。分区对数据库的长期运行状况也有很多好处，因为分区允许在同一逻辑表上使用多个自动清理工作程序，并且可以大大提高企业存储上的IO。如果IO确实在某个时候成为瓶颈，则可以使用Postgres本机远程分区，以便一些较旧的数据位于另一个节点上。

*确保为表/数据库“放入”适当的分片键

最初，数据可以仅驻留在单个物理节点上。例如，如果您的数据模型围绕着“数百万个独立客户端”的概念发展，那么甚至最好从具有相同模式的许多“分片”数据库开始，这样将分片转移到单独的硬件节点中就成为了一部分。未来的蛋糕。

从第一天起就可以扩展1000倍的系统有很多好处，但是在许多情况下，也有不合理（且成本高昂）的准备扩展的愿望。我明白了，它非常人性化-我也很想购买一辆时速最高为250公里的漂亮宝马敞篷车……却发现我的国家允许的最高速度为110，甚至在夏季。

在YouTube上，我最能引起共鸣的是，这种理论上的扩展能力存在一定的弊端–它在早期限制了开发速度和运营管理效率！ 拥有一个众所周知的简单而坚实的数据库，并且如果您知道如何使用它的话，它实际上也表现良好（通常是一个很好的起点）。 顺便说一句，这是一个很好的Github收藏中的类似注释上的另一个很好的链接，并且在这里还提供了一个非常详细的概述，其中介绍了Alexa排名前250位的公司如何在单个数据库上成功使用12年后才需要进行大规模扩展操作！ 概括起来：这可能是引用经典的好地方：过早的优化是万恶之源……