update text spacing with pangu and some manual adjustments

This commit is contained in:
Gang Yin 2022-01-22 10:01:13 +08:00
parent 8547560e62
commit d1d526e40e
6 changed files with 32 additions and 32 deletions

View File

@ -125,7 +125,7 @@
## 法律声明
从原作者处得知已经有简体中文的翻译计划将于2018年末完成。[购买地址](https://search.jd.com/Search?keyword=设计数据密集型应用)
从原作者处得知,已经有简体中文的翻译计划,将于 2018 年末完成。[购买地址](https://search.jd.com/Search?keyword=设计数据密集型应用)
译者纯粹出于 **学习目的****个人兴趣** 翻译本书,不追求任何经济利益。

View File

@ -15,7 +15,7 @@
如果你的数据量、读取负载、写入负载超出单台机器的处理能力,可以将负载分散到多台计算机上。
* 容错/高可用性
* 容错 / 高可用性
如果你的应用需要在单台机器(或多台机器,网络或整个数据中心)出现故障的情况下仍然能继续工作,则可使用多台机器,以提供冗余。一台故障时,另一台可以接管。

View File

@ -4,14 +4,14 @@
在最近十年中,我们看到了很多有趣的进展,关于数据库,分布式系统,以及在此基础上构建应用程序的方式。这些进展有着各种各样的驱动力:
* 谷歌、雅虎、亚马逊、脸书、领英、微软和推特等互联网公司正在和巨大的流量/数据打交道,这迫使他们去创造能有效应对如此规模的新工具。
* 谷歌、雅虎、亚马逊、脸书、领英、微软和推特等互联网公司正在和巨大的流量 / 数据打交道,这迫使他们去创造能有效应对如此规模的新工具。
* 企业需要变得敏捷,需要低成本地检验假设,需要通过缩短开发周期和保持数据模型的灵活性,快速地响应新的市场洞察。
* 免费和开源软件变得非常成功,在许多环境中比商业软件和定制软件更受欢迎。
* 处理器主频几乎没有增长,但是多核处理器已经成为标配,网络也越来越快。这意味着并行化程度只增不减。
* 即使你在一个小团队中工作现在也可以构建分布在多台计算机甚至多个地理区域的系统这要归功于譬如亚马逊网络服务AWS等基础设施即服务IaaS概念的践行者。
* 许多服务都要求高可用,因停电或维护导致的服务不可用,变得越来越难以接受。
**数据密集型应用data-intensive applications** 正在通过使用这些技术进步来推动可能性的边界。一个应用被称为**数据密集型**的,如果**数据是其主要挑战**(数据量,数据复杂度或数据变化速度)—— 与之相对的是**计算密集型**,即处理器速度是其瓶颈。
**数据密集型应用data-intensive applications** 正在通过使用这些技术进步来推动可能性的边界。一个应用被称为 **数据密集型** 的,如果 **数据是其主要挑战**(数据量,数据复杂度或数据变化速度)—— 与之相对的是 **计算密集型**,即处理器速度是其瓶颈。
帮助数据密集型应用存储和处理数据的工具与技术正迅速地适应这些变化。新型数据库系统“NoSQL”已经备受关注而消息队列缓存搜索索引批处理和流处理框架以及相关技术也非常重要。很多应用组合使用这些工具与技术。
@ -21,14 +21,14 @@
本书的目标是帮助你在飞速变化的数据处理和数据存储技术大观园中找到方向。本书并不是某个特定工具的教程,也不是一本充满枯燥理论的教科书。相反,我们将看到一些成功数据系统的样例:许多流行应用每天都要在生产中满足可伸缩性、性能、以及可靠性的要求,而这些技术构成了这些应用的基础。
我们将深入这些系统的内部,理清它们的关键算法,讨论背后的原则和它们必须做出的权衡。在这个过程中,我们将尝试寻找**思考**数据系统的有效方式 —— 不仅关于它们**如何**工作,还包括它们**为什么**以这种方式工作,以及哪些问题是我们需要问的。
我们将深入这些系统的内部,理清它们的关键算法,讨论背后的原则和它们必须做出的权衡。在这个过程中,我们将尝试寻找 **思考** 数据系统的有效方式 —— 不仅关于它们 **如何** 工作,还包括它们 **为什么** 以这种方式工作,以及哪些问题是我们需要问的。
阅读本书后,你能很好地决定哪种技术适合哪种用途,并了解如何将工具组合起来,为一个良好应用架构奠定基础。本书并不足以使你从头开始构建自己的数据库存储引擎,不过幸运的是这基本上很少有必要。你将获得对系统底层发生事情的敏锐直觉,这样你就有能力推理它们的行为,做出优秀的设计决策,并追踪任何可能出现的问题。
## 本书的目标读者
如果你开发的应用具有用于存储或处理数据的某种服务器/后端系统而且使用网络例如Web应用、移动应用或连接到互联网的传感器那么本书就是为你准备的。
如果你开发的应用具有用于存储或处理数据的某种服务器 / 后端系统而且使用网络例如Web 应用、移动应用或连接到互联网的传感器),那么本书就是为你准备的。
本书是为软件工程师,软件架构师,以及喜欢写代码的技术经理准备的。如果你需要对所从事系统的架构做出决策 —— 例如你需要选择解决某个特定问题的工具,并找出如何最好地使用这些工具,那么这本书对你尤有价值。但即使你无法选择你的工具,本书仍将帮助你更好地了解所使用工具的长处和短处。
@ -41,18 +41,18 @@
* 你正在寻找使系统在长期运行过程易于维护的方法,即使系统规模增长,需求与技术也发生变化。
* 你对事物的运作方式有着天然的好奇心,并且希望知道一些主流网站和在线服务背后发生的事情。这本书打破了各种数据库和数据处理系统的内幕,探索这些系统设计中的智慧是非常有趣的。
有时在讨论可伸缩的数据系统时,人们会说:“你又不在谷歌或亚马逊,别操心可伸缩性了,直接上关系型数据库”。这个陈述有一定的道理:为了不必要的伸缩性而设计程序,不仅会浪费不必要的精力,并且可能会把你锁死在一个不灵活的设计中。实际上这是一种“过早优化”的形式。不过,选择合适的工具确实很重要,而不同的技术各有优缺点。我们将看到,关系数据库虽然很重要,但绝不是数据处理的终章。
有时在讨论可伸缩的数据系统时,人们会说:“你又不在谷歌或亚马逊,别操心可伸缩性了,直接上关系型数据库”。这个陈述有一定的道理:为了不必要的伸缩性而设计程序,不仅会浪费不必要的精力,并且可能会把你锁死在一个不灵活的设计中。实际上这是一种 “过早优化” 的形式。不过,选择合适的工具确实很重要,而不同的技术各有优缺点。我们将看到,关系数据库虽然很重要,但绝不是数据处理的终章。
## 本书涉及的领域
本书并不会尝试告诉读者如何安装或使用特定的软件包或API因为已经有大量文档给出了详细的使用说明。相反我们会讨论数据系统的基石——各种原则与利弊权衡并探讨了不同产品所做出的不同设计决策。
本书并不会尝试告诉读者如何安装或使用特定的软件包或 API因为已经有大量文档给出了详细的使用说明。相反我们会讨论数据系统的基石 —— 各种原则与利弊权衡,并探讨了不同产品所做出的不同设计决策。
在电子书中包含了在线资源全文的链接。所有链接在出版时都进行了验证,但不幸的是,由于网络的自然规律,链接往往会频繁地破损。如果你遇到链接断开的情况,或者正在阅读本书的打印副本,可以使用搜索引擎查找参考文献。对于学术论文,你可以在 Google 学术中搜索标题,查找可以公开获取的 PDF 文件。或者,你也可以在 https://github.com/ept/ddia-references 中找到所有的参考资料,我们在那儿维护最新的链接。
我们主要关注的是数据系统的**架构architecture**,以及它们被集成到数据密集型应用中的方式。本书没有足够的空间覆盖部署、运维、安全、管理等领域 —— 这些都是复杂而重要的主题,仅仅在本书中用粗略的注解讨论这些对它们很不公平。每个领域都值得用单独的书去讲。
我们主要关注的是数据系统的 **架构architecture**,以及它们被集成到数据密集型应用中的方式。本书没有足够的空间覆盖部署、运维、安全、管理等领域 —— 这些都是复杂而重要的主题,仅仅在本书中用粗略的注解讨论这些对它们很不公平。每个领域都值得用单独的书去讲。
本书中描述的许多技术都被涵盖在 **大数据Big Data** 这个时髦词的范畴中。然而“大数据”这个术语被滥用,缺乏明确定义,以至于在严肃的工程讨论中没有用处。这本书使用歧义更小的术语,如“单节点”之于“分布式系统”,或“在线/交互式系统”之于“离线/批处理系统”。
本书中描述的许多技术都被涵盖在 **大数据Big Data** 这个时髦词的范畴中。然而 “大数据” 这个术语被滥用,缺乏明确定义,以至于在严肃的工程讨论中没有用处。这本书使用歧义更小的术语,如 “单节点” 之于 “分布式系统”,或 “在线 / 交互式系统” 之于 “离线 / 批处理系统”。
本书对 **自由和开源软件FOSS** 有一定偏好,因为阅读、修改和执行源码是了解某事物详细工作原理的好方法。开放的平台也可以降低供应商垄断的风险。然而在适当的情况下,我们也会讨论专利软件(闭源软件,软件即服务 SaaS或一些在文献中描述过但未公开发行的公司内部软件
@ -60,16 +60,16 @@
本书分为三部分:
1. 在[第一部分](part-i.md)中,我们会讨论设计数据密集型应用所赖的基本思想。我们从[第一章](ch1.md)开始,讨论我们实际要达到的目标:可靠性、可伸缩性和可维护性;我们该如何思考这些概念;以及如何实现它们。在[第二章](ch2.md)中,我们比较了几种不同的数据模型和查询语言,看看它们如何适用于不同的场景。在[第三章](ch3.md)中将讨论存储引擎:数据库如何在磁盘上摆放数据,以便能高效地再次找到它。[第四章](ch4.md)转向数据编码(序列化),以及随时间演化的模式。
1. 在 [第一部分](part-i.md) 中,我们会讨论设计数据密集型应用所赖的基本思想。我们从 [第一章](ch1.md) 开始,讨论我们实际要达到的目标:可靠性、可伸缩性和可维护性;我们该如何思考这些概念;以及如何实现它们。在 [第二章](ch2.md) 中,我们比较了几种不同的数据模型和查询语言,看看它们如何适用于不同的场景。在 [第三章](ch3.md) 中将讨论存储引擎:数据库如何在磁盘上摆放数据,以便能高效地再次找到它。[第四章](ch4.md) 转向数据编码(序列化),以及随时间演化的模式。
2. 在[第二部分](part-ii.md)中,我们从讨论存储在一台机器上的数据转向讨论分布在多台机器上的数据。这对于可伸缩性通常是必需的,但带来了各种独特的挑战。我们首先讨论复制([第五章](ch5.md))、分区/分片([第六章](ch6.md))和事务([第七章](ch7.md))。然后我们将探索关于分布式系统问题的更多细节([第八章](ch8.md)),以及在分布式系统中实现一致性与共识意味着什么([第九章](ch9.md))。
2. 在 [第二部分](part-ii.md) 中,我们从讨论存储在一台机器上的数据转向讨论分布在多台机器上的数据。这对于可伸缩性通常是必需的,但带来了各种独特的挑战。我们首先讨论复制([第五章](ch5.md))、分区 / 分片([第六章](ch6.md))和事务([第七章](ch7.md))。然后我们将探索关于分布式系统问题的更多细节([第八章](ch8.md)),以及在分布式系统中实现一致性与共识意味着什么([第九章](ch9.md))。
3. 在[第三部分](part-iii.md)中,我们讨论那些从其他数据集衍生出一些数据集的系统。衍生数据经常出现在异构系统中:当没有单个数据库可以把所有事情都做的很好时,应用需要集成几种不同的数据库、缓存、索引等。在[第十章](ch10.md)中我们将从一种衍生数据的批处理方法开始,然后在此基础上建立在[第十一章](ch11.md)中讨论的流处理。最后,在[第十二章](ch12.md)中,我们将所有内容汇总,讨论在将来构建可靠、可伸缩和可维护的应用程序的方法。
3. 在 [第三部分](part-iii.md) 中,我们讨论那些从其他数据集衍生出一些数据集的系统。衍生数据经常出现在异构系统中:当没有单个数据库可以把所有事情都做的很好时,应用需要集成几种不同的数据库、缓存、索引等。在 [第十章](ch10.md) 中我们将从一种衍生数据的批处理方法开始,然后在此基础上建立在 [第十一章](ch11.md) 中讨论的流处理。最后,在 [第十二章](ch12.md) 中,我们将所有内容汇总,讨论在将来构建可靠、可伸缩和可维护的应用程序的方法。
## 参考文献与延伸阅读
本书中讨论的大部分内容已经在其它地方以某种形式出现过了 —— 会议演示文稿、研究论文、博客文章、代码、BUG跟踪器、邮件列表以及工程习惯中。本书总结了不同来源资料中最重要的想法并在文本中包含了指向原始文献的链接。 如果你想更深入地探索一个领域,那么每章末尾的参考文献都是很好的资源,其中大部分可以免费在线获取。
本书中讨论的大部分内容已经在其它地方以某种形式出现过了 —— 会议演示文稿、研究论文、博客文章、代码、BUG 跟踪器、邮件列表以及工程习惯中。本书总结了不同来源资料中最重要的想法,并在文本中包含了指向原始文献的链接。 如果你想更深入地探索一个领域,那么每章末尾的参考文献都是很好的资源,其中大部分可以免费在线获取。
## OReilly Safari
@ -83,11 +83,11 @@ For more information, please visit http://oreilly.com/safari.
## 致谢
本书融合了学术研究和工业实践的经验融合并系统化了大量其他人的想法与知识。在计算领域我们往往会被各种新鲜花样所吸引但我认为前人完成的工作中有太多值得我们学习的地方了。本书有800多处引用文章、博客、讲座、文档等对我来说这些都是宝贵的学习资源。我非常感谢这些材料的作者分享他们的知识。
本书融合了学术研究和工业实践的经验,融合并系统化了大量其他人的想法与知识。在计算领域,我们往往会被各种新鲜花样所吸引,但我认为前人完成的工作中,有太多值得我们学习的地方了。本书有 800 多处引用:文章、博客、讲座、文档等,对我来说这些都是宝贵的学习资源。我非常感谢这些材料的作者分享他们的知识。
我也从与人交流中学到了很多东西,很多人花费了宝贵的时间与我讨论想法并耐心解释。特别感谢 Joe Adler, Ross Anderson, Peter Bailis, Márton Balassi, Alastair Beresford, Mark Callaghan, Mat Clayton, Patrick Collison, Sean Cribbs, Shirshanka Das, Niklas Ekström, Stephan Ewen, Alan Fekete, Gyula Fóra, Camille Fournier, Andres Freund, John Garbutt, Seth Gilbert, Tom Haggett, Pat Hel land, Joe Hellerstein, Jakob Homan, Heidi Howard, John Hugg, Julian Hyde, Conrad Irwin, Evan Jones, Flavio Junqueira, Jessica Kerr, Kyle Kingsbury, Jay Kreps, Carl Lerche, Nicolas Liochon, Steve Loughran, Lee Mallabone, Nathan Marz, Caitie McCaffrey, Josie McLellan, Christopher Meiklejohn, Ian Meyers, Neha Narkhede, Neha Narula, Cathy ONeil, Onora ONeill, Ludovic Orban, Zoran Perkov, Julia Powles, Chris Riccomini, Henry Robinson, David Rosenthal, Jennifer Rullmann, Matthew Sackman, Martin Scholl, Amit Sela, Gwen Shapira, Greg Spurrier, Sam Stokes, Ben Stopford, Tom Stuart, Diana Vasile, Rahul Vohra, Pete Warden, 以及 Brett Wooldridge.
更多人通过审阅草稿并提供反馈意见在本书的创作过程中做出了无价的贡献。我要特别感谢Raul Agepati, Tyler Akidau, Mattias Andersson, Sasha Baranov, Veena Basavaraj, David Beyer, Jim Brikman, Paul Carey, Raul Castro Fernandez, Joseph Chow, Derek Elkins, Sam Elliott, Alexander Gallego, Mark Grover, Stu Halloway, Heidi Howard, Nicola Kleppmann, Stefan Kruppa, Bjorn Madsen, Sander Mak, Stefan Podkowinski, Phil Potter, Hamid Ramazani, Sam Stokes, 以及Ben Summers。当然对于本书中的任何遗留错误或难以接受的见解我都承担全部责任。
更多人通过审阅草稿并提供反馈意见在本书的创作过程中做出了无价的贡献。我要特别感谢 Raul Agepati, Tyler Akidau, Mattias Andersson, Sasha Baranov, Veena Basavaraj, David Beyer, Jim Brikman, Paul Carey, Raul Castro Fernandez, Joseph Chow, Derek Elkins, Sam Elliott, Alexander Gallego, Mark Grover, Stu Halloway, Heidi Howard, Nicola Kleppmann, Stefan Kruppa, Bjorn Madsen, Sander Mak, Stefan Podkowinski, Phil Potter, Hamid Ramazani, Sam Stokes, 以及 Ben Summers。当然对于本书中的任何遗留错误或难以接受的见解我都承担全部责任。
为了帮助这本书落地,并且耐心地处理我缓慢的写作和不寻常的要求,我要对编辑 Marie BeaugureauMike LoukidesAnn Spencer 和 O'Reilly 的所有团队表示感谢。我要感谢 Rachel Head 帮我找到了合适的术语。我要感谢 Alastair BeresfordSusan GoodhueNeha Narkhede 和 Kevin Scott在其他工作事务之外给了我充分地创作时间和自由。

View File

@ -125,7 +125,7 @@
## 法律宣告
從原作者處得知已經有簡體中文的翻譯計劃將於2018年末完成。[購買地址](https://search.jd.com/Search?keyword=設計資料密集型應用)
從原作者處得知,已經有簡體中文的翻譯計劃,將於 2018 年末完成。[購買地址](https://search.jd.com/Search?keyword=設計資料密集型應用)
譯者純粹出於 **學習目的****個人興趣** 翻譯本書,不追求任何經濟利益。

View File

@ -15,7 +15,7 @@
如果你的資料量、讀取負載、寫入負載超出單臺機器的處理能力,可以將負載分散到多臺計算機上。
* 容錯/高可用性
* 容錯 / 高可用性
如果你的應用需要在單臺機器(或多臺機器,網路或整個資料中心)出現故障的情況下仍然能繼續工作,則可使用多臺機器,以提供冗餘。一臺故障時,另一臺可以接管。

View File

@ -4,14 +4,14 @@
在最近十年中,我們看到了很多有趣的進展,關於資料庫,分散式系統,以及在此基礎上構建應用程式的方式。這些進展有著各種各樣的驅動力:
* 谷歌、雅虎、亞馬遜、臉書、領英、微軟和推特等網際網路公司正在和巨大的流量/資料打交道,這迫使他們去創造能有效應對如此規模的新工具。
* 谷歌、雅虎、亞馬遜、臉書、領英、微軟和推特等網際網路公司正在和巨大的流量 / 資料打交道,這迫使他們去創造能有效應對如此規模的新工具。
* 企業需要變得敏捷,需要低成本地檢驗假設,需要透過縮短開發週期和保持資料模型的靈活性,快速地響應新的市場洞察。
* 免費和開源軟體變得非常成功,在許多環境中比商業軟體和定製軟體更受歡迎。
* 處理器主頻幾乎沒有增長,但是多核處理器已經成為標配,網路也越來越快。這意味著並行化程度只增不減。
* 即使你在一個小團隊中工作現在也可以構建分佈在多臺計算機甚至多個地理區域的系統這要歸功於譬如亞馬遜網路服務AWS等基礎設施即服務IaaS概念的踐行者。
* 許多服務都要求高可用,因停電或維護導致的服務不可用,變得越來越難以接受。
**資料密集型應用data-intensive applications** 正在透過使用這些技術進步來推動可能性的邊界。一個應用被稱為**資料密集型**的,如果**資料是其主要挑戰**(資料量,資料複雜度或資料變化速度)—— 與之相對的是**計算密集型**,即處理器速度是其瓶頸。
**資料密集型應用data-intensive applications** 正在透過使用這些技術進步來推動可能性的邊界。一個應用被稱為 **資料密集型** 的,如果 **資料是其主要挑戰**(資料量,資料複雜度或資料變化速度)—— 與之相對的是 **計算密集型**,即處理器速度是其瓶頸。
幫助資料密集型應用儲存和處理資料的工具與技術正迅速地適應這些變化。新型資料庫系統“NoSQL”已經備受關注而訊息佇列快取搜尋索引批處理和流處理框架以及相關技術也非常重要。很多應用組合使用這些工具與技術。
@ -21,14 +21,14 @@
本書的目標是幫助你在飛速變化的資料處理和資料儲存技術大觀園中找到方向。本書並不是某個特定工具的教程,也不是一本充滿枯燥理論的教科書。相反,我們將看到一些成功資料系統的樣例:許多流行應用每天都要在生產中滿足可伸縮性、效能、以及可靠性的要求,而這些技術構成了這些應用的基礎。
我們將深入這些系統的內部,理清它們的關鍵演算法,討論背後的原則和它們必須做出的權衡。在這個過程中,我們將嘗試尋找**思考**資料系統的有效方式 —— 不僅關於它們**如何**工作,還包括它們**為什麼**以這種方式工作,以及哪些問題是我們需要問的。
我們將深入這些系統的內部,理清它們的關鍵演算法,討論背後的原則和它們必須做出的權衡。在這個過程中,我們將嘗試尋找 **思考** 資料系統的有效方式 —— 不僅關於它們 **如何** 工作,還包括它們 **為什麼** 以這種方式工作,以及哪些問題是我們需要問的。
閱讀本書後,你能很好地決定哪種技術適合哪種用途,並瞭解如何將工具組合起來,為一個良好應用架構奠定基礎。本書並不足以使你從頭開始構建自己的資料庫儲存引擎,不過幸運的是這基本上很少有必要。你將獲得對系統底層發生事情的敏銳直覺,這樣你就有能力推理它們的行為,做出優秀的設計決策,並追蹤任何可能出現的問題。
## 本書的目標讀者
如果你開發的應用具有用於儲存或處理資料的某種伺服器/後端系統而且使用網路例如Web應用、移動應用或連線到網際網路的感測器那麼本書就是為你準備的。
如果你開發的應用具有用於儲存或處理資料的某種伺服器 / 後端系統而且使用網路例如Web 應用、移動應用或連線到網際網路的感測器),那麼本書就是為你準備的。
本書是為軟體工程師,軟體架構師,以及喜歡寫程式碼的技術經理準備的。如果你需要對所從事系統的架構做出決策 —— 例如你需要選擇解決某個特定問題的工具,並找出如何最好地使用這些工具,那麼這本書對你尤有價值。但即使你無法選擇你的工具,本書仍將幫助你更好地瞭解所使用工具的長處和短處。
@ -41,18 +41,18 @@
* 你正在尋找使系統在長期執行過程易於維護的方法,即使系統規模增長,需求與技術也發生變化。
* 你對事物的運作方式有著天然的好奇心,並且希望知道一些主流網站和線上服務背後發生的事情。這本書打破了各種資料庫和資料處理系統的內幕,探索這些系統設計中的智慧是非常有趣的。
有時在討論可伸縮的資料系統時,人們會說:“你又不在谷歌或亞馬遜,別操心可伸縮性了,直接上關係型資料庫”。這個陳述有一定的道理:為了不必要的伸縮性而設計程式,不僅會浪費不必要的精力,並且可能會把你鎖死在一個不靈活的設計中。實際上這是一種“過早最佳化”的形式。不過,選擇合適的工具確實很重要,而不同的技術各有優缺點。我們將看到,關係資料庫雖然很重要,但絕不是資料處理的終章。
有時在討論可伸縮的資料系統時,人們會說:“你又不在谷歌或亞馬遜,別操心可伸縮性了,直接上關係型資料庫”。這個陳述有一定的道理:為了不必要的伸縮性而設計程式,不僅會浪費不必要的精力,並且可能會把你鎖死在一個不靈活的設計中。實際上這是一種 “過早最佳化” 的形式。不過,選擇合適的工具確實很重要,而不同的技術各有優缺點。我們將看到,關係資料庫雖然很重要,但絕不是資料處理的終章。
## 本書涉及的領域
本書並不會嘗試告訴讀者如何安裝或使用特定的軟體包或API因為已經有大量文件給出了詳細的使用說明。相反我們會討論資料系統的基石——各種原則與利弊權衡並探討了不同產品所做出的不同設計決策。
本書並不會嘗試告訴讀者如何安裝或使用特定的軟體包或 API因為已經有大量文件給出了詳細的使用說明。相反我們會討論資料系統的基石 —— 各種原則與利弊權衡,並探討了不同產品所做出的不同設計決策。
在電子書中包含了線上資源全文的連結。所有連結在出版時都進行了驗證,但不幸的是,由於網路的自然規律,連結往往會頻繁地破損。如果你遇到連結斷開的情況,或者正在閱讀本書的列印副本,可以使用搜索引擎查詢參考文獻。對於學術論文,你可以在 Google 學術中搜索標題,查詢可以公開獲取的 PDF 檔案。或者,你也可以在 https://github.com/ept/ddia-references 中找到所有的參考資料,我們在那兒維護最新的連結。
我們主要關注的是資料系統的**架構architecture**,以及它們被整合到資料密集型應用中的方式。本書沒有足夠的空間覆蓋部署、運維、安全、管理等領域 —— 這些都是複雜而重要的主題,僅僅在本書中用粗略的註解討論這些對它們很不公平。每個領域都值得用單獨的書去講。
我們主要關注的是資料系統的 **架構architecture**,以及它們被整合到資料密集型應用中的方式。本書沒有足夠的空間覆蓋部署、運維、安全、管理等領域 —— 這些都是複雜而重要的主題,僅僅在本書中用粗略的註解討論這些對它們很不公平。每個領域都值得用單獨的書去講。
本書中描述的許多技術都被涵蓋在 **大資料Big Data** 這個時髦詞的範疇中。然而“大資料”這個術語被濫用,缺乏明確定義,以至於在嚴肅的工程討論中沒有用處。這本書使用歧義更小的術語,如“單節點”之於“分散式系統”,或“線上/互動式系統”之於“離線/批處理系統”。
本書中描述的許多技術都被涵蓋在 **大資料Big Data** 這個時髦詞的範疇中。然而 “大資料” 這個術語被濫用,缺乏明確定義,以至於在嚴肅的工程討論中沒有用處。這本書使用歧義更小的術語,如 “單節點” 之於 “分散式系統”,或 “線上 / 互動式系統” 之於 “離線 / 批處理系統”。
本書對 **自由和開源軟體FOSS** 有一定偏好,因為閱讀、修改和執行原始碼是瞭解某事物詳細工作原理的好方法。開放的平臺也可以降低供應商壟斷的風險。然而在適當的情況下,我們也會討論專利軟體(閉源軟體,軟體即服務 SaaS或一些在文獻中描述過但未公開發行的公司內部軟體
@ -60,16 +60,16 @@
本書分為三部分:
1. 在[第一部分](part-i.md)中,我們會討論設計資料密集型應用所賴的基本思想。我們從[第一章](ch1.md)開始,討論我們實際要達到的目標:可靠性、可伸縮性和可維護性;我們該如何思考這些概念;以及如何實現它們。在[第二章](ch2.md)中,我們比較了幾種不同的資料模型和查詢語言,看看它們如何適用於不同的場景。在[第三章](ch3.md)中將討論儲存引擎:資料庫如何在磁碟上擺放資料,以便能高效地再次找到它。[第四章](ch4.md)轉向資料編碼(序列化),以及隨時間演化的模式。
1. 在 [第一部分](part-i.md) 中,我們會討論設計資料密集型應用所賴的基本思想。我們從 [第一章](ch1.md) 開始,討論我們實際要達到的目標:可靠性、可伸縮性和可維護性;我們該如何思考這些概念;以及如何實現它們。在 [第二章](ch2.md) 中,我們比較了幾種不同的資料模型和查詢語言,看看它們如何適用於不同的場景。在 [第三章](ch3.md) 中將討論儲存引擎:資料庫如何在磁碟上擺放資料,以便能高效地再次找到它。[第四章](ch4.md) 轉向資料編碼(序列化),以及隨時間演化的模式。
2. 在[第二部分](part-ii.md)中,我們從討論儲存在一臺機器上的資料轉向討論分佈在多臺機器上的資料。這對於可伸縮性通常是必需的,但帶來了各種獨特的挑戰。我們首先討論複製([第五章](ch5.md))、分割槽/分片([第六章](ch6.md))和事務([第七章](ch7.md))。然後我們將探索關於分散式系統問題的更多細節([第八章](ch8.md)),以及在分散式系統中實現一致性與共識意味著什麼([第九章](ch9.md))。
2. 在 [第二部分](part-ii.md) 中,我們從討論儲存在一臺機器上的資料轉向討論分佈在多臺機器上的資料。這對於可伸縮性通常是必需的,但帶來了各種獨特的挑戰。我們首先討論複製([第五章](ch5.md))、分割槽 / 分片([第六章](ch6.md))和事務([第七章](ch7.md))。然後我們將探索關於分散式系統問題的更多細節([第八章](ch8.md)),以及在分散式系統中實現一致性與共識意味著什麼([第九章](ch9.md))。
3. 在[第三部分](part-iii.md)中,我們討論那些從其他資料集衍生出一些資料集的系統。衍生資料經常出現在異構系統中:當沒有單個數據庫可以把所有事情都做的很好時,應用需要整合幾種不同的資料庫、快取、索引等。在[第十章](ch10.md)中我們將從一種衍生資料的批處理方法開始,然後在此基礎上建立在[第十一章](ch11.md)中討論的流處理。最後,在[第十二章](ch12.md)中,我們將所有內容彙總,討論在將來構建可靠、可伸縮和可維護的應用程式的方法。
3. 在 [第三部分](part-iii.md) 中,我們討論那些從其他資料集衍生出一些資料集的系統。衍生資料經常出現在異構系統中:當沒有單個數據庫可以把所有事情都做的很好時,應用需要整合幾種不同的資料庫、快取、索引等。在 [第十章](ch10.md) 中我們將從一種衍生資料的批處理方法開始,然後在此基礎上建立在 [第十一章](ch11.md) 中討論的流處理。最後,在 [第十二章](ch12.md) 中,我們將所有內容彙總,討論在將來構建可靠、可伸縮和可維護的應用程式的方法。
## 參考文獻與延伸閱讀
本書中討論的大部分內容已經在其它地方以某種形式出現過了 —— 會議簡報、研究論文、部落格文章、程式碼、BUG跟蹤器、郵件列表以及工程習慣中。本書總結了不同來源資料中最重要的想法並在文字中包含了指向原始文獻的連結。 如果你想更深入地探索一個領域,那麼每章末尾的參考文獻都是很好的資源,其中大部分可以免費線上獲取。
本書中討論的大部分內容已經在其它地方以某種形式出現過了 —— 會議簡報、研究論文、部落格文章、程式碼、BUG 跟蹤器、郵件列表以及工程習慣中。本書總結了不同來源資料中最重要的想法,並在文字中包含了指向原始文獻的連結。 如果你想更深入地探索一個領域,那麼每章末尾的參考文獻都是很好的資源,其中大部分可以免費線上獲取。
## OReilly Safari
@ -83,11 +83,11 @@ For more information, please visit http://oreilly.com/safari.
## 致謝
本書融合了學術研究和工業實踐的經驗融合並系統化了大量其他人的想法與知識。在計算領域我們往往會被各種新鮮花樣所吸引但我認為前人完成的工作中有太多值得我們學習的地方了。本書有800多處引用文章、部落格、講座、文件等對我來說這些都是寶貴的學習資源。我非常感謝這些材料的作者分享他們的知識。
本書融合了學術研究和工業實踐的經驗,融合並系統化了大量其他人的想法與知識。在計算領域,我們往往會被各種新鮮花樣所吸引,但我認為前人完成的工作中,有太多值得我們學習的地方了。本書有 800 多處引用:文章、部落格、講座、文件等,對我來說這些都是寶貴的學習資源。我非常感謝這些材料的作者分享他們的知識。
我也從與人交流中學到了很多東西,很多人花費了寶貴的時間與我討論想法並耐心解釋。特別感謝 Joe Adler, Ross Anderson, Peter Bailis, Márton Balassi, Alastair Beresford, Mark Callaghan, Mat Clayton, Patrick Collison, Sean Cribbs, Shirshanka Das, Niklas Ekström, Stephan Ewen, Alan Fekete, Gyula Fóra, Camille Fournier, Andres Freund, John Garbutt, Seth Gilbert, Tom Haggett, Pat Hel land, Joe Hellerstein, Jakob Homan, Heidi Howard, John Hugg, Julian Hyde, Conrad Irwin, Evan Jones, Flavio Junqueira, Jessica Kerr, Kyle Kingsbury, Jay Kreps, Carl Lerche, Nicolas Liochon, Steve Loughran, Lee Mallabone, Nathan Marz, Caitie McCaffrey, Josie McLellan, Christopher Meiklejohn, Ian Meyers, Neha Narkhede, Neha Narula, Cathy ONeil, Onora ONeill, Ludovic Orban, Zoran Perkov, Julia Powles, Chris Riccomini, Henry Robinson, David Rosenthal, Jennifer Rullmann, Matthew Sackman, Martin Scholl, Amit Sela, Gwen Shapira, Greg Spurrier, Sam Stokes, Ben Stopford, Tom Stuart, Diana Vasile, Rahul Vohra, Pete Warden, 以及 Brett Wooldridge.
更多人透過審閱草稿並提供反饋意見在本書的創作過程中做出了無價的貢獻。我要特別感謝Raul Agepati, Tyler Akidau, Mattias Andersson, Sasha Baranov, Veena Basavaraj, David Beyer, Jim Brikman, Paul Carey, Raul Castro Fernandez, Joseph Chow, Derek Elkins, Sam Elliott, Alexander Gallego, Mark Grover, Stu Halloway, Heidi Howard, Nicola Kleppmann, Stefan Kruppa, Bjorn Madsen, Sander Mak, Stefan Podkowinski, Phil Potter, Hamid Ramazani, Sam Stokes, 以及Ben Summers。當然對於本書中的任何遺留錯誤或難以接受的見解我都承擔全部責任。
更多人透過審閱草稿並提供反饋意見在本書的創作過程中做出了無價的貢獻。我要特別感謝 Raul Agepati, Tyler Akidau, Mattias Andersson, Sasha Baranov, Veena Basavaraj, David Beyer, Jim Brikman, Paul Carey, Raul Castro Fernandez, Joseph Chow, Derek Elkins, Sam Elliott, Alexander Gallego, Mark Grover, Stu Halloway, Heidi Howard, Nicola Kleppmann, Stefan Kruppa, Bjorn Madsen, Sander Mak, Stefan Podkowinski, Phil Potter, Hamid Ramazani, Sam Stokes, 以及 Ben Summers。當然對於本書中的任何遺留錯誤或難以接受的見解我都承擔全部責任。
為了幫助這本書落地,並且耐心地處理我緩慢的寫作和不尋常的要求,我要對編輯 Marie BeaugureauMike LoukidesAnn Spencer 和 O'Reilly 的所有團隊表示感謝。我要感謝 Rachel Head 幫我找到了合適的術語。我要感謝 Alastair BeresfordSusan GoodhueNeha Narkhede 和 Kevin Scott在其他工作事務之外給了我充分地創作時間和自由。