暂无图片
暂无图片
暂无图片
暂无图片
暂无图片
首页 / 《ClickHouse原理解析与应用实践》

《ClickHouse原理解析与应用实践》

data之道 2021-05-16
1324

    花了几天时间断断续续看完了一本书，《ClickHouse原理解析与应用实践》，感觉蛮有意思，和大家分享下，大部分内容来自于这本书。

背景

我们有对大量数据明细集聚合查询的场景，很像OLAP需求，因为有同事使用过CH，很是推荐，而且在查CH相关资料时，发现功能很强大，能满足我们的业务需求。知其然不知其所以然，为了对ClickHouse有个深入了解、避免采坑，就看了下官方文档和相关的书。

ClickHouse是什么

ClickHouse是个列式存储的OLAP数据库，支持数据分区（纵向扩展，利用多线程原理）和分片（横向扩展，利用分布式原理）；擅长有一级或二级索引的大数据量单表查询。

ClickHouse不适用什么场景

❑ 不支持事务，不能回滚，使用多版本并发控制、没有锁机制；批量插入、批量更新性能较好
❑ 不适于OLTP场景
❑ 不擅长按行删除数据（虽然支持）
❑ UPDATE/DELETE是异步、非原子的操作，
❑ 不擅长根据主键按行粒度进行查询（虽然支持），故不应该把ClickHouse当作Key-Value数据库使用；随机查询性能较差
❑ 主键不具有唯一约束，主键是为了做一级索引
❑ 不支持和Hadoop生态集成
❑ 不是像Spark、Flink一样的批量、流式数据处理引擎

一般为了解决某个场景迭代产生了某个技术，没有一种技术可以完美适应所有大数据场景，都各有所长、各有所短；技术的世界，没有银弹。

ClickHouse VS Kylin

从数据库的角度来看，ClickHouse更像一个数据库，而Kylin融合使用不同hadoop生态框架最终达到OLAP的目标。
Kylin快就快在预计算，查询时不再访问原始数据，直接利用索引结合聚会结果再二次计算；ClickHouse也有预计算的表引擎（SummingMergeTree、AggregatingMergeTree），CH是用后台进程定期合并、聚合原始数据的，而Kylin是借助第三方计算框架（Hive或Spark）。
Kylin也是用Hbase、Parquet做底层数据存储，使用Hbase或spark做分布式计算；ClickHouse自己管理数据的存储，有完善的分片、分布式解决方案。
Kylin适用固定模式的聚合查询，ClickHouse适用灵活的或者有明细查询需求的场景。

ClickHouse架构

❑ 多主：集群中的每个节点角色对等，客户端访问任意一个节点都能得到相同的效果
❑ 分布式表和本地表：本地表存储和管理数据；分布式表本身不存储任何数据，它是本地表的访问代理，其作用类似分库中间件。借助分布式表，能够代理访问多个数据分片，从而实现分布式查询
❑ 分布式查询：分布式查询是用分布式表引擎实现的，“分布式”表不存储数据，提供一个映射到所有本地表的视图，当查询分布式表时，会基于设置将请求路由到远程节点。
❑ 表副本：副本也是通过特定的表存储引擎实现的，副本使用异步多主方案，也就是说我们可以将数据写入到任意一个副本节点，然后数据会以异步复制的方式同步到其他节点。
作为一个OLAP数据库，ClickHouse给我们提供了丰富的表引擎，为实现不同的业务需求保证了最大的灵活性，但同时也为运维也带了灾难。
数据库clickhouse
文章转载自data之道，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

评论