navicat premium 链接postgresql 无法加载表_POSTGRESQL 数据库结构体系 ||| 东来西去 三个角度看...
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)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: ntko跨浏览器插件_继泄露版后,微软全
- 下一篇: redis 计数器 java_Redis