分散式資料庫架構原理 - Alex Petrov

Alex Petrov 是 Apple 的一名軟體工程師。他寫了一本關於 Database Internals 的精彩書籍，深入探討了分散式資料系統的工作原理。

我們將總結他關於資料庫管理系統 (DBMS) 背後架構的書中的一小段內容。

概括

您可能使用過像 Postgres、MySQL 等這樣的 DBMS。

它們提供了一個非常有用的抽象，您可以在應用程式中使用它來儲存和（以後）檢索資料。

所有 DBMS 都提供了一個 API，您可以通過某種型別的查詢語言使用該 API 來儲存和檢索資料。

它們還圍繞如何儲存/檢索這些資料提供了一組保證。這種保證的幾個例子是

• 耐用性- 保證在 DBMS 崩潰時您不會丟失任何資料
• 一致性- 寫入資料後，所有後續讀取是否總是給出資料的最新值？（這對於分散式資料庫很重要）
• 讀/寫速度- IOPS是儲存裝置上每秒輸入和輸出操作的標準度量。

各種資料庫管理系統的體系結構根據它們的保證和設計目標而有很大差異。為OLTP使用而設計的資料庫的設計方式與為OLAP設計的資料庫不同。

記憶體 DBMS（主要將資料儲存在記憶體中並使用磁碟進行恢復和日誌記錄）的設計也將不同於基於磁碟的 DBMS（主要將資料儲存在磁碟上並使用記憶體進行快取）。

但是，資料庫在其各種架構中都有一些共同的主題，瞭解這些主題可以為它們的工作方式提供有用的模型。

下圖可以描述一般架構。

資料庫管理系統使用客戶端/伺服器模型。您的應用程式是客戶端，DBMS 是伺服器（託管在同一臺機器上或不同的機器上）。

傳輸系統Transport是 DBMS 接受客戶端請求的方式。

客戶端請求以資料庫查詢的形式出現，通常以某種型別的查詢語言（例如 SQL）表示。

收到查詢後，傳輸系統會將查詢傳遞給查詢處理器。

查詢處理器將首先解析查詢（例如使用抽象語法樹）並確保它是有效的。

檢查有效性意味著確保查詢有意義（所有命令都被識別，訪問的資料是有效的，等等），並且客戶端被正確地允許訪問/修改他們請求的資料。

如果查詢無效，則資料庫將向客戶端返回錯誤。

否則，解析後的查詢將傳遞給查詢優化器。

優化器將首先消除查詢的冗餘部分，然後使用內部資料庫統計資訊（索引基數、近似交集大小等）來找到執行查詢的最有效方式。

對於分散式資料庫，優化器還將考慮資料放置，例如叢集中的哪個節點儲存資料以及與傳輸相關的成本。

優化器的輸出是描述執行查詢的最佳方法的執行計劃。該計劃也稱為查詢計劃或查詢執行計劃。

該執行計劃被傳遞給執行該計劃的執行引擎。

當您使用分散式資料庫時，執行計劃可能涉及遠端執行（對儲存在不同機器上的資料發出網路請求）。

否則，它只是本地執行（對本地儲存的資料執行查詢）。

遠端執行涉及叢集通訊，其中 DBMS 與資料庫叢集中的其他機器通訊並向它們傳送資料請求。如上圖所示，這是傳輸層的一部分。

本地執行涉及與儲存引擎對話以獲取資料。

儲存引擎是資料庫中直接負責在記憶體和磁碟中儲存、檢索和管理資料的元件。

儲存引擎通常提供一個簡單的資料操作 API（允許 CRUD 功能）幷包含有關如何運算元據的實際細節的所有邏輯。

儲存引擎的示例包括BerkeleyDB、LevelDB、RocksDB等。

資料庫通常允許您選擇正在使用的儲存引擎。

例如，MySQL 有多種儲存引擎可供選擇，包括 RocksDB 和 InnoDB。

儲存引擎由幾個元件組成

事務管理器- 負責建立事務物件並管理它們的原子性（整個事務成功或回滾）。

鎖管理器- 事務將同時執行，因此鎖管理器管理每個事務正在訪問的資料庫物件上的鎖（並在事務提交或回滾時釋放這些鎖）。

訪問方法- 這些管理訪問、壓縮和組織磁碟上的資料。訪問方法包括堆檔案和儲存結構，例如 B 樹。

緩衝區管理器- 此管理器將資料頁快取在 RAM 中，以減少對磁碟的訪問次數。

恢復管理器- 維護操作日誌並在發生故障時恢復系統狀態。

不同的儲存引擎在這些元件之間做出不同的權衡，從而導致壓縮、縮放、分割槽、速度等方面的效能不同。