在進(jìn)行技術(shù)選型時(shí)，需要考慮眾多因素，如功能、性能、可靠性、成本效益、社區(qū)支持和團(tuán)隊(duì)技術(shù)能力等，然而，影響最終決定的關(guān)鍵因素的往往是團(tuán)隊(duì) Leader 的技術(shù)品味，這也能解釋為什么阿里偏愛 Java，而字節(jié)跳動(dòng)更傾向 Go、Rust 等新興語言。技術(shù)本身無好壞之分，根據(jù)實(shí)際業(yè)務(wù)問題選擇適當(dāng)?shù)募夹g(shù)方案是關(guān)鍵。

本文旨在為讀者提供一種新的選擇，而非論證 PostgreSQL 比 MongoDB 更優(yōu)秀。

MongoDB 因其靈活的 "Schema-less"（無模式）特性而著名。"Schema-less" 意味著 MongoDB 不要求嚴(yán)格定義數(shù)據(jù)的結(jié)構(gòu)和字段（使用 BSON 格式存儲(chǔ)數(shù)據(jù)），允許在同一集合中存儲(chǔ)具有不同結(jié)構(gòu)的文檔，這為開發(fā)人員提供了極大的靈活性，能夠輕松適應(yīng)數(shù)據(jù)模型的變化和演進(jìn)。

PostgreSQL 提供的 JSONB 類型可用于存儲(chǔ)和處理 JSON 數(shù)據(jù)，包括嵌套的對(duì)象、數(shù)組和基本數(shù)據(jù)類型。因此，PostgreSQL 具備 MongoDB 存儲(chǔ) document 的能力。

PostgreSQL 對(duì) JSON 的支持

我們來了解一下 PostgreSQL 支持 JSON 特性的時(shí)間線（統(tǒng)計(jì)到版本 14）:

- PG 9.2 Introduction of JSON (JSON text; no indexes) -- 2012/9/10
- PG 9.4 Introduction of JSONB (binary format; indexes) -- 2014/12/18
- PG 9.5 jsonb_set(), jsonb_object(), jsonb_build_object(), jsonb_build_array, jsonb_agg, || operator etc.
- PG 9.6 jsonb_insert()
- PG 10 Full text search support for JSONB
- PG 11 jsonb_plpython
- PG 12 json_path (like xpath in XML; part of SQL Standard 2016)
- PG 13 jsonpath.datetime()
- PG 14 JSONB subscripting can be used to extract and assign to portions of JSONB

可以看出，PostgreSQL 對(duì) JSON 的支持雖晚于 MongoDB（MongoDB 1.0 在 2009年9月前后發(fā)布），但其后續(xù)的版本 JSON 相關(guān)的特性開發(fā)非?；钴S，提供了強(qiáng)大而靈活的 JSON 處理能力。

PostgreSQL提供兩種存儲(chǔ) JSON[1] 的數(shù)據(jù)類型：json 和 jsonb，二者接受幾乎相同的輸入值，主要區(qū)別在存取效率。json 存儲(chǔ)插入文本的精確副本，處理函數(shù)在每次執(zhí)行時(shí)必須重新解析；jsonb 則存儲(chǔ)解析過的的二進(jìn)制格式（類似 MongoDB 的 BSON），由于需要額外的轉(zhuǎn)換開銷，插入時(shí)稍慢一些，但因?yàn)闊o需重新解析，處理速度更勝一籌。另外 jsonb 還支持索引，這是一個(gè)重要的優(yōu)勢(shì)。

大多數(shù)場景我們都應(yīng)該使用 jsonb，除非以下幾種情況:

• 需要保留原始輸入的格式，比如空格

• 需要保留鍵的順序或冗余的鍵值

• 需要快速插入和讀取而無需對(duì)數(shù)據(jù)進(jìn)行處理

PostgreSQL 和 MongoDB 使用對(duì)比

在了解了 PostgreSQL 的 JSON 特性之后，我們來對(duì)比一下 PostgreSQL 和 MongoDB 使用上的區(qū)別。

我們將 MongoDB 的 _id 單獨(dú)存為一個(gè)字段，其它字段存為 doc:

create table inventory(_id bigserial PRIMARY KEY , doc jsonb);

1. CRUD

MongoDB:

db.inventory.insertOne(
   { item: "canvas", qty: 100, tags: ["cotton"], size: { h: 28, w: 35.5, uom: "cm" } }
)
db.inventory.insertMany([
   { item: "journal", qty: 25, tags: ["blank", "red"], size: { h: 14, w: 21, uom: "cm" } },
   { item: "mat", qty: 85, tags: ["gray"], size: { h: 27.9, w: 35.5, uom: "cm" } },
   { item: "mousepad", qty: 25, tags: ["gel", "blue"], size: { h: 19, w: 22.85, uom: "cm" } }
])
db.inventory.find( { tags: ["red", "blank"] } )
db.inventory.find( { qty: { $gt: 25 } } )
db.inventory.find( { "tags": { $size: 2 } } )
db.inventory.find( { 'size.h': { $lte: 20 } } )
db.inventory.updateOne( { _id: 3 }, [ { $set: { "item": "notepad"} } ] )
db.inventory.deleteOne( { qty: { $gt: 90 } } )

PG:

insert into inventory(doc) values('{ "item": "canvas", "qty": 100, "tags": ["cotton"], "size": { "h": 28, "w": 35.5, "uom": "cm" } }');
insert into inventory(doc) values('{ "item": "journal", "qty": 25, "tags": ["blank", "red"], "size": { "h": 14, "w": 21, "uom": "cm" } }'),
                                  ('{ "item": "mat", "qty": 85, "tags": ["gray"], "size": { "h": 27.9, "w": 35.5, "uom": "cm" } }'),
                                  ('{ "item": "mousepad", "qty": 25, "tags": ["gel", "blue"], "size": { "h": 19, "w": 22.85, "uom": "cm" } }');
SELECT * FROM inventory WHERE doc->'tags' @> '["red", "blank"]'::jsonb;
SELECT * FROM inventory WHERE (doc->>'qty')::integer > 25;
SELECT * FROM inventory WHERE jsonb_array_length(doc->'tags') = 2;
SELECT * FROM inventory WHERE (doc->'size'->>'h')::float <= 20;
UPDATE inventory SET doc = jsonb_set(doc, '{item}', '"notepad"', true) WHERE _id = 3;
DELETE FROM inventory WHERE (doc->>'qty')::integer > 90 AND ctid IN (SELECT ctid FROM inventory LIMIT 1);

注意: 將全部數(shù)據(jù)存儲(chǔ)在 PostgreSQL 的一個(gè) jsonb 字段雖然可行，但 jsonb 沒有狀態(tài)統(tǒng)計(jì)數(shù)據(jù)，將固定的列抽成一個(gè)單獨(dú)的列往往能獲得更好的查詢性能。

2. 索引

MongoDB 支持的索引在 PostgreSQL 中基本都支持，雖然通配符索引在 PostgreSQL 沒看到類似的能力，但 PostgreSQL 的索引能力應(yīng)該不遜于 MongoDB。

Can PostgreSQL with its JSONB column type replace MongoDB?[2] ???? 這篇文章對(duì) MongoDB 和 PostgreSQL 中的部分索引進(jìn)行了性能對(duì)比。

3. sharding

MongoDB 使用 sharding（分片）來支持超大數(shù)據(jù)集和高吞吐量的集群部署，通過將數(shù)據(jù)集水平拆分為多個(gè)分片，并將每個(gè)分片分布在不同的服務(wù)器上。每個(gè)服務(wù)器（或分片）都可以獨(dú)立處理一部分?jǐn)?shù)據(jù)寫入和查詢負(fù)載，從而提高整個(gè)系統(tǒng)的擴(kuò)展性和性能。其架構(gòu)如下:

• shard: 每個(gè) shard 可以部署為一個(gè)副本集（replica set），單個(gè) shard 上包含多個(gè)分片

• mongos: 接收客戶端的請(qǐng)求，并將請(qǐng)求路由到 shard

• config servers: 存儲(chǔ)集群元數(shù)據(jù)和配置信息

MongoDB 在 collection 級(jí)別進(jìn)行數(shù)據(jù)切分，使用 shard key（由文檔中的一個(gè)或多個(gè)字段組成） 將 collection 切分為多個(gè) chunks分布在集群中的各個(gè)分片上。

PostgreSQL 本身不支持分布式，但 Citus[3] 提供了 sharding 的能力，其組件幾乎都能跟 MongoDB 對(duì)應(yīng)上:

PostgreSQL + Citus 能夠?qū)崿F(xiàn) MongoDB 分片的能力。不過 Citus 不支持使用多字段作為 shard key，且只支持 Hash 分布（代碼倉庫中有 RANGE_DISTRIBUTED，但實(shí)際并不支持）。

FerretDB

說到替換 MongoDB，不得不提一下 FerretDB[4]，F(xiàn)erretDB 的目標(biāo)是允許使用現(xiàn)有的關(guān)系型數(shù)據(jù)庫來處理 MongoDB 的查詢請(qǐng)求，它充當(dāng)一個(gè)代理，接收來自應(yīng)用程序的 MongoDB 查詢，并將其轉(zhuǎn)換為相應(yīng)的 SQL 查詢，然后將結(jié)果返回給應(yīng)用程序。FerretDB 支持使用 PostgreSQL 或 SQLite 等關(guān)系型數(shù)據(jù)庫作為后端存儲(chǔ)引擎，其架構(gòu)如下:

FerretDB 能夠處理 MongoDB 大部分請(qǐng)求，但目前有些能力還不具備，如:

• $lookup aggregation pipeline[5]

• geospatial index[6]

• text indexes[7]

• sharding[8]

• ...

不過 FerretDB 的社區(qū)非常活躍，相信未來他們會(huì)將這些特性逐漸完善。

總結(jié)

相比 MongoDB 的 "Schema-less"，PostgreSQL 確實(shí)需要事先定義好表結(jié)構(gòu)，包括列名、數(shù)據(jù)類型和約束等，但 PostgreSQL 的 JSONB 類型提供了一種在關(guān)系型數(shù)據(jù)庫中存儲(chǔ)和查詢 JSON 數(shù)據(jù)的靈活性。也正是這種表結(jié)構(gòu)和 JSONB 類型相結(jié)合的能力，使得筆者認(rèn)為 PostgreSQL 比 MongoDB 單純的 "Schema-less" 更靈活、更強(qiáng)大。

雖然 Michael Stonebraker 早在 2005 年就指出 One size fits all[9] 是一個(gè)不切實(shí)際的觀點(diǎn)，但數(shù)據(jù)庫開發(fā)者從未停止探索的腳步，期望為用戶提供一站式的解決方案。MongoDB 從最初的 NoSQL[10] 到后來支持了事務(wù)[11]、時(shí)序[12]等特性，PostgreSQL 生態(tài)也有時(shí)序（TimescaleDB[13]）、圖（AGE[14]）、消息隊(duì)列（PGMQ[15]）相關(guān)的擴(kuò)展。雖然在功能特性上有所重合，但不同的是，MongoDB 作為一個(gè)商業(yè)公司，其產(chǎn)品在易用性上會(huì)更勝一籌，而 PostgreSQL 則需要使用者不斷去探索來發(fā)掘其無限可能。

最后，Michael Stonebraker 三篇關(guān)于 NoSQL 的博客:

• "Schema Later" Considered Harmful[16]: If you have data that will require a schema at some point, you are way better off doing the work up front to avoid data debt, because the cost of schema later is a lot higher.

• Comparison of JOINS: MongoDB vs. PostgreSQL[17]

• Those Who Forget the Past Are Doomed to Repeat It[18]

到此這篇關(guān)于為什么 PostgreSQL 能代替 MongoDB？的文章就介紹到這了,更多相關(guān)PostgreSQL 能代替 MongoDB內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論