clickhouse常用的MergeTree引擎外，还有特殊的引擎
1，memory引擎，顾名思义，数据是存储在内存中，数据不会被压缩也不会倍格式化转换数据在内存中保存的形态与查询时看到的如出一辙，重启ck数据丢失
2，set殷勤，数据先写入内存，然后同步到磁盘文件中，数据表重新加载时候数据不丢失，
拥有去重作用，和set集合一样，但是insert数据后查询不能使用select，只能使用in
3,buffer殷勤，使用场景少
Buffer表引擎完全使用内存装载数据，不支持文件的持久化存储，所以当服务重启之后，表内的数据会被清空。Buffer表引擎不是为了面向查询场景而设计的，它的作用是充当缓冲区的角色
假设有这样一种场景，我们需要将数据写入目标MergeTree表A，由于写入的并发数很高，这可能会导致MergeTree表A的合并速度慢于写入速度（因为每一次INSERT都会生成一个新的分区目录）。此时，可以引入Buffer表来缓解这类问题，将Buffer表作为数据写入的缓冲区。
数据首先被写入Buffer表，当满足预设条件时，Buffer表会自动将数据刷新到目标表
ENGINE = Buffer(database, table, num_layers, min_time, max_time, min_rows, max_rows, min_bytes, max_bytes)
其中，参数可以分成基础参数和条件参数两类，首先说明基础参数的作用：
database：目标表的数据库。
table：目标表的名称，Buffer表内的数据会自动刷新到目标表。
num_layers：可以理解成线程数，Buffer表会按照num_layers的数量开启线程，以并行的方式将数据刷新到目标表，官方建议设为16。
Buffer表并不是实时刷新数据的，只有在阈值条件满足时它才会刷新。阈值条件由三组最小和最大值组成。接下来说明三组极值条件参数的具体含义：
min_time和max_time：时间条件的最小和最大值，单位为秒，从第一次向表内写入数据的时候开始计算；
min_rows和max_rows：数据行条件的最小和最大值；
min_bytes和max_bytes：数据体量条件的最小和最大值，单位为字节。
根据上述条件可知，Buffer表刷新的判断依据有三个，满足其中任意一个，Buffer表就会刷新数据，它们分别是：
如果三组条件中所有的最小阈值都已满足，则触发刷新动作；
如果三组条件中至少有一个最大阈值条件满足，则触发刷新动作；
如果写入的一批数据的数据行大于max_rows，或者数据体量大于max_bytes，则数据直接被写入目标表。
还有一点需要注意，上述三组条件在每一个num_layers中都是单独计算的。假设num_layers=16，则Buffer表最多会开启16个线程来响应数据的写入，它们以轮询的方式接收请求，在每个线程内，会独立进行上述条件判断的过程。也就是说，假设一张Buffer表的max_bytes=100000000（约100 MB），num_layers=16，那么这张Buffer表能够同时处理的最大数据量约是1.6 GB。
请注意
缓冲区表不支持索引。换句话说，缓冲区中的数据已被完全扫描，这对于大型缓冲区而言可能很慢。（对于下级表中的数据，将使用其支持的索引。）
如果“缓冲区”表中的列集与从属表中的列集不匹配，则插入两个表中都存在的列子集。
如果类型与缓冲区表和从属表中的任一列都不匹配，则会在服务器日志中输入错误消息，并清除缓冲区。
如果刷新缓冲区时从属表不存在，也会发生相同的情况。
如果需要对下级表和Buffer表运行ALTER，建议先删除Buffer表，对下级表运行ALTER，然后再次创建Buffer表。
如果服务器异常重启，缓冲区中的数据将会丢失。
FINAL和SAMPLE对于缓冲区表不能正常工作。这些条件将传递到目标表，但不用于处理缓冲区中的数据。如果需要这些功能，建议从目标表读取时仅使用缓冲区表进行写入。
将数据添加到缓冲区时，缓冲区之一被锁定。如果同时从表执行读取操作，则会导致延迟。
插入到缓冲区表中的数据可能以不同的顺序和不同的块最终出现在从属表中。因此，很难使用Buffer表正确地写入CollapsingMergeTree。为了避免出现问题，可以将“ num_layers”设置为1。
如果目标表被复制，则写入缓冲区表时，复制表的某些预期特性会丢失。数据部分的行顺序和大小的随机变化会导致重复数据删除退出工作，这意味着不可能对复制表进行可靠的“仅一次”写入。
由于这些缺点，我们仅建议在极少数情况下使用Buffer表。
当在一个单位时间内从大量服务器接收到太多INSERT且无法在插入之前对数据进行缓冲的情况下，将使用Buffer表，这意味着INSERT不能足够快地运行。