世界熱點！行式數據庫系統中的列式存儲——Clickhouse

1. Clickhouse的簡介

ClickHouse是俄羅斯的Yandex于2016年開源的列式存儲數據庫（DBMS），使用 C++語言編寫，主要用于在線分析處理查詢（OLAP），能夠使用SQL查詢實時生成分析數據報告。

(資料圖)

2. Clickhouse的列式存儲

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

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

RowWatchIDJavaEnableTitleGoodEventEventTime

#0893543506621Investor Relations12016/5/18 5:19

#1903295099580Contact us12016/5/18 8:10

#2899537060541Mission12016/5/18 7:38

#N……………

處于同一行中的數據總是被物理的存儲在一起。常見的行式數據庫系統有： MySQL、Postgres、oracle和MS SQL Server。

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

Row:#0#1#2#N

WatchID:893543506629032950995889953706054…

JavaEnable:101…

Title:Investor RelationsContact usMission…

GoodEvent:111…

EventTime:2016-05-18 05:19:202016-05-18 08:10:202016-05-18 07:38:00…

該示例中只展示了數據在列式數據庫中數據的排列順序。對于存儲而言，列式數據庫總是將同一列的數據存儲在一起，不同列的數據也總是分開存儲。

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

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

系統負載越高，根據使用場景進行定制化就越重要，并且定制將會變的越精細。沒有一個系統同樣適用于明顯不同的場景。如果系統適用于廣泛的場景，在負載高的情況下，所有的場景可以會被公平但低效處理，或者高效處理一小部分場景。

列式儲存的好處：

對于列的聚合，計數，求和等統計操作原因優于行式存儲。由于某一列的數據類型都是相同的，針對于數據存儲更容易進行數據壓縮，每一列選擇更優的數據壓縮算法，大大提高了數據的壓縮比重。由于數據壓縮比更好，一方面節省了磁盤空間，另一方面對于 cache 也有了更大的發揮空間。

3. Clickhouse的SQL引擎和向量化

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

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

4. Clickhouse的吞吐能力

ClickHouse 采用類LSM Tree的結構，數據寫入后定期在后臺Compaction。通過類 LSM tree的結構，ClickHouse 在數據導入時全部是順序 append 寫，寫入后數據段不可更改，在后臺compaction 時也是多個段 merge sort 后順序寫回磁盤。順序寫的特性，充分利用了磁盤的吞吐能力，即便在 HDD 上也有著優異的寫入性能。 ??官方公開 benchmark 測試顯示能夠達到 50MB-200MB/s 的寫入吞吐能力，按照每行100Byte 估算，大約相當于 50W-200W 條/s 的寫入速度。

5. 數據分區和線程級并行

ClickHouse 將數據劃分為多個 partition，每個 partition 再進一步劃分為多個 index granularity(索引粒度)，然后通過多個CPU核心分別處理其中的一部分來實現并行數據處理。在這種設計下，單條Query就能利用整機所有CPU。極致的并行處理能力，極大的降低了查詢延時。 ??所以，ClickHouse即使對于大量數據的查詢也能夠化整為零平行處理。但是有一個弊端就是對于單條查詢使用多cpu，就不利于同時并發多條查詢。所以對于高 qps 的查詢業務，ClickHouse 并不是強項。

6. 性能數據

數據壓縮數據壓縮方面，Sparkql、Impala、Presto均采用的是hive元數據，hive數據100G上傳之后顯示為96.3G(.dat數據格式)，壓縮比0.963；hawq壓縮后數據大小為68.2G(.dat格式)，壓縮比：0.682；clickhouse采用自己默認格式42G；greenplum未使用壓縮，數據存儲大小為98G。性能測試

多表關聯查詢

單表查詢性能

ClickHouse 作為目前所有開源MPP計算框架中計算速度最快的，它在做多列的表，同時行數很多的表的查詢時，性能是很讓人興奮的，但是在做多表的join時，它的性能是不如單寬表查詢的。性能測試結果表明ClickHouse在單表查詢方面表現出很大的性能優勢，但是在多表查詢中性能卻比較差，不如presto和impala、hawq的效果好。

更多內容關注公眾號