clickhouse（八、特有存储结构和分布式表）

存储结构

以下实例我们都以clickhouse最常用的*MergeTree（合并树）子类引擎来做介绍。

逻辑划分

以分布式表为例，那么ck数据存放于该集群下多个shard分片中。如果shard不在一个节点上，也就是数据会分散到多台机下。每个分片中的数据会根据建表时指定的partition在进行划分，而单个partition中，如果数据容量超过一定阈值又会重新拆分。

# 表结构：
${ck_data}/metadata/path_to_table/*.sql
# 实际数据存放目录：
${ck_data}/data/path_to_table/${partition_*}/**
# 装卸数据目录
${ck_data}/data/path_to_table/detached

列式存储

clickhouse是真正的列式数据库管理系统，除了数据本身外基本不存在其他额外的数据。
下面我们看下clickhouse特有的计算优势。

• 多服务器分布式处理
  在ClickHouse中，数据可以保存在不同的shard上，每一个shard都由一组用于容错的replica组成，查询可以多服务器并行地在所有shard上进行处理。
• 向量引擎
  为了高效的使用CPU，计算时ck能按向量(列的一部分)进行处理，相对于实际的数据处理成本，向量化处理具有更低的转发成本。这样可以更加高效地使用CPU。

稀疏索引

Clickhouse 中最强大的表引擎当属 MergeTree （合并树）引擎及该系列（*MergeTree）中的其他引擎。MergeTree 引擎系列的基本理念如下。当你有巨量数据要插入到表中，你要高效地一批批写入数据片段，并希望这些数据片段在后台按照一定规则合并。相比在插入时不断修改（重写）数据进存储，这种策略会高效很多。主要优势：

• 存储的数据按主键排序。
  这让你可以创建一个用于快速检索数据的小稀疏索引。
• 允许使用分区，如果指定了 分区键 的话。
  在相同数据集和相同结果集的情况下 ClickHouse 中某些带分区的操作会比普通操作更快。查询中指定了分区键时 ClickHouse 会自动截取分区数据。这也有效增加了查询性能。
• 支持数据副本。
  ReplicatedMergeTree 系列的表便是用于此。

以官网用例来看。我们以 (CounterID, Date) 以主键。排序好的索引的图示会是下面这样：

全部数据  :      [-------------------------------------------------------------------------]
CounterID:      [aaaaaaaaaaaaaaaaaabbbbcdeeeeeeeeeeeeefgggggggghhhhhhhhhiiiiiiiiikllllllll]
Date:           [1111111222222233331233211111222222333211111112122222223111112223311122333]
标记:            |      |      |      |      |      |      |      |      |      |      |
                a,1    a,2    a,3    b,3    e,2    e,3    g,1    h,2    i,1    i,3    l,3
标记号:          0      1      2      3      4      5      6      7      8      9      10

如果指定查询如下：
CounterID in ('a', 'h')，服务器会读取标记号在 [0, 3) 和 [6, 8) 区间中的数据。
CounterID IN ('a', 'h') AND Date = 3，服务器会读取标记号在 [1, 3) 和 [7, 8) 区间中的数据。
Date = 3，服务器会读取标记号在 [1, 10] 区间中的数据。上面例子可以看出使用索引通常会比全表描述要高效。
稀疏索引会引起额外的数据读取。当读取主键单个区间范围的数据时，每个数据块中最多会多读 index_granularity * 2 行额外的数据。大部分情况下，当 index_granularity = 8192 时，ClickHouse的性能并不会降级。
稀疏索引让你能操作有巨量行的表。因为这些索引是常驻内存（RAM）的。ClickHouse 不要求主键惟一。所以，你可以插入多条具有相同主键的行。下面看在实际语法：

CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
    name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],
    name2 [type2] [DEFAULT|MATERIALIZED