時序數(shù)據(jù)庫GeminiDB Influx接口介紹
什么是云數(shù)據(jù)庫GeminiDB Influx接口
GeminiDB Influx接口是一款基于計算存儲分離架構(gòu)，兼容InfluxDB生態(tài)的云原生NoSQL時序數(shù)據(jù)庫。在云計算平臺高性能、高可用、高可靠、高安全、可彈性伸縮的基礎(chǔ)上，提供了一鍵部署、快速備份恢復(fù)、計算存儲獨立擴容、監(jiān)控告警等服務(wù)能力。廣泛應(yīng)用于資源監(jiān)控，業(yè)務(wù)監(jiān)控分析，物聯(lián)網(wǎng)設(shè)備實時監(jiān)控，工業(yè)生產(chǎn)監(jiān)控，生產(chǎn)質(zhì)量評估和故障回溯等。提供大并發(fā)的時序數(shù)據(jù)讀寫，壓縮存儲和類SQL查詢，并且支持多維聚合計算和數(shù)據(jù)可視化分析能力。
相比InfluxDB等開源時序數(shù)據(jù)庫，采用存儲與計算分離的云原生數(shù)據(jù)庫設(shè)計具備以下優(yōu)勢：
容忍N-1節(jié)點故障，更高可用。
存儲與計算分離，可以復(fù)用成熟的分布式存儲系統(tǒng)，提供系統(tǒng)的極致可靠性。時序數(shù)據(jù)通常會持續(xù)高性能寫入，同時還有大量的查詢業(yè)務(wù)，任何系統(tǒng)故障導(dǎo)致業(yè)務(wù)中斷甚至數(shù)據(jù)丟失都會造成嚴(yán)重的業(yè)務(wù)影響，而利用經(jīng)過驗證的成熟的分布式存儲系統(tǒng)，能夠顯著的提升系統(tǒng)可靠性，降低數(shù)據(jù)丟失風(fēng)險。
分鐘級計算節(jié)點擴容，秒級存儲擴容。
解除在傳統(tǒng)Shared Nothing架構(gòu)下，數(shù)據(jù)和節(jié)點物理綁定的約束，數(shù)據(jù)只是邏輯上歸宿于某個節(jié)點，使的計算節(jié)點無狀態(tài)化。這樣在擴容計算節(jié)點時，可以避免在計算節(jié)點間遷移大量數(shù)據(jù)，只需要邏輯上將部分數(shù)據(jù)從一個節(jié)點移交給另一個節(jié)點即可，可以將集群擴容的耗時從以天為單位縮短為分鐘級別。
消除多副本冗余，降低存儲成本。
通過將多副本復(fù)制從計算節(jié)點卸載到分布式存儲節(jié)點，可以避免用戶以Cloud Hosting形態(tài)在云上自建數(shù)據(jù)庫時，分布式數(shù)據(jù)庫和分布式存儲分別做3副本復(fù)制導(dǎo)致總共9副本的冗余問題，能夠顯著降低存儲成本。
云數(shù)據(jù)庫GeminiDB Influx接口5大特性
采用云原生存儲與計算分離架構(gòu)，具有支持億級時間線、極致寫入性能、低存儲成本、高性能多維聚合查詢和極致彈性擴縮容等5大特性。
在時序數(shù)據(jù)庫系統(tǒng)中，存在大量并發(fā)查詢和寫入操作，合理控制內(nèi)存的使用量顯得十分重要。
開源時序數(shù)據(jù)庫VictoriaMetrics、InfluxDB在寫入數(shù)據(jù)的時間線增加到千萬級別時，進程會因內(nèi)存耗盡而OOM退出。為了避免寫入海量時間線數(shù)據(jù)導(dǎo)致內(nèi)存資源被耗盡，GeminiDB Influx接口做了如下優(yōu)化：
1、在內(nèi)存分配上，大量使用內(nèi)存池復(fù)用技術(shù)，減少臨時對象內(nèi)存申請，降低內(nèi)存碎片。
2、在內(nèi)存回收上，實現(xiàn)算法根據(jù)內(nèi)存負載，動態(tài)調(diào)整GC頻率，加快內(nèi)存空間回收。
3、在單查詢上，實行Quota控制，避免單查詢耗盡內(nèi)存。
4、在緩存使用上，針對不同節(jié)點規(guī)格提供不同的最優(yōu)配置。
經(jīng)過改進，在海量時間線下，系統(tǒng)寫入性能保持穩(wěn)定，大幅超出InfluxDB開源實現(xiàn)。對于涉及海量時間線的聚合查詢，如高散列聚合查詢，查詢性能提升更為顯著。
相比單機模式，集群模式可以將寫入負載分散到集群中各個計算節(jié)點上，從而支持更大規(guī)模的數(shù)據(jù)寫入。GeminiDB Influx接口支持每天萬億條數(shù)據(jù)寫入，在工程實現(xiàn)上進行了以下優(yōu)化：
1、時序數(shù)據(jù)按照時間線做Hash Partition，利用所有節(jié)點并行寫入，充分發(fā)揮集群優(yōu)勢。
2、Shard節(jié)點采用針對寫場景優(yōu)化的LSM-Tree布局，寫WAL后確保日志持久化，再寫入內(nèi)存Buffer即可返回。
3、數(shù)據(jù)庫多副本復(fù)制卸載到分布式存儲，降低計算節(jié)點到存儲節(jié)點的網(wǎng)絡(luò)流量。
4、在大規(guī)模寫入場景下，GeminiDB Influx接口的寫入性能線性擴展度大于80%。
GeminiDB Influx接口 對數(shù)據(jù)采用列式存儲，相同類型的數(shù)據(jù)被集中存儲，更有利于數(shù)據(jù)壓縮。采用自研的時序數(shù)據(jù)自適應(yīng)壓縮算法，在壓縮前對數(shù)據(jù)進行抽樣分析，根據(jù)數(shù)據(jù)量、數(shù)據(jù)分布以及數(shù)據(jù)類型選擇最合適的數(shù)據(jù)壓縮算法。在壓縮算法上，相比原生的InfluxDB，重點針對Float、String、Timestamp這三種數(shù)據(jù)類型進行了優(yōu)化和改進。
Float數(shù)據(jù)類型： 對Gorilla壓縮算法進行了優(yōu)化，將可以無損轉(zhuǎn)換的數(shù)值轉(zhuǎn)為整數(shù)，再根據(jù)數(shù)據(jù)特點，選擇最合適的數(shù)據(jù)壓縮算法。
String數(shù)據(jù)類型：采用了壓縮效率更好的ZSTD壓縮算法，并根據(jù)待壓縮數(shù)據(jù)的Length使用不同Level的編碼方法。
Timestamp數(shù)據(jù)類型：采用差量壓縮方法，最后還針對數(shù)據(jù)文件內(nèi)的Timestamp進行相似性壓縮，進一步降低時序數(shù)據(jù)存儲成本。
在提升聚合查詢整體性能方面，GeminiDB Influx接口做了如下優(yōu)化：
采用MPP架構(gòu)：一條查詢語句可以在多節(jié)點及多核并發(fā)執(zhí)行。
向量化查詢引擎：在查詢結(jié)果數(shù)據(jù)量很大時，傳統(tǒng)的火山模型每次迭代返回一條數(shù)據(jù)，存在過多的開銷導(dǎo)致性能瓶頸。GaussDB（for Influx）內(nèi)部實現(xiàn)了向量化查詢引擎，每次迭代批量返回數(shù)據(jù)，大大減少了額外開銷。
增量聚合引擎：基于滑動窗口的聚合查詢，大部分從聚合結(jié)果緩存中直接命中，僅需要聚合增量數(shù)據(jù)部分即可。
多維倒排索引：支持多維多條件組合查詢，避免大量Scan數(shù)據(jù)。
存儲摘要索引：加快數(shù)據(jù)查詢中過濾無關(guān)數(shù)據(jù)。
在時序數(shù)據(jù)庫的運行過程中，隨著業(yè)務(wù)量的增加，常常需要對數(shù)據(jù)庫進行在線擴容，以滿足業(yè)務(wù)的要求。傳統(tǒng)數(shù)據(jù)庫中的數(shù)據(jù)存儲在本地，擴容后往往需要遷移數(shù)據(jù)。當(dāng)數(shù)據(jù)量達到一定規(guī)模時，數(shù)據(jù)遷移所耗費的時間往往按天計算，給運維帶來了很大的困難。
如圖所示，每個Database邏輯上由多個Partition組成，每個Partition獨立存儲，且都可自描述。所有Partition數(shù)據(jù)都存儲在分布式共享存儲上，數(shù)據(jù)庫Shard節(jié)點和數(shù)據(jù)沒有物理綁定關(guān)系。擴容時首先offload源節(jié)點Partition，再在目標(biāo)節(jié)點assign即可。