PG的管道模式如何工作

yzsDBA 2022-02-16

事务

1055 字丨阅读本文需 4 分钟

PG的管道模式如何工作

今天给大家介绍PG引入的一个很酷的特性--管道模式。

什么是管道模式呢?管道模式允许应用程序发送查询,而不用读取先前发送查询的结果。一句话,它允许在单个网络事务中发送和接收多个查询和结果,从而显著提高性能。

正如所有好主意一样,都有一个范例:人们可以使用应用程序代码来模拟这种行为。在客户端与服务之间异步通信了一段时间,或者称之为“批处理模式”。有许多现有的解决方案以异步方式处理多个查询。例如PgJDBC多年来一直使用标准JDBC批处理接口支持批处理模式。当然,还有老的可靠备用dblink。

流水线模式的不同之处在于它提供了一个开箱即用的解决方案,大大降低了应用程序代码处理客户端--服务端会话的复杂性。

传统的批处理模式

流水线模式

尽管在PG14中引入,管道模式适用于当前任何版本。因为增强在客户端使用的LIBPQ中,而不是服务端本身。

现在是坏消息了:利用流水线模式和需要使用“C”或能够之间与LIBPQ交互的编程语言。不幸的是,目前还没有太多的ODBC开发方式提供必要的钩子来利用这个增强的特性。因此,需要使用上述编程语言来涉及和编程客户端--应用程序会话。

提示:对于某些人来说,这是一个为自己命名并创建一个方便的LIBPQ管道模式接口的号方法。

怎么运行

现在来探讨下这个机制是如何工作的。

保持简单:

1)客户端首先连接到PG服务

2)客户端连接必须切换到管道模式

3)一旦进入管道模式,SQL语句就会被发送到服务

4)达到服务后,语句立即执行并将结果发送回客户端,即不需要客户端/服务端确认

5)因为每个SQL语句都是按顺序发送,所以应用程序逻辑可以使用状态机或者利用FIFO队列来处理结果

6)一旦所有异步语句都已执行并返回,客户端应用程序显式终止管道模式并将连接返回到默认设置

由于每个SQL语句本质上都是幂等性的,因此由客户端逻辑来解释结果。发送SQL语句并提取彼此无关的结果是一回事,但当处理具有某种程度上互相依赖的逻辑结果时,会变得更加复杂。

可以将异步SQL语句捆绑为单个事务。但与所有事务一样,这些异步发送的SQL语句中任何一个失败都将导致所有SQL语句回滚。

当然API确实在管道故障情况下提供错误处理。在FATAL情况下,当管道本身失败时,客户端连接会接收到错误通知,从而将剩余的排队操作标记为丢失。此后恢复正常处理,就好像管道已被客户端明确关闭,并且客户端连接保持活动状态。

细节

对于C程序员来说,这里有一些参考资料:

1)如前所述,可以针对多个版本的PG使用此功能,但尽在PG14及以后版本进行了描述

2)PG14源代码:src/test/modules/libpq_pipeline/libpq_pipeline.c提供了一个执行SELECT函数调用的简单例子

注意

1) 流水线模式专为异步模式而涉及,因此同步模式不可使用,这有点违背了流水线模式的目的。

2) 一次只能发送一个SQL命令,不允许多个SQL

3) 不允许复制

4) 在发送事务COMMIT情况下:客户端在收到相应结果前,不能假定事务已提交

5) 利用流水线模式需要使用C或者可以访问libpsq api的语言进行编程

免责声明:凡注明来源本网的所有作品,均为本网合法拥有版权或有权使用的作品,欢迎转载,注明出处本网。非本网作品均来自其他媒体,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如您发现有任何侵权内容,请依照下方联系方式进行沟通,我们将第一时间进行处理。

0赞 好资讯,需要你的鼓励
来自:yzsDBA
0

参与评论

登录后参与讨论 0/1000

为你推荐

没有更多了