Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
OpenDocCN
ddia
提交
6a6ec535
D
ddia
项目概览
OpenDocCN
/
ddia
通知
6
Star
0
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
D
ddia
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
前往新版Gitcode,体验更适合开发者的 AI 搜索 >>
未验证
提交
6a6ec535
编写于
11月 26, 2019
作者:
F
Feng Ruohang
提交者:
GitHub
11月 26, 2019
浏览文件
操作
浏览文件
下载
差异文件
Merge pull request #51 from latavin243/fix_translation
fix 修正ch3 ch4几处翻译
上级
01ec4b9f
352e8ba8
变更
3
隐藏空白更改
内联
并排
Showing
3 changed file
with
3 addition
and
3 deletion
+3
-3
ch3.md
ch3.md
+1
-1
ch4.md
ch4.md
+1
-1
ch5.md
ch5.md
+1
-1
未找到文件。
ch3.md
浏览文件 @
6a6ec535
...
...
@@ -273,7 +273,7 @@ B树的基本底层写操作是用新数据覆盖磁盘上的页面。假定覆
B树索引必须至少两次写入每一段数据:一次写入预先写入日志,一次写入树页面本身(也许再次分页)。即使在该页面中只有几个字节发生了变化,也需要一次编写整个页面的开销。有些存储引擎甚至会覆盖同一个页面两次,以免在电源故障的情况下导致页面部分更新【24,25】。
由于反复压缩和合并SSTables,日志结构索引也会重写数据。这种影响 —— 在数据库的生命周期中写入数据库导致对磁盘的多次写入 —— 被称为
**写放大(write amplification)**
。需要特别
关注的是固态硬盘,固态硬盘在磨损之前只能覆写一段时间
。
由于反复压缩和合并SSTables,日志结构索引也会重写数据。这种影响 —— 在数据库的生命周期中写入数据库导致对磁盘的多次写入 —— 被称为
**写放大(write amplification)**
。需要特别
注意的是固态硬盘,固态硬盘的闪存寿命在覆写有限次数后就会耗尽
。
在写入繁重的应用程序中,性能瓶颈可能是数据库可以写入磁盘的速度。在这种情况下,写放大会导致直接的性能代价:存储引擎写入磁盘的次数越多,可用磁盘带宽内的每秒写入次数越少。
...
...
ch4.md
浏览文件 @
6a6ec535
...
...
@@ -350,7 +350,7 @@ Avro为静态类型编程语言提供了可选的代码生成功能,但是它
#### 在不同的时间写入不同的值
数据库通常允许任何时候更新任何值。这意味着在一个单一的数据库中,可能有一些
价值是五毫秒前写的,而一些价
值是五年前写的。
数据库通常允许任何时候更新任何值。这意味着在一个单一的数据库中,可能有一些
值是五毫秒前写的,而一些
值是五年前写的。
在部署应用程序的新版本(至少是服务器端应用程序)时,您可能会在几分钟内完全用新版本替换旧版本。数据库内容也是如此:五年前的数据仍然存在于原始编码中,除非您已经明确地重写了它。这种观察有时被总结为数据超出代码。
...
...
ch5.md
浏览文件 @
6a6ec535
...
...
@@ -433,7 +433,7 @@
有些冲突是显而易见的。在
[
图5-7
](
img/fig5-7.png
)
的例子中,两个写操作并发地修改了同一条记录中的同一个字段,并将其设置为两个不同的值。毫无疑问这是一个冲突。
其他类型的冲突可能更为微妙,难以发现。例如,考虑一个会议室预订系统:它记录谁
腚
了哪个时间段的哪个房间。应用需要确保每个房间只有一组人同时预定(即不得有相同房间的重叠预订)。在这种情况下,如果同时为同一个房间创建两个不同的预订,则可能会发生冲突。即使应用程序在允许用户进行预订之前检查可用性,如果两次预订是由两个不同的领导者进行的,则可能会有冲突。
其他类型的冲突可能更为微妙,难以发现。例如,考虑一个会议室预订系统:它记录谁
订
了哪个时间段的哪个房间。应用需要确保每个房间只有一组人同时预定(即不得有相同房间的重叠预订)。在这种情况下,如果同时为同一个房间创建两个不同的预订,则可能会发生冲突。即使应用程序在允许用户进行预订之前检查可用性,如果两次预订是由两个不同的领导者进行的,则可能会有冲突。
现在还没有一个现成的答案,但在接下来的章节中,我们将追溯到对这个问题有很好的理解。我们将在第7章中看到更多的冲突示例,在
[
第12章
](
ch12.md
)
中我们将讨论用于检测和解决复制系统中冲突的可扩展方法。
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录