所有數據庫管理系統(tǒng)的主要工作都是可靠地存儲數據并使其對用戶可用。我們使用數據庫作為數據的主要來源，幫助我們在應用程序的不同部分之間共享數據。我們使用數據庫，而不是在每次創(chuàng)建新應用程序時尋找存儲和檢索信息的方法，也不是每次都去發(fā)明一種組織數據的新方法。這樣一來，我們就可以專注于應用程序邏輯而不是基礎設施。

　　數據庫是模塊化的系統(tǒng)，由多個部分組成：接受請求的傳輸層、決定以最高效方式運行查詢的查詢處理器、執(zhí)行操作的執(zhí)行引擎以及存儲引擎。

　　存儲引擎（或數據庫引擎）是數據庫的一個軟件組件，它負責在內存和磁盤上存儲、檢索和管理數據，而設計它的目的是長久保存每個節(jié)點的數據[REED78]。數據庫可以響應復雜的查詢，存儲引擎則會更細粒度地看待數據并提供一組簡單的數據操作API，允許用戶創(chuàng)建、更新、刪除和檢索數據記錄。從某個角度來看，數據庫是構建在存儲引擎之上的應用程序，它提供了表結構（schema）、查詢語言、索引、事務和許多其他有用的特性。

　　為了獲得靈活性，鍵和值都可以是沒有預設格式的任意字節(jié)序列。它們的排序和表示語義是在更高級別的子系統(tǒng)中定義的。例如，你可以在一個表中使用int32（32位整數）作為鍵，而在另一個表中使用ascii（ASCII字符串）；從存儲引擎的角度來看，這兩個鍵都只是序列化的條目。

　　BerkeleyDB、LevelDB（及其后代RocksDB）、LMDB（及其后代libmdbx、Sophia和HaloDB）等存儲引擎的開發(fā)都與它們現在所嵌入的數據庫彼此獨立。使用可插拔的存儲引擎使數據庫開發(fā)人員能夠使用現有存儲引擎來構建數據庫系統(tǒng)，并將精力集中在其他子系統(tǒng)上。

　　同時，數據庫系統(tǒng)組件之間清晰的解耦為切換不同引擎提供了機會，這些引擎可能分別適用于特定的用例。例如：流行的數據庫MySQL有幾個存儲引擎，包括InnoDB、MyISAM和RocksDB（在MyRocks發(fā)行版中），而MongoDB則允許在WiredTiger、內存以及（現已棄用的）MMAPv1存儲引擎之間進行切換。

　　數據庫的比較

　　對數據庫系統(tǒng)的選擇將會產生長期的影響。如果選擇的數據庫不合適（因其導致性能問題、一致性問題或運維上的挑戰(zhàn)），那么我們最好在開發(fā)周期的早期就發(fā)現這一點，因為遷移到不同的系統(tǒng)可能并非易事，甚至在某些情況下，你還需要對應用程序的代碼進行重大的修改。

　　每個數據庫系統(tǒng)都有優(yōu)點和缺點。為了降低進行高成本遷移的風險，你可以在選擇數據庫上投入一些時間，以確保其具備滿足應用程序需求的能力。

　　試圖根據數據庫的組件（例如：使用的存儲引擎，數據共享、復制和分布的方式等）、它們的排名（ThoughtWorks等咨詢機構或諸如DB-Engines和Database of Databases等數據庫比較網站所呈現的流行度值）或實現語言（C、Java或Go等）來比較數據庫，可能導致無效和不成熟的結論。這些方法只能用于高層次上的比較，并且可能出現例如在HBase和SQLite之間進行選擇這樣粗糙的對比。因此，即使只是對每個數據庫的工作原理和內部結構有粗淺了解，這些了解也可以很好地幫助你得出一個更可靠的結論。

　　每一次比較都應該從清晰界定的目標開始，因為哪怕是最小的偏差都可能使整個調查完全無效。如果你正在找尋一個非常適合當下（或者未來）的工作負載的數據庫，那么你所能做的最好的事情就是在不同的數據庫系統(tǒng)上模擬這些工作負載、測量對你很重要的那些性能指標，并比較結果。有些問題（特別是性能和可伸縮性方面的問題）只有在一段時間后或隨著容量的增長才會開始顯現出來。為了發(fā)現潛在的問題，最好在盡可能接近真實生產環(huán)境的環(huán)境中進行長期的運行測試。

　　模擬現實世界中的工作負載不僅能幫助你了解數據庫的運行方式，還能幫助你學習如何操作與調試數據庫，并了解其社區(qū)的友好程度和能提供幫助的程度。數據庫的選擇總是這些因素的組合，而性能通常并不是最重要的方面：使用保存數據緩慢的數據庫通常比使用會快速丟失數據的數據庫要好得多。

　　要比較數據庫，非常詳細地理解用例并定義當前和預期的變量是有幫助的，例如:

　　表結構和記錄大小

　　客戶端數量

　　查詢類型和訪問模式

　　讀寫查詢速率

　　任何這些變量中的預期變化

　　明確這些變量可以幫助回答以下問題：

　　數據庫支持所需的查詢嗎？

　　數據庫能夠處理我們計劃存儲的數據量嗎？

　　單個節(jié)點可以處理的讀寫操作有多少？

　　一個系統(tǒng)計劃要有多少個節(jié)點？

　　鑒于預期的增長率，我們如何擴展集群？

　　維護過程是什么？

　　在回答了這些問題之后，你可以構建一個測試集群并模擬你的工作負載。大多數數據庫已經有了壓測工具，可以用來重現特定的用例。如果沒有標準的壓測工具用來在數據庫生態(tài)系統(tǒng)中生成現實中的隨機工作負載，那么這可能是一個危險的信號。如果有什么東西讓你無法使用數據庫自帶的工具，那么你可以嘗試一個現有的通用工具，或者從零開始實現一個。

　　如果測試結果理想，那么進一步熟悉數據庫代碼可能會有更大的幫助。為了閱讀源代碼，首先要了解數據庫的各個部分、如何查找不同組件的源代碼，然后瀏覽這些組件。即使僅對數據庫代碼庫有一個粗略的了解，也有助于你更好地理解它產生的日志和配置參數，并幫助你在使用數據庫的應用程序中，甚至在數據庫代碼本身發(fā)現問題。

　　有些人以為，可以將數據庫當作黑匣子而無須了解其中的內容是件好事。但實踐往往表明，這樣做遲早會碰到bug、服務中斷、性能倒退或其他問題。你最好為這些問題做好準備，如果你了解并且理解數據庫的內部結構，就可以減少業(yè)務風險且更有可能快速地恢復。

　　用于基準測試、性能評估和比較的一個流行工具是Yahoo! Cloud Serving Benchmark（YCSB）。YCSB提供了一個框架和一組可應用于不同數據存儲的公共工作負載集。就像任何通用的東西一樣，你應該小心使用這個工具，因為使用它很容易得出錯誤的結論。為了進行公平的比較并做出明智的決定，你需要投入足夠的時間來了解數據庫將在何種實際環(huán)境下運行，并相應地調整基準測試的內容。

　　TPC-C基準

　　事務處理性能委員會（Transaction Processing Performance Council，TPC）提供了一組數據庫廠商用來比較和宣傳其產品性能的基準。TPC-C是一個聯機事務處理（OLTP）基準，它是只讀事務和更新事務的混合，用于模擬常見的應用程序工作負載。

　　該基準關注的是執(zhí)行的并發(fā)事務的性能和正確性。主要性能指標是吞吐量：數據庫系統(tǒng)每分鐘能夠處理的事務數。其需要執(zhí)行事務具備ACID屬性并符合基準本身定義的屬性集。

　　此基準不專注于任何特定的業(yè)務部門，但提供了對大多數適用OLTP數據庫的應用都很重要的抽象操作集。它包括幾個表和實體，如倉庫、庫存、客戶和訂單，并指定了表布局、可以對表執(zhí)行的事務的細節(jié)、表的最小行數和數據持久性約束。

　　這并不意味著基準測試只能用于比較數據庫。基準可用于定義和測試服務級別協(xié)議注1的詳細信息、了解系統(tǒng)要求以及容量規(guī)劃等。你在使用數據庫之前對它了解得越多，在生產環(huán)境中運行數據庫時節(jié)省的時間就越多。

　　選擇數據庫是一個長期的決定，最好跟蹤新發(fā)布的版本，了解到底發(fā)生了什么變化及其原因，并制定升級策略。新版本通常包含對bug和安全問題的改進及修復，但也可能會引入新的bug、性能退化或意外行為，因此在部署新版本之前測試新版本也是至關重要的。查看數據庫開發(fā)者以前是如何處理升級的，可能會讓你對將來的情況有一個很好的了解。過去的順利升級并不能保證未來的升級也會如此順利，但過去復雜的升級可能也是未來升級亦會不容易的標志。

　　理解權衡取舍

　　作為用戶，我們可以看到數據庫在不同條件下的行為，但是在使用數據庫時，我們必須做出選擇來直接影響其行為。

　　設計一個存儲引擎肯定比僅實現一個教科書上的數據結構要復雜得多：很難在一開始就將許多細節(jié)和邊界情況處理正確。我們需要設計物理數據布局和組織指針、決定序列化格式、了解數據將如何被進行垃圾收集、存儲引擎如何適應整個數據庫系統(tǒng)的語義、探索如何使其在并發(fā)環(huán)境中工作，以及最后確保在任何情況下都不會丟失任何數據。

　　不僅有許多事情需要決定，而且這些決定中的大多數都涉及權衡取舍。例如，如果按數據插入數據庫的順序保存，我們就可以更快地存儲它們；但是如果按字典順序檢索它們，我們就必須在將結果返回給客戶端之前對它們進行重新排序。正如你將在本書中看到的那樣，存儲引擎設計有許多不同的方法，每個實現都有它自己的優(yōu)點和缺點。

　　在研究不同的存儲引擎時，我們會討論它們的優(yōu)點和缺點。如果對于每個可以想到的用例都有一個絕對最優(yōu)的存儲引擎，那么人人都一定會使用它。但是并不存在這樣的儲存引擎，因此我們需要根據服務的工作負載和用例進行明智的選擇。

　　市面上有許多存儲引擎，它們使用各種數據結構并且用不同的語言實現—從低級語言（如C）到高級語言（如Java）。所有存儲引擎都面臨相同的挑戰(zhàn)和限制?？梢詫⑵渑c城市規(guī)劃相類比：我們?yōu)樘囟ǖ娜丝跀盗繕嫿ㄒ蛔鞘?，并選擇是在高度上還是面積上對這座城市進行擴展。這兩種情況都可以將同樣數量的人放入該城市，但這些方法導致了截然不同的生活方式。當在高度上建設城市時，人們住在公寓里，人口密度可能導致面積較小地區(qū)的交通流量增加；而在一個面積更大且更分散的城市中，人們更有可能住在大房子里，但通勤則需要走更遠的路。

　　類似地，存儲引擎的開發(fā)人員所做的設計決策使它們更適合于不同的情況：有些對低讀寫延遲進行了優(yōu)化，有些則試圖最大化存儲密度（每個節(jié)點存儲的數據量），而有些則專注于運維上的簡單性。

　　在《數據庫系統(tǒng)內幕》的小結中，你可以找到可用于實現的完整算法和其他附加參考。閱讀本書可以使你為高效地利用這些資料而做好準備，并使你對其中所述概念的現有替代辦法有扎實的理解。