簡介

我們需要儲存結構化時序資料，時間間隔為5分鐘或1分鐘，計算95峰值、995峰值、最值等指標，並且在網頁中展示。

專案開發初期，為了快速開發原型，驗證產品，我們使用MySQL作為整個專案的儲存。帶來的問題是時序資料庫範圍分析查詢耗時很長，計算30天的資料需要30s+，到了無法容忍的地步，即便是建立索引、使用BitInt儲存時間戳，幾乎沒有效能提升。

後來我們組其他同事說換ClickHouse來儲存時序資料，於是我們就開始了替換之旅。

ClickHouse是面向OLAP（線上分析處理）、相容SQL標準的列式資料庫，主要的不足是不支援事務。因此我們目前沒有把整個儲存都遷移到ClickHouse上，而是隻把時序資料存過來。

本以為替換過程會很麻煩，可能修改大量的程式碼和邏輯，實際上很快，因為之前介面的邏輯設計很合理，所以只替換了資料庫ORM庫，從gorm換成了sqlx，花了1天時間(前期重構邏輯花了1個星期我是不會會說^_^)。

更重要的是，ClickHouse提供了很多聚合函式，之前計算95值需要2次查詢，而現在只需要一次查詢就夠了，對應的SQL如下：

select d.en_name, max(d.in_value) as peak_in,    max(d.out_value) as peak_out, max(d.max_value) as peak_max,    quantileExact(0.95)(d.out_value) as peak_95,    quantileExact(0.995)(d.out_value) as peak_995,    quantileExact(0.999)(d.out_value) as peak_999from table_value d where d.record_time >= '2020-01-01 00:00:00' and d.record_time <= '2020-01-31 23:59:59'group by d.en_name

經驗證，ClickHouse是真的牛逼，30天內的查詢耗時從30s降到2s內，提升了15倍！！！

下圖是ClickHouse的測試結果，x軸表示查詢的時間範圍，最大12個月，最小1個月，共測試12次。可以看到大部分耗時在3s內。

下圖是MySQL儲存中的測試結果（忽略標題），分別計算1、2、3個月範圍的資料，共查詢1次，耗時都在100s以上。

ClickHouse之所以快主要是採用列式儲存和資料壓縮，減少了資料掃描範圍和資料傳輸大小；其次，利用CPU的SIMD(Single Instruction Multiple Data)技術實現向量化執行引擎，可以透過一條CPU指令對一組資料執行相同的操作，實現空間上的並行。

需要說明的是，MySQL和ClickHouse各有優劣，要針對自己的業務需求、場景選擇合適的資料庫。本文涉及的業務比較適用於ClickHouse的強項，才會比MySQL快15倍。