POSTGRESQL 的數據庫體系結構是了解POSTGRESQL?數據庫的整體概念的一個開始,而數據庫的結構體系這個詞有點大,所以這里從三個角度出發來看POSTGRESQL 結構

1? 從數據庫的使用者的角度來看postgresql 的數據庫的架構

POSTGRESQL 數據庫架構,從用戶的角度來看 postgresql cluster 主要由 用戶,??databases?--schema? 以及 schema 下的 各種數據庫的OBJECTS 組成,

用戶可以是一個數據庫的OWNER,?通過database下,建立不同的schema 可以管理數據庫下的不同的objects?, 可以理解為 以下的管理方式

database --- user ---??schema -- objects?

當然實際上其他的用戶也可以具有不同的schema下的OBJECTS的權限.

2 從postgresql 進程的角度來看,?POSTGRESQL 是基于CS 結構,?通過postgres進程作為前端來對客戶進行服務,所有POSTGRES 從進程的角度來看是服務器承接 客戶前端服務的,后端服務

postgres: postgres postgres [local] idle

通過上面的圖中的信息,可以看到一個連接會產生一個postgres的進程,(之前也有文字寫到關于過多連接對POSTGRESQL 本身的性能影響問題)

除此以外我們從上圖可以看到其他的進程在系統中所起的作用

postgres: logger? ?

postgres: checkpointer? ?

postgres: background writer? ?

postgres: walwriter? ?

postgres: archiver? ?

postgres: stats collector? ?

postgres: logical replication launcher??

postgres: autovacuum launcher

下面就簡單的說一下這些進程到底在做什么工作

從上面的圖和名字看

postgres: logger????日志信息的打印進程

postgres:archiver? ?在WAL LOG 需要被歸檔的時候,觸發的進程,通過這個進程來進行數據庫日志的歸檔的工作

postgres: stats collector? ?這個進程的使用主要是收集系統的訪問信息,例如pg_stat_activity 以及 表的使用的狀態信息,相當于數據庫狀態的收集器

postgres: logical replication launcher? postgres?中進行邏輯復制的進程

postgres: autovacuum launcher?? postgres?autovacuum 自動VACUUM的進程

以上的進程都和系統本身的數據庫運作關系不大,基本上周邊的進程

postgres: checkpointer? ?

postgres: background writer? ?

postgres: walwriter???

上邊的三個進程

background writer 是主要的寫進程,從內存到磁盤的過程,都要經過這個進程完成,如果這個進程DOWN 則數據庫會出現嚴重的問題,導致無法工作

checkpointer 進程是在background writer?下面的進行數據頁面定期的將臟頁刷新到磁盤中的進程

postgres: walwriter?wal?log?寫磁盤的進程

上面的三個進程任何一個出現問題,則數據庫會出現無法工作的情況.

上圖是一個網絡上比較常見的介紹?后端進程的圖,這里這些進程都是通過一個叫postmaster process的進程來工作的, 他的啟動包含了初始化 shared memory, 加載我們提到過的各個進程, 并且創建backedn process 供用戶來進行連接到POSTGRESQL 使用. 所以除了用戶連接進來的繼承, 我們管其他的進程叫background process。

所以POSTGRESQL 進程類型可以分為四類

1 postmaster process (Daemon)

2 background process

3 backend process

4 Client process

3 最后我們來說一說，POSTGRESQL的內存結構是什么樣的, 在數據庫中的內存結構是一個數據庫中十分重要的一部分， 他關系著整體數據庫的性能上的問題。

和其他的數據庫類似， POSTGRESQL 的內存也分為兩個部分?

1? ?local memory ??? 對于每一個客戶進程的內存分配

2?? Shared memory?? 對于所有進程的數據POOL 的內存使用

local memory 包含了 work men , maintenance_work_men 和 temp_buffers

其中每個項目牽扯一部分的性能

work mem 牽扯了order by distinct group by merge join , hash join ,bitmap join 等操作中使用的內存，較大的work_mem 可以提高一些復雜的SQL 的查詢速度，但內存的消耗也會變高

maintenance_work_mem? 參數的設定，主要在于系統層面使用內存加速系統的處理例如 添加內存， VACUUM? 等操作的速度

temp buffers? 對于臨時表的內存的支持

剩下的就是我們的 shard memory area

shared buffer? pool 這個不用多說了，這個一般要配置成總體內存的25%到50%，具體看系統的偏向OLAP 還是OLTP? ，所有的數據都需要在這里進行處理，所以大小的設置嚴重影響整體系統的運行的性能

wal buffer ?WAL BUFFER的設置 write ahead log 設置有時候會被忽略，wal buffer 的大小尤其對于頻繁DML 的高并發的系統，配置會提高你系統的性能。

commit log? 保存事務執行的狀態， 如事務是在?

1 In progress?

2 COMMITED

3 Aborted

4 SUB-Committed?

內存的使用關系到并發處理時的一些性能問題

今天淺析了相關從三種角度看POSTGRESQL 的結構的問題，其實也是從 用戶， 整體數據庫處理數據的邏輯， 以及性能方面去看POSTGRESQL 三個不同的面。實際上這還不夠例如，還不夠細致，如下面這張圖

總結

以上是生活随笔為你收集整理的navicat premium 链接postgresql 无法加载表_POSTGRESQL 数据库结构体系 ||| 东来西去 三个角度看...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。