Level • PartitionID 分区ID，无需多说，对于分区ID的规则在上一小节中已 经做过了详细的阐述。 • MinBlockNum和MaxBlockNum 顾名思义，最小数据块编号与最大数据块编号。这里的 BlockNum是一个整型的自增长编号。如果将其设为n的话 ，那么计数n在单张MergeTree数据表内全局累加，n从1 开始，每当新创建一个分区目录时，计数n就会累积加1 。对 按列存储，精心编排，错落有致 压缩数据块，就好比是一本书的文字段落，是组织文字的基本单元。 压缩数据块 头信息固定使用9位字节表示，具体 由1个UInt8(1字节)整型和2个 UInt32(4字节)整型组成 。 压缩数据块大小 l 单个批次数据 size < 64K 如果单个批次数据小于64K，则继续获取下一批 数据，直至累积到size >= 64K时，生成下一个压缩 数据块。 l 单个批次数据 64K<= <=1M 如果单个批次数据大小恰好在64K与1M之间，则 直接生成下一个压缩数据块。 l 单个批次数据 size > 1M 如果单个批次数据直接超过1M，则首先按照1M 大小截断并生成下一个压缩数据块。剩余数据继续依 照上述规则执行。此时，会出现一个批次数据生成多 个压缩数据块的情况。 每个压缩数据块的体积，按照其压缩前的数据字节大小，都被严格的控制在64K~1M之间，其上下限分 别由

我们遇到的问题 关于机器的配置 早期集群机器配置16核64G 一块1.7T本地SSD 问题： 1：内存限制，对于一些大的查询会出现内存不够问题 2：存储限制，随着表越来多，磁盘报警不断 3：cpu限制 64G对于一些大表(每天600亿+)的处理，很容易报错，虽然有基于磁盘解决方案，但是会影响速度 clickhouse的数据目录还不支持多个数据盘，单块盘的大小限制太大 cpu需要根据实际情况而定 解决： 1：机器的内存推荐128G+

执行涉及到全表数据的查询（cold data，从硬盘读取），处理速度为~24.28million rows/s • 只用到三块硬盘的io：3*140=420mb/s • 数据分布在六台服务器上 • 执行涉及到全表数据的查询（cold data，从硬盘读取），处理速度为~43.60million rows/s • 用到六块硬盘的io：6*140=840mb/s • io吞吐量加倍时，对于冷数据的处理速度是之前的~180%