门户网站安全建设方案,网站开发员岗位职责,网站备案 快速,wordpress 回复评论170、clickhouse介绍以及架构
clickhouse一个分布式列式存储数据库#xff0c;主要用于在线分析查询
171、列式存储和行式存储有什么区别#xff1f;
行式存储#xff1a; 1、数据是按行存储的 2、没有建立索引的查询消耗很大的IO 3、建立索引和视图花费一定的物理空间和…170、clickhouse介绍以及架构
clickhouse一个分布式列式存储数据库主要用于在线分析查询
171、列式存储和行式存储有什么区别
行式存储 1、数据是按行存储的 2、没有建立索引的查询消耗很大的IO 3、建立索引和视图花费一定的物理空间和时间资源 4、面对大量的查询复杂的复杂的数据库必须使用大量性能才能满足 列式存储 1、数据按列存储每一列单独存放 2、只访问查询设计的列大量降低系统的IO 3、数据类型一致数据特征相似就可以高效的压缩 优势
分析场景中往往需要读大量行但是少数几个列。在行式存模式下数据按行连续存储所有列的数据都存储在一个block中不参与计算的列在IO时也要全部读出读取操作被严重放大。而列存模式下只需要读取参与计算的列即可极大的减低了IO cost加速了查询。同一列中的数据属于同一类型压缩效果显著。列存往往有着高达十倍甚至更高的压缩比节省了大量的存储空间降低了存储成本。更高的压缩比意味着更小的 data size从磁盘中读取相应数据耗时更短。自由的压缩算法选择。不同列的数据具有不同的数据类型适用的压缩算法也就不尽相同。可以针对不同列类型选择最合适的压缩算法。高压缩比意味着同等大小的内存能够存放更多数据系统cache效果更好。
172、高吞吐写入
CK采用LSM Tree结构数据写入后定期在后台compaction因为是LSM Treeck在数导入的时候全部都是顺序append数据会在后台一定时候compaction但是只要是查询时候会自动的compaction
173、ck中的数据类型
整型包括有符号和无符号int8、int16、int32、int64 浮点型float32、float64 Decimal 布尔型 字符串string、fixedstringfixedstring使用null字节填充末尾字符 枚举类型 时间类型datetime精确到秒、datetime64精确到亚秒、date只精确到天 数组类型
173、表引擎
表引擎是ck的特色决定了如何存储表 日志系列引擎 1、tinylog 以列文件的形式保存在磁盘上不支持索引没有并发控制一般保存少量数据的小表 2、log和StripeLog memory 内存引擎数据以未压缩的原始形式直接保存在内存当中服务器重启数据就会消失读写操作不会相互阻塞不支持索引 合并树家族引擎 1、mergeTree 是ck中最强大的表引擎支持数据分区、主键索引、数据副本、数据采样等特性相当于mysql中的innodb 分区目录是以列文件索引文件表定义文件组成的 数据写入与分区合并任何一个批次的数据写入都会产生一个临时分区不会纳入任何一个已有的分区一段时间过后ck会自动执行合并操作把临时分区的数据合并到已有的分区中也可以手动使用optimize执行 Primary key主键并不用于去重而是用于索引加快查询速度默认的索引粒度为8192行为数据生成以及索引并保存到primary.idx文件内索引数据按照primary key排序稀疏索引只需要少量的索引标记就能够记录大量的数据区间位置信息。数据量越大越明显 跳数索引/二级索引在一级索引的基础之上再加一层索引它们使ClickHouse能够跳过保证没有匹配值的数据块。——INDEX a total_amount TYPE minmax GRANULARITY 5 如果是把一级索引分成几块那么二级索引的粒度就是每次可以跳几块GRANULARITY。每个索引块由颗粒granule组成。例如如果主表索引粒度为8192行GRANULARITY为4则每个索引“块”将为32768行。 2、repacingMergeTree 存储特征完全继承MergeTree会删除排序键值相同的重复项。 ReplacingMergeTree和MergeTree的不同之处在于它会删除排序键值相同的重复项。 数据的去重只能在compaction中出现合并会在未知的时间在后台进行或者使用optiumize进行大会引发对数据的大量读写 使用ORBER BY排序键作为判断重复数据的唯一键。只有在合并分区的时候才会触发删除重复数据的逻辑。以数据分区为单位删除重复数据。当分区合并时同一分区内的重复数据会被删除不同分区之间的重复数据不会被删除。在进行数据去重时因为分区内的数据已经基于ORBER BY进行了排序所以能够找到那些相邻的重复数据。在数据合并的时候ReplacingMergeTree 从所有具有相同排序键的行中选择一行留下如果ver列未指定保留最后一条。如果ver列已指定保留ver值最大的版本。 3、SummingMergeTree 不查询明细。只关心进行汇总聚合结果的场景提供一种预聚合的功能 以order by的列合并为准作为维度列、不在一个分区内的数据不会被聚合只有在用一批次插入的数据才会进行聚合 -ClickHouse会把所有具有相同主键的行合并为一行该行包含了被合并的行中具有数值数据类型的列的汇总值。 4、AggregatingMergeTree 可以理解为SummingMergeTree的升级版能够在合并分区时候按照预先定义的条件聚合数据同时根据预先定义的聚合函数计算数据并得到二进制的格式存入表内AggregateFunction类型字段使用二进制存储在写入数据时需要调用state函数在读数据时需要调用merge函数*表示定义时使用的聚合函数AggregateMergeTree通常作为物化视图的引擎与普通的MergeTree搭配使用 5、CollapsingMergeTree 以增代删的思路支持行级数据修改和删除的表引擎通过一个sign标记位字段记录数据行的状态如果sign标记为1表示这是一行有效的数据如果sign为-1表示改行数据需要被删除当进行分区合并时候同一数据分区内sign为1和-1的一组数据会被抵消 5、VersionedCollapsingMergeTree VersionedCollapsingMergeTree数据折叠也是发生在分区合并时只会对同分区的数据进折叠 174、Update和delete
ck提供了delete和update能力被称为mutation但是一种很重的操作不支持事务原因是每次修改或者和删除都会放弃目标数据的原有分区重建新的分区所以尽量做批量的变更不进行小数据的操作 原理分两步执行同步执行的部分其实只是进行新增数据新增分区和并把旧分区打上逻辑上失效的标记直到触发分区合并的时候才会删除数据释放磁盘空间
175、分片集群
副本可以提高数据的可用性但每台服务器实际上必须是安全量数据对数据的横向扩容没有解决 分片是把一份完整的数据进行切分不同的分片分布到不同的节点上在通过distributed表引擎把数据拼接起来该引擎本身不存数据
176、建表优化
为什么ck中能用数值或者日期时间类型就不用字符串 ck底层将datetime存储为时间戳long类型。但不建议存储long类型datetime不需要经过含函数转换处理执行效率高、可读性好 空值存储 nullable类型会拖慢性能因为存储nullable时候需要创建一额外的文件来存储null的标记nullable列无法被索引一般在业务中采用一个没有实际意义的值代替-101 表参数 如果表中不是必须要保留的全量数据一般指定TTL避免手动删除过期数据的麻烦 写入和删除优化 不要执行单条或者小批量的插入删除操作会产生小分区文件因为每一次插入都会重新分区给merge任务带来巨大压力不要一次写入过多分区或者数据写入太快——会导致merge速度跟不上而报错 谓词下推 所谓的谓词就是对数据的筛选行为下推是尽可能将这些筛选条件优先执行查询的最低端 聚合计算外推 聚合函数内的计算会外推 聚合函数消除
177、查询优化
1、prewhere代替where 两者的作用相同不同之处在于perwhere只支持MergeTree系列引擎的表会先判断数据过滤等待数据过滤之后再读取select系列字段补全prewhere最多可提高十倍性能也会自动优化
2、数据采样 采样修饰符只有在 MergeTree engine 表中才有效且在创建表时需要指定采样策略。
3、列裁剪与分区裁剪 数据量太大时应避免使用 select * 操作查询的性能会与查询的字段大小和数量成线性 表换字段越少消耗的 io 资源越少性能就会越高。
4、orderby 结合 where、limit
5、uniqCombined 替代 distinct 性能可提升 10 倍以上uniqCombined 底层采用类似 HyperLogLog 算法实现能接收 2% 左右的数据误差可直接使用这种去重方式提升查询性能。Count(distinct )会使用 uniqExact精确去重。
178、物化视图
视图只是保存了计算逻辑不保存数据 视图和物化视图的区别ck的物化视图是一种查询结果的持久化用户查起来和普通的表没区别也像是一张时时刻刻计算的表 缺点本质是一个流式数据的使用场景如果一张表加了很多的物化视图在写入的时候就会消耗很多资源 物化视图中的数据是在创建物化视图之后在往对应表中插入数据时候对应数据才会写入到物化视图中 物化视图的名字不能和表明重复
179、ck和mysql主从同步
1、确保mysql和开启binlog和GTID模式binglog记录所有对数据库执行更改的sql语句不包括查二进制文件是mysql数据复制恢复GTID是一种复制方式通过gtid保证了每个在主库上提交的事务在集群中有一个唯一的idGTID (Global Transaction ID)是全局事务ID,由主库上生成的与事务绑定的唯一标识这个标识不仅在主库上是唯一的在MySQL集群内也是唯一的。
2、确保ck物化引擎打开
180、ck的数据分布式存储机制如何设计的
1、分片和复制ck通过分片将数据水平划分为多个部分每个部分存储在不同的节点上每个分片可以有一个或者多个副本副本之间自动同步数据 2、分布式表引擎ck使用分布式表引擎跨节点数据查询和写入 3、数据分区每个分片内数据可以进一步根据分区键被划分为多个分区 4、负载均衡在执行查询时候ck能够自动在所有可用的副本之间进行负载均衡 5、一致性容错
补充CK为什么快
1、存储引擎视角 ck利用存储引擎的特殊涉及充分减少磁盘IO对查询速度的影响用户提交的一条SQL大部分时间消耗在磁盘的IO上 ck对写入数据进行预排序 ck写入数据文件的数据是有序的将数据在写入磁盘前进行排序以保证数据在磁盘上有序预排序在实现范围查找时候可以将大量的随机读转换为顺序读提高IO效率在查找时预排序能做到和未排序的数据相同的性能 列式存储 在列式数据库中同一列的所有数据都在同一个文件中因此在硬盘上是连续的适合OLAP 压缩 ck另一个降低IO的手段是压缩可以减少读取和写入的数据量减少IO时间事务数据库大部分情况下是针对行的操作如果对每一行都进行压缩和解压缩带来的时间消耗是远大于磁盘IO时间这也是为什么所有的事务数据库都不使用压缩技术的原因ck的最小处理单元是块块一般由8192行数据组成一次压缩针对8192行数据降低cpu的压缩和解压缩时间并且列式数据有更好的压缩比 向量化引擎 ck采用了向量化执行引擎能够将多个操作合并成单个向量操作减少了函数调用和内存分配的次数从而提高了执行效率。此外向量化执行还使得数据在内存中的布局更加紧凑 多线程与分布式处理 实现了多线程处理提高整体的处理速度 2、计算引擎视角 ck计算快是来自内部向量化引擎的加持ck计算慢是因为缺乏代价优化器 大量使用向量化运算 为了实现向量化执行需要利用CPU的SIMD指令single instruction Multiple data单条指令操作多条数据它是通过数据i你高兴以提高性能的一种实现方式它的原理是在CPU寄存器方面实现数据的并行计算计算机存储层次如下所示 其中从左往右距离CPU越近访问速度就越快显然能够容纳的数据大小也就越小CPU寄存器也是可以存储数据的CPU从寄存器中获取数据的速度是最快的是内存的300倍是磁盘的3000万倍 ck中的很多内置函数。使用时候ck会自动进行向量化优化 查询中不使用join或尽可能减少join操作 ck中没有代价优化器说明在进行join的时候会出现内存不足的情况使用ck时候应当避免join操作但join操作在ODS建模时候大量存在数据量大的时候建模工作应当下推到spark中进行 ck快的本质 ck快的本质是利用了cpu进行加速 总结CK快的原因 ck是列式存储、索引机制、数据压缩、ck使用了向量化引擎寄存器、ck使用cpu加速、ck会在内存中进行group by并使用hash table装载数据 补充ck的几点不足
1、不支持事务不能把它用于OLTP事务操作的场景 2、不擅长根据主键按行粒度进行查询所以不应该把ck当作键值对数据库使用 3、不擅长删除和修改数据
补充ck相关补充
1、CK提供了标准的SQL查询接口CK大小是大小写敏感的关键字非大小敏感 2、ck中向量化是通过数据级别的并行方式提升了性能那么多线程处理就是通过线程级并行的方式实现了性能提升 3、在分布式领域移动计算优于移动数据在服务器之间网络传输的成本是很高的相比移动数据更好的是预先将数据分布到各台服务器将数据的计算查询直接下推到数据所在的服务器 4、多主架构在传统的hdfs、spark中都采用了主从架构一个leader节点统筹全局ck采用多主架构集群中的每个节点角色对等客户端访问任意一个节点都能得到相同的效果集群中所有节点功能相同避免单点故障 5、数据分片分区时表的分区根据关键字将最终结果写入不同的文件中而分复用了数据库的分区相当于在原有的分区下作为第二层分区是在不同节点上的体现 6、ClickHouse 最终选择了这些算法对于常量使用 Volnitsky 算法对于非常量使用 CPU 的向量化执行 SIMD暴力优化正则匹配使用 re2 和 hyperscan 算法。
