clickhouse建表优化

clickhouse建表优化

数据类型：

1. 建表时能用数值型或日期时间型表示的字段就不要用字符串虽然 ClickHouse 底层将 DateTime 存储为时间戳 Long 类型，但不建议存储 Long 类型， 因为 DateTime 不需要经过函数转换处理，执行效率高、可读性好。
2. Nullable 类型几乎总是会拖累性能，应直 接使用字段默认值表示空，或者自行指定一个在业务中无意义的值（例如用-1 表示没有商品 ID）。

分区和索引

1. 分区粒度根据业务特点决定，不宜过粗或过细。一般选择按天分区。以单表一亿数据为例，分区大小控制在 10-30 个为最佳。
2. 必须指定索引列，ClickHouse 中的索引列即排序列，通过 order by 指定，通常需要满足高级列在前、查询频率大的在前原则；还有基数特别大的不适合做索引列， 如用户表的 userid 字段；通常筛选后的数据满足在百万以内为最佳。

表参数

1. Index_granularity 是用来控制索引粒度的，默认是 8192，如非必须不建议调整。
2. 如果表中不是必须保留全量历史数据，建议指定 TTL（生存时间值），可以免去手动过期 历史数据的麻烦，TTL 也可以通过 alter table 语句随时修改。

写入和删除优化（核心思想：不要太频繁）

1. 尽量不要执行单条或小批量删除和插入操作，这样会产生小分区文件，给后台Merge 任务带来巨大压力。
2. 不要一次写入太多分区，或数据写入太快，数据写入太快会导致 Merge 速度跟不 上而报错，一般建议每秒钟发起 2-3 次写入操作，每次操作写入 2w~5w 条数据（依服务器 性能而定）。（攒批处理）

​ 写入过快报错，报错信息：

1. Code: 252, e.displayText() = DB::Exception: Too many parts(304). 
Merges are processing significantly slower than inserts
2. Code: 241, e.displayText() = DB::Exception: Memory limit (for query) 
exceeded:would use 9.37 GiB (attempt to allocate chunk of 301989888 
bytes), maximum: 9.31 GiB

​ 处理方式：

“ Too many parts  处理 ”   ：使用 WAL 预写日志，提高写入性能。
in_memory_parts_enable_wal  默认为   true

3. 在服务器内存充裕的情况下增加内存配额，一般通过 max_memory_usage 来实现 。
4. 在服务器内存不充裕的情况下，建议将超出部分内容分配到系统硬盘上，但会降低执行速度，一般通过 max_bytes_before_external_group_by、max_bytes_before_external_sort 参数 来实现。

常见配置

• config.xml 的配置项
  https://clickhouse.tech/docs/en/operations/server-configuration-parameters/settings/
• users.xml 的配置项
  https://clickhouse.tech/docs/en/operations/settings/settings/

cpu资源

配置	描述
background_pool_size	后台线程池的大小，merge 线 程 就 是 在 该 线 程 池 中 执 行 ， 该 线 程 池 不仅仅是给 merge 线 程 用 的 ，默 认 值 16，允 许 的 前 提 下 建 议 改 成 cpu 个数的 2 倍 （ 线 程 数 ） 。
background_schedule_pool_size	执行后台任务（ 复 制 表 、 Kafka 流、DNS 缓存更新） 的线程数。默 认 128， 建 议 改 成 cpu 个数的 2 倍（线程数）。
background_distributed_schedule _ pool_size	设置为分 布 式 发 送 执 行 后 台 任 务 的 线 程 数 ， 默 认 16， 建 议 改 成 cpu 个数的 2 倍 （ 线 程 数 ） 。
max_concurrent_queries	最大并发处理的请求数(包含 select,insert 等 )，默 认 值 100，推 荐 1 50(不够再加)~300。
max_threads	设置单个查询所能使用的最大 cpu 个数，默认是 cpu 核数

内存资源

配置	描述
max_memory_usage	此参数在 users.xml 中 ,表 示 单 次 Query 占 用 内 存 最 大 值 ， 该 值 可以设置的比较大，这样可以提升集群查询的上限。保留一点给 OS， 比 如 128G 内 存 的 机 器 ， 设 置 为 100GB。
max_bytes_before_external_group_ by	一般按照 max_memory_usage 的一半设置内存，当 group 使 用 内 存超过阈值后会刷新到磁盘进行。因为 clickhouse 聚 合 分 两 个 阶 段 ： 查 询 并 及 建 立 中 间 数 据 、 合 并 中间数据，结 合 上 一 项 ， 建 议 50GB。
max_bytes_before_external_sort	当 order by 已使用 max_bytes_before_external_sort 内 存 就 进 行 溢写磁盘(基 于 磁 盘 排 序 )，如 果 不 设 置 该 值 ，那 么 当 内 存 不 够 时 直 接 抛 错 ，设 置 了 该 值 order by 可 以 正 常 完 成 ，但 是 速 度 相 对 存 内 存 来 说肯定要慢点(实 测 慢 的 非 常 多 ， 无 法 接 受 )。
max_table_size_to_drop	此参数在 config.xml 中 ，应 用 于 需 要 删 除 表 或 分 区 的 情 况 ，默 认 是 50GB，意 思 是 如 果 删 除 50GB 以上的分区表会失败。建 议 修 改 为 0， 这样不管多大的分区表都可以删除。

存储

ClickHouse 不支持设置多数据目录，为了提升数据 io 性能，可以挂载虚拟券组，一个券 组绑定多块物理磁盘提升读写性能，多数据查询场景 SSD 会比普通机械硬盘快 2-3 倍。