ClickHouse设计原理简介(上)

简介: ClickHouse设计原理简介(上)

简介


1、由Yandex开源的高性能OLAP数据库

2、采用列式存储结构,拥有高效的数据压缩能力

3、通过多核并行处理以及向量执行引擎提升查询能力

4、多样化的表引擎用于支撑不同的应用场景

5、支持多线程和分布式处理

ClickHouse性能

100million条数据量下,ClickHouse的单表聚合查询性能非常高,是Greenplum(x2)集群的16倍,是PostgreSQL的10倍,是Mysql的833倍。

适用场景

  • • 商业智能
  • • 电信行业数据存储统计
  • • 新浪微博用户行为记录分析
  • • 电子商务用户分析
  • • 金融等领域

不适用的场景

  • • 不支持事务
  • • 不擅长根据主键按行粒度进行查询(虽然支持)
  • • 不擅长按行删除数据(虽然支持)
  • • 不擅长按行更新数据(虽然支持)

ClickHouse采用列式存储,其格式相对于行存储格式来说,对行粒度查询进行处理稍显劣势。


核心特性


完备的DBMS功能

  • • DDL:可以动态的创建、修改或删除数据库、表和视图
  • • DML:可以动态查询、插入、修改或删除数据
  • • 权限控制:可以按照用户粒度设置数据库或表的操作权限,保证数据安全
  • • 数据备份与恢复,提供了数据的导入和导出恢复机制
  • • 分布式管理:提供集群模式,能够自动管理多个数据库节点

列式存储和数据压缩

  • • 列式存储有效减少查询时扫描数据量
  • • 列式存储比行存储的另一个优势是数据压缩的友好性
  • • 同一个字段拥有相同的数据类型和实现语义,数据重复项的可能性更高
  • • 默认采用LZ4压缩算法(速度较快,但压缩率较低),以及ZSTD压缩算法(速度较慢,压缩率较高)
  • • ClickHouse的LZ4算法在Yandex的生产环境数据压缩比能达到8:1
  • • TPCH数据(无索引),ckdb压缩率达到52%,rocksdb达到61%

行式存储是按行读取,比如一个表中有很多列,读取其中三列,就需要对所有列进行一个扫描;列式存储只需要对所需要的三列进行读取,就有效的减少了查询时候的扫描数据量。

列式存储是一个字段作为一组数据进行一个存储。

向量化执行引擎

  • • 利用寄存器硬件层面的特性,为上层的程序性能带来了指数级的提升
  • • SIMD指令,单条指令操作多条数据,通过数据并行以提高数据的并行操作。它的原理是在CPU寄存器层面实现数据的并行操作。

image.png

通过数据的并行来提高数据的查询能力和处理能力。

多样化表引擎

  • • 为了避免平庸,ClickHouse拥有和Mysql类似的表引擎设计,它拥有4大类30多种表引擎
  • • 每一种表引擎都拥有各自的特点,用户可以根据实际业务场景的要求,选择合适的表引擎使用

image.png

  • • ReplacingMergeTree

主要用于相同主键进行合并处理比如主键重复的数据有多条,可以在内部合并,最终保留一条

多线程和分布式

  • • 多线程

如果说向量化执行是通过数据级并行的方式提升性能,那么多线程就是通过线程级并行的方式实现性能的提升,默认CPU核数的一半

  • • 分布式

为了利用分布式设计,ClickHouse在数据存取,即支持分区(纵向扩展、利用多线程原理),也支持分片(横向扩展,利用分布式原理,由replica组成)

另外ClickHouse提供了本地表和分布式表的概念,本地表相当于数据分片,分布式表是本地表的访问代理,其本身不存储任何数据


image.png



ClickHouse架构设计


多主架构

区别于Master-Slave主从架构,ClickHouse采用了Multi-Master多主架构,集群中的每个节点角色对等,客户端访问任意一个节点都能得到相同的效果

多主架构具有很多优势,不用区分多主控节点,数据节点和计算节点,集群中的所有节点功能相同,客户端访问每一个节点都能得到相同的效果

image.png



MergeTree原理解析


image.png


相关文章
|
存储 SQL 运维
涨姿势 | 一文读懂备受大厂青睐的ClickHouse高性能列存核心原理
本文尝试解读ClickHouse存储层的设计与实现,剖析它的性能奥妙
3328 0
涨姿势 | 一文读懂备受大厂青睐的ClickHouse高性能列存核心原理
|
存储 自然语言处理 算法
ClickHouse设计原理简介(下)
ClickHouse设计原理简介(下)
330 0
ClickHouse设计原理简介(下)
|
存储 SQL 设计模式
ClickHouse设计原理简介(中)
ClickHouse设计原理简介(中)
365 1
ClickHouse设计原理简介(中)
|
存储 消息中间件 SQL
Sentry 监控 - Snuba 数据中台架构简介(Kafka+Clickhouse)
Sentry 监控 - Snuba 数据中台架构简介(Kafka+Clickhouse)
694 0
Sentry 监控 - Snuba 数据中台架构简介(Kafka+Clickhouse)
|
存储 SQL 分布式计算
clickhouse简介
clickhouse简介
579 0
|
22天前
|
存储 关系型数据库 数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 多对一和多对多
【6月更文挑战第7天】该文探讨数据模型,比较了“多对一”和“多对多”关系。通过使用ID而不是纯文本(如region_id代替"Greater Seattle Area"),可以实现统一、避免歧义、简化修改、支持本地化及优化搜索。在数据库设计中,需权衡冗余和范式。文档型数据库适合一对多但处理多对多复杂,若无Join,需应用程序处理。关系型数据库则通过外键和JOIN处理这些关系。文章还提及文档模型与70年代层次模型的相似性,层次模型以树形结构限制了多对多关系处理。为克服层次模型局限,发展出了关系模型和网状模型。
24 6
|
24天前
|
XML NoSQL 数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 概念 + 数据模型
【6月更文挑战第5天】本文探讨了数据模型的分析,关注点包括数据元素、关系及不同类型的模型(关系、文档、图)与Schema模式。查询语言的考量涉及与数据模型的关联及声明式与命令式编程。数据模型从应用开发者到硬件工程师的各抽象层次中起着简化复杂性的关键作用,理想模型应具备简洁直观和可组合性。
16 2
|
21天前
|
SQL 人工智能 关系型数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 文档模型中Schema的灵活性
【6月更文挑战第8天】网状模型是层次模型的扩展,允许节点有多重父节点,但导航复杂,需要预知数据库结构。关系模型将数据组织为元组和关系,强调声明式查询,解耦查询语句与执行路径,简化了访问并通过查询优化器提高效率。文档型数据库适合树形结构数据,提供弱模式灵活性,但在Join支持和访问局部性上不如关系型。关系型数据库通过外键和Join处理多对多关系,适合高度关联数据。文档型数据库的模式灵活性体现在schema-on-read,写入时不校验,读取时解析,牺牲性能换取灵活性。适用于不同类型或结构变化的数据场景。
19 0
|
23天前
|
SQL JSON NoSQL
【DDIA笔记】【ch2】 数据模型和查询语言 -- 关系模型与文档模型
【6月更文挑战第6天】关系模型是主流数据库模型,以二维表形式展示数据,支持关系算子。分为事务型、分析型和混合型。尽管有其他模型挑战,如网状和层次模型,但关系模型仍占主导。然而,随着大数据增长和NoSQL的出现(如MongoDB、Redis),强调伸缩性、专业化查询和表达力,关系模型的局限性显现。面向对象编程与SQL的不匹配导致“阻抗不匹配”问题,ORM框架缓解但未完全解决。文档模型(如JSON)提供更自然的嵌套结构,适合表示复杂关系,具备模式灵活性和更好的数据局部性。
21 0
|
25天前
|
敏捷开发 存储 缓存
【DDIA笔记】【ch1】 可靠性、可扩展性和可维护性 -- 可维护性
【6月更文挑战第4天】本文探讨了Twitter面临的一次发推文引发的巨大写入压力问题,指出用户粉丝数分布是决定系统扩展性的关键因素。为解决此问题,Twitter采用混合策略,大部分用户推文扇出至粉丝主页时间线,而少数名人推文则单独处理。性能指标包括吞吐量、响应时间和延迟,其中高百分位响应时间对用户体验至关重要。应对负载的方法分为纵向和横向扩展,以及自动和手动调整。文章强调了可维护性的重要性,包括可操作性、简单性和可演化性,以减轻维护负担和适应变化。此外,良好设计应减少复杂性,提供预测性行为,并支持未来改动。
21 0

热门文章

最新文章