ClickHouse的學習與了解

什么是ClickHouse？

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

在傳統的行式數據庫系統中，數據按如下順序存儲：

Row	WatchID	JavaEnable	Title	GoodEvent	EventTime
#0	89354350662	1	Investor Relations	1	2016/5/18 5:19
#1	90329509958	0	Contact us	1	2016/5/18 8:10
#2	89953706054	1	Mission	1	2016/5/18 7:38
#N	…	…	…	…	…

處于同一行中的數據總是被物理的存儲在一起。

常見的行式數據庫系統有：MySQL、Postgres和MS SQL Server。

在列式數據庫系統中，數據按如下的順序存儲：

Row:	#0	#1	#2	#N
WatchID:	89354350662	90329509958	89953706054	…
JavaEnable:	1	0	1	…
Title:	Investor Relations	Contact us	Mission	…
GoodEvent:	1	1	1	…
EventTime:	2016/5/18 5:19	2016/5/18 8:10	2016/5/18 7:38	…

這些示例只顯示了數據的排列順序。來自不同列的值被單獨存儲，來自同一列的數據被存儲在一起。

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

不同的數據存儲方式適用不同的業務場景，數據訪問的場景包括：進行了何種查詢、多久查詢一次以及各類查詢的比例；每種類型的查詢(行、列和字節)讀取多少數據；讀取數據和更新之間的關系；使用的數據集大小以及如何使用本地的數據集；是否使用事務,以及它們是如何進行隔離的；數據的復制機制與數據的完整性要求；每種類型的查詢要求的延遲與吞吐量等等。

系統負載越高，依據使用場景進行定制化就越重要，并且定制將會變的越精細。沒有一個系統能夠同時適用所有不同的業務場景。如果系統適用于廣泛的場景，在負載高的情況下，要兼顧所有的場景，那么將不得不做出選擇。是要平衡還是要效率？

OLAP場景的關鍵特征

絕大多數是讀請求
數據以相當大的批次(> 1000行)更新，而不是單行更新;或者根本沒有更新。
已添加到數據庫的數據不能修改。
對于讀取，從數據庫中提取相當多的行，但只提取列的一小部分。
寬表，即每個表包含著大量的列
查詢相對較少(通常每臺服務器每秒查詢數百次或更少)
對于簡單查詢，允許延遲大約50毫秒
列中的數據相對較小：數字和短字符串(例如，每個URL 60個字節)
處理單個查詢時需要高吞吐量(每臺服務器每秒可達數十億行)
事務不是必須的
對數據一致性要求低
每個查詢有一個大表。除了他以外，其他的都很小。
查詢結果明顯小于源數據。換句話說，數據經過過濾或聚合，因此結果適合于單個服務器的RAM中

很容易可以看出，OLAP場景與其他通常業務場景(例如,OLTP或K/V)有很大的不同，因此想要使用OLTP或Key-Value數據庫去高效的處理分析查詢場景，并不是非常完美的適用方案。例如，使用OLAP數據庫去處理分析請求通常要優于使用MongoDB或Redis去處理分析請求。

列式數據庫更適合OLAP場景的原因

列式數據庫更適合于OLAP場景(對于大多數查詢而言，處理速度至少提高了100倍)，下面詳細解釋了原因(通過圖片更有利于直觀理解)：

行式
在這里插入圖片描述
采用行式存儲的好處是想查某行所有數據時，可以通過一次磁盤查找加順序讀取就可以全部獲取到。但是當想查所有數據的某列局部數據時，需要不停的查找，或者全表掃描才行，遍歷的很多數據都是為了最終結果的中間遍歷過程，是不需要的。

列式
在這里插入圖片描述
采用列式存儲的好處是，如需要查某列，只需要通過一次磁盤查找就把對應列全部獲取出來。

輸入/輸出

針對分析類查詢，通常只需要讀取表的一小部分列。在列式數據庫中你可以只讀取你需要的數據。例如，如果只需要讀取100列中的5列，這將幫助你最少減少20倍的I/O消耗。
由于數據總是打包成批量讀取的，所以壓縮是非常容易的。同時數據按列分別存儲這也更容易壓縮。這進一步降低了I/O的體積。
由于I/O的降低，這將幫助更多的數據被系統緩存。

例如，查詢?統計每個廣告平臺的記錄數量?需要讀取?廣告平臺ID?這一列，它在未壓縮的情況下需要1個字節進行存儲。如果大部分流量不是來自廣告平臺，那么這一列至少可以以十倍的壓縮率被壓縮。當采用快速壓縮算法，它的解壓速度最少在十億字節(未壓縮數據)每秒。換句話說，這個查詢可以在單個服務器上以每秒大約幾十億行的速度進行處理。這實際上是當前實現的速度。

CPU

由于執行一個查詢需要處理大量的行，因此在整個向量上執行所有操作將比在每一行上執行所有操作更加高效。同時這將有助于實現一個幾乎沒有調用成本的查詢引擎。如果你不這樣做，使用任何一個機械硬盤，查詢引擎都不可避免的停止CPU進行等待。所以，在數據按列存儲并且按列執行是很有意義的。

有兩種方法可以做到這一點：

向量引擎：所有的操作都是為向量而不是為單個值編寫的。這意味著多個操作之間的不再需要頻繁的調用，并且調用的成本基本可以忽略不計。操作代碼包含一個優化的內部循環。
代碼生成：生成一段代碼，包含查詢中的所有操作。

這是不應該在一個通用數據庫中實現的，因為這在運行簡單查詢時是沒有意義的。但是也有例外，例如，MemSQL使用代碼生成來減少處理SQL查詢的延遲(只是為了比較，分析型數據庫通常需要優化的是吞吐而不是延遲)。

請注意，為了提高CPU效率，查詢語言必須是聲明型的(SQL或MDX)，或者至少一個向量(J，K)。查詢應該只包含隱式循環，允許進行優化。

ClickHouse的特性

真正的列式數據庫管理系統

在一個真正的列式數據庫管理系統中，除了數據本身外不應該存在其他額外的數據。這意味著為了避免在值旁邊存儲它們的長度?number?，你必須支持固定長度數值類型。例如，10億個UInt8類型的數據在未壓縮的情況下大約消耗1GB左右的空間，如果不是這樣的話，這將對CPU的使用產生強烈影響。即使是在未壓縮的情況下，緊湊的存儲數據也是非常重要的，因為解壓縮的速度主要取決于未壓縮數據的大小。

這是非常值得注意的，因為在一些其他系統中也可以將不同的列分別進行存儲，但由于對其他場景進行的優化，使其無法有效的處理分析查詢。例如： HBase，BigTable，Cassandra，HyperTable。在這些系統中，你可以得到每秒數十萬的吞吐能力，但是無法得到每秒幾億行的吞吐能力。

需要說明的是，ClickHouse不單單是一個數據庫，它是一個數據庫管理系統。因為它允許在運行時創建表和數據庫、加載數據和運行查詢，而無需重新配置或重啟服務。

數據壓縮

在一些列式數據庫管理系統中(例如：InfiniDB CE 和 MonetDB) 并沒有使用數據壓縮。但是, 若想達到比較優異的性能，數據壓縮確實起到了至關重要的作用。

除了在磁盤空間和CPU消耗之間進行不同權衡的高效通用壓縮編解碼器之外，ClickHouse還提供針對特定類型數據的專用編解碼器，這使得ClickHouse能夠與更小的數據庫(如時間序列數據庫)競爭并超越它們。

數據的磁盤存儲

許多的列式數據庫(如 SAP HANA, Google PowerDrill)只能在內存中工作，這種方式會造成比實際更多的設備預算。

ClickHouse被設計用于工作在傳統磁盤上的系統，它提供每GB更低的存儲成本，但如果可以使用SSD和內存，它也會合理的利用這些資源。

多核心并行處理

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

多服務器分布式處理

上面提到的列式數據庫管理系統中，幾乎沒有一個支持分布式的查詢處理。在ClickHouse中，數據可以保存在不同的shard上，每一個shard都由一組用于容錯的replica組成，查詢可以并行地在所有shard上進行處理。這些對用戶來說是透明的

支持SQL
ClickHouse支持一種基于SQL的聲明式查詢語言，它在許多情況下與ANSI SQL標準相同。

支持的查詢GROUP BY, ORDER BY, FROM, JOIN, IN以及非相關子查詢。

相關(依賴性)子查詢和窗口函數暫不受支持，但將來會被實現。

向量引擎

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

實時的數據更新

ClickHouse支持在表中定義主鍵。為了使查詢能夠快速在主鍵中進行范圍查找，數據總是以增量的方式有序的存儲在MergeTree中。因此，數據可以持續不斷地高效的寫入到表中，并且寫入的過程中不會存在任何加鎖的行為。

索引

按照主鍵對數據進行排序，這將幫助ClickHouse在幾十毫秒以內完成對數據特定值或范圍的查找。

適合在線查詢

在線查詢意味著在沒有對數據做任何預處理的情況下以極低的延遲處理查詢并將結果加載到用戶的頁面中。

支持近似計算

ClickHouse提供各種各樣在允許犧牲數據精度的情況下對查詢進行加速的方法：

用于近似計算的各類聚合函數，如：distinct values, medians, quantiles
基于數據的部分樣本進行近似查詢。這時，僅會從磁盤檢索少部分比例的數據。
不使用全部的聚合條件，通過隨機選擇有限個數據聚合條件進行聚合。這在數據聚合條件滿足某些分布條件下，在提供相當準確的聚合結果的同時降低了計算資源的使用。

自適應連接算法

ClickHouse支持自定義JOIN多個表，它更傾向于散列連接算法，如果有多個大表，則使用合并-連接算法

支持數據復制和數據完整性

ClickHouse使用異步的多主復制技術。當數據被寫入任何一個可用副本后，系統會在后臺將數據分發給其他副本，以保證系統在不同副本上保持相同的數據。在大多數情況下ClickHouse能在故障后自動恢復，在一些少數的復雜情況下需要手動恢復。

更多信息，參見數據復制。

角色的訪問控制

ClickHouse使用SQL查詢實現用戶帳戶管理，并允許角色的訪問控制，類似于ANSI SQL標準和流行的關系數據庫管理系統。

限制

沒有完整的事務支持。
缺少高頻率，低延遲的修改或刪除已存在數據的能力。僅能用于批量刪除或修改數據，但這符合 GDPR。
稀疏索引使得ClickHouse不適合通過其鍵檢索單行的點查詢。

ClickHouse的性能

根據Yandex的內部測試結果，ClickHouse表現出了比同類可比較產品更優的性能。你可以在這里查看具體的測試結果。

許多其他的測試也證實這一點。你可以使用互聯網搜索到它們，或者你也可以從我們收集的部分相關連接中查看。

單個大查詢的吞吐量

吞吐量可以使用每秒處理的行數或每秒處理的字節數來衡量。如果數據被放置在page cache中，則一個不太復雜的查詢在單個服務器上大約能夠以2-10GB／s（未壓縮）的速度進行處理（對于簡單的查詢，速度可以達到30GB／s）。如果數據沒有在page cache中的話，那么速度將取決于你的磁盤系統和數據的壓縮率。例如，如果一個磁盤允許以400MB／s的速度讀取數據，并且數據壓縮率是3，則數據的處理速度為1.2GB/s。這意味著，如果你是在提取一個10字節的列，那么它的處理速度大約是1-2億行每秒。

對于分布式處理，處理速度幾乎是線性擴展的，但這受限于聚合或排序的結果不是那么大的情況下。

處理短查詢的延遲時間

如果一個查詢使用主鍵并且沒有太多行(幾十萬)進行處理，并且沒有查詢太多的列，那么在數據被page cache緩存的情況下，它的延遲應該小于50毫秒(在最佳的情況下應該小于10毫秒)。否則，延遲取決于數據的查找次數。如果你當前使用的是HDD，在數據沒有加載的情況下，查詢所需要的延遲可以通過以下公式計算得知：查找時間（10 ms） * 查詢的列的數量 * 查詢的數據塊的數量。

處理大量短查詢的吞吐量

在相同的情況下，ClickHouse可以在單個服務器上每秒處理數百個查詢（在最佳的情況下最多可以處理數千個）。但是由于這不適用于分析型場景。因此我們建議每秒最多查詢100次。

數據的寫入性能

我們建議每次寫入不少于1000行的批量寫入，或每秒不超過一個寫入請求。當使用tab-separated格式將一份數據寫入到MergeTree表中時，寫入速度大約為50到200MB/s。如果您寫入的數據每行為1Kb，那么寫入的速度為50，000到200，000行每秒。如果您的行更小，那么寫入速度將更高。為了提高寫入性能，您可以使用多個INSERT進行并行寫入，這將帶來線性的性能提升。