联机分析的列式数据库 clickHouse
? ? ? ? ? ? ??
ClickHouse是一個用于聯(lián)機分析(OLAP)的列式數(shù)據(jù)庫管理系統(tǒng)(DBMS)。
在傳統(tǒng)的行式數(shù)據(jù)庫系統(tǒng)中，數(shù)據(jù)按如下順序存儲：
| #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 | … | … | … | … | … |
處于同一行中的數(shù)據(jù)總是被物理的存儲在一起。
常見的行式數(shù)據(jù)庫系統(tǒng)有：MySQL、Postgres和MS SQL Server。
在列式數(shù)據(jù)庫系統(tǒng)中，數(shù)據(jù)按如下的順序存儲：
| 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 | … |
這些示例只顯示了數(shù)據(jù)的排列順序。來自不同列的值被單獨存儲，來自同一列的數(shù)據(jù)被存儲在一起。
常見的列式數(shù)據(jù)庫有：Vertica、 Paraccel (Actian Matrix，Amazon Redshift)、 Sybase IQ、 Exasol、 Infobright、 InfiniDB、 MonetDB (VectorWise， Actian Vector)、 LucidDB、 SAP HANA、 Google Dremel、 Google PowerDrill、 Druid、 kdb+。
不同的數(shù)據(jù)存儲方式適用不同的業(yè)務(wù)場景，數(shù)據(jù)訪問的場景包括：進行了何種查詢、多久查詢一次以及各類查詢的比例；每種類型的查詢(行、列和字節(jié))讀取多少數(shù)據(jù)；讀取數(shù)據(jù)和更新之間的關(guān)系；使用的數(shù)據(jù)集大小以及如何使用本地的數(shù)據(jù)集；是否使用事務(wù),以及它們是如何進行隔離的；數(shù)據(jù)的復(fù)制機制與數(shù)據(jù)的完整性要求；每種類型的查詢要求的延遲與吞吐量等等。
系統(tǒng)負載越高，依據(jù)使用場景進行定制化就越重要，并且定制將會變的越精細。沒有一個系統(tǒng)能夠同時適用所有不同的業(yè)務(wù)場景。如果系統(tǒng)適用于廣泛的場景，在負載高的情況下，要兼顧所有的場景，那么將不得不做出選擇。是要平衡還是要效率？
OLAP場景的關(guān)鍵特征?
絕大多數(shù)是讀請求
數(shù)據(jù)以相當大的批次(> 1000行)更新，而不是單行更新;或者根本沒有更新。
已添加到數(shù)據(jù)庫的數(shù)據(jù)不能修改。
對于讀取，從數(shù)據(jù)庫中提取相當多的行，但只提取列的一小部分。
寬表，即每個表包含著大量的列
查詢相對較少(通常每臺服務(wù)器每秒查詢數(shù)百次或更少)
對于簡單查詢，允許延遲大約50毫秒
列中的數(shù)據(jù)相對較小：數(shù)字和短字符串(例如，每個URL 60個字節(jié))
處理單個查詢時需要高吞吐量(每臺服務(wù)器每秒可達數(shù)十億行)
事務(wù)不是必須的
對數(shù)據(jù)一致性要求低
每個查詢有一個大表。除了他以外，其他的都很小。
查詢結(jié)果明顯小于源數(shù)據(jù)。換句話說，數(shù)據(jù)經(jīng)過過濾或聚合，因此結(jié)果適合于單個服務(wù)器的RAM中
很容易可以看出，OLAP場景與其他通常業(yè)務(wù)場景(例如,OLTP或K/V)有很大的不同， 因此想要使用OLTP或Key-Value數(shù)據(jù)庫去高效的處理分析查詢場景，并不是非常完美的適用方案。例如，使用OLAP數(shù)據(jù)庫去處理分析請求通常要優(yōu)于使用MongoDB或Redis去處理分析請求。
列式數(shù)據(jù)庫更適合OLAP場景的原因?
列式數(shù)據(jù)庫更適合于OLAP場景(對于大多數(shù)查詢而言，處理速度至少提高了100倍)，下面詳細解釋了原因(通過圖片更有利于直觀理解)：
行式
列式
看到差別了么？下面將詳細介紹為什么會發(fā)生這種情況。
輸入/輸出?
針對分析類查詢，通常只需要讀取表的一小部分列。在列式數(shù)據(jù)庫中你可以只讀取你需要的數(shù)據(jù)。例如，如果只需要讀取100列中的5列，這將幫助你最少減少20倍的I/O消耗。
由于數(shù)據(jù)總是打包成批量讀取的，所以壓縮是非常容易的。同時數(shù)據(jù)按列分別存儲這也更容易壓縮。這進一步降低了I/O的體積。
由于I/O的降低，這將幫助更多的數(shù)據(jù)被系統(tǒng)緩存。
例如，查詢?統(tǒng)計每個廣告平臺的記錄數(shù)量?需要讀取?廣告平臺ID?這一列，它在未壓縮的情況下需要1個字節(jié)進行存儲。如果大部分流量不是來自廣告平臺，那么這一列至少可以以十倍的壓縮率被壓縮。當采用快速壓縮算法，它的解壓速度最少在十億字節(jié)(未壓縮數(shù)據(jù))每秒。換句話說，這個查詢可以在單個服務(wù)器上以每秒大約幾十億行的速度進行處理。這實際上是當前實現(xiàn)的速度。
CPU?
由于執(zhí)行一個查詢需要處理大量的行，因此在整個向量上執(zhí)行所有操作將比在每一行上執(zhí)行所有操作更加高效。同時這將有助于實現(xiàn)一個幾乎沒有調(diào)用成本的查詢引擎。如果你不這樣做，使用任何一個機械硬盤，查詢引擎都不可避免的停止CPU進行等待。所以，在數(shù)據(jù)按列存儲并且按列執(zhí)行是很有意義的。
有兩種方法可以做到這一點：
向量引擎：所有的操作都是為向量而不是為單個值編寫的。這意味著多個操作之間的不再需要頻繁的調(diào)用，并且調(diào)用的成本基本可以忽略不計。操作代碼包含一個優(yōu)化的內(nèi)部循環(huán)。
代碼生成：生成一段代碼，包含查詢中的所有操作。
這是不應(yīng)該在一個通用數(shù)據(jù)庫中實現(xiàn)的，因為這在運行簡單查詢時是沒有意義的。但是也有例外，例如，MemSQL使用代碼生成來減少處理SQL查詢的延遲(只是為了比較，分析型數(shù)據(jù)庫通常需要優(yōu)化的是吞吐而不是延遲)。
請注意，為了提高CPU效率，查詢語言必須是聲明型的(SQL或MDX)， 或者至少一個向量(J，K)。查詢應(yīng)該只包含隱式循環(huán)，允許進行優(yōu)化。
總結(jié)
以上是生活随笔為你收集整理的联机分析的列式数据库 clickHouse的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 基于单TCP连接的高吞吐模型设计
- 下一篇： sql server和mysql的区别是