百度BaikalDB在同程藝龍的成功應用實踐剖析

導讀：文章主要介紹 BaikalDB在同程藝龍的完整落地實踐，文章把BaikalDB總結爲六個核心特性，分別是《BaikalDB高可用與HTAP特性實踐》、《BaikalDB 高性能與擴展性實踐》、《BaikalDB 低成本的思考》，但願對你們有幫助。

全文14032字，預計閱讀時間 19分鐘。

1、BaikalDB高可用與HTAP特性實踐

咱們從2019年開始調研開源NewSQL數據庫BaikalDB，嘗試解決工做中遇到的一些實際問題，例如OLAP業務跑在行存數據庫上查詢速度慢，數據庫跨中心部署高可用方案待完善，在近6個月的研究與實踐中，咱們向社區提交了列存特性，並使用BaikalDB分別部署了基於列存的OLAP類業務，基於行存的OLTP類業務，及基於雙中心的高可用部署方案，有效的解決了相關問題，在這裏作一個相關使用經驗的分享，但願能夠給遇到相似問題的同窗提供參考。

一、BaikalDB選型考慮

1.1業界紛紛佈局NewSQL

1.2 NewSQL數據庫核心技術對比

• 注1：ShardingSphere基於MySQL MGR的Paxos複製協議還沒有發佈。

• 注2：TiDB 3.0起已同時支持樂觀事務與悲觀事務。

• 注3：因爲筆者精力所限，尚有不少NewSQL未參與對比：Amazon Aurora，Aliyun PolarDB， AnalyticDB，Apple FoundationDB， CockroachDB, 華爲GaussDB， Yandex ClickHouse等。

1.3 NewSQL技術選型

路徑選擇：

• 純自研：能力有限，投入有限

• 純開源：沒法及時知足定製化需求

• 雲服務：安全與成本考慮，短時間內核心業務自建IDC，k8s化

• 半自研：咱們的選擇，不重複造輪子，主體功能交由社區完成，集中有限力量知足公司需求，可供選擇的NewSQL有：TiDB，BaikalDB，CockRoachDB等。

從以上幾款開源DB中，最終選擇BaikalDB的緣由有：

• 背景類似：BaikalDB來源於百度鳳巢廣告業務團隊，因爲廣告業務的增加走過了從單機到分庫分表到分佈式的全過程，而咱們面臨相似的問題。

• 經受考驗：已經有百度廣告平臺多個業務實際使用經驗，千級別集羣節點，PB級數據規模，咱們跟進使用，風險可控。

• 技術棧匹配：BaikalDB（c++實現， 10萬行代碼精煉），依賴少而精（brpc，braft，rocksdb），社區友好，部署簡單，技術棧匹配。

• 特性比較完善：基本知足咱們需求，咱們能夠專一於知足公司需求。

1.4 BaikalDB簡介

BaikalDB是一款百度開源（github.com/baidu/BaikalDB ）分佈式關係型HTAP數據庫。支持PB級結構化數據的隨機實時讀寫。

架構以下：

其中：

• BaikalStore 負責數據存儲，用 region 組織，三個 Store 的 三個region造成一個 Raft group 實現三副本，多實例部署，Store實例宕機能夠自動遷移 Region數據。

• BaikalMeta 負責元信息管理，包括分區，容量，權限，均衡等，Raft保障的3副本部署，Meta 宕機隻影響數據沒法擴容遷移，不影響數據讀寫。

• BaikalDB 負責前端SQL解析，查詢計劃生成執行，無狀態全同構多實例部署，宕機實例數不超過 qps 承載極限便可。

核心特性：

• 強一致：實現Read Committed 級別的分佈式事務，保證數據庫的ACID 特性

• 高可用：Multi Raft協議保證數據多副本一致性，少數節點故障自愈， 支持跨機房部署，異地多活，可用性>99.99%， RTO=0， RPO<30s

• 高擴展：Share-nothing架構，存儲與計算分離， 在線縮擴容不停服 5分鐘內完成，動態變動schema 30s生效

• 高性能：表1000張，單表：10億行，1千列狀況下：QPS >1W 點查 P95 < 100ms

• 易用性：兼容MySQL 5.6協議

二、BaikalDB線上遷移過程

咱們在線上已部署了50個存儲節點百億行數據規模的BaikalDB集羣，本章將重點講述業務遷移到BaikalDB的步驟以確保上線過程平穩與業務無縫遷移。總體的上線過程可分爲以下幾個階段：

2.1 列存特性開發

因爲咱們上線的首個業務是分析類業務，適合列式存儲，在社區的幫助與指導下，咱們開發並提交了列存特性，原理見列式存儲引擎

2.2 配套運維工具

• 部署工具：線上暫以自研部署腳本爲主，將來會對接公司k8s；

• 監控工具：Prometheus，BaikalDB對接Prometheus很是簡單，參見監控指標導出到Prometheus

• 數據同步工具：Canal + 數據同步平臺，原理相似再也不展開；

• 物理備份工具：SSTBackup，使用說明見基於SST的備份與恢復 ，能夠實現全量+增量的物理備份，內部數據格式，僅適用於BaikalDB；

• 邏輯備份工具：BaikalDumper，模擬MySQLDumper，導出的是SQL語句，能夠導入到其餘數據庫，目前只支持全量導出；

• 測試工具：Sysbench 使用說明見BaikalDB Sysbench

• 欠缺的工具：基於MySQL binlog的數據訂閱工具，開發中。

2.3 數據遷移

數據同步採用全量+增量同步方式，全量採用批量插入，增量原理相似於MySQL binlog訂閱，採用Replace模式同步。共計80億條數據全量同步約3天，增量同步穩定在10ms之內。

2.4 業務測試

通過數據同步環節，BaikalDB已經具有與線上等價數據集，業務測試階段重點在於對待上線系統真實SQL的支持能力，咱們採用全流量回放的方式進行。

以下圖： 

經過實時回放線上真實流量咱們主要驗證了：

• 業務使用SQL的100%兼容性

• 業務峯值的性能承載能力

• 7*24小時的穩定性

2.5 業務上線

通過以上環節，業務上線須要的惟一操做就是更改數據庫鏈接配置。

2.6 運維與監控

下圖是上線後部分指標Prometheus監控截圖，能夠看到從qps，響應時間，環比變化看均十分平穩。

2.7 注意事項

BaikalDB尚在完善的功能：

• 子查詢：開發中

• information_schema：圖形化工具支持與系統變量支持不全，開發中

• 行列並存：一張表可選擇行存或列存，但不能並存，開發中

• 分佈式時鐘：影響事務隔離級別，與Follower一致性讀，開發中

• 視圖：排期中

• 觸發器，存儲過程等傳統關係型數據庫功能，暫無規劃

使用BaikalDB須要注意的事項：

• 數據建模：DB並不能取代數據庫使用者的角色，好的數據模型，表結構的設計，主鍵與索引的使用，SQL語句，在咱們實際測試中比壞的用法會有10倍以上的提高；

• 寫放大：與RocksDB層數有關，建議單store數據大小控制在1T之內；

• 參數調優：默認配置已很是合理，僅有少許參數建議根據實際狀況修改：

export TCMALLOC_SAMPLE_PARAMETER=524288 #512kexport TCMALLOC_MAX_TOTAL_THREAD_CACHE_BYTES=209715200 #200M，當大value時，調大能夠避免線程競爭，提升性能-bthread_concurrency=200 # 建議（cpu核數- 4）* 10-low_query_timeout_s=60 # 慢查詢閾值，建議根據需求設置-peer_balance_by_ip=false # 默認爲false，單機多實例時建議開啓-max_background_jobs = 24 #建議（cpu核數- 4）-cache_size = 64M #建議不超過單實例內存空間40%

• 大事務限制：行鎖限制：per_txn_max_num_locks 默認100w；DB與Store RPC 包的大小限制：max_body_size默認256M；消息體限制：max protobuf size =2G，此爲protobuf限制不可修改。通常建議事務影響行數不超過10M；

• 雙機房資源預留Buffer：資源使用率建議40%左右，容災時單機房須要承載double的壓力，分配副本時disk_used_percent 超過80%的store將被剔除。

三、高可用與HTAP部署方案

咱們的BaikalDB一套集羣部署在兩個城市4個IDC機房，同時支撐基於行存的OLTP業務與基於列存的OLAP業務，本章將說明咱們是如何經過設計部署方案來發揮BaikalDB高可用與HTAP能力的。

雙中心HTAP部署示意圖：

• 注1：圖中省去了meta節點部署

• 注2：每一個IDC會實際部署了多個store與db節點。

如上圖城市 A與城市 B雙中心採用徹底對稱的部署結構，在BaikalDB裏Region是存儲的基本單位，每張表至少有一個Region組成，每一個Region有若干個peer合在一塊兒構成了一組Raft Group。每一個store便可建立行存表也能夠建立列存表，業務建表時能夠根據場景的不一樣進行選擇，另外業務也能夠根據地域的不一樣選擇副本的分佈，例如城市 A的業務能夠選擇城市 A 2副本+城市 B 1副本，城市 B的業務能夠選擇城市 A 1副本+城市 B 2副本。

假設有2家業務在使用BaikalDB集羣，業務A是一個部署在城市 A的OLAP類業務建立了表ctable用Region1表明。業務B是一個部署在城市 B的OLTP類業務建立了表rtable用Region2表明。則相關的配置過程以下：

1. 初始化meta機房信息

echo -e "場景：添加邏輯機房bj sz\n"curl -d '{"op_type": "OP_ADD_LOGICAL","logical_rooms": {"logical_rooms" : ["bj", "sz"]}}' http://$1/MetaService/meta_managerecho -e "插入bj物理機房\n"curl -d '{"op_type": "OP_ADD_PHYSICAL","physical_rooms": {"logical_room" : "bj","physical_rooms" : ["bj1","bj2"]}}' http://$1/MetaService/meta_managerecho -e "\n"echo -e "插入sz物理機房\n"curl -d '{"op_type": "OP_ADD_PHYSICAL","physical_rooms": {"logical_room" : "sz","physical_rooms" : ["sz1","sz2"]}}' http://$1/MetaService/meta_manager

2. 設置每一個baikalstore的物理機房信息

#IDC1 store的機房信息配置#vim store/conf/gflag-default_physical_room=bj1

3. 設置每一個baikaldb的物理機房信息

#IDC1 db的機房信息配置#vim db/conf/gflag-default_physical_room=bj1

4. 建立表時根據須要指定副本策略與存儲類型

--業務A是一家部署在城市 A的OLAP類型請求採用列存表，建表語句以下：CREATE TABLE `TestDB`.`ctable` (`N_NATIONKEY` INTEGER NOT NULL,`N_NAME` CHAR(25) NOT NULL,`N_REGIONKEY` INTEGER NOT NULL,`N_COMMENT` VARCHAR(152),PRIMARY KEY (`N_NATIONKEY`))ENGINE=Rocksdb_cstore COMMENT='{"comment":"這是一張列存表", "resource_tag":"bizA", "namespace":"TEST_NAMESPACE","dists": [ {"logical_room":"bj", "count":2}, {"logical_room":"sz", "count":1}] }';--業務B是一家部署在城市 B的OLTP類型請求採用行存表，建表語句以下：CREATE TABLE `TestDB`.`rtable` (`N_NATIONKEY` INTEGER NOT NULL,`N_NAME` CHAR(25) NOT NULL,`N_REGIONKEY` INTEGER NOT NULL,`N_COMMENT` VARCHAR(152),PRIMARY KEY (`N_NATIONKEY`))ENGINE=Rocksdb COMMENT='{"comment":"這是一張行存表", "resource_tag":"bizB", "namespace":"TEST_NAMESPACE","dists": [ {"logical_room":"bj", "count":1}, {"logical_room":"sz", "count":2}] }';

優勢：

• 容災能力：任何少數節點故障，不管是機器級，機房級仍是城市級故障，都可作到RPO(數據丟失時長) = 0s，RTO（數據恢復時長）< 30s。

• Async Write：因爲Raft多數Peer寫成功便可返回，雖然3peer會有1個peer分佈在另外一個城市存在延遲，但寫操做通常寫完同城的2個peer便可，異地的peer在進行異步寫，寫性能接近同城寫性能。

• Follower Read：因爲每一個城市至少有一個副本，對於讀業務須要分別部署在兩個城市的場景，BaikalDB提供了就近讀功能，路由選擇時會優先選擇與DB同在一個邏輯機房的Region進行讀操做，因此讀性能能夠在兩地均獲得保證。

• HTAP能力：業務能夠根據業務場景分別選擇行存表與列存表，每一個store能夠同時支持這兩種表。

• 資源隔離：若是擔憂HTAP的業務workload會互相影響，業務能夠經過resource_tag字段對store進行分組，例如store1的resource_tag = bizA， 那麼store1只會給建表時指定resource_tag = bizA的表分配Region。

待完善：

• 容災能力：多數節點故障RPO最大可到3s，BaikalDB副本的分配策略後續能夠增長降級策略，若是多數機房故障，降級到在少數機房分配副本，從而保證RPO依舊爲0。

• Async Write：當寫發生在少數城市時依舊會存在延遲，但這種狀況實際業務不多發生；如確有須要例如兩地業務均需對同一張表發生寫操做，必然有一個處於異地寫狀態，這種狀況建議寫時拆成兩張表，讀時用Union或視圖。

• Follower Read：能夠加強爲Follower一致性讀。就是對Follower可能落後與Leader的請求進行補償，須要分佈式時鐘特性（開發中）的支持。

2、BaikalDB 高性能和擴展性實踐

核心特性

這也是咱們在業務推廣中的關注次序，即

• 首先必須（Must to）業務場景匹配精 準（1一致性）和運行平穩（2高可用）

• 其次最好（Had better）是數據多（3擴展性）與跑的快（4高性能）

• 最後應該是（Should）使用友好（5高兼容性）與 成本節省（6低成本）

簡稱：穩準多快好省。

本文將會經過介紹業務落地前的兩個實際測試案例，來分享總結BaikalDB在性能與擴展性方面的數據。

一、基於行存OLTP場景的基準測試

1.1測試目標

若是把BaikalDB當作一款產品，基準測試的目的就是加上一份產品規格說明書，在性能測試同窗的參與下，咱們進行了爲期2個月的基準測試，並給BaikalDB這款產品的外包裝上寫下以下關於規格的信息：

• 設計的集羣最大規模，在 1000 個節點狀況下，能支持 18 種數據類型，單節點 1T 數據容量，集羣總體1P容量。

• 在基準數據測試下，集羣單點性能達到，write不低於2000 QPS，單次write不超過 50 ms， read性能達到不低於4000 QPS,單次read不超過 20 ms。

• 對外接口基本兼容MySQL 5.6版本協議。

• 基於Multi Raft 協議保障數據副本一致性，少數節點故障不影響正常使用。

• Share-Nothing架構，存儲與計算分離，在線縮擴容對性能影響僅限於內部的數據自動均衡，而對外部透明，新增字段30s生效對集羣無影響。

1.2測試範圍

• 性能測試（行式存儲，大表104字段，小表63字段，集羣總基礎數據1TB，2TB，3TB）

• 與mysql基準對比測試

• 表結構字段個數影響（大表104字段，小表63字段）

• 集羣總基礎數據大小影響（1TB，2TB，3TB）

• 表結構影響（"自增主鍵"，"片鍵作全局索引"，"片鍵作主鍵"）

• 帶壓力的擴展性測試

• 加節點（store）

• 減節點（store）

• 動態加列

1.3測試環境

五臺機器混合部署3 meta, 5 db, 5 store獲取基準，另有一臺機器做爲增減節點機動（centos 7.4 32核 2.4GHZ，128G內存 1.5TSSD硬盤）

測試部署

1.4主要指標說明

• 最佳容量（KTPS）：

• 5臺機器配置的集羣（3 meta, 5 db, 5 store）

• 連續兩分鐘能夠穩定支撐的最大吞吐能力

• 平均讀響應時間小於20ms，平均寫響應時間小於50ms

• 系統最大吞吐能力: 每秒dml操做請求數

• 單位爲KTPS（千次操做請求/秒）

• 定義

• 前置條件：

• 響應時間：dml操做從發送到收到返回結果所通過的時間，單位爲毫秒

• diskIOUtil 磁盤使用率: 一秒中有百分之多少的時間用於 I/O 操做,或者說一秒中有多少時間 I/O 隊列是非空的

• 若是接近 100%，說明產生的I/O請求太多，I/O系統已經滿負荷，該磁盤可能存在瓶頸。

• 大於30%說明I/O壓力就較大了，讀寫會有較多的wait

• 最佳容量斷定方法

繪製系統的性能指標隨着併發用戶數增長而出現降低趨勢的曲線，分析並識別性能區間和拐點並肯定性能閾值。

1.5測試結論

• 性能測試

• 讀：片鍵作主鍵模式，5節點讀容量爲72K+TPS，性能比mysql高85%+，瓶頸爲CPU

• 寫：片鍵作主鍵模式，5節點寫性能爲9.6K+TPS，與mysql至關，爲mysql的85%~120%之間，瓶頸爲DiskIO

• 擴展性測試

• 加節點：前端吞吐平穩

• 減節點：減節點操做須要確保集羣能力有足夠的餘量，能承載被減掉節點轉移的壓力

• 加列：22秒新列生效（1.25億基礎數據）

1.6性能測試詳情

與mysql基準對比測試：

表結構字段個數影響：

集羣總基礎數據大小的影響：

表結構影響：

擴展性測試詳情

不停服增減節點：

不停服增長列：

不停服加列測試過程曲線圖（22秒後全部的帶新列的insert語句所有成功，紅色曲線表明失敗數降爲0）

二、基於列存OLAP場景測試

2.1測試背景

指標監控系統用於實時（定時）監控線上某實時業務數據，生成關於健康狀態的相關指標，若是指標超出閾值，則觸發報警功能。數據表約50列20億行，查詢sql10餘種均爲聚合類查詢，檢索列數不超過4列，查詢條件爲必定時間區間的範圍查詢，以前是跑在一款行存的分佈式數據庫之上，這是一個典型的olap類場景，咱們採用baikaldb的列存模式與線上進行了對比測試，測試對象均爲線上真實數據，兩款DB集羣配置至關，測試查詢性能的同時，均承擔等同的寫負載。

2.2測試結果：

從測試結果能夠看出，在寬表少列與聚合查詢的sql查詢，使用baikaldb的列式存儲，能夠有效減小磁盤IO，提升掃表及計算速度，進而提升查詢性能，這類查詢也是olap場景sql的常見寫法。

三、性能與擴展性總結與思考

3.1性能分析的幾個角度

• 資源瓶頸視角

• 查詢及事務大小建議控制在10M之內，數據量過大會觸發事務及RPC包大小限制；

• 若需全量導出，用 /*{"full_export":true}*/ select * from tb where id > x limit 1000; 語法。

• io.util滿可致使rocksdb的L0層文件壓縮不過來，出現快速的空間放大，進而致使磁盤快速被寫滿。相關參數：max_background_jobs=24

• rocksdb數據文件不建議超過1T，按照默認配置，超過1T後rocksdb將增長1層，寫放大增大10，寫放大會致使io.util出現瓶頸。若服務器磁盤遠大於1T，建議單機多實例部署。

• io.util滿可致使內存刷盤不及時進而引發內存滿（store）；

• 慢查詢過多時，會致使查詢積壓於store，進而引發內存滿（store）；相關參數db：slow_query_timeout_s=60s ；

• store內存建議配置爲所在實例的40%以上，由於內存直接影響cache命中率，cache miss過多的話，會增大io.util及sql用時；相關參數：cache_size=64M

• export TCMALLOC_MAX_TOTAL_THREAD_CACHE_BYTES=209715200 #200M，當大value時，調大能夠避免線程競爭，提升性能 。

• CPU : 多發生在讀qps過大時（db，store），可監控vars/bthread_count指標

• IO：多發生在寫qps過大時（store），可監控io.util指標，及store/rocksdb/LOG日誌。

• Mem：

• Disk：

• NetWork：

3.1.1用戶視角

• 聯合主鍵 vs 自增主鍵

• BaikalDB是按主鍵進行分片的，主鍵的選擇影響了數據的物理分佈，好的作法是把查詢條件落在儘可能少的分片上，查詢時基於前綴匹配，通常建議按範圍從左到右創建聯合主鍵，例如：class表主鍵可設置爲schoolid，collegeid，classid # 學校，學院，班級;

• BaikalDB實現自增主鍵主要是爲了與MySQL兼容，因爲全局自增是經過meta單raft group完成，會存在rpc開銷及擴展性問題；另外全局自增主鍵也容易致使數據批量插入時請求集中於最後一個Region節點，容易出現瓶頸。

• 全局索引 vs 局部索引

• 全局索引與主表不在一塊兒，有本身的分片規則，好處是有路由發現功能，壞處是多了與全局索引的RPC開銷，局部索引與主表一塊兒，須要經過主鍵肯定分片，不然須要廣播，好處是RPC開銷。

• 小表建議用局部索引；

• 大表（1億以上），查詢條件帶主鍵前綴，用局部索引，不然用全局索引。

• 行存 vs 列存

• 寬表少列（查詢列/總列數 小於 20%）， 聚合查詢的olap請求用列存

• 其餘狀況用行存

3.1.2實現視角

• Balance：BaikalDB會週期性的進行Leader均衡與Peer均衡，負載均衡過程當中若數據遷移量較大，多是影響性能，通常發生在：

• 增刪節點時

• 批量導入數據時

• 機器故障時

• SQL Optimizer：目前主要基於RBO，實現了部分CBO，若性能與執行計劃有關，可使用explain，及 index hint功能調優。

3.1.3****擴展性考慮因素

• 穩定性

• meta，尤爲是主meta掛了狀況下，將不能提供ddl， 主auto incr 掛了狀況下，將不能提供自增主鍵表的insert功能。

• store讀正常，但瞬間一半store leader掛了狀況下，寫功能須要等到全部leader遷移至健康中心爲止。

• 擴容：從實測狀況看，擴容狀況下比較平穩

• 縮容：縮容較少發生，但在雙中心單中心故障的狀況下，至關於縮容一半，此時穩定性仍是值得注意與優化的，主要包括：

• 極限容量：

• 計算邏輯以下

• 理論上Meta 20G， Store 1T磁盤狀況下，預計可管理 10k個store節點， 10P大小數據。

• 實際上百度最大的集羣管理了1000個store節點，每store 1T磁盤， 共計約1P的集羣總空間。

1. Region元數據=0.2k， Meta20G內存共計可管理的 Region總數 = 20G/0.2k = 100M

2. Region數據量 = 100M，Store 1T磁盤共可管理的 Region個數每store = 1T/100M = 10k

3. 共計能夠管理的數據量 = Region總數 * Region數據量 = 100M * 100M = 10P

4. 共計能夠管理的store個數 = Region總數 / Region個數每store = 100M/10k = 10k

• 線性

• 固定範圍：O（1）

• 能夠下推store全量：O(n/db併發度)

• 不可下推store全量：O（n）

• JOIN查詢：O（n^2）

四、後記

• 本文的性能與擴展性分析數據均來源於實際項目，而非TPCC，TPCH標準化測試，但測試項目具備必定的表明性。

• BaikalDB測試數據基於V1.0.1版，最新發布的V1.1.2版又有了較多優化：

• 優化seek性能，實測range scan速度提升1倍；

• rocksdb升級6.8.1，使用Partitioned Index Filters，進一步提升了內存使用效率；

• 增長利用統計信息計算代價選擇索引功能（部分）；

• 事務多語句Raft複製拆分執行，提升了Follower的併發度。

3、BaikalDB 低成本思考

這也是咱們在業務推廣中的關注次序，即

一、首先必須（Must to）業務場景匹配精 準（1一致性）和運行平穩（2高可用）；

二、其次最好（had better）是數據多（3擴展性）與跑的快（4高性能）；

三、最後應該是（should）使用友好（5高兼容性）與 成本節省（6低成本）。

簡稱：穩準多快好省。

做爲系列文章的最後一篇，是關於成本的思考，若是說強一致與高可用是用戶關心的在功能上是否知足需求，擴展性與高性能是老闆關心的在規格上是否值得投入，那麼兼容性與成本則是項目實施者應該關心的問題，由於它關係到項目推動難度。

若是你承認NewSQL的發展趨勢，也發現了公司的實際業務場景需求，本文將會討論在項目實施中須要克服的問題，並建議用成本的角度進行評估，這樣有助於對項目的工做量進行計算。例如若是調研發現公司的潛在目標用戶均跑在mysql數據庫上，那麼是否兼容mysql協議直接決定了用戶的意願，用戶的學習成本，業務代碼的改形成本，生態的配套成本，若是潛在用戶超過10個以上則成本將會放大10倍；若是大部分潛在業務使用的是PostgreSQL，那麼最好在選型時選擇兼容pg的NewSQL。這也是本文將兼容性歸類到低成本一併討論的緣由。

一、成本的分類

**狹義的成本：指數據庫軟件的開發，受權，運維及硬件成本，特色是可量化，**例如：一、開發投入：24人月

二、License受權：10萬/年

三、運維投入：DBA 2人

四、硬件成本：服務器10臺

**廣義的成本：泛指在組織實施數據庫應用工程實踐過程當中，所產生費用總和，**特色是與項目管理與實施有關，包括：

一、學習開發成本

二、測試驗證成本

三、業務遷移成本

四、用戶習慣

五、運維配套工具

六、軟件成熟度

七、技術前瞻性

狹義的成本能夠理解爲這件事值不值得作，廣義的成本能夠理解爲把事情作成須要作的工做，截止到本文發表爲止，BaikalDB已在公司10餘家業務上進行了落地應用，這些應用實際產生的成本與收益如何評估（狹義）？項目落地過程當中須要落實哪些工做(廣義）？下面將就這兩個問題展開討論。

二、狹義的成本理論上可減低100倍

因爲BaikalDB是開源的，開發成本能夠忽略，部署簡單，其狹義成本主要集中在硬件成本上。結合公司的雙中心建設與Kubernetes雲原平生臺戰略，咱們給出了BaikalDB兩地四中心三副本行列混存的方案，理論上有望使硬件成本下降100倍，方案以下圖：

一、注1：圖中省去了meta節點部署

二、注2：每一個IDC會實際部署了多個store與db節點。

三、注3：行列混存的特性還在開發中

上圖採用了徹底對稱的雙中心部署方案，每一個數據中心又存在2個對等IDC機房，基於BaikalDB的邏輯機房與物理機房概念，能夠完成以上部署，並提供城市級別的容災能力，經過Raft Group層面的行列混存技術實現僅需3副本便可提供HTAP的能力，配置細節已經在第一篇文章HTAP部署有所描述，本文在以前基礎上增長了行列混存（功能還沒有實現）的方式，進一步合併了應用場景，減小副本個數，從而達到節約成本的目的。以上方案具體成本節約主要體如今三個方面：

2.1 HTAP帶來的成本下降爲5倍

爲了知足不一樣的應用場景，經過同步工具，數據會被分發到ETL，ES，HBASE，kafka，TiDB等不一樣數據組件中去，核心業務的存儲資源存在5倍以上的放大。依據數據庫使用現狀狀況，核心業務通常1套OLTP主庫+數據同步平臺+5套OLAP數據庫，採用此方案後能同時知足以上所有場景，而且省去了異構數據源之間數據同步延遲問題，由於異構數據源超過了5個，合併爲1個後，預計收益增大5倍。

2.2 單位資源效能帶來的成本減低爲4倍

• 行存OLTP類場景性能提高85%

BaikalDB存儲層使用RocksDB的LSM-Tree存儲，相較於innodb的B+樹，經過平衡讀，寫，空間放大使得讀寫性能更加均衡，經過out-of-place update及必定的空間放大來優化寫性能（對比innodb至關於犧牲全局有序性及存儲空間換取寫性能），能充分發揮SSD硬盤的隨機讀優點及利用高效緩存來加速點查詢，對於範圍查則主要經過data reorganization（merge/compaction）及SSD的併發讀來優化速度。參考第二篇性能測試文章的基準性能測試結果，適用於OLTP場景的行存BaikalDB綜合性能可提高85%。

• 列存OLAP類場景性能提高10倍

OLAP類場景下的SQL查詢語句通常是寬表少列，以聚合函數爲主，數據比較適合按列存放在一塊兒，一個例子以下：

cstore vs rstore

Demo

#統計每一個廣告平臺的記錄數量SELECT CounterID, count() FROM hits GROUP BY CounterID ORDER BY count() DESC LIMIT 20;

行式

列式

使用BaikalDB的列存引擎，使咱們第一家接入OLAP業務（約100億數據量的聚合查詢）查詢速度提高10倍。

業務通常會有1個OLTP場景加n個OLAP場景組成，平均來看BaikalDB可使單位資源效能提高4倍左右。

2.3 雲原生彈性能力帶來的成本減低爲5倍

以mysql爲例，因爲縮擴容升降配困難，爲了應對少數發生的業務高峯時段（例如雙11一年只有一次）而不得不一直留夠Buffer，致使硬件資源的投入不能隨着流量的變化而動態變化，彈性不足，資源利用率廣泛較低約8%的水平。公司也意識到相關問題，在積極構建基於kubernetes雲原平生臺（見下圖），具體文章參見同程藝龍雲原生 K8s 落地實踐[4] 。

BaikalDB的share –nothing雲原生特性能完美的k8s的調度能力進行結合，預計能夠把資源利用率提高到40%，所以彈性收益爲5倍。之因此沒有提高到80%以上是爲了知足雙中心容災互備的須要，以應對城市級故障帶來的單中心雙倍壓力。

綜上所述，總收益  =  HTAP收益  * 單位資源能效收益 * 資源利用率收益 =  5 * 4 * 5 = 100倍

三、實際上廣義的成本難以量化但不能有短板

在狹義成本評估值得作的狀況下，須要從項目管理或項目實施的角度思考如何把項目順利推動，因爲每家公司每一個項目的實際狀況均不同，項目的評估很難統一量化，但咱們在進行項目實施時必需要慎重考慮這些因素，而且任何一個環節不達標都可能致使項目的失敗，在這裏把項目推動中要完成的工做量稱爲廣義的成本，以咱們實踐經驗進行總結評分，滿分爲10分，分值越高越好，評價不一樣於以往的性能測試，具備很強的主觀性，僅供參考。

3.1 學習開發成本：9分

BaikalDB的學習主要包括依賴與BaikalDB代碼自己。

BaikalDB的依賴少而精，主要有三個：

一、brpc：Apache項目，百度內最常使用的工業級RPC框架；

二、braft：百度開源的Raft一致性與複製狀態機工業級實現庫；

三、RocksDB：kv存儲引擎，集成了Google與Facebook雙方大牛的力做；

以上三款開源項目，社區都比較成熟，每一款都值得好好學習。

BaikalDB自己做爲一款純開源的分佈式數據庫，代碼10萬行，以C++語言爲主，代碼架構簡潔，組織清晰。雖然目前文檔不是不少還在完善中，但項目保持了良好編碼風格，代碼可讀性強，大部分實現原理能夠經過直接閱讀代碼掌握，少部分須要結合數據庫及分佈式領域的理論知識與論文學習。在模塊化抽象與分層上保持清晰保持簡潔，在一些核心對象例如邏輯計劃：LogicalPlanner，表達式：ExprNode，執行算子：ExecNode 僅有一層繼承關係，具備薄膠合層顯著特色，有效的減低了軟件的學習成本，體現了Unix開源文化的KISS原則（Keep It Simple， Stupid！）

總之，BaikalDB是一款很是值得學習的DB，給9分。

3.2 測試驗證成本：7分

BaikalDB的測試驗證工做量與其它DB差很少，中規中矩給7分。

3.3 業務遷移成本：8分

業務的遷移成本主要包括數據遷移與SQL改寫兩個部分，因爲BaikalDB兼容MySQL協議，公司已研發了基於MySQL生態的數據同步平臺，數據遷移成本不大。使用MySQL開發的業務代碼，大部分狀況不須要改寫SQL，改寫主要發生在BaikalDB還沒有支持的MySQL語法例如（子查詢，一些系統函數上）和慢查詢改寫上面，業務遷移成本給8分。

3.4 用戶習慣：7分

一、圖像化工具：能使用Navicat， IDEA自帶MySQL UI， DataGrip進行簡單的表瀏覽，SQL執行功能，不能進行復雜管理操做；

二、公司已有系統對接（例如工單，權限，一站式查詢等）：還沒有打通；

三、對新概念的接受過程（例如新的數據文件，部署方式，資源隔離，多租戶等）。

3.5 運維配套工具：7分

• 備份工具：

熱備：基於SST的備份恢復

冷備：經過SQL語句邏輯備份。

/{"full_export":true}/ select * from tb where id > x limit 1000;

• 監控工具：Prometheus

• 運維腳本：script[5]

• 部署工具：Ansible

• 壓測工具：sysbench

• 訂閱工具：Binlog功能開發中

• 同步工具：Canal

3.6 軟件成熟度：7分

3.7 技術前瞻性：9分

BaikalDB提供的PB級分佈式擴展能力，動態變動Schema能力，分佈式事務，異地多活，資源隔離，雲原生K8s，HTAP能力均與公司將來的需求或規劃匹配，所以給9分。

四、後記

至此BaikalDB在同程藝龍的應用實踐系列文章就結束了，BaikalDB做爲一款開源兩歲的NewSQL數據庫還很是年輕，存在很大完善空間。同時做爲後浪也借鑑不少前浪的設計思想，有必定的後發優點。BaikalDB實現簡潔，功能強大，社區專業友好，不管是用來代碼學習仍是業務應用均有很大成長空間，歡迎感興趣的朋友一塊兒參與。因爲筆者水平有限，文中若有不妥之處，還望理解指正。

招聘信息：

百度商業平臺研發部主要負責百度商業產品的平臺建設，包括廣告投放、落地頁託管、全域數據洞察等核心業務方向，致力於用平臺化的技術服務讓客戶及生態夥伴持續成長，成爲客戶最爲依賴的商業服務平臺。

不管你是後端，前端，仍是算法，這裏有若干職位在等你，歡迎投遞簡歷， 百度商業平臺研發部期待你的加入！

簡歷投遞郵箱：geektalk@baidu.com （投遞備註【百度商業】）

推薦閱讀：

｜面向大規模商業系統的數據庫設計和實踐

｜百度愛番番移動端網頁秒開實踐

｜解密百TB數據分析如何跑進45秒

---------- END ----------

百度Geek說

百度官方技術公衆號上線啦！

技術乾貨 · 行業資訊 · 線上沙龍 · 行業大會

招聘信息 · 內推信息 · 技術書籍 · 百度周邊

歡迎各位同窗關注