一、ClickHouse性能情況
主要分為4個方面
1、單個查詢吞吐量
場景一：
如果數據被放置在page cache中，則一個不太復雜的查詢在單個服務器上大約能夠以2-10GB／s（未壓縮）的速度進行處理（對於簡單的查詢，速度可以達到30GB／s）
場景二：
如果數據沒有在page cache中的話，那么速度將取決於你的磁盤系統和數據的壓縮率
例如：
a、如果一個磁盤允許以400MB／s的速度讀取數據，並且數據壓縮率是3，則數據的處理速度為1.2GB/s。
b、這意味着，如果你是在提取一個10字節的列，那么它的處理速度大約是1-2億行每秒
c、對於分布式處理，處理速度幾乎是線性擴展的，但這受限於聚合或排序的結果不是那么大的情況下
2、處理短查詢的延時時間
（1）數據被page cache緩存的情況下，它的延遲應該小於50毫秒(最佳情況下應該小於10毫秒)，否則，延遲取決於數據的查找次數
（2）延遲可以通過以下公式計算得知： 查找時間（10 ms） * 查詢的列的數量 * 查詢的數據塊的數量
3、處理大量短查詢
（1）ClickHouse可以在單個服務器上每秒處理數百個查詢（在最佳的情況下最多可以處理數千個）
（2）但是由於這不適用於分析型場景。建議每秒最多查詢100次
4、數據寫入性能
（1）建議每次寫入不少於1000行的批量寫入，或每秒不超過一個寫入請求
（2）當使用tab-separated格式將一份數據寫入到MergeTree表中時，寫入速度大約為50到200MB/s
（3）如果您寫入的數據每行為1Kb，那么寫入的速度為50，000到200，000行每秒
（4）如果您的行更小，那么寫入速度將更高
（5）如果您的行更小，那么寫入速度將更高
注意：ClickHouse並非無所不能，查詢語句需要不斷的調優，可能與查詢條件有關，不同的查詢條件表是左join還是右join也是很有講究的
補充問題：
mysql與ClickHouse性能寫入區別？
mysql：
（1）MySQL單條SQL是單線程的，只能跑滿一個core
（2）IO方面，MySQL是行存儲，MySQL需要大量隨機IO
ClickHouse：
（1）ClickHouse相反，有多少CPU，吃多少資源，所以飛快
（2）ClickHouse不支持事務，不存在隔離級別。ClickHouse的定位是分析性數據庫，而不是嚴格的關系型數據庫
（3）IO方面，ClickHouse是列存儲，后者在count()這類操作天然有優勢，ClickHouse基本是順序IO
思考：
據導入的時候，數據肯定緩存在內存里了，這個的確，但是ClickHouse基本上是順序IO。對IO基本沒有太高要求，當然，磁盤越快，上層處理越快，但是99%的情況是，CPU先跑滿了（數據庫里太少見了，大多數都是IO不夠用）
二、ClickHouse相關優化
（1）關閉虛擬內存，物理內存和虛擬內存的數據交換，會導致查詢變慢
（2）為每一個賬戶添加join_use_nulls配置，左表中的一條記錄在右表中不存在，右表的相應字段會返回該字段相應數據類型的默認值，而不是標准SQL中的Null值
（3）JOIN操作時一定要把數據量小的表放在右邊，ClickHouse中無論是Left Join 、Right Join還是Inner Join永遠都是拿着右表中的每一條記錄到左表中查找該記錄是否存在，所以右表必須是小表
（4）批量寫入數據時，必須控制每個批次的數據中涉及到的分區的數量，在寫入之前最好對需要導入的數據進行排序。無序的數據或者涉及的分區太多，會導致ClickHouse無法及時對新導入的數據進行合並，從而影響查詢性能
（5）盡量減少JOIN時的左右表的數據量，必要時可以提前對某張表進行聚合操作，減少數據條數。有些時候，先GROUP BY再JOIN比先JOIN再GROUP BY查詢時間更短
（6）ClickHouse的分布式表性能性價比不如物理表高，建表分區字段值不宜過多，防止數據導入過程磁盤可能會被打滿
（7）CPU一般在50%左右會出現查詢波動，達到70%會出現大范圍的查詢超時，CPU是最關鍵的指標，要非常關注
三、ClickHouse有哪些優缺點？
優點：
（1）為了高效的使用CPU，數據不僅僅按列存儲，同時還按向量進行處理
（2）數據壓縮空間大，減少IO；處理單查詢高吞吐量每台服務器每秒最多數十億行
（3）索引非B樹結構，不需要滿足最左原則；只要過濾條件在索引列中包含即可；即使在使用的數據不在索引中，由於各種並行處理機制ClickHouse全表掃描的速度也很快
（4）寫入速度非常快，50-200M/s，對於大量的數據更新非常適用
缺點：
（1）不支持事務，不支持真正的刪除/更新
（2）不支持高並發，官方建議qps為100，可以通過修改配置文件增加連接數，但是在服務器足夠好的情況下
（3）不支持真正的刪除/更新支持 不支持事務（期待后續版本支持）
（4）不支持二級索引
（5）有限的SQL支持，join實現與眾不同
（6）不支持窗口功能
（7）元數據管理需要人工干預維護
（8）SQL滿足日常使用80%以上的語法，join寫法比較特殊；最新版已支持類似SQL的join，但性能不好
（9）ClickHouse快是因為采用了並行處理機制，即使一個查詢，也會用服務器一半的CPU去執行，所以ClickHouse不能支持高並發的使用場景，默認單查詢使用CPU核數為服務器核數的一半，安裝時會自動識別服務器核數，可以通過配置文件修改該參數
四、ClickHouse的特性有哪些？
（1）真正的列式數據庫管理系統
概述：
除了數據本身外不應該存在其他額外的數據意味着為了避免在值旁邊存儲它們的長度«number»，你必須支持固定長度數值類型
例如：
a、10億個UInt8類型的數據在未壓縮的情況下大約消耗1GB左右的空間，如果不是這樣的話，這將對CPU的使用產生強烈影響
b、即使是在未壓縮的情況下，緊湊的存儲數據也是非常重要的，因為解壓縮的速度主要取決於未壓縮數據的大小
注意：
a、在一些其他系統中也可以將不同的列分別進行存儲，但由於對其他場景進行的優化，使其無法有效的處理分析查詢。 例如： HBase，BigTable，Cassandra，HyperTable
b、在這些系統中，你可以得到每秒數十萬的吞吐能力，但是無法得到每秒幾億行的吞吐能力
說明：
a、ClickHouse不單單是一個數據庫， 它是一個數據庫管理系統
b、它允許在運行時創建表和數據庫、加載數據和運行查詢，而無需重新配置或重啟服務
（2）數據壓縮
a、一些列式數據庫管理系統中(例如：InfiniDB CE 和 MonetDB) 並沒有使用數據壓縮
b、但是, 若想達到比較優異的性能，數據壓縮確實起到了至關重要的作用。
（3）數據的磁盤存儲
a、許多的列式數據庫(如 SAP HANA, Google PowerDrill)只能在內存中工作，這種方式會造成比實際更多的設備預算
b、ClickHouse被設計用於工作在傳統磁盤上的系統，它提供每GB更低的存儲成本，但如果有可以使用SSD和內存，它也會合理的利用這些資源
（4）多核心並行處理
ClickHouse會使用服務器上一切可用的資源，從而以最自然的方式並行處理大型查詢
（5）多服務器分布式處理
a、列式數據庫管理系統中，幾乎沒有一個支持分布式的查詢處理
b、在ClickHouse中，數據可以保存在不同的shard上，每一個shard都由一組用於容錯的replica組成，查詢可以並行地在所有shard上進行處理。這些對用戶來說是透明的
（6）支持SQL
a、ClickHouse支持基於SQL的聲明式查詢語言，該語言大部分情況下是與SQL標准兼容的
b、支持的查詢包括 GROUP BY，ORDER BY，IN，JOIN以及非相關子查詢
c、不支持窗口函數和相關子查詢
（7）向量引擎
為了高效的使用CPU，數據不僅僅按列存儲，同時還按向量(列的一部分)進行處理，這樣可以更加高效地使用CPU
（8）實時的數據更新
a、ClickHouse支持在表中定義主鍵
b、為了使查詢能夠快速在主鍵中進行范圍查找，數據總是以增量的方式有序的存儲在MergeTree中
c、因此，數據可以持續不斷地高效的寫入到表中，並且寫入的過程中不會存在任何加鎖的行為
（9）索引
按照主鍵對數據進行排序，這將幫助ClickHouse在幾十毫秒以內完成對數據特定值或范圍的查找
（10）適合在線查詢
在線查詢意味着在沒有對數據做任何預處理的情況下以極低的延遲處理查詢並將結果加載到用戶的頁面中
（11）支持近似計算
ClickHouse提供各種各樣在允許犧牲數據精度的情況下對查詢進行加速的方法：
a、用於近似計算的各類聚合函數，如：distinct values, medians, quantiles
b、基於數據的部分樣本進行近似查詢。這時，僅會從磁盤檢索少部分比例的數據
c、不使用全部的聚合條件，通過隨機選擇有限個數據聚合條件進行聚合。這在數據聚合條件滿足某些分布條件下，在提供相當准確的聚合結果的同時降低了計算資源的使用
（12）支持數據復制和數據完整性
a、ClickHouse使用異步的多主復制技術
b、當數據被寫入任何一個可用副本后，系統會在后台將數據分發給其他副本，以保證系統在不同副本上保持相同的數據
c、在大多數情況下ClickHouse能在故障后自動恢復，在一些少數的復雜情況下需要手動恢復。
五、ClickHouse的超出內存限制解決辦法
ClickHouse進行復雜查詢時，包含多個left join和group by，會報錯：超出內存限制。
1.臨時設置
SET max_memory_usage = 128000000000; #128G，
如果沒有那么多的內存可用，ClickHouse可以通過設置這個“溢出”數據到磁盤：set max_bytes_before_external_group_by=20000000000; #20G
set max_memory_usage=40000000000; #40G
將max_memory_usage設置為max_bytes_before_external_group_by大小的兩倍。如果發現還是報內存不夠或者服務器直接崩潰，設置partial_merge_join = 1，但是運行速度會很慢。
2.全局設置
在users.xml文件中為每個用戶設置參數：#max_memory_usage：在單個ClickHouse服務進程中，運行一次查詢限制使用的最大內存用量，默認值為10G； #max_bytes_before_external_group_by：在執行GROUP BY聚合查詢的時候，限制使用的最大內存用量，默認值為0，即不做限制。當超過閾值數量的時候，聚合查詢將會進一步借用本地磁盤。 #use_uncompressed_cache：使用未壓縮的緩存大小，默認0不限制。 <max_bytes_before_external_group_by>0</max_bytes_before_external_group_by> <max_memory_usage>10000000000</max_memory_usage> <use_uncompressed_cache>0</use_uncompressed_cache>