fix cross links in v1 content
Some checks are pending
Deploy Hugo site to Pages / build (push) Waiting to run
Deploy Hugo site to Pages / deploy (push) Blocked by required conditions

This commit is contained in:
Gang Yin 2025-08-12 16:49:45 +08:00
parent 8efd0b7f46
commit 8099734ef3
15 changed files with 35 additions and 35 deletions

View File

@ -52,16 +52,16 @@ PostgreSQL 专家,数据库老司机,云计算泥石流。
## 目录 ## 目录
### [序言](/preface) ### [序言](/v1/preface)
### [第一部分:数据系统基础](/part-i) ### [第一部分:数据系统基础](/v1/part-i)
* [第一章:可靠性、可伸缩性和可维护性](/v1/ch1) * [第一章:可靠性、可伸缩性和可维护性](/v1/ch1)
* [第二章:数据模型与查询语言](/v1/ch2) * [第二章:数据模型与查询语言](/v1/ch2)
* [第三章:存储与检索](/v1/ch3) * [第三章:存储与检索](/v1/ch3)
* [第四章:编码与演化](/v1/ch4) * [第四章:编码与演化](/v1/ch4)
### [第二部分:分布式数据](/part-ii) ### [第二部分:分布式数据](/v1/part-ii)
* [第五章:复制](/v1/ch5) * [第五章:复制](/v1/ch5)
* [第六章:分区](/v1/ch6) * [第六章:分区](/v1/ch6)
@ -69,15 +69,15 @@ PostgreSQL 专家,数据库老司机,云计算泥石流。
* [第八章:分布式系统的麻烦](/v1/ch8) * [第八章:分布式系统的麻烦](/v1/ch8)
* [第九章:一致性与共识](/v1/ch9) * [第九章:一致性与共识](/v1/ch9)
### [第三部分:衍生数据](/part-iii) ### [第三部分:衍生数据](/v1/part-iii)
* [第十章:批处理](/v1/ch10) * [第十章:批处理](/v1/ch10)
* [第十一章:流处理](/v1/ch11) * [第十一章:流处理](/v1/ch11)
* [第十二章:数据系统的未来](/v1/ch12) * [第十二章:数据系统的未来](/v1/ch12)
### [术语表](/glossary) ### [术语表](/v1/glossary)
### [后记](/colophon) ### [后记](/v1/colophon)
<br> <br>

View File

@ -359,7 +359,7 @@ breadcrumbs: false
不幸的是,使应用可靠、可伸缩或可维护并不容易。但是某些模式和技术会不断重新出现在不同的应用中。在接下来的几章中,我们将看到一些数据系统的例子,并分析它们如何实现这些目标。 不幸的是,使应用可靠、可伸缩或可维护并不容易。但是某些模式和技术会不断重新出现在不同的应用中。在接下来的几章中,我们将看到一些数据系统的例子,并分析它们如何实现这些目标。
在本书后面的 [第三部分](/part-iii) 中,我们将看到一种模式:几个组件协同工作以构成一个完整的系统(如 [图 1-1](/v1/ddia_0101.png) 中的例子) 在本书后面的 [第三部分](/v1/part-iii) 中,我们将看到一种模式:几个组件协同工作以构成一个完整的系统(如 [图 1-1](/v1/ddia_0101.png) 中的例子)
## 参考文献 ## 参考文献

View File

@ -201,7 +201,7 @@ MapReduce 有点像 Unix 工具,但分布在数千台机器上。像 Unix 工
[^iv]: 一个不同之处在于,对于 HDFS可以将计算任务安排在存储特定文件副本的计算机上运行而对象存储通常将存储和计算分开。如果网络带宽是一个瓶颈从本地磁盘读取有性能优势。但是请注意如果使用纠删码Erasure Coding则会丢失局部性因为来自多台机器的数据必须进行合并以重建原始文件【20】。 [^iv]: 一个不同之处在于,对于 HDFS可以将计算任务安排在存储特定文件副本的计算机上运行而对象存储通常将存储和计算分开。如果网络带宽是一个瓶颈从本地磁盘读取有性能优势。但是请注意如果使用纠删码Erasure Coding则会丢失局部性因为来自多台机器的数据必须进行合并以重建原始文件【20】。
与网络连接存储NAS和存储区域网络SAN架构的共享磁盘方法相比HDFS 基于 **无共享** 原则(请参阅 [第二部分](/part-ii) 的介绍)。共享磁盘存储由集中式存储设备实现,通常使用定制硬件和专用网络基础设施(如光纤通道)。而另一方面,无共享方法不需要特殊的硬件,只需要通过传统数据中心网络连接的计算机。 与网络连接存储NAS和存储区域网络SAN架构的共享磁盘方法相比HDFS 基于 **无共享** 原则(请参阅 [第二部分](/v1/part-ii) 的介绍)。共享磁盘存储由集中式存储设备实现,通常使用定制硬件和专用网络基础设施(如光纤通道)。而另一方面,无共享方法不需要特殊的硬件,只需要通过传统数据中心网络连接的计算机。
HDFS 在每台机器上运行了一个守护进程,它对外暴露网络服务,允许其他节点访问存储在该机器上的文件(假设数据中心中的每台通用计算机都挂载着一些磁盘)。名为 **NameNode** 的中央服务器会跟踪哪个文件块存储在哪台机器上。因此HDFS 在概念上创建了一个大型文件系统,可以使用所有运行有守护进程的机器的磁盘。 HDFS 在每台机器上运行了一个守护进程,它对外暴露网络服务,允许其他节点访问存储在该机器上的文件(假设数据中心中的每台通用计算机都挂载着一些磁盘)。名为 **NameNode** 的中央服务器会跟踪哪个文件块存储在哪台机器上。因此HDFS 在概念上创建了一个大型文件系统,可以使用所有运行有守护进程的机器的磁盘。

View File

@ -254,7 +254,7 @@ Apache Kafka 【17,18】、Amazon Kinesis Streams 【19】和 Twitter 的 Distri
#### 变更数据捕获的实现 #### 变更数据捕获的实现
我们可以将日志消费者叫做 **衍生数据系统**,正如在 [第三部分](/part-iii) 的介绍中所讨论的:存储在搜索索引和数据仓库中的数据,只是 **记录系统** 数据的额外视图。变更数据捕获是一种机制,可确保对记录系统所做的所有更改都反映在衍生数据系统中,以便衍生系统具有数据的准确副本。 我们可以将日志消费者叫做 **衍生数据系统**,正如在 [第三部分](/v1/part-iii) 的介绍中所讨论的:存储在搜索索引和数据仓库中的数据,只是 **记录系统** 数据的额外视图。变更数据捕获是一种机制,可确保对记录系统所做的所有更改都反映在衍生数据系统中,以便衍生系统具有数据的准确副本。
从本质上说,变更数据捕获使得一个数据库成为领导者(被捕获变化的数据库),并将其他组件变为追随者。基于日志的消息代理非常适合从源数据库传输变更事件,因为它保留了消息的顺序(避免了 [图 11-2](/v1/ddia_1102.png) 的重新排序问题)。 从本质上说,变更数据捕获使得一个数据库成为领导者(被捕获变化的数据库),并将其他组件变为追随者。基于日志的消息代理非常适合从源数据库传输变更事件,因为它保留了消息的顺序(避免了 [图 11-2](/v1/ddia_1102.png) 的重新排序问题)。

View File

@ -147,7 +147,7 @@ JSON 表示比 [图 2-1](/v1/ddia_0201.png) 中的多表模式具有更好的 **
[^ii]: 关于关系模型的文献区分了几种不同的规范形式,但这些区别几乎没有实际意义。一个经验法则是,如果重复存储了可以存储在一个地方的值,则模式就不是 **规范化normalized** 的。 [^ii]: 关于关系模型的文献区分了几种不同的规范形式,但这些区别几乎没有实际意义。一个经验法则是,如果重复存储了可以存储在一个地方的值,则模式就不是 **规范化normalized** 的。
> 数据库管理员和开发人员喜欢争论规范化和非规范化,让我们暂时保留判断吧。在本书的 [第三部分](/part-iii),我们将回到这个话题,探讨系统的方法用以处理缓存,非规范化和衍生数据。 > 数据库管理员和开发人员喜欢争论规范化和非规范化,让我们暂时保留判断吧。在本书的 [第三部分](/v1/part-iii),我们将回到这个话题,探讨系统的方法用以处理缓存,非规范化和衍生数据。
不幸的是,对这些数据进行规范化需要多对一的关系(许多人生活在一个特定的地区,许多人在一个特定的行业工作),这与文档模型不太吻合。在关系数据库中,通过 ID 来引用其他表中的行是正常的,因为连接很容易。在文档数据库中,一对多树结构没有必要用连接,对连接的支持通常很弱 [^iii]。 不幸的是,对这些数据进行规范化需要多对一的关系(许多人生活在一个特定的地区,许多人在一个特定的行业工作),这与文档模型不太吻合。在关系数据库中,通过 ID 来引用其他表中的行是正常的,因为连接很容易。在文档数据库中,一对多树结构没有必要用连接,对连接的支持通常很弱 [^iii]。

View File

@ -13,7 +13,7 @@ math: true
> —— 道格拉斯・亚当斯1992 > —— 道格拉斯・亚当斯1992
复制意味着在通过网络连接的多台机器上保留相同数据的副本。正如在 [第二部分](/part-ii) 的介绍中所讨论的那样,我们希望能复制数据,可能出于各种各样的原因: 复制意味着在通过网络连接的多台机器上保留相同数据的副本。正如在 [第二部分](/v1/part-ii) 的介绍中所讨论的那样,我们希望能复制数据,可能出于各种各样的原因:
* 使得数据与用户在地理上接近(从而减少延迟) * 使得数据与用户在地理上接近(从而减少延迟)
* 即使系统的一部分出现故障,系统也能继续工作(从而提高可用性) * 即使系统的一部分出现故障,系统也能继续工作(从而提高可用性)
@ -189,7 +189,7 @@ math: true
## 复制延迟问题 ## 复制延迟问题
容忍节点故障只是需要复制的一个原因。正如在 [第二部分](/part-ii) 的介绍中提到的,其它原因还包括可伸缩性(处理比单个机器更多的请求)和延迟(让副本在地理位置上更接近用户)。 容忍节点故障只是需要复制的一个原因。正如在 [第二部分](/v1/part-ii) 的介绍中提到的,其它原因还包括可伸缩性(处理比单个机器更多的请求)和延迟(让副本在地理位置上更接近用户)。
基于领导者的复制要求所有写入都由单个节点处理但只读查询可以由任何一个副本来处理。所以对于读多写少的场景Web 上的常见模式),一个有吸引力的选择是创建很多从库,并将读请求分散到所有的从库上去。这样能减小主库的负载,并允许由附近的副本来处理读请求。 基于领导者的复制要求所有写入都由单个节点处理但只读查询可以由任何一个副本来处理。所以对于读多写少的场景Web 上的常见模式),一个有吸引力的选择是创建很多从库,并将读请求分散到所有的从库上去。这样能减小主库的负载,并允许由附近的副本来处理读请求。
@ -288,7 +288,7 @@ math: true
如果应用程序开发人员不必担心微妙的复制问题,并可以信赖他们的数据库 “做了正确的事情”,那该多好呀。这就是 **事务transaction** 存在的原因:**数据库通过事务提供强大的保证**,所以应用程序可以更加简单。 如果应用程序开发人员不必担心微妙的复制问题,并可以信赖他们的数据库 “做了正确的事情”,那该多好呀。这就是 **事务transaction** 存在的原因:**数据库通过事务提供强大的保证**,所以应用程序可以更加简单。
单节点事务已经存在了很长时间。然而在走向分布式(复制和分区)数据库时,许多系统放弃了事务,声称事务在性能和可用性上的代价太高,并断言在可伸缩系统中最终一致性是不可避免的。这个叙述有一些道理,但过于简单了,本书其余部分将提出更为细致的观点。我们将在 [第七章](/v1/ch7) 和 [第九章](/v1/ch9) 回到事务的话题,并将在 [第三部分](/part-iii) 讨论一些替代机制。 单节点事务已经存在了很长时间。然而在走向分布式(复制和分区)数据库时,许多系统放弃了事务,声称事务在性能和可用性上的代价太高,并断言在可伸缩系统中最终一致性是不可避免的。这个叙述有一些道理,但过于简单了,本书其余部分将提出更为细致的观点。我们将在 [第七章](/v1/ch7) 和 [第九章](/v1/ch9) 回到事务的话题,并将在 [第三部分](/v1/part-iii) 讨论一些替代机制。
## 多主复制 ## 多主复制

View File

@ -23,7 +23,7 @@ breadcrumbs: false
通常情况下,每条数据(每条记录,每行或每个文档)属于且仅属于一个分区。有很多方法可以实现这一点,本章将进行深入讨论。实际上,每个分区都是自己的小型数据库,尽管数据库可能支持同时进行多个分区的操作。 通常情况下,每条数据(每条记录,每行或每个文档)属于且仅属于一个分区。有很多方法可以实现这一点,本章将进行深入讨论。实际上,每个分区都是自己的小型数据库,尽管数据库可能支持同时进行多个分区的操作。
分区主要是为了 **可伸缩性**。不同的分区可以放在不共享集群中的不同节点上(请参阅 [第二部分](/part-ii) 关于 [无共享架构](/part-ii#无共享架构) 的定义)。因此,大数据集可以分布在多个磁盘上,并且查询负载可以分布在多个处理器上。 分区主要是为了 **可伸缩性**。不同的分区可以放在不共享集群中的不同节点上(请参阅 [第二部分](/v1/part-ii) 关于 [无共享架构](/v1/part-ii#无共享架构) 的定义)。因此,大数据集可以分布在多个磁盘上,并且查询负载可以分布在多个处理器上。
对于在单个分区上运行的查询,每个节点可以独立执行对自己的查询,因此可以通过添加更多的节点来扩大查询吞吐量。大型,复杂的查询可能会跨越多个节点并行处理,尽管这也带来了新的困难。 对于在单个分区上运行的查询,每个节点可以独立执行对自己的查询,因此可以通过添加更多的节点来扩大查询吞吐量。大型,复杂的查询可能会跨越多个节点并行处理,尽管这也带来了新的困难。

View File

@ -95,7 +95,7 @@ breadcrumbs: false
## 不可靠的网络 ## 不可靠的网络
正如在 [第二部分](/part-ii) 的介绍中所讨论的那样,我们在本书中关注的分布式系统是无共享的系统,即通过网络连接的一堆机器。网络是这些机器可以通信的唯一途径 —— 我们假设每台机器都有自己的内存和磁盘,一台机器不能访问另一台机器的内存或磁盘(除了通过网络向服务器发出请求)。 正如在 [第二部分](/v1/part-ii) 的介绍中所讨论的那样,我们在本书中关注的分布式系统是无共享的系统,即通过网络连接的一堆机器。网络是这些机器可以通信的唯一途径 —— 我们假设每台机器都有自己的内存和磁盘,一台机器不能访问另一台机器的内存或磁盘(除了通过网络向服务器发出请求)。
**无共享** 并不是构建系统的唯一方式,但它已经成为构建互联网服务的主要方式,其原因如下:相对便宜,因为它不需要特殊的硬件,可以利用商品化的云计算服务,通过跨多个地理分布的数据中心进行冗余可以实现高可靠性。 **无共享** 并不是构建系统的唯一方式,但它已经成为构建互联网服务的主要方式,其原因如下:相对便宜,因为它不需要特殊的硬件,可以利用商品化的云计算服务,通过跨多个地理分布的数据中心进行冗余可以实现高可靠性。
@ -639,7 +639,7 @@ Web 应用程序确实需要预期受终端用户控制的客户端(如 Web
如果你习惯于在理想化的数学完美的单机环境同一个操作总能确定地返回相同的结果中编写软件那么转向分布式系统的凌乱的物理现实可能会有些令人震惊。相反如果能够在单台计算机上解决一个问题那么分布式系统工程师通常会认为这个问题是平凡的【5】现在单个计算机确实可以做很多事情【95】。如果你可以避免打开潘多拉的盒子把东西放在一台机器上那么通常是值得的。 如果你习惯于在理想化的数学完美的单机环境同一个操作总能确定地返回相同的结果中编写软件那么转向分布式系统的凌乱的物理现实可能会有些令人震惊。相反如果能够在单台计算机上解决一个问题那么分布式系统工程师通常会认为这个问题是平凡的【5】现在单个计算机确实可以做很多事情【95】。如果你可以避免打开潘多拉的盒子把东西放在一台机器上那么通常是值得的。
但是,正如在 [第二部分](/part-ii) 的介绍中所讨论的那样,可伸缩性并不是使用分布式系统的唯一原因。容错和低延迟(通过将数据放置在距离用户较近的地方)是同等重要的目标,而这些不能用单个节点实现。 但是,正如在 [第二部分](/v1/part-ii) 的介绍中所讨论的那样,可伸缩性并不是使用分布式系统的唯一原因。容错和低延迟(通过将数据放置在距离用户较近的地方)是同等重要的目标,而这些不能用单个节点实现。
在本章中,我们也转换了几次话题,探讨了网络、时钟和进程的不可靠性是否是不可避免的自然规律。我们看到这并不是:有可能给网络提供硬实时的响应保证和有限的延迟,但是这样做非常昂贵,且导致硬件资源的利用率降低。大多数非安全关键系统会选择 **便宜而不可靠**,而不是 **昂贵和可靠** 在本章中,我们也转换了几次话题,探讨了网络、时钟和进程的不可靠性是否是不可避免的自然规律。我们看到这并不是:有可能给网络提供硬实时的响应保证和有限的延迟,但是这样做非常昂贵,且导致硬件资源的利用率降低。大多数非安全关键系统会选择 **便宜而不可靠**,而不是 **昂贵和可靠**

View File

@ -919,7 +919,7 @@ ZooKeeper 和它的小伙伴们可以看作是成员资格服务membership se
本章引用了大量关于分布式系统理论的研究。虽然理论论文和证明并不总是容易理解,有时也会做出不切实际的假设,但它们对于指导这一领域的实践有着极其重要的价值:它们帮助我们推理什么可以做,什么不可以做,帮助我们找到反直觉的分布式系统缺陷。如果你有时间,这些参考资料值得探索。 本章引用了大量关于分布式系统理论的研究。虽然理论论文和证明并不总是容易理解,有时也会做出不切实际的假设,但它们对于指导这一领域的实践有着极其重要的价值:它们帮助我们推理什么可以做,什么不可以做,帮助我们找到反直觉的分布式系统缺陷。如果你有时间,这些参考资料值得探索。
这里已经到了本书 [第二部分](/part-ii) 的末尾,第二部介绍了复制([第五章](/v1/ch5))、分区([第六章](/v1/ch6))、事务([第七章](/v1/ch7))、分布式系统的故障模型([第八章](/v1/ch8))以及最后的一致性与共识([第九章](/v1/ch9))。现在我们已经奠定了扎实的理论基础,我们将在 [第三部分](/part-iii) 再次转向更实际的系统,并讨论如何使用异构的组件积木块构建强大的应用。 这里已经到了本书 [第二部分](/v1/part-ii) 的末尾,第二部介绍了复制([第五章](/v1/ch5))、分区([第六章](/v1/ch6))、事务([第七章](/v1/ch7))、分布式系统的故障模型([第八章](/v1/ch8))以及最后的一致性与共识([第九章](/v1/ch9))。现在我们已经奠定了扎实的理论基础,我们将在 [第三部分](/v1/part-iii) 再次转向更实际的系统,并讨论如何使用异构的组件积木块构建强大的应用。
## 参考文献 ## 参考文献

View File

@ -15,7 +15,7 @@ PostgreSQL 专家,数据库老司机,云计算泥石流。
## 校订与维护 ## 校订与维护
YinGang [@yingang](https://github.com/yingang) 对本书进行了全文校订,并持续维护。 Yin Gang [@yingang](https://github.com/yingang) 对本书进行了全文校订,并持续维护。
## 繁体中文版本 ## 繁体中文版本
@ -29,8 +29,8 @@ YinGang [@yingang](https://github.com/yingang) 对本书进行了全文校订,
1. [序言初翻修正](https://github.com/Vonng/ddia/commit/afb5edab55c62ed23474149f229677e3b42dfc2c) by [@seagullbird](https://github.com/Vonng/ddia/commits?author=seagullbird) 1. [序言初翻修正](https://github.com/Vonng/ddia/commit/afb5edab55c62ed23474149f229677e3b42dfc2c) by [@seagullbird](https://github.com/Vonng/ddia/commits?author=seagullbird)
2. [第一章语法标点校正](https://github.com/Vonng/ddia/commit/973b12cd8f8fcdf4852f1eb1649ddd9d187e3644) by [@nevertiree](https://github.com/Vonng/ddia/commits?author=nevertiree) 2. [第一章语法标点校正](https://github.com/Vonng/ddia/commit/973b12cd8f8fcdf4852f1eb1649ddd9d187e3644) by [@nevertiree](https://github.com/Vonng/ddia/commits?author=nevertiree)
3. [第六章部分校正](https://github.com/Vonng/ddia/commit/d4eb0852c0ec1e93c8aacc496c80b915bb1e6d48) 与[第十章的初翻](https://github.com/Vonng/ddia/commit/9de8dbd1bfe6fbb03b3bf6c1a1aa2291aed2490e) by [@MuAlex](https://github.com/Vonng/ddia/commits?author=MuAlex) 3. [第六章部分校正](https://github.com/Vonng/ddia/commit/d4eb0852c0ec1e93c8aacc496c80b915bb1e6d48) 与[第十章的初翻](https://github.com/Vonng/ddia/commit/9de8dbd1bfe6fbb03b3bf6c1a1aa2291aed2490e) by [@MuAlex](https://github.com/Vonng/ddia/commits?author=MuAlex)
4. [第一部分](/part-i)前言,[ch2](/v1/ch2)校正 by [@jiajiadebug](https://github.com/Vonng/ddia/commits?author=jiajiadebug) 4. [第一部分](/v1/part-i)前言,[ch2](/v1/ch2)校正 by [@jiajiadebug](https://github.com/Vonng/ddia/commits?author=jiajiadebug)
5. [词汇表](/glossary)、[后记](/colophon)关于野猪的部分 by [@Chowss](https://github.com/Vonng/ddia/commits?author=Chowss) 5. [词汇表](/v1/glossary)、[后记](/v1/colophon)关于野猪的部分 by [@Chowss](https://github.com/Vonng/ddia/commits?author=Chowss)
6. [繁體中文](https://github.com/Vonng/ddia/pulls)版本与转换脚本 by [@afunTW](https://github.com/afunTW) 6. [繁體中文](https://github.com/Vonng/ddia/pulls)版本与转换脚本 by [@afunTW](https://github.com/afunTW)
7. 多处翻译修正 by [@songzhibin97](https://github.com/Vonng/ddia/commits?author=songzhibin97) [@MamaShip](https://github.com/Vonng/ddia/commits?author=MamaShip) [@FangYuan33](https://github.com/Vonng/ddia/commits?author=FangYuan33) 7. 多处翻译修正 by [@songzhibin97](https://github.com/Vonng/ddia/commits?author=songzhibin97) [@MamaShip](https://github.com/Vonng/ddia/commits?author=MamaShip) [@FangYuan33](https://github.com/Vonng/ddia/commits?author=FangYuan33)

View File

@ -63,7 +63,7 @@ breadcrumbs: false
## **衍生数据derived data** ## **衍生数据derived data**
一种数据集,根据其他数据通过可重复运行的流程创建。必要时,你可以运行该流程再次创建衍生数据。衍生数据通常用于提高特定数据的读取速度。常见的衍生数据有索引、缓存和物化视图。请参阅[第三部分](/part-iii)的介绍。 一种数据集,根据其他数据通过可重复运行的流程创建。必要时,你可以运行该流程再次创建衍生数据。衍生数据通常用于提高特定数据的读取速度。常见的衍生数据有索引、缓存和物化视图。请参阅[第三部分](/v1/part-iii)的介绍。
## **确定性deterministic** ## **确定性deterministic**
@ -203,7 +203,7 @@ breadcrumbs: false
## **无共享shared-nothing** ## **无共享shared-nothing**
与共享内存或共享磁盘架构相比独立节点每个节点都有自己的CPU内存和磁盘通过传统网络连接。见[第二部分](/part-ii)的介绍。 与共享内存或共享磁盘架构相比独立节点每个节点都有自己的CPU内存和磁盘通过传统网络连接。见[第二部分](/v1/part-ii)的介绍。
## **偏斜skew** ## **偏斜skew**
@ -229,7 +229,7 @@ breadcrumbs: false
## **记录系统system of record** ## **记录系统system of record**
一个保存主要权威版本数据的系统,也被称为真相的来源。首先在这里写入数据变更,其他数据集可以从记录系统衍生。请参阅[第三部分](/part-iii)的介绍。 一个保存主要权威版本数据的系统,也被称为真相的来源。首先在这里写入数据变更,其他数据集可以从记录系统衍生。请参阅[第三部分](/v1/part-iii)的介绍。
## **超时timeout** ## **超时timeout**

View File

@ -11,7 +11,7 @@ breadcrumbs: false
------- -------
在本书的 [第一部分](/part-i) 中,我们讨论了数据系统的各个方面,但仅限于数据存储在单台机器上的情况。现在我们到了 [第二部分](/part-ii),进入更高的层次,并提出一个问题:如果 **多台机器** 参与数据的存储和检索,会发生什么? 在本书的 [第一部分](/v1/part-i) 中,我们讨论了数据系统的各个方面,但仅限于数据存储在单台机器上的情况。现在我们到了 [第二部分](/v1/part-ii),进入更高的层次,并提出一个问题:如果 **多台机器** 参与数据的存储和检索,会发生什么?
你可能会出于各种各样的原因,希望将数据库分布到多台机器上: 你可能会出于各种各样的原因,希望将数据库分布到多台机器上:
@ -66,7 +66,7 @@ breadcrumbs: false
理解了这些概念,就可以开始讨论在分布式系统中需要做出的困难抉择。[第七章](/v1/ch7) 将讨论 **事务Transaction**,这对于了解数据系统中可能出现的各种问题,以及我们可以做些什么很有帮助。[第八章](/v1/ch8) 和 [第九章](/v1/ch9) 将讨论分布式系统的根本局限性。 理解了这些概念,就可以开始讨论在分布式系统中需要做出的困难抉择。[第七章](/v1/ch7) 将讨论 **事务Transaction**,这对于了解数据系统中可能出现的各种问题,以及我们可以做些什么很有帮助。[第八章](/v1/ch8) 和 [第九章](/v1/ch9) 将讨论分布式系统的根本局限性。
在本书的 [第三部分](/part-iii) 中,将讨论如何将多个(可能是分布式的)数据存储集成为一个更大的系统,以满足复杂的应用需求。但首先,我们来聊聊分布式的数据。 在本书的 [第三部分](/v1/part-iii) 中,将讨论如何将多个(可能是分布式的)数据存储集成为一个更大的系统,以满足复杂的应用需求。但首先,我们来聊聊分布式的数据。
## 索引 ## 索引

View File

@ -5,7 +5,7 @@ breadcrumbs: false
--- ---
在本书的 [第一部分](/part-i) 和 [第二部分](/part-ii) 中,我们自底向上地把所有关于分布式数据库的主要考量都过了一遍。从数据在磁盘上的布局,一直到出现故障时分布式系统一致性的局限。但所有的讨论都假定了应用中只用了一种数据库。 在本书的 [第一部分](/v1/part-i) 和 [第二部分](/v1/part-ii) 中,我们自底向上地把所有关于分布式数据库的主要考量都过了一遍。从数据在磁盘上的布局,一直到出现故障时分布式系统一致性的局限。但所有的讨论都假定了应用中只用了一种数据库。
现实世界中的数据系统往往更为复杂。大型应用程序经常需要以多种方式访问和处理数据,没有一个数据库可以同时满足所有这些不同的需求。因此应用程序通常组合使用多种组件:数据存储、索引、缓存、分析系统等等,并实现在这些组件中移动数据的机制。 现实世界中的数据系统往往更为复杂。大型应用程序经常需要以多种方式访问和处理数据,没有一个数据库可以同时满足所有这些不同的需求。因此应用程序通常组合使用多种组件:数据存储、索引、缓存、分析系统等等,并实现在这些组件中移动数据的机制。

View File

@ -65,11 +65,11 @@ breadcrumbs: false
本书分为三部分: 本书分为三部分:
1. 在 [第一部分](/part-i) 中,我们会讨论设计数据密集型应用所赖的基本思想。我们从 [第一章](/v1/ch1) 开始,讨论我们实际要达到的目标:可靠性、可伸缩性和可维护性;我们该如何思考这些概念;以及如何实现它们。在 [第二章](/v1/ch2) 中,我们比较了几种不同的数据模型和查询语言,看看它们如何适用于不同的场景。在 [第三章](/v1/ch3) 中将讨论存储引擎:数据库如何在磁盘上摆放数据,以便能高效地再次找到它。[第四章](/v1/ch4) 转向数据编码(序列化),以及随时间演化的模式。 1. 在 [第一部分](/v1/part-i) 中,我们会讨论设计数据密集型应用所赖的基本思想。我们从 [第一章](/v1/ch1) 开始,讨论我们实际要达到的目标:可靠性、可伸缩性和可维护性;我们该如何思考这些概念;以及如何实现它们。在 [第二章](/v1/ch2) 中,我们比较了几种不同的数据模型和查询语言,看看它们如何适用于不同的场景。在 [第三章](/v1/ch3) 中将讨论存储引擎:数据库如何在磁盘上摆放数据,以便能高效地再次找到它。[第四章](/v1/ch4) 转向数据编码(序列化),以及随时间演化的模式。
2. 在 [第二部分](/part-ii) 中,我们从讨论存储在一台机器上的数据转向讨论分布在多台机器上的数据。这对于可伸缩性通常是必需的,但带来了各种独特的挑战。我们首先讨论复制([第五章](/v1/ch5))、分区 / 分片([第六章](/v1/ch6))和事务([第七章](/v1/ch7))。然后我们将探索关于分布式系统问题的更多细节([第八章](/v1/ch8)),以及在分布式系统中实现一致性与共识意味着什么([第九章](/v1/ch9))。 2. 在 [第二部分](/v1/part-ii) 中,我们从讨论存储在一台机器上的数据转向讨论分布在多台机器上的数据。这对于可伸缩性通常是必需的,但带来了各种独特的挑战。我们首先讨论复制([第五章](/v1/ch5))、分区 / 分片([第六章](/v1/ch6))和事务([第七章](/v1/ch7))。然后我们将探索关于分布式系统问题的更多细节([第八章](/v1/ch8)),以及在分布式系统中实现一致性与共识意味着什么([第九章](/v1/ch9))。
3. 在 [第三部分](/part-iii) 中,我们讨论那些从其他数据集衍生出一些数据集的系统。衍生数据经常出现在异构系统中:当没有单个数据库可以把所有事情都做的很好时,应用需要集成几种不同的数据库、缓存、索引等。在 [第十章](/v1/ch10) 中我们将从一种衍生数据的批处理方法开始,然后在此基础上建立在 [第十一章](/v1/ch11) 中讨论的流处理。最后,在 [第十二章](/v1/ch12) 中,我们将所有内容汇总,讨论在将来构建可靠、可伸缩和可维护的应用程序的方法。 3. 在 [第三部分](/v1/part-iii) 中,我们讨论那些从其他数据集衍生出一些数据集的系统。衍生数据经常出现在异构系统中:当没有单个数据库可以把所有事情都做的很好时,应用需要集成几种不同的数据库、缓存、索引等。在 [第十章](/v1/ch10) 中我们将从一种衍生数据的批处理方法开始,然后在此基础上建立在 [第十一章](/v1/ch11) 中讨论的流处理。最后,在 [第十二章](/v1/ch12) 中,我们将所有内容汇总,讨论在将来构建可靠、可伸缩和可维护的应用程序的方法。
## 参考文献与延伸阅读 ## 参考文献与延伸阅读

View File

@ -8,9 +8,9 @@ breadcrumbs: false
![](/title-v1.jpg) ![](/title-v1.jpg)
## [序言](/preface) ## [序言](/v1/preface)
## [第一部分:数据系统基础](/part-i) ## [第一部分:数据系统基础](/v1/part-i)
### [第一章:可靠性、可伸缩性和可维护性](/v1/ch1) ### [第一章:可靠性、可伸缩性和可维护性](/v1/ch1)
* [关于数据系统的思考](/v1/ch1#关于数据系统的思考) * [关于数据系统的思考](/v1/ch1#关于数据系统的思考)
@ -33,7 +33,7 @@ breadcrumbs: false
* [数据流的类型](/v1/ch4#数据流的类型) * [数据流的类型](/v1/ch4#数据流的类型)
* [本章小结](/v1/ch4#本章小结) * [本章小结](/v1/ch4#本章小结)
## [第二部分:分布式数据](/part-ii) ## [第二部分:分布式数据](/v1/part-ii)
### [第五章:复制](/v1/ch5) ### [第五章:复制](/v1/ch5)
* [领导者与追随者](/v1/ch5#领导者与追随者) * [领导者与追随者](/v1/ch5#领导者与追随者)
@ -66,7 +66,7 @@ breadcrumbs: false
* [分布式事务与共识](/v1/ch9#分布式事务与共识) * [分布式事务与共识](/v1/ch9#分布式事务与共识)
* [本章小结](/v1/ch9#本章小结) * [本章小结](/v1/ch9#本章小结)
## [第三部分:衍生数据](/part-iii) ## [第三部分:衍生数据](/v1/part-iii)
### [第十章:批处理](/v1/ch10) ### [第十章:批处理](/v1/ch10)
* [使用Unix工具的批处理](/v1/ch10#使用Unix工具的批处理) * [使用Unix工具的批处理](/v1/ch10#使用Unix工具的批处理)
@ -85,7 +85,7 @@ breadcrumbs: false
* [做正确的事情](/v1/ch12#做正确的事情) * [做正确的事情](/v1/ch12#做正确的事情)
* [本章小结](/v1/ch12#本章小结) * [本章小结](/v1/ch12#本章小结)
### [术语表](/glossary) ### [术语表](/v1/glossary)
### [后记](/colophon) ### [后记](/v1/colophon)