POSTGRESQL 的數(shù)據(jù)庫體系結(jié)構(gòu)是了解POSTGRESQL?數(shù)據(jù)庫的整體概念的一個(gè)開始,而數(shù)據(jù)庫的結(jié)構(gòu)體系這個(gè)詞有點(diǎn)大,所以這里從三個(gè)角度出發(fā)來看POSTGRESQL 結(jié)構(gòu)

1? 從數(shù)據(jù)庫的使用者的角度來看postgresql 的數(shù)據(jù)庫的架構(gòu)

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

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

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

當(dāng)然實(shí)際上其他的用戶也可以具有不同的schema下的OBJECTS的權(quán)限.

2 從postgresql 進(jìn)程的角度來看,?POSTGRESQL 是基于CS 結(jié)構(gòu),?通過postgres進(jìn)程作為前端來對(duì)客戶進(jìn)行服務(wù),所有POSTGRES 從進(jìn)程的角度來看是服務(wù)器承接 客戶前端服務(wù)的,后端服務(wù)

postgres: postgres postgres [local] idle

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

除此以外我們從上圖可以看到其他的進(jìn)程在系統(tǒng)中所起的作用

postgres: logger? ?

postgres: checkpointer? ?

postgres: background writer? ?

postgres: walwriter? ?

postgres: archiver? ?

postgres: stats collector? ?

postgres: logical replication launcher??

postgres: autovacuum launcher

下面就簡(jiǎn)單的說一下這些進(jìn)程到底在做什么工作

從上面的圖和名字看

postgres: logger????日志信息的打印進(jìn)程

postgres:archiver? ?在WAL LOG 需要被歸檔的時(shí)候,觸發(fā)的進(jìn)程,通過這個(gè)進(jìn)程來進(jìn)行數(shù)據(jù)庫日志的歸檔的工作

postgres: stats collector? ?這個(gè)進(jìn)程的使用主要是收集系統(tǒng)的訪問信息,例如pg_stat_activity 以及 表的使用的狀態(tài)信息,相當(dāng)于數(shù)據(jù)庫狀態(tài)的收集器

postgres: logical replication launcher? postgres?中進(jìn)行邏輯復(fù)制的進(jìn)程

postgres: autovacuum launcher?? postgres?autovacuum 自動(dòng)VACUUM的進(jìn)程

以上的進(jìn)程都和系統(tǒng)本身的數(shù)據(jù)庫運(yùn)作關(guān)系不大,基本上周邊的進(jìn)程

postgres: checkpointer? ?

postgres: background writer? ?

postgres: walwriter???

上邊的三個(gè)進(jìn)程

background writer 是主要的寫進(jìn)程,從內(nèi)存到磁盤的過程,都要經(jīng)過這個(gè)進(jìn)程完成,如果這個(gè)進(jìn)程DOWN 則數(shù)據(jù)庫會(huì)出現(xiàn)嚴(yán)重的問題,導(dǎo)致無法工作

checkpointer 進(jìn)程是在background writer?下面的進(jìn)行數(shù)據(jù)頁面定期的將臟頁刷新到磁盤中的進(jìn)程

postgres: walwriter?wal?log?寫磁盤的進(jìn)程

上面的三個(gè)進(jìn)程任何一個(gè)出現(xiàn)問題,則數(shù)據(jù)庫會(huì)出現(xiàn)無法工作的情況.

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

所以POSTGRESQL 進(jìn)程類型可以分為四類

1 postmaster process (Daemon)

2 background process

3 backend process

4 Client process

3 最后我們來說一說，POSTGRESQL的內(nèi)存結(jié)構(gòu)是什么樣的, 在數(shù)據(jù)庫中的內(nèi)存結(jié)構(gòu)是一個(gè)數(shù)據(jù)庫中十分重要的一部分， 他關(guān)系著整體數(shù)據(jù)庫的性能上的問題。

和其他的數(shù)據(jù)庫類似， POSTGRESQL 的內(nèi)存也分為兩個(gè)部分?

1? ?local memory ??? 對(duì)于每一個(gè)客戶進(jìn)程的內(nèi)存分配

2?? Shared memory?? 對(duì)于所有進(jìn)程的數(shù)據(jù)POOL 的內(nèi)存使用

local memory 包含了 work men , maintenance_work_men 和 temp_buffers

其中每個(gè)項(xiàng)目牽扯一部分的性能

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

maintenance_work_mem? 參數(shù)的設(shè)定，主要在于系統(tǒng)層面使用內(nèi)存加速系統(tǒng)的處理例如 添加內(nèi)存， VACUUM? 等操作的速度

temp buffers? 對(duì)于臨時(shí)表的內(nèi)存的支持

剩下的就是我們的 shard memory area

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

wal buffer ?WAL BUFFER的設(shè)置 write ahead log 設(shè)置有時(shí)候會(huì)被忽略，wal buffer 的大小尤其對(duì)于頻繁DML 的高并發(fā)的系統(tǒng)，配置會(huì)提高你系統(tǒng)的性能。

commit log? 保存事務(wù)執(zhí)行的狀態(tài)， 如事務(wù)是在?

1 In progress?

2 COMMITED

3 Aborted

4 SUB-Committed?

內(nèi)存的使用關(guān)系到并發(fā)處理時(shí)的一些性能問題

今天淺析了相關(guān)從三種角度看POSTGRESQL 的結(jié)構(gòu)的問題，其實(shí)也是從 用戶， 整體數(shù)據(jù)庫處理數(shù)據(jù)的邏輯， 以及性能方面去看POSTGRESQL 三個(gè)不同的面。實(shí)際上這還不夠例如，還不夠細(xì)致，如下面這張圖

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。