Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
OpenDocCN
ddia
提交
0381c15a
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 搜索 >>
提交
0381c15a
编写于
3月 30, 2018
作者:
J
jiajia.debug
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
minor change to improve translation of part-i and ch1
上级
b12f63ed
变更
2
隐藏空白更改
内联
并排
Showing
2 changed file
with
18 addition
and
18 deletion
+18
-18
ch1.md
ch1.md
+15
-15
part-i.md
part-i.md
+3
-3
未找到文件。
ch1.md
浏览文件 @
0381c15a
...
...
@@ -2,7 +2,7 @@
![](
img/ch1.png
)
> 互联网做得太棒了,以至于多数人将它看作像
海洋这样的天然资源,而不是什么人工产物。上一次出现这种大规模且无差错的技术, 你还记得是什么时候吗?
> 互联网做得太棒了,以至于多数人将它看作像
太平洋这样的自然资源,而不是什么人工产物。上一次出现这种大规模且无差错的技术, 你还记得是什么时候吗?
>
> ——阿兰·凯在接受Dobb博士杂志采访时说(2012年)
...
...
@@ -32,11 +32,11 @@
***批处理(batch processing)**
*
定期
压缩
累积的大批量数据
定期
处理
累积的大批量数据
如果这些功能听上去平淡无奇,那是因为这些
**数据系统(data system)**
是非常成功的抽象,
我们一直不假思索地使用它们并习以为常。绝大多数工程师不会想从零开始编写存储引擎,因为在开发应用时,数据库已经是足够完美的工具了。
上述组件如果听上去显而易见,那是因为这些
**数据系统(data system)**
是非常成功的抽象:
我们一直不假思索地使用它们并习以为常。绝大多数工程师不会想从零开始编写存储引擎,因为在开发应用时,数据库已经是足够完美的工具了。
但
事实并没有这么简单。不同的应用有着不同的需求,所以数据库系统也是百花齐放,有着各式各样的特性。我们有很多种手段可以实现缓存,也有好几种方法可以搞定搜索索引,诸如此类。因此在开发应用前,我们有必要先弄清楚最适合手头工作的工具和方法。而且当单个工具解决不了你的问题时,你会发现组合使用这些工具还
是挺有难度的。
但
现实并没有这么简单。不同的应用有着不同的需求,因而数据库系统也是百花齐放,有着各式各样的特性。实现缓存有很多种手段,创建搜索索引也有好几种方法,诸如此类。因此在开发应用前,我们依然有必要先弄清楚最适合手头工作的工具和方法。而且当单个工具解决不了你的问题时,你会意识到组合使用这些工具
是挺有难度的。
本书将是一趟关于数据系统原理、实践与应用的旅程,并讲述了设计数据密集型应用的方法。我们将探索不同工具之间的共性与特性,以及各自的实现原理。
...
...
@@ -141,7 +141,7 @@
尽管人类不可靠,但怎么做才能让系统变得可靠?最好的系统会组合使用以下几种办法:
*
以最小化犯错机会的方式设计系统。例如,精心设计的抽象、API和管理后台使做对事情更容易,搞砸事情更困难。但如果接口限制太多,人们就会
否定它们的好处而想办法绕开。这是一个很难正确把握的棘手
平衡。
*
以最小化犯错机会的方式设计系统。例如,精心设计的抽象、API和管理后台使做对事情更容易,搞砸事情更困难。但如果接口限制太多,人们就会
忽略它们的好处而想办法绕开。很难正确把握这种微妙的
平衡。
*
将人们最容易犯错的地方与可能导致失效的地方
**解耦(decouple)**
。特别是提供一个功能齐全的非生产环境
**沙箱(sandbox)**
,使人们可以在不影响真实用户的情况下,使用真实数据安全地探索和实验。
*
在各个层次进行彻底的测试【3】,从单元测试、全系统集成测试到手动测试。自动化测试易于理解,已经被广泛使用,特别适合用来覆盖正常情况中少见的
**边缘场景(corner case)**
。
*
允许从人为错误中简单快速地恢复,以最大限度地减少失效情况带来的影响。 例如,快速回滚配置变更,分批发布新代码(以便任何意外错误只影响一小部分用户),并提供数据重算工具(以备旧的计算出错)。
...
...
@@ -150,7 +150,7 @@
### 可靠性有多重要?
可靠性不仅仅是针对核电站和空中交通管制软件而言,我们也期望
许
多平凡的应用能可靠地运行。商务应用中的错误会导致生产力损失(也许数据报告不完整还会有法律风险),而电商网站的中断则可能会导致收入和声誉的巨大损失。
可靠性不仅仅是针对核电站和空中交通管制软件而言,我们也期望
更
多平凡的应用能可靠地运行。商务应用中的错误会导致生产力损失(也许数据报告不完整还会有法律风险),而电商网站的中断则可能会导致收入和声誉的巨大损失。
即使在“非关键”应用中,我们也对用户负有责任。试想一位家长把所有的照片和孩子的视频储存在你的照片应用里【15】。如果数据库突然损坏,他们会感觉如何?他们可能会知道如何从备份恢复吗?
...
...
@@ -166,7 +166,7 @@
### 描述负载
讨论增长问题(如果负载加倍会发生什么?)前,首先要能简要描述系统的当前负载。负载可以用一些称为
**负载参数(load parameters)**
的数字来描述。参数的最佳选择取决于系统架构,它可能是每秒向Web服务器发出的请求、数据库中的读写比率、聊天室中同时活跃的用户数量、缓存命中率或其他东西。除此之外,也许平均情况对你很重要,也许你的瓶颈是少数极端场景。
在
讨论增长问题(如果负载加倍会发生什么?)前,首先要能简要描述系统的当前负载。负载可以用一些称为
**负载参数(load parameters)**
的数字来描述。参数的最佳选择取决于系统架构,它可能是每秒向Web服务器发出的请求、数据库中的读写比率、聊天室中同时活跃的用户数量、缓存命中率或其他东西。除此之外,也许平均情况对你很重要,也许你的瓶颈是少数极端场景。
为了使这个概念更加具体,我们以推特在2012年11月发布的数据【16】为例。推特的两个主要业务是:
...
...
@@ -207,29 +207,29 @@
然而方法2的缺点是,发推现在需要大量的额外工作。平均来说,一条推文会发往约75个关注者,所以每秒4.6k的发推写入,变成了对主页时间线缓存每秒345k的写入。但这个平均值隐藏了用户粉丝数差异巨大这一现实,一些用户有超过3000万的粉丝,这意味着一条推文就可能会导致主页时间线缓存的3000万次写入!及时完成这种操作是一个巨大的挑战——推特尝试在5秒内向粉丝发送推文。
在推特的例子中,每个用户粉丝数的分布(可能按这些用户的发推频率来加权)是
讨论可扩展性的关键负载参数,因为它决定了扇出负载。你的应用程序可能具有非常不同的特征,但可以使用相似的原则来考虑你
的负载。
在推特的例子中,每个用户粉丝数的分布(可能按这些用户的发推频率来加权)是
探讨可扩展性的一个关键负载参数,因为它决定了扇出负载。你的应用程序可能具有非常不同的特征,但可以采用相似的原则来考虑它
的负载。
推特轶事的最终转折:现在
方法2已经稳健地实现了,但推特又转向了两种方法的混合。大多数用户发推时仍然是扇出写入粉丝的主页时间线缓存中。但是少数拥有海量粉丝的用户(即名流)被排除在外。当用户读取主页时间线时,来自所关注名流的推文都会单独拉取,并与用户的主页时间线缓存合并,如方法1所示。这种混合方法能始终如一地提供良好性能。在
[
第12章
](
ch12.md
)
中将重新讨论这个例子,那时我们已经覆盖了更多的技术层面
。
推特轶事的最终转折:现在
已经稳健地实现了方法2,推特逐步转向了两种方法的混合。大多数用户发的推文会被扇出写入其粉丝主页时间线缓存中。但是少数拥有海量粉丝的用户(即名流)会被排除在外。当用户读取主页时间线时,分别地获取出该用户所关注的每位名流的推文,再与用户的主页时间线缓存合并,如方法1所示。这种混合方法能始终如一地提供良好性能。在
[
第12章
](
ch12.md
)
中我们将重新讨论这个例子,这在覆盖更多技术层面之后
。
### 描述性能
一旦系统的负载
可以被描述
,就可以研究当负载增加会发生什么。我们可以从两种角度来看:
一旦系统的负载
被描述好
,就可以研究当负载增加会发生什么。我们可以从两种角度来看:
*
增加负载参数并保持系统资源(CPU、内存、网络带宽等)不变时,系统性能将
有
什么影响?
*
增加负载参数并保持系统资源(CPU、内存、网络带宽等)不变时,系统性能将
受到
什么影响?
*
增加负载参数并希望保持性能不变时,需要增加多少系统资源?
这两个问题都需要性能数据,所以让我们简单地看一下如何描述系统性能。
对于Hadoop这样的批处理系统,通常关心的是
**吞吐量(throughput)**
,即每秒可以处理的记录数量,或者在特定规模数据集上运行作业的总时间[^iii]。对于在线系统,通常更重要的是服务的
**响应时间(response time)**
,即客户端发送请求
和
接收响应之间的时间。
对于Hadoop这样的批处理系统,通常关心的是
**吞吐量(throughput)**
,即每秒可以处理的记录数量,或者在特定规模数据集上运行作业的总时间[^iii]。对于在线系统,通常更重要的是服务的
**响应时间(response time)**
,即客户端发送请求
到
接收响应之间的时间。
[
^iii
]:
理想情况下,批量作业的运行时间是数据集的大小除以吞吐量。
在实践中由于数据倾斜(数据不是均匀分布在每个工作进程中),需要等待最慢的任务完成,所以运行时间往往更长。
> #### 延迟和响应时间
>
> **延迟(latency)**和**响应时间(response time)**通常
当成同义词
用,但实际上它们并不一样。响应时间是客户所看到的,除了实际处理请求的时间(**服务时间(service time)**)之外,还包括网络延迟和排队延迟。延迟是某个请求等待处理的**持续时长**,在此期间它处于**休眠(latent)**状态,并等待服务【17】。
> **延迟(latency)**和**响应时间(response time)**通常
互当成同义词来使
用,但实际上它们并不一样。响应时间是客户所看到的,除了实际处理请求的时间(**服务时间(service time)**)之外,还包括网络延迟和排队延迟。延迟是某个请求等待处理的**持续时长**,在此期间它处于**休眠(latent)**状态,并等待服务【17】。
>
即使不断重复发送同样的请求,每次得到的响应时间也都会略有不同。现实世界的系统会处理各式各样的请求,响应时间可能会有很大差异。因此我们需要将响应时间视为一个可以测量的
**分布(distribution)**
,而不是单个数值。
即使不断重复发送同样的请求,每次得到的响应时间也都会略有不同。现实世界的系统会处理各式各样的请求,响应时间可能会有很大差异。因此我们需要将响应时间视为一个可以测量的
数值
**分布(distribution)**
,而不是单个数值。
在
[
图1-4
](
img/fig1-4.png
)
中,每个灰条表代表一次对服务的请求,其高度表示请求花费了多长时间。大多数请求是相当快的,但偶尔会出现需要更长的时间的异常值。这也许是因为缓慢的请求实质上开销更大,例如它们可能会处理更多的数据。但即使(你认为)所有请求都花费相同时间的情况下,随机的附加延迟也会导致结果变化,例如:上下文切换到后台进程,网络数据包丢失与TCP重传,垃圾收集暂停,强制从磁盘读取的页面错误,服务器机架中的震动【18】,还有很多其他原因。
...
...
@@ -245,7 +245,7 @@
为了弄清异常值有多糟糕,可以看看更高的百分位点,例如第95、99和99.9百分位点(缩写为p95,p99和p999)。它们意味着95%,99%或99.9%的请求响应时间要比该阈值快,例如:如果第95百分位点响应时间是1.5秒,则意味着100个请求中的95个响应时间快于1.5秒,而100个请求中的5个响应时间超过1.5秒。如
[
图1-4
](
img/fig1-4.png
)
所示。
响应时间的高百分位点(也称为
**尾部延迟(tail
percentil
)**
)非常重要,因为它们直接影响用户的服务体验。例如亚马逊在描述内部服务的响应时间要求时以99.9百分位点为准,即使它只影响一千个请求中的一个。这是因为请求响应最慢的客户往往也是数据最多的客户,也可以说是最有价值的客户——因为他们掏钱了【19】。保证网站响应迅速对于保持客户的满意度非常重要,亚马逊观察到:响应时间增加100毫秒,销售量就减少1%【20】;而另一些报告说:慢1秒钟会让客户满意度指标减少16%【21,22】。
响应时间的高百分位点(也称为
**尾部延迟(tail
latencies
)**
)非常重要,因为它们直接影响用户的服务体验。例如亚马逊在描述内部服务的响应时间要求时以99.9百分位点为准,即使它只影响一千个请求中的一个。这是因为请求响应最慢的客户往往也是数据最多的客户,也可以说是最有价值的客户——因为他们掏钱了【19】。保证网站响应迅速对于保持客户的满意度非常重要,亚马逊观察到:响应时间增加100毫秒,销售量就减少1%【20】;而另一些报告说:慢1秒钟会让客户满意度指标减少16%【21,22】。
另一方面,优化第99.99百分位点(一万个请求中最慢的一个)被认为太昂贵了,不能为亚马逊的目标带来足够好处。减小高百分位点处的响应时间相当困难,因为它很容易受到随机事件的影响,这超出了控制范围,而且效益也很小。
...
...
part-i.md
浏览文件 @
0381c15a
...
...
@@ -4,10 +4,10 @@
1.
[
第一章
](
ch1.md
)
将介绍本书使用的术语和方法。
**可靠性,可扩展性和可维护性**
,这些词汇到底意味着什么?如何实现这些目标?
2.
[
第二章
](
ch2.md
)
将对几种不同的
**数据模型和查询语言**
进行比较。从程序员的角度看,这是数据库之间最明显的区别。不同的数据模型适用于不同的应用场景。
3.
[
第三章
](
ch3.md
)
将深
**存储引擎**
内部,并
研究数据库如何在磁盘上摆放数据。不同的存储引擎针对不同的负载进行优化,选择合适的存储引擎对系统性能有巨大影响。
4.
[
第四章
](
ch4
)
将对几种不同的
**数据编码**
进行比较。特别
讨论了在应用需求经常变化、模式需要随时间演化的环境中,这些格式的适用
情况。
3.
[
第三章
](
ch3.md
)
将深
入
**存储引擎**
内部,
研究数据库如何在磁盘上摆放数据。不同的存储引擎针对不同的负载进行优化,选择合适的存储引擎对系统性能有巨大影响。
4.
[
第四章
](
ch4
)
将对几种不同的
**数据编码**
进行比较。特别
地分析了他们在应用需求经常变化、模式需要随着时间演变的环境中的表现
情况。
第二部分将专门讨论在
**分布式数据系统**
中
才
有的问题。
第二部分将专门讨论在
**分布式数据系统**
中
特
有的问题。
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录