ClickHouse

ClickHouse

ClickHouse是俄罗斯第一大搜索引擎Yandex开发的列式储存数据库，Yandex在2016年6月15日开源了ClickHouse。

ClickHouse是一个用于联机分析处理（OLAP）的列式数据库管理系统（columnar DBMS）。
传统数据库在数据大小比较小，索引大小适合内存，数据缓存命中率足够高的情形下能正常提供服务。但残酷的是，这种理想情形最终会随着业务的增长走到尽头，查询会变得越来越慢。你可能通过增加更多的内存，订购更快的磁盘等等来解决问题（纵向扩展），但这只是拖延解决本质问题。

ClickHouse是近年来备受关注的开源列式数据库，主要用于数据分析（OLAP）领域。

ClickHouse从OLAP场景需求出发，定制开发了一套全新的高效列式存储引擎，并且实现了数据有序存储、主键索引、稀疏索引、数据Sharding、数据Partitioning、TTL、主备复制等丰富功能。以上功能共同为ClickHouse极速的分析性能奠定了基础。

应用场景：

• 绝大多数请求都是用于读访问的
• 数据需要以大批次（大于1000行）进行更新，而不是单行更新；或者根本没有更新操作
• 数据只是添加到数据库，没有必要修改
• 读取数据时，会从数据库中提取出大量的行，但只用到一小部分列
• 表很“宽”，即表中包含大量的列
• 查询频率相对较低（通常每台服务器每秒查询数百次或更少）
• 对于简单查询，允许大约50毫秒的延迟
• 列的值是比较小的数值和短字符串（例如，每个URL只有60个字节）
• 在处理单个查询时需要高吞吐量（每台服务器每秒高达数十亿行）
• 不需要事务
• 数据一致性要求较低
• 每次查询中只会查询一个大表。除了一个大表，其余都是小表
• 查询结果显著小于数据源。即数据有过滤或聚合。返回结果不超过单个服务器内存大小

ClickHouse的限制：

• 不支持真正的删除/更新支持 不支持事务（期待后续版本支持）
• 不支持二级索引
• 有限的SQL支持，join实现与众不同
• 不支持窗口功能
• 元数据管理需要人工干预维护

OLAP场景的特点
读多于写
不同于事务处理（OLTP）的场景，比如电商场景中加购物车、下单、支付等需要在原地进行大量insert、update、delete操作，数据分析（OLAP）场景通常是将数据批量导入后，进行任意维度的灵活探索、BI工具洞察、报表制作等。数据一次性写入后，分析师需要尝试从各个角度对数据做挖掘、分析，直到发现其中的商业价值、业务变化趋势等信息。这是一个需要反复试错、不断调整、持续优化的过程，其中数据的读取次数远多于写入次数。这就要求底层数据库为这个特点做专门设计，而不是盲目采用传统数据库的技术架构。

大宽表，读大量行但是少量列，结果集较小
在OLAP场景中，通常存在一张或是几张多列的大宽表，列数高达数百甚至数千列。对数据分析处理时，选择其中的少数几列作为维度列、其他少数几列作为指标列，然后对全表或某一个较大范围内的数据做聚合计算。这个过程会扫描大量的行数据，但是只用到了其中的少数列。而聚合计算的结果集相比于动辄数十亿的原始数据，也明显小得多。

数据批量写入，且数据不更新或少更新
OLTP类业务对于延时（Latency）要求更高，要避免让客户等待造成业务损失；而OLAP类业务，由于数据量非常大，通常更加关注写入吞吐（Throughput），要求海量数据能够尽快导入完成。一旦导入完成，历史数据往往作为存档，不会再做更新、删除操作。

无需事务，数据一致性要求低
OLAP类业务对于事务需求较少，通常是导入历史日志数据，或搭配一款事务型数据库并实时从事务型数据库中进行数据同步。多数OLAP系统都支持最终一致性。

灵活多变，不适合预先建模
分析场景下，随着业务变化要及时调整分析维度、挖掘方法，以尽快发现数据价值、更新业务指标。而数据仓库中通常存储着海量的历史数据，调整代价十分高昂。预先建模技术虽然可以在特定场景中加速计算，但是无法满足业务灵活多变的发展需求，维护成本过高。

优点：

• 为了高效的使用CPU，数据不仅仅按列存储，同时还按向量进行处理；
• 数据压缩空间大，减少IO；处理单查询高吞吐量每台服务器每秒最多数十亿行；
• 索引非B树结构，不需要满足最左原则；只要过滤条件在索引列中包含即可；即使在使用的数据不在索引中，由于各种并行处理机制ClickHouse全表扫描的速度也很快；
• 写入速度非常快，50-200M/s，对于大量的数据更新非常适用。

缺点：

• 不支持事务，不支持真正的删除/更新；
• 不支持高并发，官方建议qps为100，可以通过修改配置文件增加连接数，但是在服务器足够好的情况下；
• SQL满足日常使用80%以上的语法，join写法比较特殊；最新版已支持类似SQL的join，但性能不好；
• 尽量做1000条以上批量的写入，避免逐行insert或小批量的insert，update，delete操作，因为ClickHouse底层会不断的做异步的数据合并，会影响查询性能，这个在做实时数据写入的时候要尽量避开；
• Clickhouse快是因为采用了并行处理机制，即使一个查询，也会用服务器一半的CPU去执行，所以ClickHouse不能支持高并发的使用场景，默认单查询使用CPU核数为服务器核数的一半，安装时会自动识别服务器核数，可以通过配置文件修改该参数。
• 全量数据导入：数据导入临时表 -> 导入完成后，将原表改名为tmp1 -> 将临时表改名为正式表 -> 删除原表
• 增量数据导入： 增量数据导入临时表 -> 将原数据除增量外的也导入临时表 -> 导入完成后，将原表改名为tmp1-> 将临时表改成正式表-> 删除原数据表

参考文章：
Clickhouse优缺点及性能情况
clickhouse 基础知识
ClickHouse深度揭秘