• Clickhouse


    Clickhouse - MergeTree原理

    MergeTree引擎以及隶属于MergeTree引擎族的所有引擎是Clickhouse表引擎中最重要, 最强大的引擎.

    MergeTree引擎族中的引擎被设计用于将大量数据写入表中. 这些数据被快速的写入每个表的每个part, 然后在Clickhouse底层会进行多个parts的合并(merge). 这种形式的处理比在插入过程中不断重写存储中的数据要高效得多.

    主要的功能点:

    • 存储按主键(primary key)排序的数据.

      这允许用户可以创建一个小型的稀疏索引, 有利于更快的在表中找到索要的数据.

    • 如果partitioning key被设置, 分片(partitions)可以被使用.

      Clickhouse支持某些带分区的操作, 对于同一份数据进行处理, 带有分区的操作会比一般操作更有效. 当在查询语句中指定了分区后, Clickhouse会根据分区信息来进行数据的切分, 这样极大程度上提升了查询的性能.

    • 数据副本机制支持(Replication)

      ReplicatedMergeTree并引擎提供了数据副本机制.

    • 支持数据采样

      如果必要, 可以在表中设置数据采样方式.

    1. 创建表

    1.1. 建表语句

    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, ...]
    

    1.2. 参数说明

    • ENGINE: 指定该表所使用的的引擎. 如果引擎需要一些具体的参数, 需要进行相应的设置, MergeTree引擎不需要, 例如ReplicatedMergeTree:

      ENGINE=ReplicatedMergeTree('/clickhouse/tables/#_tenant_id_#/#__appname__#/#_at_date_#/{shard}/hits', '{replica}')
      
    • ORDER BY : 按指定字段进行排序

      支持设置的值为元组(一个列名或任意多字段表达式), 例如:

      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指定的字段必须是主键(或排序字段)所包含的字段. 例如:

      SAMPLE BY intHash32(USERID)
      ORDER BY (CounterID, EventDate, intHash32(UserID))
      
    • TTL: 一些被指定的规则, 涉及存储数据行的存储时长, 以及确定数据parts的自动移除逻辑. 可选

      TTL表达式必须包含一个Date类型或者DateTime类型的字段作为一个结果值, 例如:

      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. 样例说明

    ENGINE MergeTree() 
    PARTITION BY toYYYYMM(EventDate) 
    ORDER BY (CounterID, EventDate, intHash32(UserID)) 
    SAMPLE BY intHash32(UserID) 
    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. 在这种情况下, 颗粒的大小等于行的大小.

  • 相关阅读:
    ubuntu应用商店打不开怎么办
    java线程池系列(1)-ThreadPoolExecutor实现原理
    java并发之SynchronousQueue实现原理
    java并发等待条件的实现原理(Condition)
    轻松掌握java读写锁(ReentrantReadWriteLock)的实现原理
    Java NIO 内存映射文件
    Java NIO Path接口和Files类配合操作文件
    Java 序列化 序列化与单例模式 [ 转载 ]
    Java 序列化 JDK序列化总结
    Java 泛型 Java使用泛型的意义
  • 原文地址:https://www.cnblogs.com/yisany/p/13889399.html
Copyright © 2020-2023  润新知