數(shù)據(jù)計(jì)算層面：
向量化執(zhí)行+SIMD(單指令多數(shù)據(jù)流)
* ClickHouse實(shí)現(xiàn)了向量執(zhí)行引擎(Vectorized execution engine)，對(duì)內(nèi)存中的列式數(shù)據(jù)，一個(gè)batch調(diào)用一次SIMD指令(而非每一行調(diào)用一次)，不僅減少了函數(shù)調(diào)用次數(shù)、降低了cache miss，而且可以充分發(fā)揮SIMD指令的并行能力，大幅縮短了計(jì)算耗時(shí)。向量執(zhí)行引擎，通常能夠帶來數(shù)倍的性能提升。
動(dòng)態(tài)代碼生成(Runtime Codegen)
* 在經(jīng)典的數(shù)據(jù)庫(kù)實(shí)現(xiàn)中，通常對(duì)表達(dá)式計(jì)算采用火山模型，也即將查詢轉(zhuǎn)換成一個(gè)個(gè)operator，比如HashJoin、Scan、IndexScan、Aggregation等。為了連接不同算子，operator之間采用統(tǒng)一的接口，比如open/next/close。在每個(gè)算子內(nèi)部都實(shí)現(xiàn)了父類的這些虛函數(shù)，在分析場(chǎng)景中單條SQL要處理數(shù)據(jù)通常高達(dá)數(shù)億行，虛函數(shù)的調(diào)用開銷不再可以忽略不計(jì)。另外，在每個(gè)算子內(nèi)部都要考慮多種變量，比如列類型、列的size、列的個(gè)數(shù)等，存在著大量的if-else分支判斷導(dǎo)致CPU分支預(yù)測(cè)失效。 * ClickHouse實(shí)現(xiàn)了Expression級(jí)別的runtime codegen，動(dòng)態(tài)地根據(jù)當(dāng)前SQL直接生成代碼，然后編譯執(zhí)行。如下圖例子所示，對(duì)于Expression直接生成代碼，不僅消除了大量的虛函數(shù)調(diào)用(即圖中多個(gè)function pointer的調(diào)用)，而且由于在運(yùn)行時(shí)表達(dá)式的參數(shù)類型、個(gè)數(shù)等都是已知的，也消除了不必要的if-else分支判斷。
多核并行處理+分布式處理
* ClickHouse將數(shù)據(jù)劃分為多個(gè)partition，每個(gè)partition再進(jìn)一步劃分為多個(gè)index granularity，然后通過多個(gè)CPU核心分別處理其中的一部分來實(shí)現(xiàn)并行數(shù)據(jù)處理。在這種設(shè)計(jì)下，單條Query就能利用整機(jī)所有CPU。極致的并行處理能力，極大的降低了查詢延時(shí)。 * 分布式計(jì)算，即多機(jī)器處理線性擴(kuò)展
著眼硬件+高效的算法實(shí)現(xiàn)
# 比如 * ClickHouse設(shè)計(jì)時(shí)非常在于對(duì)CPU L3級(jí)別的緩存使用，因?yàn)橐淮蜭3 cache miss會(huì)帶來70~100納秒的延遲。這意味著，在單核CPU上，它會(huì)浪費(fèi)4000萬/每秒的運(yùn)算;而在一個(gè)32線程的CPU上，則可能會(huì)浪費(fèi)5億/每秒的運(yùn)算，別小看這些細(xì)節(jié)，一點(diǎn)一滴的將它們累加起來，數(shù)據(jù)是非?？捎^的。也正因?yàn)樽⒁饬诉@些細(xì)節(jié)，所以ClickHouse在基準(zhǔn)查詢中，能做到1.75億/每秒的數(shù)據(jù)掃描性能。 * 針對(duì)不同的場(chǎng)景選擇不同算法，例如去重計(jì)數(shù)uniqCombined函數(shù)，根據(jù)數(shù)據(jù)量的不同會(huì)選擇不同的算法。當(dāng)數(shù)據(jù)量較小的時(shí)候，會(huì)選擇Array保存;當(dāng)數(shù)據(jù)量中等時(shí)候，則會(huì)選擇HashSet;而當(dāng)數(shù)據(jù)量很大的時(shí)候,則使用HyperLogLog算法。
數(shù)據(jù)存儲(chǔ)和寫入層面：
列式存儲(chǔ)+有序存儲(chǔ)
主鍵索引+稀疏索引
數(shù)據(jù)分片
數(shù)據(jù)寫入是Batch+Append+后臺(tái)線程Merge
京公網(wǎng)安備 11010802030320號(hào)