本文分享自華爲雲社區《openGemini v1.2.0版本正式發佈，IoT 場景性能大幅提升！》，作者：華爲雲開源。
在openGemini v1.2.0版本中，我們爲您帶來了一系列令人振奮的內核優化，將您的體驗提升到新的高度，這包括
- 針對IoT場景的性能優化，查詢效率有極大的提升。
- 針對數據存儲的優化，進一步節約磁盤空間，降低數據存儲成本。
- 針對部分功能的優化，比如
show tag keys,stream等，使得功能更加豐富。 - 新增了一部分內核的監控指標，進一步清楚瞭解內核的運行狀態、行爲和性能，幫助分析、定位和優化數據庫性能。
此外，我們還進行了一系列的讀寫流程上的改進和修復，以提供更穩定和可靠的體驗。
內核優化
IoT典型場景性能優化
本次版本針對IoT場景的寫入和典型查詢場景進行了優化，通過TSBS工具的測試結果可以看出，openGemini全面超越InfluxDB，最高提升了50倍。相比其他時序數據庫，openGemini也是具有領先優勢。
具體性能數據參考:
https://docs.opengemini.org/zh/guide/introduction/performance.html
schema數據壓縮
type Record struct {
*RecMeta
ColVals []ColVal
Schema Schemas
}
type Schemas []Field
type Field struct {
Type int
Name string
}
openGemini將行數據協議轉化爲Record結構進行存儲，Schema保存每一列FIELD的數據類型和名稱，並會隨着數據一起保存在磁盤上，當表的FIELD數量很多，比如1000列或者更多時，加之時間線數量很大的情況下，這裏的Schema數據會變得很大，在tssp文件中的佔比可能超過80%。
可以通過配置文件開啓schema數據壓縮（默認關閉），但需要注意的是，該功能會對查詢性能有一定的影響，因爲查詢過程中要對schema進行數據解壓
[data] ## Compressing ChunkMeta in TSSP Files. 0: not compressed(default); 1: use snappy # chunk-meta-compress-mode = 0
優化效果：500萬時間線 1000+列模型下，開啓壓縮功能後（Snappy算法），寫性能提升 2.5+倍，平均刷盤時延減少68%，level 0 文件大小減少 70%
最佳實踐：針對列比較多的情況，儘可能用短字符串給FIELD命名。再考慮開啓schema數據壓縮。
該優化優先級高於 "tssp 臨時文件磁盤佔用優化"，開啓該優化後，臨時文件的優化將自動失效
優化僅一行數據情況下的數據編碼
在一些業務中，時間線很多，但是每次寫入時，同一時間線僅一條數據，這使得在 level 0 的文件中，一條時間線僅一條數據，本身沒有辦法進行壓縮，還需要存儲很多額外的信息，佔用了大量的磁盤空間。 本次優化是專門針對上述場景，減少level 0文件大小，達到提升compaction、Merge和部分查詢的性能的目的。
優化效果：250萬時間線，優化前文件大小 987MB， 優化後 733MB，存儲空間減少 25%。
優化全空值或沒有空值列的存儲
在openGemini中，數據的壓縮存儲是以segment爲粒度（1000行），可能存在 segment爲全空值（ColVal.Len == ColVal.NilCount）或沒有空值（ColVal.NilCount == 0），此時可以不存儲bitmap相關數據，減少磁盤佔用。
優化效果：3萬時間線，2400萬行數據，沒有空值的情況下，優化後存儲空間減少20%
tssp 臨時文件磁盤佔用優化
數據寫入openGemini後，在數據刷盤過程中，文件元數據會先保存到一個臨時文件，在所有數據刷盤完成後，將臨時文件追加到數據文件中，然後刪除該臨時文件，當寫入數據量非常大時，臨時文件數據也會頻繁刷盤，佔一部分磁盤I/O，本次優化是對臨時文件進行一個壓縮處理，減少磁盤I/O。該優化對刷盤，compaction，merge 等操作有效。
可通過修改配置項 data.temporary-index-compress-mode 來開啓，該優化方法是用CPU開銷（解壓）換取磁盤I/O，在選擇壓縮算法時需要考慮實際情況。
SHOW TAG KEYS支持條件過濾
用法如下：
> select * from cpu name: cpu time cpu host mem ---- --- ---- --- 1710209706991211420 0.8 192.168.0.1 0.3 1710209718880801483 0.65 192.168.0.2 0.42 1710209735839331535 0.77 192.168.0.3 0.46 > show tag keys from cpu where host="192.168.0.1" name: cpu tagKey ------ host
流式聚合（stream）用法和性能優化
在用法上，之前使用該功能時，必須是tags & time 一起分組，當前版本支持僅按time分組。例如
# 之前版本用法 > CREATE STREAM ... ON SELECT ... FROM ... GROUP BY time(1m),"cpu","host" delay 20s # 現在可以僅使用time分組 > CREATE STREAM ... ON SELECT ... FROM ... GROUP BY time(1m) delay 20s
在性能上，聚合效率較之前版本有數倍提升。
新增監控項
IOReadMetaCounts、IOReadMetaSize、IOReadDataCounts、IOReadDataSize，分別表示從數據文件中讀取元數據的次數和大小和讀取數據的次數和大小。
有了這些基本數據，通過簡單的處理就可以知道在某段時間內查詢的數據量大小，以此作爲性能優化或根因分析的依據。比如在定位查詢問題時，如果查詢時延比較大，此時可以觀察該指標，瞭解openGemini存儲引擎從文件讀取數據的情況，以此判斷是否由於計算數據量太多導致，從而優化查詢語句。
新增監控項
IOFrontIndexReadOkCount，IOFrontIndexReadOkBytes，IOFrontIndexReadDuration ，在openGemini中，磁盤I/O包括業務數據讀寫I/O, 索引讀寫I/O，Compaction讀寫I/O，亂序合併讀寫I/O等，這裏新增的3個監控項均爲索引讀寫I/O的指標，分別是索引數據讀取次數/字節數/時延。
當性能瓶頸發生在磁盤I/O時，通過調取相應細分I/O數據，確定何種類型的I/O流量佔比較大，可以進行鍼對性優化。
新增監控項
以下爲本次優化新增的關於ts-store上查詢請求執行相關的監控項，用於洞察ts-store上的查詢執行情況
# ts-store處理的查詢請求數 storeQueryReq # ts-store的查詢時延 storeQueryReqDurationNs # 當前ts-store上正在執行的查詢請求數 storeQueryReqActive # ts-store上反序列化查詢請求的時延 UnmarshalQueryTimeTotal # ts-store上查詢請求獲取shard資源的時延。 # 這裏有流控，ts-store執行查詢請求的併發數是一定的，如果查詢併發比較大，就會出現排隊情況，這裏的時延就會比較大。 GetShardResourceTimeTotal # 以下兩項分別是ts-store上TAG構建掃描索引計劃的時延和掃描數據的時延 IndexScanDagBuildTimeTotal IndexScanDagRunTimeTotal # ts-store上查詢請求查找索引的時延 IndexScanRunTimeTotal # ts-store上查詢請求涉及的shard個數 QueryShardNumTotal # ts-store上查詢請求掃描的時間線數量 IndexScanSeriesNumTotal # 以下兩項是查詢請求讀取數據的監控項 ChunkReaderDagBuildTimeTotal ChunkReaderDagRunTimeTotal
調整配置項read-page-size，默認32KB，最大可配64KB，對提升查詢性能有幫助，但會增大磁盤I/O帶寬，二者需要平衡。
[data] # read-page-size set pageSize of read from file of datablock, default is "32kb", valid setting is "1kb"/"4kb"/"8kb"/"16kb"/"32kb"/"64kb"/"variable" # read-page-size = "32kb"
Bug修復
- 修復了一些異常場景下節點Panic的問題
- 修復了批量刪除表時，ts-store出現刪除表失敗的問題
- 修復了一些內核中鎖的問題
- 修復了一些內核處理空值的問題
- 修復了一些內存泄露的問題
安全
- 修復漏洞：CVE-2022-41723，通過升級golang.org/x/net的版本到v0.7.0
- 修復漏洞：CVE-2023-39325，通過升級golang.org/x/net的版本到v0.17.0
- 修復漏洞：CVE-2023-47248，通過升級pyarrow的版本到v14.0.1
結束
openGemini 是一款開源時序數據庫，它的 v1.2.0版本已經正式發佈，在這個版本中，內核得到優化，新增幾項監控項，修復了若干Bug和漏洞，無論是性能還是使用體驗都得到了有效提升。歡迎大家試用openGemini，提出您寶貴的優化意見。
如何參與社區貢獻，參考：
- https://docs.opengemini.org/zh/dev-guide/get_started/
- https://docs.opengemini.org/zh/guide/contribution/Document.html
openGemini官網：http://www.openGemini.org
Star for me😊：https://github.com/openGemini