提交 a6df7e9f 编写于 作者: V Vonng

各部分卷首语精翻

上级 84aace63
......@@ -49,6 +49,8 @@
## [目录](ddia/README.md)
#### [序言](ddia/preface.md)
#### [I. 数据系统基础](ddia/part-i.md)
1. [可靠性、可扩展性、可维护性](ddia/ch1.md)
......@@ -87,26 +89,26 @@
精翻可以看,机翻基本没法看,初翻对于业内人士能凑合看。
| 章节 | 进度 | Credit |
| :--------------------------------: | :----------: | --------------------------------------------------------- |
| 序言 | 机翻 | 序言初翻 by [seagullbird](https://github.com/seagullbird) |
| 第一部分:数据系统基础 ——概览 | 初翻 | |
| 第一章:可靠性、可扩展性、可维护性 | **精翻** | |
| 第二章:数据模型与查询语言 | 初翻 | |
| 第三章:存储与检索 | 初翻 | |
| 第四章:编码与演化 | 初翻 | |
| 第二部分:分布式数据——概览 | 初翻 | |
| 第五章:复制 | 初翻 | |
| 第六章:分片 | 初翻 | |
| 第七章:事务 | **精翻 80%** | |
| 第八章:分布式系统中的问题 | **初翻** | |
| 第九章:一致性与共识 | 机翻 | 进行中,初翻30% |
| 第三部分:前言 | 机翻 | |
| 第十章:批处理 | 机翻 | |
| 第十一章:流处理 | 机翻 | |
| 第十二章:数据系统的未来 | 机翻 | |
| 术语表 | - | |
| 后记 | 机翻 | |
| 章节 | 进度 |
| :--------------------------------: | :------: |
| 序言 | 初翻 |
| 第一部分:数据系统基础 ——概览 | **精翻** |
| 第一章:可靠性、可扩展性、可维护性 | **精翻** |
| 第二章:数据模型与查询语言 | 初翻 |
| 第三章:存储与检索 | 初翻 |
| 第四章:编码与演化 | 初翻 |
| 第二部分:分布式数据——概览 | 精翻 |
| 第五章:复制 | 初翻 |
| 第六章:分片 | 初翻 |
| 第七章:事务 | 初翻 |
| 第八章:分布式系统中的问题 | 初翻 |
| 第九章:一致性与共识 | 机翻 |
| 第三部分:前言 | **精翻** |
| 第十章:批处理 | 机翻 |
| 第十一章:流处理 | 机翻 |
| 第十二章:数据系统的未来 | 机翻 |
| 术语表 | - |
| 后记 | 机翻 |
最近比较忙,精翻计划可能会延后,但初翻会尽量先过一遍。早期的几章初翻质量很一般,后续会重新过一遍。
......
......@@ -53,7 +53,7 @@
8. [分布式系统的麻烦](ch8.md)
9. [一致性与共识](ch9.md)
### [生数据](part-iii.md)
### [生数据](part-iii.md)
10. [批处理](ch10.md)
11. [流处理](ch11.md)
......@@ -80,19 +80,19 @@
| 章节 | 文件 | 进度 |
| ------ | ------ | ---- |
| 序言 | [preface.md](preface.md) | 翻 |
| 第一部分:数据系统基础 ——概览 | [part-i.md](part-i.md) | 翻 |
| 第一章:可靠性、可扩展性、可维护性 | [ch1.md](ch1.md) | **精翻** |
| 序言 | [preface.md](preface.md) | 翻 |
| 第一部分:数据系统基础 ——概览 | [part-i.md](part-i.md) | 翻 |
| 第一章:可靠性、可扩展性、可维护性 | [ch1.md](ch1.md) | 精翻 |
| 第二章:数据模型与查询语言 | [ch2.md](ch2.md) | 初翻 |
| 第三章:存储与检索 | [ch3.md](ch3.md) | 初翻 |
| 第四章:编码与演化 | [ch4.md](ch4.md) | 初翻 |
| 第二部分:分布式数据——概览 | [part-ii.md](part-ii.md) | 翻 |
| 第二部分:分布式数据——概览 | [part-ii.md](part-ii.md) | 翻 |
| 第五章:复制 | [ch5.md](ch5.md) | 初翻 |
| 第六章:分片 | [ch6.md](ch6.md) | 初翻 |
| 第七章:事务 | [ch7.md](ch7.md) | **精翻 80%** |
| 第七章:事务 | [ch7.md](ch7.md) | 初翻 |
| 第八章:分布式系统的麻烦 | [ch8.md](ch8.md) | 初翻 |
| 第九章:一致性与共识 | [ch9.md](ch9.md) | 机翻 |
| 第三部分:前言 | [part-iii.md](part-iii.md) | 翻 |
| 第九章:一致性与共识 | [ch9.md](ch9.md) | 初翻 30% |
| 第三部分:前言 | [part-iii.md](part-iii.md) | 翻 |
| 第十章:批处理 | [ch10.md](ch10.md) | 机翻 |
| 第十一章:流处理 | [ch11.md](ch11.md) | 机翻 |
| 第十二章:数据系统的未来 | [ch12.md](ch12.md) | 机翻 |
......
......@@ -1026,7 +1026,7 @@ MapReduce经常写入磁盘,这使得从单个失败的任务中轻松地恢
------
| 上一章 | 目录 | 下一章 |
| ---------------------------- | ------------------------------- | ------------------------ |
| [九章:一致与共识](ch9.md) | [设计数据密集型应用](README.md) | [第十章:流处理](ch7.md) |
| 上一章 | 目录 | 下一章 |
| --------------------------------- | ------------------------------- | ------------------------ |
| [三部分:派生数据](part-iii.md) | [设计数据密集型应用](README.md) | [第十章:流处理](ch7.md) |
此差异已折叠。
此差异已折叠。
......@@ -2,10 +2,10 @@
本书前四章介绍了数据系统底层的基础概念,无论是在单台机器上运行的单点数据系统,还是分布在多台机器上的分布式数据系统都适用。
1. [第一章](ch1.md)将介绍本书使用的术语和方法。**可靠性,可扩展性和可维护性** ,这些词汇到底意味着什么?以及如何实现这些目标。
1. [第一章](ch1.md)将介绍本书使用的术语和方法。**可靠性,可扩展性和可维护性** ,这些词汇到底意味着什么?如何实现这些目标?
2. [第二章](ch2.md)将对几种不同的**数据模型和查询语言**进行比较。从程序员的角度看,这是数据库之间最明显的区别。不同的数据模型适用于不同的应用场景。
3. [第三章](ch3.md)将深**存储引擎**内部,并研究数据库如何在磁盘上摆放数据。不同的存储引擎针对不同的负载进行优化,选择合适的存储引擎对系统性能有巨大影响。
4. [第四章](ch4)将对几种不同的 **数据编码(序列化)**进行比较。特别讨论了在应用需求经常变化、模式需要随时间调整的环境中这些格式的适用情况。
4. [第四章](ch4)将对几种不同的 **数据编码**进行比较。特别讨论了在应用需求经常变化、模式需要随时间演化的环境中,这些格式的适用情况。
第二部分将专门讨论在**分布式数据系统**中才有的问题。
......@@ -20,3 +20,10 @@
4. [编码与演化](ch4.md)
------
| 上一章 | 目录 | 下一章 |
| ------------------ | ------------------------------- | -------------------------------------------- |
| [序言](preface.md) | [设计数据密集型应用](README.md) | [第一章:可靠性、可扩展性、可维护性](ch1.md) |
\ No newline at end of file
# 第二部分: 分布式数据
> 一个成功的技术,可行性的优先级必须高于PR,你可以糊弄别人,但糊弄不了自然规律。
> 一个成功的技术,现实的优先级必须高于公关,你可以糊弄别人,但糊弄不了自然规律。
>
> ——罗杰斯委员会报告(1986)
>
-------
在本书的第一部分中,我们讨论了数据存储在一台机器上数据系统的方方面面。现在到了第二部分中,我们提一个更高级的问题:如果**多台机器**参与数据的存储和检索会发生什么?
将数据库分布到多台机器上可能会有很多原因:
在本书的[第一部分](part-i.md)中,我们讨论了数据系统的各个方面,但仅限于数据存储在单台机器上的情况。现在我们到了[第二部分](part-ii.md),进入更高的层次,并提出一个问题:如果**多台机器**参与数据的存储和检索,会发生什么?
你可能会出于各种各样的原因,希望将数据库分布到多台机器上:
***可扩展性***
如果您的数据量读取负载/写入负载比单台计算机可以处理的还要大,则可以将负载分散到多台计算机上。
如果你的数据量、读取负载、写入负载超出单台机器的处理能力,可以将负载分散到多台计算机上。
***容错/高可用性***
如果即使一台机器(或多台机器,网络或整个数据中心)出现故障,您的应用程序仍然需要继续工作,您可以使用多台机器来提供冗余。当一台故障时,另一台可以接管。
如果你的应用需要在单台机器(或多台机器,网络或整个数据中心)出现故障的情况下仍然能继续工作,则可使用多台机器,以提供冗余。一台故障时,另一台可以接管。
***延迟***
如果在世界各地都有用户,也许你会考虑在全球多处部署服务器,既而每个用户从地理上相近的数据中心获取服务,以免用户需要等待网络数据包穿越半个世界。
如果在世界各地都有用户,你也许会考虑在全球范围部署多个服务器,从而每个用户可以从地理上最近的数据中心获取服务,避免了等待网络数据包穿越半个世界。
### 扩展至更高的载荷
### 扩展到更高的负载
如果你需要的只是扩展至更高的**载荷(load)**,最简单的方法就是购买更强大的机器(有时称为**垂直扩展(vertical scaling)****向上扩展(scale up)**)。许多处理器,内存和磁盘可以在同一个操作系统下相互连接,快速的相互连接允许任意处理器访问内存或磁盘的任意部分。在这种**共享内存架构(shared-memory architecture)**中,所有的组件都可以看作一台单独的机器。
如果只是需要扩展到支持更高的负载,最简单的方法就是购买更强大的机器(有时称为垂直扩展 vertical scaling或scaling up)。许多CPU、RAM芯片和磁盘可以在一个操作系统内相互连接,快速互连允许任何CPU访问存储器或磁盘的任何部分。在这种共享内存架构中,所有的组件都可以看作是一台单独的机器(在大型机中,尽管任何CPU都可以访问内存的任何部分,但是总有一些内存区域与一些CPU更接近[^i]。 为了有效地利用这种架构特性,需要对处理进行细分,以便每个CPU主要访问临近的内存,这意味着底层仍然进行了分区,即使表面上看起来只有一台机器在运行)
[^i]: 在大型机中,尽管任意处理器都可以访问内存的任意部分,但总有一些内存区域与一些处理器更接近(称为**非均匀内存访问(nonuniform memory access, NUMA)**【1】)。 为了有效利用这种架构特性,需要对处理进行细分,以便每个处理器主要访问临近的内存,这意味着即使表面上看起来只有一台机器在运行,**分区(partitioning)**仍然是必要的。
[^i]: 称为非均匀内存访问 nonuniform memory access,或者NUMA
共享内存方法的问题在于,成本增长速度快于线性增长:一台有着双倍处理器数量,双倍内存大小,双倍磁盘容量的机器,通常成本会远远超过原来的两倍。而且可能因为存在瓶颈,并不足以处理双倍的载荷。
共享内存方法的问题在于,开销的增长速度快于线性增长:一台机器的CPU数量翻倍,内存大小也翻倍,磁盘大小翻倍,但成本通常多的可不止一倍。而且由于瓶颈存在,一台双倍规格机器不一定能处理双倍的负载
共享内存架构可以提供有限的容错能力,高端机器可以使用热插拔的组件(不关机更换磁盘,内存模块,甚至处理器)——但它必然囿于单个地理位置的桎梏
共享内存体系结构可以提供有限的容错能力,相比之下,使用高端机器虽然具有热插拔组件(可以不关机更换磁盘,内存模块,甚至CPU),但是它必然局限于单个地理位置
另一种方法是**共享磁盘架构(shared-disk architecture)**,它使用多台具有独立处理器和内存的机器,但将数据存储在机器之间共享的磁盘阵列上,这些磁盘通过快速网络连接[^ii]。这种架构用于某些数据仓库,但竞争和锁定的开销限制了共享磁盘方法的可扩展性【2】
另一种方法是**共享磁盘架构**,它使用多台具有独立CPU和RAM的机器,但将数据存储在机器之间共享的磁盘阵列上,这些磁盘通过快速网络连接(Network Attached Storage, Storage Area Network)。此架构用于某些数据仓储,但竞争和锁定的开销限制了共享磁盘方法的可扩展性[2]。
[^ii]: 网络附属存储(Network Attached Storage, NAS),或**存储区网络(Storage Area Network, SAN)**
#### 无共享架构
相比之下,**无共享架构**(shared-nothing 有时称为水平扩展 horizontal scaling 或 scaling out)已经相当普及。在这种架构中,运行数据库软件的每台机器/虚拟机都称为节点(node)。每个节点只使用各自的CPU,内存和磁盘。节点之间的任何协调都是在软件层面使用传统网络实现的。
相比之下,**无共享架构(shared-nothing architecture)**(有时称为**水平扩展(horizontal scale)****向外扩展(scale out)**)已经相当普及。在这种架构中,运行数据库软件的每台机器/虚拟机都称为**节点(node)**。每个节点只使用各自的处理器,内存和磁盘。节点之间的任何协调,都是在软件层面使用传统网络实现的。
无共享系统不需要特殊的硬件,所以你可以用任何性价比最好的机器。也许可以跨多个地理区域分发数据从而减少用户延迟,也许可以在整个数据中心丢失的情况下幸免于难。随着云端虚拟机部署的出现,即使是小公司,现在无需Google级别的运维,也可以实现多地分布式架构。
无共享系统不需要使用特殊的硬件,所以你可以用任意机器——比如性价比最好的机器。你也许可以跨多个地理区域分布数据从而减少用户延迟,或者在损失一整个数据中心的情况下幸免于难。随着云端虚拟机部署的出现,即使是小公司,现在无需Google级别的运维,也可以实现异地分布式架构。
在这一部分里,我们将重点放在无共享架构上,并不是因为它们一定是每个用例的最佳选择,而是因为它们要求应用程序开发人员最为谨慎。如果你的数据分布在多个节点上,你需要意识到这样一个分布式系统中约束和权衡 ——数据库并不能神奇地把这些东西藏起来。
在这一部分里,我们将重点放在无共享架构上。它不见得是所有场景的最佳选择,但它是最需要你谨慎从事的架构。如果你的数据分布在多个节点上,你需要意识到这样一个分布式系统中约束和权衡 ——数据库并不能魔术般地把这些东西隐藏起来。
虽然分布式无共享架构具有许多优点,但它通常也会给应用程序带来额外的复杂性,有时也会限制您可以使用的数据模型表现力。在某些情况下,一个简单的单线程程序可以比一个拥有100多个CPU核心的集群表现得更好[4]。另一方面,无共享系统可以非常强大。接下来的几章将详细讨论分布式数据的问题。
虽然分布式无共享架构有许多优点,但它通常也会给应用带来额外的复杂度,有时也会限制你可用数据模型的表达力。在某些情况下,一个简单的单线程程序可以比一个拥有超过100个CPU核的集群表现得更好【4】。另一方面,无共享系统可以非常强大。接下来的几章,将详细讨论分布式数据会带来的问题。
### 复制 vs 分区
数据分布在多个节点上有两种常见的方式:
- 复制(Replication)
在几个不同的节点上保存相同数据的副本,可能位于不同的位置。 复制提供了冗余:如果某些节点不可用,则仍然可以从其余节点提供数据。 复制也可以帮助提高性能。
***复制(Replication)***
[第五章](ch5.md)将讨论复制。
​ 在几个不同的节点上保存数据的相同副本,可能放在不同的位置。 复制提供了冗余:如果一些节点不可用,剩余的节点仍然可以提供数据服务。 复制也有助于改善性能。 [第五章](ch5.md)将讨论复制。
- 分区 (Partitioning)
***分区 (Partitioning)***
将大型数据库拆分成称为分区的较小子集,以便不同的分区可以指派:给不同的节点(也称为分片 sharding)。
​ 将一个大型数据库拆分成较小的子集(称为**分区(partitions)**),从而不同的分区可以指派给不同的**节点(node)**(亦称**分片(shard)**)。 [第六章](ch6.md)将讨论分区。
[第六章](ch6.md)将讨论分区。
复制和分区是不同的机制,但它们经常同时使用。如图II-1所示。
复制和分区是不同的机制,但它们经常同时使用。如[图II-1](img/figii-1.png)所示。
![](img/figii-1.png)
**图II-1 复制与分区**
**图II-1 一个数据库切分为两个分区,每个分区都有两个副本**
理解了这些概念,就可以开始讨论在分布式系统中需要做出的困难抉择。[第七章](ch7.md)将讨论**事务(Transaction)**,这对于了解数据系统中可能出现的各种问题,以及我们可以做些什么很有帮助。[第八章](ch8.md)[第九章](ch9.md)将讨论分布式系统的根本局限性。
理解了这些概念,就可以开始讨论在分布式系统中需要做出的困难抉择。
[第七章](ch7.md)将讨论**事务(Transaction)**,这对了解数据系统中可能出现的所有问题以及可以做些什么很有帮助。
[第八章](ch8.md)[第九章](ch9.md)将讨论分布式系统的基本局限性
在本书的第三部分中,将讨论如何将多个(可能分布的)数据存储集成到一个更大的系统中,以满足复杂应用程序的需求。 但首先我们来谈谈分布式的数据。
在本书的[第三部分](part-iii.md)中,将讨论如何将多个(可能是分布式的)数据存储集成为一个更大的系统,以满足复杂的应用需求。 但首先,我们来聊聊分布式的数据。
......@@ -84,4 +77,24 @@
6. [分片](ch6.md)
7. [事务](ch7.md)
8. [分布式系统的麻烦](ch8.md)
9. [一致性与共识](ch9.md)
\ No newline at end of file
9. [一致性与共识](ch9.md)
## 参考文献
1. Ulrich Drepper: “[What Every Programmer Should Know About Memory](http://www.benstopford.com/2009/11/24/understanding-the-shared-nothing-architecture/),” akka‐dia.org, November 21, 2007.
2. Ben Stopford: “[Shared Nothing vs. Shared Disk Architectures: An Independent View](http://www.benstopford.com/2009/11/24/understanding-the-shared-nothing-architecture/),” benstopford.com, November 24, 2009.
3. Michael Stonebraker: “[The Case for Shared Nothing](http://db.cs.berkeley.edu/papers/hpts85-nothing.pdf),” IEEE Database EngineeringBulletin, volume 9, number 1, pages 4–9, March 1986.
4. Frank McSherry, Michael Isard, and Derek G. Murray: “[Scalability! But at What COST?](http://www.frankmcsherry.org/assets/COST.pdf),” at 15th USENIX Workshop on Hot Topics in Operating Systems (HotOS),May 2015.
------
| 上一章 | 目录 | 下一章 |
| ---------------------------- | ------------------------------- | ---------------------- |
| [第四章:编码与演化](ch4.md) | [设计数据密集型应用](README.md) | [第五章:复制](ch5.md) |
\ No newline at end of file
# 第三部分:衍生数据
本书的第一部分和第二部分,自底向上把所有关于分布式数据库的主要考量都讲了一遍。从数据在磁盘上的布局,一直到故障时关于分布式系统一致性的局限性。但所有的讨论都假定了应用程序中只用了一种数据库。
在本书的[第一部分](part-i.md)[第二部分](part-ii.md)中,我们自底向上地把所有关于分布式数据库的主要考量都过了一遍。从数据在磁盘上的布局,一直到出现故障时分布式系统一致性的局限。但所有的讨论都假定了应用中只用了一种数据库。
现实世界中的数据系统往往更为复杂。大型应用程序经常需要以多种方式访问和处理数据,没有一个数据库可以同时满足所有这些不同的需求。因此应用程序通常组合使用多种组件:数据存储,索引,缓存,分析系统,等等,并实现在这些组件中移动数据的机制。
本书的最后一部分,会研究将多个不同数据系统(可能有着不同数据模型,并针对不同的访问模式进行优化)协调一致地集成入应用架构时会遇到的问题。软件供应商经常会忽略这一方面的系统建设,并声称他们的产品能够满足您的所有需求。在现实世界中,集成不同的系统是实际应用中最重要的事情之一。
本书的最后一部分,会研究将多个不同数据系统(可能有着不同数据模型,并针对不同的访问模式进行优化)集成为一个协调一致的应用架构时,会遇到的问题。软件供应商经常会忽略这一方面的生态建设,并声称他们的产品能够满足你的所有需求。在现实世界中,集成不同的系统是实际应用中最重要的事情之一。
## 记录和派生数据系统
......@@ -12,31 +12,23 @@
#### 记录系统(System of record)
一个关于记录的系统,也被称为*真相源*(source of truth),保留了权威版本的数据。当新的数据进入时(例如,用户输入)首先会在这里记录。每个事实恰好只表示一次(表示通常是标准化的 normalized)。如果另一个系统和记录系统之间有任何差异,那么记录系统中的值是(根据定义)是正确的
**记录系统**,也被称为**真相源(source of truth)**,持有数据的权威版本。当新的数据进入时(例如,用户输入)首先会记录在这里。每个事实正正好好表示一次(表示通常是**标准化的(normalized)**)。如果其他系统和**记录系统**之间存在任何差异,那么记录系统中的值是正确的(根据定义)
#### 衍生数据系统(Derived data systems)
衍生系统中的数据,通常来自另一个系统的现有数据,以某种方式进行转换或处理的结果。如果丢失衍生的数据,您可以从原始来源重新创建它。典型的例子是*缓存*:如果存在,数据可以从缓存中提供;如果缓存不包含所需数据,总是可以降级由底层数据库提供。非规范化的值,索引和物化视图也属于这个类别。在推荐系统中,预测汇总数据通常派生自来用户日志。
**衍生系统**中的数据,通常是另一个系统中的现有数据以某种方式进行转换或处理的结果。如果丢失衍生数据,可以从原始来源重新创建。典型的例子是**缓存(cache)**:如果数据在缓存中,就可以由缓存提供服务;如果缓存不包含所需数据,则降级由底层数据库提供。非规范化的值,索引和物化视图亦属此类。在推荐系统中,预测汇总数据通常衍生自用户日志。
从技术上讲,派生数据是**冗余的(redundant)**,因为它重复了已有的信息。但是衍生数据对于获得良好的读性能通常是至关重要的。它通常是非规范化的。可以从同一个来源派生出多个不同的数据集,使得用户可以从不同的“视角”去洞察数据。
从技术上讲,衍生数据是**冗余的(redundant)**,因为它重复了已有的信息。但是衍生数据对于获得良好的只读查询性能通常是至关重要的。它通常是非规范化的。可以从单个源头衍生出多个不同的数据集,使你能从不同的“视角”洞察数据。
并不是所有的系统都在其架构中明确区分记录系统和派生系统,但是这是一种有用的区分方式,因为它明确了系统中的数据流:系统的哪一部分具有哪些输入和哪些输出,以及它们如何相互依赖。
并不是所有的系统都在其架构中明确区分**记录系统****衍生数据系统**,但是这是一种有用的区分方式,因为它明确了系统中的数据流:系统的哪一部分具有哪些输入和哪些输出,以及它们如何相互依赖。
大多数数据库,存储引擎和查询语言,本质上既不是记录系统也不是派生系统。数据库只是一个工具:如何使用它取决于你。记录系统和衍生数据系统之间的区别不在于工具,而在于应用程序中的使用方式。
大多数数据库,存储引擎和查询语言,本质上既不是记录系统也不是派生系统。数据库只是一个工具:如何使用它取决于你自己。**记录系统和衍生数据系统之间的区别不在于工具,而在于应用程序中的使用方式。**
通过梳理数据的派生关系,可以清楚地理解一个令人困惑的系统架构。这将贯穿本书的这一部分。
通过梳理数据的派生关系,可以清楚地理解一个令人困惑的系统架构。这将贯穿本书的这一部分。
## 章节概述
[第十章](ch10.md)通过研究面向批处理的数据流系统,例如MapReduce,看看它们是如何给我们提供构建大规模数据系统的优秀工具和原理的。
[第十一章](ch11.md)将把这些概念应用到*流式数据*(data streams)中,使同样的任务能以更低的延迟完成。
[第十二章](ch12.md)将对本书进行总结,探讨使用这些工具来构建可靠,可扩展和可维护的应用程序的思路。
我们将从[第十章](ch10.md)开始,研究例如MapReduce这样的**面向批处理(batch-oriented)**的数据流系统。对于建设大规模数据系统,我们将看到,它们提供了优秀的工具和思想。[第十一章](ch11.md)将把这些思想应用到**流式数据(data streams)**中,使我们能用更低的延迟完成同样的任务。[第十二章](ch12.md)将对本书进行总结,探讨如何使用这些工具来构建可靠,可扩展和可维护的应用。
## 索引
......@@ -44,3 +36,9 @@
11. [流处理](ch11.md)
12. [数据系统的未来](ch12.md)
------
| 上一章 | 目录 | 下一章 |
| ------------------------------ | ------------------------------- | ------------------------- |
| [第九章:一致性与共识](ch9.md) | [设计数据密集型应用](README.md) | [第十章:批处理](ch10.md) |
\ No newline at end of file
# 序
如果您近几年从业于软件工程领域,特别是服务器端和后端开发,那么您很可能已经被大量关于数据存储和处理的时髦词汇轰炸过了: NoSQL!大数据!Web-Scale!分片!最终一致性!ACID! CAP定理!云服务!MapReduce!实时!
如果近几年从业于软件工程,特别是服务器端和后端系统开发,那么您很有可能已经被大量关于数据存储和处理的时髦词汇轰炸过了: NoSQL!大数据!Web-Scale!分片!最终一致性!ACID! CAP定理!云服务!MapReduce!实时!
过去的十年中,我们已经看到了数据库,分布式系统以及在其上构建应用程序的方式的许多有趣的发展。这些发展有各种各样的推动力量
最近十年中,我们看到了很多有趣的进展,关于数据库,分布式系统,以及在此基础上构建应用程序的方式。这些进展有着各种各样的驱动力
* 谷歌,雅虎,亚马逊,Facebook,LinkedIn,微软和Twitter等互联网公司正在处理海量的数据和流量,迫使他们创造新的工具,使他们能够有效地处理这种规模
* 企业需要敏捷,低成本地测试假说,通过缩短开发周期和保持数据模型的灵活性,快速响应新的市场洞察。
* 免费且开放源代码的软件已经非常成功,现在在许多环境中更倾向于商业或定制的内部软件
* CPU主频几乎没有增长,但是多核处理器已经成为标配,网络变得更快。这意味着并行化只会增加
* 即使您在一个小团队中工作,现在也可以构建分布在多台计算机甚至多个地理区域的系统,这要归功于基础设施即服务(IaaS)概念的践行者譬如亚马逊网络服务(AWS)等
* 现在,许多服务都要求高可用,因为停电、维护导致的服务不可用变得越来越不可接受。
* 谷歌,雅虎,亚马逊,脸书,领英,微软和推特等互联网公司正在和巨大的流量/数据打交道,这迫使它们创造能有效应对这种规模的新工具
* 企业需要敏捷,廉价地测试假设,通过缩短开发周期和保持数据模型的灵活性,快速响应新的市场洞察。
* 免费和开源软件变得非常成功,在许多环境中比商业软件和定制软件更受欢迎
* 处理器主频几乎没有增长,但是多核处理器已经成为标配,网络也越来越快。这意味着并行程度只增不减
* 即使您在一个小团队中工作,现在也可以构建分布在多台计算机甚至多个地理区域的系统,这要归功于譬如亚马逊网络服务(AWS)等基础设施即服务(IaaS)概念的践行者
* 许多服务都要求高可用,因停电或维护导致的服务不可用,变得越来越难以接受。
数据密集型应用正在通过利用这些技术发展推动可能的边界。如果**数据是其主要挑战**(数据量,数据复杂度或数据变化速度),我们称这类应用为**数据密集型**,与之相对的是**计算密集型**,即CPU周期是瓶颈。
数据密集型应用正在通过利用这些技术进步推动可能性的边界。如果**数据是其主要挑战**(数据量,数据复杂度或数据变化速度),我们称这类应用为**数据密集型**,与之相对的是**计算密集型**,即处理器速度是瓶颈。
帮助数据密集型应用程序存储和处理数据的工具和技术已经迅速适应这些变化。新型数据库系统(“NoSQL”)已经引起了人们的关注,但消息队列,缓存,搜索索引,批处理和流处理框架以及相关技术也非常重要。许多应用程序使用这些技术的组合
帮助数据密集型应用程序存储和处理数据的工具和技术已经迅速适应这些变化。新型数据库系统(“NoSQL”)已经引起了人们的关注,但消息队列,缓存,搜索索引,批处理和流处理框架以及相关技术也非常重要。许多应用程序组合使用这些技术
这些充满整个空间的流行语是对新的可能性的热情的表现,这是一件好事。但是,作为软件工程师和架构师,如果我们想要建立良好的应用程序,我们还需要对各种层出不穷的技术持有准确而严谨的技术性理解,以及它们之间的取舍权衡。为此,我们必须深入挖掘流行语背后的内容。
......@@ -29,7 +29,7 @@
## 本书的目标读者
如果您开发的应用程序具有用于存储或处理数据的某种服务器/后端,并且您的应用程序使用互联网(例如,Web应用程序,移动应用程序或连接到互联网的传感器),那么本书就是为您准备的。
如果您开发的应用程序具有用于存储或处理数据的某种服务器/后端系统,并且您的应用程序使用互联网(例如,Web应用程序,移动应用程序或连接到互联网的传感器),那么本书就是为您准备的。
本书适用于热爱编写代码的软件工程师,软件架构师和技术经理。如果您需要就您所从事的系统架构做出决定,例如您需要选择解决某个特定问题的工具,并找出如何最好地应用这些工具来解决问题,那么这本书对您尤其重要。但即使您不能选择您的工具,这本书仍将帮助您更好地了解您所使用工具的长处和短处。
......@@ -50,7 +50,7 @@
本书不会试图给出详细的指导,说明如何安装或使用特定的软件包或API,因为已经有大量的文档。相反,我们讨论了基本的数据系统的各种原则和权衡,并探讨了不同产品所做出的不同设计决策。
在电子书版本中,我们包含了在线资源全文的链接。所有链接都在发布时进行了验证,但不幸的是,由于网络的性质,链接往往频繁地中断。如果您遇到链接断开的情况,或者您正在阅读本书的打印副本,则可以使用搜索引擎查找引用。对于学术论文,您可以在Google学术搜索中搜索标题以查找开放获取的PDF文件。或者,您可以在https://github.com/ept/ddia-references上找到所有的参考资料,我们在那里维护最新的链接。
在电子书版本中,我们包含了在线资源全文的链接。所有链接都在发布时进行了验证,但不幸的是,由于网络的性质,链接往往频繁地中断。如果您遇到链接断开的情况,或者您正在阅读本书的打印副本,则可以使用搜索引擎查找引用。对于学术论文,您可以在Google学术搜索中搜索标题以查找开放获取的PDF文件。或者,您可以在[DDIA-Reference](https://github.com/ept/ddia-references)上找到所有的参考资料,我们在那里维护最新的链接。
我们主要关注数据系统的体系结构以及它们被集成到数据密集型应用程序中的方式。本书没有讨论部署,操作,安全,管理等领域的空间 —— 这些都是复杂而重要的话题,仅仅在本书中用肤浅的注解讨论它们对它们不公平。它们各自配得上一本单独的书。
......@@ -64,23 +64,24 @@
本书分为三部分:
1.第一部分中,我们讨论支持数据密集型应用程序设计的基本思想。我们从第1章开始,讨论我们实际要达到的目标:可靠性,可伸缩性和可维护性;我们该如何考虑他们;以及我们如何实现它们。在第2章中,我们比较了几种不同的数据模型和查询语言,看看它们是如何适用于不同的情况的。在第3章中,我们讨论存储引擎:数据库如何在磁盘上安排数据,以便我们可以再次有效地找到它。第4章转向数据编码(序列化)的格式和纲要随时间的演变
1.[第一部分](part-i.md)中,我们会讨论设计数据密集型应用所赖的基本思想。我们从[第1章](ch1.md)开始,讨论我们实际要达到的目标:可靠性,可扩展性和可维护性;我们该如何考虑它们;以及如何实现它们。在[第2章](ch2.md)中,我们比较了几种不同的数据模型和查询语言,看看它们是如何适用于不同的场景。在[第3章](ch3.md)中将讨论存储引擎:数据库如何在磁盘上摆放数据,以便能高效地再次找到它。[第4章](ch4.md)转向数据编码(序列化),以及随时间演化的模式
2.第二部分中,我们从讨论存储在一台机器上的数据转向讨论分布在多台机器上的数据。这对于可伸缩性通常是必需的,但带来了各种独特的挑战。我们首先讨论复制(第5章),分区/分片(第6章)和事务(第7章)。我们然后探索关于分布式系统的问题的更多细节(第8章),以及在分布式系统中实现一贯性和一致性意味着什么(第9章)。
2.[第二部分](part-ii.md)中,我们从讨论存储在一台机器上的数据转向讨论分布在多台机器上的数据。这对于可扩展性通常是必需的,但带来了各种独特的挑战。我们首先讨论复制([第5章](ch5.md)),分区/分片([第6章](ch6.md))和事务([第7章](ch7.md))。我们然后探索关于分布式系统的问题的更多细节([第8章](ch8.md)),以及在分布式系统中实现共识和一致性意味着什么([第9章](ch9.md))。
3.第三部分中,我们讨论从其他数据集派生一些数据集的系统。派生数据经常发生在异构系统中:当没有一个数据库可以把所有事都做好时,应用程序需要集成几个不同的数据库,缓存,索引等等。在第10章中我们将从一种批处理派生数据的方法开始,然后我们将在第11章中在此基础上用流处理构建。最后,在第12章中,我们将所有内容放在一起,并讨论未来构建可靠,可伸缩和可维护的应用程序的方法。
3.[第三部分](part-iii.md)中,我们讨论从其他数据集衍生一些数据集的系统。派生数据经常发生在异构系统中:当没有一个数据库可以把所有事都做好时,应用程序需要集成几个不同的数据库,缓存,索引等等。在[第10章](ch10.md)中我们将从一种批处理派生数据的方法开始,然后我们将在第11章中在此基础上用流处理构建。最后,在[第12章](ch12.md)中,我们将所有内容放在一起,并讨论未来构建可靠,可伸缩和可维护的应用程序的方法。
## 参考和进一步阅读
我们在本书中讨论的大部分内容已经在其他地方以某种形式出现了 —— 在会议演示文稿,研究论文,博客文章,代码,错误跟踪器,邮件列表和工程民俗中。这本书总结了来自许多不同来源的最重要的想法,其中包括指向原始文献的指针。 如果您想更深入地探索一个领域,那么每章末尾的参考资料都是很好的资源,其中大部分可以在线免费获取。
## 参考文献与延伸阅读
本书中讨论的大部分内容已经在其它地方以某种形式出现过了 —— 会议演示文稿,研究论文,博客文章,代码,BUG跟踪器,邮件列表,以及工程习惯中。本书总结了不同来源资料中最重要的想法,并在文本中包含了指向原始文献的指针。 如果你想更深入地探索一个领域,那么每章末尾的参考文献都是很好的资源,其中大部分可以免费在线获取。
## O‘Reilly广告
blah blah 不想翻
## O‘Reilly Safari
[Safari](http://oreilly.com/safari)赛高!
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册