爲什麼數據庫不應該使用外鍵

爲什麼這麼設計(Why’s THE Design)是一系列關於計算機領域中程序設計決策的文章,我們在這個系列的每一篇文章中都會提出一個具體的問題並從不同的角度討論這種設計的優缺點、對具體實現造成的影響。如果你有想要了解的問題,可以在文章下面留言。

當我們想要持久化地存儲數據時,使用關係型數據庫往往都是最穩妥的選擇,這不僅因爲今天的關係型數據庫種類非常豐富並且穩定,還因爲不同社區對關係型數據庫的支持都非常完備。我們在前面的文章中曾經分析過 爲什麼 MySQL 的自增主鍵不單調也不連續,這篇文章我們來分析關係型數據庫中另一個重要的概念 — 外鍵(Foreign Key)。

在關係型數據庫中,外鍵也被稱爲關係鍵,它是關係型數據庫中提供關係表之間連接的多個列 [^1],這一組數據列是當前關係表中的外鍵,也必須是另一個關係表中的候選鍵(Candidate Key),我們可以通過候選鍵在當前表中找到唯一的元素 [^2]。在通常情況下,我們都會使用關係表中的主鍵作爲其他表中的外鍵,這樣纔可以滿足關係型數據庫對外鍵的約束。

圖 1 - 關係型數據庫與外鍵

外鍵不僅僅是數據庫表中的一個整數,它還提供了額外的一致性保證。因爲數據庫往往是整個系統的真理之源(Source of Truth),所以保證數據的一致性和正確性非常重要,關係型數據庫雖然提供了外鍵、觸發器等特性保證一致性,但是在今天的生產環境中卻很少被使用。

引用完整性(Referential Integrity)是數據的屬性,如果數據擁有該屬性,那麼數據中所有的引用都是合法的,在關係型數據庫的上下文中,這就意味着關係型數據庫中引用另一個表中的值必須存在 [^3]。

ALTER TABLE posts
ADD CONSTRAINT FOREIGN KEY (author_id)
REFERENCES authors(id);

上述 SQL 語句可以向關係表中增加外鍵約束,該 SQL 語句的執行前提是 posts 表中存在 author_id 字段。從 SQL 語句中的 CONSTRAINT 關鍵字我們也能推測出外鍵不是一種數據類型,它是不同關係表之間的約束。

圖 2 - 無狀態服務與數據庫

不使用外鍵的原因其實很簡單,MySQL、PostgreSQL 等關係型數據庫很難水平擴容,但是無狀態的服務往往都可以很容易地擴容。由於外鍵等特性需要數據庫執行額外的工作,而這些操作會佔用數據庫的計算資源,所以我們可以將大部分的需求都遷移到無狀態的服務中完成以降低數據庫的工作負載。

根據更新和刪除時的行爲不同,我們可以將外鍵分成 RESTRICTCASCADESET NULL 等幾種 [^4],當我們爲關係表中的字段增加外鍵約束時,需要指定外鍵的類型,最常見的也就是 RESTRICTCASCADE 兩種,其中 RESTRICT 爲外鍵的默認類型,不同類型的外鍵會帶來不同的額外開銷,而這些額外開銷就是我們不使用外鍵的理由:

注意:MySQL 中的 NO ACTIONRESTRICT 具有相同的語義 [^5]。

接下來我們會詳細介紹關係型數據庫如何處理上述兩種不同類型的外鍵,而我們應該如何在應用中模擬這些功能。

一致性檢查

當我們使用默認的外鍵類型 RESTRICT 時,在創建、修改或者刪除記錄時都會檢查引用的合法性。想要在 MySQL 等數據庫中觸發外鍵的一致性檢查其實非常容易,假設我們的數據庫中包含 posts(id, author_id, content)authors(id, name) 兩張表,在執行如下所示的操作時都會觸發數據庫對外鍵的檢查:

作爲專門用於管理數據的系統,數據庫與應用服務相比能夠更好地保證完整性,而上述的這些操作都是引入外鍵帶來的額外工作,不過這也是數據庫保證數據完整性的必要代價。上述的這些分析都是理論上的定性分析,我們其實可以簡單的定量分析一下引入外鍵對性能的影響。

在這裏我們在數據庫中同時創建 authorspostsforeign_key_posts 三種表,如下所示,其中 postsforeign_key_posts 兩個表中的列完全相同,只是 foreign_key_posts 表爲 author_id 字段增加了 RESTRICT 類型的外鍵約束:

圖 3 - 外鍵性能測試關係圖

我們先在 authors 表中插入一條記錄,隨後分別在 postsforeign_key_posts 中插入多條新數據列引用該條記錄,前者不會檢查外鍵的合法性,而後者會做額外的檢查。你可以在 這裏 找到作者用來測試外鍵額外開銷的 Go 語言代碼 [^6],經過多次基準測試,我們可以得到如下所示的結果:

BenchmarkBaseline-8     	    3770	    309503 ns/op
BenchmarkForeignKey-8   	    3331	    317162 ns/op
BenchmarkBaseline-8     	    3192	    315506 ns/op
BenchmarkForeignKey-8   	    3381	    315577 ns/op
BenchmarkBaseline-8     	    3298	    312761 ns/op
BenchmarkForeignKey-8   	    3829	    345342 ns/op
BenchmarkBaseline-8     	    3753	    291642 ns/op
BenchmarkForeignKey-8   	    3948	    325239 ns/op

作者執行了 4 次外鍵的基準測試,雖然 4 次測試的結果不是特別穩定,但是使用外鍵的用例在每次測試中都明顯弱於不使用外鍵的用例,外鍵帶來的額外開銷分別爲 ~2.47%、~0.02%、~10.41% 和 ~11.52%。這裏的基準測試只是一個比較簡單的定量分析,但是我們也可以從結果中看到大概的趨勢 — 外鍵的完整性檢查確實會帶來額外的性能開銷,而這些開銷在高併發的服務中需要慎重考慮。

想要在應用程序中模擬數據庫外鍵的功能其實比較容易,我們只需要遵循以下的幾個準則:

需要注意的是爲了保證一致性,我們需要在事務中執行上述的查詢和修改語句,這樣才能完整模擬外鍵的功能;當我們向 posts 表中插入或者修改數據時,需要的處理相對比較簡單,我們只需要執行有限的 SELECT 語句並按照如下所示的模式執行對應的操作就可以了:

BEGIN
SELECT * FROM authors WHERE id = <post.author_id> FOR UPDATE;
-- INSERT INTO posts ... / UPDATE posts ...
END

但是如果我們要刪除 authors 表中的數據,就需要查詢所有引用 authors 數據的表;如果有 10 個表都有指向 authors 表的外鍵,我們就需要在 10 個表中查詢是否存在對應的記錄,這個過程相對比較麻煩,不過也是爲了實現完整性的必要代價,不過這種模擬外鍵方法其實遠比使用外鍵更消耗資源,它不僅需要查詢關聯數據,還要通過網絡發送更多的數據包。

級聯操作

當我們在關係型數據庫中創建外鍵約束時,如果使用如下所示的 SQL 語句指定更新或者刪除記錄時使用 CASCADE 行爲,那麼在客戶端更新或者刪除數據時就會觸發級聯操作:

ALTER TABLE posts
ADD CONSTRAINT FOREIGN KEY (author_id)
REFERENCES authors(id)
ON UPDATE CASCADE
ON DELETE CASCADE;

不過無論是執行更新還是刪除操作,數據庫都可以保證各個關係表之間引用的一致性和合法性不會出現引用到不存在記錄的情況,與 RESTRICT 行爲一樣,所有外鍵的更新和刪除行爲都可以通過執行額外的檢查和操作保證數據的一致。

圖 4 - 複雜的級聯操作

雖然級聯刪除的出發點也是保證數據的完整性,但是在設計關係表之間的不同關係時,我們也需要注意級聯刪除引起的數據大規模刪除的問題。如上圖所示,當客戶端想要在數據庫中刪除 authos 表中的數據時,如果我們同時在 authorsposts 中指定了級聯刪除的行爲,那麼數據庫會同時刪除所有關聯的 posts 記錄以及與 posts 表關聯的 comments 數據。

這種涉及多級的級聯刪除行爲在數據量較小的數據庫中不會導致問題,但是在數據量較大的數據庫中刪除關鍵數據可能會引起雪崩,一條記錄的刪除可能會被放大到幾十倍甚至上百倍,這些對磁盤的隨機讀寫會帶來巨大的開銷,是我們想要儘可能避免的情況。如果我們能夠較好地設計各個表之間的關係並且慎用 CASCADE 行爲,這對於保證數據庫中數據的合法性有着很重要的意義,使用該特性可以避免數據庫中出現過期的、不合法的數據,但是在使用時也要合理預估可能造成的最壞情況。

手動實現數據庫的級聯刪除操作是可行的,如果我們在一個事務中按照順序刪除所有的數據,確實可以保證數據的一致性,但是這與外鍵的級聯刪除功能沒有太大的區別,反而會有更差的表現。如果我們能夠接受在一個時間窗口內的數據不一致,就可以將一個大號的刪除任務拆成多個子任務分批執行,降低對數據庫影響的峯值。

DELETE FROM posts WHERE author_id = 1 LIMIT 100;
DELETE FROM posts WHERE author_id = 1 LIMIT 100;
...
DELETE FROM authors WHERE id = 1;

與數據庫外鍵的 CASCADE 相比,這種方式會帶來更大的額外開銷,只是我們能降低對數據庫性能的瞬時影響。

總結

外鍵提供的幾種在更新和刪除時的不同行爲都可以幫助我們保證數據庫中數據的一致性和引用合法性,但是外鍵的使用也需要數據庫承擔額外的開銷,在大多數服務都可以水平擴容的今天,高併發場景中使用外鍵確實會影響服務的吞吐量上限。在數據庫之外手動實現外鍵的功能是可能的,但是卻會帶來很多維護上的成本或者需要我們在數據一致性上做出一些妥協。我們可以從可用性、一致性幾個方面分析使用外鍵、模擬外鍵以及不使用外鍵的差異:

在大多數不需要高併發或者對一致性有較強要求的系統中,我們可以直接使用數據庫提供的外鍵幫助我們對數據進行校驗,但是在對一致性要求不高的、複雜的場景或者大規模的團隊中,不使用外鍵也確實可以爲數據庫減負,而大團隊也有更多的時間和精力去設計其他的方案,例如:分佈式的關係型數據庫。

當我們考慮應不應該在數據庫中使用外鍵時,需要關注的核心我們的數據庫承擔這部分計算任務後會不會影響系統的可用性,在使用時也不應該一刀切的決定用或者不用外鍵,應該根據具體的場景做決策,我們在這裏介紹了兩個使用外鍵時可能遇到的問題:

我們在很多時候其實並不能選擇是否使用外鍵,大多數公司的 DBA 都會對數據庫系統的使用有比較明確的規定,但是我們要清楚做出使用外鍵和不使用外鍵這一抉擇的原因。到最後,我們還是來看一些比較開放的相關問題,有興趣的讀者可以仔細思考一下下面的問題:

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/wyhyor2XJJY0EOjQ0MQsCQ