day2-什麼是ClickHouse

14th鐵人賽

peter279k

2022-09-16 10:03:57

5607 瀏覽

分享至

前言

在上一章節中，我們了解了時序資料的定義與特性，還有各式儲存技術方式來儲存時序資料的資料庫，從本章節開始，介紹什麼是ClickHouse與其特性。

什麼是ClickHouse

ClickHouse是一個列為導向(column-oriented)儲存的資料庫系統(database management system, DBMS)，並用來於OLAP(online analytical processing)線上分析處理的查詢。
ClickHouse是由俄羅斯IT公司Yandex為Yandex.Metrica網路分析服務開發的，且ClickHouse允許分析即時更新的資料，以及該資料庫系統以高效能為目標，這個專案是在2016年6月發布的Apache許可證(License)下的開源軟體。

在一般常見的行為導向(row-oriented)儲存的資料庫系統，資料會依照下列的示意圖方式來儲存：

row-oriented-store

換句話說，所有的有關於此行的值都會依序地儲存在硬碟上，這類的資料庫有：MySQL、PostgreSQL與MS SQL Server。

在列式為導向儲存的資料庫系統中，資料會依照下列的示意圖方式進行儲存：

column-oriented-store

上述的資料範例只會顯示出資料是依序安排好在各個欄位名稱中，這些值被分開儲存在各個不同的列中，而且資料屬於同一個列中會儲存在一起。

以列為導向儲存的這類型資料庫系統有：Vertica、Paraccel (Actian Matrix and Amazon Redshift)、Sybase IQ、Exasol、Infobright、InfiniDB、MonetDB (VectorWise and Actian Vector)、LucidDB、SAP HANA、Google Dremel、Google PowerDrill、Druid以及kdb+.

對於上述儲存資料的不同方法，可以合適的對應到不同的情境。資料存取的情境取決於使用什麼樣的查詢，以及此查詢的頻繁程度，還有查詢資料量的比重；像是有多少的資料在每個類型的查詢中被讀取出來。如讀取出多少行rows、列columns以及多少大小的位元組bytes等。

需要考量的點如下：

讀取與更新資料之間的關聯性，資料運作的大小還有如何使用這些資料？
是否會用到交易的機制、資料是否需要隔離？
資料有沒有複製(data repliaction)、邏輯的完整性(logical integrity)等需求？
還有對於每種類型的資料查詢的延遲(latency)與寫入資料吞吐(throughput)速度等需求？

我們還要考慮到系統的負載，以及重要的是需要客製化系統並符合使用的需求情境，因為沒有一個系統可以顯著地適合每個不同的情境。如果有這樣的系統並可以合適並可以符合多個不同的情境，則會讓系統運作處在高負載的情形，以及系統將會讓所有的情境都處理的較為差勁或是只有幾種可能的情境運作的較佳。

OLAP重要的特性情境

下面列出幾個OLAP重要的特性情境：

在絕大多數的請求中都是讀取資料為主。
資料可以在超過1000筆的行資料的批次大小中進行更新，而且不是逐一針對單一的行的資料進行更新，或是根本就不可以進行資料更新的動作。
對於資料的讀取，可以從資料庫中讀取出很大筆的行資料。但是，列的欄位是只有小的子集，即指定的欄位很少。
資料表是廣泛的，意思是在資料表中會包含非常多的列欄位。
資料查詢時間應該要快速。一般來說，在單一的伺服器上進行數以千計的查詢或是每個查詢回應時間小於1秒。
對於簡單的資料查詢，例如：可以接受查詢回應的時間為50微秒。
列的值應要較小，像是數字和較短的字串。舉例來說，每個網址連結URL應只有60的位元組(bytes)大小。
在處理單一的查詢時候，需要有高的吞吐量(throughput)，可以到每台伺服器每秒處理數十億以上的行資料。
資料庫交易的特性是不需要的。
一個查詢結果是顯著地比來源資料大小來的小，換句話說，資料是可以篩選與聚合的，所以查詢結果對於在單一伺服器的記憶體使用率是良好的。

我們可以輕易的從上述的OLAP的重要情境看到，OLAP情境與其他流行的情境；如OLTP或是鍵-值存取有很大的不同。如果要有良好的查詢效能，嘗試著使用OLTP或是鍵-值的資料庫作為處理線上分析的查詢是不適合的。

舉例來說，如果我們使用了MongoDB或是Redis等這類的資料庫來做處理分析的查詢，則我們將會得到比OLAP類型資料庫還差勁的效能。

為什麼列式儲存資料庫會在OLAP情境中良好的運作？

Input/Ouptut討論

對於一個分析的資料查詢來說，只會有一小部分的資料表欄位被讀取到，在列式導向儲存的資料庫中，我們可以只讀取我們需要的資料出來即可。
- 舉例來說，如果我們需要在100的欄位中讀取5個欄位出來，則我們可以節省約20倍的硬碟的I/O量。
自從資料從封包中進行讀取出來，這將會較容易進行資料壓縮，資料在列中也較容易進行壓縮，而且這可以更進一步的解少I/O的大小。
因為節省了I/O大小，因此較多資料可以儲存在系統快取中。

舉例來說，在一個平台上計算有多少比紀錄的查詢需要讀取一個平台ID的欄位，這將會占用未壓縮的1 byte大小，如果部分的流量不是來自於此平台，我們可以期望此列至少壓縮10倍。當使用了快速壓縮的演算法，資料壓縮是可能在以每秒至少幾GB(gigabytes)的未壓縮數據的速度。換句話說，這個查詢可以在單一伺服器上每秒處理約數十億行的資料，這個處理速度可以在實際情形中達成。

CPU討論

當執行一個查詢時，需要處理非常多個行數，但是我們可以透過向量處理器的方式來幫助我們分配到各個操作來處理多個行數，而不是針對分開的行數進行處理；或者是實做了查詢引擎，這樣一來就幾乎沒有分配的成本。如果我們不按這上述的方式做的話，用任何一個不錯的硬碟子系統或是查詢直譯器，都會無可避免地造成CPU的停頓，增加查詢處理的時間。因此將資料儲存在列式導向的資料庫並並處理這些資料是合理的，當要處理的時候，會針對各個列進行處理。

以下有兩種方法可以來做到上述處理查詢的事情：

向量處理器，所有的動作都是在向量進行，而不是針對分開的值來一個個的處理。這意思是我們不需要頻繁的呼叫動作且分配的成本是非常小的。運作的指令包含了一個優化的內部循環機制來進行。
CPU指令產生器，這些指令是為了查詢而產生的，且會在間接地在查詢中被呼叫來執行。

上述的這些事情無法在一般的關聯式資料庫完成，因為當執行簡易的查詢時，這些情形是不太需要的。然而，有些例外的情形。舉例來說，MemSQL在執行與處理查詢語句時，使用了指令產生器來減少查詢延遲的時間；MemSQL與分析類型的資料庫管理比較，分析類型的資料庫系統需要的是優化的吞吐量throughput，即資料處理的速度，而不是延遲的時間。

我們注意到對於CPU的效能優化，查詢語言需要先被宣告好，像是SQL，查詢應該只包含了隱含迴圈，並允許可以對其優化。