分布式列存數(shù)據(jù)庫技術(shù)的應(yīng)用

1、技術(shù)創(chuàng)新，變革未來分布式列存數(shù)據(jù)庫在同程藝龍的應(yīng)用目錄列存數(shù)據(jù)庫選型架構(gòu)及核心特性列存的技術(shù)實現(xiàn)公司的業(yè)務(wù)應(yīng)用業(yè)界紛紛布局NewSQL核心技術(shù)對比技術(shù)選型純自研：能力有限，投入有限純開源：無法及時滿足定制化需求云服務(wù)：安全與成本考慮，短期內(nèi)核心業(yè)務(wù)自建IDC，k8s 化半自研：我們的選擇，不重復(fù)造輪子，主體功能交由社區(qū) 完成，集中有限力量滿足公司需求，可供選擇的NewSQL 有： TiDB，BaikalDB，CockRoachDB等。背景相似：BaikalDB來源 于百度鳳巢廣告業(yè)務(wù)團隊， 由于廣告業(yè)務(wù)的增長走過 了從單機到分庫分表到分 布式的全過程，而我們面 臨類似的問題。經(jīng)受考驗：已經(jīng)有百

2、度廣 告平臺多個業(yè)務(wù)實際使用 經(jīng)驗，千級別集群節(jié)點， PB級數(shù)據(jù)規(guī)模，我們跟進 使用，風(fēng)險可控。技術(shù)棧匹配：BaikalDB（c+實現(xiàn)， 10萬行代碼 精煉），依賴少而精（brpc，braft，rocksdb），社區(qū)友好， 部署簡單，技術(shù)棧匹配。特性比較完善：基本滿足 我們需求，我們可以專注 于滿足公司需求?；A(chǔ)架構(gòu)核心特性存儲模型列式存儲減少IO：寬表少列情況下只讀需要列，更新部分字段時 只寫涉及列利于壓縮：列針對性壓縮同構(gòu)的列值連續(xù)擺放在一起， 字節(jié)上重復(fù)的部分很多，因而信息熵很低，可以充分利 用壓縮利于緩存：I/O的降低，提高緩存效率向量化查詢：以塊的形式處理數(shù)據(jù)延遲物化：只解析與SQL

3、有相關(guān)性的列并過濾，減少非 必須列的掃描行 式 存 儲列 式 存 儲設(shè)計實現(xiàn)/baidu/BaikalDB/pull/52相關(guān)優(yōu)化減少I/O（讀，寫，過濾）ZSTD壓縮（更適合列存）并行化（分區(qū)，小Region）向量化處理（TableScan）Rocksdb讀優(yōu)化 write_buffer_number level0_file_num partitioned_index_filters遷移與測試上線效果實時獲取線上業(yè)務(wù)運行數(shù)據(jù)生成關(guān)于健康狀態(tài)的相關(guān)指標(biāo)，如果指標(biāo)超 出閾值，則觸發(fā)報警功能。數(shù)據(jù)表約50列20億行查詢sql均為聚合類查詢，檢索列數(shù)不超過4 列，查詢條件為一定時間區(qū)間的范圍查詢Sql示例：SELECT project_code, count(*) as count FROM trajectoryWHERE created_on 2020-01-11ANDcreated_on