clickhouse

clickhouse

三豐 soft張三丰

Clickhouse簡介

ClickHouse是一個用於聯機分析(OLAP)的列式數據庫管理系統(DBMS)。

常見的列式數據庫有：Vertica、 Paraccel (Actian Matrix，Amazon Redshift)、 Sybase IQ、 Exasol、 Infobright、 InfiniDB、 MonetDB (VectorWise， Actian Vector)、 LucidDB、 SAP HANA、 Google Dremel、 Google PowerDrill、 Druid、 kdb+。

不一樣的存儲方式適合不一樣的場景，這裏的查詢場景包括：

•進行了哪些查詢
•多久查詢一次
•各種查詢的比例
•每種查詢讀取多少數據————行、列和字節
•讀取數據和寫入數據之間的關係
•使用的數據集大小以及如何使用本地的數據集
•是否使用事務,以及它們是如何進行隔離的
•數據的複製機制與數據的完整性要求
•每種類型的查詢要求的延遲與吞吐量
系統負載越高，根據使用場景進行定製化就越重要，而且定製將會變的越精細。沒有一個系統一樣適用於明顯不一樣的場景。若是系統適用於普遍的場景，在負載高的狀況下，全部的場景能夠會被公平但低效處理，或者高效處理一小部分場景。

優勢

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-> 將臨時表改爲正式表-> 刪除原數據表

架構對比

Hbase架構

Kudu架構

Clickhouse架構

綜上所示，Hbase和Kudu都是相似於Master-slave的架構而Clickhouse不存在Master結構，Clickhouse的每臺Server的地位都是等價的，是multi-master模式。不過Hbase和Clickhouse額外增長了一個Zookeeper做爲輔助的元數據存儲或者是log server等，而Kudu的元數據是Master管理的，爲了不server頻繁從Master讀取元數據，server會從Master獲取一份元數據到本地，可是會有元數據丟失的風險。