談?wù)凜lickHouse性能情況以及相關(guān)優(yōu)化

ClickHouse性能情況

主要分為4個(gè)方面

1、單個(gè)查詢吞吐量

場(chǎng)景一：

如果數(shù)據(jù)被放置在page cache中，則一個(gè)不太復(fù)雜的查詢?cè)趩蝹€(gè)服務(wù)器上大約能夠以2-10GB／s（未壓縮）的速度進(jìn)行處理（對(duì)于簡(jiǎn)單的查詢，速度可以達(dá)到30GB／s）

場(chǎng)景二：

如果數(shù)據(jù)沒有在page cache中的話，那么速度將取決于你的磁盤系統(tǒng)和數(shù)據(jù)的壓縮率

例如：

a、如果一個(gè)磁盤允許以400MB／s的速度讀取數(shù)據(jù)，并且數(shù)據(jù)壓縮率是3，則數(shù)據(jù)的處理速度為1.2GB/s。
b、這意味著，如果你是在提取一個(gè)10字節(jié)的列，那么它的處理速度大約是1-2億行每秒
c、對(duì)于分布式處理，處理速度幾乎是線性擴(kuò)展的，但這受限于聚合或排序的結(jié)果不是那么大的情況下

2、處理短查詢的延時(shí)時(shí)間

（1）數(shù)據(jù)被page cache緩存的情況下，它的延遲應(yīng)該小于50毫秒(最佳情況下應(yīng)該小于10毫秒)，否則，延遲取決于數(shù)據(jù)的查找次數(shù)
（2）延遲可以通過以下公式計(jì)算得知：查找時(shí)間（10 ms） * 查詢的列的數(shù)量 * 查詢的數(shù)據(jù)塊的數(shù)量

3、處理大量短查詢

（1）ClickHouse可以在單個(gè)服務(wù)器上每秒處理數(shù)百個(gè)查詢（在最佳的情況下最多可以處理數(shù)千個(gè)）
（2）但是由于這不適用于分析型場(chǎng)景。建議每秒最多查詢100次

4、數(shù)據(jù)寫入性能

（1）建議每次寫入不少于1000行的批量寫入，或每秒不超過一個(gè)寫入請(qǐng)求
（2）當(dāng)使用tab-separated格式將一份數(shù)據(jù)寫入到MergeTree表中時(shí)，寫入速度大約為50到200MB/s
（3）如果您寫入的數(shù)據(jù)每行為1Kb，那么寫入的速度為50，000到200，000行每秒
（4）如果您的行更小，那么寫入速度將更高
（5）如果您的行更小，那么寫入速度將更高

注意：ClickHouse并非無所不能，查詢語句需要不斷的調(diào)優(yōu)，可能與查詢條件有關(guān)，不同的查詢條件表是左join還是右join也是很有講究的

補(bǔ)充問題：

mysql與ClickHouse性能寫入?yún)^(qū)別？

mysql：

（1）MySQL單條SQL是單線程的，只能跑滿一個(gè)core
（2）IO方面，MySQL是行存儲(chǔ)，MySQL需要大量隨機(jī)IO

ClickHouse：

（1）ClickHouse相反，有多少CPU，吃多少資源，所以飛快
（2）ClickHouse不支持事務(wù)，不存在隔離級(jí)別。ClickHouse的定位是分析性數(shù)據(jù)庫，而不是嚴(yán)格的關(guān)系型數(shù)據(jù)庫
（3）IO方面，ClickHouse是列存儲(chǔ)，后者在count()這類操作天然有優(yōu)勢(shì)，ClickHouse基本是順序IO

思考：

據(jù)導(dǎo)入的時(shí)候，數(shù)據(jù)肯定緩存在內(nèi)存里了，這個(gè)的確，但是ClickHouse基本上是順序IO。對(duì)IO基本沒有太高要求，當(dāng)然，磁盤越快，上層處理越快，但是99%的情況是，CPU先跑滿了（數(shù)據(jù)庫里太少見了，大多數(shù)都是IO不夠用）

二、ClickHouse相關(guān)優(yōu)化

（1）關(guān)閉虛擬內(nèi)存，物理內(nèi)存和虛擬內(nèi)存的數(shù)據(jù)交換，會(huì)導(dǎo)致查詢變慢

（2）為每一個(gè)賬戶添加join_use_nulls配置，左表中的一條記錄在右表中不存在，右表的相應(yīng)字段會(huì)返回該字段相應(yīng)數(shù)據(jù)類型的默認(rèn)值，而不是標(biāo)準(zhǔn)SQL中的Null值

（3）JOIN操作時(shí)一定要把數(shù)據(jù)量小的表放在右邊，ClickHouse中無論是Left Join 、Right Join還是Inner Join永遠(yuǎn)都是拿著右表中的每一條記錄到左表中查找該記錄是否存在，所以右表必須是小表

（4）批量寫入數(shù)據(jù)時(shí)，必須控制每個(gè)批次的數(shù)據(jù)中涉及到的分區(qū)的數(shù)量，在寫入之前最好對(duì)需要導(dǎo)入的數(shù)據(jù)進(jìn)行排序。無序的數(shù)據(jù)或者涉及的分區(qū)太多，會(huì)導(dǎo)致ClickHouse無法及時(shí)對(duì)新導(dǎo)入的數(shù)據(jù)進(jìn)行合并，從而影響查詢性能

（5）盡量減少JOIN時(shí)的左右表的數(shù)據(jù)量，必要時(shí)可以提前對(duì)某張表進(jìn)行聚合操作，減少數(shù)據(jù)條數(shù)。有些時(shí)候，先GROUP BY再JOIN比先JOIN再GROUP BY查詢時(shí)間更短

（6）ClickHouse的分布式表性能性價(jià)比不如物理表高，建表分區(qū)字段值不宜過多，防止數(shù)據(jù)導(dǎo)入過程磁盤可能會(huì)被打滿

（7）CPU一般在50%左右會(huì)出現(xiàn)查詢波動(dòng)，達(dá)到70%會(huì)出現(xiàn)大范圍的查詢超時(shí)，CPU是最關(guān)鍵的指標(biāo)，要非常關(guān)注

三、ClickHouse有哪些優(yōu)缺點(diǎn)？

優(yōu)點(diǎn)：

（1）為了高效的使用CPU，數(shù)據(jù)不僅僅按列存儲(chǔ)，同時(shí)還按向量進(jìn)行處理
（2）數(shù)據(jù)壓縮空間大，減少IO；處理單查詢高吞吐量每臺(tái)服務(wù)器每秒最多數(shù)十億行
（3）索引非B樹結(jié)構(gòu)，不需要滿足最左原則；只要過濾條件在索引列中包含即可；即使在使用的數(shù)據(jù)不在索引中，由于各種并行處理機(jī)制ClickHouse全表掃描的速度也很快
（4）寫入速度非常快，50-200M/s，對(duì)于大量的數(shù)據(jù)更新非常適用

缺點(diǎn)：

（1）不支持事務(wù)，不支持真正的刪除/更新
（2）不支持高并發(fā)，官方建議qps為100，可以通過修改配置文件增加連接數(shù)，但是在服務(wù)器足夠好的情況下
（3）不支持真正的刪除/更新支持 不支持事務(wù)（期待后續(xù)版本支持）
（4）不支持二級(jí)索引
（5）有限的SQL支持，join實(shí)現(xiàn)與眾不同
（6）不支持窗口功能
（7）元數(shù)據(jù)管理需要人工干預(yù)維護(hù)
（8）SQL滿足日常使用80%以上的語法，join寫法比較特殊；最新版已支持類似SQL的join，但性能不好
（9）ClickHouse快是因?yàn)椴捎昧瞬⑿刑幚頇C(jī)制，即使一個(gè)查詢，也會(huì)用服務(wù)器一半的CPU去執(zhí)行，所以ClickHouse不能支持高并發(fā)的使用場(chǎng)景，默認(rèn)單查詢使用CPU核數(shù)為服務(wù)器核數(shù)的一半，安裝時(shí)會(huì)自動(dòng)識(shí)別服務(wù)器核數(shù)，可以通過配置文件修改該參數(shù)

四、ClickHouse的特性有哪些？

（1）真正的列式數(shù)據(jù)庫管理系統(tǒng)

概述：
除了數(shù)據(jù)本身外不應(yīng)該存在其他額外的數(shù)據(jù)意味著為了避免在值旁邊存儲(chǔ)它們的長(zhǎng)度?number?，你必須支持固定長(zhǎng)度數(shù)值類型?
例如：
a、10億個(gè)UInt8類型的數(shù)據(jù)在未壓縮的情況下大約消耗1GB左右的空間，如果不是這樣的話，這將對(duì)CPU的使用產(chǎn)生強(qiáng)烈影響
b、即使是在未壓縮的情況下，緊湊的存儲(chǔ)數(shù)據(jù)也是非常重要的，因?yàn)榻鈮嚎s的速度主要取決于未壓縮數(shù)據(jù)的大小

注意：
a、在一些其他系統(tǒng)中也可以將不同的列分別進(jìn)行存儲(chǔ)，但由于對(duì)其他場(chǎng)景進(jìn)行的優(yōu)化，使其無法有效的處理分析查詢。例如：HBase，BigTable，Cassandra，HyperTable
b、在這些系統(tǒng)中，你可以得到每秒數(shù)十萬的吞吐能力，但是無法得到每秒幾億行的吞吐能力

說明：
a、ClickHouse不單單是一個(gè)數(shù)據(jù)庫， 它是一個(gè)數(shù)據(jù)庫管理系統(tǒng)
b、它允許在運(yùn)行時(shí)創(chuàng)建表和數(shù)據(jù)庫、加載數(shù)據(jù)和運(yùn)行查詢，而無需重新配置或重啟服務(wù)

（2）數(shù)據(jù)壓縮?

a、一些列式數(shù)據(jù)庫管理系統(tǒng)中(例如：InfiniDB CE 和 MonetDB) 并沒有使用數(shù)據(jù)壓縮
b、但是, 若想達(dá)到比較優(yōu)異的性能，數(shù)據(jù)壓縮確實(shí)起到了至關(guān)重要的作用。

（3）數(shù)據(jù)的磁盤存儲(chǔ)?

a、許多的列式數(shù)據(jù)庫(如 SAP HANA, Google PowerDrill)只能在內(nèi)存中工作，這種方式會(huì)造成比實(shí)際更多的設(shè)備預(yù)算
b、ClickHouse被設(shè)計(jì)用于工作在傳統(tǒng)磁盤上的系統(tǒng)，它提供每GB更低的存儲(chǔ)成本，但如果有可以使用SSD和內(nèi)存，它也會(huì)合理的利用這些資源

（4）多核心并行處理?

ClickHouse會(huì)使用服務(wù)器上一切可用的資源，從而以最自然的方式并行處理大型查詢

（5）多服務(wù)器分布式處理?

a、列式數(shù)據(jù)庫管理系統(tǒng)中，幾乎沒有一個(gè)支持分布式的查詢處理
b、在ClickHouse中，數(shù)據(jù)可以保存在不同的shard上，每一個(gè)shard都由一組用于容錯(cuò)的replica組成，查詢可以并行地在所有shard上進(jìn)行處理。這些對(duì)用戶來說是透明的

（6）支持SQL?

a、ClickHouse支持基于SQL的聲明式查詢語言，該語言大部分情況下是與SQL標(biāo)準(zhǔn)兼容的
b、支持的查詢包括 GROUP BY，ORDER BY，IN，JOIN以及非相關(guān)子查詢
c、不支持窗口函數(shù)和相關(guān)子查詢

（7）向量引擎?

為了高效的使用CPU，數(shù)據(jù)不僅僅按列存儲(chǔ)，同時(shí)還按向量(列的一部分)進(jìn)行處理，這樣可以更加高效地使用CPU

（8）實(shí)時(shí)的數(shù)據(jù)更新?

a、ClickHouse支持在表中定義主鍵
b、為了使查詢能夠快速在主鍵中進(jìn)行范圍查找，數(shù)據(jù)總是以增量的方式有序的存儲(chǔ)在MergeTree中
c、因此，數(shù)據(jù)可以持續(xù)不斷地高效的寫入到表中，并且寫入的過程中不會(huì)存在任何加鎖的行為

（9）索引

按照主鍵對(duì)數(shù)據(jù)進(jìn)行排序，這將幫助ClickHouse在幾十毫秒以內(nèi)完成對(duì)數(shù)據(jù)特定值或范圍的查找

（10）適合在線查詢

在線查詢意味著在沒有對(duì)數(shù)據(jù)做任何預(yù)處理的情況下以極低的延遲處理查詢并將結(jié)果加載到用戶的頁面中

（11）支持近似計(jì)算?

ClickHouse提供各種各樣在允許犧牲數(shù)據(jù)精度的情況下對(duì)查詢進(jìn)行加速的方法：
a、用于近似計(jì)算的各類聚合函數(shù)，如：distinct values, medians, quantiles
b、基于數(shù)據(jù)的部分樣本進(jìn)行近似查詢。這時(shí)，僅會(huì)從磁盤檢索少部分比例的數(shù)據(jù)
c、不使用全部的聚合條件，通過隨機(jī)選擇有限個(gè)數(shù)據(jù)聚合條件進(jìn)行聚合。這在數(shù)據(jù)聚合條件滿足某些分布條件下，在提供相當(dāng)準(zhǔn)確的聚合結(jié)果的同時(shí)降低了計(jì)算資源的使用

（12）支持?jǐn)?shù)據(jù)復(fù)制和數(shù)據(jù)完整性?

a、ClickHouse使用異步的多主復(fù)制技術(shù)
b、當(dāng)數(shù)據(jù)被寫入任何一個(gè)可用副本后，系統(tǒng)會(huì)在后臺(tái)將數(shù)據(jù)分發(fā)給其他副本，以保證系統(tǒng)在不同副本上保持相同的數(shù)據(jù)
c、在大多數(shù)情況下ClickHouse能在故障后自動(dòng)恢復(fù)，在一些少數(shù)的復(fù)雜情況下需要手動(dòng)恢復(fù)。