比MySQL快839倍！揭開分析型資料庫JCHDB的神秘面紗 京東智聯雲開發者

前不久，京東智聯云云產品研發部架構師王向飛老師線上上公開課 《Clickhouse在京東智聯雲的大規模應用和架構改良》中，介紹了Clickhouse 資料庫在京東智聯雲的落地應用與最佳化改進經歷，為想要深入瞭解Clickhouse的小夥伴們送上了一堂乾貨滿滿的技術分享課程。

精彩分享回顧 ： 《億級資料庫毫秒級查詢？看完這一篇，海量資料賦能你也行》

現在，這個基於Clickhouse的分析型雲資料庫JCHDB已正式上線，大家可以前往京東智聯雲控制檯開通試用。

JCHDB是京東智聯雲基於ClickHouse打造的聯機分析（OLAP）服務，採用分散式架構，可實現多核、多節點的並行化大型查詢，其查詢效能比傳統開源資料庫 快1~2個數量級，可充分滿足大型業務系統資料分析的需求。

ClickHouse是Yandex公司開源的一款分析型資料庫。Yandex是俄羅斯最大的提供搜尋服務的公司，包含各類線上流量分析服務。ClickHouse就是在這樣的背景下出現的。下面有一組資料，可以先來讓你感受一下ClickHouse的強悍效能：

▲各種型別資料庫在1億資料量下的查詢效能▲

上圖列舉了包含count、sum、group by、order by等情況的查詢對比，同等條件下，ClickHouse的查詢效能異常強悍：

• 是MySQL的839倍
• 是Greenplum的24倍
• 是Vertica的5倍

那麼，ClickHouse 為什麼能這麼快呢？下面我就帶大家來一起揭開它的神秘面紗：

1列式儲存與高效的資料壓縮

ClickHouse為了處理大資料量，同樣選擇了列式儲存，這種方式不但可以節省資料查詢時的IO，更有利於資料壓縮。ClickHouse在資料壓縮上預設使用LZ4演算法，總體壓縮比可達8:1。高壓縮比減小了資料體量，進而會提高磁碟IO及網路IO的效率，但壓縮和解壓還是會消耗CPU資源，所以ClickHouse對資料塊的大小做了最佳化控制來達到最佳效果。

2分散式多主架構提高併發效能

ClickHouse使讀請求可以隨機打到任意節點，均衡讀壓力，寫請求也無需轉發到master節點，不會產生單點壓力。並且使用分片（shard）分割槽（partition）的概念，使資料可以透過隨機或是hash的方式準均分地落在所有分片上，即資料的水平拆分，加速資料查詢時的並行能力。在節點內部使用分割槽分割表資料，在進一步提升並行處理能力的同時，更能加快資料塊的快速定位。

3向量引擎利用SIMD指令實現平行計算

向量引擎是ClickHouse很重要的一個特點，向量計算就是ClickHouse自底向上極盡最佳化設計思路的重要體現。向量引擎藉助CPU的SIMD實現，對多個資料塊來說，一次SIMD指令會同時操作多個塊，大大減少了命令執行次數，縮短了計算時間。向量引擎在結合多核後會將ClickHouse的效能淋漓盡致的發揮出來。

4稀疏索引及跳數索引

ClickHouse使用稀疏索引大大提高了搜尋效能。ClickHouse的索引是固定間隔（預設8192）抽樣形成的，而不是一一對應的索引，這樣就在大資料量情況下，大大縮減了索引大小，進而可以將索引載入到記憶體中，加快索引速度。如果不夠快，ClickHouse還提供了二級索引（跳數索引），這類索引是建立在主鍵索引（稀疏索引）之上的，以跳錶的原理為實現，加快主鍵索引的定位速度。當然這種設計對於單條資料的查詢來講並不適合，這也是ClickHouse作為OLAP行資料庫對OLTP類部分功能捨棄，也證明了ClickHouse對於OLAP領域的特有針對性。

5提供豐富的表引擎匹配各類分析場景

ClickHouse針對特殊業務需求做許多業務抽象，如：

• ReplacingMergeTree
• CollapsingMergeTree
• VersionedCollapsingMergeTree
• SummingMergeTree
• AggregatingMergeTree

如果資料有去重場景可以使用前三種，如果資料有簡單欄位預聚合操作可以使用SummingMergeTree，如果有自定義複雜預聚合操作可以使用AggregatingMergeTree。總之，ClickHouse透過各類表引擎，省去了對資料預處理的環節，加快了資料處理速度。

6支援資料取樣統計

這是ClickHouse比較特別的一個設計，支援百分比資料取樣，並進行統計分析，有很多場景是不需要取到所有完整資料的，或者在大資料量條件下只需獲取大體趨勢，這類場景不需要業務端做額外工作，使用ClickHouse就可以了。

其實ClickHouse並不是在某個方面用了特別的技術，而是在所有可以最佳化的方面都極盡最佳化，所以跬步千里。

ClickHouse是針對OLAP場景而設計研發的，所以在OLTP場景還是會有些水土不服，所以結合以上特點，推薦ClickHouse在如下場景中使用：

• 海量資料的儲存和查詢統計
• 使用者行為分析
• 實時報表
• 商業智慧
• 其他實時分析的業務或場景

結合種種優勢及京東集團內部多年的使用經驗，京東智聯雲基於開源ClickHouse研發了分析型資料庫JCHDB服務，並將其對外賦能。京東智聯雲JCHDB主要是依賴開源ClickHouse，並基於雲K8s平臺構建的分新型資料庫服務，可以為使用者提供快速建立、自定義規格、規格變配等服務的同時，可以讓使用者使用ClickHouse各種豐富的功能。

▲JCHDB架構圖▲

JCHDB採用Zookeeper叢集和ClickHouse叢集的組合方式結合ReplicatedMergeTree表引擎來提供多副本機制，使多副本實現單寫，並且多節點非同步同步資料。這樣可確保資料的冗餘儲存，保證資料的高可用性。JCHDB透過使用者VPC、服務VPC和管理VPC互相隔離的方式保證ClickHouse節點的資料安全性。同時，JCHDB透過將豐富的指標及日誌資料對接到統一監控平臺，實現了資料庫節點對使用者的可觀測性，可使使用者更加透明安心地使用JCHDB。

ClickHouse的叢集架構天然就適合跑在K8s上，外加K8s已經成熟的StatefulSet，更加適合使用K8s進行排程，並且基於K8s進行架構部署也會更好地順應多雲思想。

▲JCHDB K8s架構圖▲

針對ClickHouse叢集的複雜度，使用Operator自定義CRD進行監聽和排程。以Helm的方式進行chart包管理，透過values.yaml進行渲染，可靈活對叢集進行復雜多樣的屬性配置。利用StatefulSet並掛載雲盤，使儲存和計算分離，同時也可以使pod故障實現秒級恢復。JCHDB不但使用多副本保證計算節點的高可用，還使用雲盤三備份方式保證資料的高可用。

JCHDB支援多可用區部署。雖然上面提到了很多可以保證高可用的機制和措施，但如果大部分資料庫例項都被排程到了同一臺物理機，在這臺物理機突發故障的時候也是不可想象的。

▲JCHDB多可用區架構圖▲

JCHDB會根據使用者對可用區的選擇實現不同的排程方式，如果使用者選擇3副本3可用區，則會將3個副本節點排程到3個可用區，如果多餘3個節點，會在此基礎上再近似均分的方式進行排程。ClickHouse和Zookeeper節點都是類似的排程方式。如果使用者選擇了單可用區，也會保證同分片的不同副本節點不會被排程到同一臺物理機。使用者可以根據自己的需求自行選擇可用區配置。

JCHDB不但提供了許多例項級的基礎指標（如CPU使用率、記憶體使用率、磁碟使用及IO指標等），還提供了針對ClickHouse的許多相關指標（QPS、每秒插入記錄數、積壓job數、當前活躍連線數等）。

▲JCHDB部分指標資料監控圖▲

當然，以上所述只是JCHDB的冰山一角，本篇文章先讓大家對JCHDB有個初步瞭解，歡迎有興趣的或有需求的同學們來試用。 點選 【 閱讀 】 即可詳細瞭解 京東智聯雲JCHDB 。