(本文作者：觀測云資深系統(tǒng)開發(fā)工程師 熊豹)
2023 年 4 月 23 日，觀測云正式發(fā)布自研時序數(shù)據(jù)庫 GuanceDB，并在當天應用到了觀測云所有 SaaS 節(jié)點的底座。此次升級性能提升的效果立竿見影，對比之前使用 InfluxDB 的環(huán)境資源占用大幅降低、查詢性能顯著提升，我們成功地吃上了自己的狗糧。
我們也深知 talk is cheap show me the benchmark 的道理，這里發(fā)布我們在近期完成的 GuanceDB 性能壓測報告。
壓測方案說明
本次測試的目標是對比 GuanceDB、InfluxDB 和某知名開源時序數(shù)據(jù)庫(簡稱 xxDB)在相同的寫入負載和查詢條件下的性能表現(xiàn)及資源占用情況。
關于測試工具：
我們對比 tsbs、prometheus-benchmark 兩種時序數(shù)據(jù)庫的壓測方案。
其中 prometheus-benchmark 構造了更偏真實環(huán)境的持續(xù)寫入負載，指標數(shù)值的變化也更真實，所以我們主要參考 prometheus-benchmark 來構造本次測試。
原 prometheus-benchmark 方案中使用了 vmagent 來抓取和寫入指標，但我們今天測試的 3 種數(shù)據(jù)庫對 Prometheus 寫入?yún)f(xié)議支持力度不一，沒法一起比較。所以我們對 vmagent 進行了一些改造，讓其支持了 InfluxDB 的行寫入?yún)f(xié)議。
本次測試的最終方案如下：
1.部署的一個單機的 node-exporter ，其暴露宿主機的 1383 個真實指標
2.部署 Nginx 反代并緩存 node-exporter 結果 1s，降低頻繁請求的壓力
3.調整 agent 的抓取配置，模擬生成不同的 node-exporter 實例數(shù)以生成不同的寫入負載
4.agent 以相同的請求大小、頻率將數(shù)據(jù)同時以 influx 協(xié)議 http 接口寫入三種時序數(shù)據(jù)庫
軟件版本：
1.GuanceDB: v1.0.0
2.InfluxDB: v1.8.10
3.xxDB
主機配置：
1.壓測機：1 臺阿里云 ecs.g7.16xlarge 云主機：64 core，128 GB RAM
2.存儲集群：3 臺阿里云 ecs.g7.4xlarge 云主機：16 core，64 GB RAM，200 GB PL1 類型 ESSD
部署方式：
因為 InfluxDB 的開源版本不支持集群模式，所以我們也將分兩組進行測試。一組是 InfluxDB 與 GuanceDB、xxDB 的單機版本對比，另一組是 GuanceDB 與 xxDB 的集群模式進行對比，集群模式都使用 3 個存儲節(jié)點。
參數(shù)優(yōu)化：
GuanceDB 對大部分場景都做了自動調優(yōu)，所以我們不用手動調整配置。
InfluxDB 默認對高基數(shù)場景做了一些保護，我們調整 max-series-per-database = 0 放開了限制，cache-max-memory-size 增大到了 10g，并且開啟 tsi1 索引。
xxDB 我們也參考文檔進行了針對性的調優(yōu)。
至此完成所有配置，開始測試。
寫入測試
●單機組
本組測試進行的測試輪次比較多，這里我們挑選某一輪展示詳細監(jiān)控截圖。
在此輪測試中，我們虛擬了 344 個 node-exporter 實例，生成大約 50w 條活躍時間線，5s 抓取一次，時序點寫入 QPS 10w。
GuanceDB 資源開銷：CPU 占用率 2%，內存占用約 3 GB。
InfluxDB 資源開銷：CPU 占用率 16%，內存占用約 7.4 GB。
xxDB 資源開銷：CPU 占用率 61%，內存占用 9 GB。
匯總結果表格如下：
完成了限定性能的測試場景后，我們很好奇要多大的壓力才能將各臺數(shù)據(jù)庫主機的資源打滿，尤其對 GuanceDB，響應 10w 寫入 QPS 僅僅花費了 2% 的 CPU 開銷，它的性能上限在哪里?隨即我們開始加大 QPS，當各臺主機的 CPU，內存和磁盤若有一項被打滿時，即被認為到達瓶頸。
實際測試結果都是主機的 CPU 先被打滿，此時內存占用和磁盤寫入帶寬都還有余量，所以我們就以 CPU 利用率為瓶頸指標畫出以下對比圖：
在單機場景下，當 CPU 達到滿載時，xxDB 的寫入 QPS 約 15w，InfluxDB 約 90w，GuanceDB 約 270w。本輪 GuanceDB 獲得第一，寫入性能是 InfluxDB 的 3 倍。也可以看到在 CPU 利用率超過 20% 后，性能不再呈線性增長，都有一定程度衰退。
●集群組
我們按照之前的方法繼續(xù)測試 3 節(jié)點集群：
在集群場景下，仍然是 CPU 利用率先達到瓶頸。同樣在 CPU 滿載情況下，GuanceDB 此時的寫入 QPS 約為 860w，xxDB 約為 45w。
對比之前 GuanceDB 和 xxDB 的單機寫入性能測試，理想情況下 N 個節(jié)點的集群版的寫入性能應該是單機版的 N 倍，呈線性增長，實測 3 節(jié)點集群符合性能預期。
查詢測試
查詢測試將混合單機 InfluxDB、集群版 GuanceDB、集群版 xxDB 一起進行。集群一般可以將數(shù)據(jù)和查詢分攤并可以在節(jié)點之間并行查詢，理論上這個測試方式對 InfluxDB 不太公平，但條件受限，暫且這么設計。
我們虛擬 688 個 node-exporter 實例，生成大約 100w 個活躍時間線，5s 抓取一次，時序點寫入 QPS 20w。在持續(xù)寫入 24 小時后，我們再測試一些常見語句的查詢性能和對比存儲空間占用。
GuanceDB 同時支持 DQL 和 PromQL 兩種查詢語法。DQL 是觀測云自研的多模數(shù)據(jù)查詢語言，同時支持指標、日志、對象等多種類型負載數(shù)據(jù)的查詢和分析，語法表達非常簡潔。語法設計上跟 SQL 接近，但更加適應時序分析場景，學習曲線平滑。
這里我們一共對比了四種查詢語法在相同語義的 1h、8h、24h 不同時間范圍下的響應時間：
查詢 1 響應時間：
注：圖示中 0ms 表示響應時間不到 1ms。
查詢 2 響應時間：
查詢 3 響應時間：
注：圖示中 -1ms 表示請求響應時間超過了 60s 不計數(shù)。
空間占用對比
在上述的查詢測試構造的寫入壓力(活躍時間線 100w，時序點寫入 QPS 20w)下，運行 24 小時后，我們對比存儲空間占用。
總結
經(jīng)過數(shù)輪的寫入和查詢性能測試，相信各位對 GuanceDB 的綜合性能表現(xiàn)已經(jīng)有了比較清晰的認識了。GuanceDB 對比 InfluxDB 寫入性能提升 3 倍，存儲空間占用減少 68%，查詢性能提升 30 倍以上。GuanceDB 相比 xxDB 提升則更明顯，背后的原因是 xxDB 雖然明面上是支持了 Schemaless 數(shù)據(jù)的寫入，但是對 Schemaless 的場景明顯優(yōu)化不足，所以表現(xiàn)欠佳。
GuanceDB 的優(yōu)異性能來自于我們構建的高效的火山模型查詢引擎、SIMD 指令加速、對 Schemaless 數(shù)據(jù)的最優(yōu)先支持等，也因為我們站在了 VictoriaMetrics 的肩膀上。非常感謝 VictoriaMetrics 開源社區(qū)對我們的支持，我們將持續(xù)貢獻回報社區(qū)，共同促進可觀測領域技術的發(fā)展與進步。
我們在 5 月中下旬也將發(fā)布 GuanceDB 的單機版本，歡迎大家到時關注和測試。如有同學對 GuanceDB 感興趣，或有任何疑問，可以隨時站內和我聯(lián)絡，或者在觀測云社群里溝通。
免責聲明：市場有風險，選擇需謹慎！此文僅供參考，不作買賣依據(jù)。
關鍵詞：
