1 概述

? 表引擎在ClickHouse中的作用十分關鍵，表引擎有如下作用：

? （1）數據如何存儲，存在哪，數據寫到哪, 怎樣讀取數據；

? （2）支持哪些查詢以及如何支持；

? （3）并發數據訪問；

? （4）索引的使用；

? （5）是否可以執行多線程的請求；

? （6）數據如何同步。

2 表引擎系列

2.1 MergeTree系列

? MergeTree系列是對于高負載任務的最通用和最實用的表引擎。這些引擎共享的屬性是快速數據插入和后續的后臺數據處理。想要高效地一批批寫入數據片段，并希望這些數據片段在后臺按照一定規則合并。相比在插入時不斷修改（重寫）數據進存儲，這種策略會高效很多。MergeTree系列引擎支持數據復制、分區和其他引擎不支持的特性。有如下特點：①數據按照主鍵進行排序；②可以使用分區（如果指定了主鍵）；③支持數據副本；④支持數據采樣

2.1.1 MergeTree

? MergeTree 引擎支持索引，通過主鍵和日期來構建索引, 同時提供 數據的實時更新能力. 這是目前 ClickHouse處理能力最好的引擎。

? 注意：①不能和Merge 引擎相混淆。

? ②MergeTree雖然有主鍵索引，但是其主要作用是加速查詢，而不是類似MySQL等數據庫用來保持記錄唯一。即便在Compaction完成后，主鍵相同的數據行也仍舊共同存在。

? 建表語句如下

CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster] (name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1] [TTL expr1],name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2] [TTL expr2],...INDEX index_name1 expr1 TYPE type1(...) GRANULARITY value1,INDEX index_name2 expr2 TYPE type2(...) GRANULARITY value2 ) ENGINE = MergeTree() [PARTITION BY expr] [ORDER BY expr] [PRIMARY KEY expr] [SAMPLE BY expr] [TTL expr [DELETE|TO DISK 'xxx'|TO VOLUME 'xxx'], ...] [SETTINGS name=value, ...]

? 參數說明：

參數說明

ENGINE = MergeTree()	ENGINE：引擎名和參數
PARTITION BY expr	PARTITION BY：分區鍵，按月分區采用“YYYYMM”格式，可以使用toYYYYMM (date_column)表達式，date_column類型必須是Date
ORDER BY expr	ORDER BY：排序鍵，列的元組或任意表達式 (字段的組合)， 或者單獨的表達式。如:ORDER BY (CounterID, EventDate)
PRIMARY KEY expr	PRIMARY KEY：主鍵，需要與排序鍵字段不同，默認主鍵與排序鍵相同
SAMPLE BY expr	SAMPLE BY：抽樣表達式，要用抽樣表達式，主鍵必須包含這個表達式
TTL expr [DELETE |TO DISK ‘xxx’ TO VOLUME ‘xxx’], …	TTL：指定行存儲時間和定義磁盤與卷之間自動部件移動邏輯的規則列表。如：TTL create_time + INTERVAL 1 MONTH（表數據的生命周期為期一個月 ）它的含義是當ClickHouse合并數據分區時, 會根據create_time這一列的時間數據以及之后一個月的這樣一周期內的數據進行保存，不在這一時間段內的數據，ck就是主動刪除分區目錄下的列文件
SETTINGS name=value, …	SETTINGS：影響MergeTree性能的額外參數 ①index_granularity：索引粒度，索引鍵相鄰標記間的數據行數，默認8192 ②use_minimalistic_part_header_in_zookeeper：在Zookeeper中的存儲方式 ③min_merge_bytes_to_use_direct_io：使用直接I/O來操作磁盤的合并操作時的最小數據量

? 測試：test_mt表的主鍵為(id, create_time)，并且按照主鍵進行存儲排序，按照create_time進行數據分區，根據create_time這一列的時間數據保留最近一個月。

CREATE TABLE test_mt ( \id UInt16, \create_time Date, \comment Nullable(String) \ ) ENGINE = MergeTree() \ PARTITION BY create_time \ ORDER BY (id, create_time) \ PRIMARY KEY (id, create_time) \ TTL create_time + INTERVAL 1 MONTH \ SETTINGS index_granularity=8192;

? 插入數據

insert into test_mt values(0, '2020-01-01', null); insert into test_mt values(0, '2020-01-01', null); insert into test_mt values(1, '2020-01-02', null); insert into test_mt values(2, '2020-01-03', null);

? 查詢數據

SELECT count(*) FROM test_mt ┌─count()─┐ │ 4 │ └─────────┘SELECT * FROM test_mt ┌─id─┬─create_time─┬─comment─┐ │ 2 │ 2020-01-03 │ ???? │ └────┴─────────────┴─────────┘ ┌─id─┬─create_time─┬─comment─┐ │ 1 │ 2020-01-02 │ ???? │ └────┴─────────────┴─────────┘ ┌─id─┬─create_time─┬─comment─┐ │ 0 │ 2020-01-01 │ ???? │ └────┴─────────────┴─────────┘ ┌─id─┬─create_time─┬─comment─┐ │ 0 │ 2020-01-01 │ ???? │ └────┴─────────────┴─────────┘

? 可以發現雖然主鍵id、create_time相同的數據只有3條數據，但是結果卻有4行。因為MergeTree采用類似LSM tree的結構，很多存儲層處理邏輯直到Compaction期間才會發生。因此強制后臺compaction執行

optimize table test_mt final;

? 再次查詢，發現沒有數據了。

SELECT count(*) FROM test_mt ┌─count()─┐ │ 0 │ └─────────┘

? 是因為TTL的原因，我們在表上加了TTL當表內的數據過期時, ClickHouse會刪除所有對應的行。如果是列上加TTL，當列字段中的值過期時, ClickHouse會將它們替換成數據類型的默認值。如果分區內，某一列的所有值均已過期，則ClickHouse會從文件系統中刪除這個分區目錄下的列文件。

? 如果沒有加TTL的查詢出來應該是如下所示

SELECT count(*) FROM test_mt ┌─count()─┐ │ 4 │ └─────────┘select * from test_mt; ┌─id─┬─create_time─┬─comment─┐ │ 2 │ 2020-01-03 │ ???? │ └────┴─────────────┴─────────┘ ┌─id─┬─create_time─┬─comment─┐ │ 1 │ 2020-01-02 │ ???? │ └────┴─────────────┴─────────┘ ┌─id─┬─create_time─┬─comment─┐ │ 0 │ 2020-01-01 │ ???? │ │ 0 │ 2020-01-01 │ ???? │ └────┴─────────────┴─────────┘

?

2.1.2 ReplacingMergeTree

? ReplacingMergeTree在MergeTree的基礎上，添加了處理重復數據的功能，也就是會刪除具有相同主鍵的重復項，這就是與MergeTree的不同之處。

? 注意：數據的去重是在合并的過程中出現的，合并會在未知的時間在后臺運行，所以無法預先做出計劃。所以可能有一些數據任未被處理，因此ReplacingMergeTree適用于在后臺清理重復數據以節省空間，但是不能保證沒有重復的數據出現。

? 語法：

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] [PRIMARY KEY expr] [SAMPLE BY expr] [SETTINGS name=value, ...]

? 參數說明：ENGINE = ReplacingMergeTree([ver])，這個ver是版本列，類型是UInt*，Date或者DateTime，合并的時候ReplacingMergeTree從具有相同主鍵的行中選擇一行留下，如果ver列沒有指定，選擇最后一條，如果ver列已指定，選擇ver最大的版本。其他的參考MergeTree的

? 測試：

CREATE TABLE test_rmt (\id UInt16,\create_time Date,\comment Nullable(String)\ ) ENGINE = ReplacingMergeTree()\PARTITION BY create_time\ORDER BY (id, create_time)\PRIMARY KEY (id, create_time)\TTL create_time + INTERVAL 1 MONTH\SETTINGS index_granularity=8192;

? 插入數據：

insert into test_rmt values(0, '2020-05-01', null); insert into test_rmt values(0, '2020-05-01', null); insert into test_rmt values(1, '2020-05-02', null); insert into test_rmt values(2, '2020-05-03', null);

? 查詢結果：

SELECT count(*) FROM test_rmt ┌─count()─┐ │ 4 │ └─────────┘SELECT * FROM test_rmt ┌─id─┬─create_time─┬─comment─┐ │ 1 │ 2020-05-02 │ ???? │ └────┴─────────────┴─────────┘ ┌─id─┬─create_time─┬─comment─┐ │ 2 │ 2020-05-03 │ ???? │ └────┴─────────────┴─────────┘ ┌─id─┬─create_time─┬─comment─┐ │ 0 │ 2020-05-01 │ ???? │ └────┴─────────────┴─────────┘ ┌─id─┬─create_time─┬─comment─┐ │ 0 │ 2020-05-01 │ ???? │ └────┴─────────────┴─────────┘

? 可以發現數據還是4條，強制后臺compaction

optimize table test_rmt final;

? 再次查詢

SELECT count(*) FROM test_rmt ┌─count()─┐ │ 3 │ └─────────┘SELECT * FROM test_rmt ┌─id─┬─create_time─┬─comment─┐ │ 1 │ 2020-05-02 │ ???? │ └────┴─────────────┴─────────┘ ┌─id─┬─create_time─┬─comment─┐ │ 2 │ 2020-05-03 │ ???? │ └────┴─────────────┴─────────┘ ┌─id─┬─create_time─┬─comment─┐ │ 0 │ 2020-05-01 │ ???? │ └────┴─────────────┴─────────┘

? 總結：雖然ReplacingMergeTree提供了主鍵去重的能力，但是仍舊有以下缺點：①在沒有徹底optimize之前，可能無法達到主鍵去重的效果，部分數據已經去重，部分沒有去重②在分布式情況下，相同primary key的數據可能被sharding到不同節點上，不同shard間可能無法去重③無法預測optimize具體執行時間點④海量數據下要手動執行optimize需要消耗大量時間，無法滿足業務即時查詢的需求

2.1.3 SummingMergeTree

? SummingMergeTree與MergeTree不區別在與當合并SummingMergeTree表的數據片段時，會把相同主鍵的行合并為一行，這一行包含了被合并的行中具有數值數據類型的列的匯總值，對于不可加的列會取出一個最先出現的值。如果相同的主鍵對應大量的行，可以顯著減少存儲空間并加快數據查詢的速度。

? 語法：

CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster] (name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2],... ) ENGINE = SummingMergeTree([columns]) [PARTITION BY expr] [ORDER BY expr] [SAMPLE BY expr] [SETTINGS name=value, ...]

? 參數說明：ENGINE = SummingMergeTree([columns])：[columns]表示將要被匯總的列的列名的元組。

? 測試：

CREATE TABLE test_smt(\date Date,\name String,\money UInt16,\not_sum UInt16\ )\ ENGINE = SummingMergeTree(money)\ PARTITION by date \ ORDER by (date,name);

? 插入數據：

insert into test_smt values ('2020-05-01', 'zs', 6, 1); insert into test_smt values ('2020-05-01', 'ls', 8, 2); insert into test_smt values ('2020-05-02', 'ww', 6, 3); insert into test_smt values ('2020-05-02', 'ww', 8, 4); insert into test_smt values ('2020-05-03', 'zl', 6, 5);

? 查詢：

SELECT * FROM test_smt ┌───────date─┬─name─┬─money─┬─not_sum─┐ │ 2020-05-02 │ ww │ 8 │ 4 │ └────────────┴──────┴───────┴─────────┘ ┌───────date─┬─name─┬─money─┬─not_sum─┐ │ 2020-05-01 │ zs │ 6 │ 1 │ └────────────┴──────┴───────┴─────────┘ ┌───────date─┬─name─┬─money─┬─not_sum─┐ │ 2020-05-03 │ zl │ 6 │ 5 │ └────────────┴──────┴───────┴─────────┘ ┌───────date─┬─name─┬─money─┬─not_sum─┐ │ 2020-05-01 │ ls │ 8 │ 2 │ └────────────┴──────┴───────┴─────────┘ ┌───────date─┬─name─┬─money─┬─not_sum─┐ │ 2020-05-02 │ ww │ 6 │ 3 │ └────────────┴──────┴───────┴─────────┘

? 通過GROUP BY進行聚合查詢

SELECT date, name, sum(money), min(not_sum) FROM test_smt GROUP BY date, name┌───────date─┬─name─┬─sum(money)─┬─min(not_sum)─┐ │ 2020-05-01 │ ls │ 8 │ 2 │ │ 2020-05-02 │ ww │ 14 │ 3 │ │ 2020-05-03 │ zl │ 6 │ 5 │ │ 2020-05-01 │ zs │ 6 │ 1 │ └────────────┴──────┴────────────┴──────────────┘

? 強制compaction

optimize table test_smt final;

? 再次查詢

SELECT * FROM test_smt ┌───────date─┬─name─┬─money─┬─not_sum─┐ │ 2020-05-03 │ zl │ 6 │ 5 │ └────────────┴──────┴───────┴─────────┘ ┌───────date─┬─name─┬─money─┬─not_sum─┐ │ 2020-05-01 │ ls │ 8 │ 2 │ │ 2020-05-01 │ zs │ 6 │ 1 │ └────────────┴──────┴───────┴─────────┘ ┌───────date─┬─name─┬─money─┬─not_sum─┐ │ 2020-05-02 │ ww │ 14 │ 3 │ └────────────┴──────┴───────┴─────────┘

2.1.4 ClollapsingMergeTree

? ClollapsingMergeTree實現了對ReplacingMergeTree功能的限制，在建表語句中指定一個標記列sign，后臺Compaction時會將主鍵相同，sign相反的行進行刪除。ClollapsingMergeTree將行安裝sign的值分為兩類：sign=1為狀態行，sign=-1位取消行。每次需要新增狀態時，寫入一行狀態行，需要刪除狀態時，寫入一行取消行。后臺在Compaction時，狀態行與取消行會自動做折疊（刪除），而尚未進行Compaction的數據，狀態行與取消行同時存在。

? 為了能夠達到主鍵折疊（刪除）的目的，對業務層進行適當改造：①執行刪除操作需要寫入取消行，而取消行中需要包含與原始狀態行主鍵一樣的數據（Sign列除外）。所以在應用層需要記錄原始狀態行的值，或者在執行刪除操作前先查詢數據庫獲取原始狀態行。②由于后臺Compaction時機無法預測，在發起查詢時，狀態行和取消行可能尚未被折疊；另外，ClickHouse無法保證primary key相同的行落在同一個節點上，不在同一節點上的數據無法折疊。因此在進行count(*)、sum(col)等聚合計算時，可能會存在數據冗余的情況。為了獲得正確結果，業務層需要改寫SQL，將count()、sum(col)分別改寫為sum(Sign)、sum(col * Sign)。

? 測試：

CREATE TABLE test_cmt1(\UserID UInt64,\PageViews UInt8,\Duration UInt8,\Sign Int8\ )\ ENGINE = CollapsingMergeTree(Sign)\ ORDER BY UserID;

? 插入狀態行，sign列的值為1

INSERT INTO test_cmt1 VALUES (123456, 6, 88, 1);

? 插入一行取消行，用于抵消上述狀態行。sign列的值為-1，其余值與狀態行一致；并且插入一行主鍵相同的新狀態行，用來將PageViews從6更新至7，將Duration從888更新為889.

INSERT INTO test_cmt1 VALUES (123456, 6, 88, -1), (123456, 7, 90, 1);

? 查詢數據：可以看到未Compaction之前，狀態行與取消行共存。

SELECT * FROM test_cmt1 ┌─UserID─┬─PageViews─┬─Duration─┬─Sign─┐ │ 123456 │ 6 │ 88 │ 1 │ └────────┴───────────┴──────────┴──────┘ ┌─UserID─┬─PageViews─┬─Duration─┬─Sign─┐ │ 123456 │ 6 │ 88 │ -1 │ │ 123456 │ 7 │ 90 │ 1 │ └────────┴───────────┴──────────┴──────┘ 為了獲取正確的sum值，需要改寫SQL： sum(PageViews) => sum(PageViews * Sign)、 sum(Duration) => sum(Duration * Sign) SELECT UserID, sum(PageViews * Sign) AS PageViews, sum(Duration * Sign) AS Duration FROM test_cmt1 GROUP BY UserID HAVING sum(Sign) > 0┌─UserID─┬─PageViews─┬─Duration─┐ │ 123456 │ 7 │ 90 │ └────────┴───────────┴──────────┘

? 強制后臺Compaction

optimize table test_cmt1 final;

? 再次查詢，可以看到狀態行、取消行已經被折疊，只剩下最新的一行狀態行。

SELECT * FROM test_cmt1 ┌─UserID─┬─PageViews─┬─Duration─┬─Sign─┐ │ 123456 │ 7 │ 90 │ 1 │ └────────┴───────────┴──────────┴──────┘

? CollapsingMergeTree雖然解決了主鍵相同的數據即時刪除的問題，但是狀態持續變化且多線程并行寫入情況下，狀態行與取消行位置可能亂序，導致無法正常折疊。

CREATE TABLE test_cmt2(\UserID UInt64,\PageViews UInt8,\Duration UInt8,\Sign Int8\ )\ ENGINE = CollapsingMergeTree(Sign)\ ORDER BY UserID;

? 先插入取消行，然后后插入狀態行

INSERT INTO test_cmt2 VALUES (123456, 6, 88, -1); INSERT INTO test_cmt2 VALUES (123456, 6, 88, 1);

? 強制Compaction

optimize table test_cmt2 final;

? 查詢

select * from test_cmt2;

? 可以看到即便Compaction之后也無法進行主鍵折疊: 2行數據仍舊都存在。

SELECT * FROM test_cmt2 ┌─UserID─┬─PageViews─┬─Duration─┬─Sign─┐ │ 123456 │ 6 │ 88 │ -1 │ │ 123456 │ 6 │ 88 │ 1 │ └────────┴───────────┴──────────┴──────┘

? 為了解決CollapsingMergeTree亂序寫入情況下無法正常折疊問題，VersionedCollapsingMergeTree表引擎在建表語句中新增了一列Version，用于在亂序情況下記錄狀態行與取消行的對應關系。主鍵相同，且Version相同、Sign相反的行，在Compaction時會被刪除。

? 與CollapsingMergeTree類似， 為了獲得正確結果，業務層需要改寫SQL，將count()、sum(col)分別改寫為sum(Sign)、sum(col * Sign)。

2.1.5 AggregatingMergeTree

? AggregatingMergeTree與MergeTree的區別在于會進行預先的聚合，用于提升聚合計算的性能。與SummingMergeTree的區別在于SummingMergeTree對于非主鍵列進行sum聚合，而AggregatingMergeTree則可以指定各種聚合函數。

? AggregatingMergeTree需要結合物化視圖或者ClickHouse的特殊數據類型ArrregateFunction一起使用，在insert寫入的時候需要使用-State語法，在select查詢的時候使用-Merge語法。

? 語法：

CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster] (name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2],... ) ENGINE = AggregatingMergeTree() [PARTITION BY expr] [ORDER BY expr] [SAMPLE BY expr] [TTL expr] [SETTINGS name=value, ...]

? （1）結合物化視圖

CREATE TABLE test_amt1(\UserID UInt64,\CounterID UInt8,\StartDate Date,\Sign Int8\ )\ ENGINE = CollapsingMergeTree(Sign)\ ORDER BY UserID;

? 對test_amt建立物化視圖，進行預先聚合。預先聚合使用的函數分別為： sumState, uniqState。對應于寫入語法-State.

CREATE MATERIALIZED VIEW test_amt1_view\ ENGINE = AggregatingMergeTree() PARTITION BY toYYYYMM(StartDate) ORDER BY (CounterID, StartDate)\ AS SELECT\CounterID,\StartDate,\sumState(Sign) AS Visits,\uniqState(UserID) AS Users\ FROM test_amt1\ GROUP BY CounterID, StartDate;

? 插入數據

INSERT INTO test_amt1 VALUES(123, 0, '2020-05-01', 3); INSERT INTO test_amt1 VALUES(123, 1, '2020-05-01', 3); INSERT INTO test_amt1 VALUES(111, 2, '2020-05-02', 2);

? 對物化視圖進行最終的聚合操作。使用的聚合函數為 sumMerge， uniqMerge。

SELECT \StartDate, \sumMerge(Visits) AS Visits, \uniqMerge(Users) AS Users\ FROM test_amt1_view \ GROUP BY StartDate\ ORDER BY StartDate ASC┌──StartDate─┬─Visits─┬─Users─┐ │ 2020-05-01 │ 6 │ 1 │ │ 2020-05-02 │ 2 │ 1 │ └────────────┴────────┴───────┘

? 普通函數 sum, uniq不再可以使用,會報錯： Illegal type AggregateFunction(sum, Int8) of argument

? （2）配合特殊數據類型AggregateFunction使用

CREATE TABLE test_amt2(\CounterID UInt8,\StartDate Date,\Money UInt64,\UserID UInt64\ ) ENGINE = MergeTree() \ PARTITION BY toYYYYMM(StartDate) \ ORDER BY (CounterID, StartDate);

? 插入數據

INSERT INTO test_amt2 VALUES(111, '2020-05-01', 10, 1); INSERT INTO test_amt2 VALUES(111, '2020-05-01', 12, 5); INSERT INTO test_amt2 VALUES(122, '2020-05-02', 9, 2);

? 建立預先聚合表，其中UserID一列的類型為：AggregateFunction(uniq, UInt64)

CREATE TABLE test_amt2_agg(\CounterID UInt8,\StartDate Date,\Money AggregateFunction(sum, UInt64),\UserID AggregateFunction(uniq, UInt64)\ ) ENGINE = AggregatingMergeTree() \ PARTITION BY toYYYYMM(StartDate) \ ORDER BY (CounterID, StartDate);

? 從明細表中讀取數據，插入聚合表，子查詢中使用的聚合函數為 uniqState

INSERT INTO test_amt2_agg SELECT \CounterID, \StartDate, \sumState(Money),\uniqState(UserID)\ FROM test_amt2 \ GROUP BY \CounterID, \StartDate

? 注意：不能使用普通insert語句向AggregatingMergeTree中插入數據。會報錯：Cannot convert UInt64 to AggregateFunction(uniq, UInt64)

? 從聚合表中查詢，select中使用的聚合函數為uniqMerge

SELECT CounterID,StartDate,sumMerge(Money),uniqMerge(UserID) AS state\ FROM test_amt2_agg \ GROUP BY \CounterID, \StartDateSELECT CounterID, StartDate, sumMerge(Money), uniqMerge(UserID) AS state FROM test_amt2_agg GROUP BY CounterID, StartDate┌─CounterID─┬──StartDate─┬─sumMerge(Money)─┬─state─┐ │ 122 │ 2020-05-02 │ 9 │ 1 │ │ 111 │ 2020-05-01 │ 22 │ 2 │ └───────────┴────────────┴─────────────────┴───────┘

?

2.2 Log系列

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

? 特點：

? （1）數據被順序append寫到磁盤上。

? （2）不支持delete、update。

? （3）不支持index。

? （4）不支持原子性寫。

? （5）insert會阻塞select操作。

? TinyLog，StripLog，Log區別如下：①TinyLog：不支持并發讀取數據文件，查詢性能較差；格式簡單，適合用來暫存中間數據。②StripLog：支持并發讀取數據文件，查詢性能比TinyLog好；將所有列存儲在同一個大文件中，減少了文件個數。③Log：支持并發讀取數據文件，查詢性能比TinyLog好；每個列會單獨存儲在一個獨立文件中。

2.2.1 TinyLog

? 最簡單的表引擎，用于將數據存儲在磁盤上。每列都存儲在單獨的壓縮文件中，寫入時，數據將附加到文件末尾。該引擎沒有并發控制，如果同時從表中讀取和寫入數據，則讀取操作將拋出異常；如果同時寫入多個查詢中的表，則數據將被破壞。
不支持索引。

? 測試：

CREATE TABLE test_tl (\id UInt16,\name String)\ ENGINE=TinyLog;

? 插入數據：

INSERT INTO test_tl (id, name) values (1, 'zs');

? 進入ClickHouse的test_tl表的數據存儲目錄

[root@ambari01 test_tl]# cd /data/clickhouse/data/test/test_tl[root@ambari01 test_tl]# ll total 12 -rw-r----- 1 clickhouse hadoop 28 May 22 18:07 id.bin -rw-r----- 1 clickhouse hadoop 29 May 22 18:07 name.bin -rw-r----- 1 clickhouse hadoop 64 May 22 18:07 sizes.json

? id.bin和name.bin是壓縮過的對應的列的數據，sizes.json 中記錄了每個 *.bin 文件的大小。

[root@ambari01 test_tl]# cat sizes.json {"yandex":{"id%2Ebin":{"size":"28"},"name%2Ebin":{"size":"29"}}}

2.3 Integration系列

? 該系統表引擎主要用于將外部數據導入到ClickHouse中，或者在ClickHouse中直接操作外部數據源。

2.3.1 Kafka

? 將Kafka Topic中的數據直接導入到ClickHouse。

2.3.2 MySQL

? 將Mysql作為存儲引擎，直接在ClickHouse中對MySQL表進行select等操作。

2.3.3 JDBC/ODBC

? 通過指定jdbc、odbc連接串讀取數據源。

2.3.4 HDFS

? 直接讀取HDFS上的特定格式的數據文件；

2.4 Special系列

? Special系列的表引擎，是為了特定場景而定制的，不做詳述。

? Memory：將數據存儲在內存中，重啟后會導致數據丟失。查詢性能極好，適合于對于數據持久性沒有要求的1億一下的小表。在ClickHouse中，通常用來做臨時表。

? Buffer：為目標表設置一個內存buffer，當buffer達到了一定條件之后會flush到磁盤。

? File：直接將本地文件作為數據存儲。

? Null：寫入數據被丟棄、讀取數據為空。

總結

以上是生活随笔為你收集整理的ClickHouse表引擎的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。