9.ClickHouse系列之数据一致性保证

1. 数据一致性保证

对于ReplacingMergeTree引擎，我们之前讲过在后台合并的时间不定，合并前查询会存在数据不一致问题。

CREATE TABLE study.house (
    id String,
    city String,
    region String,
    name String,
    price Float32,
    publish_date DateTime
) ENGINE=ReplacingMergeTree(publish_date) PARTITION BY toYYYYMMDD(publish_date) PRIMARY KEY(id) ORDER BY (id, city, region, name)
SETTINGS index_granularity=8192

INSERT INTO study.house VALUES (1, '上海', '静安', '场中小区', 60000, toDateTime('2022-05-01'));
INSERT INTO study.house VALUES (1, '上海', '静安', '场中小区', 60000, toDateTime('2022-05-01'));
INSERT INTO study.house VALUES (1, '上海', '静安', '场中小区', 61000, toDateTime('2022-06-01'));
INSERT INTO study.house VALUES (1, '上海', '静安', '场中小区', 61000, toDateTime('2022-06-01'));

查询结果如下：
1,上海,静安,场中小区,61000,2022-06-01 00:00:00
1,上海,静安,场中小区,61000,2022-06-01 00:00:00
1,上海,静安,场中小区,60000,2022-05-01 00:00:00
1,上海,静安,场中小区,60000,2022-05-01 00:00:00

为保证数据一致性，有以下解决方案

1.1 手动执行分区合并

optimize table study.house final;

查询结果如下：
1,上海,静安,场中小区,61000,2022-06-01 00:00:00
1,上海,静安,场中小区,60000,2022-05-01 00:00:00

可以看到，虽然id, city, region, name为order by的唯一键，但是price价格不一致，仍然会作为两个值进行保留

1.2 通过Group By去重

SELECT id, city, region, name, argMax(price, publish_date), max(publish_date) FROM study.house GROUP BY id, city, region, name;

查询结果如下：
1,上海,静安,场中小区,61000,2022-06-01 00:00:00

1.3 通过final查询

在查询语句后增加FINAL修饰符，这样查询过程中将会执行Merge的特殊逻辑。FINAL在新版本中，支持多线程执行，可以通过max_threads设置

EXPLAIN SELECT id, city, region, name, price, publish_date FROM study.house FINAL SETTINGS max_threads=2;

查询结果如下：
1,上海,静安,场中小区,61000,2022-06-01 00:00:00

2. 特点介绍

2.1 列式存储

采用列式存储时，数据在磁盘上的组织结构为：
1 2 3 张三 李四 王五 18 20 25
好处：

• 对于列的聚合、计数、求和等统计操作由于列式存储
• 由于列数据类型相同，更容易数据压缩
• 由于数据压缩比更好，不仅节省磁盘空间，更便于cache发挥空间

2.2 DBMS功能完备

几乎覆盖标准SQL大部分语法，包括DDL与DML,以及配套函数，用户管理权限管理，数据备份与恢复

2.3 引擎种类丰富

ClickHouse与Mysql类似，把表级的存储引擎插件化，根据表的不同需求可以设定不同的存储引擎。目前包括合并树、日志、接口和其他四大类20多种引擎

2.4 高吞吐写入能力

ClickHouse采用类LSM Tree的结构，数据写入后定期在后台Compaction。ClickHouse在数据导入时全部是顺序append写，写入后数据段不可更改，在后台Compaction时也是多个段merge sort后顺序写回磁盘。顺序写的特性，充分利用了磁盘的吞吐能力。

官方公开能达到50MB_{200MB写入吞吐能力，按照每行100Byte计算，大约相当于50}200W条/s的写入速度

2.5 数据分区与线程级并行

ClickHouse将数据划分为多个partition,每个partition在进一步划分为多个index granularity(索引粒度)，然后通过多个CPU核心分别处理其中一部分在实现并行处理。因此，单条Query就能利用整机所有CPU

就ClickHouse的特点而言，比较适合处理后的宽表的存储与统计分析

欢迎关注公众号算法小生或沈健的技术博客shenjian.online

3. 为啥这么快

好像面试的东西大家更感兴趣，我会陆续给大家分享一些真实面试题目，但还是已系列性分享为主，毕竟要招的是实实在在干活的人，当然要是在开源社区有一定的贡献，呢还不是妥妥的不需要八股吗

3.1 ClickHouse为什么这么快

ClickHouse 之所以如此快，是因为它在设计和实现时采用了多种技术和优化策略：
1.列式存储：ClickHouse采用列式存储，这种方式可以提高数据压缩比，减少I/O访问，从而加速查询速度
2.数据分区：ClickHouse支持将数据分成不同的分区，可以减少数据扫描的范围，提高查询速度
3.数据本地化：ClickHouse可以将数据存储在本地磁盘上，避免了数据网络传输的开销
4.数据压缩：ClickHouse支持多种数据压缩算法，可以降低磁盘I/O访问和网络传输的数据量
5.向量化计算：ClickHouse使用SIMD指令集和CPU缓存来实现向量化计算，这样可以在处理大数据集时提高计算速度
6.并行查询：ClickHouse支持并行查询，可以将一个查询分成多个子查询，同时执行，从而加速查询速度
7.多级缓存：ClickHouse支持多级缓存，可以将热数据存储在内存中，减少磁盘I/O访问
综上所述，ClickHouse采用多种优化技术，如列式存储、数据分区、数据本地化、数据压缩、向量化计算、并行查询和多级缓存等，使得它具有出色的查询性能和扩展性

追问:如何理解数据本地化?

“数据本地化”是指将数据存储在本地磁盘上，而不是分布式存储在多个节点上。ClickHouse支持本地化存储方式，这意味着用户可以将数据存储在单个节点的本地磁盘上，而不是分布式存储在多个节点上

追问:简单介绍下ClickHouse数据压缩算法?

1.LZ4 压缩算法：LZ4 是一种无损压缩算法，它可以快速压缩和解压数据，并且具有较高的压缩比。在ClickHouse中，LZ4 压缩算法常用于对字典类型数据进行压缩，例如IP地址、城市名称等。
2.Zstandard 压缩算法：Zstandard 是一种压缩速度快、压缩比高的无损压缩算法。在ClickHouse中，Zstandard 压缩算法常用于对文本、JSON、CSV等非字典类型数据进行压缩

3.2 ClickHouse为什么比ES快

ClickHouse和Elasticsearch（ES）是两种不同的数据存储和处理系统，它们的设计和应用场景也有很大不同。虽然它们都可以用于数据分析和搜索，但是它们的性能特点有所不同:
1.存储结构：ClickHouse采用列式存储结构，这种方式可以提高数据压缩比，减少I/O访问，从而加速查询速度。ES采用文档式存储结构，这种方式对实时索引和搜索有很好的支持，但是在大规模数据查询和聚合计算时性能会受到一定的影响
2.数据处理方式：ClickHouse采用向量化计算方式，可以在处理大数据集时提高计算速度，而ES则采用迭代式计算方式，对于实时索引和搜索有很好的支持，但是在大规模数据查询和聚合计算时性能会较慢
3.查询优化：ClickHouse在查询优化方面有很多优秀的算法和技术，如自适应索引、数据分区、多级缓存等，可以有效地提高查询性能。而ES在这方面的优化相对较少
4.数据可靠性：ClickHouse采用多副本数据备份机制，可以保障数据的可靠性和容错性。而ES的数据备份机制相对较弱

总体来说，ClickHouse和ES各有优劣，选择哪种系统主要取决于应用场景和需求。如果需要进行大规模的数据查询和聚合计算，或者需要保证数据的可靠性和容错性，可以选择ClickHouse；如果需要进行实时索引和搜索，或者需要支持文本分析和聚合等高级搜索功能，可以选择ES

追问:简单介绍下自适应索引

自适应索引是一种基于查询模式自动调整索引策略的索引技术。与传统的手动创建和维护索引不同，自适应索引可以根据数据的访问模式动态地选择合适的索引策略，从而提高查询性能和减少存储开销。
自适应索引通常采用统计分析的方法来分析查询模式和数据分布，以选择最适合的索引策略。例如，可以根据频繁的查询条件创建多个索引，或者根据数据的分布情况创建分区索引等。自适应索引还可以在数据访问模式发生变化时自动调整索引策略，以适应新的查询需求。
自适应索引通常应用于列式存储数据库等大规模数据存储系统，由于数据量庞大和查询复杂度高，手动创建和维护索引往往是一项耗时、耗力的任务。通过采用自适应索引技术，可以降低索引维护成本，提高查询性能和效率

3.3 列式存储的缺点

1.更新操作性能低：由于数据存储在不同的列中，对于每次更新操作，需要更新多个列，这会导致写入性能比行式存储低。
2.高并发性能问题：当多个查询请求需要同时读取不同的列时，由于数据存储在不同的列中，可能需要进行多次I/O操作，这会导致高并发性能问题。
3.不适合实时查询：由于列式存储需要对多个列进行扫描和聚合计算，因此在实时查询方面可能存在一定的局限性。
4.不适合小规模数据集：由于列式存储的优势在于大规模数据集的处理，因此在处理小规模数据集时可能会出现存储空间的浪费和查询性能不佳等问题。
总的来说，列式存储适用于大规模数据集的分析和查询，但也需要根据具体应用场景和需求来选择合适的数据存储方式。对于更新频繁、并发性要求高、实时查询等场景，可能需要考虑其他存储方式
欢迎关注公众号算法小生与我沟通交流

欢迎关注公众号算法小生或沈健的技术博客shenjian.online