clickhouse
qq_35640866
这个作者很懒,什么都没留下…
展开
-
clickhouse ttl不生效
是因为删除数据速度 赶不上插入数据速度,造成历史数据无法被清理。通过 partition 字段查找 需要删除的分区。日志保留31天, 但是发现1年前的数据还有。TTL 删除数据按照 分区时间删除。历史使用通过删除分区的方式删除。加速删除数据的速度。原创 2024-04-18 22:04:40 · 533 阅读 · 0 评论 -
clickhouse 查询group 分组最大值的一行数据。
但文档又做了说明:因为查询可能是以任意顺序执行的,并且可能每次执行得顺序都不同(如同我们上面的select * from user_order返回的行顺序不同),所以这个函数的执行结果可能是不确定的。或者,select的对象的是一个已经排序过的子查询。使用any函数可以去匹配到的第一行数据,所以可以先让数据按照query_time_ms 排序,然后再使用group by 和any结合取第一行数据,就是最大值的那一行数据。窗体函数在数据量大的时候性能堪忧,在clickhouse中还有其他的处理方式。原创 2024-03-29 11:56:33 · 526 阅读 · 0 评论 -
clickhouse 双引号符串查询报错 Missing columns: required columns:
ERROR 47 (00000): Code: 47. DB::Exception: Missing columns: ‘leopard_know’ while processing query: ‘SELECT dbname FROM rds_all_slow_sql_record_local WHERE dbname = leopard_know LIMIT 10’, required columns: ‘dbname’ ‘leopard_know’, maybe you meant: [‘dbname原创 2024-03-27 21:08:03 · 546 阅读 · 0 评论 -
clickhouse 单副本和双副本升级差别
双副本集群必须用ReplicatedMergeTree;但是单副本就没必要用ReplicatedMergeTree了,还会对写入性能会有影响(单副本用MergeTree即可)。双副本的优势在于升级、重启等可滚动进行,考虑到这是少数场景,如果业务不是非常敏感,为了这个滚动付出多一倍成本不太值得。clickhouse,单副本,升级、重启,会有1-3分钟连接闪断。云上单副本就够了,成本更低,而且基于云盘不会丢数据。原创 2024-01-20 21:05:46 · 725 阅读 · 0 评论 -
clickhouse join查询算法
算法对比:使用方法:SELECT town, max(price) AS max_price, any(population) AS populationFROM uk_xxx_paidJOIN uk_xxx_tableON lower(uk_price_paid.town) = lower(uk_populations_table.city)GROUP BY townORDER BY max_price DESCSETTINGS join_algorithm =原创 2024-01-12 14:35:36 · 657 阅读 · 0 评论 -
压测clickhouse性能相关参数
【代码】clickhouse性能相关参数。原创 2024-01-09 14:16:14 · 711 阅读 · 0 评论 -
clickhouse报错Too many partitions for single INSERT block
我们是按照天分区, 开发一次写入了一年的数据,365天 365个分区。是因为一次写入的数据,超过100个分区,所以报错。和本次无的命令记录一下, 可以强制刷新临时表。调大了参数,解决这个问题。解决方法: 默认是100。原创 2023-11-23 23:10:36 · 1128 阅读 · 0 评论 -
clickhouse 写入分布式表报 504 Gateway Time-out
ck数据写入超过3分钟 会报 504初步分析是因为类似超时参数引起,分析现有参数发现http_send_timeout http_receive_timeout distributed_ddl_task_timeout的参数超时时间是180秒。猜测是:修改ck参数 (顺便把 distributed_ddl_task_timeout参数修改。查看参数是否生效。修改参数以后 可以查看query_log 中的Settings 内容语句是否已经生效。原创 2023-08-17 11:25:24 · 458 阅读 · 1 评论 -
clickhouse 的使用场景 人群圈选
optimize的执行周期可在业务的实时性需求与计算资源之间做权衡。标签的不断更新将会使得ES不得不频繁的重构索引,这将对ES的性能造成巨大的开销。4、索引的构造过程是复杂的,耗时的。针对以上sql,ES的执行会对3个标签分别做3次索引扫描,之后再将3次扫描的结果做merge。1、ClickHouse是一款彻底的列式存储数据库,且ClickHouse的查询不依赖索引。6、开源ES缺少完备的sql支持,查询请求的json格式复杂。3、对搜索的数据需要构建索引, 不构建索引,不能搜索。原创 2023-08-03 13:57:29 · 169 阅读 · 0 评论 -
clickhouse对数据实时性的解决方案
mergeTree自己合并数据 是Clickhouse基于策略控制的,执行时间比较随机,因此数据一致性缺少时间保证,极端情况下数据过了一天也没有完全合并。因为clickhouse 对数据的更新不是实时性的,但是有的业务对实时性要求比较高。clickhouse 对update,delete 支持不友好, 比较适合insert 场景的应用。只能做到最终一致性,数据非实时, 极端情况下,可能需要一天的时间。注意: 所以不能指望merge自己合并数据,非常不靠谱。每次查询之前都要合并数据, 成本高。原创 2023-08-02 19:20:39 · 595 阅读 · 0 评论 -
clickhouse code: 209. DB::NetException: Timeout: connect timed out:
set global on cluster default connections_with_failover_max_tries=10 (默认是3次)查看query log 日志 提示网络超时, 最后定位到问题是ck 底层系统升级造成。2、也可以调整重试次数,降低失败概率。ck 插入数据失败,原创 2023-06-15 16:23:34 · 1064 阅读 · 0 评论