Update ch07.md

remove redundant *
This commit is contained in:
muniao 2023-01-08 15:57:23 +08:00 committed by GitHub
parent 157a484ce1
commit 9685c37508
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

10
ch07.md
View File

@ -53,7 +53,7 @@
3. **CAP 定理**。一致性指的是线性一致性,是多副本间一致性的一种特例。
4. **ACID**。数据库在应用程序的视角处于某种”一致性的状态“。
因此,我们使用该术语时,一定要明确其所属上下文,进而明确其含义。具体到 ACID 中,一致性是对某些**不变性invariants**的维持,所谓不变性,即某些约束条件。如,在银行账户中,在任何时刻,账户余额须等于收入减去支出。
因此,我们使用该术语时,一定要明确其所属上下文,进而明确其含义。具体到 ACID 中,一致性是对某些**不变性invariants** 的维持,所谓不变性,即某些约束条件。如,在银行账户中,在任何时刻,账户余额须等于收入减去支出。
不同于 ACID 中其他性质,一致性是需要**应用侧**和**数据库侧**共同维护的:
@ -121,7 +121,7 @@ SELECT COUNT(*) FROM emails WHERE recipient_id = 2 AND unread_flag = true
在多对象事务中,一个关键点是如何确定多个操作是否属于同一事务:
1. 从**物理上来考虑**可以通过 TCP 连接来确定,在同一个连接中,`BEGIN TRANSACTION` 和 `COMMIT`语句之间的所有内容,可以认为属于同一个事务。但会有一些 corner case如在客户端提交请求后服务器确认提交之前网络中断连接断开此时客户端则无从得知事务是否被成功提交。
1. 从**物理上来考虑**可以通过 TCP 连接来确定,在同一个连接中,`BEGIN TRANSACTION` 和 `COMMIT`语句之间的所有内容,可以认为属于同一个事务。但会有一些 corner case如在客户端提交请求后服务器确认提交之前网络中断连接断开此时客户端则无从得知事务是否被成功提交。
2. **从逻辑上来考虑**。使用事务管理器,为每个事务分配一个唯一标识符,从而对操作进行分组。
实际中基本上使用第二种方法。
@ -708,7 +708,7 @@ SSI顾名思义基于快照隔离。即在 SSI 隔离级别中,所有的
2. 决策:考察读到的数据,做出某种决策。
3. 写入:将对应决策造成结果写回数据库。
即,这里面存在一个因果关系,读为因,写为果。如果在提交时,发现决策的**前提***premise*如:“今天有两名医生排到了值班”)不再满足,则后面写入失去意义。因此为了提供可串行化的隔离级别,需要识别这种因果关系,并且能够在提交时检测前提是否失效,以决定是否中止事务。
即,这里面存在一个因果关系,读为因,写为果。如果在提交时,发现决策的**前提***premise*如:“今天有两名医生排到了值班”)不再满足,则后面写入失去意义。因此为了提供可串行化的隔离级别,需要识别这种因果关系,并且能够在提交时检测前提是否失效,以决定是否中止事务。
那如何检测前提是否失效呢?
@ -754,10 +754,10 @@ SSI顾名思义基于快照隔离。即在 SSI 隔离级别中,所有的
1. 如果细粒度跟踪,虽然能精确的检测到真正的冲突,减少重试,但会有显著的记录开销。
2. 如果粗粒度的跟踪,虽然性能会好,但会导致更多的冲突和重试。
在某些情况下,即使一个事务读到的信息被另外一个事务的写入覆盖,仍然能保证可串行化的隔离级别。这取决于事务读到这些信息后,用来做了什么,*PostgreSQL* 便根据这个原则来减少不必要的重试**
在某些情况下,即使一个事务读到的信息被另外一个事务的写入覆盖,仍然能保证可串行化的隔离级别。这取决于事务读到这些信息后,用来做了什么,*PostgreSQL* 便根据这个原则来减少不必要的重试。
和 2PL 相比SSI 的最大优点是不会通过锁来阻塞有依赖关系的事务并发执行。SSI 就想运行在快照隔离级别一样,读不阻塞写,写不阻塞读。只是追踪记录,在提交时决定是否提交或重试。这种设计是的查询延迟更可预测。尤其是,只读事务可以工作在一致性快照上,而不受影响,这对读负载很重的场景很有吸引力。
相比物理上的串行化SSI 能够进行平滑扩展。如 FoundationDB 就可以利用多机并行进行冲突检测,从而通过加机器获取很高的吞吐。
事务的中止率会显著影响 SSI 性能。长时间的读写事务大概率会引起冲突,并重试。因此 SSI 要求**读写事务**尽可能的短。尽管如此SSI 仍然比物理串行化以及两阶段锁对慢事务更友好。
事务的中止率会显著影响 SSI 性能。长时间的读写事务大概率会引起冲突,并重试。因此 SSI 要求**读写事务**尽可能的短。尽管如此SSI 仍然比物理串行化以及两阶段锁对慢事务更友好。