PostgreSQL 參與某沙龍的演講稿與回顧

• 2020 年 3 月 26 日
• 筆記

最近參與了一個沙龍的知識分享，以下是這次沙龍中我的演講稿。

正文：

————————————————————————————

Hello 我是Austin,目前在從事資料庫架構與資料庫管理方面的工作，目前也在維護一個公眾號，進行資料庫知識的分享和討論。今天會和大家來分享資料庫選型方面的一些個人看法。

這裡主要從四個角度來分析和探討，我想此時已經有同學就產生一個疑問，為什麼不從技術的角度來聊，怎麼選資料庫，尤其相互比較更好。我想解釋一下，為什麼不用技術來開始比較，因為技術本身是有其適用的場景的，脫離了場景來討論一個技術問題本身就是偽命題。沒有一個技術是千金方，所以如果一上來就比較的話，就會產生一個問題，我說A，大家不熟悉A場景，所以大家從B場景來理解，那我說的大概率都是不對的。舉一個最簡單的例子，MYSQL好還是PostgreSQL好，其實這個問題本身沒有太大的意義，因為各有各的好。

任何一個技術都是有對應的需求，沒有需求的技術，很可能他就滅絕了，所以脫離需求來講我怎麼選擇哪項技術，或者那種資料庫，就有點盲人摸象了。

從需求的角度來分析，我們要從不同的角度來分析這個需求中，到底哪些是真的必要，哪些是非必要的選項，哪些是我們要堅持的，那些是可以妥協的，從這麼多年的工作經驗來說，一個項目選擇的技術方向，例如一個資料庫的被選擇是有，天時地利人和的，例如 這個項目的架構師，投資商，輿論等等都可能影響你的資料庫最終的選型， 這個項目的預算是多少，這個項目的開發周期，項目的人員精通什麼技術，等等這些都是問題，都會造成你最後選擇的資料庫技術的不同，來滿足上面的問題。

從cost的角度來看得話，其實我們需要考慮以下成本，人力成本，這非常重要，舉例使用PostgreSQL 資料庫作為我們目前的某個項目的資料庫，但需要我們找到熟練通過JAVA 來操作PG，或有這方面經驗的開發人員，目前需要培養，很難找到現成的人員，並且項目的時間短，PG的DBA 也比較難找，此時大概率我們就不會選擇PG作為此次項目的主要資料庫選擇。

一項技術的易用性也是要考慮的問題，或者比如在解決一些開發方面的問題，是否通過資料庫的技術能方便的化解，更便捷的實施和部署，這都是一個資料庫是否能成為項目中使用資料庫的一個維度點。

從學習的成本角度，最簡單的事情，如果我是一個生手，想掌握一項技術，官方的文檔以及其解決方案是否能容易的被找到，並確認，知識圈是否能輕易的獲得，周圍掌握這項技術的人是否容易找到並請教，或者我們的線上或者線下的課程能否滿足我們的需求等等。

其實說到這裡，大家可能就更能理解，今天為什麼沒有從技術的角度來進行相關的資料庫方面的對比和解讀。

為什麼是COST 優先，不光是軟體的項目，各種的項目都要有產出比，所以這是成本的問題。那怎麼在一個項目中節省成本，是非常重要的，一個項目或企業在使用一項技術的時候，時刻都要想到成本，大部分以技術為導向的技術工作者，容易忽略這個問題，或者接觸不到這個層次上面的問題。

一個資料庫的使用和選擇與很多情況有關，例如資料庫廠商的某些問題，國與國之間的關係問題，企業與國家之間的衝突問題，大家可以關注最近華為大量招聘，ORACLE 和 PG 雙料的DBA，因為公司開始啟動了去ORACLE的項目，這就是一個上面的案例。公司的體量不大，那就需要考慮成本，一個公司的體量太大，那就更要考慮成本。一套ORACLE 加符合他的伺服器的成本可能就需要幾十萬,或更貴，這就對企業產生了經濟壓力，尤其最近幾年經濟比較低緩的情況下，更明顯。

另外，還有一個種認為，開源資料庫不穩定，功能差，這可能都是早期使用過MYSQL 後的架構師和開發人員留下的刻板印象。實際上開源資料庫不僅僅有MYSQL，比如POSTGRESQL , MONGODB ,REDIS, Cassandra,並且MYSQL 也在進步, 不能用刻舟求劍的方式來看問題。

還有一種觀點，開源的資料庫的人才不好找，這個不是沒有道理，他可能不如ORACLE來培養的人才流水線化的方式更快速，導致開源資料庫的人才比較難找，並且生長的也慢，怎麼認證更是一個問題，尤其商業集團裡面他們也是要一些證書之類的東西，證明你有這項技能。

淘寶曾經有全亞洲最大的ORACLE資料庫集群，再有錢的公司也要核算成本，商人算計的都是利益，那作為高級打工仔要體現價值，並不是收費的資料庫不好，是因為免費的已經達到了我們要的功能需求，降低成本，體現價值，何樂不為，如果還能順便來將這項技術作為一種架構推廣，並賺取利益不是更好。

下面從架構的角度來看資料庫的選型，早期大量的銀行，電信，傳統企業裡面大部分都是購買的商業的系統，或整體的商業解決方案，比如小型機+BD2，或者ORACLE 的資料庫，從成本的角度來，剛才已經講過了，如果開源資料庫能滿足需求，並降低成本何樂而不為。

從開發的角度，現今的業務的變化速度，要比之前業務變化的速度快的多，這也就導致新的開發系統的方式的轉變，微服務方式的興起，來應對多變複雜的業務環境。從架構的角度來說，ORACLE 和 DB2 也越來越不適合當前的軟體的開發潮流和趨勢。

從上圖看，這樣的設計對於現在的企業的需求滿足是有問題的，從資料庫的角度，如果ORACLE DOWN掉，我們的所有的業務模組全部DOWN掉，如果我們把每個業務模組都分別連接到單個的ORACLE的資料庫上，成本又不允許，或者隨著業務的擴展，以後的擴展的瓶頸可能都在資料庫上，因為都在一個資料庫，沒有解耦，將這些模組的資訊交換都在資料庫內部做了。以後的問題就會越來越多。

所以不再使用ORACLE 的原因也很多，從架構的方面考慮我們沒有必要再在每個環節要使用這麼重的資料庫。

這裡的擴展指的是橫向思維，還是縱向思維的模式來進行擴展，早些年間我們大部分都是通過縱向的手段來進行問題的解決因為簡單，奏效，而橫向的方式來解決問題，則需要的技術水平是不一樣的，他的思維模式複雜，需要軟體架構，硬體架構，資料庫架構，全方面的做出努力，資料庫為了應對橫向擴展，引入例如分散式的資料庫等等。

從運維的角度，從原來的一台大型機，或幾台資料庫的伺服器，變成現在很多企業動輒成百上千的資料庫伺服器群組。應對性能和業務的擴展。所以現在的運維在監控，管理，備份等等面對的需求也都變化了，自動化管理的方式需求越來越多。

程式的複雜度，程式的複雜度與業務，和底層的架構都有關，實際上選擇了不同的資料庫後，資料庫的使用的方式就有所改變，例如某些開源的資料庫，造成資料庫本身功能的弱化，程式承擔原有資料庫方面的可以做的工作，導致資料庫承載能力的簡單化和容器化。

為什麼這樣說，不是每個業務面對的都是，簡單的，高並發，的業務邏輯，例如秒殺，點餐，叫車，實際上大面積的企業，需要的不是高並發，而是複雜邏輯的處理，複雜事務的處理，這也是為什麼至今還有大量的企業，在使用ORACLE的原因，因為他能在可控的成本下，滿足這些需求。並且傳統企業很難快速提高目前的軟體開發水平，以及解決複雜邏輯方面，去使用MYSQL 資料庫達到理想的或同等與原來的水平。

例如：並行化處理SQL ， 多種複雜的JOIN的處理， 高密度的存儲過程的需求，主外鍵關係處理，在程式還是資料庫的問題，如果延續傳統企業不動原有架構的方式下，和開發軟體的方式的情況下，則分散式和MYSQL 解決此類問題比較困難。

那這就提出一個問題了，ORACLE 直接數據遷移，不需要再系統架構上做推翻性的變化，或徹底拋棄現有架構，那資料庫的選擇的範圍可能就不如我們想像的那樣多。

從實際問題的角度來看資料庫的選型，我們可以通過實際的幾個例子來看

1 應用開發中，需要進行模糊查詢，%值%的方式。

面對不同的資料庫的解決方式

1 postgresql 對需要進行查詢的欄位添加 GIST 或者 GIN 索引，然後直接使用我們最熟悉的語句去查詢

2 其他資料庫，開啟全文索引的功能，或者引入ES的方式來處理需求，同事程式上也需要進行特殊的處理，合併結果。

從各種角度考慮，開發成本，複雜度，運維成本等等，我想大家應該可以進行相關的比較。

2 一家傳統企業，開發人員的水平一般，目前開發的財務系統由於要求的開發速度快，業務邏輯也比較複雜，其中開發人員需要在資料庫端建立部分存儲過程，簡化程式設計進行一些批操作，或者一些複雜事務的需求。

在這樣的情況下，如果堅持使用某種流行的開源資料庫，則存儲過程的需求可能就不能再資料庫端來實現業務邏輯，需要將其在程式端來實現，所以會將事務打散，並且部分使用2段式提交的方式來解決複雜的問題，系統和資料庫的交互次數會直線升高，並且還要注意某些語句的寫法，否則很可能性能低下。

那從開發者和老闆的角度，這樣的方式可能就不會滿意，開發人員也會怨聲載道，那我們就一種和ORACLE 類似解決方案的匹配的開源資料庫。來滿足我們上面提到的 成本，架構方面的滿足，並降低複雜度。

3 某軟體開發企業，開發訂製化的軟體，提供給甲方的時候，需要打包整體運維部分一併提供給甲方，甲方是一家跨國外資企業，法務部門對合約進行審核，發現軟體開發企業提供資料庫雖然是開源產品，但其中的開源協議不適於商業化，對軟體公司提供的產品提出了異議

最後這個案例，其實和我們的軟體開發商是有關的，因為軟體開發商除了開發系統也提供包含運維等等一整套的服務和軟體的維護安裝等等服務，如果此時我們的開發商將軟體產品與MYSQL資料庫一併提供給企業，則這樣是不符合相關法律的，有人可能說那讓甲方自己裝MYSQL 資料庫不就行了，其實我們是知道一些企業，尤其是外企對於法律文書方面是非常在意的，尤其是合約，很可能就因為一個你認為不是問題的問題，和你解除合約。PG 遵循的是BSD 協議，在法律上面臨的風險會比較小。

最後一個問題，可能會跟我們自身從業者的自身利益有關，也就是職業規劃，現在我們從JD上招聘架構或者DBA 的時候，尤其DBA的時候，很少會看到只會一種資料庫就可以的，基本上2-3種，即使知識招一種，則大概率是這家公司不止一種資料庫，但需要專人來管理某種資料庫。

這就會涉及我們的職業的發展的寬度的問題，如果公司從ORACLE轉型到其他資料庫，你在開始學，那公司是不是要考慮你職位存在的必要性。

我經常聽到一些DB的朋友說，別學PG，沒有發展，首先先不說PG有沒有發展，這樣的話其實10年前我就聽到過，不過主角是MYSQL ，說別學MYSQL 沒有發展。

從學習的角度來看，掌握的資料庫種類越多，你的思路就越開闊，處理問題的角度和思路都會不一樣。，在面臨不同的項目中，能過提供的處理方法不會只有一種，並時常會有一種無力感。

那麼我們目前的頭部的公司對資料庫的態度來看，也是從未偏愛過一家的，騰訊的TDSQL ,TBASE 就是騰訊對資料庫的態度，MYSQL + POSTGRESQL 的混合方式，其他公司也是一樣，這裡不再舉例了。所以一庫走天下的時代已經過去了，我們為什麼不充實自己，提高自己的附加值，俗話說的好，多條後路多條命，尤其在當下競爭激烈的環境。