什么是ClickHouse?

ClickHouse是一個(gè)用于聯(lián)機(jī)分析(OLAP)的列式數(shù)據(jù)庫管理系統(tǒng)(DBMS)。
聯(lián)機(jī)分析處理OLAP是一種軟件技術(shù)，它使分析人員能夠迅速鸟缕、一致搀庶、交互地從各個(gè)方面觀察信息按脚，以達(dá)到深入理解數(shù)據(jù)的目的溉卓。Online analytical processing
OLTP是傳統(tǒng)的關(guān)系型數(shù)據(jù)庫的主要應(yīng)用，主要是基本的搬泥、日常的事務(wù)處理桑寨，例如銀行交易。on-line transaction processing

誰在用忿檩？

今日頭條 內(nèi)部用ClickHouse來做用戶行為分析尉尾，內(nèi)部一共幾千個(gè)ClickHouse節(jié)點(diǎn)，單集群最大1200節(jié)點(diǎn)燥透，總數(shù)據(jù)量幾十PB沙咏，日增原始數(shù)據(jù)300TB左右辨图。
騰訊內(nèi)部用ClickHouse做游戲數(shù)據(jù)分析，并且為之建立了一整套監(jiān)控運(yùn)維體系肢藐。
攜程內(nèi)部從18年7月份開始接入試用故河，目前80%的業(yè)務(wù)都跑在ClickHouse上。每天數(shù)據(jù)增量十多億吆豹，近百萬次查詢請(qǐng)求鱼的。
快手內(nèi)部也在使用ClickHouse，存儲(chǔ)總量大約10PB痘煤， 每天新增200TB凑阶， 90%查詢小于3S。
在國(guó)外衷快，Yandex內(nèi)部有數(shù)百節(jié)點(diǎn)用于做用戶點(diǎn)擊行為分析宙橱，CloudFlare、Spotify等頭部公司也在使用蘸拔。
米哈游也有專門的數(shù)據(jù)分析部門在用

實(shí)現(xiàn)了什么师郑？

數(shù)據(jù)有序存儲(chǔ)、主鍵索引都伪、稀疏索引呕乎、數(shù)據(jù)Sharding、數(shù)據(jù)Partitioning陨晶、TTL猬仁、主備復(fù)制

數(shù)據(jù)有序存儲(chǔ)：

ClickHouse支持在建表時(shí)，指定將數(shù)據(jù)按照某些列進(jìn)行sort by先誉。
排序后湿刽，保證了相同sort key的數(shù)據(jù)在磁盤上連續(xù)存儲(chǔ)，且有序擺放褐耳。在進(jìn)行等值诈闺、范圍查詢時(shí)，where條件命中的數(shù)據(jù)都緊密存儲(chǔ)在一個(gè)或若干個(gè)連續(xù)的Block中铃芦，而不是分散的存儲(chǔ)在任意多個(gè)Block雅镊， 大幅減少需要IO的block數(shù)量。另外刃滓，連續(xù)IO也能夠充分利用操作系統(tǒng)page cache的預(yù)取能力仁烹，減少page fault。

使用了什么存儲(chǔ)結(jié)構(gòu)咧虎，為什么是LSM-Tree卓缰？

Google提出的BIGTable又叫LSM-Tree全稱是Log Structured Merge Tree，是一種分層，有序征唬，面向磁盤的數(shù)據(jù)結(jié)構(gòu)捌显，其核心思想是充分利用了磁盤順序?qū)懀疟P批量的順序?qū)懸h(yuǎn)比隨機(jī)寫性能高出很多.
標(biāo)志的就是kafka总寒，把磁盤順序?qū)懱嵘搅藰O致扶歪。

和傳統(tǒng)的B+樹進(jìn)行對(duì)比，和傳統(tǒng)的B+樹進(jìn)行對(duì)比偿乖，隨機(jī)寫PK順序?qū)?/h4>

LSM-Tree的設(shè)計(jì)思路是击罪，將數(shù)據(jù)拆分為幾百M(fèi)大小的Segments，并是順序?qū)懭胩靶健２焕速M(fèi)時(shí)間媳禁。
B+Tree則是將數(shù)據(jù)拆分為固定大小的Block或Page, 一般是4KB大小，和磁盤一個(gè)扇區(qū)的大小對(duì)應(yīng)画切，Page是讀寫的最小單位竣稽。
在數(shù)據(jù)的更新和刪除方面，B+Tree可以做到原地更新和刪除霍弹，這種方式對(duì)數(shù)據(jù)庫事務(wù)支持更加友好毫别，因?yàn)橐粋€(gè)key只會(huì)出現(xiàn)一個(gè)Page頁里面
但由于LSM-Tree只能追加寫，并且在L0層key的range會(huì)重疊典格，所以對(duì)事務(wù)支持較弱岛宦，只能在Segment Compaction的時(shí)候進(jìn)行真正地更新和刪除。

因此LSM-Tree的優(yōu)點(diǎn)是支持高吞吐的寫（可認(rèn)為是O（1））耍缴，這個(gè)特點(diǎn)在分布式系統(tǒng)上更為看重砾肺，當(dāng)然針對(duì)讀取普通的LSM-Tree結(jié)構(gòu)，讀取是O（N）的復(fù)雜度防嗡，在使用索引或者緩存優(yōu)化后的也可以達(dá)到O（logN）的復(fù)雜度变汪。

而B+tree的優(yōu)點(diǎn)是支持高效的讀（穩(wěn)定的OlogN），但是在大規(guī)模的寫請(qǐng)求下（復(fù)雜度O(LogN)）蚁趁，效率會(huì)變得比較低裙盾，因?yàn)殡S著insert的操作，為了維護(hù)B+樹結(jié)構(gòu)他嫡，節(jié)點(diǎn)會(huì)不斷的分裂和合并番官。操作磁盤的隨機(jī)讀寫概率會(huì)變大，故導(dǎo)致性能降低钢属。

關(guān)鍵特征提扰侨邸：

1：適應(yīng)場(chǎng)景為絕大多數(shù)都是讀請(qǐng)求

2：數(shù)據(jù)大批次更新，每次（1000行）署咽，而不是高頻率，低行數(shù)更新。（這樣就能列存儲(chǔ)就能應(yīng)用上宁否，將1000條插入窒升，拆分成對(duì)x列的插入（行數(shù)>列數(shù)））

3：已添加到數(shù)據(jù)庫的數(shù)據(jù)不能修改（不建議修改，會(huì)影響到排序和聚合）

4：對(duì)于讀取慕匠，行數(shù)大于列數(shù)（這樣才能將行的讀取轉(zhuǎn)換為列的讀取饱须，要是行數(shù)等于列數(shù)，這個(gè)優(yōu)勢(shì)就不復(fù)存在）

5：寬表台谊，即每個(gè)表存在大量的列

6：查詢相對(duì)較少（高頻率用ES更適合蓉媳，有查詢緩存）,適用報(bào)表，做低頻率的數(shù)據(jù)聚合分析

7：簡(jiǎn)單查詢锅铅，可能也會(huì)有50ms左右的延時(shí)

8：列中的數(shù)據(jù)相對(duì)較小酪呻，方便聚合，如果超過60的大JSON盐须，建議拆分成多列進(jìn)行聚合

9：?jiǎn)蝹€(gè)查詢高吞吐量（并發(fā)雖然不適合玩荠，但適合對(duì)大數(shù)據(jù)的處理，單服務(wù)器每秒10億行的處理速度）

10：不支持事務(wù) （大數(shù)據(jù)的事務(wù)處理贼邓，會(huì)浪費(fèi)多余的性能去維護(hù)數(shù)據(jù)的完整性阶冈，這會(huì)喪失他的快速分析優(yōu)勢(shì)），關(guān)于事務(wù)其實(shí)參考上面的存儲(chǔ)結(jié)構(gòu)就能發(fā)現(xiàn)了塑径。

11：同上女坑，數(shù)據(jù)一致無法保證

12：?jiǎn)蝹€(gè)查詢最好是大表拖小表

13：查詢結(jié)果小于源數(shù)據(jù)，全量查詢统舀，啥都頂不住

14：靈活多變匆骗，適用于非預(yù)先建模的場(chǎng)景（如業(yè)務(wù)要做實(shí)時(shí)分析，條件也是隨機(jī)的绑咱，就很適合使用）

參考文章：
https://cloud.tencent.com/developer/article/1441835
https://developer.aliyun.com/article/739804