ClickHouse设计原理简介(中)

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

ClickHouse核心模块--Column&Field


  • • Column与Field是ClickHouse数据最基础的映射单元
  • • 内存中的每一列数据由一个Column对象表示。Column对象分为接口和实现两部分,在IColunn接口对象中,定义了对数据进行各种关系运算的方法
  • • 在大多数场合,ClickHouse都会以整列的方式操作数据。如果需要操作单个具体的数值,则需要使用Field对象,Field对象代表一个单值。与Column对象的泛化设计思路不同,Field对象使用了聚合的设计模式。
  • • 在Field对象内部聚合了Null、UInt64、String和Array等13种数据类型及相应的处理逻辑。


ClickHouse核心模块--DataType&Block


  • • 数据的序列化核反序列化工作由DataType负责。IDataType接口定义了许多正反序列化的方式,它们成对出现
  • • ClickHouse内部的数据操作是面向Block对象进行的,并且采用流的形式
  • • Block对象可以看作数据表的子集。Block对象是由Column、DataType及列名称组成的三元组,仅通过Block对象能完成一系列的数据操作
  • • Block流操作有两组顶层接口,IBlockInputStream负责数据的读取和关系运算;IBlockOutputStream负责将数据输出到下一环节。IBlockInputStream接口有众多实现类,这些实现类大致可以分为三类,第一类用于处理数据定义的DDL操作;第二类用于处理关系运算的各种操作;第三类是与表引擎呼应,每一种表引擎都拥有与之对应的。


ClickHouse核心模块--Parser&Interpreter


  • • Parser分析器可以将一条SQL语句以递归下降的方式解析成AST语法树的形式。不同的SQL语句,会经由不同的Parser实现类解析
  • • Interpreter解释器负责解释AST,并进一步创建查询的执行Processor,起到串联整个查询过程的作用,它会根据解释器的类型,聚合它所需要的资源


ClickHouse核心模块--Functions&Aggregate Functions


  • • ClickHouse主要提供两类函数,普通函数核聚合函数
  • • 普通函数由IFunction接口定义,拥有数十钟函数实现,普通函数是没有状态的,而是采用向量化的方式直接作用于一整列数据
  • • 聚合函数由AggregateFunction接口定义,聚合函数是有状态的,以COUNT聚合函数为例,其AggregateFunctionCount的状态使用整型Unit64记录,聚合函数的状态支持序列化核反序列化。所以能够在分布式节点之间进行传输,以实现增量计算。


MergeTree表引擎家族


image.png

  • • PARTITION BY 选填,分区键
  • • ORDER BY 必填,排序键
  • • PRIMARY KEY 选填,表示主键,声明之后会依次按照主键字段生成一级索引,用于加速表查询。如果不指定,那么主键默认和排序键相同。MergeTree允许主键有重复数据
  • • SAMPLE KEY 选填,抽样表达式。用于声明数据以何种标准进行采样,其用于配合SAMPLE子查询使用
  • • INDEX 选填,二级索引,也叫做跳数索引
  • • SETTINGS 选填,用于指定一些额外的参数,例index_granularity(索引粒度),min_compress_block_size(最小的压缩数据块大小)

MergeTree存储结构

image.png

  • • columns.txt

列信息文件,使用文本文件存储,用于保存分区下的列字段信息

  • • primay.idx

索引文件,用于存储稀疏索引

  • • [column].bin

数据文件,使用压缩格式存储,默认使用LZ4压缩格式,用于存储某一列数据

  • • [column].mrk

列字段标记,保存了bin文件中的数据偏移量信息,MergeTree通过标记文件建立了primay.idx稀疏索引与bin数据文件的映射关系

  • • [column].mrk2

如果用了自适应大小的索引间隔,则标记文件会以.mrk2命名

  • • partition.dat

用于保存当前分区表达式最终生成值

  • • minmax_[column].idx

用于记录当前分区字段对应原始数据的最小值和最大值

  • • skip_idx_[column]


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