mergetree
原始的 mergetree 通过分片的形式支持高吞吐量。
通过 replicatedMergeTree 去支持副本。
但是这种副本机制，需要进行服务器间的数据同步，消耗计算资源。（比如 insert_quorum，设置数据需要插入到一半的 replicas 上才算成功；）
对分布式表的查询会分发到每一个分片上执行。
同一分片上的多个 replicates 可以并行数据查询范围。（当然如果数据没有重新 balance 的话，简单增加节点数量不等于增加查询资源。）
当然，用户可以将数据配置成通过 s3 的形式放到 oss；但是这依然是数据分片，不同分片的数据不共享。
sharedMergeTree
使用 sharedMergeTree 之后。
所有的节点共享完全相同的数据源头。
每个节点可以说都是彼此的 replicates.
大大提高了 merge 的性能。如图所示，插入的性能 clickhouse cloud 可以随着节点数目变多进行扩展，而 replicated merge tree 在节点数过多的时候就不太行。
查询的速度也会得到扩展。
每个查询都会在多个 replicas 之间进行分布，以 granules 的粒度拆分任务。
在 clickhouse bench 中查询性能倒是没有随节点数而线性的扩展。单个 replicas 但是和裸机差不多。
某种意义上这意味着 clickhouse 更适合垂直扩展，而不是水平扩展。
clickhouse cloud 同时也支持计算和计算分离，这可以用来隔离写入和查询。
价格
clickhouse 企业版本一个 ccu 0.5 人名币/小时。
社区兼容版本的话，1 TB SSD 加上 8 core 32GB 的内存差不多 8.4 人民币一小时，机器 5.6，存储 2.8。
价格差不多便宜两倍。一方面是没了 ssd，一方面是 ccu 比独立的机器更便宜。
插入优化
- 最高档位：我们配置的插入块大小越大，ClickHouse 需要创建的部分就越少，所需的磁盘文件 i/o和后台合并就越少。
- 全面加速：我们配置的并行插入线程数越高，数据处理速度就越快。
但是，这两个性能因素之间存在着相互冲突的权衡（加上与后台部分合并的权衡）。ClickHouse 服务器可用的主内存量是有限的。较大的块使用更多的主内存，这限制了我们可以利用的并行插入线程的数量。相反，更多的并行插入线程需要更多的主内存，因为插入线程的数量决定了内存中同时创建的插入块的数量。这限制了插入块的可能大小。此外，插入线程和后台合并线程之间可能会发生资源争用。配置的插入线程数量较多 (1) 会创建更多需要合并的部分，并且 (2) 会从后台合并线程中夺走 CPU 核心和内存空间。
- max_insert_threads. 将写入线程设置为服务器 cpu 的一半，这样可以留出一半来进行 merge 操作。
- 最小单次插入的 block bytes：最大内存使用量的 1/3.
