高并发系统实战课
徐长龙
前微博架构师、极客时间架构师
11663 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 30 讲
结束语&结课测试 (2讲)
高并发系统实战课
15
15
1.0x
00:00/00:00
登录|注册

14|跳数索引:后起新秀ClickHouse

查询流程
实现原理
索引类型
数据检索流程
数据存储和索引排序
历史数据清理方法
评估表格
选择ClickHouse或Elasticsearch
ClickHouse关键特性
扩容服务器配置
主从分片
数据插入方式
实时统计
查询效率提高策略
数据部分合并
数据来源优化方式
MergeTree引擎
客户端驱动
优化思路
查询QPS限制
ClickHouse的并发能力
跳数索引
主键索引
思考题
总结
分布式表
查询效率提升
批量写入优化
并行能力CPU吞吐和性能
跳数索引
跳数索引:后起新秀ClickHouse

该思维导图由 AI 生成,仅供参考

你好,我是徐长龙。
通过前面的学习,我们见识到了 Elasticsearch 的强大功能。不过在技术选型的时候,价格也是重要影响因素。Elasticsearch 虽然用起来方便,但却有大量的硬件资源损耗,再富有的公司,看到每月服务器账单的时候也会心疼一下。
而 ClickHouse 是新生代的 OLAP,尝试使用了很多有趣的实现,虽然仍旧有很多不足,比如不支持数据更新、动态索引较差、查询优化难度高、分布式需要手动设计等问题。但由于它架构简单,整体相对廉价,逐渐得到很多团队的认同,很多互联网企业加入社区,不断改进 ClickHouse。
ClickHouse 属于列式存储数据库,多用于写多读少的场景,它提供了灵活的分布式存储引擎,还有分片、集群等多种模式,供我们搭建的时候按需选择。
这节课我会从写入、分片、索引、查询的实现这几个方面带你重新认识 ClickHouse。在学习过程中建议你对比一下 Elasticsearch、MySQL、RocksDB 的具体实现,想想它们各有什么优缺点,适合什么样的场景。相信通过对比,你会有更多收获。

并行能力 CPU 吞吐和性能

我先说说真正使用 ClickHouse 的时候,最让我意料不到的地方。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

ClickHouse:OLAP数据库的新生代代表 ClickHouse是一款新生代的OLAP数据库,相对于传统数据库具有更高的数据处理能力和更灵活的分布式存储引擎。该数据库充分利用多核CPU,提供高数据处理能力,但并发性较低;通过客户端和引擎的优化,实现了高效的批量写入;定期合并数据部分以提高查询效率。ClickHouse的查询功能包括主键索引和跳数索引,通过稀疏索引和跳数索引加快查询速度。此外,ClickHouse还支持实时统计和分布式表,通过Materialized View实现实时统计,以及手动设置创建分布式表来实现多租户数据服务。总的来说,ClickHouse适用于写多读少的场景,对大数据和业务系统数据有针对性的优化,为用户提供了一种性能高、成本相对较低的数据库选择。 ClickHouse作为OLAP的新生代代表,拥有独特的设计,引起了OLAP数据库的革命,也引发了云厂商的思考,参考其思路来实现HTAP服务。通过分片及内存周期顺序落盘,提高了写并发能力;通过后台定期合并data parts文件,提高了查询效率;在索引方面,通过稀疏索引缩小了检索数据的颗粒范围,对于不在主键的查询,则是通过跳数索引来减少遍历数据的数据量;另外,ClickHouse还有多线程并行读取筛选的设计,共同实现了大吞吐的数据查找功能。最近选择Elasticsearch还是ClickHouse更好的话题,讨论得非常火热,目前来看还没有彻底分出高下。个人建议如果硬件资源丰富,研发人员少的话,就选择Elasticsearch;硬件资源少,研发人员多的情况,可以考虑试用ClickHouse;如果硬件和人员都少,建议买云服务的云分布式数据库去做,需要根据团队具体情况来合理地决策。 总的来说,ClickHouse作为OLAP数据库的新生代代表,具有高效的数据处理能力和灵活的分布式存储引擎,适用于写多读少的场景,为用户提供了一种性能高、成本相对较低的数据库选择。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《高并发系统实战课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(11)

  • 最新
  • 精选
  • 黄堃健
    好,我们回头来整体看看 ClickHouse 的查询工作流程: 1. 根据查询条件,查询过滤出需要读取的 data part 文件夹范围; 2. 根据 data part 内数据的主键索引、过滤出要查询的 granule; 3. 使用 skip index 跳过不符合的 granule; -- 老师, 前面的3个步骤都涉及到过滤,不明白有什么区别,能举例说明一下吗?

    作者回复: 你好,堃健,在 ClickHouse 的查询工作流程中,前三个步骤虽然都涉及到过滤,但它们各自的目的和操作方式有所不同。下面我将通过举例来解释这三个步骤的区别: 1. 根据查询条件,查询过滤出需要读取的 data part 文件夹范围 这个步骤主要是通过分区键(如果有的话)来快速定位到需要查询的数据所在的 data part 文件夹。由于 ClickHouse 支持分区,每个分区可以包含多个 data part,这一步可以大大减少查询需要处理的数据量。 举例:假设你有一个销售数据表,按月份分区。如果你想要查询2023年1月份的所有销售记录,那么这一步就会直接定位到2023年1月的分区,而忽略其他月份的数据。 2. 根据 data part 内数据的主键索引、过滤出要查询的 granule 在这个步骤中,ClickHouse 会使用主键索引来进一步缩小查询范围到特定的 granule。主键索引允许 ClickHouse 快速定位到数据所在的 block。 举例:在同一个销售数据表中,假设主键是 order_id。如果你要查询 order_id 等于 12345 的记录,ClickHouse 会通过主键索引快速找到包含这个 order_id 的 granule。 3. 使用 skip index 跳过不符合的 granule 跳数索引(skip index)的作用是在查询过程中排除那些肯定不包含符合条件数据的 granule,从而减少不必要的磁盘 I/O。 举例:假设你的查询条件是 price > 100,并且你在 price 字段上建立了 min_max 跳数索引。在查询时,如果某个 granule 的价格范围(通过 min_max 索引得知)完全低于100,那么 ClickHouse 就会跳过这个 granule,不对其进行读取。 总结一下,这三个步骤可以这样理解: 第一步是宏观上的数据过滤,通过分区键快速定位到数据所在的 data part。 第二步是中观上的数据过滤,通过主键索引定位到具体的 granule。 第三步是微观上的数据过滤,通过跳数索引跳过不可能包含符合条件数据的 granule,以减少查询所需资源。 在实际使用中,这些步骤共同作用,使得 ClickHouse 能够高效地进行大数据量的查询。

    2024-03-09归属地:广东
    1
  • 黄堃健
    在实际用上 ClickHouse 之后,你会发现很难对它做索引查询优化,动不动就扫全表,这是为什么呢? 主要是我们大部分数据的特征不是很明显、建立的索引区分度不够高 --老师,索引区分度不够高。 这个索引区分度 指的是 主键索引,还是跳表索引。 谢谢老师的评论。

    作者回复: 你好,堃健,索引区分度通常指的是主键索引和跳表索引的有效性。在 ClickHouse 中,主键索引是建表时指定的,它能够帮助快速定位到特定的数据颗粒(granule)。而跳表索引(也称为稀疏索引)是一种辅助索引,它可以帮助查询时跳过不符合条件的数据块。 在问题中,提到的“索引区分度不够高”可能指的是这两种索引中的任何一种或两者的结合。具体来说: 主键索引区分度:如果主键索引的选择不够具有区分度,即索引字段的数据分布比较均匀或者重复性较高,那么在查询时,ClickHouse 可能需要扫描更多的颗粒来找到匹配的数据,这会导致查询效率降低。 跳表索引区分度:跳表索引是为了减少查询时需要扫描的数据量。如果跳表索引的区分度不够高,即索引无法有效地排除大量的不符合条件的数据颗粒,查询优化器可能会选择扫描全表,因为使用索引带来的额外开销可能比全表扫描还要大。 因此,当提到“索引区分度不够高”时,它可能指的是在 ClickHouse 中建立的主键索引和/或跳表索引不足以有效地减少查询需要处理的数据量。为了优化这种情况,可以考虑以下措施: 优化主键选择:选择更有区分度的字段作为主键,以便在查询时能够更快地定位到数据颗粒。 使用辅助索引:在适当的字段上创建跳表索引,以帮助查询时跳过不符合条件的数据块。 调整数据模型:如果可能,重新组织数据模型,以便数据插入时能够按照有区分度的特征排序,这样可以提高索引的效率。

    2024-03-09归属地:广东
  • 黄堃健
    老师,新年好, 大部分数据的特征不是很明显、建立的索引区分度不够? 这句话怎么理解?是主键的区分度不高吗? 因为只有主键才有索引。如果是主键,怎么可能区分度不高呢? 如果不是?究竟是怎么意思?

    作者回复: 你好,堃健,说这一句是因为我们很多数据结构在后期都会碰到和我们开始设计相违背的查询,所以ck这种只有建表索引的库后期很多查询基本都是遍历,这对我们toC的场景不友好,并且ck主键还承担了(mergtree)合并去重功能,所以导致用他多数用于OLAP统计count场景,toC业务使用成本太高。而数据特征不明显这里特指当我们的数据超过一定数量后很难用一些属性大量筛选缩小遍历数据范围,综合起来只有一个建表的索引就会有一些不够,虽然最后还有跳数索引,但是这个索引只是降低cpu和io消耗

    2024-02-20归属地:广东
  • IT小村
    elasticsearch的写性能并不高

    作者回复: 你好,可以尝试使用Rally对es集群进行测试分析,增加分片服务器会提高写性能,多加几台对比即可。

    2023-12-02归属地:北京
  • zhou
    clickhourse存储有leve0,leve1,leve2,用datapart的文件的方式存储,那多节点的情况下是如何做到同步的。

    作者回复: clickhouse的副本是使用zk做的同步通知,当写入方更新后 本地会写对应目录下的操作日志文件,并且会同步更新zk对应路径下的offset。这时订阅方会watch到这个变更后,会主动去对应的地方下载操作日志,并更新自己的zk记录的同步offset

    2023-02-07归属地:浙江
  • 林龍
    读吞吐跟QPS有什么区别?一直以为是同个东西

    作者回复: 你好,林龍,吞吐能力一般指数据量,比如一秒能写600Mb数据,一秒能读取200Mb数据,QPS是每秒能处理多少请求。

    2023-01-11归属地:广东
  • 林龍
    感觉用clickhouse就是为了解决MySQL慢的问题,但是却没有es那么好用,还要考虑的问题反而加大了

    作者回复: 你好,林龍,clickhouse是解决了实时大量计算数据问题,他的QPS并不高,偶尔还会因为错误查询姿势导致服务卡死。使用OLAP主要还是因为大数据的离线计算很缓慢,有时候几百台的大数据服务器集群全量计算20个大任务需要一天时间,而OLAP期望是在一分钟以内,OLAP他主要功能是在加工清理统计过后的大量历史数据中实时计算统计数据返回给图表系统或业务系统使用。所以其实他不是替代MySQL,毕竟MySQL一般都是对外提供业务服务,这很在意响应速度的,普遍希望1秒内返回,对响应速度要求更高。

    2023-01-11归属地:广东
  • 分清云淡
    mysql写性能不差吧?

    作者回复: 你好,分清云淡,核心在于主库只有一个,无法通过增加服务器线性提升写性能。

    2022-12-14归属地:内蒙古
    2
  • Layne
    看到了几个通性: 1.利用分片提高写性能 2.通过后期合并来提高查询性能 3.利用布隆过滤器快速检验数据存在标志位 4.利用顺序性特性,磁盘顺序写,存储文件顺序性,天生降低数据的杂乱

    作者回复: 没毛病

    2022-12-05归属地:北京
  • Elvis Lee
    ClickHouse 是不能轻易修改删除数据的,那我们要如何做历史数据的清理呢? 1.设置TTL 2.表使用ReplaceMergetree

    作者回复: 你好,Elvis Lee,这俩是有效方法~很不错~

    2022-11-24归属地:北京
    3
收起评论
显示
设置
留言
11
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部