共計(jì) 4010 個(gè)字符，預(yù)計(jì)需要花費(fèi) 11 分鐘才能閱讀完成。
本篇內(nèi)容介紹了“PostgreSQL 12 GA 的新特性有哪些”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓丸趣 TV 小編帶領(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)建對應(yīng)數(shù)量的臨時(shí)索引。3. 當(dāng)前一步插入數(shù)據(jù)完成，再插入創(chuàng)建索引期間產(chǎn)生的新的數(shù)據(jù)。4. 所有數(shù)據(jù)都插入完畢后，使用臨時(shí)縮影替換掉原先的索引。5. 最后刪除老索引完成整體操作。 第二個(gè)重要的變更：生成列功能的加入。 在數(shù)據(jù)庫的使用中，難免會(huì)遇到需要的數(shù)據(jù)庫表的某一列或者某幾列使用函數(shù)生成的數(shù)據(jù)。這種時(shí)候，如果每次都是實(shí)時(shí)地進(jìn)行運(yùn)算，那么這個(gè)計(jì)算代價(jià)比較大，尤其是表非常大的時(shí)候。 生成列的出現(xiàn)就是為了解決這個(gè)問題。每當(dāng)數(shù)據(jù)插入數(shù)據(jù)庫表的時(shí)候，對于生成列來說，就會(huì)生成其對應(yīng)的數(shù)據(jù)，而不需要用戶的明確輸入，當(dāng)然實(shí)際上用戶也無法輸入。 在 PG 的實(shí)現(xiàn)里面，包含了對生成列的索引的處理。 但是目前這個(gè)功能的實(shí)現(xiàn)也不是萬能的，它存在很多的限制。下面我列出其中一些： 1. 目前只能實(shí)現(xiàn)某一行的計(jì)算。2. 不支持子查詢。3. 不能使用別的生成列。4. 能用作分區(qū)鍵。 第三個(gè)重要的變更：優(yōu)化器層面的處理，即 CTE 的 inline 優(yōu)化。 CTE，實(shí)際上指的就是 with 語法指定的在主 SQL 語句前面的查詢，通常會(huì)作為臨時(shí)表提供給主查詢結(jié)構(gòu)使用。 在之前的實(shí)現(xiàn)形態(tài)中，執(zhí)行時(shí)候會(huì)首先查詢出來 CTE 內(nèi)的數(shù)據(jù)作為臨時(shí)表，然后去對執(zhí)行主查詢對應(yīng)的操作，而在 PostgreSQL 12 中，這里進(jìn)行了名為 inline 的優(yōu)化：如果 ctw 表達(dá)式指定的表，在主查詢中制備使用了一次，那么，數(shù)據(jù)庫會(huì)直接使用子查詢，而非預(yù)先查詢的方式來執(zhí)行之后的查詢與處理，這里與 c 等編程語言的 inline 意味類似。 通過子查詢進(jìn)行進(jìn)一步的優(yōu)化，可以很大程度地提升性能。 這個(gè)特性也可以人工控制，對于一些不滿足條件的 CTE 也進(jìn)行 inline 處理（MATERIALIZED），或者對滿足條件的情況下，依然不使用 inline 方式處理（NOT MATERIALIZED）。 第四個(gè)重要的變更：緩存執(zhí)行計(jì)劃，目前雖然未見得有多么重要，但在未來，可能會(huì)有很大作用的一個(gè)功能。 眾所周知，Oracle 是緩存執(zhí)行計(jì)劃的，而類似 MySQL，PostgreSQL 這些開源數(shù)據(jù)庫，都是 SQL 語句每次現(xiàn)場解析來處理的。而現(xiàn)在，PostgreSQL 12 中，首先做到了執(zhí)行計(jì)劃的緩存———雖然這個(gè)功能影響范圍目前十分有限：目前只有明確使用了 prepare 語句，創(chuàng)建了臨時(shí)過程，或者干脆就是存儲(chǔ)過程 PL/pgSQL，否則無法使用到緩存的執(zhí)行計(jì)劃，遠(yuǎn)遠(yuǎn)達(dá)不到像 Oracle 那樣，普通 SQL 語句都可以緩存執(zhí)行計(jì)劃。 但是，可以展望的未來，就勢必會(huì)有這么一個(gè)優(yōu)化。而這，也將是后續(xù) PG 的迭代版本需要去做到的事情。 第五個(gè)重要的變更：實(shí)際上是配置的變更，但其主題影響的是 SQL 執(zhí)行，因此在這里簡單說一下，就是 JIT 在 PostgreSQL 12 中，默認(rèn)是打開的狀態(tài)。 關(guān)于 JIT，在這里簡單描述一下：把 SQL 語句中的簡單計(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)心的話題之外，對于運(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 可以對數(shù)據(jù)庫中發(fā)生的重度行為有更詳細(xì)的了解，以下定更好的決策。 第二個(gè)，是我認(rèn)為絕對值得大書一筆，在 PG 歷史上留下精彩篇章的變更：“干掉”recovery.conf 文件，配置項(xiàng)目合并入 postgresql.conf 配置文件。 這個(gè)文件幾乎伴隨著 PG 的出現(xiàn)就已經(jīng)存在了，在 PG 9.0 版本之前漫長的年代，這個(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ù)庫啟動(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 不需要重啟就可以變更主庫，也不是一件不可能的事情了。 第三個(gè)，是 PG 的日常問題，vacuum 的優(yōu)化：
設(shè)置 VACUUM 不回收尾部空白頁
設(shè)置 VACUUM 跳過對索引的掃描
設(shè)置 VACUUM 遇到無法立即獲取的鎖則跳過
這些設(shè)置當(dāng)然可以極大程度地減小 vacuum 對數(shù)據(jù)庫的影響，但對 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)對應(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)維都必須面對的問題。在 zheap 中，通過引入 undo 日志，zheap 試圖同時(shí)解決 vacuum 問題，以及 32 位事務(wù) id 導(dǎo)致的 vacuum freeze（事務(wù) ID 回卷）問題。 在 zheap 中，并沒有對 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ù)倉庫，而在數(shù)據(jù)倉庫來說，通常掃描一個(gè)表特定幾列的情況，會(huì)遠(yuǎn)多于需要同時(shí)掃所有列的情況，因此 zedstore 設(shè)計(jì)目的，就是一個(gè)列存數(shù)據(jù)庫。 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ù) – 作為對比的 MySQL InnoDB 壓縮，就是整個(gè)數(shù)據(jù)塊級(jí)別的壓縮，于是共享池里面，就得同時(shí)保存數(shù)據(jù)塊的壓縮與未壓縮版本，平白消耗了寶貴的內(nèi)存。
“PostgreSQL 12 GA 的新特性有哪些”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注丸趣 TV 網(wǎng)站，丸趣 TV 小編將為大家輸出更多高質(zhì)量的實(shí)用文章！
