ClickHouse是一個用於聯機分析(OLAP)的列式數據庫管理系統(DBMS)。
官網中文文檔 https://clickhouse.tech/docs/zh/
在傳統的行式數據庫系統中，數據按如下順序存儲：
| Row | WatchID | JavaEnable | Title | GoodEvent | EventTime |
| #0 | 89354350662 | 1 | Investor Relations | 1 | 2016-05-18 05:19:20 |
| #1 | 90329509958 | 0 | Contact us | 1 | 2016-05-18 08:10:20 |
| #2 | 89953706054 | 1 | Mission | 1 | 2016-05-18 07:38:00 |
| #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-05-18 05:19:20 | 2016-05-18 08:10:20 | 2016-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+。
不同的存儲方式適合不同的場景，這里的查詢場景包括： 進行了哪些查詢，多久查詢一次以及各類查詢的比例； 每種查詢讀取多少數據————行、列和字節；讀取數據和寫入數據之間的關系；使用的數據集大小以及如何使用本地的數據集；是否使用事務,以及它們是如何進行隔離的；數據的復制機制與數據的完整性要求；每種類型的查詢要求的延遲與吞吐量等等。
系統負載越高，根據使用場景進行定制化就越重要，並且定制將會變的越精細。沒有一個系統同樣適用於明顯不同的場景。如果系統適用於廣泛的場景，在負載高的情況下，所有的場景可以會被公平但低效處理，或者高效處理一小部分場景。
就越重要，並且定制將會變的越精細。沒有一個系統同樣適用於明顯不同的場景。如果系統適用於廣泛的場景，在負載高的情況下，所有的場景可以會被公平但低效處理，或者高效處理一小部分場景。
OLAP場景的關鍵特征¶
- 大多數是讀請求
- 數據總是以相當大的批(> 1000 rows)進行寫入
- 不修改已添加的數據
- 每次查詢都從數據庫中讀取大量的行，但是同時又僅需要少量的列
- 寬表，即每個表包含着大量的列
- 較少的查詢(通常每台服務器每秒數百個查詢或更少)
- 對於簡單查詢，允許延遲大約50毫秒
- 列中的數據相對較小： 數字和短字符串(例如，每個URL 60個字節)
- 處理單個查詢時需要高吞吐量（每個服務器每秒高達數十億行）
- 事務不是必須的
- 對數據一致性要求低
- 每一個查詢除了一個大表外都很小
- 查詢結果明顯小於源數據，換句話說，數據被過濾或聚合后能夠被盛放在單台服務器的內存中
很容易可以看出，OLAP場景與其他流行場景(例如,OLTP或K/V)有很大的不同， 因此想要使用OLTP或Key-Value數據庫去高效的處理分析查詢是沒有意義的，例如，使用OLAP數據庫去處理分析請求通常要優於使用MongoDB或Redis去處理分析請求。
列式數據庫更適合OLAP場景的原因¶
列式數據庫更適合於OLAP場景(對於大多數查詢而言，處理速度至少提高了100倍)，下面詳細解釋了原因(通過圖片更有利於直觀理解)：
行式
列式
看到差別了么？下面將詳細介紹為什么會發生這種情況。
Input/output¶
- 針對分析類查詢，通常只需要讀取表的一小部分列。在列式數據庫中你可以只讀取你需要的數據。例如，如果只需要讀取100列中的5列，這將幫助你最少減少20倍的I/O消耗。
- 由於數據總是打包成批量讀取的，所以壓縮是非常容易的。同時數據按列分別存儲這也更容易壓縮。這進一步降低了I/O的體積。
- 由於I/O的降低，這將幫助更多的數據被系統緩存。
例如，查詢“統計每個廣告平台的記錄數量”需要讀取“廣告平台ID”這一列，它在未壓縮的情況下需要1個字節進行存儲。如果大部分流量不是來自廣告平台，那么這一列至少可以以十倍的壓縮率被壓縮。當采用快速壓縮算法，它的解壓速度最少在十億字節(未壓縮數據)每秒。換句話說，這個查詢可以在單個服務器上以每秒大約幾十億行的速度進行處理。這實際上是當前實現的速度。
示例
$ clickhouse-client
ClickHouse client version 0.0.52053.
Connecting to localhost:9000.
Connected to ClickHouse server version 0.0.52053.
:) SELECT CounterID, count() FROM hits GROUP BY CounterID ORDER BY count() DESC LIMIT 20
SELECT
CounterID,
count()
FROM hits
GROUP BY CounterID
ORDER BY count() DESC
LIMIT 20
┌─CounterID─┬──count()─┐
│ 114208 │ 56057344 │
│ 115080 │ 51619590 │
│ 3228 │ 44658301 │
│ 38230 │ 42045932 │
│ 145263 │ 42042158 │
│ 91244 │ 38297270 │
│ 154139 │ 26647572 │
│ 150748 │ 24112755 │
│ 242232 │ 21302571 │
│ 338158 │ 13507087 │
│ 62180 │ 12229491 │
│ 82264 │ 12187441 │
│ 232261 │ 12148031 │
│ 146272 │ 11438516 │
│ 168777 │ 11403636 │
│ 4120072 │ 11227824 │
│ 10938808 │ 10519739 │
│ 74088 │ 9047015 │
│ 115079 │ 8837972 │
│ 337234 │ 8205961 │
└───────────┴──────────┘
20 rows in set. Elapsed: 0.153 sec. Processed 1.00 billion rows, 4.00 GB (6.53 billion rows/s., 26.10 GB/s.)
:)CPU¶
由於執行一個查詢需要處理大量的行，因此在整個向量上執行所有操作將比在每一行上執行所有操作更加高效。同時這將有助於實現一個幾乎沒有調用成本的查詢引擎。如果你不這樣做，使用任何一個機械硬盤，查詢引擎都不可避免的停止CPU進行等待。所以，在數據按列存儲並且按列執行是很有意義的。
有兩種方法可以做到這一點：
-
向量引擎：所有的操作都是為向量而不是為單個值編寫的。這意味着多個操作之間的不再需要頻繁的調用，並且調用的成本基本可以忽略不計。操作代碼包含一個優化的內部循環。
-
代碼生成：生成一段代碼，包含查詢中的所有操作。
這是不應該在一個通用數據庫中實現的，因為這在運行簡單查詢時是沒有意義的。但是也有例外，例如，MemSQL使用代碼生成來減少處理SQL查詢的延遲(只是為了比較，分析型數據庫通常需要優化的是吞吐而不是延遲)。
請注意，為了提高CPU效率，查詢語言必須是聲明型的(SQL或MDX)， 或者至少一個向量(J，K)。 查詢應該只包含隱式循環，允許進行優化。