目錄
- 建表
- 資料存盤
- 主鍵和索引在查詢中的表現
- 主鍵的選擇
- 選擇與排序鍵不同的主鍵
- 索引和磁區在查詢中的應用
- 部分單調主鍵的使用
- 跳數索引
- 可用的索引型別
- 并發資料訪問
- 列和表的 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 運算式的性能,
- n – 短語長度,
- size_of_bloom_filter_in_bytes – 布隆過濾器大小,位元組為單位,(因為壓縮得好,可以指定比較大的值,如 256 或 512),
- number_of_hash_functions – 布隆過濾器中使用的哈希函式的個數,
- 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
作者公眾號:張飛的豬大資料分享,不定期分享大資料學習的總結和相關資料,歡迎關注,
轉載請註明出處,本文鏈接:https://www.uj5u.com/shujuku/526938.html
標籤:其他
