1. 爲什麼要做數據庫選型

1.1 數據庫選型的重要性與難點

發展數字經濟是當下各行各業的重要方向。支撐數字經濟的底座是軟件，特別是基礎軟件，可以說基礎軟件是整個數字經濟的堅實底座。在基礎軟件領域，有三大基礎軟件，分別是操作系統、數據庫系統和中間件。我們每天日常生活中的方方面面，背後都離不開這些基礎軟件的支撐，其中數據庫系統是業務數據的載體，比如銀行卡上的餘額，是非常重要的數據，不能有任何差錯，數據庫在所有 IT 系統中的地位都是重中之重。

數據庫作爲基礎軟件的重要性不言而喻，各行各業的數字系統都離不開數據庫系統。但不同行業特點不同，行業需求也就不同。面對着業界上百種數據庫類型，到底應該如何根據自己的業務特徵去選擇最合適的數據庫系統？這個問題非常的重要，因爲如果數據庫選擇不合適，可能會讓業務系統停擺，造成嚴重經濟損失。所謂合適的數據庫系統，不僅僅要滿足業務需求，還要儘可能降低成本，減輕運維管理難度，滿足業務未來的發展等等。這是個複雜的問題， 因爲各行各業的業務場景各不相同，對數據庫的需求和使用場景差異很大，可選擇的數據庫系統也是幾十上百種，如此一組合下來，對於非數據庫專業人士，選擇複雜度非常高。

本文的目的就是要嘗試回答這個重要且複雜的問題。如果您計劃將 IT 業務系統部署在火山引擎之上，可以參考本文的思路，選擇合適的火山引擎雲數據庫服務，爲業務應用打造堅實的數據庫底座。

1.2 數據庫發展與類型簡介

數據庫系統在上世紀 70 年代初出現，至今已經發展了半個多世紀，其理論、技術與產品已經非常豐富，呈現出百花齊放的景象。根據其特點可以大概分爲關係型數據庫管理系統 ( RDBMS ) ，非關係型數據庫 ( NoSQL ) ，NewSQL、雲原生數據庫、分佈式數據庫等等。每一類數據庫中使用不同的技術實現，又可以分化出不同的產品類型。根據 DB-Engines 的統計，數據庫產品數量已經有將近 400 種，數據庫廠商也有幾百家，如下圖所示，不同數據庫產品的實際應用規模也大有不同，其中關係型數據庫管理系統是所有數據庫中使用最廣泛的一類。同時，根據卡內基梅隆大學維護的全球數據庫信息庫 ( dbdb.io ) 顯示，數據庫系統種類已經多達 870 種，可謂是欣欣向榮，讓人眼花繚亂。

縱觀整個數據庫發展史，關係型數據庫系統是歷史最悠久並且使用最廣泛的一類數據庫系統，其理論基礎是基於 IBM 研究員 E.F.Codd 博士在 1970 年提出的 ” 關係模型 ( Relational model ) “。關係型數據庫也是過去幾十年裏各行各業使用最多最廣泛的數據庫類型。

隨着 2000 年之後移動互聯網的大規模爆發，催生出了豐富多彩的面向互聯網的應用，這些應用共同的特點是併發量非常高，數據量特別大。基於這些互聯網的新場景與新需求，又出現了 NoSQL 數據庫技術，其理論基礎主要是由 Eric Brewer 提出的 CAP 定理以及 Dan Pritchett 提出的 BASE 原則。

再往後，業界將關係型數據庫與 NoSQL 數據庫的優勢進行了融合，出現了 NewSQL 數據庫，隨着雲原生技術的入場與爆發，又有了雲原生數據庫。

關係型數據庫將數據存儲於二維表格之中，數據以行爲單位，一行數據表示一個實體信息，每一行數據的屬性都是相同的，通過 SQL 語言進行操作，容易理解，廣泛應用於企業的 ERP、CRM、財務系統和交易系統等核心業務系統。其最大的特點是支持事務，遵循 ACID，保證數據強一致性。業界常見的關係型數據庫又分商業數據庫與開源數據庫，其中主流的商業關係型數據庫代表有 Oracle、SQL Server、DB2 等；主流的開源關係型數據庫代表有 MySQL、PostgreSQL、MariaDB 等。

NoSQL，Not Only SQL，” 不僅僅是 SQL”，廣泛應用於以互聯網業務爲代表的場景。NoSQL 數據庫又可以細分爲 KV 型 NoSQL 數據庫 ( 以 Redis 爲代表 ) 、文檔型 NoSQL 數據庫 ( 以 MongoDB 爲代表 ) 、寬列型 NoSQL 數據庫 ( 以 HBase 爲代表 ) 、時序型 NoSQL 數據庫 ( 以 InfluxDB 爲代表 ) 以及圖 NoSL 數據庫 ( 以 Neo4j 爲代表 ) 。雖然這些類型都屬於 NoSQL 數據庫範疇，但是不同類型的 NoSQL 數據庫所適用的場景各有不同，需要根據業務特徵選擇合適的 NoSQL 數據庫。

其中 KV 型 NoSQL 數據庫適用於需要超高性能，讀遠多於寫，並且可以容忍數據部分丟失的場景，例如作爲關係型數據庫的外部緩存，用於提升系統整體的讀性能，減輕關係型數據庫的讀壓力。

文檔型 NoSQL 數據庫使用的是一種半結構化的數據模型（json 或 xml 格式），與關係型數據庫相比，文檔型 NoSQL 是沒有 Schema 的，由於沒有 Schema 的特性，可以隨意地存儲與讀取數據，因此文檔型 NoSQL 數據庫解決了關係型數據庫表結構擴展不方便的問題。

寬列型 NoSQL 數據庫，主要用在大數據、OLAP 場景。其特點是可以提供海量的存儲容量，PB 級別數據量可以輕鬆存儲，並且成本較低。

時序型 NoSQL 數據庫主要應用在一些與時間強相關的數據模型，例如 IoT、監控數據等場景。對於時間序列相關的數據，時序型 NoSQL 數據庫的處理與關係型數據庫的處理方式是不一樣的，時序型 NoSQL 數據庫主要是有效地收集、存儲和查詢高頻產生的各種時間序列數據，對此做了專門的設計和優化，專門用於這類場景。

圖 NoSQL 數據庫主要用於處理‘關係’數據。這裏的‘關係’不是關係型數據庫中的關係，而是指不同對象之間的聯繫。例如，社交關係 ( 人與人的關係 ) 、推薦關係 ( 人與物的關係 ) 、關聯關係 ( 物與物的關係 ) 等等。這類數據用關係型數據庫很難處理，特別是在互聯網海量數據條件下更復雜，所以圖 NoSQL 數據庫主要是針對這類場景做了專門的設計與優化，用於進行‘關係’數據的存儲與查詢。

從技術角度出發，數據庫可以分爲關係型數據庫與 NoSQL 數據庫。從場景角度出發，數據庫又可以分爲 OLTP 數據庫與 OLAP 數據庫。OLTP（Online trancaction processing），是關係型數據庫的主要應用，側重於交互式的事務處理，例如銀行交易、在線訂單處理等。OLAP ( Online analytical processing ) 是數據倉庫系統的主要應用，支持複雜的分析操作，側重分析決策支持，並且提供直觀易懂的查詢結果，主要跟大數據系統關係緊密。OLTP 與 OLAP 系統之間通常會使用 ETL 進行連接。

本文主要側重於 OLTP 系統的選型指南，也就是上圖中圓圈中的範圍，包含關係型數據庫與 NoSQL 數據庫。OLAP 與大數據相關不在本文討論範圍。

2. 選型基本方法論

在開始介紹數據庫選型方法論之前，首先需要介紹一個理念：” 數據庫選型沒有銀彈 “。就是說沒有任何一款數據庫可以滿足所有業務場景的需求，找不到一個可以包打天下的數據庫。

如果真有 ” 數據庫銀彈 “，那也就不必做數據庫選型了，直接用銀彈就行，數據庫世界也就不會出現如此多種類的數據庫技術和產品類型了。

所以需要根據不同的業務場景、業務需求去選擇一款最適合的數據庫系統，這也是本文所要討論的核心問題。

2.1 參與選型的角色

數據庫選型不僅僅是一個技術選擇，而是一個全局選擇。後面會從多種視角多個方面來說明做數據庫選型需要考慮的因素，包括應用接口、數據模型、性能、穩定性、成本、運維複雜度、高可用性、安全性、擴展性等方面。

數據庫選型是一個全局選擇，參與到選擇中的角色主要有三類：

● 開發人員，代表了業務和應用本身。

● DBA，代表了數據庫管理角色。

● 財務部門，代表了成本控制角色。

財務部門主要關注的是數據庫系統的成本，需要根據業務系統的規模、重要性等方面決定財務投入，簡單說就是準備花多少錢建設與維護數據庫系統。投入越多，可以獲得更強的數據庫能力，也可以聘請更專業的 DBA 進行數據庫維護，保障數據庫系統穩定運行。企業組織中越是重要核心的數據庫系統，會獲得更多的資源投入。

DBA，Database Administrator，是數據庫管理員的簡稱。從名字就能看出來，DBA 是負責管理數據庫系統的角色，主要關注數據庫的可運維性，包括監控告警、備份恢復、升級遷移、問題診斷工具、調優工具等；穩定性，包括高可用性、自動主從切換、手動主從切換、會話管理等；性能，包括 QPS、時延、吞吐量等；可擴展性，包括靈活變配、計算擴容、存儲擴容等；安全性，包括 SQL 審計、操作審計、數據加密、數據脫敏等。

開發人員，是應用程序的設計者與開發者，也是數據庫系統的實際使用者，開發人員設計的應用程序會直接與數據庫進行交互，利用數據庫進行數據的高效存取。開發人跟 DBA 的關注點有類似的地方，例如開發人員也會關注數據庫的性能、穩定性、可擴展性。但除此之外，開發人員更關注的是數據庫提供的接口和支持的數據模型，這一點直接決定了應用應該選擇什麼樣的數據庫。接口與數據模型包括了是否支持 SQL、是否遵循 ACID、數據一致性等等。

2.2 數據庫選型考慮

數據庫選型首先需要考慮的應該是業務應用所服務的場景，是 OLTP 場景還是 OLAP 場景。如果是 OLAP，建議參考大數據相關選型指導；如果是 OLTP，可以參考本文的選型指導。

接下來是考慮應用的數據模型。數據模型可以是關係型、半結構化、非結構化、KV 型等等。如果是關係型，可以選擇關係型數據庫；如果是 KV 型，可以選擇 Redis；如果是非結構化或半結構化，可以從 NoSQL 數據庫系列中選擇適合的種類，需要看具體的數據模型。

如果業務應用對事務 ACID 是強需求，那麼關係型數據庫將會是最佳的選擇，例如 MySQL、PostgreSQL 等。

接着要考慮業務應用對數據一致性的要求。如果業務應用需要強一致性，那麼優先選擇關係型數據庫；如果業務應用可以接受數據的最終一致性，那麼各類 NoSQL 數據庫都可以成爲待選項，具體結合數據模型做進一步考慮。其中，MongoDB 可以通過調整本身的某些參數達到數據強一致的效果，開發人員需要關注。

此外，除了考慮業務應用現階段的需求，還需要爲未來做考慮，這裏面最重要的就是預估業務增量，包括對性能、數據量的預估。如果業務在未來增速可能會很快，會需要更強的數據處理能力，或者需要更大的數據容量，那麼也需要同時考慮數據庫的可擴展性，通過擴展來獲取更強的數據處理能力以及更大的數據存儲空間，以保證業務應用可以平穩運行。

3. 火山引擎雲數據庫選型參考

火山引擎雲數據庫提供了豐富的雲數據庫產品類型，包括開源數據庫與自研數據庫，同時也提供了完整的數據庫生態服務，包括數據庫遷移服務與數據庫統一管理服務。接下來會簡單介紹每一種數據庫的特點與適用場景，便於選型參考。

3.1、關係型數據庫 RDS

火山引擎雲數據庫 RDS 是關係型數據庫的合稱，RDS 支持 MySQL 引擎、Postgre SQL 引擎、SQL Server ( 暫未上線，敬請期待 ) 引擎，同時提供了數據庫管理、安全、災備、監控、遷移等全套解決方案。RDS 基於雲原生架構部署，在擴展性、彈性和性價比方面有很大的優勢。

火山引擎雲數據庫 RDS 可以廣泛應用於互聯網電商、遊戲、在線交易等場景，也可以承載傳統 ERP、CRM 等業務數據，具備高可用、高性能、靈活易用等特點，已有多個行業的客戶正在使用火山引擎雲數據庫 RDS 承載其在線核心業務系統。

3.2 雲原生數據庫 veDB MySQL

veDB MySQL 完全兼容開源 MySQL，採用計算存儲分離架構，最大支持 128TiB 的結構化數據存儲，單個數據庫集羣最多可擴展至 16 個計算節點，包含 1 個主節點與 15 個讀節點。基於雲原生數據庫設計理念，雲數據庫 veDB MySQL 既融合了商業數據庫高性能、高可靠、高可用的特徵，又具有開源數據庫簡單開放、快速迭代、高效擴展的優勢。經過字節跳動內部關鍵業務場景的錘鍊和打磨，veDB MySQL 能夠爲企業提供安全可靠、性能優越、功能豐富的數據庫服務。

veDB MySQL 已經在字節跳動內部廣泛使用，承載了內部多條業務線的業務，例如抖音、廣告、小說等業務。在 2021 年的春晚紅包雨活動中，全國一共發起了 703 億次紅包雨互動，其中 veDB MySQL 的讀 QPS 峯值達到 500w+，寫峯值達到 360w+，良好的支持了本次紅包雨活動。

veDB 現在正在公測階段，歡迎試用。https://www.volcengine.com/product/vedb-mysql

3.3 緩存數據庫 Redis

火山引擎緩存數據庫 Redis 提供的是託管型的緩存數據庫服務，兼容開源 Redis 數據庫引擎，幫助您在雲上輕鬆、快速地構建 Redis 數據庫。緩存數據庫 Redis 提供了高性能且安全的 Redis 數據庫解決方案，按需計費結合動態擴展能力能夠顯著地幫助企業降低成本，同時也有助於消除管理、運維數據庫的複雜性。

緩存數據庫 Redis 在開源社區 Redis 架構上進行了大量優化，採用字節跳動內部實踐的 Achemy 架構，極大提升了 Redis 集羣的規模與穩定性。

3.4 文檔數據庫 MongoDB

火山引擎文檔數據庫 MongoDB 版是一款完全兼容開源 MongoDB 協議，且具備高可用、高性能的在線雲數據庫服務。文檔數據庫 MongoDB 支持多種架構，能夠滿足業務靈活部署的需求。除副本集實例架構外，文檔數據庫 MongoDB 還提供了分片集羣架構，以滿足海量數據業務場景，同時提供了災備、備份及恢復、監控等全套解決方案。在互聯網（遊戲、電商、直播、資訊、社交）、新零售等行業都有廣泛的應用。火山引擎文檔數據庫 MongoDB 即將上線 MongoDB 5.0 版本，敬請期待。

3.5 表格數據庫 HBase

火山引擎表格數據庫 HBase 是基於 Apache HBase 提供的全託管 NoSQL 服務，兼容標準 HBase 訪問協議，具備低成本存儲、高吞吐、靈活擴展等優勢。

表格數據庫 HBase 具備以下優勢，幫助您構建理想應用：

支持 KeyValue 數據模型。

● 高可用架構，Master 爲包含兩個節點的主備模式，支持 HA 實時檢測。

● 存儲和計算分離保證數據的高可靠，存儲採用多副本機制，可用性不低於 99.5%。

● 支持實例變配，包括橫向擴容和縱向擴縮容，還提供了監控告警等功能，實例管理簡單方便。

3.6 圖數據庫 veGraph

圖數據庫 veGrap 是一款以屬性圖爲基礎結構數據的分佈式雲原生數據庫，提供了海量關係的數據存儲和毫秒級的在線查詢服務，廣泛應用於社交網絡、欺詐檢測、推薦引擎、知識圖譜等場景。

圖數據庫 veGraph 主要具備如下特性：

● 有向屬性圖。基於有向屬性圖（Property Graph），由點、邊、點類型、邊類型以及屬性組成。

● 可視化圖平臺。查詢結果可視化，支持圖形化地展示數據的關聯性，便於更高效地分析數據。

● 圖管理。提供圖管理、Schema 管理和通過圖形化界面來配置數據導入等功能。

● 圖查詢語言。支持 Gremlin 圖查詢語言。

3.7 生態工具 DTS

火山引擎數據庫傳輸服務 DTS（Database Transmission Service）提供了數據遷移、數據同步、數據訂閱於一體的數據庫數據傳輸管理服務，支持關係型數據庫、非關係型數據庫數據源間的數據傳輸，降低數據庫之間數據流通複雜性，可在業務不停服的前提下輕鬆完成數據庫遷移上雲。相較於第三方遷移工具，數據庫傳輸服務 DTS 可以更方便地創建和管理豐富多樣、高性能、高安全可靠的傳輸鏈路。

3.8 小結

在傳統自建數據庫模式下，DBA 人員需要承擔的運維工作會非常繁雜，從主機、存儲、操作系統到數據庫，每一層都涉及到複雜的運維操作。但是在雲計算時代，火山引擎雲數據庫提供了完善的數據庫運維體系，將很多常規數據庫管理動作都封裝爲自動化功能，DBA 無需再去執行很多複雜的運維命令，直接通過火山引擎雲數據庫控制檯一鍵即可完成。同時火山引擎雲數據庫控制檯上也提供了完善的數據庫指標監控儀表盤，可以從多種維度觀測數據庫系統的運行情況，讓 DBA 對數據庫運行狀態做到心中有數。

火山引擎雲數據庫極大的簡化了複雜的數據庫運維工作，通過自動化、平臺化的方式把 DBA 從繁瑣的運維工作中解放出來。同時火山引擎雲數據庫也提供了高可用部署、自動 / 手動主備切換、自動 / 手動備份、靈活升降配等功能，又進一步的降低了 DBA 的運維工作量，提高了數據庫系統的靈活性。DBA 可以投入更多精力去關注數據庫系統其他方面，例如性能優化，幫助開發人員優化 SQL 等。

在成本方面，火山引擎雲數據庫提供按量計費與包年包月的計費方式，相較於自建數據庫的模式，避免了一次性投入大量資金，做到只爲使用的資源付費，極大的降低了數據庫的成本。

以上就是火山引擎雲數據庫提供的產品與能力，如果我們將這些雲數據庫產品做一個橫向比較，把數據庫選型過程中關注的細節進行對比，我們可以得到下面的雲數據庫能力對比表格。再結合前面介紹的數據庫選型方法論，就可以爲業務應用選擇合適的數據庫系統。

注： * 代表還未上線，敬請期待。

我們把選型方法論和火山引擎雲數據庫產品能力結合在一起，就可以得到了如下的一張選型流程圖，按照流程可以確定應用需要的雲數據庫類型，供大家參考。

4. 測試驗證與優化

爲了確保選擇的雲數據庫可以滿足業務應用需要，可以穩定支撐業務應用的運行，非常建議將業務應用與雲數據庫放在一起進行全面的驗證與測試工作。主要驗證兼容性、性能、異常處理等方面。也可以通過一些測試工具來測試雲數據庫的性能峯值是否滿足業務需求，例如 RDS MySQL 可以使用 sysbench 工具，Redis 可以使用 Memtier-benchmark 工具。

在測試過程中，通過雲數據庫提供的監控系統，收集測試過程中雲數據庫的各項指標，例如 CPU 負載、內存使用率、連接數、響應時間、慢查詢等指標。通過收集到的各項參數指標，找到業務應用或雲數據庫的性能瓶頸所在，並進行相應的調優。

火山引擎雲數據庫線上文檔也有性能測試相關白皮書，提供了測試工具、測試方法和性能結果等內容，可以作爲性能測試的參考內容。

如果出現整體測試效果不佳的情況，一方面需要由 DBA 調整雲數據庫規格、參數，另一方面需要開發人員檢查應用使用雲數據庫的方式，最常見的就是進行 SQL 優化，例如 SQL 查詢中沒有加索引，或者加了索引但因爲某種原因導致索引失效等。除 SQL 優化之外，業務拆分也是常見的優化手段，即將業務數據與壓力分散到不同的數據庫實例之上，這樣既可以保證性能，又可以進行故障隔離。在整體測試效果不佳的時候，需要檢查每一個環節，優化每一個環節。

火山引擎雲數據庫提供了強大的性能、穩定性和功能支撐，但不意味着業務應用不需要遵守一些標準的開發規範，特別是一些 SQL 規範。只有在業務應用與雲數據庫都做到各自最優的時候，整體系統纔可以達到一個最優的情況，讓業務平穩且高性能的運行。需要開發人與 DBA 一起緊密配合，業務需要根據自身特徵選擇數據庫，也需要根據數據庫特徵調整業務邏輯，互相配合才能達到最佳效果。

5. 總結與展望

數據庫一直是 IT 系統基礎中的基礎，核心中的核心。正所謂 ” 基礎不牢，地動山搖 “，數據庫如果出現問題，即使是很小的問題，也會成倍放大最終對業務系統造成嚴重的影響。所以業務系統對數據庫的選擇需要非常謹慎。

本文介紹了數據庫系統的分類與每一類數據庫適合的場景，也從技術和場景細節方面說明了不同的業務特徵應該選擇何種數據庫產品。根據選型流程圖的指導，業務應用可以選擇出合適的數據庫類型。同時也介紹了火山引擎雲數據庫的產品種類和各種特徵，結合選型方法論，可以幫助業務應用在火山引擎上選擇出合適的雲數據庫作爲業務應用的底座。在業務系統正式上線之前，還需要開發人員與 DBA 進行緊密的配合，對整體系統進行充分的測試與優化，保障業務系統可以高性能、平穩的運行。

火山引擎提供了豐富的雲數據產品類型，可以滿足大部分業務場景的需求。雲原生數據庫 veDB 現在正在進行公測，歡迎試用。後續火山引擎雲數據庫還會陸續推出圖數據庫 veGraph、時序數據庫、數據庫工作臺 DBW 等一系列相關產品，敬請期待。