Clickhouse優缺點及性能狀況

優勢：

1，爲了高效的使用CPU，數據不只僅按列存儲，同時還按向量進行處理；

2，數據壓縮空間大，減小IO；處理單查詢高吞吐量每臺服務器每秒最多數十億行；

3，索引非B樹結構，不須要知足最左原則；只要過濾條件在索引列中包含便可；即便在使用的數據不在索引中，因爲各類並行處理機制ClickHouse全表掃描的速度也很快；

4，寫入速度很是快，50-200M/s，對於大量的數據更新很是適用。

缺點：

1，不支持事務，不支持真正的刪除/更新；

2，不支持高併發，官方建議qps爲100，能夠經過修改配置文件增長鏈接數，可是在服務器足夠好的狀況下；

3，SQL知足平常使用80%以上的語法，join寫法比較特殊；最新版已支持相似SQL的join，但性能很差；

4，儘可能作1000條以上批量的寫入，避免逐行insert或小批量的insert，update，delete操做，由於ClickHouse底層會不斷的作異步的數據合併，會影響查詢性能，這個在作實時數據寫入的時候要儘可能避開；

5，Clickhouse快是由於採用了並行處理機制，即便一個查詢，也會用服務器一半的CPU去執行，因此ClickHouse不能支持高併發的使用場景，默認單查詢使用CPU核數爲服務器核數的一半，安裝時會自動識別服務器核數，能夠經過配置文件修改該參數。

全量數據導入：數據導入臨時表 -> 導入完成後，將原表更名爲tmp1 -> 將臨時表更名爲正式表 -> 刪除原表

增量數據導入： 增量數據導入臨時表 -> 將原數據除增量外的也導入臨時表 -> 導入完成後，將原表更名爲tmp1-> 將臨時表改爲正式表-> 刪除原數據表

相關優化：

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是最關鍵的指標，要很是關注。

性能狀況

1,單個查詢吞吐量：若是數據被放置在page cache中，則一個不太複雜的查詢在單個服務器上大約可以以2-10GB／s（未壓縮）的速度進行處理（對於簡單的查詢，速度能夠達到30GB／s）。若是數據沒有在page cache中的話，那麼速度將取決於你的磁盤系統和數據的壓縮率。例如，若是一個磁盤容許以400MB／s的速度讀取數據，而且數據壓縮率是3，則數據的處理速度爲1.2GB/s。這意味着，若是你是在提取一個10字節的列，那麼它的處理速度大約是1-2億行每秒。對於分佈式處理，處理速度幾乎是線性擴展的，但這受限於聚合或排序的結果不是那麼大的狀況下。

2，處理短查詢的延時時間：數據被page cache緩存的狀況下，它的延遲應該小於50毫秒(最佳狀況下應該小於10毫秒)。 不然，延遲取決於數據的查找次數。延遲能夠經過如下公式計算得知： 查找時間（10 ms） * 查詢的列的數量 * 查詢的數據塊的數量。

3，處理大量短查詢：ClickHouse能夠在單個服務器上每秒處理數百個查詢（在最佳的狀況下最多能夠處理數千個）。可是因爲這不適用於分析型場景。建議每秒最多查詢100次。

4，數據寫入性能：建議每次寫入很多於1000行的批量寫入，或每秒不超過一個寫入請求。當使用tab-separated格式將一份數據寫入到MergeTree表中時，寫入速度大約爲50到200MB/s。若是您寫入的數據每行爲1Kb，那麼寫入的速度爲50，000到200，000行每秒。若是您的行更小，那麼寫入速度將更高。爲了提升寫入性能，您可使用多個INSERT進行並行寫入，這將帶來線性的性能提高。

count: 千萬級別，500毫秒，1億 800毫秒  2億 900毫秒 3億 1.1秒
group: 百萬級別 200毫米，千萬 1秒，1億 10秒，2億 20秒，3億 30秒
join：千萬-10萬 600 毫秒， 千萬 -百萬：10秒，千萬-千萬 150秒

ClickHouse並不是無所不能，查詢語句須要不斷的調優，可能與查詢條件有關，不一樣的查詢條件表是左join仍是右join也是頗有講究的。

其餘補充：

1，MySQL單條SQL是單線程的，只能跑滿一個core，ClickHouse相反，有多少CPU，吃多少資源，因此飛快；2，ClickHouse不支持事務，不存在隔離級別。ClickHouse的定位是分析性數據庫，而不是嚴格的關係型數據庫。3，IO方面，MySQL是行存儲，ClickHouse是列存儲，後者在count()這類操做自然有優點，同時，在IO方面，MySQL須要大量隨機IO，ClickHouse基本是順序IO。有人可能以爲上面的數據導入的時候，數據確定緩存在內存裏了，這個的確，可是ClickHouse基本上是順序IO。對IO基本沒有過高要求，固然，磁盤越快，上層處理越快，可是99%的狀況是，CPU先跑滿了（數據庫裏太少見了，大多數都是IO不夠用）。