什么是ClickHouse?

ClickHouse 是面向 OLAP 的分布式列式 DBMS.

在“正乘栌”的面向行的DBMS中撮弧，數(shù)據(jù)按順序進(jìn)行存儲(chǔ)：

5123456789123456789? ? 1? ? ? Eurobasket - Greece - Bosnia and Herzegovina - example.com? ? ? 1? ? ? 2011-09-01 01:03:02? ? 6274717? 1294101174? ? ? 11409? 612345678912345678? ? ? 0? ? ? 33? ? ? 6? ? ? http://www.example.com/basketball/team/123/match/456789.html http://www.example.com/basketball/team/123/match/987654.html? ? ? 0? ? ? 1366? ? 768? ? 32? ? ? 10? ? ? 3183? ? ? 0? ? ? 0? ? ? 13? ? ? 0\0? ? 1? ? ? 1? ? ? 0? ? ? 0? ? ? ? ? ? ? ? ? ? ? 2011142 -1? ? ? 0? ? ? ? ? ? ? 0? ? ? 01321? ? 613? ? 660? ? 2011-09-01 08:01:17? ? 0? ? ? 0? ? ? 0? ? ? 0? ? ? utf-8? 1466? ? 0? ? ? 0? ? ? 0? ? ? 5678901234567890123? ? ? ? ? ? ? 277789954? ? ? 0? ? ? 0? ? ? 0? ? ? 0? ? ? 0

5234985259563631958? ? 0? ? ? Consulting, Tax assessment, Accounting, Law? ? ? 1? ? ? 2011-09-01 01:03:02? ? 6320881? 2111222333? ? ? 213? ? 6458937489576391093? ? 0? ? ? 3? ? ? 2? ? ? http://www.example.ru/? ? ? ? 0? ? ? 800? ? 600? ? ? 16? ? ? 10? ? ? 2? ? ? 153.1? 0? ? ? 0? ? ? 10? ? ? 63? ? ? 1? ? ? 1? ? ? 0? ? ? 0? ? ? ? ? ? ? ? ? ? ? 2111678 000? ? ? 0? ? ? 588? ? 368? ? 240? ? 2011-09-01 01:03:17? ? 4? ? ? 0? ? ? 60310? 0? ? ? windows-1251? ? 1466? ? 0? ? ? 000? ? ? ? ? ? ? 778899001? ? ? 0? ? ? 0? ? ? 0? ? ? 0? ? ? 0

...

換句話說(shuō)迷扇，與一行相關(guān)的所有值都被存儲(chǔ)在一起拆吆。面向行的DBMS主要有MySQL轻抱，Postgres骗村，MS SQL Server等等嫌褪。

在面向列的DBMS中，數(shù)據(jù)存儲(chǔ)如下：

WatchID:5385521489354350662? ? 5385521490329509958? ? 5385521489953706054? ? 5385521490476781638? ? 5385521490583269446? ? 5385521490218868806? ? 5385521491437850694? 5385521491090174022? ? ? 5385521490792669254? ? 5385521490420695110? ? 5385521491532181574? ? 5385521491559694406? ? 5385521491459625030? ? 5385521492275175494? 5385521492781318214? ? ? 5385521492710027334? ? 5385521492955615302? ? 5385521493708759110? ? 5385521494506434630? ? 5385521493104611398

JavaEnable:1? ? ? 0? ? ? 1? ? ? 0? ? ? 0? ? ? 0? ? ? 1? ? ? 0? ? ? 1? ? ? 1? ? ? 1? ? ? 1? ? ? 1? ? ? 1? ? ? 0? ? ? 1? ? ? 0? ? ? 0? ? ? 1? ? ? 1

Title:Yandex? Announcements - Investor Relations - Yandex? ? Yandex — Contact us — Moscow? ? Yandex — Mission? ? ? ? Ru? ? ? Yandex — History — History of Yandex? ? Yandex Financial Releases - Investor Relations - Yandex Yandex — Locations? ? ? Yandex Board of Directors - Corporate Governance - Yandex? ? ? Yandex — Technologies

GoodEvent:1? ? ? 1? ? ? 1? ? ? 1? ? ? 1? ? ? 1? ? ? 1? ? ? 1? ? ? 1? ? ? 1? ? ? 1? ? ? 1? ? ? 1? ? ? 1? ? ? 1? ? ? 1? ? ? 1? ? ? 1? ? ? 1? ? ? 1

EventTime:2016-05-18 05:19:20? ? 2016-05-18 08:10:20? ? 2016-05-18 07:38:00? ? 2016-05-18 01:13:08? ? 2016-05-18 00:04:06? ? 2016-05-18 04:21:30? ? 2016-05-18 00:34:16? ? 2016-05-18 07:35:49? ? 2016-05-18 11:41:59? ? 2016-05-18 01:13:32...

這些示例僅顯示數(shù)據(jù)排列的順序胚股。不同列的值分開(kāi)存儲(chǔ)笼痛，同一列的數(shù)據(jù)一起存儲(chǔ)。例如琅拌，面向列的DBMS：Vertica缨伊，Paraccel（Actian Matrix）（Amazon Redshift），Sybase IQ进宝，Exasol刻坊，Infobright，InfiniDB即彪，MonetDB（VectorWise）（Actian Vector）紧唱，LucidDB，SAP HANA隶校，Google Dremel漏益，Google PowerDrill，Druid 深胳，kdb +等绰疤。

存儲(chǔ)數(shù)據(jù)的不同存儲(chǔ)順序更適合于不同的應(yīng)用場(chǎng)景。數(shù)據(jù)訪問(wèn)場(chǎng)景指的是執(zhí)行什么查詢舞终，多長(zhǎng)時(shí)間查詢轻庆，每種類(lèi)型的查詢讀取多少數(shù)據(jù) - 行癣猾，列和字節(jié);寫(xiě)取和更新數(shù)據(jù)之間的關(guān)系;數(shù)據(jù)的大小以及它在本地的使用情況;是否使用交易處理，以及它們是如何隔離的;數(shù)據(jù)同步和邏輯完整性的要求;每類(lèi)查詢的延遲和吞吐量要求等等余爆。

系統(tǒng)上的負(fù)載越高纷宇，場(chǎng)景化的系統(tǒng)定制就越重要，定制化就越具體蛾方。沒(méi)有一個(gè)系統(tǒng)能夠適用于截然不同的應(yīng)用場(chǎng)景像捶。如果一個(gè)系統(tǒng)可以適應(yīng)多種場(chǎng)景，那么在高負(fù)載情況下桩砰，系統(tǒng)處理所有場(chǎng)景表現(xiàn)都會(huì)很差拓春，或者僅其中一種場(chǎng)景表現(xiàn)良好。

對(duì)于OLAP（聯(lián)機(jī)分析處理）方案亚隅，將會(huì)有如下幾種應(yīng)用場(chǎng)景：

- 絕大多數(shù)請(qǐng)求是以讀為主硼莽。

- 數(shù)據(jù)以相當(dāng)大的批次（> 1000行）進(jìn)行更新，而不是單行更新;或者根本不更新煮纵。

- 數(shù)據(jù)被添加到數(shù)據(jù)庫(kù)懂鸵，基本不怎么修改。

- 對(duì)于讀取行疏，大量的數(shù)據(jù)從數(shù)據(jù)庫(kù)中抽取出來(lái)矾瑰，但只有列的一個(gè)子集。

- 表是“寬的”隘擎，這意味著它們包含大量的列。

- 查詢相對(duì)較少（通常每臺(tái)服務(wù)器數(shù)百個(gè)查詢或更少）凉夯。

- 對(duì)于簡(jiǎn)單的查詢货葬，允許大約50 ms的延遲。

- 列值相當(dāng)小 - 數(shù)字和短字符串（例如劲够，每個(gè)URL 60個(gè)字節(jié)）震桶。

- 處理單個(gè)查詢時(shí)需要高吞吐量（每臺(tái)服務(wù)器每秒高達(dá)數(shù)十億行）。

- 無(wú)事務(wù)處理征绎。

- 數(shù)據(jù)一致性要求低- 每個(gè)查詢有一個(gè)大表蹲姐，其他所有的表都是小表。

- 查詢結(jié)果顯著小于源數(shù)據(jù)人柿。也就是說(shuō)柴墩，數(shù)據(jù)被過(guò)濾或聚合。結(jié)果可以放在單個(gè)服務(wù)器的內(nèi)存中凫岖。

很容易看出江咳，OLAP方案與其他常見(jiàn)方案（如OLTP或Key-Value訪問(wèn)）有很大不同。所以哥放，如果你想獲得不錯(cuò)的表現(xiàn)歼指，嘗試使用OLTP或Key-Value DB來(lái)處理分析查詢是沒(méi)有意義的爹土。例如，如果您嘗試使用MongoDB或Elliptics進(jìn)行分析踩身，與OLAP數(shù)據(jù)庫(kù)相比胀茵，您的性能會(huì)很差。

面向列的數(shù)據(jù)庫(kù)更適合于OLAP方案（對(duì)于大多數(shù)查詢挟阻，處理速度至少提高了100倍）琼娘，原因如下：

1.對(duì)于I/O

1.1 對(duì)于分析查詢，只需要讀取少量的列赁濒。在面向列的數(shù)據(jù)庫(kù)中轨奄，您只能讀取所需的數(shù)據(jù)。例如拒炎，如果您需要100列中的5列挪拟，則I/O可能會(huì)減少20倍。

1.2 由于數(shù)據(jù)是以數(shù)據(jù)包的形式讀取的击你，因此壓縮比較容易玉组。列中的數(shù)據(jù)也更容易壓縮。這進(jìn)一步減少了I/O量丁侄。

1.3 由于減少的I/O惯雳，更多的數(shù)據(jù)適合在系統(tǒng)緩存中。

例如鸿摇，查詢“統(tǒng)計(jì)每個(gè)廣告平臺(tái)的記錄數(shù)量”需要讀取一個(gè)“廣告平臺(tái)ID”列石景，其占用1個(gè)未壓縮字節(jié)。如果大多數(shù)流量不是來(lái)自廣告平臺(tái)拙吉，那么您可以期望至少有10倍的壓縮比潮孽。當(dāng)使用快速壓縮算法時(shí)，數(shù)據(jù)解壓縮速度可以達(dá)到每秒至少幾千兆字節(jié)的未壓縮數(shù)據(jù)筷黔。換句話說(shuō)往史，這個(gè)查詢可以在一臺(tái)服務(wù)器上以每秒大約幾十億行的速度處理。這個(gè)速度實(shí)際上是在實(shí)踐中是容易實(shí)現(xiàn)的佛舱。

milovidov@████████.yandex.ru:~$ 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.)

:)

2.對(duì)于CPU

由于執(zhí)行查詢需要處理大量的行椎例，因此它有助于為整個(gè)向量而不是單獨(dú)的行指派所有操作，或者實(shí)現(xiàn)查詢引擎请祖，以便沒(méi)有指派成本订歪。如果你不這樣做，任何半象限的磁盤(pán)子系統(tǒng)损拢，查詢解釋器不可避免地中斷CPU陌粹。將數(shù)據(jù)存儲(chǔ)在列中并在可能的情況下按列處理是有意義的。

有兩種方法可以做到這一點(diǎn)：

1.向量引擎。所有的操作都是為向量而寫(xiě)的掏秩，而不是單獨(dú)的值或舞。這意味著您不需要經(jīng)常調(diào)用操作，調(diào)度成本可以忽略不計(jì)蒙幻。操作代碼包含一個(gè)優(yōu)化的內(nèi)部循環(huán)映凳。

2.代碼生成。為查詢生成的代碼具有所有的間接調(diào)用邮破。

這不是在“普通”數(shù)據(jù)庫(kù)中完成的诈豌，因?yàn)檫\(yùn)行簡(jiǎn)單查詢時(shí)沒(méi)有意義。但是抒和，也有例外矫渔。例如，MemSQL在處理SQL查詢時(shí)使用代碼生成來(lái)減少延遲摧莽。（為了比較庙洼，分析DBMS需要優(yōu)化吞吐量，而不是延遲镊辕。）

請(qǐng)注意油够，為了提高CPU效率，查詢語(yǔ)言必須是聲明式的（SQL或MDX）征懈，或者至少是一個(gè)向量（J石咬，K）。查詢應(yīng)該只包含隱式循環(huán)卖哎，以便優(yōu)化鬼悠。

ClickHouse的顯著特性

1.真正的面向列的DBMS

2.數(shù)據(jù)高效壓縮

3.磁盤(pán)存儲(chǔ)的數(shù)據(jù)

4.多核并行處理

5.在多個(gè)服務(wù)器上分布式處理

6. SQL語(yǔ)法支持

7.向量化引擎

8.實(shí)時(shí)數(shù)據(jù)更新

9.索引

10.適合在線查詢

11.支持近似預(yù)估計(jì)算

12.支持嵌套的數(shù)據(jù)結(jié)構(gòu)

支持?jǐn)?shù)組作為數(shù)據(jù)類(lèi)型

13.支持限制查詢復(fù)雜性以及配額

14.復(fù)制數(shù)據(jù)復(fù)制和對(duì)數(shù)據(jù)完整性的支持

我們來(lái)看看其中的一些功能：

1.真正的面向列的DBMS

在一個(gè)真正的面向列的DBMS中，沒(méi)有任何“垃圾”存儲(chǔ)在值中亏娜。例如厦章，必須支持定長(zhǎng)數(shù)值，以避免在數(shù)值旁邊存儲(chǔ)長(zhǎng)度“數(shù)字”照藻。例如，十億個(gè)UInt8類(lèi)型的值實(shí)際上應(yīng)該消耗大約1 GB的未壓縮磁盤(pán)空間汗侵，否則這將強(qiáng)烈影響CPU的使用幸缕。由于解壓縮的速度（CPU使用率）主要取決于未壓縮的數(shù)據(jù)量，所以即使在未壓縮的情況下晰韵，緊湊地存儲(chǔ)數(shù)據(jù)（沒(méi)有任何“垃圾”）也是非常重要的发乔。

因?yàn)橛行┫到y(tǒng)可以單獨(dú)存儲(chǔ)單獨(dú)列的值，但由于其他場(chǎng)景的優(yōu)化雪猪，無(wú)法有效處理分析查詢栏尚。例如HBase，BigTable只恨，Cassandra和HyperTable译仗。在這些系統(tǒng)中抬虽，每秒鐘可以獲得大約十萬(wàn)行的吞吐量，但是每秒不會(huì)達(dá)到數(shù)億行纵菌。

另外阐污，ClickHouse是一個(gè)DBMS，而不是一個(gè)單一的數(shù)據(jù)庫(kù)咱圆。ClickHouse允許在運(yùn)行時(shí)創(chuàng)建表和數(shù)據(jù)庫(kù)笛辟，加載數(shù)據(jù)和運(yùn)行查詢，而無(wú)需重新配置和重新啟動(dòng)服務(wù)器序苏。

2.數(shù)據(jù)壓縮

一些面向列的DBMS（InfiniDB CE和MonetDB）不使用數(shù)據(jù)壓縮手幢。但是，數(shù)據(jù)壓縮確實(shí)提高了性能忱详。

3.磁盤(pán)存儲(chǔ)的數(shù)據(jù)

許多面向列的DBMS（SAP HANA和Google PowerDrill）只能在內(nèi)存中工作围来。但即使在數(shù)千臺(tái)服務(wù)器上，內(nèi)存也太小踱阿，無(wú)法在Yandex.Metrica中存儲(chǔ)所有瀏覽量和會(huì)話管钳。

4.多核并行處理

多核多節(jié)點(diǎn)并行化大型查詢。

5.在多個(gè)服務(wù)器上分布式處理

上面列出的列式DBMS幾乎都不支持分布式處理软舌。在ClickHouse中才漆，數(shù)據(jù)可以駐留在不同的分片上。每個(gè)分片可以是用于容錯(cuò)的一組副本佛点。查詢?cè)谒蟹制喜⑿刑幚泶祭摹＿@對(duì)用戶來(lái)說(shuō)是透明的。

6. SQL支持

如果你熟悉標(biāo)準(zhǔn)的SQL超营，我們不能真正談?wù)揝QL的支持鸳玩。

NULL不支持。

所有的函數(shù)都有不同的名字演闭。

JOIN支持不跟。

子查詢?cè)贔ROM，IN米碰，JOIN子句中被支持;

標(biāo)量子查詢支持窝革。

關(guān)聯(lián)子查詢不支持。

7.向量化引擎

數(shù)據(jù)不僅按列存儲(chǔ)吕座，而且由矢量 - 列的部分進(jìn)行處理虐译。這使我們能夠?qū)崿F(xiàn)高CPU性能。

8.實(shí)時(shí)數(shù)據(jù)更新

ClickHouse支持主鍵表吴趴。為了快速執(zhí)行對(duì)主鍵范圍的查詢漆诽，數(shù)據(jù)使用合并樹(shù)(MergeTree)進(jìn)行遞增排序。由于這個(gè)原因，數(shù)據(jù)可以不斷地添加到表中厢拭。添加數(shù)據(jù)時(shí)無(wú)鎖處理兰英。

9.索引

例如，帶有主鍵可以在特定的時(shí)間范圍內(nèi)為特定客戶端（Metrica計(jì)數(shù)器）抽取數(shù)據(jù)蚪腐，并且延遲時(shí)間小于幾十毫秒箭昵。

10.支持在線查詢

這讓我們使用該系統(tǒng)作為Web界面的后端。低延遲意味著可以無(wú)延遲實(shí)時(shí)地處理查詢回季，而Yandex.Metrica界面頁(yè)面正在加載（在線模式）家制。

11.支持近似計(jì)算

1.系統(tǒng)包含用于近似計(jì)算各種值，中位數(shù)和分位數(shù)的集合函數(shù)泡一。

2.支持基于部分（樣本）數(shù)據(jù)運(yùn)行查詢并獲得近似結(jié)果颤殴。在這種情況下，從磁盤(pán)檢索比例較少的數(shù)據(jù)鼻忠。

3.支持為有限數(shù)量的隨機(jī)密鑰（而不是所有密鑰）運(yùn)行聚合涵但。在數(shù)據(jù)中密鑰分發(fā)的特定條件下，這提供了相對(duì)準(zhǔn)確的結(jié)果帖蔓，同時(shí)使用較少的資源矮瘟。

12.數(shù)據(jù)復(fù)制和對(duì)數(shù)據(jù)完整性的支持。

使用異步多主復(fù)制塑娇。寫(xiě)入任何可用的副本后澈侠，數(shù)據(jù)將分發(fā)到所有剩余的副本。系統(tǒng)在不同的副本上保持相同的數(shù)據(jù)埋酬。數(shù)據(jù)在失敗后自動(dòng)恢復(fù)哨啃，或?qū)?fù)雜情況使用“按鈕”。有關(guān)更多信息写妥，請(qǐng)參閱“數(shù)據(jù)復(fù)制”一節(jié)拳球。

ClickHouse目前未實(shí)現(xiàn)功能

1.無(wú)事務(wù)處理。

2.對(duì)于聚合珍特，查詢結(jié)果必須適合單個(gè)服務(wù)器上的內(nèi)存祝峻。但是，查詢的源數(shù)據(jù)量可能無(wú)限大扎筒。

3.缺乏全面的UPDATE / DELETE實(shí)現(xiàn)

Yandex.Metrica任務(wù)

我們需要根據(jù)點(diǎn)擊和會(huì)話獲取自定義報(bào)告呼猪，并使用用戶設(shè)置的自定義。報(bào)告數(shù)據(jù)實(shí)時(shí)更新砸琅。查詢必須立即運(yùn)行（在線模式）。我們必須能夠在任何時(shí)間段建立報(bào)告轴踱。必須計(jì)算復(fù)雜的匯總症脂，例如唯一訪客的數(shù)量。目前（2014年4月），Yandex.Metrica每天接收約120億次事件（瀏覽量和鼠標(biāo)點(diǎn)擊）诱篷。所有這些事件都必須存儲(chǔ)以建立自定義報(bào)告壶唤。單個(gè)查詢可能需要幾秒鐘掃描數(shù)億行，或者數(shù)百萬(wàn)行不超過(guò)幾百毫秒棕所。

匯總和非匯總數(shù)據(jù)

有一種流行的觀點(diǎn)認(rèn)為闸盔，為了有效地計(jì)算統(tǒng)計(jì)數(shù)據(jù)，您必須匯總數(shù)據(jù)琳省，因?yàn)檫@會(huì)減少數(shù)據(jù)量迎吵。

但是數(shù)據(jù)聚合是一個(gè)非常有限的解決方案，原因如下：

- 您必須具有用戶需要的預(yù)定義報(bào)告列表针贬。用戶不能進(jìn)行自定義報(bào)告击费。

- 聚合大量密鑰時(shí)，數(shù)據(jù)量不會(huì)減少桦他，聚合無(wú)用蔫巩。

- 對(duì)于大量的報(bào)告吏祸，聚合變化太多（組合爆炸）貌笨。

- 聚合高基數(shù)密鑰（如URL）時(shí)未桥，數(shù)據(jù)量不會(huì)減少太多（小于兩倍）卫病。出于這個(gè)原因北滥，聚合的數(shù)據(jù)量可能會(huì)增長(zhǎng)诡必，而不是縮小赊颠。

- 用戶不會(huì)查看我們?yōu)樗麄冇?jì)算的所有報(bào)告枣氧。大部分的計(jì)算是無(wú)用的拦宣。

- 各種聚合可能違反數(shù)據(jù)的邏輯完整性截粗。

如果我們不匯總?cè)魏蝺?nèi)容并使用非匯總的數(shù)據(jù)，這實(shí)際上可能會(huì)減少計(jì)算量鸵隧。

但是绸罗，通過(guò)匯總，相當(dāng)一部分工作脫離了線索豆瘫，相對(duì)冷靜地完成了工作珊蟀。相反，在線計(jì)算需要盡可能快地計(jì)算外驱，因?yàn)橛脩粽诘却Y(jié)果育灸。

Yandex.Metrica有一個(gè)專(zhuān)門(mén)的系統(tǒng)來(lái)匯總稱(chēng)為Metrage的數(shù)據(jù)，這個(gè)數(shù)據(jù)用于大多數(shù)報(bào)告昵宇。從2009年開(kāi)始磅崭，Yandex.Metrica還使用專(zhuān)門(mén)的OLAP數(shù)據(jù)庫(kù)來(lái)處理非聚合數(shù)據(jù)，稱(chēng)為OLAPServer瓦哎，以前用于報(bào)告生成器砸喻。OLAPServer對(duì)非匯總數(shù)據(jù)運(yùn)行良好柔逼，但是它有許多限制，不能根據(jù)需要用于所有報(bào)告割岛。這些包括缺乏對(duì)數(shù)據(jù)類(lèi)型（僅數(shù)字）的支持愉适，以及無(wú)法實(shí)時(shí)增量更新數(shù)據(jù)（只能通過(guò)每天重寫(xiě)數(shù)據(jù)來(lái)完成）。OLAPServer不是一個(gè)DBMS癣漆，而是一個(gè)專(zhuān)門(mén)的DB维咸。

為了消除OLAPServer的限制，并解決所有報(bào)告使用非匯總數(shù)據(jù)的問(wèn)題惠爽，我們開(kāi)發(fā)了ClickHouse DBMS癌蓖。

用于Yandex.Metrica和其他Yandex服務(wù)

ClickHouse在Yandex.Metrica中用于多種用途。其主要任務(wù)是使用非聚合數(shù)據(jù)以在線模式構(gòu)建報(bào)告疆股。它使用374個(gè)服務(wù)器的集群费坊，在數(shù)據(jù)庫(kù)中存儲(chǔ)超過(guò)8萬(wàn)億行（超過(guò)四十億個(gè)值）。壓縮數(shù)據(jù)量不計(jì)復(fù)制和復(fù)制旬痹，大約是800TB附井。未壓縮的數(shù)據(jù)量（以TSV格式）將大約為7PB。

ClickHouse還用于：

- 存儲(chǔ)WebVisor數(shù)據(jù)两残。

- 處理中間數(shù)據(jù)永毅。

- 使用Google Analytics構(gòu)建全球報(bào)告。

- 運(yùn)行查詢以調(diào)試Metrica引擎人弓。

- 分析來(lái)自API和用戶界面的日志沼死。

ClickHouse在其他Yandex服務(wù)中至少安裝了十幾個(gè)安裝：搜索行業(yè)，市場(chǎng)崔赌，Direct意蛀，業(yè)務(wù)分析，移動(dòng)開(kāi)發(fā)健芭，AdFox县钥，個(gè)人服務(wù)等。

類(lèi)似開(kāi)源系統(tǒng)

有沒(méi)有類(lèi)似的ClickHouse可用慈迈。目前（2016年5月）若贮，沒(méi)有任何可用的開(kāi)源和免費(fèi)系統(tǒng)具有上面列出的所有功能。但是痒留，這些功能對(duì)于Yandex.Metrica是絕對(duì)必要的谴麦。

可能愚蠢的問(wèn)題

1.為什么不使用map-reduce等系統(tǒng)？

像map-reduce這樣的系統(tǒng)是分布式計(jì)算系統(tǒng)伸头，其中使用分布式排序來(lái)執(zhí)行縮減階段匾效。回顧這個(gè)方面恤磷，map-reduce與YAMR面哼，Hadoop雪侥，YT等其他系統(tǒng)類(lèi)似。

這些系統(tǒng)由于延遲而不適合在線查詢精绎，所以不能用于后臺(tái)級(jí)別的網(wǎng)頁(yè)界面。這樣的系統(tǒng)也不適合實(shí)時(shí)更新锌妻。分布式排序并不是減少操作的最佳解決方案代乃，如果操作的結(jié)果和所有中間結(jié)果都存在，就像通常在聯(lián)機(jī)分析查詢的情況下發(fā)生的那樣仿粹，它們適合單個(gè)服務(wù)器的運(yùn)行內(nèi)存搁吓。在這種情況下，執(zhí)行reduce操作的最佳方法是使用散列表吭历。map-reduce任務(wù)的常用優(yōu)化方法是在內(nèi)存中使用散列表的組合操作（partial reduce）堕仔。這個(gè)優(yōu)化是由用戶手動(dòng)完成的。分布式排序是簡(jiǎn)單的map-reduce作業(yè)長(zhǎng)時(shí)間延遲的主要原因晌区。

與map-reduce類(lèi)似的系統(tǒng)可以在集群上運(yùn)行任何代碼摩骨。但是，對(duì)于OLAP朗若，使用情況下的執(zhí)行查詢語(yǔ)言更為合適恼五，因?yàn)榻?jīng)過(guò)調(diào)研它們可以更快地運(yùn)行。例如哭懈，Hadoop有Hive和Pig灾馒。還有其他：Cloudera Impala,Shark (depricated)andSpark SQLforSpark,Presto,Apache Drill.。然而遣总，與專(zhuān)門(mén)系統(tǒng)的性能相比睬罗，這些任務(wù)的性能是非常不理想的，相對(duì)較高的延遲不允許將這些系統(tǒng)用作網(wǎng)絡(luò)接口的后端旭斥。YT允許您存儲(chǔ)單獨(dú)的一組列容达。但YT不是一個(gè)真正的列式存儲(chǔ)系統(tǒng)，因?yàn)橄到y(tǒng)沒(méi)有固定長(zhǎng)度的數(shù)據(jù)類(lèi)型（所以你可以有效地存儲(chǔ)一個(gè)數(shù)字而不是“垃圾”）琉预，而且沒(méi)有向量化引擎董饰。YT中的任務(wù)由流模式下的任意代碼執(zhí)行，因此不能被充分優(yōu)化（每臺(tái)服務(wù)器每秒高達(dá)數(shù)億行）圆米。在2014-2016年卒暂，YT將開(kāi)發(fā)使用合并樹(shù)，強(qiáng)類(lèi)型值和類(lèi)SQL語(yǔ)言支持的“動(dòng)態(tài)表格排序”功能娄帖。動(dòng)態(tài)排序的表不適用于OLAP任務(wù)也祠，因?yàn)閿?shù)據(jù)存儲(chǔ)在行中。YT中的查詢語(yǔ)言開(kāi)發(fā)仍處于孵化階段近速，不能專(zhuān)注于這個(gè)功能诈嘿。YT開(kāi)發(fā)人員正在考慮在OLTP和Key-Value方案中使用動(dòng)態(tài)排序的表堪旧。

性能

根據(jù)內(nèi)部測(cè)試結(jié)果，ClickHouse在可用于測(cè)試的同類(lèi)系統(tǒng)中顯示出最佳性能奖亚。這包括長(zhǎng)查詢的最高吞吐量和短查詢的最低延遲淳梦。測(cè)試結(jié)果顯示在此頁(yè)面上。

吞吐量為單個(gè)大型查詢

吞吐量可以以每秒行數(shù)或兆字節(jié)每秒來(lái)衡量昔字。如果數(shù)據(jù)放置在頁(yè)面緩存中爆袍，則在現(xiàn)代硬件上處理不太復(fù)雜的查詢，在單個(gè)服務(wù)器上以大約2-10 GB / s的未壓縮數(shù)據(jù)的速度進(jìn)行處理（對(duì)于最簡(jiǎn)單的情況作郭，速度可能會(huì)達(dá)到30 GB / s）陨囊。如果數(shù)據(jù)不在頁(yè)面緩存中，則速度取決于磁盤(pán)子系統(tǒng)和數(shù)據(jù)壓縮率夹攒。例如蜘醋，如果磁盤(pán)子系統(tǒng)允許以400 MB / s讀取數(shù)據(jù)，并且數(shù)據(jù)壓縮率為3咏尝，則速度將在1.2 GB / s左右压语。要獲得每秒行數(shù)的速度，請(qǐng)將查詢中使用的列的總大小除以每秒字節(jié)數(shù)状土。例如无蜂，如果提取10個(gè)字節(jié)的列，速度將在每秒大約1到2億行蒙谓。

處理速度對(duì)于分布式處理幾乎線性地增加斥季，但是只有在聚合或排序產(chǎn)生的行數(shù)不太大的情況下。

處理短的查詢時(shí)延遲

如果一個(gè)查詢使用一個(gè)主鍵累驮，并且沒(méi)有選擇太多的行來(lái)處理（成千上萬(wàn)）酣倾，并且不使用太多的列，我們可以預(yù)計(jì)到不到50毫秒的延遲（最好的情況下谤专，單位為毫秒）if數(shù)據(jù)被放置在頁(yè)面緩存中躁锡。否則，延遲是根據(jù)搜索的數(shù)量來(lái)計(jì)算的置侍。如果使用旋轉(zhuǎn)驅(qū)動(dòng)器映之，對(duì)于沒(méi)有過(guò)載的系統(tǒng)，延遲時(shí)間通過(guò)以下公式計(jì)算：查找時(shí)間（10 ms）*查詢的列數(shù)*數(shù)據(jù)部分的數(shù)量蜡坊。

處理大量的短查詢時(shí)的吞吐量

在相同的條件下杠输，ClickHouse可以在單個(gè)服務(wù)器上每秒處理幾百個(gè)查詢（在最好的情況下可以達(dá)到幾千個(gè)）。由于這種情況對(duì)分析型DBMS并不常見(jiàn)秕衙，因此我們建議每秒最多可以查詢100個(gè)查詢蠢甲。

數(shù)據(jù)插入性能

我們建議將數(shù)據(jù)插入至少1000行的數(shù)據(jù)包中，或者每秒不超過(guò)一個(gè)請(qǐng)求据忘。從制表符分隔轉(zhuǎn)儲(chǔ)插入到MergeTree表時(shí)鹦牛，插入速度將從50到200 MB / s搞糕。如果插入的行大小約為1Kb，速度將從每秒50,000到200,000行曼追。如果行很小窍仰，則每秒的行數(shù)會(huì)更高（Yandex Banner System數(shù)據(jù) - > 500,000行/秒，Graphite數(shù)據(jù) - > 1,000,000行/秒）礼殊。為了提高性能辈赋，可以并行執(zhí)行多個(gè)INSERT查詢，并且性能會(huì)線性增加膏燕。