ITPUB "

作者|馮

轉(zhuǎn)移自|非法添加馮

微信官方賬號ID | addvon

PostgreSQL的口號是“世界上最先進(jìn)的開源關(guān)系數(shù)據(jù)庫”，但我覺得這個(gè)口號不夠明確。什么是“高級”？而且，乍一看，MySQL的口號“世界上最流行的開源關(guān)系數(shù)據(jù)庫”，有碰瓷的嫌疑。我想說，PG的特點(diǎn)最生動的描述應(yīng)該是:一個(gè)全棧數(shù)據(jù)庫專門化了多久，全世界吃了多少招。

全棧數(shù)據(jù)庫

成熟的應(yīng)用可能會用到很多數(shù)據(jù)組件(功能):緩存、OLTP、OLAP/批處理/數(shù)據(jù)倉庫、流處理/消息隊(duì)列、搜索索引、NoSQL/文檔數(shù)據(jù)庫、地理數(shù)據(jù)庫、空 inter-database、時(shí)序數(shù)據(jù)庫、圖形數(shù)據(jù)庫。在傳統(tǒng)架構(gòu)選擇中，可能會結(jié)合多種組件，比如Redis+MySQL+Greenplum/Hadoop+Kafuka/Flink+Elastic Search，一套組合拳基本可以滿足大部分需求。但更值得注意的是異構(gòu)系統(tǒng)的集成:很多代碼都是重復(fù)的、繁瑣的搬磚代碼，做著把數(shù)據(jù)從A組件移到B組件的事情。

在這里，MySQL只能扮演OLTP關(guān)系數(shù)據(jù)庫的角色，但是如果是PostgreSQL，它可以有多個(gè)角色，一個(gè)人處理所有的角色，例如:

OLTP：事務(wù)處理是PostgreSQL的本行OLAP：citus分布式插件，ANSI SQL兼容，窗口函數(shù)，CTE，CUBE等高級分析功能，任意語言寫UDF流處理：PipelineDB擴(kuò)展，Notify-Listen，物化視圖，規(guī)則系統(tǒng)，靈活的存儲過程與函數(shù)編寫時(shí)序數(shù)據(jù)：timescaledb時(shí)序數(shù)據(jù)庫插件，分區(qū)表，BRIN索引空間數(shù)據(jù)：PostGIS擴(kuò)展（殺手锏），內(nèi)建的幾何類型支持，GiST索引。搜索索引：全文搜索索引足以應(yīng)對簡單場景；豐富的索引類型，支持函數(shù)索引，條件索引NoSQL：JSON，JSONB，XML，HStore原生支持，至NoSQL數(shù)據(jù)庫的外部數(shù)據(jù)包裝器數(shù)據(jù)倉庫：能平滑遷移至同屬Pg生態(tài)的GreenPlum，DeepGreen，HAWK等，使用FDW進(jìn)行ETL圖數(shù)據(jù)：遞歸查詢緩存：物化視圖

以膨脹為六儀，天地?zé)o處不在。

用FDW儀式，用青梅儀式，

用西圖對待東方，用時(shí)標(biāo)對待南方。

用PostGIS迎接西方，用Pipeline迎接北方。

——《李周筆記》

在探索的舊架構(gòu)中，整個(gè)系統(tǒng)是圍繞PostgreSQL設(shè)計(jì)的。每天有數(shù)百萬的活動，有數(shù)百萬的全局DB-TPS，有數(shù)百TB的數(shù)據(jù)，數(shù)據(jù)組件只用PostgrSQL。獨(dú)立的數(shù)據(jù)倉庫、消息隊(duì)列和緩存都是后來才引入的。而且這只是一個(gè)驗(yàn)證過的尺度，進(jìn)一步按PG完全可行。

所以在相當(dāng)大的規(guī)模上，PostgreSQL可以起到全才的作用，一個(gè)組件可以作為多組件使用。雖然在某些方面可能不如專用元器件，但一點(diǎn)也不差。單個(gè)數(shù)據(jù)組件的選擇可以大大降低項(xiàng)目的額外復(fù)雜性，這意味著可以節(jié)省大量成本。它把十個(gè)人能做的變成一個(gè)人能做的。

對于大多數(shù)應(yīng)用來說，在其生命周期中沒有超出Pg能力的數(shù)據(jù)順序。為不必要的規(guī)模進(jìn)行設(shè)計(jì)是浪費(fèi)精力，這實(shí)際上是一種過早優(yōu)化的形式。另外，只有當(dāng)沒有一款軟件能夠滿足你所有的需求時(shí)，才會有拆分和整合的利弊取舍。集成多種異構(gòu)技術(shù)是一項(xiàng)艱巨的工作。如果有一種技術(shù)可以滿足您的所有需求，那么使用這種技術(shù)是最好的選擇，而不是試圖用多個(gè)組件來重新實(shí)現(xiàn)它。

當(dāng)業(yè)務(wù)規(guī)模增長到一定程度時(shí)，可能需要使用基于微服務(wù)/總線的體系結(jié)構(gòu)，將數(shù)據(jù)庫的功能分成多個(gè)組件。但是PostgreSQL的存在，大大的把這種取舍的門檻往后推了推，拆分后依然可以發(fā)揮重要作用。

易于操作和維護(hù)

當(dāng)然，除了功能強(qiáng)大，Pg的另一個(gè)重要優(yōu)勢就是友好的操作和維護(hù)。有許多非常實(shí)用的功能:

DDL能放入事務(wù)中，刪表，TRUNCATE，創(chuàng)建函數(shù)，索引，都可以放在事務(wù)里原子生效，或者回滾。這就能進(jìn)行很多騷操作，比如在一個(gè)事務(wù)里通過RENAME，完成兩張表的王車易位。能夠并發(fā)地創(chuàng)建、刪除索引，添加非空字段，重整索引與表（不鎖表）。這意味著可以隨時(shí)在線上不停機(jī)進(jìn)行重大的模式變更，按需對索引進(jìn)行優(yōu)化。復(fù)制方式多樣：段復(fù)制，流復(fù)制，觸發(fā)器復(fù)制，邏輯復(fù)制，插件復(fù)制等等。這使得不停服務(wù)遷移數(shù)據(jù)變得相當(dāng)容易：復(fù)制，改讀，改寫三步走，線上遷移穩(wěn)如狗。提交方式多樣：異步提交，同步提交，法定人數(shù)同步提交。這意味著Pg允許在C和A之間做出權(quán)衡與選擇，例如交易庫使用同步提交，普通庫使用異步提交。系統(tǒng)視圖非常完備，做監(jiān)控系統(tǒng)相當(dāng)簡單。FDW的存在讓ETL變得無比簡單，一行SQL就能解決。FDW可以方便地讓一個(gè)實(shí)例訪問其他實(shí)例的數(shù)據(jù)或元數(shù)據(jù)。在跨分區(qū)操作，數(shù)據(jù)庫監(jiān)控指標(biāo)收集，數(shù)據(jù)遷移等場景中妙用無窮。同時(shí)還可以對接很多異構(gòu)數(shù)據(jù)系統(tǒng)。

功能很多，就不一一列舉了。

生態(tài)健康

PostgreSQL擁有健康的生態(tài)和非常活躍的社區(qū)。

與MySQL相比，PostgreSQL的一大優(yōu)勢是協(xié)議友好。Pg采用類似BSD/MIT的PostgreSQL協(xié)議，幾乎就是說只要你不打著PG的旗號進(jìn)行詐騙和欺騙，你就可以為所欲為，換個(gè)皮賣了。你不會看到很多國內(nèi)的數(shù)據(jù)庫，或者很多“自主開發(fā)的數(shù)據(jù)庫”其實(shí)是Pg的換膚或者二次開發(fā)產(chǎn)品。

當(dāng)然也有很多衍生產(chǎn)品會回饋到主干上，比如timescaledb、pipelinedb、citus，這些都是基于PG的，最終成為原生PG的插件。很多時(shí)候，如果想實(shí)現(xiàn)一個(gè)功能，可以通過搜索找到對應(yīng)的插件或者實(shí)現(xiàn)。開源，還是想談點(diǎn)感受。

Pg的代碼質(zhì)量挺高的，評論很明確。c的代碼讀起來有一種Go的感覺，代碼可以當(dāng)做文檔來讀。你可以從中學(xué)到很多。相比之下，其他數(shù)據(jù)庫，比如MongoDB，一目了然就放棄了閱讀。

至于MySQL，社區(qū)版用的是GPL協(xié)議，其實(shí)很傷人。要不是GPL感染，怎么會有這么多基于MySQL的開源數(shù)據(jù)庫？而且MySQL還在龜殼手里，把球托在別人手里不是明智的選擇，更不是行業(yè)內(nèi)的毒瘤。Facebook修改反應(yīng)協(xié)議的混亂是過去的一個(gè)教訓(xùn)。

問題

當(dāng)然，如果有什么缺點(diǎn)或遺憾，還是有幾個(gè):

因?yàn)槭褂昧薓VCC，數(shù)據(jù)庫需要定期VACUUM，需要定期維護(hù)表和索引避免膨脹導(dǎo)致性能下降。沒有很好的開源集群監(jiān)控方案（或者太丑?。?，需要自己做。慢查詢?nèi)罩竞推胀ㄈ罩臼腔煸谝黄鸬?，需要自己解析處理。官方Pg沒有很好用的列存儲，對數(shù)據(jù)分析而言算一個(gè)小遺憾。

當(dāng)然都是小病小病，但真正的問題可能與技術(shù)無關(guān)…

歸根結(jié)底，MySQL確實(shí)是最受歡迎的開源關(guān)系數(shù)據(jù)庫。沒有辦法。很多寫Java和PHP的人一開始都用MySQL，所以Pg招人比較難是事實(shí)，很多情況下只能自己培養(yǎng)。不過看DB Engines上的流行趨勢，未來還是很光明的。