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

banq發表於2020-11-22
資料庫

資料庫是神話般的資源，我們已經濫用了它們。如果你擁有一個超級穩定安全的關聯式資料庫，那麼它就可能大包大攬，它就可能變成一把錘子，用來解決一切視為釘子的問題。
在Tandem，我瞭解到支援公司業務的資料庫是一個複雜而複雜的生物。它不僅需要提供對客戶資料的訪問，還需要線上DDL，高可用性，歸檔，異地磁帶輪換和管理，線上備份，訪問控制，監視和操作支援，甚至複製到遠端資料中心。
當你公司擁有一個或多個DBA（資料庫管理員）以及一個資料中心中的設定，公司中的每個新應用程式也都希望使用您的資料庫！這是合理的，很快，他們不斷地表建立表庫和管理表的資料庫，並且隨著新功能和新應用程式被更多地新增到共享資料庫系統。
隨著資料庫在公司運營中變得越來越重要，它變得 至關重要。需要保障資料庫以24 x 7或儘可能接近的速度執行所需的所有方面，都得到了越來越多的關注。當資料庫關閉時，公司也關閉了，那不是一件好事。（單點風險）
最初，每個應用程式使用其自己的表，並確保注意自己的業務。最終，讀取另一個應用程式的表似乎比協商如何使用訊息或介面呼叫另一個應用程式要容易得多。很快，一個確定的趨勢增加了：應用程式和表格的熵和相互纏繞。跨表為不同應用程式進行事務更新變得很普遍。
 

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

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

從資料庫中提取這些珍貴而龐大的資料項並不像看起來那樣容易。但是掃描紙質文件和其他介質的一成不變的性質對我們儲存它們具有巨大的幫助。您可以為文件分配128位UUID，並將文件儲存在其他位置。然後，可以將該識別符號儲存在與某些關係記錄關聯的資料庫中。
 
很快，您意識到，儘管這可以將儲存容量轉移到更便宜的儲存介質上，但仍存在挑戰：
  • 系統更新是非事務性的。  通常，您需要透過以下方式更新新的統一系統： 
    • 步驟1：  在資料庫上的transaction-T1中，​​更新關係系統，說您打算將UUID-X物件插入應用程式可理解的表的列中。另一列管理持有不可變物件的儲存區中物件的狀態。
    • 步驟2：  使用UUID-X將不可變物件複製到新儲存中。
    • 步驟3：  最後，在transaction-T2中，在附加列中更新物件的狀態，以便您知道應用程式可以使用該物件。

    這可能是什麼問題？

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

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

  

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

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

這樣，有時需要多年的成功投資才能擺脫困境。
即使您將同一資料庫從集中式系統轉移到分散式系統，幾乎可以肯定的是，在獲得一定擴充套件的同時，應用程式的效能肯定會受到某些影響。協調鎖和併發將面臨不同的效能挑戰，並且過渡階段將是一條艱難之路。將應用程式調整到分散式資料庫需要耐心和洞察力。
 

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

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



 

相關文章