From 6eb3ecd346b2272ee8ec139bfc1df699fcf9464e Mon Sep 17 00:00:00 2001 From: Guo Qi Date: Tue, 8 Oct 2019 16:38:33 +0800 Subject: [PATCH 1/3] =?UTF-8?q?ch4:=20=E4=BF=AE=E6=AD=A3=E7=BF=BB=E8=AF=91?= =?UTF-8?q?,=20=E4=BB=B7=E5=80=BC->=E5=80=BC?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ch4.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch4.md b/ch4.md index 80fc7a9..79d573a 100644 --- a/ch4.md +++ b/ch4.md @@ -350,7 +350,7 @@ Avro为静态类型编程语言提供了可选的代码生成功能，但是它 #### 在不同的时间写入不同的值 -数据库通常允许任何时候更新任何值。这意味着在一个单一的数据库中，可能有一些价值是五毫秒前写的，而一些价值是五年前写的。 +数据库通常允许任何时候更新任何值。这意味着在一个单一的数据库中，可能有一些值是五毫秒前写的，而一些值是五年前写的。 在部署应用程序的新版本（至少是服务器端应用程序）时，您可能会在几分钟内完全用新版本替换旧版本。数据库内容也是如此：五年前的数据仍然存在于原始编码中，除非您已经明确地重写了它。这种观察有时被总结为数据超出代码。 From e233177ade5debd474b0fd8fff4773000be77920 Mon Sep 17 00:00:00 2001 From: Guo Qi Date: Tue, 8 Oct 2019 17:03:52 +0800 Subject: [PATCH 2/3] =?UTF-8?q?ch3:=20=E4=BF=AE=E6=94=B9=E4=BA=86=E4=B8=80?= =?UTF-8?q?=E4=B8=AASSD=E7=9B=B8=E5=85=B3=E7=9A=84=E7=BF=BB=E8=AF=91?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ch3.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch3.md b/ch3.md index 880a2e2..d121dda 100644 --- a/ch3.md +++ b/ch3.md @@ -273,7 +273,7 @@ B树的基本底层写操作是用新数据覆盖磁盘上的页面。假定覆 B树索引必须至少两次写入每一段数据：一次写入预先写入日志，一次写入树页面本身（也许再次分页）。即使在该页面中只有几个字节发生了变化，也需要一次编写整个页面的开销。有些存储引擎甚至会覆盖同一个页面两次，以免在电源故障的情况下导致页面部分更新【24,25】。 -由于反复压缩和合并SSTables，日志结构索引也会重写数据。这种影响 —— 在数据库的生命周期中写入数据库导致对磁盘的多次写入 —— 被称为**写放大（write amplification）**。需要特别关注的是固态硬盘，固态硬盘在磨损之前只能覆写一段时间。 +由于反复压缩和合并SSTables，日志结构索引也会重写数据。这种影响 —— 在数据库的生命周期中写入数据库导致对磁盘的多次写入 —— 被称为**写放大（write amplification）**。需要特别注意的是固态硬盘，固态硬盘的闪存寿命在覆写有限次数后就会耗尽。 在写入繁重的应用程序中，性能瓶颈可能是数据库可以写入磁盘的速度。在这种情况下，写放大会导致直接的性能代价：存储引擎写入磁盘的次数越多，可用磁盘带宽内的每秒写入次数越少。 From 352e8ba839307092dee8d0a734fbd8e7138a11bb Mon Sep 17 00:00:00 2001 From: Guo Qi Date: Tue, 8 Oct 2019 19:29:31 +0800 Subject: [PATCH 3/3] =?UTF-8?q?ch5:=20typo,=20=E8=85=9A->=E8=AE=A2?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ch5.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch5.md b/ch5.md index 31c1ac8..0c5013e 100644 --- a/ch5.md +++ b/ch5.md @@ -433,7 +433,7 @@ ​ 有些冲突是显而易见的。在[图5-7](img/fig5-7.png)的例子中，两个写操作并发地修改了同一条记录中的同一个字段，并将其设置为两个不同的值。毫无疑问这是一个冲突。 -​ 其他类型的冲突可能更为微妙，难以发现。例如，考虑一个会议室预订系统：它记录谁腚了哪个时间段的哪个房间。应用需要确保每个房间只有一组人同时预定（即不得有相同房间的重叠预订）。在这种情况下，如果同时为同一个房间创建两个不同的预订，则可能会发生冲突。即使应用程序在允许用户进行预订之前检查可用性，如果两次预订是由两个不同的领导者进行的，则可能会有冲突。 +​ 其他类型的冲突可能更为微妙，难以发现。例如，考虑一个会议室预订系统：它记录谁订了哪个时间段的哪个房间。应用需要确保每个房间只有一组人同时预定（即不得有相同房间的重叠预订）。在这种情况下，如果同时为同一个房间创建两个不同的预订，则可能会发生冲突。即使应用程序在允许用户进行预订之前检查可用性，如果两次预订是由两个不同的领导者进行的，则可能会有冲突。 ​ 现在还没有一个现成的答案，但在接下来的章节中，我们将追溯到对这个问题有很好的理解。我们将在第7章中看到更多的冲突示例，在[第12章](ch12.md)中我们将讨论用于检测和解决复制系统中冲突的可扩展方法。