# ClickHouse概述 [TOC] ## ClickHouse简介 ​ - ClickHouse是俄罗斯的Yandex于2016年开源的一个用于联机分析(OLAP:Online Analytical Processing)的列式数据库管理系统(DBMS:Database Management System) , 主要用于在线分析处理查询（OLAP），能够使用SQL查询实时生成分析数据报告。 ClickHouse的全称是Click Stream，Data WareHouse，简称ClickHouse - ClickHouse是一个完全的列式分布式数据库管理系统(DBMS)，允许在运行时创建表和数据库，加载数据和运行查询，而无需重新配置和重新启动服务器，支持线性扩展，简单方便，高可靠性，容错。它在大数据领域没有走 Hadoop 生态，而是采用 Local attached storage 作为存储，这样整个 IO 可能就没有 Hadoop 那一套的局限。它的系统在生产环境中可以应用到比较大的规模，因为它的线性扩展能力和可靠性保障能够原生支持 shard + replication 这种解决方案。它还提供了一些 SQL 直接接口，有比较丰富的原生 client。 ## 官方文档 中文文档 https://clickhouse.tech/docs/zh/ 英文文档 https://clickhouse.tech/docs/en/ 版本原因，中文文档不全面，建议使用英文文档 例如：  ## ClickHouse特性 - 列式数据库 - 数据压缩 - 支持SQL - 实时数据更新 ... https://clickhouse.tech/docs/zh/introduction/distinctive-features/ ## ClickHouse性能 - 单个查询的吞吐量 吞吐量可以使用每秒处理的行数或每秒处理的字节数来衡量。如果数据被放置在page cache中，则一个不太复杂的查询在单个服务器上大约能够以2-10GB／s（未压缩）的速度进行处理（对于简单的查询，速度可以达到30GB／s）。如果数据没有在page cache中的话，那么速度将取决于你的磁盘系统和数据的压缩率。例如，如果一个磁盘允许以400MB／s的速度读取数据，并且数据压缩率是3，则数据的处理速度为1.2GB/s。这意味着，如果你是在提取一个10字节的列，**那么它的处理速度大约是1-2亿行每秒**。 对于分布式处理，处理速度几乎是线性扩展的，但这受限于聚合或排序的结果不是那么大的情况下。 - 查询的延迟时间 如果一个查询使用主键并且没有太多行(几十万)进行处理，并且没有查询太多的列，那么在数据被page cache缓存的情况下，它的延迟应该**小于50毫秒**(在最佳的情况下应该小于10毫秒)。 否则，延迟取决于数据的查找次数。如果你当前使用的是HDD，在数据没有加载的情况下，查询所需要的延迟可以通过以下公式计算得知： 查找时间（10 ms） * 查询的列的数量 * 查询的数据块的数量。 - 查询的吞吐量 ClickHouse可以在单个服务器上每秒处理数百个查询（在最佳的情况下最多可以处理数千个）。但是由于这不适用于分析型场景。因此我们建议每秒最多查询100次。 - 写入性能 我们建议每次写入不少于1000行的批量写入，或每秒不超过一个写入请求。当使用tab-separated格式将一份数据写入到MergeTree表中时，写入速度大约为50到200MB/s。如果您写入的数据每行为1Kb，**那么写入的速度为50，000到200，000行每秒**。如果您的行更小，那么写入速度将更高。为了提高写入性能，您可以使用多个INSERT进行并行写入，这将带来线性的性能提升。 https://clickhouse.tech/docs/zh/introduction/performance/ ## ClickHouse优点 灵活的MPP架构,支持线性扩展，简单方便，高可靠性 多服务器分布式处理数据 ,完备的DBMS系统 底层数据列式存储,支持压缩,优化数据存储,优化索引数据 优化底层存储 容错跑分快：比Vertica快5倍，比Hive快279倍，比MySQL快800倍,其可处理的数据级别已达到10亿级别 功能多：支持数据统计分析各种场景，支持类SQL查询，异地复制部署 海量数据存储,分布式运算,快速闪电的性能,几乎实时的数据分析 ,友好的SQL语法,出色的函数支持 ## ClickHouse缺点 不支持事务，不支持真正的删除/更新 不支持高并发，官方建议qps为100，可以通过修改配置文件增加连接数，但是在服务器足够好的情况下 不支持二级索引 不擅长多表join 元数据管理需要人为干预 尽量做1000条以上批量的写入，避免逐行insert或小批量的insert，update，delete操作 依赖zookeeper ## 使用场景 1.绝大多数请求都是用于读访问的, 要求实时返回结果 2.数据需要以大批次（大于1000行）进行更新，而不是单行更新；或者根本没有更新操作 3.数据只是添加到数据库，没有必要修改 4.读取数据时，会从数据库中提取出大量的行，但只用到一小部分列 5.表很“宽”，即表中包含大量的列 6.查询频率相对较低（通常每台服务器每秒查询数百次或更少） 7.对于简单查询，允许大约50毫秒的延迟 8.列的值是比较小的数值和短字符串（例如，每个URL只有60个字节） 9.在处理单个查询时需要高吞吐量（每台服务器每秒高达数十亿行） 10.不需要事务 11.数据一致性要求较低 [原子性 持久性 一致性 隔离性] 12.每次查询中只会查询一个大表。除了一个大表，其余都是小表 13.查询结果显著小于数据源。即数据有过滤或聚合。返回结果不超过单个服务器内存大小 ## 不适合场景 不支持事务（对并发的读写不支持，批量插入是支持事务的） 不擅长根据主键按行粒度进行查询，不应该把ClickHouse当作Key-Value数据库使用 不擅长按行删除数据（支持但不擅长，一般批量删除） ## OLTP和OLAP 业务类系统主要供基层人员使用，进行一线业务操作，通常被称为OLTP（On-Line Transaction Processing，联机事务处理）。 数据分析的目标则是探索并挖掘数据价值，作为企业高层进行决策的参考，通常被称为OLAP（On-Line Analytical Processing，联机分析处理）。  从功能角度来看，OLTP负责基本业务的正常运转，而业务数据积累时所产生的价值信息则被OLAP不断呈现，企业高层通过参考这些信息会不断调整经营方针，也会促进基础业务的不断优化，这是OLTP与OLAP最根本的区别。 OLAP不应该对OLTP产生任何影响，（理想情况下）OLTP应该完全感觉不到OLAP的存在。 ## 核心概念 列式存储 列式数据库更适合于OLAP场景(对于大多数查询而言，处理速度至少提高了100倍)，下面详细解释了原因(通过图片更有利于直观理解)： <img src="https://clickhouse.tech/docs/zh/images/row-oriented.gif"/> <img src="https://clickhouse.tech/docs/zh/images/column-oriented.gif"/> 分片 - ClickHouse支持分片，而分片则依赖集群。每个集群由1到多个分片组成，而每个分片则对应了ClickHouse的1个服务节点。分片的数量上限 取决于节点数量（1个分片只能对应1个服务节点）。ClickHouse并不像其他分布式系统那样，拥有高度自动化的分片功能。 - ClickHouse提供了本地表（Local Table）与分布式表（Distributed Table）的概念。一张本地表等同于一份数据的分片。而分布式表本身不存储任何数据，它是本地表的访问代理，其作用类似分库中间件。借助分布式表，能够代理访问多个数据分片，从而实现分布式查询。 副本 - 数据存储副本,在集群模式下实现高可用 , 简单理解就是相同的数据备份，在CK中通过复制集，我们实现保障了数据可靠性外，也通过多副本的方式，增加了CK查询的并发能力。这里一般有2种方式：（1）基于ZooKeeper的表复制方式；（2）基于C[1.2ClickHouse安装](1.2ClickHouse%E5%AE%89%E8%A3%85.md)luster的复制方式。由于我们推荐的数据写入方式本地表写入，禁止分布式表写入，所以我们的复制表只考虑ZooKeeper的表复制方案。 分区 - ClickHouse支持PARTITION BY子句，在建表时可以指定按照任意合法表达式进行数据分区操作，比如通过toYYYYMM()将数据按月进行分区、toMonday()将数据按照周几进行分区、对Enum类型的列直接每种取值作为一个分区等。数据以分区的形式统一管理和维护一批数据! 表 - 表的基本结构和数据 引擎 - 表引擎决定了数据在文件系统中的存储方式，常用的也是官方推荐的存储引擎是MergeTree系列，如果需要数据副本的话可以使用ReplicatedMergeTree系列，相当于MergeTree的副本版本。读取集群数据需要使用分布式表引擎Distribute。 向量化 - ClickHouse实现了向量执行引擎（Vectorized execution engine），对内存中的列式数据，一个batch调用一次SIMD指令（而非每一行调用一次），不仅减少了函数调用次数、降低了cache miss，而且可以充分发挥SIMD指令的并行能力，大幅缩短了计算耗时。向量执行引擎，通常能够带来数倍的性能提升。 (SIMD全称Single Instruction Multiple Data，单指令多数据流，能够复制多个操作数，并把它们打包在大型寄存器的一组指令集。以同步方式，在同一时间内执行同一条指令。) ## ClickHouse VS ElasticSearch https://developer.aliyun.com/article/783804?spm=5176.20128342.J_6302206100.2.9a567ba2KDUuLj&groupCode=clickhouse