中秋节假期这么快就没了,这几天还一直下雨,索性在家看看书。这次看的是Tom Lane的《A Tour of PostgreSQL Internals》。这篇小随笔就算做学习笔记了。园子里面大神多,如果有哪里讲得不对,还请各位前辈多多指教了~
在这个ppt里面,大神Tom Lane分别从三个角度对Postgresql的内部原理进行了介绍。
View 1 Postgresql进程以及内部进程间的通信
这部分比较简短,主要介绍了客户端/服务器间通信,服务器内部的通信。
1.客户端/服务器间通信
一图胜千言,我们先上图
将上图一分为二地看,分为客户端和服务器端:
1.1客户端
在客户端中,主要有两类进程,一个是客户端本身的应用程序(Client Application),例如:psql,这些程序向服务器端发送DB请求或者接受从服务器端返回的查询结果;
另一类是客户端接口库,主要用于处理前后端通信协议。它们是一组通信协议接口库:libpq, ODBC, JDBC,Perl DBD等等。值得一提的是,libpq是Postgresql提供的使用C语言实现的协议处理库。利用这个库可以比较轻松地和后端进行通信。除了C以外,还支持Perl和PHP等其他语言,这些语言在内部也调用了libpq。(PSQLODBC在版本09.05.0400后完全使用libpq进行前后端的通信),当然,也有不依赖于libpq而直接与PostgreSQL通信的库。比较具有代表性的是Java, PostgreSQL的JDBC驱动是不依赖于libpq直接与PostgreSQL通信的。
1.2服务器端
1.2.1postmaster进程
在服务器端,postmaster是管理后端的常驻进程,默认监听UNIX Domain Socket和TCP/IP的5432端口,等待来自前端的的连接处理。一旦有前端连接过来,postgres会通过fork(2)生成子进程。对于没有fork(2)的windows平台,则利用createProcess()生成新的进程。在这种情形下,父进程的数据不会被继承过来,所以需要利用共享内存把父进程的数据继承过来。
1.2.2postgres进程
Postgres会接受前端过来的查询,然后对数据库进行检索,最后把结果返回(select)或者对数据库进行更新(update,delete,set等)。更新的数据同时还会记录在事务日志里面(PostgreSQL称为WAL日志),这个主要是当停电的时候,服务器当机,重新启动的时候进行恢复处理的时候使用的。另外,把日志归档保存起来,可在需要进行恢复的时候使用。在PostgreSQL 9.0以后,通过把WAL日志传送其他的postgreSQL,可以实时得进行数据库复制,这就是所谓的‘数据库复制’功能。
1.2.3其他进程
在服务端除了以上两个进程以外,还有其他很多辅助进程,这些进程都是由postmaster进程启动的。
a) Writer process
Writer process在适当的时间点把共享内存上的缓存写往磁盘。通过这个进程,可以防止在检查点的时候(checkpoint),大量的往磁盘写而导致性能恶化,使得服务器可以保持比较稳定的性能。Background writer起来以后就一直常驻内存,但是并非一直在工作,它会在工作一段时间后进行休眠,休眠的时间间隔通过postgresql.conf里面的参数bgwriter_delay设置,默认是200微秒。
这个进程的另外一个重要的功能是定期执行检查点(checkpoint)。在检查点的时候,会把共享内存上的缓存内容往数据库文件写,使得内存和文件的状态一致。这样可以在系统崩溃的时候可以缩短从WAL恢复的时间,另外也可以防止WAL无限的增长。 可以通过postgresql.conf的checkpoint_segments、checkpoint_timeout指定执行检查点的时间间隔。
b) WAL writer process
WAL writer process把共享内存上的WAL缓存在适当的时间点往磁盘写.这样可以减轻后端进程在写自己的WAL缓存时的压力,提高性能。另外,非同步提交设为true的时候,可以保证在一定的时间间隔内,把WAL缓存上的内容写入WAL日志文件。
c) Archive process
Archive process把WAL日志转移到归档日志里。如果保存了基础备份以及归档日志,即使是在磁盘完全损坏的时候,也可以回复数据库到最新的状态。
d) stats collector process
统计信息的收集进程。收集好统计表的访问次数,磁盘的访问次数等信息。收集到的信息除了能被autovaccum利用,还可以给其他数据库管理员作为数据库管理的参考信息。
e) Logger process
把postgresql的活动状态写到日志信息文件(并非事务日志),在指定的时间间隔里面,对日志文件进行rotate。
f) Autovacuum启动进程
autovacuum launcher process是依赖于postmaster间接启动vacuum进程。而其自身是不直接启动自动vacuum进程的。通过这样可以提高系统的可靠性。
g) 自动vacuum进程
autovacuum worker process进程实际执行vacuum的任务。有时候会同时启动多个vacuum进程。
h) wal sender / wal receiver
wal sender 进程和wal receiver进程是实现postgresql复制(streaming replication)的进程。Wal sender进程通过网络传送WAL日志,而其他PostgreSQL实例的wal receiver进程则接收相应的日志。Wal receiver进程的宿主PostgreSQL(也称为Standby)接受到WAL日志后,在自身的数据库上还原,生成一个和发送端的PostgreSQL(也称为Master)完全一样的数据库。
2.服务器内部通信
还是要上图:
postmaster在接受到客户端的请求后,会创建共享内存,内存里的数据是从Unix系统硬盘里面读出来的,供postgres进程读取和写入,即客户端对postgresql数据库中的数据的操作不是实时写回物理磁盘的,而是通过Writer process定期写回磁盘,这里具体可以参照上面提到的几个进程。
为了能看得更明白一点,总结以上两点,我们来一张更细致的图,如下:
3.View 1 小结
postgresql进程间的这种机制的好处是:
- 客户端和服务器端的“硬”分离,使系统具有良好的安全性和可靠性;
- 使得Postgrsql在网络环境下能够工作良好(此处应该是指客户端接口库);
- 在大部分Unix系统上使用方便,工作良好。
缺点也是明显的:
- 服务器内部的通信过于依赖share memory(大小是有明显限制的),限制了其扩展性;
- postgresql的连接启动时间是一定的,对于运行时间较短的客户端任务而言,该时间开销所占比重较大。不过这个缺点通常可以通过客户端连接池的方法来解决。
这篇介绍了 《A Tour of PostgreSQL Internals》中三个View中View 1 的内容,View2 和View3我们明天再继续学习吧。
对了,附上链接,《A Tour of PostgreSQL Internals》
还有 本文也参考了Postgresql srcstructure