一文讀懂火山引擎雲資料庫產品及選型
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 等一系列相關產品，敬請期待。
