可对映射表在CH的SQL使用的做以下的最简洁的规范 所有映射表作为驱动表时无须用子查询封装,但作为被驱动表时一律用子查询进行封装(简化规范,保持一致性) 在SELECT中只提取需要用到的字段(减少字段数来降低的网络IO,及内存使用) 在WHERE语句中尽可能的提前过滤字段,但不能对字段做CH的函数处理(减少记录数来降低的网络IO,及内存使用) ClickHouse中MySQL(TiDB)的映射表的使用优化 ClickHouse
此篇作为开端,即是引题又是总结,后续会在陆续发布不同角度优化的探索过程 整体来说,ClickHouse的性能,但这些都是基于优化后的结果,一条优化过的SQL与没有经过优化的SQL的性能可能会相差好几倍。 SQL慢查大部分主要体现在CPU负载过高,IO(磁盘IO/网络IO)过高,或者查询的列中无索引导致的。 对于ClickHouse的优化可以从表结构存储设计优化与查询SQL优化两个方向来进行。此篇先只针对查询SQL优化的方向进行整理,大致有以下几个方向 在WHERE语法只过滤出必要的记录。 在SELECT中只选择必要的字段。 尽可能的提前做运算,降低网络IO成本。 注意JOIN语句的不合理使用造成的数据量爆炸(过度放大)。 对于MySQL(TiDB)的映射表使用,结合1,2两点做子查询封装。 所有映射表作为驱动表时无须用子查询封装,但作为被驱动表时一律用子查询进行封装(简化规范,保持一致性) 在SELECT中只提取需要用到的字段(减少字段数来降低的网络IO,及内存使用) 在WHERE语句中尽可能的提前过滤字段,但不能对字段做CH的函数处理(减少记录数来降低的网络IO,及内存使用) .... ClickHouse的SQL优化概览 ClickHouse
作为一个有追求的开发攻城狮,你是否困惑:既然事务已经满足了 ACID,为什么还要搞出个事务隔离级别?事务隔离级别究竟时干啥用的?难道写代码的时候不是简单地开关事务就万事大吉了吗? MySQL 事务与锁 MySQL
Kafka 事务性最开始的出发点是为了在 Kafka Streams 中实现 Exactly-Once 语义的数据处理,这部分的实现要比幂等性的实现复杂一些,但是幂等性实现是事务性实现的基础。简单来说,Kafka 事务性是为了解决 atomic writes across partitions。 Kafka 事务相关总结 Kafka
最近在开发任务服务,其中有一个任务上报模块。其业务逻辑如下: 1.上报子任务详情,更新数据库 2.根据子任务状态同步总任务状态,实时更新任务进度。 最简单的实现方式就是UpdateSubTask,UpdateTask。 显然,这种方式并发情况下会有问题。 优化一 1.对子任务id进行分布锁,这里记得上锁时要添加超时时间,不然死锁就完犊子了。 func (impl *RedisCache) Lock(ctx context.Context, key string, expiration time.Duration) error { ok, err := impl.r.SetNX(impl.getKey(key), 1, expiration).Result() if err != nil { return err } if !ok { return errors.New("redis lock: already locked") } return nil } func (impl *RedisCache) Unlock(ctx context.Context, key string) e.... 任务服务的一次优化 优化
选择 限流算法大体有两种: 1.计数式 计数算法有固定窗口算法与滑动窗口算法两种。 固定窗口临界不易处理。例如: 窗口为一分钟限流30 第一分钟,前30秒流量为0,后30秒流量为25 第二分钟,前30秒流量为25,后30秒流量为0 固定窗口对于这两分钟流量都没触发限流操作。 滑动窗口则会统计每一个窗口期内的流量。 例如: 窗口为一分钟限流30 第一分钟,前30秒流量为0,后30秒流量为25 第二分钟,前30秒流量为25,后30秒流量为0 滑动窗口会统计第一分钟后30秒与第二分钟前30秒的流量 在窗口期流量为50,则触发流量限制 所以对于滑动窗口可以很好的处理临界问题 2.桶算法 桶算法分为漏桶算法与令牌桶算法。 桶算法主动往桶里添加token,。 对于我们业务场景,通常情况下桶的数量(key)不易于确定,所以我们采用计数式滑动窗口算法。 实现 以时间区间为窗口 基于redis的ZADD实现 ZADD key score member ZCOUNT ZCOUNT key min max 主要依赖ZADD与ZCOUNT命令 ZADD中的score使用时间戳(.... 分布式限流-滑动窗口实现 限流