MergeTree引擎以及隶属于MergeTree引擎族的所有引擎是Clickhouse表引擎中最重要, 最强大的引擎. MergeTree引擎族中的引擎被设计用于将大量数据写入表中. 这些数据被快速的写入每个表的每个part, 然后在Clickhouse底层会进行多个parts的合并(merge). 这种形式的处理比在插入过程中不断重写存储中的数据要高效得多. 主要的功能点:
  • 存储按主键(primary key)排序的数据.这允许用户可以创建一个小型的稀疏索引, 有利于更快的在表中找到索要的数据.
  • 如果partitioning key被设置, 分片(partitions)可以被使用.Clickhouse支持某些带分区的操作, 对于同一份数据进行处理, 带有分区的操作会比一般操作更有效. 当在查询语句中指定了分区后, Clickhouse会根据分区信息来进行数据的切分, 这样极大程度上提升了查询的性能.
  • 数据副本机制支持(Replication)ReplicatedMergeTree并引擎提供了数据副本机制.
  • 支持数据采样如果必要, 可以在表中设置数据采样方式.

1. 创建表#

1.1. 建表语句

  1. CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
  2. (
  3. name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1] [TTL expr1],
  4. name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2] [TTL expr2],
  5. ...
  6. INDEX index_name1 expr1 TYPE type1(...) GRANULARITY value1,
  7. INDEX index_name2 expr2 TYPE type2(...) GRANULARITY value2
  8. ) ENGINE = MergeTree()
  9. ORDER BY expr
  10. [PARTITION BY expr]
  11. [PRIMARY KEY expr]
  12. [SAMPLE BY expr]
  13. [TTL expr [DELETE|TO DISK 'xxx'|TO VOLUME 'xxx'], ...]
  14. [SETTINGS name=value, ...]

1.2. 参数说明

  • ENGINE: 指定该表所使用的的引擎. 如果引擎需要一些具体的参数, 需要进行相应的设置, MergeTree引擎不需要, 例如ReplicatedMergeTree:Copy ENGINE=ReplicatedMergeTree(‘/clickhouse/tables/#tenant_id#/#appname#/#at_date#/{shard}/hits’, ‘{replica}’)
  • ORDER BY: 按指定字段进行排序支持设置的值为元组(一个列名或任意多字段表达式), 例如:Copy ORDER BY (CounterID, EventDate)如果创建表的时候, 没有使用PRIMARY KEY修饰词来显式指定主键, 那么Clickhouse会将ORDER BY指定的字段作为主键处理.如果该表不需要排序, 可以使用ORDER BY tuple()语法.
  • PARTITION BY: 指定分区字段, 可选分区字段一般是一个Date类型或者DateTime类型的字段. 如果想按照月进行分区, 可以使用toYYYYMM(date_column)表达式, 那么分区字段的格式就是YYYYMM.
  • PAIMARY KEY: 主键, 可选默认情况下, 在Clickhouse中主键都是和排序字段(ORDER BY子句指定字段)是一致的, 所以在大多数情况下, 不需要单独指定主键. 如果需要两者不一致, 详情可见differs from the sorting key.
  • SAMPLE BY: 取样表达式, 可选如果使用了SAMPLE BY子句, 那么SAMPLE BY指定的字段必须是主键(或排序字段)所包含的字段. 例如:
  1. SAMPLE BY intHash32(USERID)
  2. ORDER BY (CounterID, EventDate, intHash32(UserID))
  • TTL: 一些被指定的规则, 涉及存储数据行的存储时长, 以及确定数据parts的自动移除逻辑. 可选TTL表达式必须包含一个Date类型或者DateTime类型的字段作为一个结果值, 例如:Copy TTL date + INTERVAL 1 DAY这种类型的规则DELETE|TO DISK ‘xxx’|TO VOLUME ‘xxx’指定了当表达式条件被满足时对数据parts处理的操作: 删除过期的行, 移除数据parts(如果该数据parts中所有的行都满足条件)到指定的位置TO DISK ‘XXX’.规则的默认类型是DELETE. 可以指定多个规则组成一条表达式, 但是DELETE规则不成超过一条.查看更多细节: TTL for columns and tables.
  • SETTINGS: 设置MergeTree引擎的附加的参数, 可选 - index_graularity索引标记之间的最大数据行数. 默认值: 8192. - index_graularity_bytes数据颗粒的最大大小, 单位bytes, 默认值: 10MB. 若要仅按行数限制颗粒大小, 请设置为0(不推荐). - min_index_granularity_bytes数据颗粒的最小大小, 单位bytes, 默认值: 1024b. 该值是为了防止意外创建index_graularity_bytes值很低的表. - enable_mixed_granularity_parts同样是设置数据颗粒的最大大小, 该参数用于过渡取代index_graularity_bytes. 在v19.11版本前, 只有index_granularity用于控制颗粒大小.当查询数据涉及到大量的行(几十或几百兆)时, index_granularity_bytes参数提高了Clickhouse的性能. 如果你的表拥有大量的行时, 可以为表启用这个参数来提高查询的性能. - use_minimalistic_part_header_in_zookeeper在Zookeeper中数据parts_headers存储的方式. 如果设置为1, 则Zookeeper中存储的数据较少, 具体可以参考setting description. - min_merge_bytes_to_use_direct_io使用直接I/O访问存储磁盘所需的merge操作的最小数据量. merge数据parts时, Clickhouse会计算所有要合并的数据的总存储空间, 如果超过min_merge_bytes_to_use_direct_io设定的值, Clickhouse会使用直接I/O接口(O_DIRECT选项)读取和写入数据到磁盘. 如果设置为0, 则直接I/O被禁用, 默认值: 10M. - merge_with_ttl_timeout重复合并TTL的最小延迟时间, 单位秒, 默认值: 1 day. - write_final_mark启用或禁用在数据部分的末尾(最后一个字节之后)写入最后的索引标记. 默认值: 1, 不要关闭. - merge_max_block_size合并操作时, 每个块的最大行数, 默认值: 8192. - storage_policy存储策略, 详见Using Multiple Block Devices for Data Storage. - min_bytes_for_wide_part, min_rows_for_wide_part数据部分中可存储为Wide格式的最小字节数/行数. 可以设置这些设置中的一个, 两个或全部.

1.3. 样例说明

  1. ENGINE MergeTree()
  2. PARTITION BY toYYYYMM(EventDate)
  3. ORDER BY (CounterID, EventDate, intHash32(UserID))
  4. SAMPLE BY intHash32(UserID)
  5. SETTINGS index_granularity=8192
在这个样例中, 设置了按月份进行分区. 同时设置了一个表达式 -> 按用户ID进行Hash采样. 这样就可以为每个CounterID和EventDate伪随机化(pseudorandomize)表中的数据. 如果你在选择数据时定义了一个SAMPLE子句, Clickhouse将会为用户的子集返回一个均匀的伪随机化的数据样本. index_granularity设置可以省略, 因为8192是默认值.

2. 数据存储#

一个表由按主键排序的数据parts组成. 当在表中插入数据时, 会创建单独的数据parts, 并对每个数据parts按主键进行字典排序. 例如, 如果主键是(CounterID, Date), 则该部分的数据会按照CounterID排序, 在每个CounterID内, 再按照Date排序. 属于不同分片的数据会被分隔成不同的part. 在Clickhouse底层, ck合并数据parts成为更有效的存储结构. 属于不同分片的parts不会被merge. Merge机制并不能保证所有具有相同主键的行都在同一个数据parts. 数据parts可以用宽(Wide)或者紧凑(Compact)格式来存储. 在Wide格式中, 每一列都会被存储在磁盘的一个单独的文件中, 在Compact格式中, 所有的列都会被存在在同一个文件中. Compact格式可以用来提高小规模和频繁插入的性能(涉及到写入到更少的文件中). 数据存储格式有表引擎的min_bytes_for_wide_partmin_rows_for_wide_part参数控制. 如果数据parts的字节数小于相应的设置项, 则该部分以Compact格式存储, 反之以Wide格式存储. 如果这两个参数未被设置, 将会默认以Wide格式存储. 每个数据part在逻辑上被划分成颗粒(granule). 一个颗粒是Clickhouse在读取选中数据时, 最小的不可分割的数据集单位. Clickhouse不会拆分行或者字段值, 所以每个颗粒总是包含整数单位的行. 颗粒的第一行是用该行的主键值进行标记的. 对于每个数据part来说, Clickhouse都会创建一个索引文件来存储这些标记(mark). 对于每一列而言, 无论它是否是主键, Clickhouse都会存储相同的标记. 这些标记可以帮助查询的时候直接在列文件中找到数据. 颗粒的大小收到表引擎index_granularityindex_granularity_bytes参数的限制. 根据行的大小, 一个颗粒中的行数在[1, index_granularity]范围内. 如果单行的大小大于设置值, 那么颗粒的大小可以超过index_granularity_bytes. 在这种情况下, 颗粒的大小等于行的大小.