溫馨提示×

您好，登錄后才能下訂單哦！

密碼登錄×
登錄注冊(cè)×
其他方式登錄
點(diǎn)擊 登錄注冊(cè) 即表示同意《億速云用戶服務(wù)條款》

PostgreSQL 12 GA的新特性有哪些

發(fā)布時(shí)間：2021-11-08 14:17:56 來源：億速云 閱讀：163 作者：iii 欄目：關(guān)系型數(shù)據(jù)庫(kù)

本篇內(nèi)容介紹了“PostgreSQL 12 GA的新特性有哪些”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

SQL的執(zhí)行優(yōu)化

 
第一個(gè)重要的變更：重建索引的并行化處理。
 
比如在遇到索引數(shù)據(jù)損壞、索引膨脹、索引的創(chuàng)建選項(xiàng)變更、無效索引重建等情況，在之前版本中，重建索引需要在表上加全局只讀鎖，阻止其他會(huì)話的寫入。而在現(xiàn)在，則通過一個(gè)細(xì)分的多步事務(wù)操作，避免了這個(gè)問題，具體如下：
 
1. 首先，是開啟事務(wù)，創(chuàng)建臨時(shí)索引。
2. 在臨時(shí)索引上開始插入數(shù)據(jù)，這里需要注意的是，如果是重建表上的所有索引，那么這里也會(huì)同時(shí)創(chuàng)建對(duì)應(yīng)數(shù)量的臨時(shí)索引。
3. 當(dāng)前一步插入數(shù)據(jù)完成，再插入創(chuàng)建索引期間產(chǎn)生的新的數(shù)據(jù)。
4. 所有數(shù)據(jù)都插入完畢后，使用臨時(shí)縮影替換掉原先的索引。
5. 最后刪除老索引完成整體操作。
 
第二個(gè)重要的變更：生成列功能的加入。
 
在數(shù)據(jù)庫(kù)的使用中，難免會(huì)遇到需要的數(shù)據(jù)庫(kù)表的某一列或者某幾列使用函數(shù)生成的數(shù)據(jù)。這種時(shí)候，如果每次都是實(shí)時(shí)地進(jìn)行運(yùn)算，那么這個(gè)計(jì)算代價(jià)比較大，尤其是表非常大的時(shí)候。
 
生成列的出現(xiàn)就是為了解決這個(gè)問題。每當(dāng)數(shù)據(jù)插入數(shù)據(jù)庫(kù)表的時(shí)候，對(duì)于生成列來說，就會(huì)生成其對(duì)應(yīng)的數(shù)據(jù)，而不需要用戶的明確輸入，當(dāng)然實(shí)際上用戶也無法輸入。
 
在PG的實(shí)現(xiàn)里面，包含了對(duì)生成列的索引的處理。
 
但是目前這個(gè)功能的實(shí)現(xiàn)也不是萬能的，它存在很多的限制。下面我列出其中一些：
 
1. 目前只能實(shí)現(xiàn)某一行的計(jì)算。
2. 不支持子查詢。
3. 不能使用別的生成列。
4. 能用作分區(qū)鍵。
 
第三個(gè)重要的變更：優(yōu)化器層面的處理，即CTE的inline優(yōu)化。
 
CTE，實(shí)際上指的就是with語(yǔ)法指定的在主SQL語(yǔ)句前面的查詢，通常會(huì)作為臨時(shí)表提供給主查詢結(jié)構(gòu)使用。
 
在之前的實(shí)現(xiàn)形態(tài)中，執(zhí)行時(shí)候會(huì)首先查詢出來CTE內(nèi)的數(shù)據(jù)作為臨時(shí)表，然后去對(duì)執(zhí)行主查詢對(duì)應(yīng)的操作，而在PostgreSQL 12中，這里進(jìn)行了名為inline的優(yōu)化：
如果ctw表達(dá)式指定的表，在主查詢中制備使用了一次，那么，數(shù)據(jù)庫(kù)會(huì)直接使用子查詢，而非預(yù)先查詢的方式來執(zhí)行之后的查詢與處理，這里與c等編程語(yǔ)言的inline意味類似。
 
通過子查詢進(jìn)行進(jìn)一步的優(yōu)化，可以很大程度地提升性能。
 
這個(gè)特性也可以人工控制，對(duì)于一些不滿足條件的CTE也進(jìn)行inline處理（MATERIALIZED），或者對(duì)滿足條件的情況下，依然不使用inline方式處理（NOT MATERIALIZED）。
 
第四個(gè)重要的變更：緩存執(zhí)行計(jì)劃，目前雖然未見得有多么重要，但在未來，可能會(huì)有很大作用的一個(gè)功能。
 
眾所周知，Oracle是緩存執(zhí)行計(jì)劃的，而類似MySQL，PostgreSQL這些開源數(shù)據(jù)庫(kù)，都是SQL語(yǔ)句每次現(xiàn)場(chǎng)解析來處理的。而現(xiàn)在，PostgreSQL 12中，首先做到了執(zhí)行計(jì)劃的緩存———雖然這個(gè)功能影響范圍目前十分有限：
目前只有明確使用了prepare語(yǔ)句，創(chuàng)建了臨時(shí)過程，或者干脆就是存儲(chǔ)過程PL/pgSQL，否則無法使用到緩存的執(zhí)行計(jì)劃，遠(yuǎn)遠(yuǎn)達(dá)不到像Oracle那樣，普通SQL語(yǔ)句都可以緩存執(zhí)行計(jì)劃。
 
但是，可以展望的未來，就勢(shì)必會(huì)有這么一個(gè)優(yōu)化。而這，也將是后續(xù)PG的迭代版本需要去做到的事情。
 
第五個(gè)重要的變更：實(shí)際上是配置的變更，但其主題影響的是SQL執(zhí)行，因此在這里簡(jiǎn)單說一下，就是JIT在PostgreSQL 12中，默認(rèn)是打開的狀態(tài)。
 
關(guān)于JIT，在這里簡(jiǎn)單描述一下：把SQL語(yǔ)句中的簡(jiǎn)單計(jì)算，直接編譯為機(jī)器匯編碼執(zhí)行，效率遠(yuǎn)高于需要從SQL轉(zhuǎn)C調(diào)用的普通SQL執(zhí)行效率，除了需要在SQL解析階段稍微多一點(diǎn)CPU之外，沒有其他壞處，而打開這個(gè)特性，獲得的好處是巨大的。

配置的優(yōu)化

除了SQL優(yōu)化這個(gè)開發(fā)人員最關(guān)心的話題之外，對(duì)于運(yùn)維來說，PG 12這個(gè)版本也做到很多的變化。
 
第一個(gè)，是新增了兩個(gè)管理用的視圖，以及一個(gè)新的函數(shù)：
- pg_stat_progress_create_index 查看當(dāng)前正在創(chuàng)建的索引進(jìn)度

  • 已經(jīng)執(zhí)行的數(shù)據(jù)塊數(shù)量

  • 已經(jīng)執(zhí)行的行數(shù)量

  • 使用/等待鎖的情況

- pg_stat_progress_cluster 查看當(dāng)前vacuum full/cluster進(jìn)度

  • 數(shù)據(jù)塊讀寫數(shù)量

  • 數(shù)據(jù)條目讀寫數(shù)量

- pg_ls_archive_statusdir() 列出歸檔狀態(tài)文件夾內(nèi)容
 
這個(gè)變化讓DBA可以對(duì)數(shù)據(jù)庫(kù)中發(fā)生的重度行為有更詳細(xì)的了解，以下定更好的決策。
 
第二個(gè)，是我認(rèn)為絕對(duì)值得大書一筆，在PG歷史上留下精彩篇章的變更：“干掉”recovery.conf文件，配置項(xiàng)目合并入postgresql.conf配置文件。
 
這個(gè)文件幾乎伴隨著PG的出現(xiàn)就已經(jīng)存在了，在PG 9.0版本之前漫長(zhǎng)的年代，這個(gè)文件負(fù)責(zé)了redo（WAL/XLOG）的回放配置，因此叫做recovery.conf。在9.0之后，流復(fù)制出現(xiàn)，于是理所當(dāng)然地，流復(fù)制的配置，也被放到這個(gè)文件里面了。而后，實(shí)際上這個(gè)文件更多地扮演者流復(fù)制配置而非數(shù)據(jù)恢復(fù)的角色。但是，與數(shù)據(jù)恢復(fù)僅僅需要離線操作不同，流復(fù)制在很多時(shí)候，是需要有在線變更手段的，而recovery.conf不支持reload，就成了一個(gè)需要解決的麻煩事了。
 
在PostgreSQL開始，這個(gè)文件原先的項(xiàng)目合并到postgresql.conf之后，為了避免配置沖突，PG自己新增了一個(gè)強(qiáng)行的限制：如果檢查到數(shù)據(jù)目錄有recovery.conf這個(gè)文件，則不允許數(shù)據(jù)庫(kù)啟動(dòng)。
 
這個(gè)合并，不僅僅是個(gè)單純的合并，也牽扯到很多相關(guān)參數(shù)的改名以及默認(rèn)值變更：
 
- 以下參數(shù)允許reload

  • archive_cleanup_command

  • promote_trigger_file

  • recovery_end_command

  • recovery_min_apply_delay

- 名稱與默認(rèn)值變更

  • trigger_file 名稱變更為promote_trigger_file

  • 取消standby_mode 配置選項(xiàng)

  • 不允許指定多個(gè)recovery target

  • 默認(rèn)恢復(fù)到last時(shí)間線（之前是current）

  • 使用cluster name作為默認(rèn)的wal receiver的application name

 
相信未來的后續(xù)版本，PG主從切換之后，standby不需要重啟就可以變更主庫(kù)，也不是一件不可能的事情了。
 
第三個(gè)，是PG的日常問題，vacuum的優(yōu)化：

  • 設(shè)置VACUUM不回收尾部空白頁(yè)

  • 設(shè)置VACUUM跳過對(duì)索引的掃描

  • 設(shè)置VACUUM遇到無法立即獲取的鎖則跳過

 
這些設(shè)置當(dāng)然可以極大程度地減小vacuum對(duì)數(shù)據(jù)庫(kù)的影響，但對(duì)PG的未來來說，更好地解決這個(gè)問題的方式，當(dāng)然是新的存儲(chǔ)引擎。

獨(dú)立存儲(chǔ)引擎

就實(shí)際來說，MySQL早些年的MyISAM，實(shí)現(xiàn)質(zhì)量并不好，不支持事務(wù)，表級(jí)別的讀寫鎖。但因?yàn)榇鎯?chǔ)引擎獨(dú)立接口，MySQL等到了InnoDB，InnoDB實(shí)現(xiàn)了全套事務(wù)存儲(chǔ)引擎，且現(xiàn)在已完全取代了MyISAM的地位。
 
而PG本身就實(shí)現(xiàn)了事務(wù)存儲(chǔ)引擎，這個(gè)獨(dú)立存儲(chǔ)引擎的需求雖然很多年前早已規(guī)劃，但實(shí)際上拆分出來正經(jīng)去做，才是這個(gè)迭代的事情。
 
目前，PG單獨(dú)處理了數(shù)據(jù)存儲(chǔ)，索引存儲(chǔ)的接口，第三方可以直接實(shí)現(xiàn)對(duì)應(yīng)的接口和數(shù)據(jù)結(jié)構(gòu)，就可以讓PG利用到新增的存儲(chǔ)引擎。
 
在社區(qū)里，已經(jīng)有兩個(gè)非常重要的存儲(chǔ)引擎產(chǎn)生--雖然距離生成環(huán)境尚且還有一段距離，但這兩個(gè)存儲(chǔ)引擎都解決了PG本身存在多年的痼疾，未來可期。
 
兩個(gè)非常重要的存儲(chǔ)引擎，就是EDB的zheap（開發(fā)中），以及Greenplum團(tuán)隊(duì)共享的zedstore（開發(fā)中）存儲(chǔ)引擎。
 
首先，說一說zheap。
 
PostgreSQL的存儲(chǔ)實(shí)現(xiàn)中，其中dirty的一部分，vacuum，在實(shí)際生產(chǎn)環(huán)境中，成了一個(gè)每個(gè)運(yùn)維都必須面對(duì)的問題。在zheap中，通過引入undo日志，zheap試圖同時(shí)解決vacuum問題，以及32位事務(wù)id導(dǎo)致的vacuum freeze（事務(wù)ID回卷）問題。
 
在zheap中，并沒有對(duì)heap（后文以此代稱“pg”原生存儲(chǔ)引擎）的索引，執(zhí)行計(jì)劃等進(jìn)行處理，而只是單純處理了其數(shù)據(jù)存儲(chǔ)部分，也就是把undo從數(shù)據(jù)文件剝離出來成為undo日志。
 
目前其實(shí)現(xiàn)是：undo日志一直向前寫（類似WAL日志），單獨(dú)的purge進(jìn)程從undo日志最老的日志開始回收，數(shù)據(jù)變更會(huì)保留在undo日志的數(shù)據(jù)指針，方便需要查詢“老”數(shù)據(jù)的情況。這么一來，就可以避免數(shù)據(jù)文件的膨脹，以及vacuum的全表掃描的代價(jià)了。
 
而zedstore則代表了不同的方向：OLAP。
greenplum所處理的，就是MPP數(shù)據(jù)倉(cāng)庫(kù)，而在數(shù)據(jù)倉(cāng)庫(kù)來說，通常掃描一個(gè)表特定幾列的情況，會(huì)遠(yuǎn)多于需要同時(shí)掃所有列的情況，因此zedstore設(shè)計(jì)目的，就是一個(gè)列存數(shù)據(jù)庫(kù)。
 
zedstore的實(shí)現(xiàn)中，每個(gè)條目，都有一個(gè)名為tid的虛擬主鍵，表的某一列或者某幾列，就保存在使用tid作為主鍵的B樹索引中。通過支持tid到多列的索引，也相當(dāng)于實(shí)現(xiàn)了“行列混合存儲(chǔ)”。
 
zedstore另外一個(gè)重要的實(shí)現(xiàn)，就是壓縮。zedstore數(shù)據(jù)存儲(chǔ)的時(shí)候，是只壓縮數(shù)據(jù)，不壓縮數(shù)據(jù)塊元數(shù)據(jù)的，這么搞雖然犧牲了一定比例的壓縮比（考慮到數(shù)據(jù)塊頭的大小，未必有多大代價(jià)）。但得到的好處就是顯而易見了：數(shù)據(jù)塊以壓縮的形態(tài)存儲(chǔ)在共享池中，由用戶會(huì)話解壓縮各自所需的數(shù)據(jù)--作為對(duì)比的MySQL InnoDB壓縮，就是整個(gè)數(shù)據(jù)塊級(jí)別的壓縮，于是共享池里面，就得同時(shí)保存數(shù)據(jù)塊的壓縮與未壓縮版本，平白消耗了寶貴的內(nèi)存。

“PostgreSQL 12 GA的新特性有哪些”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！

向AI問一下細(xì)節(jié)

免責(zé)聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱：is@yisu.com進(jìn)行舉報(bào)，并提供相關(guān)證據(jù)，一經(jīng)查實(shí)，將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI
助
手