數據庫如何選擇

這篇文章給大家分享的是有關數據庫如何選擇的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

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

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

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

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

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

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

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

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

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

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

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

表結構和記錄大小

客戶端數量

查詢類型和訪問模式

讀寫查詢速率

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

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

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

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

單個節點可以處理的讀寫操作有多少?

一個系統計劃要有多少個節點?

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

維護過程是什么?

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

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

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

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

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

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

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

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

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

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

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

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

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

市面上有許多存儲引擎，它們使用各種數據結構并且用不同的語言實現—從低級語言(如C)到高級語言(如Java)。所有存儲引擎都面臨相同的挑戰和限制。可以將其與城市規劃相類比：我們為特定的人口數量構建一座城市，并選擇是在高度上還是面積上對這座城市進行擴展。這兩種情況都可以將同樣數量的人放入該城市，但這些方法導致了截然不同的生活方式。當在高度上建設城市時，人們住在公寓里，人口密度可能導致面積較小地區的交通流量增加;而在一個面積更大且更分散的城市中，人們更有可能住在大房子里，但通勤則需要走更遠的路。

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

感謝各位的閱讀！關于“數據庫如何選擇”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！