postgresql架構基礎(轉)-(1)

PostgreSQL使用一種客戶端/服務器的模型。一次PostgreSQL會話由下列相關的進程（程序）組成：

    一個服務器進程，它管理數據庫文件、接受來自客戶端應用與數據庫的聯接而且表明客戶端在數據庫上執行操做。 該數據庫服務器程序叫作postgres。

    那些須要執行數據庫操做的用戶的客戶端（前端）應用。 客戶端應用可能自己就是多種多樣的：能夠是一個面向文本的工具， 也能夠是一個圖形界面的應用，或者是一個經過訪問數據庫來顯示網頁的網頁服務器，或者是一個特製的數據庫管理工具。 一些客戶端應用是和 PostgreSQL發佈一塊兒提供的，但絕大部分是用戶開發的。

   和典型的客戶端/服務器應用（C/S應用）同樣，這些客戶端和服務器能夠在不一樣的主機上。 這時它們經過 TCP/IP 網絡聯接通信。 你應該記住的是，在客戶機上能夠訪問的文件未必可以在數據庫服務器機器上訪問（或者只能用不一樣的文件名進行訪問）。

    PostgreSQL服務器能夠處理來自客戶端的多個併發請求。 所以，它爲每一個鏈接啓動（"forks"）一個新的進程。 從這個時候開始，客戶端和新服務器進程就再也不通過最初的 postgres進程的干涉進行通信。 所以，主服務器進程老是在運行並等待着客戶端聯接， 而客戶端和相關聯的服務器進程則是起起停停。

  PostgreSQL 結構以下：

  

Potgres(常駐進程)

管理後端的常駐進程，也稱爲’postmaster’。其默認監聽UNIX Domain Socket和TCP/IP（Windows等，一部分的平臺只監聽tcp/ip）的5432端口，等待來自前端的的鏈接處理。監聽的端口號能夠在PostgreSQL的設置文件postgresql.conf裏面能夠改。

一旦有前端鏈接過來，postgres會經過fork(2)生成子進程。沒有Fork(2)的windows平臺的話，則利用createProcess()生成新的進程。這種情形的話，和fork(2)不一樣的是，父進程的數據不會被繼承過來，因此須要利用共享內存把父進程的數據繼承過來。

Postgres(子進程)

子進程根據pg_hba.conf定義的安全策略來判斷是否容許進行鏈接，根據策略，會拒絕某些特定的IP及網絡，或者也能夠只容許某些特定的用戶或者對某些數據庫進行鏈接。

Postgres會接受前端過來的查詢，而後對數據庫進行檢索，最好把結果返回，有時也會對數據庫進行更新。更新的數據同時還會記錄在事務日誌裏面（PostgreSQL稱爲WAL日誌），這個主要是當停電的時候，服務器當機，從新啓動的時候進行恢復處理的時候使用的。另外，把日誌歸檔保存起來，可在須要進行恢復的時候使用。在PostgreSQL 9.0之後，經過把WAL日誌傳送其餘的postgreSQL，能夠實時得進行數據庫複製，這就是所謂的‘數據庫複製’功能。

其餘的進程

Postgres以外還有一些輔助的進程。這些進程都是由常駐postgres啓動的進程。

Writer process

Writer process在適當的時間點把共享內存上的緩存寫往磁盤。經過這個進程，能夠防止在檢查點的時候(checkpoint),大量的往磁盤寫而致使性能惡化，使得服務器能夠保持比較穩定的性能。Background writer起來之後就一直常駐內存，可是並不是一直在工做，它會在工做一段時間後進行休眠，休眠的時間間隔經過postgresql.conf裏面的參數bgwriter_delay設置，默認是200微秒。

這個進程的另一個重要的功能是按期執行檢查點(checkpoint)。

檢查點的時候，會把共享內存上的緩存內容往數據庫文件寫，使得內存和文件的狀態一致。經過這樣，能夠在系統崩潰的時候能夠縮短從WAL恢復的時間，另外也能夠防止WAL無限的增加。 能夠經過postgresql.conf的checkpoint_segments、checkpoint_timeout指定執行檢查點的時間間隔。

WAL writer process

WAL writer process把共享內存上的WAL緩存在適當的時間點往磁盤寫，經過這樣，能夠減輕後端進程在寫本身的WAL緩存時的壓力，提升性能。另外，非同步提交設爲true的時候，能夠保證在必定的時間間隔內，把WAL緩存上的內容寫入WAL日誌文件。

Archive process

Archive process把WAL日誌轉移到歸檔日誌裏。若是保存了基礎備份以及歸檔日誌，即便實在磁盤徹底損壞的時候，也能夠回覆數據庫到最新的狀態。

stats collector process

統計信息的收集進程。收集好統計表的訪問次數，磁盤的訪問次數等信息。收集到的信息除了能被autovaccum利用，還能夠給其餘數據庫管理員做爲數據庫管理的參考信息。

Logger process

把postgresql的活動狀態寫到日誌信息文件（並不是事務日誌），在指定的時間間隔裏面，對日誌文件進行rotate.

Autovacuum啓動進程

autovacuum launcher process是依賴於postmaster間接啓動vacuum進程。而其自身是不直接啓動自動vacuum進程的。經過這樣能夠提升系統的可靠性。

自動vacuum進程

autovacuum worker process進程實際執行vacuum的任務。有時候會同時啓動多個vacuum進程。

wal sender / wal receiver

wal sender 進程和wal receiver進程是實現postgresql複製(streaming replication)的進程。Wal sender進程經過網絡傳送WAL日誌，而其餘PostgreSQL實例的wal receiver進程則接收相應的日誌。Wal receiver進程的宿主PostgreSQL（也稱爲Standby）接受到WAL日誌後，在自身的數據庫上還原，生成一個和發送端的PostgreSQL(也稱爲Master)徹底同樣的數據庫。

 

後端的處理流程

下面看看數據庫引擎postgres子進程的處理概要。爲了簡單起見下面的說明中，把backend process簡稱爲backend。Backend的main函數是PostgresMain (tcop/postgres.c)。

1. 接收前端發送過來的查詢(SQL文)
2. SQL文是單純的文字，電腦是認識不了的，因此要轉換成比較容易處理的內部形式構文樹parser tree,這個處理的稱爲構文解析。構文解析的模塊稱爲parser.這個階段只可以使用文字字面上得來的信息，因此只要沒語法錯誤之類的錯誤，即便是select不存在的表也不會報錯。這個階段的構文樹被稱爲raw parse tree. 構文處理的入口在raw_parser (parser/parser.c)。
3. 構文樹解析完之後，會轉換爲查詢樹(Query tree)。這個時候，會訪問數據庫，檢查表是否存在，若是存在的話，則把表名轉換爲OID。這個處理稱爲分析處理(Analyze), 進行分析處理的模塊是analyzer。 另外，PostgreSQL的代碼裏面提到構文樹parser tree的時候，更多的時候是指查詢樹Query tree。分析處理的模塊的入口在parse_analyze (parser/analyze.c)
4. PostgreSQL還經過查詢語句的重寫實現視圖(view)和規則(rule), 因此須要的時候，在這個階段會對查詢語句進行重寫。這個處理稱爲重寫(rewrite)，重寫的入口在QueryRewrite (rewrite/rewriteHandler.c)。
5. 經過解析查詢樹，能夠實際生成計劃樹。生成查詢樹的處理稱爲‘執行計劃處理’，最關鍵是要生成估計能在最短的時間內完成的計劃樹(plan tree)。這個步驟稱爲’查詢優化’(不叫query optimize, 而是optimize), 而完成這個處理的模塊稱爲查詢優化器(不叫query optimizer,而是optimizer, 或者稱爲planner)。執行計劃處理的入口在standard_planner (optimizer/plan/planner.c)。
6. 按照執行計劃裏面的步驟能夠完成查詢要達到的目的。運行執行計劃樹裏面步驟的處理稱爲執行處理‘execute’, 完成這個處理的模塊稱爲執行器‘Executor’, 執行器的入口地址爲，ExecutorRun (executor/execMain.c)
7. 執行結果返回給前端。
8. 返回到步驟一重複執行。

參考文章：

https://wiki.postgresql.org/wiki/Pgsrcstructure

http://www.postgres.cn/docs/9.6/tutorial-arch.html