网站建设依据什么法律,广州营销咨询公司,wordpress分类添加关键词,合肥网站建设报价1. 数据类型 1.1 时间字段的类型 建表时能用数值型或日期时间型表示的字段就不要用字符串#xff0c;全String类型在以Hive为中心的数仓建设中常见#xff0c;但ClickHouse环境不应受此影响。 虽然ClickHouse底层将DateTime存储为时间戳Long类型#xff0c;但不建议存储Long… 1. 数据类型 1.1 时间字段的类型 建表时能用数值型或日期时间型表示的字段就不要用字符串全String类型在以Hive为中心的数仓建设中常见但ClickHouse环境不应受此影响。 虽然ClickHouse底层将DateTime存储为时间戳Long类型但不建议存储Long类型因为DateTime不需要经过函数转换处理执行效率高、可读性好。 create table t_type2(id UInt32,sku_id String,total_amount Decimal(16,2) ,create_time Int32 ) engine ReplacingMergeTree(create_time)partition by toYYYYMMDD(toDate(create_time)) –-需要转换一次否则报错primary key (id)order by (id, sku_id);1.2 空值存储类型 官方已经指出Nullable类型几乎总是会拖累性能因为存储Nullable列时需要创建一个额外的文件来存储NULL的标记并且Nullable列无法被索引。因此除非极特殊情况应直接使用字段默认值表示空或者自行指定一个在业务中无意义的值例如用-1表示没有商品ID。 CREATE TABLE t_null(x Int8, y Nullable(Int8)) ENGINE TinyLog; INSERT INTO t_null VALUES (1, NULL), (2, 3); SELECT x y FROM t_null; 查看存储的文件没有权限就用root用户 官网说明可为空类型名称) | ClickHouse Docs 2 分区和索引 分区粒度根据业务特点决定不宜过粗或过细。一般选择按天分区也可以指定为Tuple()以单表一亿数据为例分区大小控制在10-30个为最佳。 必须指定索引列ClickHouse中的索引列即排序列通过order by指定一般在查询条件中经常被用来充当筛选条件的属性被纳入进来可以是单一维度也可以是组合维度的索引通常需要满足高级列在前、查询频率大的在前原则还有基数特别大的不适合做索引列如用户表的userid字段通常筛选后的数据满足在百万以内为最佳。 比如官方案例的hits_v1表 ……
PARTITION BY toYYYYMM(EventDate)
ORDER BY (CounterID, EventDate, intHash32(UserID))
……
visits_v1表
……
PARTITION BY toYYYYMM(StartDate)
ORDER BY (CounterID, StartDate, intHash32(UserID), VisitID)
……3 表参数 Index_granularity是用来控制索引粒度的默认是8192如非必须不建议调整。 如果表中不是必须保留全量历史数据建议指定TTL生存时间值可以免去手动过期历史数据的麻烦TTL 也可以通过alter table语句随时修改。参考基础文档4.4.5 数据TTL 4 写入和删除优化 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 在服务器内存充裕的情况下增加内存配额一般通过max_memory_usage来实现 在服务器内存不充裕的情况下建议将超出部分内容分配到系统硬盘上但会降低执行速度一般通过max_bytes_before_external_group_by、max_bytes_before_external_sort参数来实现。 5 常见配置 配置项主要在config.xml或users.xml中 基本上都在users.xml里 config.xml的配置项 Global Server Settings | ClickHouse Docs users.xml的配置项 Core Settings | ClickHouse Docs 5.1 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推荐150(不够再加)~300。 max_threads 设置单个查询所能使用的最大cpu个数默认是cpu核数 5.2 内存资源 配置 描述 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这样不管多大的分区表都可以删除。 5.3 存储 ClickHouse不支持设置多数据目录为了提升数据io性能可以挂载虚拟券组一个券组绑定多块物理磁盘提升读写性能多数据查询场景SSD会比普通机械硬盘快2-3倍。
