- 来源 | 愿码(ChainDesk.CN)内容编辑
- 愿码Slogan | 链接每一个程序员的故事
- 网站 | http://chaindesk.cn
- 愿码愿景 | 打造全学科IT系统免费课程,助力小白用户、初级工程师0成本免费系统学习、低成本进阶,帮助BAT一线资深工程师成长并利用自身优点创造睡后收入。
- 官方公众号 | 愿码 | 愿码服务号 | 区块链部落
- 免费加入愿码全思惟工程师社群 | 任一公众号回复“愿码”两个字获取入群二维码
本文阅读时长:11min程序员
可伸缩性是指软件系统随着使用它的业务增加而增加的能力。 PostgreSQL提供了一些功能,能够帮助您构建可扩展的解决方案,但严格来讲, PostgreSQL自己是不可扩展的。它能够有效地利用单台机器的如下资源:算法
可是,当涉及将数据库解决方案扩展到多台计算机时,它可能很是有问题,由于标准PostgreSQL服务器只能在单个计算机上运行。在本文中,咱们将介绍PostgreSQL中不一样的扩展方案及其实现。数据库
系统可扩展性的要求意味着如今支持业务的系统也应该可以以与其增加相同的服务质量来支持相同的业务。后端
假设一个数据库能够存储1 GB的数据,而且每秒有效地处理100个查询。若是随着业务的发展,处理的数据量会增加100倍?它可以每秒支持10,000个查询并处理100 GB的数据吗?也许不是如今,不是在同一个装置中。可是,能够扩展可扩展的解决方案,以便可以在须要时当即处理负载。缓存
在须要得到更好性能的场景中,设置更多服务器以处理额外负载并从主服务器将相同数据复制到它们是很常见的。在须要高可用性的状况下,这也是将数据连续复制到备用服务器的典型解决方案,以便在主服务器崩溃时它能够接管。服务器
复制可用于许多扩展方案。其主要目的是在系统出现故障时建立和维护备份数据库。对于物理复制尤为如此。可是,复制也可用于提升基于PostgreSQL的解决方案的性能。有时,第三方工具可用于实现复杂的扩展方案。架构
想象一下,有一个系统应该处理大量的读取请求。例如,可能有一个应用程序实现支持网站上的自动完成功能的HTTP API端点。每次用户在Web表单中输入字符时,系统都会在数据库中搜索名称以用户输入的字符串开头的对象。因为用户数量众多,查询数量可能很是大,而且还由于每一个用户会话都处理了多个请求。为了处理大量请求,数据库应该可以使用多个CPU核心。若是同时请求的数量很是大,则处理它们所需的核心数量可能大于单个机器可能具备的核心数量。并发
这一样适用于应该同时处理多个重度查询的系统。您不须要大量查询,可是当查询自己很大时,使用尽量多的CPU将提供性能优点,尤为是在使用并行查询时。负载均衡
在这种状况下,一个数据库没法处理负载,能够设置多个数据库,设置从一个主数据库到全部数据库的复制,使每一个数据库做为热备用,而后让应用程序查询不一样的数据库不一样的要求。应用程序自己能够是智能的,每次均可以查询不一样的数据库,但这须要应用程序的数据访问组件的特殊实现,以下所示:微服务
另外一个选择是使用一个名为Pgpool-II的工具,它能够做为几个PostgreSQL数据库前面的负载均衡器。该工具公开了一个SQL接口,应用程序能够链接到那里,就好像它是一个真正的PostgreSQL服务器。而后Pgpool-II会将查询重定向到当时执行最少查询的数据库; 换句话说,它将执行负载平衡:
另外一种选择是将应用程序与数据库一块儿扩展,以便应用程序的一个实例将链接到数据库的一个实例。在这种状况下,应用程序的用户应该链接到许多实例中的一个。这能够经过HTTP负载平衡来实现:
当问题不是并发查询的数量,而是数据库的大小和单个查询的速度时,能够实现不一样的方法。能够将数据分红多个服务器,这些服务器将并行查询,而后将查询结果合并到这些数据库以外。这称为数据分片。
PostgreSQL提供了一种基于表分区实现分片的方法,其中分区位于不一样的服务器上,而另外一个分区(主服务器)将它们用做外部表。在主服务器上定义的父表上执行查询时,具体取决于WHERE子句和分区的定义,PostgreSQL能够识别哪些分区包含所请求的数据,而且只查询这些分区。根据查询,有时能够在远程服务器上执行联接,分组和聚合。PostgreSQL能够并行查询不一样的分区,这将有效地利用多台机器的资源。完成全部这些后,能够在应用程序链接到单个数据库时构建解决方案,该数据库将根据要查询的数据在不一样的数据库服务器上物理执行查询。
也能够在使用PostgreSQL的应用程序中构建分片算法。简而言之,应用程序可能会知道哪些数据位于哪一个数据库中,只在那里写入,而且只能从那里读取数据。这会给应用程序增长不少复杂性。
另外一种选择是使用市场上可用的基于PostgreSQL的分片解决方案或开源解决方案。它们有各自的优势和缺点,但常见的问题是它们基于PostgreSQL的早期版本,而且不使用最新的功能(有时会提供本身的功能)。
最受欢迎的分片解决方案之一是Postgres-XL,它使用运行PostgreSQL的多个服务器实现无共享架构。该系统有几个组成部分:
· 多个数据节点:存储数据
· 单个全局事务监视器(GTM):管理集群,提供全局事务一致性
· 多个协调器节点:支持用户链接,构建查询执行计划,并与GTM和数据节点交互
Postgres-XL实现与PostgreSQL相同的API,所以应用程序不须要以任何特殊方式处理服务器。它符合ACID,这意味着它支持事务和完整性约束。该COPY命令也受支持。
使用Postgres-XL的主要好处以下:
Postgres-XL是开源的,但能够得到商业支持。
值得一提的另外一个解决方案是Greenplum。它被定位为大规模并行处理数据库的实现,专门为数据仓库而设计。它有如下组件:
· 主节点:管理用户链接,构建查询执行计划,管理事务
· 数据节点:存储数据并执行查询
Greenplum还实现了PostgreSQL API,应用程序能够链接到Greenplum数据库而无需任何更改。它支持事务,但对完整性约束的支持是有限的。该COPY命令受支持。
Greenplum的主要好处以下:
缺点以下:
Greenplum有商业和开源版本。
与可伸缩性相关的另外一个用例是当数据库链接的数量很大时。可是,当在具备大量微服务的环境中使用单个数据库而且每一个数据库都有本身的链接池时,即便它们不执行太多查询,也可能在数据库中打开数百甚至数千个链接。每一个链接都消耗服务器资源,只是处理大量链接的要求已经成为问题,甚至不执行任何查询。
若是应用程序仅在须要查询数据库并在以后关闭它们时才使用链接池和打开链接,则可能会出现另外一个问题。创建数据库链接须要时间 - 而不是太多,可是当操做数量很大时,总开销将是巨大的。
有一个名为PgBouncer的工具能够实现链接池功能。它能够接受来自许多应用程序的链接,就像它是PostgreSQL服务器同样,而后打开有限数量的数据库链接。它将为多个应用程序的链接重用相同的数据库链接。创建从应用程序到PgBouncer的链接的过程比链接到真实数据库要快得多,由于PgBouncer不须要初始化会话的数据库后端进程。
PgBouncer能够建立多个链接池,它们能够在如下三种模式之一中工做:
· 会话模式:与PostgreSQL服务器的链接用于与PgBouncer的客户端链接的生命周期。这种设置可用于加速应用程序端的链接过程。这是默认模式。
· 事务模式:与PostgreSQL的链接用于客户端执行的单个事务。当仅同时执行少许翻译时,这可用于减小PostgreSQL端的链接数。
· 语句模式:数据库链接用于单个语句。而后将它返回到池中,并为下一个语句使用不一样的链接。此模式相似于交易模式,但更具侵略性。请注意,使用语句模式时,没法进行多语句事务。
能够设置不一样的池以在不一样模式下工做。
可让PgBouncer链接到多个PostgreSQL服务器,从而起到反向代理的做用。
可使用PgBouncer的方式以下图所示:
PgBouncer创建了与数据库的多个链接。当应用程序链接到PgBouncer并启动事务时,PgBouncer会为该应用程序分配现有数据库链接,将全部SQL命令转发到数据库,而后将结果传回。交易完成后,PgBouncer将断开链接,但不关闭它们。若是另外一个应用程序启动事务,则可使用相同的数据库链接。这样的设置须要配置PgBouncer以在事务模式下工做。
PostgreSQL提供了几种实现复制的方法,这种方法能够维护来自另外一个服务器或服务器上的数据库的数据副本。这能够用做备份或备用解决方案,以便在主服务器崩溃时接管。经过使负载能够分布在多个数据库服务器上,复制还可用于提升软件系统的性能。