PostgreSQL正在吞噬數(shù)據(jù)庫世界
當(dāng)前位置：點(diǎn)晴教程→知識管理交流
→『 技術(shù)文檔交流 』
PostgreSQL 并不是一個簡單的關(guān)系型數(shù)據(jù)庫，而是一個數(shù)據(jù)管理的抽象框架，具有吞噬整個數(shù)據(jù)庫世界的力量。而這也是正在發(fā)生的事情 —— “一切皆用 Postgres” 已經(jīng)不再是少數(shù)精英團(tuán)隊的前沿探索，而是成為了一種進(jìn)入主流視野的最佳實(shí)踐。 OLAP 領(lǐng)域迎來踢館者 在 2016 年的一次數(shù)據(jù)庫沙龍里，我提出了一個觀點(diǎn)： 現(xiàn)在 PostgreSQL 生態(tài)的一個主要遺憾是，缺少一個足夠好的列式存儲分析插件來做 OLAP 分析。盡管PostgreSQL 本身提供了很強(qiáng)大的分析功能集，應(yīng)付常規(guī)的分析任務(wù)綽綽有余。但在較大數(shù)據(jù)量下全量分析的性能，相比專用的實(shí)時數(shù)倉仍然有些不夠看。 以分析領(lǐng)域的權(quán)威評測 Clickbench 為例，我們在其中標(biāo)注出了 PostgreSQL 與生態(tài)擴(kuò)展插件以及兼容衍生數(shù)據(jù)庫在其中的性能表現(xiàn)。原生未經(jīng)過調(diào)優(yōu)的 PostgreSQL 表現(xiàn)較為拉垮（x1050），但經(jīng)過調(diào)優(yōu)后可以達(dá)到（x47）；此外還有三個與分析有關(guān)系的擴(kuò)展：列存 Hydra（x42），時序擴(kuò)展 TimescaleDB（x103），以及分布式擴(kuò)展 Citus（x262）。
這樣的分析性能表現(xiàn)不能說爛，因?yàn)楸绕?nbsp;MySQL，MariaDB 這樣的純 OLTP 數(shù)據(jù)庫的辣眼表現(xiàn)（x3065,x19700）確實(shí)好很多；但第三梯隊的性能表現(xiàn)也絕對說不上足夠好，與專注于 OLAP 的第一梯隊組件：Umbra，ClickHouse，Databend，SelectDB（x3~x4）相比，在分析性能上仍然有十幾倍的性能差距。食之無味，棄之可惜。 而 DuckDB 則專注于 OLAP ，將分析性能這件事做到了極致（x3.2） —— 略過第一名 Umbra 這種學(xué)術(shù)研究型閉源數(shù)據(jù)庫，DuckDB 也許是 OLAP 實(shí)戰(zhàn)性能最快的數(shù)據(jù)庫了。它并不是 PG 的擴(kuò)展插件，但它是一個嵌入式文件數(shù)據(jù)庫，而 DuckDB FDW 以及 pg_quack 這樣的 PG 生態(tài)項(xiàng)目，能讓 PostgreSQL 充分利用 DuckDB 帶來的完整分析性能紅利！ ParadeDB 與 DuckDB 的出現(xiàn)讓 PostgreSQL 的分析性能來到了 OLAP 的第一梯隊與金字塔尖，彌補(bǔ)了 PostgreSQL 在 OLAP 性能這最后一塊關(guān)鍵短板。 分久必合的數(shù)據(jù)庫領(lǐng)域數(shù)據(jù)庫誕生伊始，并沒有 OLTP 與 OLAP 的分野。OLAP 數(shù)據(jù)倉庫從數(shù)據(jù)庫中“獨(dú)立”出來，已經(jīng)是上世紀(jì)九十年代時候的事了 —— 因?yàn)閭鹘y(tǒng)的 OLTP 數(shù)據(jù)庫難以支撐起分析場景下的查詢模式，數(shù)據(jù)量與性能要求。 在相當(dāng)一段時間里，數(shù)據(jù)處理的最佳實(shí)踐是使用 MySQL / PG 處理 OLTP 工作負(fù)載，并通過 ETL 將數(shù)據(jù)同步到專用的 OLAP 組件中去處理，比如 Greenplum, ClickHouse, Doris, Snowflake 等等。 與許多 “專用數(shù)據(jù)庫” 一樣，專業(yè)的 OLAP 組件的優(yōu)勢往往在于性能 —— 相比原生 PG 、MySQL 上有 1～3 個數(shù)量級的提升；而代價則是數(shù)據(jù)冗余、 大量不必要的數(shù)據(jù)搬運(yùn)工作、分布式組件之間缺乏一致性、額外的專業(yè)技能帶來的復(fù)雜度成本、學(xué)習(xí)成本、以及人力成本、 額外的軟件許可費(fèi)用、極其有限的查詢語言能力、可編程性、可擴(kuò)展性、有限的工具鏈、以及與OLTP 數(shù)據(jù)庫相比更差的數(shù)據(jù)完整性和可用性 —— 但這是一個合理的利弊權(quán)衡。 然而天下大勢，分久必合，合久必分。硬件遵循摩爾定律又發(fā)展了三十年，性能翻了幾個數(shù)量級，成本下降了幾個數(shù)量級。在 2024 年的當(dāng)下，x86 單機(jī)可以達(dá)到 512 核幾個TB的內(nèi)存，單卡 NVMe SSD 可達(dá) 64TB，全閃單機(jī)柜 2PB ；S3 這樣對象存儲更是能實(shí)現(xiàn)幾乎沒有上限的存儲。
硬件的發(fā)展解決了數(shù)據(jù)量的問題，而數(shù)據(jù)庫軟件的發(fā)展（PostgreSQL，ParadeDB，DuckDB）解決了查詢模式的問題，而這導(dǎo)致分析領(lǐng)域 —— 所謂的“大數(shù)據(jù)” 行業(yè)基本工作假設(shè)面臨挑戰(zhàn)。 正如 DuckDB 發(fā)表的宣言《大數(shù)據(jù)已死》所主張的：大數(shù)據(jù)時代已經(jīng)結(jié)束了 —— 大多數(shù)人并沒有那么多的數(shù)據(jù)，大多數(shù)數(shù)據(jù)也很少被查詢。大數(shù)據(jù)的前沿隨著軟硬件發(fā)展不斷后退，99% 的場景已經(jīng)不再需要所謂“大數(shù)據(jù)”了。 如果 99% 的場景甚至都可以放在一臺計算機(jī)上用單機(jī)/主從的 DuckDB 或 PostgreSQL 搞定，那么使用專用的分析組件還有多少意義？如果每臺手機(jī)都可以自由自主收發(fā)短信，那么 BP 機(jī)還有什么存在價值？（北美醫(yī)院還在用BP機(jī)，正好比也還有 1% 不到的場景也許真的需要“大數(shù)據(jù)”） 基本工作假設(shè)的變化，將重新推動數(shù)據(jù)庫世界從百花齊放的“合久必分”階段，走向“分久必合”的階段，從大爆發(fā)到大滅絕，大浪淘沙中，新的大一統(tǒng)超融合數(shù)據(jù)庫將會出現(xiàn)，重新統(tǒng)一 OLTP 與 OLAP。而承擔(dān)重新整合數(shù)據(jù)庫領(lǐng)域這一使命的會是誰？ 吞食天地的 PostgreSQL數(shù)據(jù)庫領(lǐng)域有許多“細(xì)分領(lǐng)域”：時序數(shù)據(jù)庫，地理空間數(shù)據(jù)庫，文檔數(shù)據(jù)庫，搜索數(shù)據(jù)庫，圖數(shù)據(jù)庫，向量數(shù)據(jù)庫，消息隊列，對象數(shù)據(jù)庫。而 PostgreSQL 在任何一個領(lǐng)域都不會缺席。 一個 PostGIS 插件，成為了地理空間事實(shí)標(biāo)準(zhǔn)；一個 TimescaleDB 擴(kuò)展，讓一堆“通用”時序數(shù)據(jù)庫尷尬的說不出話來；一個向量擴(kuò)展 PGVector 插件，更是讓整個專用向量數(shù)據(jù)庫細(xì)分領(lǐng)域 變成笑話。 同樣的事情已經(jīng)發(fā)生過很多次，而現(xiàn)在，我們將在拆分最早，地盤最大的一個子領(lǐng)域 OLAP 分析中再次見證這一點(diǎn)。但 PostgreSQL 要替代的可不僅僅是 OLAP 數(shù)倉，它的野望是整個數(shù)據(jù)庫世界！
用戶選擇 PostgreSQL 的原因：開源，先進(jìn)，擴(kuò)展。 為什么？因?yàn)?PGVECTOR 作者不需要操心數(shù)據(jù)庫的通用額外復(fù)雜度：事務(wù) ACID，故障恢復(fù)，備份PITR，高可用，訪問控制，監(jiān)控，部署，三方生態(tài)工具，客戶端驅(qū)動這些需要成百上千萬行代碼才能解決好的問題，只需要關(guān)注自己所需問題的本質(zhì)復(fù)雜度即可。
向量數(shù)據(jù)庫哪家強(qiáng)？ 再比如，ElasticSearch 基于 Lucene 搜索庫開發(fā)，而 Rust 生態(tài)有一個改進(jìn)版的下一代 Tantivy 全文搜索庫作為 Lucene 的替代；而 ParadeDB 只需要將其封裝對接到 PostgreSQL 的接口上，即可提供比肩 ElasticSearch 的搜索服務(wù)。更重要的是，它可以站在 PostgreSQL 巨人的肩膀上，借用 PG 生態(tài)的全部合力（例如，與 PG Vector 做混合檢索），不講武德地用數(shù)據(jù)庫全能王的力量，去與一個專用數(shù)據(jù)庫單品來對比。 可擴(kuò)展性帶來的另一點(diǎn)巨大優(yōu)勢是擴(kuò)展的可組合性，讓不同擴(kuò)展相互合作，產(chǎn)生出 1+1 >> 2 的協(xié)同效應(yīng)。例如，TimescaleDB 可以與 PostGIS 組合使用，提供時空數(shù)據(jù)支持；再比如，提供全文檢索能力的 BM25 擴(kuò)展可以和提供語義模糊檢索的 PGVector 擴(kuò)展組合使用，提供混合檢索能力。 再比如，分布式擴(kuò)展 Citus 可以將單機(jī)主從數(shù)據(jù)庫集群，原地升級改造為透明水平分片的分布式數(shù)據(jù)庫集群。而這個能力是可以與其他功能正交組合的，因此，PostGIS 可以成為分布式地理數(shù)據(jù)庫，PGVector 可以成為分布式向量數(shù)據(jù)庫，ParadeDB 可以成為分布式全文搜索數(shù)據(jù)庫，諸如此類。 更強(qiáng)大的地方在于，擴(kuò)展插件是獨(dú)立演進(jìn)的，不需要繁瑣的主干合并，聯(lián)調(diào)協(xié)作。因此可以 Scale —— PG 的可擴(kuò)展性允許無數(shù)個團(tuán)隊并行探索數(shù)據(jù)庫前研發(fā)展方向，而擴(kuò)展全部都是的可選的，不會影響主干核心能力的穩(wěn)定性。那些非常強(qiáng)大成熟的特性，則有機(jī)會以穩(wěn)定的形態(tài)進(jìn)入主干中。 通過極致可擴(kuò)展性的魔法，PostgreSQL 做到了守正出奇，實(shí)現(xiàn)了主干極致穩(wěn)定性與功能敏捷性的統(tǒng)一。扎實(shí)的基本盤配上驚人的演進(jìn)速度，讓它成為了數(shù)據(jù)庫世界中的一個異數(shù)，改變了數(shù)據(jù)庫世界的游戲規(guī)則。 改變游戲規(guī)則的玩家PostgreSQL 的出現(xiàn)，改變了數(shù)據(jù)庫領(lǐng)域的游戲規(guī)則：任何試圖開發(fā)“新數(shù)據(jù)庫內(nèi)核”的團(tuán)隊，都需要經(jīng)過這道試煉與考驗(yàn) —— 相比開源免費(fèi)、功能齊備的 Postgres，價值點(diǎn)在哪里？ 至少到硬件出現(xiàn)革命性突破前，實(shí)用的通用數(shù)據(jù)庫新內(nèi)核都不太可能誕生了，因?yàn)槿魏螁我粩?shù)據(jù)庫都無法與所有擴(kuò)展加持下的 PG 在整體實(shí)力上相抗衡 —— 包括 Oracle，因?yàn)?PG 還有開源免費(fèi)的必殺技。 而某個細(xì)分領(lǐng)域的數(shù)據(jù)庫產(chǎn)品，如果能在單點(diǎn)屬性（通常是性能）上相比 PostgreSQL 實(shí)現(xiàn)超過一個數(shù)量級的優(yōu)勢，那也許還有一個專用數(shù)據(jù)庫的生態(tài)位存在。但通常用不了多久，便會有 PostgreSQL 生態(tài)的開源替代擴(kuò)展插件滾滾而來。因?yàn)檫x擇開發(fā) PG 擴(kuò)展，而不是一個完整數(shù)據(jù)庫的團(tuán)隊會在追趕復(fù)刻速度上有碾壓性優(yōu)勢！ 因此，如果按照這樣的邏輯展開，PostgreSQL 生態(tài)的雪球只會越滾越大，隨著優(yōu)勢的積累，不可避免地進(jìn)入一家獨(dú)大的狀態(tài)。在幾年的時間內(nèi)，實(shí)現(xiàn) Linux 內(nèi)核在服務(wù)器操作系統(tǒng)領(lǐng)域的狀態(tài)。而各種開發(fā)者調(diào)研報告，數(shù)據(jù)庫流行趨勢都在印證著這一點(diǎn)。
StackOverflow 2023 調(diào)研結(jié)果，PostgreSQL 三項(xiàng)全能王
StackOverflow過去7年的數(shù)據(jù)庫指標(biāo)走勢 在引領(lǐng)潮流的 HackerNews StackOverflow 上，PostgreSQL 早已成為了最受歡迎的數(shù)據(jù)庫。許多新的開源項(xiàng)目都默認(rèn)使用 PostgreSQL 作為首要，甚至唯一的數(shù)據(jù)庫 —— 例如，給各種數(shù)據(jù)庫做模式管理的 Bytebase。《云時代數(shù)據(jù)庫DevOps：硅谷調(diào)研》也提出，許多新一代互聯(lián)網(wǎng)公司都開始積極擁抱并 All in PostgreSQL。 正如《技術(shù)極簡主義：一切皆用 Postgres 》所言：簡化技術(shù)棧、減少組件、加快開發(fā)速度、降低風(fēng)險并提供更多功能特性的方法之一就是 “一切皆用 Postgres”。Postgres 能夠取代許多后端技術(shù)，包括 MySQL，Kafka、RabbitMQ、ElasticSearch，Mongo和 Redis，至少到數(shù)百萬用戶時都毫無問題。一切皆用 Postgres ，已經(jīng)不再是少數(shù)精英團(tuán)隊的前沿探索，而是成為了一種進(jìn)入主流視野的最佳實(shí)踐。 還有什么可以做的？我們已經(jīng)不難預(yù)見到數(shù)據(jù)庫領(lǐng)域的終局。但我們又能做什么，又應(yīng)該做什么呢？ PostgreSQL 對于絕大多數(shù)場景都已經(jīng)是一個足夠完美的數(shù)據(jù)庫內(nèi)核了，在這個前提下，數(shù)據(jù)庫內(nèi)核卡脖子純屬無稽之談。這些Fork PostgreSQL 和 MySQL 并以內(nèi)核魔改作為賣點(diǎn)的所謂“數(shù)據(jù)庫”基本沒啥出息。 這好比今天我們看 Linux 操作系統(tǒng)內(nèi)核一樣，盡管市面上有這么多的 Linux 操作系統(tǒng)發(fā)行版，但大家都選擇使用同樣的 Linux 內(nèi)核，吃飽了撐著魔改內(nèi)核屬于沒有困難創(chuàng)造困難也要上，會被業(yè)界當(dāng)成山炮看待。 同理，數(shù)據(jù)庫內(nèi)核本身已經(jīng)不再是主要矛盾，焦點(diǎn)將會集中到兩個方向上 —— 數(shù)據(jù)庫擴(kuò)展與數(shù)據(jù)庫服務(wù)！前者體現(xiàn)為數(shù)據(jù)庫內(nèi)部的可擴(kuò)展性， 后者體現(xiàn)為數(shù)據(jù)庫外部的可組合性。而競爭的形式，正如操作系統(tǒng)生態(tài)一樣 —— 集中于數(shù)據(jù)庫發(fā)行版上。對于數(shù)據(jù)庫領(lǐng)域來說，只有那些以擴(kuò)展和服務(wù)作為核心價值主張的發(fā)行版，才有最終成功的可能。 做內(nèi)核的廠商不溫不火，MariaDB 作為 MySQL 的親爹 Fork 甚至都已經(jīng)瀕臨退市，而白嫖內(nèi)核自己做服務(wù)與擴(kuò)展賣 RDS 的 AWS 可以賺的缽滿盆翻。投資機(jī)構(gòu)已經(jīng)出手了許多 PG 生態(tài)的擴(kuò)展插件與服務(wù)發(fā)行版：Citus，TimescaleDB，Hydra，PostgresML，ParadeDB，FerretDB，StackGres，Aiven，Neon，Supabase，Tembo，PostgresAI，以及我們正在做的 Pigsty 。 PostgreSQL 生態(tài)中的一個困境就是，許多擴(kuò)展插件，生態(tài)工具都是獨(dú)立演進(jìn)，各自為戰(zhàn)的，沒有一個整合者能將他們凝聚起來形成合力。例如，提供分析的 Hydra 會打一個包一個 Docker 鏡像， PostgresML 也會打自己的包和鏡像，各家只發(fā)行加裝了自己擴(kuò)展的 Postgres 鏡像。而這些樸素的鏡像與包也距離 RDS 這樣完整的數(shù)據(jù)庫服務(wù)相距甚遠(yuǎn)。 即使是類似于 AWS RDS 這樣的服務(wù)提供商與生態(tài)整合者，在諸多擴(kuò)展面前也依然力有所不逮，只能提供其中的少數(shù)。更多的強(qiáng)力擴(kuò)展出于各種原因（AGPLv3 協(xié)議，多租戶租賃帶來的安全挑戰(zhàn)）而無法使用。從而難以發(fā)揮 PostgreSQL 生態(tài)擴(kuò)展的協(xié)同增幅作用。
許多關(guān)鍵擴(kuò)展在RDS中并不可用 擴(kuò)展是 PostgreSQL 的靈魂，無法自由使用擴(kuò)展的 Postgres 就像做菜不放鹽。只能和 MySQL 放在同一個 RDS 的框子里同臺，龍游淺水，虎落平陽。而這正是我們想要解決的問題。 知行合一的實(shí)踐：Pigsty雖然接觸 MySQL 和 MSSQL 要早得多，但我在 2015 年第一次上手 PostgreSQL 時，就相信它會是數(shù)據(jù)庫領(lǐng)域的未來了?？焓赀^去，我也從 PG 的使用者，管理者，變?yōu)榱素暙I(xiàn)者，開發(fā)者。也不斷見證著 PG 走向這一目標(biāo)。 在與形形色色的用戶溝通交流中，我早已發(fā)現(xiàn)數(shù)據(jù)庫領(lǐng)域的木桶短板不是內(nèi)核 —— 現(xiàn)有的 PostgreSQL 已經(jīng)足夠好了，而是用好數(shù)據(jù)庫內(nèi)核本身的能力，這也是 RDS 這樣的服務(wù)賺的缽滿盆翻的原因。 但我希望這樣的能力，應(yīng)該像自由軟件運(yùn)動所倡導(dǎo)的理念那樣，像 PostgreSQL 內(nèi)核本身一樣 —— 普及到每一個用戶手中，而不是必須向賽博空間上的封建云領(lǐng)主花大價錢租賃。 所以我打造了 Pigsty —— 一個開箱即用的開源 PostgreSQL 數(shù)據(jù)庫發(fā)行版，旨在凝聚 PostgreSQL 生態(tài)擴(kuò)展的合力，并把提供優(yōu)質(zhì)數(shù)據(jù)庫服務(wù)的能力普及到每個用戶手中。
Pigsty 是 PostgreSQL in Great STYle 的縮寫，意為 PostgreSQL 的全盛狀態(tài)。 我們提出了六點(diǎn)核心價值主張，對應(yīng) PostgreSQL 數(shù)據(jù)庫服務(wù)中的的六個核心問題：Postgres 的可擴(kuò)展性，基礎(chǔ)設(shè)施的可靠性，圖形化的可觀測性，服務(wù)的可用性，工具的可維護(hù)性，以及擴(kuò)展模塊和三方組件可組合性。 Pigsty 六點(diǎn)價值主張的首字母合起來，則為 Pigsty 提供了另外一種縮寫解釋：
可擴(kuò)展的 PostgreSQL 是這個發(fā)行版中最重要的價值主張。在剛剛發(fā)布的 Pigsty v2.6 中，我們整合了上面提到的 DuckdbFDW 與 ParadeDB 擴(kuò)展，這兩個插件讓 PostgreSQL 的分析能力得到史詩級增強(qiáng)，而我們確保每個用戶都能輕松用得上這樣的能力。
來自 ParadeDB 創(chuàng)始人與 DuckdbFDW 作者的感謝致意 我們希望整合 PostgreSQL 生態(tài)里的各種力量，并將其凝聚在一起形成合力，打造一個數(shù)據(jù)庫世界中的 Ubuntu 發(fā)行版。而我相信，內(nèi)核之爭早已塵埃落定，而這里才會是數(shù)據(jù)庫世界的未來競爭焦點(diǎn)。
開發(fā)者朋友們，你們的選擇會塑造數(shù)據(jù)庫世界的未來。希望我的這些工作，可以幫助你們更好的用好這世界上最先進(jìn)的開源數(shù)據(jù)庫內(nèi)核 —— PostgreSQL。 參考閱讀該文章在 2024/3/7 11:49:49 編輯過 |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... 
|
400 186 1886
