編者按：一般來說，大型共享數(shù)據(jù)庫的管理會遇到不少麻煩，比如維護費用、剩余垃圾等等，但做好一些事情之后，這些麻煩就會不那么讓人頭疼了。
編譯 | 彎月 責編 | 張文
頭 圖 | CSDN 下載自東方 IC
出品 | CSDN（ID：CSDNnews）
以下為譯文：
數(shù)據(jù)庫是業(yè)務系統(tǒng)的基礎(chǔ)，不僅提供數(shù)據(jù)訪問，還需要在線數(shù)據(jù)庫定義語言、高可用性、存檔、異地磁帶輪換和管理、在線備份、訪問控制、監(jiān)視和操作支持，以及復制到遠程數(shù)據(jù)中心。
通常，數(shù)據(jù)庫規(guī)模龐大，功能強大且成本昂貴。即便是集團級別的企業(yè)一般也只能負擔得起一個大型數(shù)據(jù)庫。此外，大型主機計算機系統(tǒng)及其數(shù)據(jù)庫非常昂貴，常常需要專門的工程師來構(gòu)建能夠滿足企業(yè)需求的應用程序。
因此，很多公司的數(shù)據(jù)庫都會面臨一些相同的問題：每個應用程序都希望共享相同的數(shù)據(jù)庫，且數(shù)據(jù)庫內(nèi)容納了許多垃圾。“公地的悲劇”在數(shù)據(jù)庫中也層出不窮。
因此，在本文中，我們就來探討一下如何在多個應用程序之間合理地共享數(shù)據(jù)庫，同時確保數(shù)據(jù)庫不會被文檔、照片、音頻文件和電影等非關(guān)系型的數(shù)據(jù)占據(jù)。
獨享數(shù)據(jù)庫與共享數(shù)據(jù)庫
在公司招收若干數(shù)據(jù)庫管理員，并建立起數(shù)據(jù)中心之后，公司的每個新應用程序都將使用這個數(shù)據(jù)庫。這也無可厚非，因為一般公司都無力再負擔另一個大型的主機。
很快，數(shù)據(jù)管理員就需要不斷設(shè)計各種的表結(jié)構(gòu)，同時各種新功能和新應用程序也將源源不斷地添加到這個共享的系統(tǒng)。隨著公司的發(fā)展，這個數(shù)據(jù)庫變得越來越重要，數(shù)據(jù)庫管理員必須確保數(shù)據(jù)庫 24 小時無間斷運行。一旦數(shù)據(jù)庫出現(xiàn)任何問題，公司的業(yè)務也會立即受到影響。公司的所有數(shù)據(jù)都集中在這個共享數(shù)據(jù)庫。數(shù)據(jù)庫管理員需要確保所有的數(shù)據(jù)都安全，萬無一失。
剛開始的時候，每個應用程序都使用各自的表，服務各自的業(yè)務。然而，隨著應用程序之間的交互越來越多，程序員很快就會放棄繁瑣的消息機制或 API 調(diào)用，轉(zhuǎn)而直接讀取其他應用程序的表。這樣有什么壞處？各個應用程序和表之間的關(guān)系會越來越復雜，糾纏不清。通過一個事務更新多個應用程序的表的現(xiàn)象也會非常普遍。這時，數(shù)據(jù)庫的整潔性也會蕩然無存。
非關(guān)系型的數(shù)據(jù)應該保存在何處？
非關(guān)系型的數(shù)據(jù)，例如文檔、照片、音頻以及視頻資料也需要妥善地保存起來。程序員常常利用 SQL 的 Blob 類型來存儲大量的數(shù)據(jù)。雖然數(shù)據(jù)庫是保存這類數(shù)據(jù)的一個好地方，但從數(shù)據(jù)庫本身來看，這種做法弊端很多。
對數(shù)據(jù)庫的使用者來說，將大量的數(shù)據(jù)塞入數(shù)據(jù)省時又省心，不僅可以輕松地存儲數(shù)據(jù)，而且還有備份，保證了高可用性。此外，這些數(shù)據(jù)的更新也可以通過事務保證一致性。
然而，對于數(shù)據(jù)庫管理員來說，這就是噩夢！隨著大量數(shù)據(jù)的“入駐”，數(shù)據(jù)庫會變得臃腫不堪。將文檔、照片、視頻這類的不可變數(shù)據(jù)存儲在數(shù)據(jù)庫底層昂貴的存儲上，簡直就是浪費。
此外，從數(shù)據(jù)庫中提取這類龐大的數(shù)據(jù)并不是一件易事。也許我們可以利用掃描后的紙質(zhì)文檔和其他介質(zhì)的不可變的性質(zhì)來幫助我們完成這一操作。你可以為文檔分配 128 位 UUID，并將文檔存儲在其他位置，而數(shù)據(jù)庫只需在相關(guān)的記錄中保存該標識符。
不過，很快你就會發(fā)現(xiàn)，將這些數(shù)據(jù)轉(zhuǎn)移到更便宜的存儲介質(zhì)上時會遇到很多困難。
首先，無法保證數(shù)據(jù)更新的事務性。通常，你需要通過以下方式更新這些數(shù)據(jù)：
通過數(shù)據(jù)庫的事務 1 更新關(guān)系系統(tǒng)，即將 UUID-X 對象插入應用程序的表中，并通過另一列管理不可變對象的狀態(tài)。
使用 UUID-X 將不可變對象復制到新的存儲中。
通過數(shù)據(jù)庫的事務 2 更新對象的狀態(tài)（表示應用程序可以使用不可變對象了）。
這中間會出現(xiàn)什么問題？
如果在第 1 步和第 2 步之間出現(xiàn)問題，那就會導致表中出現(xiàn)不完整的數(shù)據(jù)，應用程序雖然可以讀取數(shù)據(jù)，但外部存儲中卻沒有實際的文件。與之類似，如果第2 步和第 3 步之間出現(xiàn)錯誤，就會導，外部存儲中的不可變對象就會變成永遠無法訪問的“垃圾”。
這個問題的解決方法是，使用另一個表來記錄正在進行的插入或者刪除。至少，這個表的狀態(tài)與應用程序表中的插入或刪除操作的狀態(tài)是同步的。而且，正在進行的插入或刪除應該帶有時間戳，這樣萬一出現(xiàn)了失敗的插入，你可以通過時間戳來判斷是否已經(jīng)過了足夠長的時間，從而決定是否應該進行清理。這樣你的數(shù)據(jù)庫就相對穩(wěn)定了。
另一個可能出現(xiàn)的問題是，過了幾個月或幾年后，存儲不可變數(shù)據(jù)的 blob 即將達到容量上限。為了在多個存儲中不可變數(shù)據(jù)，你不得不修改數(shù)據(jù)庫中所有保存了 UUID 的表，為它們添加一列來記錄存儲庫的 ID。結(jié)果，你會發(fā)現(xiàn)你不知道數(shù)據(jù)庫的哪些表存儲了不可變對象！因為各個應用程序在添加不可變對象的時候，并沒有彼此協(xié)調(diào)。
這個問題的解決方法就是，專門建立一個表來管理不可變對象，并通過一個專門的模塊來封裝更新操作。這樣只要新的應用程序遵守這個規(guī)則，采用間接的方式來使用不可變對象即可。但是，那些依然在直接訪問不可變對象的舊應用程序就只能聽之任之了，因為幾乎不可能把所有的直接訪問都找出來并改掉。
你可以通過這種間接的手段，跨數(shù)據(jù)中心復制數(shù)據(jù)，甚至可以將不可變的 Blob存儲遷移到新的數(shù)據(jù)中心。
分割系統(tǒng)
軟件工程中最大的問題之一就是解耦合。我們的系統(tǒng)包含成千上萬的軟件工程師傾注大量心血編寫的代碼，這些代碼相互交織，又互依互存。
然而，很多時候，共享寶貴的數(shù)據(jù)庫會讓我們的系統(tǒng)深陷巨大的泥潭。一旦各個應用程序之間開始互相訪問表，就很難將它們隔離開來。
為了實現(xiàn)應用程序之間的解耦合，我們需要循序漸進：
創(chuàng)建渠道，方便跨應用程序之間的異步工作。
禁止跨應用程序訪問表。應用程序可以保留表的只讀副本，并在表的“主人”更新數(shù)據(jù)時，異步更新這些副本。而其他應用程序只可訪問這些副本。
這種方式需要堅持多年才能實現(xiàn)解耦合。
通常，這些工作都需要系統(tǒng)架構(gòu)師來推動，由他們從整體角度出發(fā)，設(shè)計各個應用程序的基礎(chǔ)架構(gòu)。很多時候，系統(tǒng)的整體架構(gòu)設(shè)計會與實際的工作發(fā)生沖突，公司領(lǐng)導需要高度重視公司文化的轉(zhuǎn)變與培養(yǎng)。在達成目標時成功給予公平合理的獎賞，并在構(gòu)建新功能時優(yōu)先考慮解耦合，避免解耦合成為團隊前進的阻力。
從某些方面來看，分割一個大型的應用程序要比將兩個遺留系統(tǒng)以解耦合的方式合并在一起簡單得多。在收購另一家公司時，他們的應用程序基于完全不同的公司文化，對最基本的概念（比如客戶）都有不同的理解，如果將這些應用程序的元數(shù)據(jù)直接融合到你的數(shù)據(jù)庫中，那么勢必引發(fā)巨大的混亂。
分割巨大的應用程序就像規(guī)劃一座城市的道路一樣，如何能夠像古代長安一樣，規(guī)劃出整齊劃一又四通八達的街道，這本身就是一項巨大的挑戰(zhàn)。一不小心，城市中心就會被一座座摩天大樓割裂，道路崎嶇，交通堵塞。
數(shù)據(jù)庫的擴張
隨著公司業(yè)務的發(fā)展，數(shù)據(jù)庫必將不斷增長。即使將 Blob 等大型數(shù)據(jù)存儲在其他地方，實現(xiàn)各個應用程序之間的解耦合，相關(guān)的數(shù)據(jù)仍然在同一個數(shù)據(jù)庫中。
通常，數(shù)據(jù)庫的擴張可以朝著兩個方向發(fā)展：
向上擴展：購買更多更好的硬件，擴展數(shù)據(jù)庫的底層設(shè)施。
向外擴展：嘗試向外擴展數(shù)據(jù)庫，通過多臺計算機組成的集群來構(gòu)建更大規(guī)模的數(shù)據(jù)庫。
規(guī)模擴大意味著保存的數(shù)據(jù)更多，處理的事務也更多。應用程序是在平臺上開發(fā)出來的，而數(shù)據(jù)庫是平臺的主要組成部分。將某個大型應用程序移至新數(shù)據(jù)庫的難度非常大，且風險極高。
數(shù)據(jù)庫中有許多微妙的方面，會對應用程序大量的代碼產(chǎn)生影響，比如：
使用非標準數(shù)據(jù)庫功能。每個數(shù)據(jù)庫供應商都會提供一些專屬的非標準功能。在大多數(shù)情況下，代碼中會存在大量使用這些非標準功能的代碼，而且經(jīng)過長年累月的修改和重構(gòu)，這些代碼已經(jīng)深深扎根于代碼庫中，而最初的作者早已離職，根本沒辦法找出當初這樣做的原因。
并發(fā)語義。 多版本并發(fā)控制、可序列化性、可重復讀取以及讀取已提交數(shù)據(jù)這些并發(fā)模型之間的細微差別并不是無中生有。 有關(guān)這方面的討論層出不窮，在大型應用程序保證并發(fā)語義的一致性非常關(guān)鍵。
樂觀并發(fā)控制與悲觀并發(fā)控制。 樂觀并發(fā)控制假設(shè)多用戶并發(fā)的事務在處理時不會彼此互相影響，各事務能夠在不產(chǎn)生鎖的情況下處理各自的數(shù)據(jù)。如果發(fā)生沖突，則事務中止。大多數(shù)時候，這種做法更有效率。在悲觀并發(fā)控制中，如果一個事務執(zhí)行的操作讀某行數(shù)據(jù)應用了鎖，那么只有當這個事務釋放鎖，其他事務才能夠執(zhí)行與該鎖沖突的操作。盡管悲觀并發(fā)控制的代價更高，但這種方式可以防止陷入由于沖突而反復提交失敗的困境。雖然樂觀和悲觀之間的選擇并不會影響應用程序所做更改的正確性，但數(shù)據(jù)庫行為更改為超出應用程序預期的范圍可能會引發(fā)很多性能問題。
數(shù)據(jù)庫遷移的難度不容小覷。而將數(shù)據(jù)庫從集中式系統(tǒng)轉(zhuǎn)移到分布式系統(tǒng)，雖然規(guī)模的擴張毋庸置疑，但其性能肯定會受到某些影響。協(xié)調(diào)鎖和并發(fā)將面臨各種的性能挑戰(zhàn)，而整個過度的過程也將充滿艱險。因此，將應用程序遷移到分布式數(shù)據(jù)庫上，需要耐心和洞察力。
總結(jié)
人們對于數(shù)據(jù)庫往往是愛與痛并存。讓每個應用程序獨享數(shù)據(jù)庫會導致公司內(nèi)產(chǎn)生很多數(shù)據(jù)庫，不僅會加重成本的負擔，而且也會為數(shù)據(jù)庫的操作和管理帶來挑戰(zhàn)。然而，共享數(shù)據(jù)庫時，應用程序之間又面臨解耦合與交互的問題。因此，我們需要謹慎地使用數(shù)據(jù)庫：
管理 Blob。創(chuàng)建一種形式化的機制來處理 Blob，即使目前你將這些數(shù)據(jù)保存在數(shù)據(jù)庫中，以后也可以移至其他地方。
保證應用程序之間的解耦合，讓每個應用程序都遠離其他應用程序的表。
利用消息機制實現(xiàn)應用程序之間的交互。通過某種形式的異步消息將應用程序連接起來，結(jié)合應用程序的解耦合，可以降低數(shù)據(jù)庫的遷移難度。