• 建表
• 數據存儲
• 主鍵和索引在查詢中的表現
  • 主鍵的選擇
  • 選擇與排序鍵不同的主鍵
  • 索引和分區在查詢中的應用
  • 部分單調主鍵的使用
  • 跳數索引
    • 可用的索引類型
  • 併發數據訪問
  • 列和表的 TTL
    • 列TTL
    • 表TTL
    • 刪除數據
• 使用多個塊設備進行數據存儲
  • • 配置
• 虛擬列
• 資料分享
• 參考文章

Clickhouse中最強大的表引擎當屬MergeTree（合併樹）引擎及該系列（MergeTree）中的其他引擎。MergeTree系列的引擎被設計用於插入極大量的數據到一張表當中。數據可以以數據片段的形式一個接著一個的快速寫入，數據片段在後臺按照一定的規則進行合併。相比在插入時不斷修改（重寫）已存儲的數據，這種策略會高效很多。

主要特點

• 存儲的數據按主鍵排序。這使得您能夠創建一個小型的稀疏索引來加快數據檢索。
• 如果指定了分區鍵的話，可以使用分區。在相同數據集和相同結果集的情況下ClickHouse中某些帶分區的操作會比普通操作更快。查詢中指定了分區鍵時ClickHouse會自動截取分區數據。這也有效增加了查詢性能。
• 支持數據副本。ReplicatedMergeTree系列的表提供了數據副本功能。
• 支持數據採樣。需要的話，您可以給表設置一個採樣方法。

建表

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()
ORDER BY expr
[PARTITION BY expr]
[PRIMARY KEY expr]
[SAMPLE BY expr]
[TTL expr [DELETE|TO DISK 'xxx'|TO VOLUME 'xxx'], ...]
[SETTINGS name=value, ...]

對於建表語句中這個部分的解釋.

• ENGINE:引擎名和參數。ENGINE=MergeTree().MergeTree引擎沒有參數。
• ORDERBY:排序鍵。可以是一組列的元組或任意的表達式。例如:ORDER BY (CounterID,EventDate)。如果沒有使用PRIMARY KEY顯式指定的主鍵，ClickHouse會使用排序鍵作為主鍵。如果不需要排序，可以使用 ORDER BY tuple().
• PARTITION BY:分區鍵，可選項。大多數情況下，不需要分使用區鍵。即使需要使用，也不需要使用比月更細粒度的分區鍵。分區不會加快查詢（這與ORDER BY表達式不同）。永遠也別使用過細粒度的分區鍵。不要使用客戶端指定分區標識符或分區欄位名稱來對數據進行分區（而是將分區欄位標識或名稱作為ORDER BY表達式的第一列來指定分區）。要按月分區，可以使用表達式toYYYYMM(date_column)，這裡的date_column是一個 Date類型的列。分區名的格式會是"YYYYMM"。
• PRIMARY KEY:如果要選擇與排序鍵不同的主鍵，在這裡指定，可選項。預設情況下主鍵跟排序鍵（由ORDER BY 子句指定）相同。因此，大部分情況下不需要再專門指定一個PRIMARY KEY子句。
• SAMPLE BY:用於抽樣的表達式，可選項。如果要用抽樣表達式，主鍵中必須包含這個表達式。例如：SAMPLE BY intHash32(UserID) ORDER BY (CounterID, EventDate, intHash32(UserID))。
• TTL:指定行存儲的持續時間並定義數據片段在硬碟和捲上的移動邏輯的規則列表，可選項。表達式中必須存在至少一個 Date或DateTime類型的列，比如：TTL date + INTERVAl 1 DAY。規則的類型 DELETE|TO DISK 'xxx'|TO VOLUME 'xxx'指定了當滿足條件（到達指定時間）時所要執行的動作：移除過期的行，還是將數據片段（如果數據片段中的所有行都滿足表達式的話）移動到指定的磁碟（TO DISK 'xxx') 或 捲（TO VOLUME 'xxx'）。預設的規則是移除（DELETE）。可以在列表中指定多個規則，但最多只能有一個DELETE的規則。
• SETTINGS:控制 MergeTree 行為的額外參數，可選項：
• index_granularity:索引粒度。索引中相鄰的『標記』間的數據行數。預設值8192 。
• index_granularity_bytes:索引粒度，以位元組為單位，預設值:10Mb。如果想要僅按數據行數限制索引粒度, 可以設置為0,但是不建議。
• min_index_granularity_bytes:允許的最小數據粒度，預設值：1024b。該選項用於防止誤操作，添加了一個非常低索引粒度的表。參考數據存儲
• enable_mixed_granularity_parts:是否啟用通過index_granularity_bytes控制索引粒度的大小。在19.11版本之前, 只有index_granularity配置能夠用於限制索引粒度的大小。當從具有很大的行（幾十上百兆位元組）的表中查詢數據時候，index_granularity_bytes配置能夠提升ClickHouse的性能。如果您的表裡有很大的行，可以開啟這項配置來提升SELECT 查詢的性能。
• use_minimalistic_part_header_in_zookeeper:ZooKeeper中數據片段存儲方式。如果use_minimalistic_part_header_in_zookeeper=1，ZooKeeper會存儲更少的數據。
• min_merge_bytes_to_use_direct_io:使用直接I/O來操作磁碟的合併操作時要求的最小數據量。合併數據片段時，ClickHouse會計算要被合併的所有數據的總存儲空間。如果大小超過了min_merge_bytes_to_use_direct_io設置的位元組數，則ClickHouse將使用直接I/O介面對磁碟讀寫。如果設置min_merge_bytes_to_use_direct_io = 0，則會禁用直接 I/O。預設值：10 * 1024 * 1024 * 1024 位元組。
• merge_with_ttl_timeout:TTL合併頻率的最小間隔時間，單位：秒。預設值:86400(1 天)。
• write_final_mark:是否啟用在數據片段尾部寫入最終索引標記。預設值:1（不要關閉）。
• merge_max_block_size:在塊中進行合併操作時的最大行數限制。預設值：8192
• storage_policy:存儲策略。 參見 使用具有多個塊的設備進行數據存儲.
• min_bytes_for_wide_part,min_rows_for_wide_part:在數據片段中可以使用Wide格式進行存儲的最小位元組數/行數。您可以不設置、只設置一個，或全都設置。
• max_parts_in_total:所有分區中最大塊的數量
• max_compress_block_size:在數據壓縮寫入表前，未壓縮數據塊的最大大小。可以在全局設置中設置該值。建表時指定該值會覆蓋全局設置。
• min_compress_block_size:在數據壓縮寫入表前，未壓縮數據塊的最小大小。可以在全局設置中設置該值。建表時指定該值會覆蓋全局設置。
• max_partitions_to_read:一次查詢中可訪問的分區最大數。您可以在全局設置中設置該值。

數據存儲

表由按主鍵排序的數據片段（DATAPART）組成。

當數據被插入到表中時，會創建多個數據片段並按主鍵的字典序排序。例如，主鍵是(CounterID,Date)時，片段中數據首先按CounterID排序，具有相同CounterID的部分按Date排序。

不同分區的數據會被分成不同的片段，ClickHouse在後臺合併數據片段以便更高效存儲。不同分區的數據片段不會進行合併。合併機制並不保證具有相同主鍵的行全都合併到同一個數據片段中。

數據片段可以以Wide或Compact格式存儲。在Wide格式下，每一列都會在文件系統中存儲為單獨的文件，在Compact格式下所有列都存儲在一個文件中。Compact格式可以提高插入量少插入頻率頻繁時的性能。

數據存儲格式由min_bytes_for_wide_part和min_rows_for_wide_part表引擎參數控制。如果數據片段中的位元組數或行數少於相應的設置值，數據片段會以Compact格式存儲，否則會以Wide格式存儲。

每個數據片段被邏輯的分割成顆粒（granules）。顆粒是ClickHouse中進行數據查詢時的最小不可分割數據集。ClickHouse不會對行或值進行拆分，所以每個顆粒總是包含整數個行。每個顆粒的第一行通過該行的主鍵值進行標記，ClickHouse會為每個數據片段創建一個索引文件來存儲這些標記。對於每列，無論它是否包含在主鍵當中，ClickHouse都會存儲類似標記。這些標記讓您可以在列文件中直接找到數據。

顆粒的大小通過表引擎參數index_granularity和index_granularity_bytes控制。顆粒的行數的在[1,index_granularity]範圍中，這取決於行的大小。如果單行的大小超過了index_granularity_bytes設置的值，那麼一個顆粒的大小會超過index_granularity_bytes。在這種情況下，顆粒的大小等於該行的大小。

主鍵和索引在查詢中的表現

我們以 (CounterID, Date) 以主鍵。排序好的索引的圖示會是下麵這樣：

    全部數據  :     [-------------------------------------------------------------------------]
    CounterID:      [aaaaaaaaaaaaaaaaaabbbbcdeeeeeeeeeeeeefgggggggghhhhhhhhhiiiiiiiiikllllllll]
    Date:           [1111111222222233331233211111222222333211111112122222223111112223311122333]
    標記:            |      |      |      |      |      |      |      |      |      |      |
                    a,1    a,2    a,3    b,3    e,2    e,3    g,1    h,2    i,1    i,3    l,3
    標記號:          0      1      2      3      4      5      6      7      8      9      10

如果指定查詢如下：

CounterID in ('a','h')，伺服器會讀取標記號在 [0, 3) 和 [6, 8) 區間中的數據。
CounterID IN ('a','h') AND Date = 3，伺服器會讀取標記號在 [1, 3) 和 [7, 8) 區間中的數據。
Date = 3，伺服器會讀取標記號在[1, 10]區間中的數據。
上面例子可以看出使用索引通常會比全表描述要高效。

稀疏索引會引起額外的數據讀取。當讀取主鍵單個區間範圍的數據時，每個數據塊中最多會多讀 index_granularity * 2 行額外的數據。

稀疏索引使得您可以處理極大量的行，因為大多數情況下，這些索引常駐於記憶體。

ClickHouse 不要求主鍵唯一，所以可以插入多條具有相同主鍵的行。

可以在PRIMARY KEY與ORDER BY條件中使用可為空的類型的表達式，但強烈建議不要這麼做。為了啟用這項功能，需要打開allow_nullable_key，NULLS_LAST規則也適用於ORDER BY條件中有NULL值的情況下。

主鍵的選擇

主鍵中列的數量並沒有明確的限制。依據數據結構，可以在主鍵包含多些或少些列。一般主鍵的選擇可以按照下麵的規則：

• 改善索引的性能。
• 如果當前主鍵是 (a, b) ，在下列情況下添加另一個 c 列會提升性能：
• 查詢會使用 c 列作為條件
• 很長的數據範圍（index_granularity的數倍）里(a, b)都是相同的值，並且這樣的情況很普遍。換言之，就是加入另一列後，可以讓您的查詢略過很長的數據範圍。
• 改善數據壓縮。ClickHouse以主鍵排序片段數據，所以，數據的一致性越高，壓縮越好。
• 在CollapsingMergeTree和SummingMergeTree引擎里進行數據合併時會提供額外的處理邏輯。在這種情況下，指定與主鍵不同的 排序鍵也是有意義的。

長的主鍵會對插入性能和記憶體消耗有負面影響，但主鍵中額外的列並不影響SELECT查詢的性能。

可以使 ORDER BY tuple()語法創建沒有主鍵的表。在這種情況下ClickHouse根據數據插入的順序存儲。如果在使用INSERT...SELECT時希望保持數據的排序，需要設置 max_insert_threads = 1。

選擇與排序鍵不同的主鍵

Clickhouse可以做到指定一個跟排序鍵不一樣的主鍵，此時排序鍵用於在數據片段中進行排序，主鍵用於在索引文件中進行標記的寫入。這種情況下，主鍵表達式元組必須是排序鍵表達式元組的首碼(即主鍵為(a,b)，排序列必須為(a,b,**))。

當使用SummingMergeTree和AggregatingMergeTree引擎時，這個特性非常有用。通常在使用這類引擎時，表裡的列分兩種：維度和度量。典型的查詢會通過任意的GROUP BY對度量列進行聚合併通過維度列進行過濾。由於SummingMergeTree和AggregatingMergeTree會對排序鍵相同的行進行聚合，所以把所有的維度放進排序鍵是很自然的做法。但這將導致排序鍵中包含大量的列，並且排序鍵會伴隨著新添加的維度不斷的更新。

在這種情況下合理的做法是，只保留少量的列在主鍵當中用於提升掃描效率，將維度列添加到排序鍵中。

對排序鍵進行ALTER是輕量級的操作，因為當一個新列同時被加入到表裡和排序鍵里時，已存在的數據片段並不需要修改。由於舊的排序鍵是新排序鍵的首碼，並且新添加的列中沒有數據，因此在表修改時的數據對於新舊的排序鍵來說都是有序的。

索引和分區在查詢中的應用

對於SELECT查詢，ClickHouse分析是否可以使用索引。如果WHERE/PREWHERE子句具有下麵這些表達式（作為完整WHERE條件的一部分或全部）則可以使用索引：進行相等/不相等的比較；對主鍵列或分區列進行IN運算、有固定首碼的LIKE運算(如name like 'test%')、函數運算(部分函數適用)，還有對上述表達式進行邏輯運算。

因此，在索引鍵的一個或多個區間上快速地執行查詢是可能的。下麵例子中，指定標簽；指定標簽和日期範圍；指定標簽和日期；指定多個標簽和日期範圍等執行查詢，都會非常快。

--表引擎配置
--ENGINE MergeTree() PARTITION BY toYYYYMM(EventDate) ORDER BY (CounterID, EventDate) SETTINGS index_granularity=8192;

--
SELECT count() FROM table WHERE EventDate = toDate(now()) AND CounterID = 34
SELECT count() FROM table WHERE EventDate = toDate(now()) AND (CounterID = 34 OR CounterID = 42)
SELECT count() FROM table WHERE ((EventDate >= toDate('2014-01-01') AND EventDate <= toDate('2014-01-31')) OR EventDate = toDate('2014-05-01')) AND CounterID IN (101500, 731962, 160656) AND (CounterID = 101500 OR EventDate != toDate('2014-05-01'))

ClickHouse 會依據主鍵索引剪掉不符合的數據，依據按月分區的分區鍵剪掉那些不包含符合數據的分區。

上面的查詢顯示，即使索引用於複雜表達式，因為讀表操作經過優化，所以使用索引不會比完整掃描慢。

但是下麵這個就不會走索引。

SELECT count() FROM table WHERE CounterID = 34 OR URL LIKE '%upyachka%'

要檢查 ClickHouse 執行一個查詢時能否使用索引，可設置 force_index_by_date 和 force_primary_key 。

使用按月分區的分區列允許只讀取包含適當日期區間的數據塊，這種情況下，數據塊會包含很多天（最多整月）的數據。在塊中，數據按主鍵排序，主鍵第一列可能不包含日期。因此，僅使用日期而沒有用主鍵欄位作為條件的查詢將會導致需要讀取超過這個指定日期以外的數據。

部分單調主鍵的使用

考慮這樣的場景，比如一個月中的天數。它們在一個月的範圍內形成一個單調序列 ，但如果擴展到更大的時間範圍它們就不再單調了。這就是一個部分單調序列。如果用戶使用部分單調的主鍵創建表，ClickHouse同樣會創建一個稀疏索引。當用戶從這類表中查詢數據時，ClickHouse 會對查詢條件進行分析。如果用戶希望獲取兩個索引標記之間的數據並且這兩個標記在一個月以內，ClickHouse 可以在這種特殊情況下使用到索引，因為它可以計算出查詢參數與索引標記之間的距離。

如果查詢參數範圍內的主鍵不是單調序列，那麼 ClickHouse 無法使用索引。在這種情況下，ClickHouse 會進行全表掃描。

ClickHouse 在任何主鍵代表一個部分單調序列的情況下都會使用這個邏輯。

跳數索引

此索引在 CREATE 語句的列部分里定義。

INDEX index_name expr TYPE type(...) GRANULARITY granularity_value

MergeTree系列的表可以指定跳數索引。跳數索引是指數據片段按照粒度(建表時指定的index_granularity)分割成小塊後，將上述SQL的granularity_value數量的小塊組合成一個大的塊，對這些大塊寫入索引信息，這樣有助於使用where篩選時跳過大量不必要的數據，減少SELECT需要讀取的數據量。具體可以看下麵這個例子。

CREATE TABLE table_name
(
    u64 UInt64,
    i32 Int32,
    s String,
    ...
    INDEX a (u64 * i32, s) TYPE minmax GRANULARITY 3,
    INDEX b (u64 * length(s)) TYPE set(1000) GRANULARITY 4
) ENGINE = MergeTree()
...

上例中的索引能讓 ClickHouse 執行下麵這些查詢時減少讀取數據量。

SELECT count() FROM table WHERE s < 'z'
SELECT count() FROM table WHERE u64 * i32 == 10 AND u64 * length(s) >= 1234

可用的索引類型

• minmax:存儲指定表達式的極值（如果表達式是 tuple ，則存儲 tuple 中每個元素的極值），這些信息用於跳過數據塊，類似主鍵。

• set(max_rows):存儲指定表達式的不重覆值（不超過 max_rows 個，max_rows=0 則表示『無限制』）。這些信息可用於檢查數據塊是否滿足 WHERE 條件。

• ngrambf_v1(n, size_of_bloom_filter_in_bytes, number_of_hash_functions, random_seed):存儲一個包含數據塊中所有 n元短語（ngram） 的 布隆過濾器 。只可用在字元串上。 可用於優化 equals ， like 和 in 表達式的性能。

  1. n – 短語長度。
  2. size_of_bloom_filter_in_bytes – 布隆過濾器大小，位元組為單位。（因為壓縮得好，可以指定比較大的值，如 256 或 512）。
  3. number_of_hash_functions – 布隆過濾器中使用的哈希函數的個數。
  4. random_seed – 哈希函數的隨機種子。

• tokenbf_v1(size_of_bloom_filter_in_bytes, number_of_hash_functions, random_seed):跟ngrambf_v1類似，但是存儲的是token而不是ngrams。Token是由非字母數字的符號分割的序列。

• bloom_filter(bloom_filter([false_positive]):為指定的列存儲布隆過濾器

  可選參數false_positive用來指定從布隆過濾器收到錯誤響應的幾率。取值範圍是 (0,1)，預設值：0.025

  支持的數據類型：Int, UInt, Float*, Enum, Date, DateTime, String, FixedString, Array, LowCardinality, Nullable。

併發數據訪問

對於表的併發訪問，我們使用多版本機制。換言之，當一張表同時被讀和更新時，數據從當前查詢到的一組片段中讀取。沒有冗長的的鎖。插入不會阻礙讀取。

對錶的讀操作是自動並行的。

列和表的 TTL

TTL用於設置值的生命周期，它既可以為整張表設置，也可以為每個列欄位單獨設置。表級別的TTL還會指定數據在磁碟和捲上自動轉移的邏輯。

TTL表達式的計算結果必須是日期或日期時間類型的欄位。

例如:

-- TTL time_column
-- TTL time_column + interval

TTL date_time + INTERVAL 1 MONTH
TTL date_time + INTERVAL 15 HOUR

列TTL

創建列TTL:

CREATE TABLE example_table
(
    d DateTime,
    a Int TTL d + INTERVAL 1 MONTH,
    b Int TTL d + INTERVAL 1 MONTH,
    c String
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(d)
ORDER BY d;

在已有的列創建ttl

ALTER TABLE example_table
    MODIFY COLUMN
    c String TTL d + INTERVAL 1 DAY;

修改列欄位的 TTL

ALTER TABLE example_table
    MODIFY COLUMN
    c String TTL d + INTERVAL 1 MONTH;

表TTL

表可以設置一個用於移除過期行的表達式，以及多個用於在磁碟或捲上自動轉移數據片段的表達式。當表中的行過期時，ClickHouse 會刪除所有對應的行。對於數據片段的轉移特性，必須所有的行都滿足轉移條件。

TTL expr
    [DELETE|TO DISK 'xxx'|TO VOLUME 'xxx'][, DELETE|TO DISK 'aaa'|TO VOLUME 'bbb'] ...
    [WHERE conditions]
    [GROUP BY key_expr [SET v1 = aggr_func(v1) [, v2 = aggr_func(v2) ...]] ]

TTL 規則的類型緊跟在每個 TTL 表達式後面，它會影響滿足表達式時（到達指定時間時）應當執行的操作：

• DELETE:刪除過期的行（預設操作）;
• TO DISK 'aaa':將數據片段移動到磁碟 aaa;
• TO VOLUME 'bbb':將數據片段移動到捲 bbb.
• GROUP BY:聚合過期的行

使用WHERE從句，您可以指定哪些過期的行會被刪除或聚合(不適用於移動)。GROUP BY表達式必須是表主鍵的首碼。如果某列不是GROUP BY表達式的一部分，也沒有在SET從句顯示引用，結果行中相應列的值是隨機的(就好像使用了any函數)。

例子:

-- 創建時指定 TTL
CREATE TABLE example_table
(
    d DateTime,
    a Int
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(d)
ORDER BY d
TTL d + INTERVAL 1 MONTH [DELETE],
    d + INTERVAL 1 WEEK TO VOLUME 'aaa',
    d + INTERVAL 2 WEEK TO DISK 'bbb';

--修改表的 TTL
ALTER TABLE example_table
    MODIFY TTL d + INTERVAL 1 DAY;

-- 創建一張表，設置一個月後數據過期，這些過期的行中日期為星期一的刪除

CREATE TABLE table_with_where
(
    d DateTime,
    a Int
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(d)
ORDER BY d
TTL d + INTERVAL 1 MONTH DELETE WHERE toDayOfWeek(d) = 1;

-- 創建一張表，設置過期的列會被聚合。列x包含每組行中的最大值，y為最小值，d為可能任意值。

CREATE TABLE table_for_aggregation
(
    d DateTime,
    k1 Int,
    k2 Int,
    x Int,
    y Int
)
ENGINE = MergeTree
ORDER BY (k1, k2)
TTL d + INTERVAL 1 MONTH GROUP BY k1, k2 SET x = max(x), y = min(y);

刪除數據

ClickHouse 在數據片段合併時會刪除掉過期的數據。

當ClickHouse發現數據過期時,它將會執行一個計劃外的合併。要控制這類合併的頻率,您可以設置merge_with_ttl_timeout。如果該值被設置的太低,它將引發大量計劃外的合併，這可能會消耗大量資源。

如果在兩次合併的時間間隔中執行SELECT查詢,則可能會得到過期的數據。為了避免這種情況，可以在SELECT之前使用OPTIMIZE。

使用多個塊設備進行數據存儲

MergeTree 系列表引擎可以將數據存儲在多個塊設備上。這對某些可以潛在被劃分為“冷”“熱”的表來說是很有用的。最新數據被定期的查詢但只需要很小的空間。相反，詳盡的歷史數據很少被用到。如果有多塊磁碟可用，那麼“熱”的數據可以放置在快速的磁碟上（比如NVMe固態硬碟或記憶體），“冷”的數據可以放在相對較慢的磁碟上（比如機械硬碟）。

數據片段是MergeTree引擎表的最小可移動單元。屬於同一個數據片段的數據被存儲在同一塊磁碟上。數據片段會在後臺自動的在磁碟間移動，也可以通過ALTER查詢來移動。

配置

磁碟、捲和存儲策略應當在主配置文件 config.xml 或 config.d 目錄中的獨立文件中的 <storage_configuration> 標簽內定義。

磁碟、捲配置如下，disk_name_N> — 磁碟名，名稱必須與其他磁碟不同。path — 伺服器將用來存儲數據 (data 和 shadow 目錄) 的路徑, 應當以 ‘/’ 結尾。keep_free_space_bytes — 需要保留的剩餘磁碟空間。

<storage_configuration>
    <disks>
        <disk_name_1> <!-- disk name -->
            <path>/mnt/fast_ssd/clickhouse/</path>
        </disk_name_1>
        <disk_name_2>
            <path>/mnt/hdd1/clickhouse/</path>
            <keep_free_space_bytes>10485760</keep_free_space_bytes>
        </disk_name_2>
        <disk_name_3>
            <path>/mnt/hdd2/clickhouse/</path>
            <keep_free_space_bytes>10485760</keep_free_space_bytes>
        </disk_name_3>

        ...
    </disks>

    ...
</storage_configuration>

存儲策略配置如下，policy_name_N — 策略名稱，不能重覆。volume_name_N — 捲名稱，不能重覆。
disk — 捲中的磁碟。max_data_part_size_bytes — 捲中的磁碟可以存儲的數據片段的最大大小。move_factor — 當可用空間少於這個因數時，數據將自動的向下一個捲（如果有的話）移動 (預設值為 0.1)。prefer_not_to_merge - 禁止在這個捲中進行數據合併。該選項啟用時，對該捲的數據不能進行合併。這個選項主要用於慢速磁碟。

<storage_configuration>
    ...
    <policies>
        <policy_name_1>
            <volumes>
                <volume_name_1>
                    <disk>disk_name_from_disks_configuration</disk>
                    <max_data_part_size_bytes>1073741824</max_data_part_size_bytes>
                </volume_name_1>
                <volume_name_2>
                    <!-- configuration -->
                </volume_name_2>
                <!-- more volumes -->
            </volumes>
            <move_factor>0.2</move_factor>
        </policy_name_1>
        <policy_name_2>
            <!-- configuration -->
        </policy_name_2>

        <!-- more policies -->
    </policies>
    ...
</storage_configuration>

虛擬列

這個介紹mergeTree表的一些虛擬列。

• _part - 分區名稱。
• _part_index - 作為請求的結果，按順序排列的分區數。
• _partition_id — 分區名稱。
• _part_uuid - 唯一部分標識符（如果 MergeTree 設置assign_part_uuids 已啟用）。
• _partition_value — partition by 表達式的值（元組）。
• _sample_factor - 採樣因數（來自請求）。

資料分享

ClickHouse經典中文文檔分享

參考文章

• ClickHouse(01)什麼是ClickHouse,ClickHouse適用於什麼場景
• ClickHouse(02)ClickHouse架構設計介紹概述與ClickHouse數據分片設計
• ClickHouse(03)ClickHouse怎麼安裝和部署
• ClickHouse(04)如何搭建ClickHouse集群
• ClickHouse(05)ClickHouse數據類型詳解
• ClickHouse(06)ClickHouse建表語句DDL詳細解析

本文來自博客園，作者：張飛的豬，轉載請註明原文鏈接：https://www.cnblogs.com/the-pig-of-zf/p/16855442.html

作者公眾號：張飛的豬大數據分享，不定期分享大數據學習的總結和相關資料，歡迎關註。