openGemini v1.2.0版本正式釋出，IoT 場景效能大幅提升！

华为云开发者联盟發表於2024-05-15

本文分享自華為雲社群《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"