Skip to content

Commit

Permalink
remove the leading TAB character in almost all paragraphs, suggested by
Browse files Browse the repository at this point in the history
  • Loading branch information
yingang committed Nov 22, 2021
1 parent b7769f6 commit f403404
Show file tree
Hide file tree
Showing 26 changed files with 3,108 additions and 3,106 deletions.
186 changes: 93 additions & 93 deletions ch1.md

Large diffs are not rendered by default.

436 changes: 218 additions & 218 deletions ch10.md

Large diffs are not rendered by default.

448 changes: 224 additions & 224 deletions ch11.md

Large diffs are not rendered by default.

598 changes: 299 additions & 299 deletions ch12.md

Large diffs are not rendered by default.

2 changes: 1 addition & 1 deletion ch3.md
Original file line number Diff line number Diff line change
Expand Up @@ -110,7 +110,7 @@ $ cat database

***文件格式***

CSV不是日志的最佳格式。使用二进制格式更快,更简单,首先以字节为单位对字符串的长度进行编码,然后使用原始字符串(不需要转义)。
CSV不是日志的最佳格式。使用二进制格式更快,更简单,首先以字节为单位对字符串的长度进行编码,然后使用原始字符串(不需要转义)。

***删除记录***

Expand Down
4 changes: 2 additions & 2 deletions ch4.md
Original file line number Diff line number Diff line change
Expand Up @@ -26,11 +26,11 @@

***向后兼容 (backward compatibility)***

新代码可以读旧数据。
新代码可以读旧数据。

***向前兼容 (forward compatibility)***

旧代码可以读新数据。
旧代码可以读新数据。

向后兼容性通常并不难实现:新代码的作者当然知道由旧代码使用的数据格式,因此可以显示地处理它(最简单的办法是,保留旧代码即可读取旧数据)。

Expand Down
356 changes: 178 additions & 178 deletions ch5.md

Large diffs are not rendered by default.

182 changes: 91 additions & 91 deletions ch6.md

Large diffs are not rendered by default.

50 changes: 25 additions & 25 deletions ch7.md

Large diffs are not rendered by default.

320 changes: 160 additions & 160 deletions ch8.md

Large diffs are not rendered by default.

509 changes: 255 additions & 254 deletions ch9.md

Large diffs are not rendered by default.

12 changes: 6 additions & 6 deletions en-us/ch7.md
Original file line number Diff line number Diff line change
Expand Up @@ -53,27 +53,27 @@ In this chapter, we went particularly deep into the topic of concurrency control

***Dirty reads***

One client reads another client’s writes before they have been committed. The read committed isolation level and stronger levels prevent dirty reads.
One client reads another client’s writes before they have been committed. The read committed isolation level and stronger levels prevent dirty reads.

***Dirty writes***

One client overwrites data that another client has written, but not yet committed. Almost all transaction implementations prevent dirty writes.
One client overwrites data that another client has written, but not yet committed. Almost all transaction implementations prevent dirty writes.

***Read skew (nonrepeatable reads)***

A client sees different parts of the database at different points in time. This issue is most commonly prevented with snapshot isolation, which allows a transaction to read from a consistent snapshot at one point in time. It is usually implemented with *multi-version concurrency control* (MVCC).
A client sees different parts of the database at different points in time. This issue is most commonly prevented with snapshot isolation, which allows a transaction to read from a consistent snapshot at one point in time. It is usually implemented with *multi-version concurrency control* (MVCC).

***Lost updates***

Two clients concurrently perform a read-modify-write cycle. One overwrites the other’s write without incorporating its changes, so data is lost. Some implemen‐ tations of snapshot isolation prevent this anomaly automatically, while others require a manual lock (SELECT FOR UPDATE).
Two clients concurrently perform a read-modify-write cycle. One overwrites the other’s write without incorporating its changes, so data is lost. Some implemen‐ tations of snapshot isolation prevent this anomaly automatically, while others require a manual lock (SELECT FOR UPDATE).

***Write skew***

A transaction reads something, makes a decision based on the value it saw, and writes the decision to the database. However, by the time the write is made, the premise of the decision is no longer true. Only serializable isolation prevents this anomaly.
A transaction reads something, makes a decision based on the value it saw, and writes the decision to the database. However, by the time the write is made, the premise of the decision is no longer true. Only serializable isolation prevents this anomaly.

***Phantom reads***

A transaction reads objects that match some search condition. Another client makes a write that affects the results of that search. Snapshot isolation prevents straightforward phantom reads, but phantoms in the context of write skew require special treatment, such as index-range locks.
A transaction reads objects that match some search condition. Another client makes a write that affects the results of that search. Snapshot isolation prevents straightforward phantom reads, but phantoms in the context of write skew require special treatment, such as index-range locks.



Expand Down
12 changes: 6 additions & 6 deletions en-us/ch9.md
Original file line number Diff line number Diff line change
Expand Up @@ -41,27 +41,27 @@ We saw that achieving consensus means deciding something in such a way that all

***Linearizable compare-and-set registers***

The register needs to atomically *decide* whether to set its value, based on whether its current value equals the parameter given in the operation.
The register needs to atomically *decide* whether to set its value, based on whether its current value equals the parameter given in the operation.

***Atomic transaction commit***

A database must *decide* whether to commit or abort a distributed transaction.
A database must *decide* whether to commit or abort a distributed transaction.

***Total order broadcast***

The messaging system must *decide* on the order in which to deliver messages.
The messaging system must *decide* on the order in which to deliver messages.

***Locks and leases***

When several clients are racing to grab a lock or lease, the lock *decides* which one successfully acquired it.
When several clients are racing to grab a lock or lease, the lock *decides* which one successfully acquired it.

***Membership/coordination service***

Given a failure detector (e.g., timeouts), the system must *decide* which nodes are alive, and which should be considered dead because their sessions timed out.
Given a failure detector (e.g., timeouts), the system must *decide* which nodes are alive, and which should be considered dead because their sessions timed out.

***Uniqueness constraint***

When several transactions concurrently try to create conflicting records with the same key, the constraint must *decide* which one to allow and which should fail with a constraint violation.
When several transactions concurrently try to create conflicting records with the same key, the constraint must *decide* which one to allow and which should fail with a constraint violation.



Expand Down
4 changes: 2 additions & 2 deletions part-ii.md
Original file line number Diff line number Diff line change
Expand Up @@ -53,11 +53,11 @@

***复制(Replication)***

在几个不同的节点上保存数据的相同副本,可能放在不同的位置。 复制提供了冗余:如果一些节点不可用,剩余的节点仍然可以提供数据服务。 复制也有助于改善性能。 [第五章](ch5.md)将讨论复制。
在几个不同的节点上保存数据的相同副本,可能放在不同的位置。 复制提供了冗余:如果一些节点不可用,剩余的节点仍然可以提供数据服务。 复制也有助于改善性能。 [第五章](ch5.md)将讨论复制。

***分区 (Partitioning)***

将一个大型数据库拆分成较小的子集(称为**分区(partitions)**),从而不同的分区可以指派给不同的**节点(node)**(亦称**分片(shard)**)。 [第六章](ch6.md)将讨论分区。
将一个大型数据库拆分成较小的子集(称为**分区(partitions)**),从而不同的分区可以指派给不同的**节点(node)**(亦称**分片(shard)**)。 [第六章](ch6.md)将讨论分区。

复制和分区是不同的机制,但它们经常同时使用。如[图II-1](img/figii-1.png)所示。

Expand Down
Loading

0 comments on commit f403404

Please sign in to comment.