Clickhouse的前世今生和優缺點

ClickHouse最初是爲 Yandex.Metrica 世界第二大Web分析平臺 而開發的。多年來一直作爲該系統的核心組件被該系統持續使用着。目前爲止,該系統在ClickHouse中有超過13萬億條記錄,並且每天超過200多億個事件被處理。它允許直接從原始數據中動態查詢並生成報告

聚合與非聚合數據

有一種流行的觀點認爲,想要有效的計算統計數據,必須要聚合數據,因爲聚合將降低數據量。
但是數據聚合是一個有諸多限制的解決方案,例如:

  1. 你必須提前知道用戶定義的報表的字段列表
  2. 用戶無法自定義報表
  3. 當聚合條件過多時,可能不會減少數據,聚合是無用的。
  4. 存在大量報表時,有太多的聚合變化(組合爆炸)
  5. 當聚合條件有非常大的基數時(如:url),數據量沒有太大減少(少於兩倍)
  6. 聚合的數據量可能會增長而不是收縮
  7. 用戶不會查看我們爲他生成的所有報告,大部分計算將是無用的
  8. 各種聚合可能違背了數據的邏輯完整性
  9. 如果我們直接使用非聚合數據而不進行任何聚合時,我們的計算量可能是減少的。

然而,相對於聚合中很大一部分工作被離線完成,在線計算需要儘快的完成計算,因爲用戶在等待結果

Yandex.Metrica 有一個專門用於聚合數據的系統,稱爲Metrage,它可以用作大部分報表。 從2009年開始,Yandex.Metrica還爲非聚合數據使用專門的OLAP數據庫,稱爲OLAPServer,它以前用於報表構建系統。 OLAPServer可以很好的工作在非聚合數據上,但是它有諸多限制,導致無法根據需要將其用於所有報表中。如,缺少對數據類型的支持(只支持數據),無法實時增量的更新數據(只能通過每天重寫數據完成)。OLAPServer不是一個數據庫管理系統,它只是一個數據庫。

爲了消除OLAPServer的這些侷限性,解決所有報表使用非聚合數據的問題,我們開發了ClickHouse數據庫管理系統。

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

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

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

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

數據壓縮

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

數據的磁盤存儲

許多的列式數據庫(如 SAP HANA, Google PowerDrill)只能在內存中工作,這種方式會造成比實際更多的設備預算。ClickHouse被設計用於工作在傳統磁盤上的系統,它提供每GB更低的存儲成本,但如果有可以使用SSD和內存,它也會合理的利用這些資源。

多核心並行處理

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

多服務器分佈式處理

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

支持SQL

ClickHouse支持基於SQL的聲明式查詢語言,該語言大部分情況下是與SQL標準兼容的。 支持的查詢包括 GROUP BY,ORDER BY,IN,JOIN以及非相關子查詢。 不支持窗口函數和相關子查詢。

向量引擎

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

實時的數據更新

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

索引

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

適合在線查詢

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

支持近似計算

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

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

支持數據複製和數據完整性

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

ClickHouse的缺點

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

更多文章可以關注工作號"數據專場"
在這裏插入圖片描述

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章