作者 | 核子可樂、Tina
過去幾年，資料庫可信生态的建構情況到底如何？标準到底是什麼？技術層面取得了哪些進展？這些進展又将如何與産業做結合？各行業在實踐層面的最佳方法論到底是什麼？如果你希望擷取上述問題的答案，歡迎報名參加【2023 可信資料庫發展大會】。
在瞬息萬變的開源世界中，軟體項目來得快、去得也快。如今獲得廣泛追捧的工具，很可能在短時間後就被更好的成果取代，再也無人問津。但即使在這樣殘酷的環境下，也有不少項目能夠長期保持生命力。
PostgreSQL 資料庫系統就是其中的典型，其曆史可以追溯到 1986 年的伯克利 POSTGRES 項目。經過幾十年的發展，作為一款跨平台、免費和開源的資料庫軟體，PostgreSQL 應用已經相當廣泛：根據 Stack Overflow 2023 開發者調查資料顯示，PostgreSQL 甚至超越了 MySQL，成為開發人員首選。
對擁有如此悠久曆史的大型代碼庫做根本性變更絕非易事，但項目開發團隊正在認真考慮這種可能性，希望讓 PostgreSQL 脫離長久以來的面向程序模型。
任何 PostgreSQL 執行個體都是以大量協作程序的形式保持運作，其中包含一個用于所有接入用戶端的程序。這些程序使用精心設計的庫通過多個共享記憶體區域進行彼此通信，而這個庫的作用就是在記憶體設定各異、映射位址不同的所有程序之間建立起複雜的資料結構。
多年以來，這套模型一直兢兢業業地支撐整個項目。但随着項目發展，現實世界正在發生巨大變化。是以，PostgreSQL 開發團隊意識到必須盡快調整、順應現實的潮流。
一份提案
今年 6 月初，Heikki Linnakangas 在經過一系列線下讨論之後，釋出了将 PostgreSQL 轉為線程模型的提案。
我覺得現在大家已經達成了強烈共識，比以往任何時候都更支援這項重大調整。實作這個目标需要投入大量精力、讨論很多細節，但團隊高層對這個基本思路沒有異議。
這封電子郵件的釋出，就是想把這種沉默的共識變成明确的發展路線。
其中簡要概括了這項遷移所涉及的種種挑戰，并低調地承認轉化過程“肯定無法通過單一版本徹底完成”。但郵件中沒有提到推動這項重大變更的原因，好在随着讨論的進行，相關資訊很快得到了補充。正如 Andres Freund（PostgreSQL Developer & Committer，EnterpriseDB 進階資料庫架構師）指出的那樣：
我認為原有流程模型開始産生諸多限制，這個問題在大型裝置上展現得尤其明顯。跨程序上下文切換所帶來的開銷，原本就比在同一程序内的不同線程間切換要更高——我估計這種開銷還将持續提升。面對大量連接配接，整個體系最終一定會因 TLB 未命中而浪費*大量*時間。這是程序模型無法跨程序共享 TLB 的天然屬性造成的必然結果。
他還提到，程序模型也增加了開發成本，迫使項目不得不維護大量重複代碼，包括在同一位址空間内保留本不必要的多種記憶體管理機制。在随後的消息中，他還補充稱由于線程全部運作在同一位址空間之内，是以可以更高效地實作狀态共享。
但有部分開發人員反映，Linnakangas 所說的“強烈共識”可能并沒有那麼強烈。Postgres 的主要貢獻者Tom Lane 表示，“我認為這将是一場災難，大量原有代碼将受到影響。”他随後補充稱，此次調整将帶來“巨大”成本，産生“不止一個安全級 bug”，也無法證明其收益超過成本投入。有人提出，目前還有其他一些高優先級工作值得早做打算。也有人擔心随着程序模型被淘汰，原本基于各獨立程序的隔離性将被打破，導緻系統的整體健壯性受到破壞。
盡管如此，大部分 PostgreSQL 開發者還是以謹慎樂觀的态度支援、至少願意嘗試這一改動。EnterpriseDB 副總裁、首席資料庫科學家，PostgreSQL 主要貢獻者 Robert Haas 表示，PostgreSQL 在大型系統上的擴充性确實不佳，主要就是因為所有程序都在消耗資源。“其他很多資料庫并不存在這個問題。如果不進行某種重大的架構變更，PostgreSQL 将無法克服這個難題。”
也許單純轉向線程模型可能還不夠，但他認為這将為其他後續改進開個好頭。
從提案到現實
将 PostgreSQL 伺服器的核心轉移至單一位址空間，幾乎必然帶來諸多挑戰。正如 Haas 等研究人員所指出，其中最大的問題就是伺服器“目前正頻繁使用全局變量”。具體來講，當每個伺服器程序都擁有自己的集合時，全局變量就能良好運作；而在用線程加以替代時則會引發問題。根據 Konstantin Knizhnik 的說法，PostgreSQL 伺服器目前使用約 2000 個全局變量。
開發團隊随後讨論了該問題的幾種解決思路。首先是将所有全局變量拉入統一的“會話狀态”結構，而這套結構具備線程本地化屬性。但考慮到需要建立并維護的是需要容納 2000 個變量成員的複雜結構時，這個提議因為可行性太低而很快失去了吸引力。另一種方法是直接把所有全局變量放入線程本地存儲内，這種方法倒是簡單可行，但大量使用線程本地存儲會導緻性能損失，損耗轉為線程模型帶來的收益。Haas 指出，對全局變量做明确标記（包括将其放入線程本地存儲）本身也有積極的意義，可說為減少全局變量的使用開了個好頭。Freund 贊同這個觀點，并表示即使後續沒有全面轉向線程模型，這項調整也将有所回報。
但 Freund 也警告稱，将全局變量轉移至線程本地存儲隻是這項工作中最簡單的部分：
在此之後，重新設計 postmaster、定義如何處理擴充庫、擴充相容性、開發工具以實作線程化 postgres、在會話生命周期内建立新的記憶體配置設定和釋放機制（以往是通過退出程序實作記憶體釋放）、保證變更的可審查性和可移植性等等，全都是更加困難的工作。
這裡還有一個讨論熱度不高、但卻非常有趣的觀點，即 Knizhnik 已經完成了 PostgreSQL 的線程端口。他說全局變量的問題并不是那麼難以解決。他在配置資料、錯誤處理、信号等方面遇到的麻煩還更多。另外，支援由外部維護的擴充也是個重大挑戰。可盡管如此，他還是認可轉向線程模型所帶來的一系列顯著回報，隻是提醒項目決策層在采取任何行動之前，務必要認真做好研究分析。
PostgreSQL 開發團隊還想到了另一個複雜問題，即是否可能同時支援基于程序和基于線程兩種模式。在繼續支援程序模式的同時引入線程架構不僅極為困難，而且會顯著增加項目的總體維護負擔。但 Haas 堅持認為，PostgreSQL 絕對不可能徹底放棄對程序模式的支援。畢竟線程在一部分用例中的性能反而更差，也有不少重要擴充無法線上程模式下正常運作。他強調稱，隻有在确認線程架構運作良好之後，才可能認真讨論要不要徹底放棄程序支援。
目前無論是從郵件讨論還是從社交媒體平台投票結果來看，大多數 PostgreSQL 開發者認同架構轉換的理論收益。
并且，資料庫管理系統 Peloton 早在 2015 年就已經嘗試讓 PostgreSQL 多線程化了。至于 PostgreSQL 本身，從讨論到具體實施落地還有很長的路要走，更重要的是，需要有人主動請纓、表示願意投入時間來推進這項工作。
Peloton 的《Postgres 架構變更公告》：
最初，Postgres 采用的是多程序架構。其中主程序名為 Postmaster，負責處理 Postgres 接收到的請求，以及啟動、關閉等系統層面的操作。請注意，Postmaster 本身并不執行這些操作，而會派生出子程序來執行操作。再有，處理使用者查詢的 backend 也是由 Postmaster 分叉而來。這種架構非常适合基于磁盤的資料庫，因為磁盤可以作為大容量共享存儲。由于 peloton 充當主記憶體資料庫，多程序架構導緻不同後端和 peloton 資料庫間的資訊共享變得極其困難。在早期的嘗試中，我們曾考慮用共享記憶體讓 peloton 從每個分叉的 backend 處擷取查詢計劃和其他資訊。但結果證明其性能慢得令人無法接受，是以我們最終決定将 Postgres 轉為多線程架構！
參考連結：
https://news.ycombinator.com/item?id=36393030
https://github.com/cmu-db/peloton/wiki/Postgres-Modifications
本文轉載來源：
https://www.infoq.cn/article/VVCTQbCV1rKcZoMD3TKR