PostgreSQL体系架构
PostgreSQL 使用客戶機/服務器（C/S）的模式提供服務，一個PostgreSQL會話由下列相關的進程（程序）組成：
(1)一個服務器端進程。該進程管理數據庫文件，接受客戶端與數據庫的連接，且代表客戶端對數據庫進行操作。該進程的程序名叫做 postgres。
(2)前端應用，即需要進行數據庫操作的客戶端應用。客戶端應用可能本身就是多種多樣的：它們可以是一個字符界? 面的工具， 也可以是一個圖形界面的應用，或者是一個通過訪問數據庫來顯示網頁的 web 服務器，或者是一個特殊的數據庫管理工具。 一些客戶端應用是和 PostgreSQL 發布一起提供的，但絕大部分是用戶開發的。
和典型的客戶端/服務器應用（C/S應用）一樣，客戶端和服務器可以在不同的主機上。此時，它們通過TCP/IP進行網絡連接，你應該記住這一點，因為在客戶機上可以訪問的文件未必能夠在數據庫服務器機器上訪問（或者只能用不同的文件名進行訪問）。
PostgreSQL 服務器可以處理來自客戶端的多個并發請求。為了能這樣處理，它會為每個請求啟動（“forks”）一個新的進程，然后，客戶端和新服務器端進程就不再經過最初的postgres 進程而直接通信。 因此， 服務器端的主進程一直運行，等待著來自客戶端的連接；而客戶端和相關聯的服務器端進程則在需要的時候才會運行。（當然，這些對用戶來說是透明的，在這里談這些主要是為了說明的完整性。）
PostgreSQL數據庫是一種極好可以運行在各種平臺上的免費的開放源碼的對象關系數據庫，它是一種以關系數據庫和SQL為基礎，擴展了抽象數據類型，從而具備面向對象特性的數據庫。
PostgreSQL體系結構圖（組成結構和關系）
PostgreSQL由連接管理系統（系統控制器），編譯執行系統，存儲管理系統，事務系統，系統表五大部分組成。
連接管理系統接受外部操作對系統的請求，對操作請求進行預處理和分發，起系統邏輯控制作用；
編譯執行系統由查詢編譯器，查詢執行器組成，完成操作請求在數據庫中的分析處理和轉化工作，最終實現物理存儲介質中數據的操作；
存儲管理系統由索引管理器，內存管理器，外存管理器組成，負責存儲和管理物理數據，提供對編譯查詢系統的支持；
事務系統由事務管理器，日志管理器，并發控制，鎖管理器組成，日志管理器和事務管理器完成對操作請求的事務一致性支持，鎖管理器和并發控制提供對并發訪問數據的一致性支持；
系統表是PostgreSQL數據庫的元信息管理中心，包括數據庫對象信息和數據庫管理控制信息。系統表管理元數據信息，將PostgreSQL數據庫的各個模塊有機地連接在一起，形成一個高效的數據管理系統。
系統表
在關系數據庫中，為了實現數據庫系統的控制，必須提供數據字典的功能。數據字典不僅存儲各種對象的描述信息，而且存儲系統管理所需的各種對象的細節信息。數據字典包含數據庫系統中所有對象及其屬性的描述信息，對象之間關系的描述信息，對象屬性的自然語言含義以及數據字典變化的歷史，數據字典是關系數據庫系統管理控制信息的核心，在PostgreSQL數據庫系統中系統表扮演著數據字典的角色。
系統表是PostgreSQL數據庫存放結構元數據的地方，他在PostgreSQL中表現為存放有系統信息的普通表或者視圖（用戶可以刪除，重建）。
系統表保存了數據庫的所有元數據，所以系統運行時對系統表的訪問是非常頻繁的。為了提高系統性能，在內存中建立了共享的系統表，使用Hash表提高查詢效率。
主要系統表功能
1 pg_namespace 存儲命名空間
2 pg_tablespace 存儲空間信息
3 pg_database 存儲當前數據集簇中數據庫的信息。
4 pg_class 存儲表及與表類似結構的數據庫對象信息，包含，索引，序列，視圖，復合數據類型，TOAST表等。
5 pg_type 存儲數據類型信息。
6 pg_attribute 存儲表的屬性信息。
7 pg_index 存儲索引的具體信息。
?
PostgreSQL數據庫系統的主要功能都集中于Postgres程序，其入口是Main模塊中的main函數，在初始化數據集簇，啟動數據庫服務器是，都將從這里開始執行。Main模塊主要的工作時確定當前的操作系統平臺，并據此做一些平臺相關的環境變量設置和初始化，然后通過對命令行參數的判斷，將控制轉到相應的模塊中去。下圖是main函數的調用流程。
PostgreSQL系統主函數main的流程
PostgreSQL守護進程Postmaster為用戶連接請求分配后臺Postgres服務進程，還將啟動相關的后臺服務進程：SysLogger(系統日志進程),PgStat(統計數據收集進程),
AutoVacuum(系統自動清理進程).在Postmaster進入到循環監聽中時啟動如下進行：BgWriter(后臺寫進程),WalWriter(預寫式日志寫進程),PgArch(預寫式日志歸檔進程)。這些進程將在后續文章中介紹。
下圖是PostgreSQL的后臺流程圖：
?
?
?? 1.1.1.1 Potgres(常駐進程)
管理后端的常駐進程，也稱為’postmaster’。其默認監聽UNIXDomain Socket和TCP/IP（Windows等，一部分的平臺只監聽tcp/ip）的5432端口，等待來自前端的的連接處理。監聽的端口號可以在PostgreSQL的設置文件postgresql.conf里面可以改。
一旦有前端連接過來，postgres會通過fork(2)生成子進程。沒有Fork(2)的windows平臺的話，則利用createProcess()生成新的進程。這種情形的話，和fork(2)不同的是，父進程的數據不會被繼承過來，所以需要利用共享內存把父進程的數據繼承過來。
?? 1.1.1.2 Postgres(子進程)
子進程根據pg_hba.conf定義的安全策略來判斷是否允許進行連接，根據策略，會拒絕某些特定的IP及網絡，或者也可以只允許某些特定的用戶或者對某些數據庫進行連接。
Postgres會接受前端過來的查詢，然后對數據庫進行檢索，最好把結果返回，有時也會對數據庫進行更新。更新的數據同時還會記錄在事務日志里面（PostgreSQL稱為WAL日志），這個主要是當停電的時候，服務器當機，重新啟動的時候進行恢復處理的時候使用的。另外，把日志歸檔保存起來，可在需要進行恢復的時候使用。在PostgreSQL 9.0以后，通過把WAL日志傳送其他的postgreSQL，可以實時得進行數據庫復制，這就是所謂的‘數據庫復制’功能。
?? 1.1.1.3 其他的進程
Postgres之外還有一些輔助的進程。這些進程都是由常駐postgres啟動的進程。
(1)?Postmaster主進程和服務進程
當PG數據庫啟動時，首先會啟動Postmaster主進程。這個進程是PG數據庫的總控制進程，負責啟動和關閉數據庫實例。實際上Postmaster進程是一個指向postgres命令的鏈接，如下：
?ll/opt/postgresql/bin/postmaster
?/opt/postgresql/bin/postmaster-> postgres
當用戶和PG數據庫建立連接時，要先與Postmaster進程建立連接，此時客戶端進程會發送身份驗證消息給Postmaster主進程，Postmaster主進程根據消息進行身份驗證，驗證通過后，Postmaster主進程會fork出一個會話服務進程為這個用戶連接服務。可以通過pg_stat_activity表來查看服務進程的pid，如下：
test=# select pid,usename,client_addr,client_port frompg_stat_activity;
(2)?Writer process
Writer process在適當的時間點把共享內存上的緩存寫往磁盤。通過這個進程，可以防止在檢查點的時候(checkpoint),大量的往磁盤寫而導致性能惡化，使得服務器可以保持比較穩定的性能。Background writer起來以后就一直常駐內存，但是并非一直在工作，它會在工作一段時間后進行休眠，休眠的時間間隔通過postgresql.conf里面的參數bgwriter_delay設置，默認是200微秒。
這個進程的另外一個重要的功能是定期執行檢查點(checkpoint)。
檢查點的時候，會把共享內存上的緩存內容往數據庫文件寫，使得內存和文件的狀態一致。通過這樣，可以在系統崩潰的時候可以縮短從WAL恢復的時間，另外也可以防止WAL無限的增長。 可以通過postgresql.conf的checkpoint_segments、checkpoint_timeout指定執行檢查點的時間間隔。
Writer進程是把共享內存中的臟頁寫到磁盤上的進程。它的作用有兩個：一是定期把臟數據從內存緩沖區刷出到磁盤中，減少查詢時的阻塞；二是PG在定期作檢查點時需要把所有臟頁寫出到磁盤，通過BgWriter預先寫出一些臟頁，可以減少設置檢查點（CheckPoint，數據庫恢復技術的一種）時要進行的IO操作，使系統的IO負載趨向平穩。BgWriter是PostgreSQL8.0以后新加的特性，它的機制可以通過postgresql.conf文件中以"bgwriter_"開頭配置參數來控制：
bgwriter_delay:
backgroud writer進程連續兩次flush數據之間的時間的間隔。默認值是200，單位是毫秒。
bgwriter_lru_maxpages：
backgroud writer進程每次寫的最多數據量，默認值是100，單位buffers。如果臟數據量小于該數值時，寫操作全部由backgroud writer進程完成；反之，大于該值時，大于的部分將有server process進程完成。設置該值為0時表示禁用backgroud writer寫進程，完全有server process來完成；配置為-1時表示所有臟數據都由backgroud writer來完成。(這里不包括checkpoint操作)
bgwriter_lru_multiplier：
這個參數表示每次往磁盤寫數據塊的數量，當然該值必須小于bgwriter_lru_maxpages。設置太小時需要寫入的臟數據量大于每次寫入的數據量，這樣剩余需要寫入磁盤的工作需要server process進程來完成，將會降低性能；值配置太大說明寫入的臟數據量多于當時所需buffer的數量，方便了后面再次申請buffer工作，同時可能出現IO的浪費。該參數的默認值是2.0。
bgwriter的最大數據量計算方式：
1000/bgwriter_delay*bgwriter_lru_maxpages*8K=最大數據量
bgwriter_flush_after：
?
數據頁大小達到bgwriter_flush_after時觸發BgWriter，默認是512KB。
?
(3)?WAL writer process（預寫式日志寫）
WAL writer process把共享內存上的WAL緩存在適當的時間點往磁盤寫，通過這樣，可以減輕后端進程在寫自己的WAL緩存時的壓力，提高性能。另外，非同步提交設為true的時候，可以保證在一定的時間間隔內，把WAL緩存上的內容寫入WAL日志文件。
預寫式日志WAL（Write Ahead Log，也稱為Xlog）的中心思想是對數據文件的修改必須是只能發生在這些修改已經記錄到日志之后，也就是先寫日志后寫數據（日志先行）。使用這種機制可以避免數據頻繁的寫入磁盤，可以減少磁盤I/O。數據庫在宕機重啟后可以運用這些WAL日志來恢復數據庫。postgresql.conf文件中與WalWriter進程相關的參數如下：
wal_level：控制wal存儲的級別。wal_level決定有多少信息被寫入到WAL中。 默認值是最小的（minimal），其中只寫入從崩潰或立即關機中恢復的所需信息。replica 增加 wal 歸檔信息 同時包括 只讀服務器需要的信息。（9.6 中新增，將之前版本的 archive 和 hot_standby 合并）
logical 主要用于logical decoding 場景
fsync：該參數直接控制日志是否先寫入磁盤。默認值是ON（先寫入），表示更新數據寫入磁盤時系統必須等待WAL的寫入完成。可以配置該參數為OFF，表示更新數據寫入磁盤完全不用等待WAL的寫入完成。
synchronous_commit：參數配置是否等待WAL完成后才返回給用戶事務的狀態信息。默認值是ON，表明必須等待WAL完成后才返回事務狀態信息；配置成OFF能夠更快地反饋回事務狀態。
wal_sync_method：WAL寫入磁盤的控制方式，默認值是fsync，可選用值包括open_datasync、fdatasync、fsync_writethrough、fsync、open_sync。open_datasync和open_sync分別表示在打開WAL文件時使用O_DSYNC和O_SYNC標志；fdatasync和fsync分別表示在每次提交時調用fdatasync和fsync函數進行數據寫入，兩個函數都是把操作系統的磁盤緩存寫回磁盤，但前者只寫入文件的數據部分，而后者還會同步更新文件的屬性；fsync_writethrough表示在每次提交并寫回磁盤會保證操作系統磁盤緩存和內存中的內容一致。
full_page_writes：表明是否將整個page寫入WAL。
wal_buffers：用于存放WAL數據的內存空間大小，系統默認值是64K，該參數還受wal_writer_delay、commit_delay兩個參數的影響。
wal_writer_delay：WalWriter進程的寫間隔時間，默認值是200毫秒，如果時間過長可能造成WAL緩沖區的內存不足；時間過短將會引起WAL的不斷寫入，增加磁盤I/O負擔。
wal_writer_flush_after：
commit_delay：表示一個已經提交的數據在WAL緩沖區中存放的時間，默認值是0毫秒，表示不用延遲；設置為非0值時事務執行commit后不會立即寫入WAL中，而仍存放在WAL緩沖區中，等待WalWriter進程周期性地寫入磁盤。
commit_siblings：表示當一個事務發出提交請求時，如果數據庫中正在執行的事務數量大于commit_siblings值，則該事務將等待一段時間（commit_delay的值）；否則該事務則直接寫入WAL。系統默認值是5，該參數還決定了commit_delay的有效性。
?wal_writer_flush_after：當臟數據超過閾值時，會被刷出到磁盤。
?
(4)?Archive process
Archive process把WAL日志轉移到歸檔日志里。如果保存了基礎備份以及歸檔日志，即使實在磁盤完全損壞的時候，也可以回復數據庫到最新的狀態。
類似于Oracle數據庫的ARCH歸檔進程，不同的是ARCH是吧redo log進行歸檔，PgArch是把WAL日志進行歸檔。再深入點，WAL日志會被循環使用，也就是說，過去的WAL日志會被新產生的日志覆蓋，PgArch進程就是為了在覆蓋前把WAL日志備份出來。歸檔日志的作用是為了數據庫能夠使用全量備份和備份后產生的歸檔日志，從而讓數據庫回到過去的任一時間點。PG從8.X版本開始提供的PITR（Point-In-Time-Recovery）技術，就是運用的歸檔日志。
PgArch進程通過postgresql.conf文件中的如下參數進行
?
archive_mode：
表示是否進行歸檔操作，可選擇為off（關閉）、on（啟動）和always（總是開啟），默認值為off（關閉）。
archive_command：
由管理員設置的用于歸檔WAL日志的命令。在用于歸檔的命令中，預定義變量“%p”用來指代需要歸檔的WAL全路徑文件名，“%f”表示不帶路徑的文件名（這里的路徑都是相對于當前工作目錄的路徑）。每個WAL段文件歸檔時將調用archive_command所指定的命令。當歸檔命令返回0時，PostgreSQL就會認為文件被成功歸檔，然后就會刪除或循環使用該WAL段文件。否則，如果返回一個非零值，PostgreSQL會認為文件沒有被成功歸檔，便會周期性地重試直到成功。
archive_timeout：
表示歸檔周期，在超過該參數設定的時間時強制切換WAL段，默認值為0（表示禁用該功能）。
(5)?stats collector process
統計信息的收集進程。收集好統計表的訪問次數，磁盤的訪問次數等信息。收集到的信息除了能被autovaccum利用，還可以給其他數據庫管理員作為數據庫管理的參考信息。
PgStat進程是PostgreSQL數據庫的統計信息收集器，用來收集數據庫運行期間的統計信息，如表的增刪改次數，數據塊的個數，索引的變化等等。收集統計信息主要是為了讓優化器做出正確的判斷，選擇最佳的執行計劃。postgresql.conf文件中與PgStat進程相關的參數，如下：
track_activities：表示是否對會話中當前執行的命令開啟統計信息收集功能，該參數只對超級用戶和會話所有者可見，默認值為on（開啟）。
track_counts：表示是否對數據庫活動開啟統計信息收集功能，由于在AutoVacuum自動清理進程中選擇清理的數據庫時，需要數據庫的統計信息，因此該參數默認值為on。
track_io_timing：定時調用數據塊I/O，默認是off，因為設置為開啟狀態會反復的調用數據庫時間，這給數據庫增加了很多開銷。只有超級用戶可以設置
track_functions：表示是否開啟函數的調用次數和調用耗時統計。
track_activity_query_size：設置用于跟蹤每一個活動會話的當前執行命令的字節數，默認值為1024，只能在數據庫啟動后設置。
stats_temp_directory：統計信息的臨時存儲路徑。路徑可以是相對路徑或者絕對路徑，參數默認為pg_stat_tmp，設置此參數可以減少數據庫的物理I/O，提高性能。此參數只能在postgresql.conf文件或者服務器命令行中修改。
?
(6)?Logger process
把postgresql的活動狀態寫到日志信息文件（并非事務日志），在指定的時間間隔里面，對日志文件進行rotate.
(7)?Autovacuum（自動清理）啟動進程
autovacuum launcher process是依賴于postmaster間接啟動vacuum進程。而其自身是不直接啟動自動vacuum進程的。通過這樣可以提高系統的可靠性。
在PG數據庫中，對數據進行UPDATE或者DELETE操作后，數據庫不會立即刪除舊版本的數據，而是標記為刪除狀態。這是因為PG數據庫具有多版本的機制，如果這些舊版本的數據正在被另外的事務打開，那么暫時保留他們是很有必要的。當事務提交后，舊版本的數據已經沒有價值了，數據庫需要清理垃圾數據騰出空間，而清理工作就是AutoVacuum進程進行的。postgresql.conf文件中與AutoVacuum進程相關的參數有：
autovacuum：是否啟動系統自動清理功能，默認值為on。
log_autovacuum_min_duration：這個參數用來記錄 autovacuum 的執行時間，當 autovaccum 的執行時間超過 log_autovacuum_min_duration參數設置時，則autovacuum信息記錄到日志里，默認為 "-1", 表示不記錄。
autovacuum_max_workers：設置系統自動清理工作進程的最大數量。
autovacuum_naptime：設置兩次系統自動清理操作之間的間隔時間。
autovacuum_vacuum_threshold和autovacuum_analyze_threshold：設置當表上被更新的元組數的閾值超過這些閾值時分別需要執行vacuum和analyze。
autovacuum_vacuum_scale_factor和autovacuum_analyze_scale_factor：設置表大小的縮放系數。
autovacuum_freeze_max_age：設置需要強制對數據庫進行清理的XID上限值。
autovacuum_vacuum_cost_delay：當autovacuum進程即將執行時，對 vacuum 執行 cost 進行評估，如果超過 autovacuum_vacuum_cost_limit設置值時，則延遲，這個延遲的時間即為 autovacuum_vacuum_cost_delay。如果值為 -1, 表示使用 vacuum_cost_delay 值，默認值為 20 ms。
autovacuum_vacuum_cost_limit：這個值為autovacuum 進程的評估閥值, 默認為 -1, 表示使用 "vacuum_cost_limit " 值，如果在執行autovacuum 進程期間評估的cost 超過autovacuum_vacuum_cost_limit, 則 autovacuum 進程則會休眠。
(8)?自動vacuum進程
autovacuum worker process進程實際執行vacuum的任務。有時候會同時啟動多個vacuum進程。
(9)?wal sender / wal receiver
wal sender 進程和wal receiver進程是實現postgresql復制(streaming replication)的進程。Wal sender進程通過網絡傳送WAL日志，而其他PostgreSQL實例的wal receiver進程則接收相應的日志。Wal receiver進程的宿主PostgreSQL（也稱為Standby）接受到WAL日志后，在自身的數據庫上還原，生成一個和發送端的PostgreSQL(也稱為Master)完全一樣的數據庫。
(10)????CheckPoint（檢查點）進程
檢查點是系統設置的事務序列點，設置檢查點保證檢查點前的日志信息刷到磁盤中。postgresql.conf文件中與之相關的參數有：
?? 1.1.1.4 后端的處理流程
下面看看數據庫引擎postgres子進程的處理概要。為了簡單起見下面的說明中，把backendprocess簡稱為backend。Backend的main函數是PostgresMain (tcop/postgres.c)。
?
總結
以上是生活随笔為你收集整理的PostgreSQL体系架构的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： iptv原版固件_华为悦盒原版固件下载|
- 下一篇： MySQL一张innodb表列个数的限制