什麼是資料庫？

資料定義控制系統中資料的形態和結構

建立和控制資料在資料庫中的結構是資料庫管理的重要組成部分。這可以幫助你在將資料攝取到系統之前，控制資料的形態或結構。它還允許你設定約束，以確保資料符合特定引數。

在處理高度規範化資料的資料庫（如關係型資料庫）中，這些定義通常被稱為資料庫的模式。資料庫模式是資料必須如何格式化才能被特定資料庫接受的嚴格大綱。這包括單個記錄中必須存在的特定欄位，以及資料型別、欄位長度、最小值或最大值等值要求。資料庫模式是資料庫所有者影響和控制系統中儲存資料最重要的工具之一。

那些重視靈活性而非規範性的資料庫管理系統通常被稱為無模式資料庫。雖然這似乎暗示這些資料庫中儲存的資料沒有結構，但通常情況並非如此。相反，資料庫的結構由資料本身以及應用程式對資料的瞭解和關聯決定。資料庫通常仍然遵循某種結構，但資料庫管理系統在強制執行約束方面的參與較少。這是一種設計選擇，根據具體情況有其優點和缺點。

資料更新：從系統中攝取、修改和刪除資料

資料更新包括任何以下操作：

• 向系統中錄入新資料
• 修改現有條目
• 從資料庫中刪除條目

這些功能對於任何資料庫都是必不可少的，在許多情況下，它們構成了資料庫系統處理的大部分操作。這些型別的活動——即導致系統中資料發生變化的操作——統稱為寫入操作。

寫入操作對於任何會隨時間變化的資料來源都非常重要。即使是刪除資料這種破壞性操作，也被認為是寫入操作，因為它修改了系統中的資料。

由於寫入操作可以改變資料，這些操作具有潛在危險性。大多數資料庫管理員會配置他們的系統，將寫入操作限制在特定的應用程式程序中，以最大程度地減少意外或惡意資料損壞的可能性。例如，資料分析（利用現有資料回答關於網站效能或訪客行為的問題）只需要讀取許可權。另一方面，應用程式中記錄使用者訂單的部分則需要能夠向資料庫寫入新資料。

檢索資料以提取資訊或回答特定問題

儲存資料本身用處不大，除非你能在需要時檢索它。由於返回資料不會影響資料庫中當前儲存的任何資訊，這些操作被稱為讀取操作。讀取操作是獲取資料庫中已儲存資料的主要方式。

資料庫管理系統幾乎總是有一種透過唯一識別符號（通常稱為主鍵）訪問資料的直接方式。這允許透過提供鍵來訪問任何一個條目。

許多系統還擁有複雜的資料庫查詢方法，以返回符合特定條件的資料集或返回條目的部分資訊。這種查詢靈活性有助於資料庫管理系統除了基本資料儲存能力外，還能作為資料處理器執行。透過開發特定的查詢，使用者可以促使資料庫系統只返回他們所需的資訊。此功能通常與寫入操作結合使用，透過記錄的屬性來定位和修改特定記錄。

管理資料庫系統以確保其順利執行

資料庫通常支援的最後一類操作是管理功能。這是一類廣泛而通用的操作，旨在支援資料庫環境，而不直接影響資料本身。屬於此組的一些專案包括：

• 管理使用者、許可權、認證和授權
• 設定和維護備份
• 配置儲存的後端介質
• 管理複製及其他擴充套件性考量
• 提供線上和離線恢復選項

這組操作與任何現代應用程式共有的基本管理問題相符。

管理操作可能不是核心資料管理功能的中心，但這些能力通常使類似的資料庫管理系統脫穎而出。能夠輕鬆備份和恢復資料、實現與現有系統掛鉤的使用者管理，或者擴充套件資料庫以滿足需求，這些都是在生產環境中執行必不可少的功能。未能關注這些領域的資料庫往往難以在實際環境中獲得採用。

透過忠實記錄和重構來保障資料完整性

資料完整性是資料庫系統的基本要求，無論其目的或設計如何。載入到資料庫中的資料應該能夠可靠地檢索，而不會發生意外修改、篡改或擦除。這需要可靠的資料載入和檢索方法，以及在必要時對資料進行序列化和反序列化以將其儲存在物理介質上。

資料庫通常依賴於在寫入或檢索資料時驗證資料的功能，例如校驗和，或者使用預寫日誌等技術來防止意外關機導致的問題。資料儲存越分散式，資料完整性就越具挑戰性，因為系統的每個部分都必須反映每個資料項當前的期望狀態。這通常透過在系統中資料發生變化時，對多個成員提出更嚴格的要求和響應來實現。

提供滿足部署環境要求的效能

資料庫必須充分發揮效能才能有用。你所需的效能特徵在很大程度上取決於應用程式的特定需求。每個環境對讀寫請求都有獨特的平衡要求，你必須決定這兩個類別可接受的效能標準。

資料庫通常更擅長執行某些型別的操作。操作效能特徵通常反映了所使用的資料庫型別、資料模式或結構以及操作本身。在某些情況下，索引等功能（它為常用資料建立了效能最佳化的替代儲存）可以為這些專案提供更快的檢索。其他時候，資料庫可能不適合所請求的訪問模式。在決定你需要哪種型別的資料庫時，這是一個需要考慮的問題。

設定程序以實現安全的併發訪問

雖然這不是一個嚴格的要求，但實際上，資料庫必須允許併發訪問。這意味著多個參與方必須能夠同時操作資料庫。記錄應該能夠被任意數量的使用者同時讀取，並且在未被其他使用者鎖定時代能夠寫入。

併發訪問通常意味著資料庫必須實現其他一些基本功能，如使用者賬戶、許可權系統以及認證和授權機制。它還必須制定策略，防止多個使用者同時嘗試操作相同的資料。記錄鎖定和事務通常用於解決這些問題。

單獨或聚合檢索資料

資料庫的基本職責之一是能夠按請求檢索資料。請求可能針對與單個記錄關聯的單個數據，也可能涉及檢索許多不同記錄中的資料。在大多數系統中，這兩種情況都必須是可能的。

在大多數資料庫中，檢索期間由資料庫本身提供一定程度的資料處理。這可能包括以下型別的操作：

• 按條件搜尋
• 過濾和遵守約束
• 提取特定欄位
• 平均、排序等

這些選項幫助你清晰地表達你想要的資料以及最有用的格式。

本地記憶體或臨時檔案系統

有時應用程式會產生無用或僅在應用程式生命週期內相關的資料。在這種情況下，你可能希望將資料保留在記憶體中或解除安裝到臨時檔案系統，因為一旦應用程式退出，你就不再需要它了。對於資料永無用處的情況，你可能希望完全停用輸出或將其記錄到/dev/null。

將應用程式資料直接序列化到本地檔案系統

資料庫可能不需要的另一種情況是，少量資料可以直接序列化和反序列化。這僅適用於資料量小、使用模式可預測且幾乎不涉及併發的情況。這種方法擴充套件性不佳，但對於某些情況（例如輸出本地日誌資訊）可能很有用。

將檔案類物件直接儲存到磁碟或物件儲存

有時，來自應用程式的資料可以直接寫入磁碟或替代儲存，而不是儲存到資料庫中。例如，如果資料已經組織成面向檔案的格式（如影像或音訊檔案），並且不需要額外的元資料，那麼將其直接儲存到磁碟或專用物件儲存中可能最簡單。

儲存和處理站點資料

資料庫的主要用途之一是儲存和處理與站點相關的資料。這些項影響站點資訊的組織方式，並且在許多情況下，構成了站點的主要“內容”。

在上述示例應用程式中，資料庫將填充站點的絕大部分內容，包括產品資訊、庫存詳情和使用者配置檔案資訊。這意味著每次需要顯示產品列表、產品詳情頁面或使用者配置檔案時，都將查詢資料庫或某個中間快取。

資料庫還會在顯示當前和歷史訂單、計算運費以及透過檢查折扣程式碼或計算常客獎勵來應用折扣時涉及。我們的示例站點將使用資料庫系統透過結合產品資訊、庫存和使用者資訊來正確構建訂單。訂單中記錄的複合資訊將再次儲存在資料庫中，以跟蹤訂單處理、允許退貨、取消或修改訂單，或提供更好的客戶支援。

分析資訊以幫助做出更好的決策

上一類別的操作與網站的基本功能有關。雖然這些對於處理應用程式層的資料需求非常重要，但它們並未涵蓋全貌。

一旦你的Web應用程式開始註冊使用者和處理訂單，你可能希望能夠回答關於不同產品銷售情況、哪些使用者最有利可圖以及哪些因素影響你的銷售等詳細問題。這些是可以在任何時候執行的分析性問題，用於收集關於組織趨勢和業績的最新情報。

這些型別的操作通常被稱為商業智慧或分析。它們共同幫助組織瞭解過去發生的事情並做出明智的改變。資料庫系統儲存這些過程中使用的大部分資料，並且必須提供適當的工具或查詢能力來回答相關問題。

在我們的示例應用程式中，可以查詢資料庫來回答關於產品趨勢、使用者註冊數量、我們主要發貨到哪些州，或者誰是我們最忠實的使用者等問題。這些相對基本的查詢可以用於組成更復雜的問題，以便更好地理解和控制影響產品效能的因素。

管理軟體配置

某些型別的資料庫被用作網路上其他軟體的配置值儲存庫。它們作為網路上配置值的中央真實來源。當新服務啟動時，它們被配置為在配置資料庫的網路地址處檢查特定鍵的值。這使你能夠將引導服務所需的所有資訊儲存在一個位置。

引導完成後，應用程式可以配置為監視與其配置相關的鍵的變化。如果檢測到更改，應用程式可以重新配置自身以使用新配置。這個過程有時由一個管理過程協調，透過在新服務啟動時逐漸關閉舊服務，隨著時間推移更改活動配置以保持可用性，從而逐步推出新值。

我們的應用程式可以使用這種型別的資料庫來儲存整個應用程式環境的持久配置資料。我們的應用伺服器、Web伺服器、負載均衡器、訊息佇列等都可以配置為引用配置資料庫以獲取其生產設定。應用程式的開發者隨後可以在一箇中心位置透過調整配置值來修改環境的行為。

收集日誌、事件及其他輸出

正在積極處理請求的執行中應用程式會產生大量輸出。這包括日誌檔案、事件及其他輸出。這些資料可以寫入磁碟或其他非受管位置，但這限制了它們的有用性。將此類資料收集到資料庫中，可以更方便地處理、發現模式，並在發生意外情況或需要了解更多歷史性能時分析事件。

我們的示例應用程式可以將每個系統的日誌收集到一個數據庫中，以便於分析。這可以幫助我們找到事件之間的關聯，從而分析問題根源或瞭解我們整個環境的健康狀況。

另外，我們可能將基礎設施和程式碼產生的指標收集到時序資料庫中，這是一種專門設計用於跟蹤隨時間變化的數值的資料庫。該資料庫可以用於支援即時監控和視覺化工具，為應用程式的開發和運營團隊提供有關效能、錯誤率等方面的資訊。

資料架構師

資料架構師負責資料庫系統的整體宏觀結構、它們嚮應用程式和開發團隊公開的介面，以及滿足組織資料需求所需的基礎技術和基礎設施。

擔任此角色的人員通常決定用於不同應用程式的適當資料庫模型和實現。他們負責透過研究選項、決定技術、與現有系統整合以及為組織開發全面的資料策略來實施資料庫決策。他們全面處理資料系統，並參與決定和實施各種專案的資料模型。

DBA（資料庫管理員）

資料庫管理員（或DBA）是負責確保資料系統平穩執行的人員。他們負責規劃新的資料系統、安裝和配置軟體、為其他方設定資料庫系統以及管理效能。他們還經常負責保護資料庫安全、監控問題以及調整系統以最佳化使用模式。

資料庫管理員是單個數據庫系統以及如何將其與底層作業系統和硬體良好整合以最大化效能的專家。他們與使用資料庫的團隊廣泛合作，幫助管理容量和效能，並協助團隊解決資料庫系統的問題。

應用程式開發者

應用程式開發者以多種不同方式與資料庫互動。他們開發了許多與資料庫互動的應用程式。這非常重要，因為這些應用程式幾乎總是唯一控制單個使用者或客戶如何與資料庫系統管理的資料互動的應用程式。效能、正確性和可靠性對應用程式開發者而言極其重要。

開發者管理與其應用程式相關的資料結構，以便將資料持久化到磁碟。他們必須建立或使用能夠將他們的程式設計資料對映到資料庫系統的機制，以便元件能夠協同工作。隨著應用程式的變化，他們必須保持資料庫系統內的資料和資料結構同步。我們將在文章後面更詳細地討論開發者如何使用資料庫。

SRE（站點可靠性工程師）和運維專業人員

SRE（站點可靠性工程師）和運維專業人員從基礎設施和應用程式配置的角度與資料庫系統互動。他們可能負責預置額外容量、搭建資料庫系統、確保資料庫配置符合組織指南、監控正常執行時間以及管理備份。

在許多方面，這些人員與DBA的職責有重疊，但他們並非只專注於資料庫。運維人員確保組織其他部門所依賴的應用程式系統（包括資料庫系統）可靠執行且停機時間最短。

商業智慧和資料分析師

商業智慧部門和資料分析師主要關注資料庫系統中已收集和可用的資料。他們致力於根據資料中的趨勢和模式得出洞察，以便預測未來表現，就潛在變化向組織提供建議，併為市場和銷售等其他部門回答有關資料的問題。

資料分析師通常只對資料系統擁有隻讀訪問許可權。他們執行的查詢通常與主應用程式使用的查詢具有顯著不同的效能特徵。因此，他們經常使用資料庫副本（或複製品），以便能夠執行可能影響主資料庫系統資源使用量的長時間執行且效能密集型的聚合查詢。

在應用程式和資料庫之間轉換資料

你需要建立或使用現有介面來與資料庫通訊。你可以使用常規網路函式直接連線資料庫，利用簡單的庫，或者使用更高階的程式設計庫（例如查詢構建器或ORM）。

ORM，即物件關係對映器，是對映層，用於將關係資料庫中的錶轉換為面向物件程式語言中使用的類，反之亦然。雖然這種轉換通常很有用，但它從不完美。物件關係阻抗失配是一個術語，用於描述關係資料庫和麵向物件程式在資料結構方式上的差異所導致的摩擦。

儘管關係型資料庫和麵向物件程式設計描述了兩種特定的設計選擇，但應用程式層和資料庫層之間的轉換問題是一個普遍存在的問題，無論資料庫型別或程式設計正規化如何。資料庫抽象層是負責在這兩個上下文之間進行轉換的軟體的更通用術語。

保持結構變化與資料庫同步

在你開發應用程式時會發現一個重要事實：由於資料庫存在於你的程式碼庫之外，因此它需要特別關注以應對資料結構的變化。這個問題在某些資料庫設計中比其他設計更常見。

將應用程式資料結構與資料庫同步的最常見方法是一個稱為資料庫遷移或模式遷移（兩者通俗地都簡稱為遷移）的過程。遷移涉及更新資料庫的結構，以反映應用程式資料模型演變時的變化。這些通常以一系列檔案的形式出現，每個演變一個檔案，其中包含將資料庫轉換為新格式所需的語句。

保護資料訪問和清理輸入

作為開發者，在使用資料庫時的一個重要職責是確保你的應用程式不允許未經授權的資料訪問。資料安全是一個廣泛的、多層次的問題，涉及許多利益相關者。最終，某些安全考量將是你的職責範圍。

你的應用程式將需要特權訪問資料庫以執行日常任務。為了安全起見，資料庫的授權框架可以幫助限制你的應用程式可以執行的操作型別。但是，你需要確保你的應用程式適當限制這些操作。例如，如果你的應用程式管理使用者配置檔案資料，你必須防止使用者透過操縱訪問許可權來檢視或編輯其他使用者的資訊。

一個具體的挑戰是清理使用者輸入。清理輸入意味著在操作使用者提供的任何資料時採取特殊預防措施。惡意行為者利用正常的​​使用者輸入機制欺騙應用程式洩露敏感資料有著悠久的歷史。設計你的應用程式以防止這些情況發生是一項重要的技能。