數據庫即架構：把所有業務邏輯，甚至是Web服務器都塞進 PostgreSQL 里
當前位置：點晴教程→知識管理交流
→『 技術文檔交流 』
數據庫是業務架構的核心，是不言自明的共識。但如果我們更進一步，將數據庫作為業務架構本身，將業務邏輯甚至 HTTP Server 都放入數據庫中，又會有怎么樣的火花？ 在1月4日舉辦的第七屆PG生態大會上，我邀請尤里來中國，進行了題為《數據庫驅動未來》的主題分享。 他拋出了這個觀點 —— 數據庫就是業務架構。簡單說，他的開源 PostgreSQL 項目 —— Omnigres ，嘗試把所有應用的業務邏輯，甚至是 HTTP 服務器都放入 PostgreSQL 數據庫中。
如果你覺得這聽上去有點不靠譜，先別急著下結論 —— 我也曾親眼目睹過這樣的成功實踐，所以今天就來和大家探討下這個有趣的話題。 數據庫是架構的核心
數據庫祖師爺邁克·石破天（Michael Stonebraker）有句名言：“如果你給我看軟件架構，我對你的業務一無所知；但如果你給我看數據模型，我就能精準知道你的業務是干嘛的” 無獨有偶，微軟的 CEO 納德拉也公開表示：我們今天所稱的軟件，其實只是數據庫上的一個華麗界面。他將其簡化為一個叫“CRUD”的概念：創建（Create）、讀取（Read）、更新（Update）和刪除（Destroy）。 也就是說，你喜歡的那些應用程序，不過是包裝精美的數據庫操作界面而已。BTW， Nadella 還提出 SaaS is Dead：因為以后 Agent 可以直接繞過中間商，代替前后端去讀寫數據庫了。
即使在 GenAI 爆火的當下，絕大多數信息系統的整個 IT 技術棧依然是以數據庫為核心設計的。無論業務架構怎么折騰，底層的東西永遠是萬變不離其宗。所謂的分庫分表，幾地幾中心，異地多活這些架構花活，說到底也就是數據庫的不同使用方式罷了。
數據庫是業務架構的核心，是不言自明的共識。但如果我們更進一步，將數據庫作為業務架構本身，又會如何？ 什么，還能這么玩在 PG 生態大會上，尤里展示了一個思路：把所有業務邏輯，甚至是Web服務器都塞進 PostgreSQL 里。比如可以通過寫存儲過程，把原本后端的一部分功能直接放到數據庫里執行。為此，他還基于 PG 擴展做了很多“標準庫”，從 HTTP、vfs、os 到 Python 模塊，都可以內嵌在 PostgreSQL 中。 讓我們來看一個有趣的例子，在 PostgreSQL 中執行以下 SQL，將會啟動一個 Web 服務器，將
是的，夭壽啊，PostgreSQL 數據庫竟然拉起來了一個 HTTP 服務器，默認跑在 8080 端口！你可以把它當成 Nginx 用！
但更重要的是，你還可以將任意的 PostgreSQL 函數（支持 20 多種存儲過程語言）掛載到 HTTP 端點上，實現你想要的任何東西。像這樣的 Omni 擴展總共有 33 款，當然也不要忘了 PG 生態里還有接近 400 個開箱即用的擴展插件可以提供各種功能
這一套擴展全家桶，提供了在 PostgreSQL 中進行 Web 開發的能力！ 在數據庫中跑Web服務器是餿主意嗎？PostgREST 和 Postgraphile 這樣的工具，可以將設計良好的 PostgreSQL Schema 直接轉化為開箱即用的 RestAPI， 而類似 Omnigres 這樣的工具干脆百尺竿頭更進一步，直接讓 HTTP 服務器運行在了 PG 數據庫內部！
目前來說，這種實踐絕對算不上主流。站在一個 DBA 的角度來講，我肯定認為這是一個給 DBA 找麻煩的餿主意。但站在一個開發者，特別是前端開發者的角度來說，我認為這個主意還是很有意思，值得探索的！因為確實很省事 —— 前端一套 Next.js 一把梭，后端一個數據庫全部搞定了，架構簡單無比。 早先在探探在使用 PostgreSQL 時，幾乎所有的業務邏輯（甚至推薦算法）都在 PostgreSQL 里實現，后端只負責很輕的一層封裝 只不過，這種做法對開發者、DBA 的綜合技能要求較高，畢竟寫存儲過程、維護復雜的數據庫邏輯不是一件輕松活兒。而且那個時候，數據庫通常也是整個架構中的性能瓶頸，哪有余量給這些花活。 但現在隨著兩個關鍵要素的變化（AI 的出現與硬件性能的嚴重過剩），利弊權衡發生了改變。GPT 顯然已經達到了能夠熟練編寫存儲過程的中高級開發者的水準，而遵循摩爾定律發展的硬件直接把單機性能推到了一個匪夷所思的地步。 數據庫中跑Web服務器的利弊在數據庫中跑Web Server這種模式有一些好處： ?你的業務邏輯，業務模型，業務數據放在一個地方，用統一的方式來管理。?你的業務代碼就是一個放著 Python / JS / Java 等存儲過程的目錄，更新發布，CI/CD 都非常簡單。如果負載高要降級，把非關鍵的存儲過程刷新或在數據庫里設置標記就實現了。?存儲過程避免了應用后端與數據庫的多次網絡RT，通常有更好的延遲表現（總吞吐量會下降，但以當下的硬件水平與性能余量，Who cares！）?你所需要的只有一個 PostgreSQL 數據庫，后端融入到數據庫里，運維管理極為便利，方便進行單元化部署與敏捷交付。 這種模式的主要弊病有兩個： 1.互聯網時代，數據庫是瓶頸，難以伸縮，大家希望通過讓應用承擔更多，數據庫退后的方式解決 scale 的問題。2.對開發者水平的要求太高了，用好數據庫對開發者本身已經是一件很有挑戰的事情，而寫存儲過程的技能在年輕一代開發者中幾乎已經失傳了，維護管理更是對 DBA 提出了極高的要求。 但隨著時代發展，這兩個主要問題得到了解決：硬件的發展讓數據庫的性能重新出現 巨大 的富余。AI 的出現讓開發者的水平（AI加持下）得到了突飛猛進的發展。 前者讓數據庫性能余量重新回到了一個可以在大多數場景下容納業務邏輯的地步，后者解決了開發者不會寫存儲過程的問題。因此在當下，數據庫即架構（DBaaA）成為了一種非常值得探索的實踐。 數據庫即架構理念有一個非常成功的案例 —— Supabase —— 可能有 80% YC 創業公司都在使用它。Supabase 號稱自己是一個 Backend as a Service，將 PostgreSQL，對象存儲，以及 EdgeFunction 封裝成為一整個運行時，然后將后端與傳統意義上的數據庫整體打包成為一個 “新的數據庫”。
但 Supabase 本身仍然是一系列容器組件縫合拼接起來的，如果這種架構走到極致，大概會變成 Omnigres 的樣子 —— 一個運行著 HTTP 服務器的 PostgreSQL，Nothing Else。
這也許意味著軟件架構的鐘擺重新回歸簡單 —— 繞開花里胡哨的中間件，前端直接訪問數據庫，甚至連傳統移動/Web前端也許最終也會被 LLM Agent 與其他 Interface 替代。最后直接由 Agent 代理訪問數據庫。
那么要不要試試呢？順便一提，我們已經與 Omnigres 達成了合作。昨天在 Omnigres 創始人 Yurii 的幫助下，我為 Omnigres 構建了主流 Linux 上的 RPM/DEB 包，包含了了以下 33 個擴展插件，開箱即用。（https://ext.pigsty.io/#/omni）
Omnigres 提供的 33 個 PG 擴展插件現在可以在 Pigsty 中開箱即用，而 Omnigres 提供的容器鏡像中也包括了 Pigsty 的 300+ 擴展，可謂開源生態互惠共贏之典范。
如果你想試試在數據庫里寫應用，一套 PG 打天下的刺激玩法，確實可以試試這個！ References
閱讀原文：原文鏈接 該文章在 2025/1/23 10:18:18 編輯過 |
關鍵字查詢
相關文章
正在查詢... 
|
400 186 1886
?