ClickHouse 具有 ROLAP、在線實時查詢、完整的 DBMS、列式存儲、不需要任何數據預處理、支持批量更新、擁有非常完善的 SQL 支持和函數、支持高可用、不依賴 Hadoop 復雜生態、開箱即用等許多特點。特別是它那夸張的查詢性能，我想大多數剛接觸 ClickHouse 的人也一定會因為它的性能指標而動容。在一系列官方公布的基準測試對比中，ClickHouse 都遙遙領先對手，這其中不乏一些我們耳熟能詳的名字。
所有用于對比的數據庫都使用了相同配置的服務器，在單個節點的情況下，對一張擁有133個字段的數據表分別在1000萬、1億和10億三種數據體量下執行基準測試，基準測試的范圍涵蓋43項SQL查詢。在1億數據集體量的情況下，ClickHouse的平均響應速度是 Vertica 的2.63倍、InfiniDB的17倍、MonetDB 的27倍、Hive 的126倍、MySQL 的429倍以及 Greenplum 的10倍。詳細的測試結果可以查閱https://clickhouse.yandex/benchmark.html。
很多用戶心中一直會有這樣的疑問，為什么 ClickHouse 這么快？因為ClickHouse 是列式存儲數據庫，所以快；也因為 ClickHouse 使用了向量化引擎，所以快。這些解釋都站得住腳，但是依然不能消除全部的疑問。因為這些技術并不是秘密，世面上有很多數據庫同樣使用了這些技術，但是依然沒有ClickHouse這么快。所以我想從另外一個角度來探討一番ClickHouse的秘訣到底是什么。
首先向各位讀者拋出一個疑問：在設計軟件架構的時候，做設計的原則應該是自頂向下地去設計，還是應該自下而上地去設計呢？在傳統觀念中，或者說在我的觀念中，自然是自頂向下的設計，通常我們都被教導要做好頂層設計。而ClickHouse 的設計則采用了自下而上的方式。ClickHouse 的原型系統早在2008年就誕生了，在誕生之初它并沒有宏偉的規劃。相反它的目的很單純，就是希望能以最快的速度進行 GROUP BY 查詢和過濾。他們是如何實踐自下而上設計的呢？
著眼硬件，先想后做
首先從硬件功能層面著手設計，在設計伊始就至少需要想清楚如下幾個問題。
-
我們將要使用的硬件水平是怎樣的？包括CPU、內存、硬盤、網絡等。
-
在這樣的硬件上，我們需要達到怎樣的性能？包括延遲、吞吐量等。
-
我們準備使用怎樣的數據結構？包括 String、HashTable、Vector 等。
-
選擇的這些數據結構，在我們的硬件上會如何工作？
如果能想清楚上面這些問題，那么在動手實現功能之前，就已經能夠計算出粗略的性能了。所以，基于將硬件功效最大化的目的，ClickHouse 會在內存中進行GROUP BY，并且使用 HashTable 裝載數據。與此同時，他們非常在意 CPU L3級別的緩存，因為一次L3的緩存失效會帶來70～100ns的延遲。這意味著在單核 CPU 上，它會浪費4000萬次/秒的運算；而在一個32線程的 CPU 上，則可能會浪費5億次/秒的運算。所以別小看這些細節，一點一滴地將它們累加起來，數據是非常可觀的。正因為注意了這些細節，所以 ClickHouse 在基準查詢中能做到1.75億次/秒的數據掃描性能。
算法在前，抽象在后
常有人念叨：“有時候，選擇比努力更重要。”確實，路線選錯了再努力也是白搭。在 ClickHouse 的底層實現中，經常會面對一些重復的場景，例如字符串子串查詢、數組排序、使用 HashTable 等。如何才能實現性能的最大化呢？算法的選擇是重中之重。以字符串為例，有一本專門講解字符串搜索的書，名為“Handbook of Exact String Matching Algorithms”，列舉了35種常見的字符串搜索算法。各位猜一猜 ClickHouse 使用了其中的哪一種？答案是一種都沒有。這是為什么呢？因為性能不夠快。在字符串搜索方面，針對不同的場景，ClickHouse 最終選擇了這些算法：對于常量，使用 Volnitsky 算法；對于非常量，使用 CPU 的向量化執行 SIMD，暴力優化；正則匹配使用 re2 和hyperscan 算法。性能是算法選擇的首要考量指標。
勇于嘗鮮，不行就換
除了字符串之外，其余的場景也與它類似，ClickHouse 會使用最合適、最快的算法。如果世面上出現了號稱性能強大的新算法，ClickHouse 團隊會立即將其納入并進行驗證。如果效果不錯，就保留使用；如果性能不盡人意，就將其拋棄。
特定場景，特殊優化
針對同一個場景的不同狀況，選擇使用不同的實現方式，盡可能將性能最大化。關于這一點，其實在前面介紹字符串查詢時，針對不同場景選擇不同算法的思路就有體現了。類似的例子還有很多，例如去重計數 uniqCombined 函數，會根據數據量的不同選擇不同的算法：當數據量較小的時候，會選擇 Array 保存；當數據量中等的時候，會選擇 HashSet；而當數據量很大的時候，則使用HyperLogLog 算法。
對于數據結構比較清晰的場景，會通過代碼生成技術實現循環展開，以減少循環次數。接著就是大家熟知的大殺器—向量化執行了。SIMD 被廣泛地應用于文本轉換、數據過濾、數據解壓和 JSON 轉換等場景。相較于單純地使用 CPU，利用寄存器暴力優化也算是一種降維打擊了。
持續測試，持續改進
如果只是單純地在上述細節上下功夫，還不足以構建出如此強大的ClickHouse，還需要擁有一個能夠持續驗證、持續改進的機制。由于 Yandex的天然優勢，ClickHouse 經常會使用真實的數據進行測試，這一點很好地保證了測試場景的真實性。與此同時，ClickHouse 也是我見過的發版速度最快的開源軟件了，差不多每個月都能發布一個版本。沒有一個可靠的持續集成環境，這一點是做不到的。正因為擁有這樣的發版頻率，ClickHouse 才能夠快速迭代、快速改進。
所以ClickHouse 的黑魔法并不是一項單一的技術，而是一種自底向上的、追求極致性能的設計思路。這就是它如此之快的秘訣。
本文摘編于《ClickHouse原理解析與應用實戰》，經出版方授權發布。
#歡迎來留言#
你用過ClickHouse嗎？
對此你怎么看？
CSDN攜手【機械工業出版社】送出
《ClickHouse原理解析與應用實戰》一本
截至7月17日12:00點
關于作者：
ClickHouse貢獻者之一，ClickHouse布道者，資深架構師，騰訊云最具價值專家TVP，開源愛好者， 十多年IT從業經驗，對大數據領域主流技術與解決方案有深入研究，擅長分布式系統的架構設計與整合。曾主導過多款大數據平臺級產品的規劃、設計與研發工作，一線實戰經驗豐富。現就職于遠光軟件股份有限公司，任大數據事業部平臺開發部總經理。
