H肉动漫在线观看麻豆,国产精品香蕉女一区二区三区,啊啊啊好大快点好爽视频

本文對 Clickhouse 架構(gòu)原理、語法、性能特點做一定研究，同時將其與 MySQL、elasticsearch、tidb 做橫向?qū)Ρ龋⒅攸c分析與 mysql 的語法差異，為有 mysql 遷移 clickhouse 場景需求的技術(shù)預(yù)研及參考。

1 基礎(chǔ)概念

Clickhouse 是一個用于聯(lián)機分析（OLAP）的列式數(shù)據(jù)庫管理系統(tǒng)（DBMS)。

1.1 集群架構(gòu)

ClickHouse 采用典型的分組式的分布式架構(gòu)，具體集群架構(gòu)如下圖所示：

Shard：集群內(nèi)劃分為多個分片或分組（Shard 0 … Shard N），通過 Shard 的線性擴展能力，支持海量數(shù)據(jù)的分布式存儲計算。
Node：每個 Shard 內(nèi)包含一定數(shù)量的節(jié)點（Node，即進程），同一 Shard 內(nèi)的節(jié)點互為副本，保障數(shù)據(jù)可靠。ClickHouse 中副本數(shù)可按需建設(shè)，且邏輯上不同 Shard 內(nèi)的副本數(shù)可不同。
ZooKeeper Service：集群所有節(jié)點對等，節(jié)點間通過 ZooKeeper 服務(wù)進行分布式協(xié)調(diào)。

1.2 數(shù)據(jù)分區(qū)

Clickhouse 是分布式系統(tǒng)，其數(shù)據(jù)表的創(chuàng)建，與 mysql 是有差異的，可以類比的是在 mysql 上實現(xiàn)分庫分表的方式。

Clichhouse 先在每個 Shard 每個節(jié)點上創(chuàng)建本地表（即 Shard 的副本），本地表只在對應(yīng)節(jié)點內(nèi)可見；然后再創(chuàng)建分布式表 [Distributed]，映射到前面創(chuàng)建的本地表。

用戶在訪問分布式表時，ClickHouse 會自動根據(jù)集群架構(gòu)信息，把請求轉(zhuǎn)發(fā)給對應(yīng)的本地表。

1.3 列式存儲

相對于關(guān)系型數(shù)據(jù)庫（RDBMS），是按行存儲的。以 mysql 中 innodb 的主鍵索引為例，構(gòu)建主鍵索引的 B + 樹中，每個葉子節(jié)點存儲的就是一行記錄。

而列式數(shù)據(jù)庫，是將一個表，按 column 的維護進行存儲，“單次磁盤 I/O 拿到的是一列的數(shù)據(jù)”。

列式存儲的優(yōu)點

在查詢時，只會讀取涉及到的列，會大大減少 IO 次數(shù) / 開銷。并且 clickhouse 在存儲時會按指定順序排列數(shù)據(jù)，因此只需要按 where 條件指定列進行順序掃描、多個列的掃描結(jié)果合并，即可找到滿足條件的數(shù)據(jù)。

但由于 insert 數(shù)據(jù)時，是按行寫入的，因此存儲的過程會麻煩一些。

查詢時的區(qū)別：

列存儲：僅從存儲系統(tǒng)中讀取必要的列數(shù)據(jù)（select + where 涉及到的），無用列不讀取，速度非常快。
行存儲：從存儲系統(tǒng)讀取所有滿足條件的行數(shù)據(jù)，然后在內(nèi)存中過濾出需要的字段，速度較慢。

1.4 數(shù)據(jù)排序

每個數(shù)據(jù)分區(qū)內(nèi)部，所有列的數(shù)據(jù)是按照排序鍵（ORDER BY 列）進行排序的。

可以理解為：對于生成這個分區(qū)的原始記錄行，先按排序鍵進行排序，然后再按列拆分存儲。

1.5 數(shù)據(jù)分塊

每個列的數(shù)據(jù)文件中，實際是分塊存儲的，方便數(shù)據(jù)壓縮及查詢裁剪，每個塊中的記錄數(shù)不超過 index_granularity，默認 8192，當(dāng)達到 index_granularity 的值，數(shù)據(jù)會分文件。

1.6 向量化執(zhí)行

在支持列存的基礎(chǔ)上，ClickHouse 實現(xiàn)了一套面向向量化處理的計算引擎，大量的處理操作都是向量化執(zhí)行的。

向量化處理的計算引擎：

基于數(shù)據(jù)存儲模型，疊加批量處理模式，利用 SIMD 指令集，降低函數(shù)調(diào)用次數(shù)，降低硬件開銷（比如各級硬件緩存），提升多核 CPU 利用率。

再加上分布式架構(gòu)，多機器、多節(jié)點、多線程、批量操作數(shù)據(jù)的指令，最大限度利用硬件資源，提高效率。

注：SIMD 指令，單指令多數(shù)據(jù)流，也就是說在同一個指令周期可以同時處理多個數(shù)據(jù)。(例如：在一個指令周期內(nèi)就可以完成多個數(shù)據(jù)單元的比較).

1.7 編碼壓縮

由于 ClickHouse 采用列存儲，相同列的數(shù)據(jù)連續(xù)存儲，且底層數(shù)據(jù)在存儲時是經(jīng)過排序的，這樣數(shù)據(jù)的局部規(guī)律性非常強，有利于獲得更高的數(shù)據(jù)壓縮比。

同時，超高的壓縮比又可以降低存儲讀取開銷、提升系統(tǒng)緩存能力，從而提高查詢性能。

1.8 索引

前面提到的列式存儲，用于裁剪不必要的字段讀取；

而索引，則用于裁剪不必要的記錄讀取（減少未命中數(shù)據(jù)的 IO)。

簡單解釋：

以主鍵索引為例，Clickhouse 存儲數(shù)據(jù)時，會按排序鍵（ORDER BY) 指定的列進行排序，并按 Index_granularity 參數(shù)切分成塊，然后會抽取每個數(shù)據(jù)塊的首行，組織為一份稀疏的排序索引。

類比 B + 樹的查找過程，如果 where 條件中包含主鍵列，就可以通過稀疏索引快速的過濾。稀疏索引對于范圍查找比較高效。

二級索引，則是采用 bloom filter 來實現(xiàn)的：minmax，set，ngrambf/tokenbf。

1.9 適用場景

OLAP 分析領(lǐng)域有兩個典型的方向：

ROLAP，通過列存、索引等各類技術(shù)手段，提升查詢時性能。
寬表、大表場景，where 條件過多且動態(tài)，mysql 無法每列都建索引。
MOLAP，通過預(yù)計算提前生成聚合后的結(jié)果數(shù)據(jù)，降低查詢讀取的數(shù)據(jù)量，屬于計算換性能方式。
復(fù)雜的報表查詢，聚合、篩選很復(fù)雜的場景。

既然是 OLAP 分析，對數(shù)據(jù)的使用有些基本要求：

絕大多數(shù)都是用于讀訪問
無更新、大批量的更新（大于 1000 行）。（ck 沒有高速、低延遲的更新和刪除方法）
查詢的列盡量少，但行數(shù)很多。
不需要事務(wù)、可以避免事務(wù)（clickhouse 不支持事務(wù)）
數(shù)據(jù)一致性要求較低
多表 join 時，只有一個是大表、大表關(guān)聯(lián)小表
單表的查詢、聚合效率最高，建議數(shù)據(jù)做寬表處理

2 橫向?qū)Ρ?/p>

搬倉系統(tǒng)面臨的是從十幾億數(shù)據(jù)中進行查詢、聚合分析，從世面上可選的支持海量數(shù)據(jù)讀寫的中間件中搜集到，能夠有支持類似場景、有比較輕量級的產(chǎn)品大概有 Clickhouse、ElasticSearch、TiDB。

2.1 clickhouse 與 ElasticSearch 對比

elastic 生態(tài)很豐富，es 作為其中的存儲產(chǎn)品，從首個版本算起，已經(jīng)有 10 年發(fā)展歷史，主要解決的是搜索問題。es 的底層存儲采用 lucene，主要包含行存儲、列存儲和倒排索引，利用分片與副本機制，解決了集群下搜索性能與高可用的問題。

es 的優(yōu)勢：

支持實時更新，對 update、delete 操作支持更完整。
數(shù)據(jù)分片更均勻，集群擴展更加方便

es 的局限性：

數(shù)據(jù)量超過千萬或者億級時，若聚合的列數(shù)太多，性能也到達瓶頸；
不支持深度二次聚合，導(dǎo)致一些復(fù)雜的聚合需求，需要人工編寫代碼在外部實現(xiàn)，這又增加很多開發(fā)工作量。

ClickHouse 與 Elasticsearch（排序與聚合查詢）一樣，都采用列式存儲結(jié)構(gòu)，都支持副本分片，不同的是 ClickHouse 底層有一些獨特的實現(xiàn)，如下：

合并樹表引擎系列（MergeTree ），提供了數(shù)據(jù)分區(qū)、一級索引、二級索引。
向量引擎（Vector Engine），數(shù)據(jù)不僅僅按列存儲，同時還按向量 (列的一部分) 進行處理，這樣可以更加高效地使用 CPU

網(wǎng)上資料：聚合查詢的性能對比

es 對于在處理大查詢，可能導(dǎo)致 OOM 問題，集群雖然能夠?qū)Ξ惓９?jié)點有自動恢復(fù)機制，但其查詢數(shù)據(jù)量級不滿足搬倉系統(tǒng)需求。

2.2 clickhouse 與 TiDB 對比

TiDB 是一個分布式 NewSQL 數(shù)據(jù)庫。它支持水平彈性擴展、ACID 事務(wù)、標(biāo)準(zhǔn) SQL、MySQL 語法和 MySQL 協(xié)議，具有數(shù)據(jù)強一致的高可用特性，是一個不僅適合 OLTP 場景還適 OLAP 場景的混合數(shù)據(jù)庫。

TiDB 的優(yōu)勢：

兼容 Mysql 協(xié)議和絕大多數(shù) Mysql 語法，在大多數(shù)情況下，用戶無需修改一行代碼就可以從 Mysql 無縫遷移到 TiDB
高可用、強制一致性（Raft）
支持 ACID 事務(wù)（依賴事務(wù)列表），支持二級索引
適合快速的點插入，點更新和點刪除

TiDB 的局限性：

更擅長 OLTP
性能依賴硬件和集群規(guī)模，單機的讀寫性能不夠出色

TiDB 更加適合作為 MySql 的替代，其對 MySQL 的兼容可以使得我們的應(yīng)用切換成本較低，并且 TiDB 提供的數(shù)據(jù)自動分片無需人工維護。

3 為什么是 clickhouse

我們的項目場景是每天要同步十幾億單表數(shù)據(jù)，基本業(yè)務(wù)的查詢在百萬，還包含復(fù)雜的聚合分析。而 Clickhouse 在處理單表海量數(shù)據(jù)的查詢分析方面，是十分優(yōu)秀的，因此選用 clickhouse。

3.1 clickhouse 讀寫性能驗證

官方公開 benchmark 測試顯示能夠達到 50MB-200MB/s 的寫入吞吐能力，按照每行 100Byte 估算，大約相當(dāng)于 50W-200W 條 /s 的寫入速度。

下面是對 Clickhouse 的讀寫性能的簡單測試，數(shù)據(jù)量越大差距越明顯。

1）JDBC 方式單表、單次寫入性能測試（性能更好）：

2）MyBatis 方式單表、單次寫入性能測試：

聚合查詢性能舉例：下圖是搬倉系統(tǒng)一個聚合查詢，在 clickhouse 中不同數(shù)據(jù)量級情況下的表現(xiàn)。這個查詢在 mysql 中執(zhí)行，一百萬左右的數(shù)據(jù)量時，耗時已經(jīng)是分鐘級別。

1）count+distinct 方式聚合：

2）group by 方式聚合：

3.2 不足之處

作為分布式系統(tǒng)，通常包含三個重要組成：1、存儲引擎。 2、計算引擎。 3、分布式管控層。

在分布式管控層，CK 顯得較為薄弱，導(dǎo)致運營、使用成本較高。

分布式表、本地表、副本的維護，這些都是需要用戶自己來定義的，在使用時需要提前學(xué)習(xí)大量相關(guān)內(nèi)容。
彈性伸縮：ck 雖然可以做到水平增加節(jié)點，但不支持自動的數(shù)據(jù)均衡。也就是說當(dāng)集群擴容后，需要手動將數(shù)據(jù)重寫分片，或者依賴數(shù)據(jù)過期，才能保持存儲壓力的均衡。
故障恢復(fù)：在節(jié)點故障的情況下，ck 不能利用其他機器補齊缺失的副本數(shù)據(jù)，需要用戶 ian 補齊節(jié)點后，才能自動在副本件進行數(shù)據(jù)同步。

這方面，由于我們直接采用京東云實例，可以省很多事情。

計算引擎，CK 在處理多表關(guān)聯(lián)查詢、復(fù)雜嵌套子查詢等場景，需要人工優(yōu)化，才能做到明顯的性能提升；

實時寫入，CK 使用場景并不適合比較分散的插入，因為其沒有實現(xiàn)內(nèi)存表（Memory Table）結(jié)構(gòu)，每批次寫入直接落盤，單條記錄實時寫入會導(dǎo)致底層大量的小文件，影響查詢性能。

建議單次大批量寫入方式、報表庫場景降低小文件產(chǎn)生概率。

集群模式下本地表的寫入，需要自定義分片規(guī)則，否則隨機寫入會造成數(shù)據(jù)不均勻。

依賴分布式表的寫入，對網(wǎng)絡(luò)、資源的占用較高。

從數(shù)據(jù)量增長情況來看，使用場景：

如果預(yù)估自己的業(yè)務(wù)數(shù)據(jù)量不大 (日增不到百萬行), 那么寫分布式表和本地表都可以，但要注意如果選擇寫本地表，請保證每次寫入數(shù)據(jù)都建立新的連接，且每個連接寫入的數(shù)據(jù)量基本相同，手動保持?jǐn)?shù)據(jù)均勻
如果預(yù)估自己的業(yè)務(wù)數(shù)據(jù)量大 (日增百萬以上，并發(fā)插入大于 10), 那么請寫本地表
建議每次插入 50W 行左右數(shù)據(jù)，最多不可超過 100W 行。總之 CH 不像 MySQL 要小事務(wù)。比如 1000W 行數(shù)據(jù)，MySQL 建議一次插入 1W 左右，使用小事務(wù)，執(zhí)行 1000 次. CH 建議 20 次，每次 50W. 這是 MergeTree 引擎原理決定的，頻繁少量插入會導(dǎo)致 data part 過多，合并不過來.
MergeTree 系列：被設(shè)計用于插入極大量的數(shù)據(jù)到一張表當(dāng)中。數(shù)據(jù)可以以數(shù)據(jù)片段的形式一個接著一個的快速寫入，數(shù)據(jù)片段在后臺按照一定的規(guī)則進行合并。相比在插入時不斷修改（重寫）已存儲的數(shù)據(jù)，這種策略會高效很多。
Log 系列：功能相對簡單，主要用于快速寫入小表（1 百萬行左右的表），然后全部讀出的場景。
Integration 系列：主要用于將外部數(shù)據(jù)導(dǎo)入到 ClickHouse 中，或者在 ClickHouse 中直接操作外部數(shù)據(jù)源。
Special 系列：大多是為了特定場景而定制的。上面提到的 Distributed 就屬于該系列。

4.1 MergeTree 表引擎

主要用于海量數(shù)據(jù)分析，支持?jǐn)?shù)據(jù)分區(qū)、存儲有序、主鍵索引、稀疏索引、數(shù)據(jù) TTL 等。MergeTree 支持所有 ClickHouse SQL 語法，但是有些功能與 MySQL 并不一致，比如在 MergeTree 中主鍵并不用于去重。

先看一個創(chuàng)建表的簡單語法：

CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]

) ENGINE = ReplacingMergeTree([ver])

[PARTITION BY expr] -- 數(shù)據(jù)分區(qū)規(guī)則

[ORDER BY expr] -- 排序鍵

[SAMPLE BY expr] -- 采樣鍵

[SETTINGS index_granularity = 8192, ...] -- 額外參數(shù)

先忽略表結(jié)構(gòu)的定義，先看看相比于 mysql 建表的差異項。（指定集群、分區(qū)規(guī)則、排序鍵、采樣 0-1 數(shù)字）

數(shù)據(jù)分區(qū)：每個分片副本的內(nèi)部，數(shù)據(jù)按照 PARTITION BY 列進行分區(qū)，分區(qū)以目錄的方式管理，本文樣例中表按照時間進行分區(qū)。

基于 MergeTree 表引擎，CK 擴展很多解決特殊場景的表引擎，下面介紹幾種常用的。

4.1.1 ReplacingMergeTree 引擎

該引擎和 MergeTree 的不同之處在于它會刪除排序鍵值 (ORDER BY) 相同的重復(fù)項。

官方建表語句：

CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]

name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],

name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2],

) ENGINE = ReplacingMergeTree([ver])

[PARTITION BY expr]

[ORDER BY expr]

[SAMPLE BY expr]

[SETTINGS name=value, ...]

注意：在設(shè)置表引擎時，比 MergeTree 多了一個參數(shù)：ver - 版本列，ENGINE = ReplacingMergeTree ([ver]) 。

在數(shù)據(jù)合并的時候，ReplacingMergeTree 從所有具有相同排序鍵的行中選擇一行留下：

如果 ver 列未指定，保留最后一條。
如果 ver 列已指定，保留 ver 值最大的版本。

ReplacingMergeTree 引擎，在數(shù)據(jù)寫入后，不一定立即進行去重操作，或者不一定去重完畢（官方描述在 10 到 15 分鐘內(nèi)會進行合并）。

由于去重依賴的是排序鍵，ReplacingMergeTree 引擎是會按照分區(qū)鍵進行分區(qū)的，因此相同排序鍵的數(shù)據(jù)有可能被分到不同的分區(qū)，不同 shard 間可能無法去重。

在圖上，分區(qū) 1 的文件塊，會進行數(shù)據(jù)合并去重，但是分區(qū) 1 與分區(qū) 2 之間的數(shù)據(jù)是不會進行去重的。因此，如果要保證數(shù)據(jù)最終能夠去重，要保證相同排序鍵的數(shù)據(jù)，會寫入相同分區(qū)。

數(shù)據(jù)驗證

下圖為 ReplacingMergeTree 引擎，以日期作為分區(qū)鍵，對于重復(fù)主鍵數(shù)據(jù)的去重測試：

4.1.2 CollapsingMergeTree 引擎

該引擎要求在建表語句中指定一個標(biāo)記列 Sign，按照 Sign 的值將行分為兩類：Sign=1 的行稱之為狀態(tài)行，Sign=-1 的行稱之為取消行。每次需要新增狀態(tài)時，寫入一行狀態(tài)行；需要刪除狀態(tài)時，則寫入一行取消行。

使用場景：

按 clickhouse 的架構(gòu)，期合并、折疊操作，都是后臺獨立現(xiàn)場執(zhí)行的，因此時間上并不能控制，何時折疊完成也無法預(yù)知。
如果插入的狀態(tài)行與取消行是亂序的，會導(dǎo)致無法正常折疊

4.1.3 VersionedCollapsingMergeTree 表引擎

為了解決 CollapsingMergeTree 亂序?qū)懭肭闆r下無法正常折疊問題，VersionedCollapsingMergeTree 表引擎在建表語句中新增了一列 Version，用于在亂序情況下記錄狀態(tài)行與取消行的對應(yīng)關(guān)系。

主鍵相同，且 Version 相同、Sign 相反的行，在 Compaction 時會被刪除。

4.2 數(shù)據(jù)副本

數(shù)據(jù)副本放在表引擎這里單獨講一下，是由于只有 MergeTree 系列里的表可支持副本：

ReplicatedMergeTree
ReplicatedSummingMergeTree
ReplicatedReplacingMergeTree
ReplicatedAggregatingMergeTree
ReplicatedCollapsingMergeTree
ReplicatedVersionedCollapsingMergetree
ReplicatedGraphiteMergeTree
副本是表級別的，不是整個服務(wù)器級的。所以，服務(wù)器里可以同時有復(fù)制表和非復(fù)制表。
副本不依賴分片。每個分片有它自己的獨立副本。
要使用副本，必須配置文件中設(shè)置 ZooKeeper 集群的地址。 （京東云提供的 clickhouse 已經(jīng)完成了配置，我們直接使用即可）

<host>example1</host>

</node>

<host>example2</host>

</node>

<host>example3</host>

</node>

</zookeeper>

創(chuàng)建數(shù)據(jù)副本，是通過設(shè)置表引擎位置的參數(shù)來控制的，語法示例：

CREATE TABLE table_name

EventDate DateTime,

CounterID UInt32,

UserID UInt32

)ENGINE=ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/table_name', '{replica}') -- 這里

PARTITION BY toYYYYMM(EventDate)

ORDER BY (CounterID, EventDate, intHash32(UserID))

SAMPLE BY intHash32(UserID)

定義數(shù)據(jù)副本，只需要在以上表引擎名字的前面，帶上 Replicated 即可。

上方例子中，使用的表引擎為 MergeTree，開啟數(shù)據(jù)副本，關(guān)鍵字 Replicated，參數(shù)有 2 個且必填：

zoo_path — ZooKeeper 中該表的路徑。
replica_name — ZooKeeper 中的該表的副本名稱

示例中的取值，采用了變量 {layer}、{shard}、{replica}，他們的值取得是配置文件中的值，影響的是生成的副本粒度。

<replica>example05-02-1.yandex.ru</replica>

</macros>

4.3 Special 系列

Special 系列的表引擎，大多是為了特定場景而定制的。

Memory：將數(shù)據(jù)存儲在內(nèi)存中，重啟后會導(dǎo)致數(shù)據(jù)丟失。查詢性能極好，適合于對于數(shù)據(jù)持久性沒有要求的 1 億一下的小表。在 ClickHouse 中，通常用來做臨時表；
Buffer：為目標(biāo)表設(shè)置一個內(nèi)存 buffer，當(dāng) buffer 達到了一定條件之后會 flush 到磁盤；
File：直接將本地文件作為數(shù)據(jù)存儲；
Null：寫入數(shù)據(jù)被丟棄、讀取數(shù)據(jù)為空。
Distributed：分布式引擎，可以在多個服務(wù)器上進行分布式查詢

4.3.1 Distributed 引擎

分布式表引擎，本身不存儲數(shù)據(jù)，也不占用存儲空間，在定義時需要指定字段，但必須與要映射的表的結(jié)構(gòu)相同。可用于統(tǒng)一查詢 * MergeTree 的每個分片，類比 sharding 中的邏輯表。

比如搬倉系統(tǒng)，使用 ReplicatedReplacingMergeTree 與 Distributed 結(jié)合，實現(xiàn)通過分布式表實現(xiàn)對本地表的讀寫（寫入操作本地表，讀取操作分布式表）。

CREATE TABLE IF NOT EXISTS {distributed_table} as {local_table}

ENGINE = Distributed({cluster}, '{local_database}', '{local_table}', rand())

說明：

distributed_table：分布式表的表名
local_table：本地表名
as local_table：保持分布式表與本地表的表結(jié)構(gòu)一致。此處也可以用（column dataType）這種定義表結(jié)構(gòu)方式代替
cluster：集群名

注意事項：

分布式表本身并不存儲數(shù)據(jù)，只是提供了一個可以分布式訪問數(shù)據(jù)的框架，查詢分布式表的時候 clickhouse 會自動去查詢對應(yīng)的每個本地表中的數(shù)據(jù)，聚合后再返回
注意 AS {local_table}，它表明了分布式表所對應(yīng)的本地表（本地表是存儲數(shù)據(jù)的）
可以配置 Distributed 表引擎中的最后一個參數(shù) rand () 來設(shè)置數(shù)據(jù)條目的分配方式
可以直接往分布式表中寫數(shù)據(jù)，clickhouse 會自動按照上一點所說的方式來分配數(shù)據(jù)和自平衡，數(shù)據(jù)實際會寫到本地表
也可以自己寫分片算法，然后往本地表中寫數(shù)據(jù)【網(wǎng)上資料的場景是每天上千億寫入，性能考慮要直接寫本地表】

4.4 Log 系列

Log 系列表引擎功能相對簡單，主要用于快速寫入小表（1 百萬行左右的表），然后全部讀出的場景。

幾種 Log 表引擎的共性是：

數(shù)據(jù)被順序 Append 寫到磁盤上；
不支持 delete、update；
不支持 index；
不支持原子性寫；
insert 會阻塞 select 操作。

它們彼此之間的區(qū)別是：

TinyLog：不支持并發(fā)讀取數(shù)據(jù)文件，查詢性能較差；格式簡單，適合用來暫存中間數(shù)據(jù)；
StripLog：支持并發(fā)讀取數(shù)據(jù)文件，查詢性能比 TinyLog 好；將所有列存儲在同一個大文件中，減少了文件個數(shù)；
Log：支持并發(fā)讀取數(shù)據(jù)文件，查詢性能比 TinyLog 好；每個列會單獨存儲在一個獨立文件中。

4.5 Integration 系列

該系統(tǒng)表引擎主要用于將外部數(shù)據(jù)導(dǎo)入到 ClickHouse 中，或者在 ClickHouse 中直接操作外部數(shù)據(jù)源。

Kafka：將 Kafka Topic 中的數(shù)據(jù)直接導(dǎo)入到 ClickHouse；
MySQL：將 Mysql 作為存儲引擎，直接在 ClickHouse 中對 MySQL 表進行 select 等操作；猜測：如果有 join 需求，又不想將 mysql 數(shù)據(jù)導(dǎo)入 ck 中
JDBC/ODBC：通過指定 jdbc、odbc 連接串讀取數(shù)據(jù)源；
HDFS：直接讀取 HDFS 上的特定格式的數(shù)據(jù)文件。

5 數(shù)據(jù)類型

clickhouse 支持的數(shù)據(jù)類型如下圖，分為基礎(chǔ)類型、復(fù)合類型、特殊類型。

5.1 CK 與 Mysql 數(shù)據(jù)類型對照

6 SQL 語法 - 常用介紹

6.1 DDL

6.1.1 創(chuàng)建數(shù)據(jù)庫：

CREATE DATABASE [IF NOT EXISTS] db_name [ON CLUSTER cluster];

如果 CREATE 語句中存在 IF NOT EXISTS 關(guān)鍵字，則當(dāng)數(shù)據(jù)庫已經(jīng)存在時，該語句不會創(chuàng)建數(shù)據(jù)庫，且不會返回任何錯誤。

ON CLUSTER 關(guān)鍵字用于指定集群名稱，在集群環(huán)境下必須指定該參數(shù)，否則只會在鏈接的節(jié)點上創(chuàng)建。

6.1.2 創(chuàng)建本地表：

CREATE TABLE [IF NOT EXISTS] [db.]table_name ON CLUSTER cluster

name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],

name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2],

INDEX index_name1 expr1 TYPE type1(...) GRANULARITY value1,

INDEX index_name2 expr2 TYPE type2(...) GRANULARITY value2

) ENGINE = engine_name()

[PARTITION BY expr]

[ORDER BY expr]

[PRIMARY KEY expr]

[SAMPLE BY expr]

[SETTINGS name=value, ...];

選項描述：

db：指定數(shù)據(jù)庫名稱，如果當(dāng)前語句沒有包含‘db’，則默認使用當(dāng)前選擇的數(shù)據(jù)庫為‘db’。
cluster：指定集群名稱，目前固定為 default。ON CLUSTER 將在每一個節(jié)點上都創(chuàng)建一個本地表。
type：該列數(shù)據(jù)類型，例如 UInt32。
DEFAULT：該列缺省值。如果 INSERT 中不包含指定的列，那么將通過表達式計算它的默認值并填充它（與 mysql 一致）。
MATERIALIZED：物化列表達式，表示該列不能被 INSERT，是被計算出來的；在 INSERT 語句中，不需要寫入該列；在 SELECT * 查詢語句結(jié)果集不包含該列；需要指定列表來查詢（虛擬列）
ALIAS ：別名列。這樣的列不會存儲在表中。它的值不能夠通過 INSERT 寫入，同時 SELECT 查詢使用星號時，這些列也不會被用來替換星號。但是它們可以用于 SELECT 中，在這種情況下，在查詢分析中別名將被替換。
物化列與別名列的區(qū)別：物化列是會保存數(shù)據(jù)，查詢的時候不需要計算，而別名列不會保存數(shù)據(jù)，查詢的時候需要計算，查詢時候返回表達式的計算結(jié)果

以下選項與表引擎相關(guān)，只有 MergeTree 系列表引擎支持：

PARTITION BY：指定分區(qū)鍵。通常按照日期分區(qū)，也可以用其他字段或字段表達式。（定義分區(qū)鍵一定要考慮清楚，它影響數(shù)據(jù)分布及查詢性能）
ORDER BY：指定排序鍵。可以是一組列的元組或任意的表達式。
PRIMARY KEY：指定主鍵，默認情況下主鍵跟排序鍵相同。因此，大部分情況下不需要再專門指定一個 PRIMARY KEY 子句。
SAMPLE BY ：抽樣表達式，如果要用抽樣表達式，主鍵中必須包含這個表達式。
SETTINGS：影響性能的額外參數(shù)。
GRANULARITY ：索引粒度參數(shù)。

示例，創(chuàng)建一個本地表：

CREATE TABLE ontime_local ON CLUSTER default -- 表名為 ontime_local

Year UInt16,

Quarter UInt8,

Month UInt8,

DayofMonth UInt8,

DayOfWeek UInt8,

FlightDate Date,

FlightNum String,

Div5WheelsOff String,

Div5TAIlNum String

)ENGINE = ReplicatedMergeTree(--表引擎用ReplicatedMergeTree，開啟數(shù)據(jù)副本的合并樹表引擎）

'/clickhouse/tables/ontime_local/{shard}', -- 指定存儲路徑

'{replica}')

PARTITION BY toYYYYMM(FlightDate) -- 指定分區(qū)鍵，按FlightDate日期轉(zhuǎn)年+月維度，每月做一個分區(qū)

PRIMARY KEY (intHash32(FlightDate)) -- 指定主鍵，F(xiàn)lightDate日期轉(zhuǎn)hash值

ORDER BY (intHash32(FlightDate),FlightNum) -- 指定排序鍵，包含兩列：FlightDate日期轉(zhuǎn)hash值、FlightNunm字符串。

SAMPLE BY intHash32(FlightDate) -- 抽樣表達式，采用FlightDate日期轉(zhuǎn)hash值

SETTINGS index_granularity= 8192 ; -- 指定index_granularity指數(shù)，每個分區(qū)再次劃分的數(shù)量

6.1.3 創(chuàng)建分布式表

基于本地表創(chuàng)建一個分布式表。基本語法：

CREATE TABLE [db.]table_name ON CLUSTER default

AS db.local_table_name

ENGINE = Distributed(<cluster>, <database>, <shard table> [, sharding_key])

參數(shù)說明：

db：數(shù)據(jù)庫名。
local_table_name：對應(yīng)的已經(jīng)創(chuàng)建的本地表表名。
shard table：同上，對應(yīng)的已經(jīng)創(chuàng)建的本地表表名。
sharding_key：分片表達式。可以是一個字段，例如 user_id（integer 類型），通過對余數(shù)值進行取余分片；也可以是一個表達式，例如 rand ()，通過 rand () 函數(shù)返回值 /shards 總權(quán)重分片；為了分片更均勻，可以加上 hash 函數(shù)，如 intHash64 (user_id)。

示例，創(chuàng)建一個分布式表：

CREATE TABLE ontime_distributed ON CLUSTER default -- 指定分布式表的表名，所在集群

AS db_name.ontime_local -- 指定對應(yīng)的本地表的表名

ENGINE = Distributed(default, db_name, ontime_local, rand()); -- 指定表引擎為Distributed（固定）

6.1.4 其他建表

clickhouse 還支持創(chuàng)建其他類型的表：

6.1.5 修改表

語法與 mysql 基本一致：

ALTER TABLE [db].name [ON CLUSTER cluster] ADD|DROP|CLEAR|COMMENT|MODIFY COLUMN …

支持下列動作：

ADD COLUMN — 添加列
DROP COLUMN — 刪除列
CLEAR COLUMN — 重置列的值
COMMENT COLUMN — 給列增加注釋說明
MODIFY COLUMN — 改變列的值類型，默認表達式以及 TTL

舉例：ALTER TABLE bd01.table_1 ADD COLUMN browser String AFTER name; – 在 name 列后面追加一列

6.2 DML

注意：

索引列不支持更新、刪除
分布式表不支持更新、刪除

7 復(fù)雜查詢 JOIN

所有標(biāo)準(zhǔn) SQL JOIN 支持類型（INNER 和 OUTER 可以省略）：

INNER JOIN，只返回匹配的行。
LEFT OUTER JOIN，除了匹配的行之外，還返回左表中的非匹配行。
RIGHT OUTER JOIN，除了匹配的行之外，還返回右表中的非匹配行。
FULL OUTER JOIN，除了匹配的行之外，還會返回兩個表中的非匹配行。
CROSS JOIN，產(chǎn)生整個表的笛卡爾積，“join keys” 是不指定。

查詢優(yōu)化：

A join B 的查詢，比 from A,B,C 多表的性能高很多
global join 會把書記發(fā)送給所有節(jié)點參與計算，針對較小的維度表性能較好
JOIN 會在背地節(jié)點操作，適合于相同分片字段的兩張表關(guān)聯(lián)（A 表與 B 表的分片字段都包含字段 M）
IN 的性能比 JOIN 好，優(yōu)先使用 JOIN
先過濾再 join 效率更好（減低每個分片關(guān)聯(lián)數(shù)據(jù)量級）
在做多表 join 時，A 表的查詢過濾條件中如果能包含與 B 表的 ON expr 中字段過濾條件，性能更好
join 的順序，大表在左，小表在右；ck 查詢時會從右向左執(zhí)行

對比 JOIN 與 IN 的查詢復(fù)雜度：

CK 常用的表引擎會是分布式存儲，因此查詢過程一定是每個分片進行一次查詢，這就導(dǎo)致了 sql 的復(fù)雜度越高，查詢鎖掃描的分片數(shù)量越多，耗時也就越久。

假設(shè) AB 兩個表，分別存儲在 10 個分片中，join 則是查詢 10 次 A 表的同時，join10 次 B 表，合計要 10*10 次。采用 Global join 則會先查詢 10 次并生成臨時表，再用臨時表取和 B 表 join，合計要 10+10 次。

這算是分布式架構(gòu)的查詢特點，如果能干預(yù)數(shù)據(jù)分片規(guī)則，如果查詢條件中帶有分片列，則可以直接定位到包含數(shù)據(jù)的分片上，從而減小查詢次數(shù)。

CK 對于 join 語法上雖然支持，但是性能并不高。當(dāng) join 的左邊是子查詢結(jié)果時，ck 是無法進行分布式 join 的。

8 MySQL 遷移到 CK

數(shù)據(jù)同步成本：clickhouse 可以做到與 mysql 的表結(jié)構(gòu)一致，進而數(shù)據(jù)同步成本較低，不需要調(diào)整數(shù)據(jù)結(jié)構(gòu)、不需要額外做寬表處理（當(dāng)然轉(zhuǎn)為寬表效率更高）。
SQL 遷移成本：支持 jdbc、mybatis 接入；支持標(biāo)準(zhǔn) SQL 的語法；支持 join、in、函數(shù)，SQL 遷移成本較低。

當(dāng)然如果花功夫?qū)Ρ斫Y(jié)構(gòu)、SQL、索引等進行優(yōu)化，能得到更好的查詢效率。

官方支持

在 2020 年下半年，Yandex 公司在 ClickHouse 社區(qū)發(fā)布了 MaterializeMySQL 引擎，支持從 MySQL 全量及增量實時數(shù)據(jù)同步。MaterializeMySQL 引擎目前支持 MySQL 5.6/5.7/8.0 版本，兼容 Delete/Update 語句，及大部分常用的 DDL 操作。

也就是說，CK 支持作為 MySQL 的從節(jié)點存在，依賴訂閱 binlog 方式實現(xiàn)。

https://bbs.huaweicloud.com/blogs/238417

9 總結(jié)

ClickHouse 更加適合 OLAP 場景，在報表庫中有極大性能優(yōu)勢。如果想作為應(yīng)用數(shù)據(jù)庫，可以靈活采用其表引擎特點，盡量避免數(shù)據(jù)修改。其實，沒有最好的，只有最合適的。