關聯式資料庫大泥球帶來的管理問題和對策 - pathelland

掃描件、照片等大檔案的儲存
很多文件，照片甚至是電影都儲存到關聯式資料庫種，由於SQL可以接受Blob，因此它們可以將大量資料儲存在資料庫中。

• 這對資料庫的使用者來說非常好！  輕鬆，乾淨地儲存您的隨機資料，並具有備份，高可用性和神奇的儲存容量。此外，資料可以與資料庫中的其他內容進行事務性更新。不用擔心，可以為您的資料提供最好的照顧！生活是美好的！
• 對於資料庫管理員來說，這是一場噩夢！  突然之間，您的資料庫開始變得越來越胖。很快，您將購買更多昂貴的儲存解決方案。諸如照片和文件影像之類的不可變資料共存於 支援您的資料庫的 SAN（儲存區域網路）上。這是低效的，因為SAN是設計用於就地更新的極其昂貴的高階硬體。

• 系統更新是非事務性的。  通常，您需要透過以下方式更新新的統一系統： 
  
  • 步驟1：  在資料庫上的transaction-T1中，​​更新關係系統，說您打算將UUID-X物件插入應用程式可理解的表的列中。另一列管理持有不可變物件的儲存區中物件的狀態。
  • 步驟2：  使用UUID-X將不可變物件複製到新儲存中。
  • 步驟3：  最後，在transaction-T2中，在附加列中更新物件的狀態，以便您知道應用程式可以使用該物件。
  
  這可能是什麼問題？

• 糟糕，稍後您會發現多步插入失敗可能會導致問題。  步驟1之後和步驟2之前的故障會導致放棄和不完整的插入，如在應用程式中檢視錶時所見。在第2步之後和第3步之前的故障使不可變儲存中的廢棄物件無用。
  為了解決這個問題，您需要一個正在進行的插入和刪除的邊表。這樣可以幫助實現事務處理的鎖定記錄。  
  接下來，您將意識到也最好為正在進行的工作加上時間戳，以便您可以注意到什麼時候由於插入失敗而足以保證清理。

• 幾個月或幾年後，當前的blob的不變儲存已達到容量極限。  現在，您需要另一個程式來更新關係系統中的所有表以包括儲存ID。這樣您就可以在其他新的儲存介質中繼續儲存blob。  
  這時需要引入新的一箇中間者，能將Blob的管理推到新的專用表中，使用這種新的中間間接級別，您可以更輕鬆地管理跨資料中心的複製，甚至可以將不可變的Blob儲存遷移到新的資料中心。

資料庫泥球
軟體工程中最大的問題之一就是解開泥濘的 大球。這些相互交織，相互依存的大量程式碼有時可能包含由成千上萬的軟體工程師策劃的數千萬行程式碼。  很多時候，共享寶貴的資料庫所帶來的社會和經濟壓力造成了您自己的大泥潭。一旦應用程式文化鼓勵不受限制地訪問任何表，就很難更改。在文化上很難，而且很難進行軟體工程來完成更改。 
改變必須是漸進的。您必須同時駕駛胡蘿蔔和棍子。這可以透過以下方法演變成實現解糾纏的新方法：

1. 建立管道以使跨應用程式的非同步工作變得容易，並且
2. 跨應用程式截斷對錶的訪問。  有時人們只是需要表的只讀副本。這些是從真相之源那裡非同步更新的結果。

結論
如果一個公司中擁有許多資料庫也是煩人又昂貴，特別是在運算元據庫方面遇到的挑戰。我可以給資料庫使用者的最佳建議是謹慎謹慎地使用它。如果可能的話： 

• 管理Blob。  建立一種規範化的機制來處理Blob，即使您將它們在短期內保留在資料庫中，之後再將其移至其他位置，
• 隔離應用程式。  使其他應用程式遠離其他應用程式的表，
• 在應用程式之間使用訊息傳遞。  將應用程式與某種形式的非同步訊息連線起來，即使該訊息只是簡單地實現為在單獨事務中排隊和出隊的資料庫表中的行。結合隔離應用程式，可以使得向多個資料庫的遷移變得切實可行。