表引擎（即表的类型）决定了：
    1）数据的存储方式和位置，写到哪里以及从哪里读取数据
    2）支持哪些查询以及如何支持。
    3）并发数据访问。
    4）索引的使用（如果存在）。
    5）是否可以执行多线程请求。
    6）数据复制参数。
    ClickHouse的表引擎有很多，下面介绍其中几种，对其他引擎有兴趣的可以去查阅官方文档：官方文档
    TinyLog
    最简单的表引擎，用于将数据存储在磁盘上。每列都存储在单独的压缩文件中，写入时，数据将附加到文件末尾。
    该引擎没有并发控制

    • 如果同时从表中读取和写入数据，则读取操作将抛出异常；
    • 如果同时写入多个查询中的表，则数据将被破坏。

    这种表引擎的典型用法是 write-once：首先只写入一次数据，然后根据需要多次读取。此引擎适用于相对较小的表（建议最多1,000,000行）。如果有许多小表，则使用此表引擎是适合的，因为它比需要打开的文件更少。当拥有大量小表时，可能会导致性能低下。 不支持索引。
    案例：创建一个TinyLog引擎的表并插入一条数据

    1. :)create table t (a UInt16, b String) ENGINE = TinyLog;
    2. :)insert into t (a, b) values (1, 'abc');

    此时我们到保存数据的目录/var/lib/clickhouse/data/default/t中可以看到如下目录结构：

    1. [root@hadoop102 t]# ls
    2. a.bin  b.bin  sizes.json

    a.bin 和 b.bin 是压缩过的对应的列的数据， sizes.json 中记录了每个 *.bin 文件的大小：

    1. [root@hadoop102 t]# cat sizes.json 
    2. {"yandex":{"a%2Ebin":{"size":"28"},"b%2Ebin":{"size":"30"}}}

    Memory
    内存引擎，数据以未压缩的原始形式直接保存在内存当中，服务器重启数据就会消失。读写操作不会相互阻塞，不支持索引。简单查询下有非常非常高的性能表现（超过10G/s）。
    一般用到它的地方不多，除了用来测试，就是在需要非常高的性能，同时数据量又不太大（上限大概 1 亿行）的场景。
    Merge
    Merge 引擎 (不要跟 MergeTree 引擎混淆) 本身不存储数据，但可用于同时从任意多个其他的表中读取数据。 读是自动并行的，不支持写入。读取时，那些被真正读取到数据的表的索引（如果有的话）会被使用。
    Merge 引擎的参数：一个数据库名和一个用于匹配表名的正则表达式。
    案例：先建t1，t2，t3三个表，然后用 Merge 引擎的 t 表再把它们链接起来。

    1. :)create table t1 (id UInt16, name String) ENGINE=TinyLog;
    2. :)create table t2 (id UInt16, name String) ENGINE=TinyLog;
    3. :)create table t3 (id UInt16, name String) ENGINE=TinyLog;
    4. :)insert into t1(id, name) values (1, 'first');
    5. :)insert into t2(id, name) values (2, 'second');
    6. :)insert into t3(id, name) values (3, 'i am in t3');
    7. :)create table t (id UInt16, name String) ENGINE=Merge(currentDatabase(), '^t');
    8. :) select * from t;
    9. ┌─id─┬─name─┐
    10. │  2 │ second │
    11. └────┴──────┘
    12. ┌─id─┬─name──┐
    13. │  1 │ first │
    14. └────┴───────┘
    15. ┌─id─┬─name───────┐
    16. │ 3     │ i am in t3 │
    17. └────┴────────────┘

    MergeTree
    Clickhouse 中最强大的表引擎当属 MergeTree （合并树）引擎及该系列（*MergeTree）中的其他引擎。
    MergeTree 引擎系列的基本理念如下。当你有巨量数据要插入到表中，你要高效地一批批写入数据片段，并希望这些数据片段在后台按照一定规则合并。相比在插入时不断修改（重写）数据进存储，这种策略会高效很多。
    格式：
    ENGINE = MergeTree()
    [PARTITION BY expr] PARTITION BY 分区键 只能按照日期分区 eg：按月份分区 toYYYYMM(datecolumn)
    [ORDER BY expr] ORDER BY 排序键,可以是一组列的元组或者任意表达式 例如（ORDER BY(id，name)）排序
    [PRIMARY KEY expr] 主键 ，（如果不写PRIMARY KEY默认以ORDER BY作为主键，如果指定主键不能和order by 一样）
    [SAMPLE BY expr] 用于抽样表达式 ， 如果写了此参数，要用抽样表达式，则主键中必须包含这个表达式
    [SETTINGS name=value,…] SETTINGS :MergeTree的额外参数：
    min_merge_bytes_to_use_direct_io 使用直接 I/O 来操作磁盘的合并操作时要求的最小数据量。合并数据片段时，ClickHouse 会计算要被合并的所有数据的总存储空间。如果大小超过了 min_merge_bytes_to_use_direct_io时，ClickHouse 会计算要被合并的所有数据的总存储空间。如果大小超过了 min_merge_bytes_to_use_direct_io设置的字节数，则 ClickHouse 将使用直接 I/O 接口 否则使用缓存i/o
    use_minimalistic_part_header_in_zookeeper — 数据片段头在 ZooKeeper 中的存储方式。如果设置了
    use_minimalistic_part_header_in_zookeeper=1 ，ZooKeeper 会存储更少的数据。
    index_granularity — 索引粒度。即索引中相邻『标记』间的数据行数。默认值，8192

    1. index_granularity — 索引粒度。即索引中相邻『标记』间的数据行数。默认值，8192 。该列表中所有可用的参数可以从这里查看 MergeTreeSettings.h 。
    2. index_granularity_bytes — 索引粒度，以字节为单位，默认值: 10Mb。如果仅按数据行数限制索引粒度, 请设置为0(不建议)。
    3. enable_mixed_granularity_parts — 启用或禁用通过 index_granularity_bytes 控制索引粒度的大小。在19.11版本
    4. 之前, 只有 index_granularity 配置能够用于限制索引粒度的大小。当从大表(数十或数百兆)中查询数据时
    5. 候，index_granularity_bytes 配置能够提升ClickHouse的性能。如果你的表内数据量很大，可以开启这项配置用以提升SELECT 查询的性能。
    6. use_minimalistic_part_header_in_zookeeper — 数据片段头在 ZooKeeper 中的存储方式。如果设置了use_minimalistic_part_header_in_zookeeper=1 ，ZooKeeper 会存储更少的数据。更多信息参考『服务配置参数』这章中的 设置描述 。
    7. min_merge_bytes_to_use_direct_io — 使用直接 I/O 来操作磁盘的合并操作时要求的最小数据量。合并数据片段时，ClickHouse 会计算要被合并的所有数据的总存储空间。如果大小超过了 min_merge_bytes_to_use_direct_io时，ClickHouse 会计算要被合并的所有数据的总存储空间。如果大小超过了 min_merge_bytes_to_use_direct_io设置的字节数，则 ClickHouse 将使用直接 I/O 接口（O_DIRECT 选项）对磁盘读写。如果设置min_merge_bytes_to_use_direct_io = 0 ，则会禁用直接 I/O。默认值：10 * 1024 * 1024 * 1024 字节。=10G
    8. merge_with_ttl_timeout — TTL合并频率的最小间隔时间。默认值: 86400 (1 天)。
    9. write_final_mark — 启用或禁用在数据片段尾部写入最终索引标记。默认值: 1（不建议更改）。
    10. storage_policy — 存储策略。 参见 使用多个区块装置进行数据存储.

    格式：

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

    参数解读：

    1. date-column — 类型为 Date 的列名。ClickHouse 会自动依据这个列按月创建分区。分区名格式为 "YYYYMM" 。
    2. sampling_expression — 采样表达式。
    3. (primary, key) — 主键。类型为Tuple()
    4. index_granularity — 索引粒度。即索引中相邻”标记”间的数据行数。设为 8192 可以适用大部分场景。

    案例：

    1. create table mt_table (date  Date, id UInt8, name String) ENGINE=MergeTree(date, (id, name), 8192);
    2. insert into mt_table values ('2019-05-01', 1, 'zhangsan');
    3. insert into mt_table values ('2019-06-01', 2, 'lisi');
    4. insert into mt_table values ('2019-05-03', 3, 'wangwu');
    5. 在/var/lib/clickhouse/data/default/mt_tree下可以看到：
    6. [root@hadoop102 mt_table]# ls
    7. 20190501_20190501_2_2_0  20190503_20190503_6_6_0  20190601_20190601_4_4_0  detached

    随便进入一个目录：

    1. [root@hadoop102 20190601_20190601_4_4_0]# ls
    2. checksums.txt  columns.txt  date.bin  date.mrk  id.bin  id.mrk  name.bin  name.mrk  primary.idx
    • *.bin是按列保存数据的文件
    • *.mrk保存块偏移量
    • primary.idx保存主键索引

    ReplacingMergeTree
    这个引擎是在 MergeTree 的基础上，添加了“处理重复数据”的功能，该引擎和MergeTree的不同之处在于它会删除具有相同主键的重复项。数据的去重只会在合并的过程中出现。合并会在未知的时间在后台进行，所以你无法预先作出计划。有一些数据可能仍未被处理。因此，ReplacingMergeTree 适用于在后台清除重复的数据以节省空间，但是它不保证没有重复的数据出现。
    格式：

    1. ENGINE [=] ReplacingMergeTree(date-column [, sampling_expression], (primary, key), index_granularity, [ver])

    可以看出他比MergeTree只多了一个ver，这个ver指代版本列。
    案例：

    1. create table rmt_table (date  Date, id UInt8, name String,point UInt8) ENGINE= ReplacingMergeTree(date, (id, name), 8192,point);
    2. 插入一些数据：
    3. insert into rmt_table values ('2019-07-10', 1, 'a', 20);
    4. insert into rmt_table values ('2019-07-10', 1, 'a', 30);
    5. insert into rmt_table values ('2019-07-11', 1, 'a', 20);
    6. insert into rmt_table values ('2019-07-11', 1, 'a', 30);
    7. insert into rmt_table values ('2019-07-11', 1, 'a', 10);
    8. 等待一段时间或optimize table rmt_table手动触发merge，后查询
    9. :) select * from rmt_table;
    10. ┌───────date─┬─id─┬─name─┬─point─┐
    11. │ 2019-07-11 │  1 │ a    │    30 │
    12. └────────────┴────┴──────┴───────┘

    SummingMergeTree
    该引擎继承自 MergeTree。区别在于，当合并 SummingMergeTree 表的数据片段时，ClickHouse 会把所有具有相同主键的行合并为一行，该行包含了被合并的行中具有数值数据类型的列的汇总值。如果主键的组合方式使得单个键值对应于大量的行，则可以显著的减少存储空间并加快数据查询的速度，对于不可加的列，会取一个最先出现的值。
    语法：

    1. ENGINE [=] SummingMergeTree(date-column [, sampling_expression], (primary, key), index_granularity, [columns])

    参数：

    1. columns — 包含将要被汇总的列的列名的元组

    案例：

    1. create table smt_table (date Date, name String, a UInt16, b UInt16) ENGINE=SummingMergeTree(date, (date, name), 8192, (a))

    插入数据：

    1. insert into smt_table (date, name, a, b) values ('2019-07-10', 'a', 1, 2);
    2. insert into smt_table (date, name, a, b) values ('2019-07-10', 'b', 2, 1);
    3. insert into smt_table (date, name, a, b) values ('2019-07-11', 'b', 3, 8);
    4. insert into smt_table (date, name, a, b) values ('2019-07-11', 'b', 3, 8);
    5. insert into smt_table (date, name, a, b) values ('2019-07-11', 'a', 3, 1);
    6. insert into smt_table (date, name, a, b) values ('2019-07-12', 'c', 1, 3);

    等待一段时间或optimize table smt_table手动触发merge，后查询

    1. :) select * from smt_table 
    2. ┌───────date─┬─name─┬─a─┬─b─┐
    3. │ 2019-07-10 │ a    │ 1 │ 2 │
    4. │ 2019-07-10 │ b    │ 2 │ 1 │
    5. │ 2019-07-11 │ a    │ 3 │ 1 │
    6. │ 2019-07-11 │ b    │ 6 │ 8 │
    7. │ 2019-07-12 │ c    │ 1 │ 3 │
    8. └────────────┴──────┴───┴───┘

    发现2019-07-11，b的a列合并相加了，b列取了8（因为b列为8的数据最先插入）。
    Distributed
    分布式引擎，本身不存储数据, 但可以在多个服务器上进行分布式查询。 读是自动并行的。读取时，远程服务器表的索引（如果有的话）会被使用。

    1. Distributed(cluster_name, database, table [, sharding_key])

    参数解析：

    1. cluster_name  - 服务器配置文件中的集群名,在/etc/metrika.xml中配置的
    2. database – 数据库名
    3. table – 表名
    4. sharding_key – 数据分片键

    案例演示：
    1）在hadoop102，hadoop103，hadoop104上分别创建一个表t

    1. :)create table t(id UInt16, name String) ENGINE=TinyLog;

    2）在三台机器的t表中插入一些数据

    1. :)insert into t(id, name) values (1, 'zhangsan');
    2. :)insert into t(id, name) values (2, 'lisi');

    3）在hadoop102上创建分布式表

    1. :)create table dis_table(id UInt16, name String) ENGINE=Distributed(perftest_3shards_1replicas, default, t, id);

    4）往dis_table中插入数据

    1. :) insert into dis_table select * from t

    5）查看数据量

    1. :) select count() from dis_table 
    2. FROM dis_table 
    3. ┌─count()─┐
    4. │       8 │
    5. └─────────┘
    6. :) select count() from t
    7. SELECT count()
    8. FROM t 
    9. ┌─count()─┐
    10. │       3 │
    11. └─────────┘

    可以看到每个节点大约有1/3的数据