postgresql分妺_PostgreSQL使用分片（sharding）实现水平可扩展性

作者：Ahsan Hadi翻译：魏波Ahsan Hadi

Ahsan Hadi曾在EDB工作了15年并担任产品开发高级总监，目前就职于(加拿大)，领导多个Geo的开发团队，主要职责是基于国际社区的Postgres开发以及HighHigh Postgres服务器的开发。

前言

我最近有机会参加了一些有关PostgreSQL分片的有趣演讲。第一次演讲是Bruce Momjain在PostgreSQL conf Ottawa(2019年5月)中发表的，他介绍了PostgreSQL中分片的未来，并谈到了PostgreSQL中内置分片的现状和未来。我本人在北京(PGconf.中国-2019年7月)的PostgreSQL大会上发表了第二个演讲，其中我还谈到了PG中内置分片的现状和未来。我本质上使用了Bruce演示文稿中的幻灯片(在得到他的许可的情况下)，并添加了几张幻灯片，这些幻灯片讨论了保证可伸缩性的要求，还谈到了全局事务管理器的其他替代方案。

在渥太华举行的PostgreSQL会议期间，我继续遵循在会议周安排早餐会来讨论分片主题的传统。今年的早餐会议有来自EDB，NTT，HighGO和Pivotal，今年的参加人数超过了去年，我们不得不选择更大的早餐桌。此会议的参与者都是准备在这个主题有贡献的公司中来的人，议程是讨论内置分片的当前状态，正在进行的工作，到底发生了什么。本次会议讨论的其他主题是以分片功能为总体目标，并确定可以从分片功能中获益的大致时间范围。

本篇文章将分为3个部分：

第一部分将讨论可伸缩性，什么是不同类型的可伸缩性以及PostgreSQL中当前可用的可伸缩性选项。

第二部分将介绍PG 10中添加的声明式分区以及PostgreSQL中的分片如何工作。

第三部分将介绍内置分片架构，PG中已经存在的下推功能、最后的其余功能以及相关的挑战。

1Part One一、什么是可伸缩性，为什么我们需要它

在进行分片之前，重要的是要了解“什么是可伸缩性”，对可伸缩性的需求以及使数据库可伸缩的不同方法。数据库扩展基本上是通过增加诸如I O，内存，CPU或向群集添加其他计算机之类的资源来提高数据库吞吐量及性能。依次增加更多计算也意味着通过使用多个系统的资源来完成这项工作，从而提高数据库性能。仅当您在单个标准服务器上运行PG数据库并且无法满足您的工作负载需求时，数据库才需要可伸缩性。指出需要可伸缩性的原因是数据库性能不佳，数据越来越多且无法容纳在服务器的存储中。

当用户开始看到上一段中提到的一些问题时，他们需要在最终开始考虑可伸缩性之前考虑各种解决方案，应考虑的各种选项如下：

1.模式优化

需要确保完全优化了模式以处理工作负载和发送到数据库服务器的查询类型。重点是检查用户表是否足够大以进行分区，以便查询可以路由到较小的表，还需要考虑表是否正确范式化。

2.应用程序逻辑调整

遇到问题时，我们需要考虑的另一个重要领域是应用程序逻辑调整。用户可以考虑是否可以对应用程序进行调整以从数据库中获得最佳性能。这可能涉及重写一些数据库查询，或者在某些情况下，可以在应用程序级别进行一些重构以提高性能。

3.数据库配置参数调整

这可能是选项中最重要的建议，需要根据工作负载和为数据库生成的流量类型来调整数据库配置参数。重要参数(例如