ClickHouse 21.7.3.14-2(十一) 数据一致性

查询 CK 手册发现，即便对数据一致性支持最好的 Mergetree，也只是保证最终一致性我们在使用 ReplacingMergeTree、SummingMergeTree 这类表引擎的时候，会出现短暂数据不一致的情况。在某些对一致性非常敏感的场景，通常有以下几种解决方案。

在写入数据后，立刻执行 OPTIMIZE 强制触发新写入分区的合并动作。

可以根据自己实际重复的字段进行去重，然后对每个重复的组里选自己想要的数据。

argMax(field1，field2) 按照 field2 的最大值取 field1 的值。

这种固定的查询语句我们可以提前封装为一个视图，以后只查视图就好了

查询视图

在查询语句后增加 FINAL 修饰符，这样在查询的过程中将会执行 Merge 的特殊逻辑（例如数据去重，预聚合等）。

但是这种方法在早期版本基本没有人使用，因为在增加 FINAL 之后，我们的查询将会变成一个单线程的执行过程，查询速度非常慢。在 v20527-stable 版本中，FINAL 查询支持多线程执行，并且可以通过 max_final_threads 参数控制单个查询的线程数。但是目前读取 part 部分的动作依然是串行的。

FINAL 查询最终的性能和很多因素相关，列字段的大小、分区的数量等等都会影响到最终的查询时间，所以还要结合实际场景取舍。final 只能在部分表引擎中使用。

语法

可以通过查看以上语法的执行计划，会发现使用 final 关键字后，在分区的的数据查询时，会是单线程执行，即使设置了线程数为2

数据库一致性检查(dbcc)提供了一些命令用于检查数据库的逻辑和物理一致性。Dbcc主要有两个功能：

使用checkstorage 或 checktable 及 checkdb 在页一级和行一级检查页链及数据指针。

使用checkstorage, checkalloc, 或 checkverify, tablealloc, 及indexalloc

检查页分配。

在下列情况中需要使用 dbcc 命令： 作为数据库日常维护工作的一部分, 数据库内部结构的完整性决定于sa 或dbo 定期地运行

dbcc 检查。 在系统报错以后, 确定数据库是否有损坏。 在备份数据库之前, 确保备份的完整性。 如果怀疑数据库有损坏时, 例如,

使用某个表时报出表损坏的信息, 可以使用 dbcc 确定数据库中其他表是否也有损坏。

下面是dbcc的简单用法： dbcc checktable (table_name) 检查指定的表,

检查索引和数据页是否正确链接, 索引是否正确排序, 所有指针是否一致, 每页的数据信息是否合理, 页偏移是否合理。 dbcc

checkdb (database_name) 对指定数据库的所有表做和checktable 一样的检查。 dbcc

checkalloc (database_name,fix|nofix) 检查指定数据库, 是否所有页面被正确分配,

是否被分配的页面没被使用。当使用"fix"选项时，在检查数据库的同时会自动修复有问题的页面。（若数据库数据量很大，则该过程会持续很长时间。）

dbcc tablealloc (table_name,fix|nofix) 检查指定的表, 是否所有页面被正确分配,

是否被分配的页面没被使用。是 checkalloc 的缩小版本,

对指定的表做完整性检查。当使用"fix"选项时，在检查数据表的同时会自动修复数据表中有问题的页面。

关于上述命令的其它选项及详细使用方法和checkstorage, checkverify, indexalloc

的详细使用方法, 请参阅有关命令手册。 举例1： Unix平台检查pubs2数据库的一致性 单用户模式启动Server：

$SYBASE/install startserver -f RUN_server_name -m

vi dbcc_dbsqluse mastergosp_dboption pubs2,"single user",truegouse pubs2gocheckpoint go dbcc checkdb(pubs2)godbcc checkalloc(pubs2,fix)godbcc checkcatalog(pubs2)gouse mastergosp_dboption pubs2,"single user",falsegouse pubs2gocheckpointgoquit go isql -Usa -Pxxxxxx -SSYBASE dbcc_dbout

grep Msg dbcc_dbout

举例2： Unix平台检查pubs2数据库中titles表的一致性

定义：数据库一致性（Database Consistency）是指事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。

数据库状态如何变化？每一次数据变更就会导致数据库的状态迁移。如果数据库的初始状态是C0，第一次事务T1的提交就会导致系统生成一个SYSTEM CHANGE NUMBER（SCN），这是数据库状态从C0转变成C1。执行第二个事务T2的时候数据库状态从T1变成T2，以此类推，执行第Tn次事务的时候数据库状态由C(n-1)变成Cn。

定义一致性主要有2个方面，一致读和一致写。

一致写：事务执行的数据变更只能基于上一个一致的状态，且只能体现在一个状态中。T(n)的变更结果只能基于C(n-1)，C(n-2), C(1)状态，且只能体现在C(n)状态中。也就是说，一个状态只能有一个事务变更数据，不允许有2个或者2个以上事务在一个状态中变更数据。至于具体一致写基于哪个状态，需要判断T(n)事务是否和T(n-1)，T(n-2),T(1)有依赖关系。

一致读：事务读取数据只能从一个状态中读取，不能从2个或者2个以上状态读取。也就是T(n)只能从C(n-1），C(n-2) C(1)中的一个状态读取数据，不能一部分数据读取自C(n-1)，而另一部分数据读取自C(n-2)。

摆事实

一致写：

定义100个事务T(1)T(100)实现相同的逻辑 update table set i=i+1，i的初始值是0，那么并发执行这100个事务之后i的值是多少？可能很容易想到是100。那么怎么从一致性角度去理解呢？

数据库随机调度到T(50)执行，此时数据库状态是C(0)，而其它事务都和T(50)有依赖关系，根据写一致性原理，其它事务必须等到T(50)执行完毕后数据库状态变为C(1)才可以执行。因此数据库利用锁机制阻塞其它事务的执行。直到T(50)执行完毕，数据库状态从C(0)迁移到C(1)。数据库唤醒其它事务后随机调度到T(89)执行，以此类推直到所有事务调度执行完毕，数据库状态最终变为C(100)。

一致读：

还是上面的例子，假设T(1)T(100)顺序执行，在不同的时机执行select i from table，我们看到i的值是什么？

1 T(1)的执行过程中。数据库状态尚未迁移，读到的i=0

2 T(1)执行完毕，T(2)的执行过程中，数据库状态迁移至C(1)，读到的i=1

关于生产服务器与备份服务器的数据一致性，绝大程度取决于灾备软件的技术原理。如果是定时备份类的软件，从生产机切换到备份机的话，数据不一致的可能性较大，如果在备份间隔内，生产机没有产生新的数据，那两边的数据就应该是一致的。如果是实时备份类的软件，从生产机切换到备份机的话，数据可以保证一致性，考虑到网络传输速度也会影响备份数据，一般会选择人工方式复验。就像备特佳CDP容灾备份软件，是实时备份的，在做灾备切换或者说业务接管时，为了保证数据的一致性，也有手动接管和自动接管的区别。手动接管就是需要人工复验下备份机的数据后启用接管功能，从生产机切换到备份机。自动接管可以设置时间，最快可以在生产机故障一分钟内自动切换到备份机。

这个问题的有趣之处，不在于问题本身（“原子性、一致性的实现机制是什么”），而在于回答者的分歧反映出来的另外一个问题：原子性和一致性之间的关系是什么？

我特别关注了@我练功发自真心

的答案，他正确地指出了，为了保证事务操作的原子性，必须实现基于日志的REDO/UNDO机制。但这个答案仍然是不完整的，因为原子性并不能够完全保证一致性。

按照我个人的理解，在事务处理的ACID属性中，一致性是最基本的属性，其它的三个属性都为了保证一致性而存在的。

首先回顾一下一致性的定义。所谓一致性，指的是数据处于一种有意义的状态，这种状态是语义上的而不是语法上的。最常见的例子是转帐。例如从帐户A转一笔钱到帐户B上，如果帐户A上的钱减少了，而帐户B上的钱却没有增加，那么我们认为此时数据处于不一致的状态。

在

数据库实现的场景中，一致性可以分为数据库外部的一致性和数据库内部的一致性。前者由外部应用的编码来保证，即某个应用在执行转帐的数据库操作时，必须在

同一个事务内部调用对帐户A和帐户B的操作。如果在这个层次出现错误，这不是数据库本身能够解决的，也不属于我们需要讨论的范围。后者由数据库来保证，即

在同一个事务内部的一组操作必须全部执行成功（或者全部失败）。这就是事务处理的原子性。

为了实现原子性，需要通过日志：将所有对

数据的更新操作都写入日志，如果一个事务中的一部分操作已经成功，但以后的操作，由于断电/系统崩溃/其它的软硬件错误而无法继续，则通过回溯日志，将已

经执行成功的操作撤销，从而达到“全部操作失败”的目的。最常见的场景是，数据库系统崩溃后重启，此时数据库处于不一致的状态，必须先执行一个crash

recovery的过程：读取日志进行REDO（重演将所有已经执行成功但尚未写入到磁盘的操作，保证持久性），再对所有到崩溃时尚未成功提交的事务进行

UNDO（撤销所有执行了一部分但尚未提交的操作，保证原子性）。crash

recovery结束后，数据库恢复到一致性状态，可以继续被使用。

日志的管理和重演是数据库实现中最复杂的部分之一。如果涉及到并行处理和分布式系统（日志的复制和重演是数据库高可用性的基础），会比上述场景还要复杂得多。

但是，原子性并不能完全保证一致性。在多个事务并行进行的情况下，即使保证了每一个事务的原子性，仍然可能导致数据不一致的结果。例如，事务1需要将100元转入帐号A：先读取帐号A的值，然后在这个值上加上100。但是，在这两个操作之间，另一个事务2修改了帐号A的值，为它增加了100元。那么最后的结果应该是A增加了200元。但事实上，

事务1最终完成后，帐号A只增加了100元，因为事务2的修改结果被事务1覆盖掉了。

为了保证并发情况下的一致性，引入了隔离性，即保证每一个事务能够看到的数据总是一致的，就好象其它并发事务并不存在一样。用术语来说，就是多个事务并发执行后的状态，和它们串行执行后的状态是等价的。怎样实现隔离性，已经有很多人回答过了，原则上无非是两种类型的锁：

一

种是悲观锁，即当前事务将所有涉及操作的对象加锁，操作完成后释放给其它对象使用。为了尽可能提高性能，发明了各种粒度（数据库级/表级/行级……）/各

种性质（共享锁/排他锁/共享意向锁/排他意向锁/共享排他意向锁……）的锁。为了解决死锁问题，又发明了两阶段锁协议/死锁检测等一系列的技术。

一种是乐观锁，即不同的事务可以同时看到同一对象（一般是数据行）的不同历史版本。如果有两个事务同时修改了同一数据行，那么在较晚的事务提交时进行冲突

检测。实现也有两种，一种是通过日志UNDO的方式来获取数据行的历史版本，一种是简单地在内存中保存同一数据行的多个历史版本，通过时间戳来区分。

锁也是数据库实现中最复杂的部分之一。同样，如果涉及到分布式系统（分布式锁和两阶段提交是分布式事务的基础），会比上述场景还要复杂得多。

@

我练功发自真心

提到，其他回答者说的其实是操作系统对atomic的理解，即并发控制。我不能完全同意这一点。数据库有自己的并发控制和锁问题，虽然在原理上和操作系统

中的概念非常类似，但是并不是同一个层次上的东西。数据库中的锁，在粒度/类型/实现方式上和操作系统中的锁都完全不同。操作系统中的锁，在数据库实现中

称为latch（一般译为闩）。其他回答者回答的其实是“在并行事务处理的情况下怎样保证数据的一致性”。

最后回到原来的问题（“原子性、一致性的实现机制是什么”）。我手头有本Database

System

Concepts（4ed，有点老了），在第15章的开头简明地介绍了ACID的概念及其关系。如果你想从概念上了解其实现，把这本书的相关章节读完应该能大概明白。如果你想从实践上了解其实现，可以找innodb这样的开源引擎的源代码来读。不过，即使是一个非常粗糙的开源实现（不考虑太复杂的并行处理，不考虑分布式系统，不考虑针对操作系统和硬件的优化之类），要基本搞明白恐怕也不是一两年的事。

以上就是关于ClickHouse 21.7.3.14-2(十一) 数据一致性全部的内容，包括:ClickHouse 21.7.3.14-2(十一) 数据一致性、如何检查数据库中数据的一致性、如何理解数据库的内部一致性和外部一致性等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！