document/ddia
2
0
Fork 0
mirror of https://github.com/Vonng/ddia.git synced 2024-12-06 15:20:12 +08:00
Code Issues Packages Projects Releases Wiki Activity

各部分卷首语精翻

Browse Source
This commit is contained in:
Vonng 2018-03-09 00:00:42 +08:00
parent 84aace63ea
commit a6df7e9fb6
9 changed files with 204 additions and 269 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
README.md
View File

@ -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% |
| 第三部分：前言 | 机翻 | |
| 第十章：批处理 | 机翻 | |
| 第十一章：流处理 | 机翻 | |
| 第十二章：数据系统的未来 | 机翻 | |
| 术语表 | - | |
| 后记 | 机翻 | |
| 章节 | 进度 |
| :--------------------------------: | :------: |
| 序言 | 初翻 |
| 第一部分：数据系统基础 ——概览 | **精翻** |
| 第一章：可靠性、可扩展性、可维护性 | **精翻** |
| 第二章：数据模型与查询语言 | 初翻 |
| 第三章：存储与检索 | 初翻 |
| 第四章：编码与演化 | 初翻 |
| 第二部分：分布式数据——概览 | 精翻 |
| 第五章：复制 | 初翻 |
| 第六章：分片 | 初翻 |
| 第七章：事务 | 初翻 |
| 第八章：分布式系统中的问题 | 初翻 |
| 第九章：一致性与共识 | 机翻 |
| 第三部分：前言 | **精翻** |
| 第十章：批处理 | 机翻 |
| 第十一章：流处理 | 机翻 |
| 第十二章：数据系统的未来 | 机翻 |
| 术语表 | - |
| 后记 | 机翻 |
最近比较忙，精翻计划可能会延后，但初翻会尽量先过一遍。早期的几章初翻质量很一般，后续会重新过一遍。

16
ddia/README.md
View File

@ -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) | 机翻 |

6
ddia/ch10.md
View File

@ -1026,7 +1026,7 @@ MapReduce经常写入磁盘，这使得从单个失败的任务中轻松地恢
------
| 上一章 | 目录 | 下一章 |
| ---------------------------- | ------------------------------- | ------------------------ |
| [第九章：一致与共识](ch9.md) | [设计数据密集型应用](README.md) | [第十章：流处理](ch7.md) |
| 上一章 | 目录 | 下一章 |
| --------------------------------- | ------------------------------- | ------------------------ |
| [第三部分：派生数据](part-iii.md) | [设计数据密集型应用](README.md) | [第十章：流处理](ch7.md) |

188
ddia/ch5.md
View File

@ -795,81 +795,49 @@ LWW实现了最终收敛的目标，但以**持久性**为代价：如果同一
1. “[AlwaysOn Availability Groups](http://msdn.microsoft.com/en-us/library/hh510230.aspx),” in *SQL Server Books Online*, Microsoft, 2012.
1. Lin Qiao, Kapil Surlaker, Shirshanka Das, et al.:
“[On Brewing Fresh Espresso: LinkedIn’s Distributed Data Serving Platform](http://www.slideshare.net/amywtang/espresso-20952131),” at *ACM International Conference on
Management of Data* (SIGMOD), June 2013.
1. Lin Qiao, Kapil Surlaker, Shirshanka Das, et al.: “[On Brewing Fresh Espresso: LinkedIn’s Distributed Data Serving Platform](http://www.slideshare.net/amywtang/espresso-20952131),” at *ACM International Conference on Management of Data* (SIGMOD), June 2013.
1. Jun Rao:
“[Intra-Cluster Replication for Apache Kafka](http://www.slideshare.net/junrao/kafka-replication-apachecon2013),” at *ApacheCon North America*, February 2013.
1. Jun Rao: “[Intra-Cluster Replication for Apache Kafka](http://www.slideshare.net/junrao/kafka-replication-apachecon2013),” at *ApacheCon North America*, February 2013.
1. “[Highly Available Queues](https://www.rabbitmq.com/ha.html),” in *RabbitMQ Server Documentation*, Pivotal Software, Inc., 2014.
1. Yoshinori Matsunobu:
“[Semi-Synchronous Replication at Facebook](http://yoshinorimatsunobu.blogspot.co.uk/2014/04/semi-synchronous-replication-at-facebook.html),” *yoshinorimatsunobu.blogspot.co.uk*, April 1, 2014.
1. Yoshinori Matsunobu: “[Semi-Synchronous Replication at Facebook](http://yoshinorimatsunobu.blogspot.co.uk/2014/04/semi-synchronous-replication-at-facebook.html),” *yoshinorimatsunobu.blogspot.co.uk*, April 1, 2014.
1. Robbert van Renesse and Fred B. Schneider:
“[Chain Replication for Supporting High Throughput and Availability](http://static.usenix.org/legacy/events/osdi04/tech/full_papers/renesse/renesse.pdf),” at *6th USENIX Symposium on
Operating System Design and Implementation* (OSDI), December 2004.
1. Robbert van Renesse and Fred B. Schneider: “[Chain Replication for Supporting High Throughput and Availability](http://static.usenix.org/legacy/events/osdi04/tech/full_papers/renesse/renesse.pdf),” at *6th USENIX Symposium on Operating System Design and Implementation* (OSDI), December 2004.
1. Jeff Terrace and Michael J. Freedman:
“[Object Storage on CRAQ: High-Throughput Chain Replication for Read-Mostly Workloads](https://www.usenix.org/legacy/event/usenix09/tech/full_papers/terrace/terrace.pdf),” at *USENIX
Annual Technical Conference* (ATC), June 2009.
1. Jeff Terrace and Michael J. Freedman: “[Object Storage on CRAQ: High-Throughput Chain Replication for Read-Mostly Workloads](https://www.usenix.org/legacy/event/usenix09/tech/full_papers/terrace/terrace.pdf),” at *USENIX Annual Technical Conference* (ATC), June 2009.
1. Brad Calder, Ju Wang, Aaron Ogus, et al.:
“[Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency](http://sigops.org/sosp/sosp11/current/2011-Cascais/printable/11-calder.pdf),” at *23rd ACM
Symposium on Operating Systems Principles* (SOSP), October 2011.
1. Brad Calder, Ju Wang, Aaron Ogus, et al.: “[Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency](http://sigops.org/sosp/sosp11/current/2011-Cascais/printable/11-calder.pdf),” at *23rd ACM Symposium on Operating Systems Principles* (SOSP), October 2011.
1. Andrew Wang:
“[Windows Azure Storage](http://umbrant.com/blog/2016/windows_azure_storage.html),”
*umbrant.com*, February 4, 2016.
1. Andrew Wang: “[Windows Azure Storage](http://umbrant.com/blog/2016/windows_azure_storage.html),” *umbrant.com*, February 4, 2016.
1. “[Percona Xtrabackup - Documentation](https://www.percona.com/doc/percona-xtrabackup/2.1/index.html),” Percona LLC, 2014.
1. Jesse Newland:
“[GitHub Availability This Week](https://github.com/blog/1261-github-availability-this-week),” *github.com*, September 14, 2012.
1. Jesse Newland: “[GitHub Availability This Week](https://github.com/blog/1261-github-availability-this-week),” *github.com*, September 14, 2012.
1. Mark Imbriaco:
“[Downtime Last Saturday](https://github.com/blog/1364-downtime-last-saturday),”
*github.com*, December 26, 2012.
1. Mark Imbriaco: “[Downtime Last Saturday](https://github.com/blog/1364-downtime-last-saturday),” *github.com*, December 26, 2012.
1. John Hugg:
“[‘All in’ with Determinism for Performance and Testing in Distributed Systems](https://www.youtube.com/watch?v=gJRj3vJL4wE),” at *Strange Loop*, September 2015.
1. John Hugg: “[‘All in’ with Determinism for Performance and Testing in Distributed Systems](https://www.youtube.com/watch?v=gJRj3vJL4wE),” at *Strange Loop*, September 2015. Amit Kapila: “[WAL Internals of PostgreSQL](http://www.pgcon.org/2012/schedule/attachments/258_212_Internals%20Of%20PostgreSQL%20Wal.pdf),” at *PostgreSQL Conference* (PGCon), May 2012.
1. Amit Kapila:
“[WAL Internals of PostgreSQL](http://www.pgcon.org/2012/schedule/attachments/258_212_Internals%20Of%20PostgreSQL%20Wal.pdf),” at *PostgreSQL Conference* (PGCon), May 2012.
1. [*MySQL Internals Manual*](http://dev.mysql.com/doc/internals/en/index.html). Oracle, 2014.
1. <a href="http://dev.mysql.com/doc/internals/en/index.html">*MySQL
Internals Manual*</a>. Oracle, 2014.
1. Yogeshwer Sharma, Philippe Ajoux, Petchean Ang, et al.:
“[Wormhole: Reliable Pub-Sub to Support Geo-Replicated Internet Services](https://www.usenix.org/system/files/conference/nsdi15/nsdi15-paper-sharma.pdf),” at *12th USENIX
Symposium on Networked Systems Design and Implementation* (NSDI), May 2015.
1. Yogeshwer Sharma, Philippe Ajoux, Petchean Ang, et al.: “[Wormhole: Reliable Pub-Sub to Support Geo-Replicated Internet Services](https://www.usenix.org/system/files/conference/nsdi15/nsdi15-paper-sharma.pdf),” at *12th USENIX Symposium on Networked Systems Design and Implementation* (NSDI), May 2015.
1. “[Oracle GoldenGate 12c: Real-Time Access to Real-Time Information](http://www.oracle.com/us/products/middleware/data-integration/oracle-goldengate-realtime-access-2031152.pdf),” Oracle White Paper, October 2013.
1. Shirshanka Das, Chavdar Botev, Kapil Surlaker, et al.:
“[All Aboard the Databus!](http://www.socc2012.org/s18-das.pdf),” at
1. Shirshanka Das, Chavdar Botev, Kapil Surlaker, et al.: “[All Aboard the Databus!](http://www.socc2012.org/s18-das.pdf),” at
*ACM Symposium on Cloud Computing* (SoCC), October 2012.
1. Greg Sabino Mullane:
“[Version 5 of Bucardo Database Replication System](http://blog.endpoint.com/2014/06/bucardo-5-multimaster-postgres-released.html),” *blog.endpoint.com*, June 23, 2014.
1. Greg Sabino Mullane: “[Version 5 of Bucardo Database Replication System](http://blog.endpoint.com/2014/06/bucardo-5-multimaster-postgres-released.html),” *blog.endpoint.com*, June 23, 2014.
1. Werner Vogels:
“[Eventually Consistent](http://queue.acm.org/detail.cfm?id=1466448),”
*ACM Queue*, volume 6, number 6, pages 14–19, October 2008.
1. Werner Vogels: “[Eventually Consistent](http://queue.acm.org/detail.cfm?id=1466448),” *ACM Queue*, volume 6, number 6, pages 14–19, October 2008.
[doi:10.1145/1466443.1466448](http://dx.doi.org/10.1145/1466443.1466448)
1. Douglas B. Terry:
“[Replicated Data Consistency Explained Through Baseball](http://research.microsoft.com/pubs/157411/ConsistencyAndBaseballReport.pdf),” Microsoft Research, Technical Report
MSR-TR-2011-137, October 2011.
1. Douglas B. Terry: “[Replicated Data Consistency Explained Through Baseball](http://research.microsoft.com/pubs/157411/ConsistencyAndBaseballReport.pdf),” Microsoft Research, Technical Report MSR-TR-2011-137, October 2011.
1. Douglas B. Terry, Alan J. Demers, Karin Petersen, et al.:
“[Session Guarantees for Weakly Consistent Replicated Data](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.71.2269&rep=rep1&type=pdf),” at *3rd International Conference
on Parallel and Distributed Information Systems* (PDIS), September 1994.
[doi:10.1109/PDIS.1994.331722](http://dx.doi.org/10.1109/PDIS.1994.331722)
1. Douglas B. Terry, Alan J. Demers, Karin Petersen, et al.: “[Session Guarantees for Weakly Consistent Replicated Data](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.71.2269&rep=rep1&type=pdf),” at *3rd International Conference on Parallel and Distributed Information Systems* (PDIS), September 1994. [doi:10.1109/PDIS.1994.331722](http://dx.doi.org/10.1109/PDIS.1994.331722)
1. Terry Pratchett: *Reaper Man: A Discworld
Novel*. Victor Gollancz, 1991. ISBN: 978-0-575-04979-6
1. Terry Pratchett: *Reaper Man: A Discworld Novel*. Victor Gollancz, 1991. ISBN: 978-0-575-04979-6
1. “[Tungsten Replicator](http://tungsten-replicator.org/),” Continuent, Inc., 2014.
@ -879,85 +847,51 @@ LWW实现了最终收敛的目标，但以**持久性**为代价：如果同一
“[If You *Must* Deploy Multi-Master Replication, Read This First](http://scale-out-blog.blogspot.co.uk/2012/04/if-you-must-deploy-multi-master.html),” *scale-out-blog.blogspot.co.uk*,
March 30, 2012.
1. J. Chris Anderson, Jan Lehnardt, and Noah
Slater: *CouchDB: The Definitive Guide*. O'Reilly Media, 2010.
1. J. Chris Anderson, Jan Lehnardt, and Noah Slater: *CouchDB: The Definitive Guide*. O'Reilly Media, 2010.
ISBN: 978-0-596-15589-6
1. AppJet, Inc.:
“[Etherpad and EasySync Technical Manual](https://github.com/ether/etherpad-lite/blob/e2ce9dc/doc/easysync/easysync-full-description.pdf),” *github.com*, March 26, 2011.
1. AppJet, Inc.: “[Etherpad and EasySync Technical Manual](https://github.com/ether/etherpad-lite/blob/e2ce9dc/doc/easysync/easysync-full-description.pdf),” *github.com*, March 26, 2011.
1. John Day-Richter:
“[What’s Different About the New Google Docs: Making Collaboration Fast](http://googledrive.blogspot.com/2010/09/whats-different-about-new-google-docs.html),” *googledrive.blogspot.com*,
23 September 2010.
1. John Day-Richter: “[What’s Different About the New Google Docs: Making Collaboration Fast](http://googledrive.blogspot.com/2010/09/whats-different-about-new-google-docs.html),” *googledrive.blogspot.com*, 23 September 2010.
1. Martin Kleppmann and Alastair R. Beresford:
“[A Conflict-Free Replicated JSON Datatype](http://arxiv.org/abs/1608.03960),”
1. Martin Kleppmann and Alastair R. Beresford: “[A Conflict-Free Replicated JSON Datatype](http://arxiv.org/abs/1608.03960),”
arXiv:1608.03960, August 13, 2016.
1. Frazer Clement:
“[Eventual Consistency – Detecting Conflicts](http://messagepassing.blogspot.co.uk/2011/10/eventual-consistency-detecting.html),” *messagepassing.blogspot.co.uk*, October 20, 2011.
1. Frazer Clement: “[Eventual Consistency – Detecting Conflicts](http://messagepassing.blogspot.co.uk/2011/10/eventual-consistency-detecting.html),” *messagepassing.blogspot.co.uk*, October 20, 2011.
1. Robert Hodges:
“[State of the Art for MySQL Multi-Master Replication](https://www.percona.com/live/mysql-conference-2013/sessions/state-art-mysql-multi-master-replication),” at *Percona Live: MySQL Conference &
Expo*, April 2013.
1. Robert Hodges: “[State of the Art for MySQL Multi-Master Replication](https://www.percona.com/live/mysql-conference-2013/sessions/state-art-mysql-multi-master-replication),” at *Percona Live: MySQL Conference & Expo*, April 2013.
1. John Daily:
“[Clocks Are Bad, or, Welcome to the Wonderful World of Distributed Systems](http://basho.com/clocks-are-bad-or-welcome-to-distributed-systems/),” *basho.com*, November 12, 2013.
1. John Daily: “[Clocks Are Bad, or, Welcome to the Wonderful World of Distributed Systems](http://basho.com/clocks-are-bad-or-welcome-to-distributed-systems/),” *basho.com*, November 12, 2013.
1. Riley Berton:
“[Is Bi-Directional Replication (BDR) in Postgres Transactional?](http://sdf.org/~riley/blog/2016/01/04/is-bi-directional-replication-bdr-in-postgres-transactional/),” *sdf.org*, January 4, 2016.
1. Riley Berton: “[Is Bi-Directional Replication (BDR) in Postgres Transactional?](http://sdf.org/~riley/blog/2016/01/04/is-bi-directional-replication-bdr-in-postgres-transactional/),” *sdf.org*, January 4, 2016.
1. Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, et al.:
“[Dynamo: Amazon's Highly Available Key-Value Store](http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf),” at *21st ACM Symposium on Operating
Systems Principles* (SOSP), October 2007.
1. Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, et al.: “[Dynamo: Amazon's Highly Available Key-Value Store](http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf),” at *21st ACM Symposium on Operating Systems Principles* (SOSP), October 2007.
1. Marc Shapiro, Nuno Preguiça, Carlos Baquero,
and Marek Zawirski: “[A Comprehensive Study of Convergent and Commutative Replicated Data Types](http://hal.inria.fr/inria-00555588/),” INRIA Research Report no. 7506,
1. Marc Shapiro, Nuno Preguiça, Carlos Baquero, and Marek Zawirski: “[A Comprehensive Study of Convergent and Commutative Replicated Data Types](http://hal.inria.fr/inria-00555588/),” INRIA Research Report no. 7506,
January 2011.
1. Sam Elliott:
“[CRDTs: An UPDATE (or Maybe Just a PUT)](https://speakerdeck.com/lenary/crdts-an-update-or-just-a-put),” at *RICON West*, October 2013.
1. Sam Elliott: “[CRDTs: An UPDATE (or Maybe Just a PUT)](https://speakerdeck.com/lenary/crdts-an-update-or-just-a-put),” at *RICON West*, October 2013.
1. Russell Brown:
“[A Bluffers Guide to CRDTs in Riak](https://gist.github.com/russelldb/f92f44bdfb619e089a4d),” *gist.github.com*, October 28, 2013.
1. Russell Brown: “[A Bluffers Guide to CRDTs in Riak](https://gist.github.com/russelldb/f92f44bdfb619e089a4d),” *gist.github.com*, October 28, 2013.
1. Benjamin Farinier, Thomas Gazagnaire, and
Anil Madhavapeddy: “[Mergeable Persistent Data Structures](http://gazagnaire.org/pub/FGM15.pdf),” at *26es Journées Francophones des Langages Applicatifs* (JFLA),
January 2015.
1. Benjamin Farinier, Thomas Gazagnaire, and Anil Madhavapeddy: “[Mergeable Persistent Data Structures](http://gazagnaire.org/pub/FGM15.pdf),” at *26es Journées Francophones des Langages Applicatifs* (JFLA), January 2015.
1. Chengzheng Sun and Clarence Ellis:
“[Operational Transformation in Real-Time Group Editors: Issues, Algorithms, and Achievements](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.53.933&rep=rep1&type=pdf),” at
*ACM Conference on Computer Supported Cooperative Work* (CSCW), November 1998.
1. Chengzheng Sun and Clarence Ellis: “[Operational Transformation in Real-Time Group Editors: Issues, Algorithms, and Achievements](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.53.933&rep=rep1&type=pdf),” at *ACM Conference on Computer Supported Cooperative Work* (CSCW), November 1998.
1. Lars Hofhansl:
“[HBASE-7709: Infinite Loop Possible in Master/Master Replication](https://issues.apache.org/jira/browse/HBASE-7709),” *issues.apache.org*, January 29, 2013.
1. Lars Hofhansl: “[HBASE-7709: Infinite Loop Possible in Master/Master Replication](https://issues.apache.org/jira/browse/HBASE-7709),” *issues.apache.org*, January 29, 2013.
1. David K. Gifford:
“[Weighted Voting for Replicated Data](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.84.7698),”
at *7th ACM Symposium on Operating Systems Principles* (SOSP), December 1979.
[doi:10.1145/800215.806583](http://dx.doi.org/10.1145/800215.806583)
1. David K. Gifford: “[Weighted Voting for Replicated Data](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.84.7698),” at *7th ACM Symposium on Operating Systems Principles* (SOSP), December 1979. [doi:10.1145/800215.806583](http://dx.doi.org/10.1145/800215.806583)
1. Heidi Howard, Dahlia Malkhi, and Alexander Spiegelman:
“[Flexible Paxos: Quorum Intersection Revisited](https://arxiv.org/abs/1608.06696),”
*arXiv:1608.06696*, August 24, 2016.
1. Heidi Howard, Dahlia Malkhi, and Alexander Spiegelman: “[Flexible Paxos: Quorum Intersection Revisited](https://arxiv.org/abs/1608.06696),” *arXiv:1608.06696*, August 24, 2016.
1. Joseph Blomstedt:
“[Re: Absolute Consistency](http://lists.basho.com/pipermail/riak-users_lists.basho.com/2012-January/007157.html),” email to *riak-users* mailing list, *lists.basho.com*,
1. Joseph Blomstedt: “[Re: Absolute Consistency](http://lists.basho.com/pipermail/riak-users_lists.basho.com/2012-January/007157.html),” email to *riak-users* mailing list, *lists.basho.com*,
January 11, 2012.
1. Joseph Blomstedt:
“[Bringing Consistency to Riak](https://vimeo.com/51973001),” at *RICON West*,
October 2012.
1. Joseph Blomstedt: “[Bringing Consistency to Riak](https://vimeo.com/51973001),” at *RICON West*, October 2012.
1. Peter Bailis, Shivaram Venkataraman,
Michael J. Franklin, et al.:
“[Quantifying Eventual Consistency with PBS](http://www.bailis.org/papers/pbs-cacm2014.pdf),”
*Communications of the ACM*, volume 57, number 8, pages 93–102, August 2014.
[doi:10.1145/2632792](http://dx.doi.org/10.1145/2632792)
1. Peter Bailis, Shivaram Venkataraman, Michael J. Franklin, et al.: “[Quantifying Eventual Consistency with PBS](http://www.bailis.org/papers/pbs-cacm2014.pdf),” *Communications of the ACM*, volume 57, number 8, pages 93–102, August 2014. [doi:10.1145/2632792](http://dx.doi.org/10.1145/2632792)
1. Jonathan Ellis:
“[Modern Hinted Handoff](http://www.datastax.com/dev/blog/modern-hinted-handoff),”
*datastax.com*, December 11, 2012.
1. Jonathan Ellis: “[Modern Hinted Handoff](http://www.datastax.com/dev/blog/modern-hinted-handoff),” *datastax.com*, December 11, 2012.
1. “[Project Voldemort Wiki](https://github.com/voldemort/voldemort/wiki),” *github.com*, 2013.
@ -966,47 +900,27 @@ LWW实现了最终收敛的目标，但以**持久性**为代价：如果同一
1. “[Riak Enterprise: Multi-Datacenter Replication](http://basho.com/assets/MultiDatacenter_Replication.pdf).” Technical whitepaper, Basho Technologies, Inc.,
September 2014.
1. Jonathan Ellis:
“[Why Cassandra Doesn't Need Vector Clocks](http://www.datastax.com/dev/blog/why-cassandra-doesnt-need-vector-clocks),” *datastax.com*, September 2, 2013.
1. Jonathan Ellis: “[Why Cassandra Doesn't Need Vector Clocks](http://www.datastax.com/dev/blog/why-cassandra-doesnt-need-vector-clocks),” *datastax.com*, September 2, 2013.
1. Leslie Lamport:
“[Time, Clocks, and the Ordering of Events in a Distributed System](http://research.microsoft.com/en-US/um/people/Lamport/pubs/time-clocks.pdf),” *Communications of the ACM*,
volume 21, number 7, pages 558–565, July 1978.
[doi:10.1145/359545.359563](http://dx.doi.org/10.1145/359545.359563)
1. Leslie Lamport: “[Time, Clocks, and the Ordering of Events in a Distributed System](http://research.microsoft.com/en-US/um/people/Lamport/pubs/time-clocks.pdf),” *Communications of the ACM*, volume 21, number 7, pages 558–565, July 1978. [doi:10.1145/359545.359563](http://dx.doi.org/10.1145/359545.359563)
1. Joel Jacobson:
“[Riak 2.0: Data Types](http://blog.joeljacobson.com/riak-2-0-data-types/),”
*blog.joeljacobson.com*, March 23, 2014.
1. Joel Jacobson: “[Riak 2.0: Data Types](http://blog.joeljacobson.com/riak-2-0-data-types/),” *blog.joeljacobson.com*, March 23, 2014.
1. D. Stott Parker Jr., Gerald J. Popek, Gerard Rudisin, et al.:
“[Detection of Mutual Inconsistency in Distributed Systems](http://zoo.cs.yale.edu/classes/cs426/2013/bib/parker83detection.pdf),” *IEEE Transactions on Software Engineering*,
volume 9, number 3, pages 240–247, May 1983.
[doi:10.1109/TSE.1983.236733](http://dx.doi.org/10.1109/TSE.1983.236733)
1. D. Stott Parker Jr., Gerald J. Popek, Gerard Rudisin, et al.: “[Detection of Mutual Inconsistency in Distributed Systems](http://zoo.cs.yale.edu/classes/cs426/2013/bib/parker83detection.pdf),” *IEEE Transactions on Software Engineering*, volume 9, number 3, pages 240–247, May 1983. [doi:10.1109/TSE.1983.236733](http://dx.doi.org/10.1109/TSE.1983.236733)
1. Nuno Preguiça, Carlos Baquero, Paulo Sérgio
Almeida, et al.: “[Dotted Version Vectors: Logical Clocks for Optimistic Replication](http://arxiv.org/pdf/1011.5808v1.pdf),” arXiv:1011.5808, November 26,
2010.
1. Nuno Preguiça, Carlos Baquero, Paulo Sérgio Almeida, et al.: “[Dotted Version Vectors: Logical Clocks for Optimistic Replication](http://arxiv.org/pdf/1011.5808v1.pdf),” arXiv:1011.5808, November 26, 2010.
1. Sean Cribbs:
“[A Brief History of Time in Riak](https://www.youtube.com/watch?v=HHkKPdOi-ZU),”
at *RICON*, October 2014.
1. Sean Cribbs: “[A Brief History of Time in Riak](https://www.youtube.com/watch?v=HHkKPdOi-ZU),” at *RICON*, October 2014.
1. Russell Brown:
“[Vector Clocks Revisited Part 2: Dotted Version Vectors](http://basho.com/posts/technical/vector-clocks-revisited-part-2-dotted-version-vectors/),” *basho.com*, November 10, 2015.
1. Carlos Baquero:
“[Version Vectors Are Not Vector Clocks](https://haslab.wordpress.com/2011/07/08/version-vectors-are-not-vector-clocks/),” *haslab.wordpress.com*, July 8, 2011.
1. Reinhard Schwarz and Friedemann Mattern:
“[Detecting Causal Relationships in Distributed Computations: In Search of the Holy Grail](http://dcg.ethz.ch/lectures/hs08/seminar/papers/mattern4.pdf),” *Distributed
Computing*, volume 7, number 3, pages 149–174, March 1994.
[doi:10.1007/BF02277859](http://dx.doi.org/10.1007/BF02277859)
1. Russell Brown: “[Vector Clocks Revisited Part 2: Dotted Version Vectors](http://basho.com/posts/technical/vector-clocks-revisited-part-2-dotted-version-vectors/),” *basho.com*, November 10, 2015.
1. Carlos Baquero: “[Version Vectors Are Not Vector Clocks](https://haslab.wordpress.com/2011/07/08/version-vectors-are-not-vector-clocks/),” *haslab.wordpress.com*, July 8, 2011.
1. Reinhard Schwarz and Friedemann Mattern: “[Detecting Causal Relationships in Distributed Computations: In Search of the Holy Grail](http://dcg.ethz.ch/lectures/hs08/seminar/papers/mattern4.pdf),” *Distributed Computing*, volume 7, number 3, pages 149–174, March 1994. [doi:10.1007/BF02277859](http://dx.doi.org/10.1007/BF02277859)
--------
| 上一章 | 目录 | 下一章 |
| :--------------------------: | :-----------------------------: | :--------------------: |
| [第四章：编码与演化](ch4.md) | [设计数据密集型应用](README.md) | [第六章：分片](ch6.md) |
| 上一章 | 目录 | 下一章 |
| :--------------------------------: | :-----------------------------: | :--------------------: |
| [第二部分：分布式数据](part-ii.md) | [设计数据密集型应用](README.md) | [第六章：分片](ch6.md) |

56
ddia/ch9.md
View File

@ -323,7 +323,7 @@ CAP最初是作为一个经验法则提出的，没有准确的定义，目的
### 顺序与因果
订单不断涌现有几个原因，其中一个原因是它有助于保持因果关系。在这本书的过程中，我们已经看到了几个例子，其中因果关系是重要的：
顺序不断涌现有几个原因，其中一个原因是它有助于保持因果关系。在这本书的过程中，我们已经看到了几个例子，其中因果关系是重要的：
* 在“[一致前缀读取]()”（[图5-5](img/fig5-5.png)）中，我们看到一个例子，一个对话的观察者首先看到问题的答案，然后回答问题。这是令人困惑的，因为它违背了我们对因果的直觉：如果一个问题得到了回答，那么显然这个问题必须首先在那里，因为给出答案的人必须看到这个问题（假设他们不是精神的，未来）。我们说在问题和答案之间存在因果关系。
* [图5-9](img/fig5-9.png)中出现了类似的模式，我们在这里看到三位领导者之间的复制，并注意到由于网络延迟，一些文字可能会“超过”其他文字。从其中一个副本的角度看，好像有一个不存在的行的更新。这里的因果意味着一行必须先被创建，然后才能被更新。
@ -344,7 +344,7 @@ CAP最初是作为一个经验法则提出的，没有准确的定义，目的
但是，数学集并不完全排序：是`{a, b}`大于`{b, c}`？那么，你不能真正地比较它们，因为它们都不是其中的一个子集。我们说它们是无法比拟的，因此数学集是部分排序的：在某些情况下，一个集大于另一个（如果一个集包含另一个集的所有元素），但在其他情况下它们是无法比拟的。
总订单和部分订单之间的差异反映在不同的数据库一致性模型中：
全局顺序和局部顺序之间的差异反映在不同的数据库一致性模型中：
***线性化***
@ -393,7 +393,7 @@ CAP最初是作为一个经验法则提出的，没有准确的定义，目的
特别是，我们可以按照与因果关系一致的顺序创建序列号[^vii]：我们保证，如果操作A因果关系发生在B之前，那么A在总顺序之前发生在B之前（A具有比B更小的序列号）。并行操作可以任意命令。这样一个总的秩序捕获所有的因果信息，但也强加了比由于因果关系所严格要求的更多的秩序。
[^vii]: 与因果关系不一致的整个订单很容易创建，但不是很有用。例如，您可以为每个操作生成随机UUID，并按照字典顺序比较UUID以定义操作的总顺序。这是一个有效的总顺序，但是随机的UUID并不告诉你哪个操作首先实际发生，或者操作是否是并发的。
[^vii]: 与因果关系不一致的整个顺序很容易创建，但不是很有用。例如，您可以为每个操作生成随机UUID，并按照字典顺序比较UUID以定义操作的总顺序。这是一个有效的总顺序，但是随机的UUID并不告诉你哪个操作首先实际发生，或者操作是否是并发的。
在具有单引导程序复制的数据库中（请参见“[领导者与追随者](ch5.md#领导者与追随者)”），复制日志定义了与因果关系一致的写操作总顺序。领导者可以简单地为每个操作增加一个计数器，从而为复制日志中的每个操作分配一个单调递增的序列号。如果一个追随者按照他们在复制日志中出现的顺序来应用写入，那么追随者的状态始终是因果一致的（即使它落后于领导者）。
@ -453,9 +453,9 @@ Lamport时间戳有时会与版本向量混淆，我们在第184页上的“检
这里的问题是，只有在收集了所有的操作之后，操作的总顺序才会出现。如果另一个节点已经产生了一些操作，但是你还不知道它们是什么，那么就不能构造最终的操作顺序：来自另一个节点的未知操作可能需要被插入到总数的不同位置订购。
总之：为了实现像用户名的唯一性约束这样的事情，仅仅对操作进行全面的排序是不够的，您还需要知道该命令何时完成。如果您有创建用户名的操作，并且您确定没有其他节点可以在您的操作之前为全部订单插入相同用户名的声明，则可以安全地声明操作成功。
总之：为了实现像用户名的唯一性约束这样的事情，仅仅对操作进行全面的排序是不够的，您还需要知道该命令何时完成。如果您有创建用户名的操作，并且您确定没有其他节点可以在您的操作之前为全部顺序插入相同用户名的声明，则可以安全地声明操作成功。
这个知道什么时候你的总订单被完成的概念被记录在总订单广播的话题中。
这个知道什么时候你的总顺序被完成的概念被记录在总顺序广播的话题中。
### 全局序列广播
@ -463,13 +463,13 @@ Lamport时间戳有时会与版本向量混淆，我们在第184页上的“检
如前所述，单引导程序复制通过选择一个节点作为引导程序来确定操作的总顺序，并对引导程序上的单个CPU核心上的所有操作进行排序。接下来的挑战是如果吞吐量大于单个领导者可以处理的情况下如何扩展系统，以及如果领导者失败（参见第156页的“[处理节点宕机](#处理节点宕机)”），如何处理故障转移。在分布式系统文献中，这个问题被称为全序广播或原子广播[^ix]【25,57,58】。
[^ix]: “原子广播”这个术语是传统的，但是它是非常混乱的，因为它与原子的其他用法不一致：它与ACID事务中的原子性没有任何关系，只是与原子操作（在多线程编程的意义上 ）或原子寄存器（线性化存储）。 总的订单组播是另一个同义词。
[^ix]: “原子广播”这个术语是传统的，但是它是非常混乱的，因为它与原子的其他用法不一致：它与ACID事务中的原子性没有任何关系，只是与原子操作（在多线程编程的意义上 ）或原子寄存器（线性化存储）。 总的顺序组播是另一个同义词。
> #### 顺序保证的范围
>
> 每个分区有一个单独的引导程序的分区数据库通常只对每个分区进行排序，这意味着它们不能提供跨分区的一致性保证（例如，一致的快照，外键引用）。 所有分区的总排序是可能的，但需要额外的协调【59】。
总订单广播通常被描述为在节点之间交换消息的协议。 非正式地，它要求总是满足两个安全属性：
总顺序广播通常被描述为在节点之间交换消息的协议。 非正式地，它要求总是满足两个安全属性：
***可靠交付（reliable delivery）***
@ -479,30 +479,30 @@ Lamport时间戳有时会与版本向量混淆，我们在第184页上的“检
消息以相同的顺序传递给每个节点。
总订单广播的正确算法必须确保始终满足可靠性和订购属性，即使节点或网络出现故障。当然，在网络中断的时候，消息不会被传送，但是一个算法可以继续重试，以便在网络被最终修复的时候消息能够通过（然后它们仍然必须按照正确的顺序传送）。
总顺序广播的正确算法必须确保始终满足可靠性和订购属性，即使节点或网络出现故障。当然，在网络中断的时候，消息不会被传送，但是一个算法可以继续重试，以便在网络被最终修复的时候消息能够通过（然后它们仍然必须按照正确的顺序传送）。
#### 使用全序广播
像ZooKeeper和etcd这样的共识服务实际上是实现全面的订单播放。这个事实暗示了整个命令广播和共识之间有着密切的联系，我们将在本章后面进行探讨。
像ZooKeeper和etcd这样的共识服务实际上是实现全面的顺序播放。这个事实暗示了整个命令广播和共识之间有着密切的联系，我们将在本章后面进行探讨。
总订单广播正是您所需的数据库复制：如果每封邮件都表示写入数据库，并且每个副本按相同的顺序处理相同的写入，则副本将保持一致（除了临时复制滞后）。这个原则被称为状态机复制【60】，我们将在第11章中回到它。
类似地，可以使用总订单广播来实现可序列化的事务：如第242页上的“实际的串行执行”中所述，如果每个消息表示一个确定性事务作为存储过程来执行，并且每个节点都处理这些消息相同的顺序，那么数据库的分区和副本保持一致【61】。
总顺序广播正是您所需的数据库复制：如果每封邮件都表示写入数据库，并且每个副本按相同的顺序处理相同的写入，则副本将保持一致（除了临时复制滞后）。这个原则被称为状态机复制【60】，我们将在第11章中回到它。
类似地，可以使用总顺序广播来实现可序列化的事务：如第242页上的“实际的串行执行”中所述，如果每个消息表示一个确定性事务作为存储过程来执行，并且每个节点都处理这些消息相同的顺序，那么数据库的分区和副本保持一致【61】。
总订单广播的一个重要方面是订单在交付消息时是固定的：如果后续消息已经交付，节点不允许追溯地将消息插入订单中的较早位置。这个事实使得全部命令广播比时间戳命令更强。
总顺序广播的一个重要方面是顺序在交付消息时是固定的：如果后续消息已经交付，节点不允许追溯地将消息插入顺序中的较早位置。这个事实使得全部命令广播比时间戳命令更强。
查看总订单广播的另一种方式是创建日志（如在复制日志，事务日志或预写日志中）：传递消息就像附加到日志。由于所有节点必须以相同的顺序传递相同的消息，因此所有节点都可以读取日志并看到相同的消息序列。
查看总顺序广播的另一种方式是创建日志（如在复制日志，事务日志或预写日志中）：传递消息就像附加到日志。由于所有节点必须以相同的顺序传递相同的消息，因此所有节点都可以读取日志并看到相同的消息序列。
全面订购广播对于实施提供防护令牌的锁定服务也很有用（请参见第294页的“防护令牌”）。每个获取锁的请求都作为消息添加到日志中，并且所有消息都按它们在日志中出现的顺序依次编号。序列号可以作为一个击剑标记，因为它是单调递增的。在ZooKeeper中，这个序列号被称为`zxid` 【15】。
#### 使用全序广播实现线性化的存储
如图9-4所示，在可线性化的系统中，有一个操作的总顺序。这是否意味着线性化与总订单播放相同？不完全，但两者之间有密切的联系[^x]。
如图9-4所示，在可线性化的系统中，有一个操作的总顺序。这是否意味着线性化与总顺序播放相同？不完全，但两者之间有密切的联系[^x]。
[^x]: 从形式上讲，可线性读写寄存器是一个“更容易”的问题。 总订单广播等同于共识【67】，在异步崩溃停止模型【68】中没有确定性的解决方案，而可线性化的读写寄存器可以在同一系统模型中实现【23,24,25】。 然而，支持原子操作，如比较和设置，或者在寄存器中增加和获取，使得它相当于共识【28】。 因此，共识问题和可线性化的注册问题密切相关。
[^x]: 从形式上讲，可线性读写寄存器是一个“更容易”的问题。 总顺序广播等同于共识【67】，在异步崩溃停止模型【68】中没有确定性的解决方案，而可线性化的读写寄存器可以在同一系统模型中实现【23,24,25】。 然而，支持原子操作，如比较和设置，或者在寄存器中增加和获取，使得它相当于共识【28】。 因此，共识问题和可线性化的注册问题密切相关。
全部订单广播是异步的：消息被保证以固定的顺序可靠地传送，但是不能保证消息何时被传送（所以一个接收者可能落后于其他接收者）。相比之下，线性化是最近的保证：读取保证看到写入的最新值。
全部顺序广播是异步的：消息被保证以固定的顺序可靠地传送，但是不能保证消息何时被传送（所以一个接收者可能落后于其他接收者）。相比之下，线性化是最近的保证：读取保证看到写入的最新值。
但是，如果您有全面的订单广播，则可以在其上构建线性化存储。例如，您可以确保用户名唯一标识用户帐户。
但是，如果您有全面的顺序广播，则可以在其上构建线性化存储。例如，您可以确保用户名唯一标识用户帐户。
想象一下，对于每一个可能的用户名，你都可以拥有一个带有原子比较和设置操作的线性化寄存器。每个寄存器最初的值为空值（表示不使用用户名）。当用户想要创建一个用户名时，对该用户名的注册表执行比较设置操作，在前一个注册值为空的情况下，将其设置为用户账号。如果多个用户试图同时获取相同的用户名，则只有一个比较和设置操作会成功，因为其他用户将看到非空值（由于线性化）。
@ -522,17 +522,17 @@ Lamport时间戳有时会与版本向量混淆，我们在第184页上的“检
* 如果日志允许以线性方式获取最新日志消息的位置，则可以查询该位置，等待直到该位置的所有条目传送给您，然后执行读取。 （这是Zookeeper的`sync()`操作背后的思想【15】）。
* 您可以从写入时同步更新的副本进行读取，因此可以确保最新。 （这种技术用于链式复制【63】;另请参阅第155页上的“复制研究”。）
#### 使用线性化存储实现总订单广播
#### 使用线性化存储实现总顺序广播
最后一节介绍了如何从全部命令广播中构建一个线性化的比较和设置操作。我们也可以把它转过来，假设我们有可线性化的存储，并展示如何从它构建全部命令播放。
最简单的方法是假设你有一个线性化的寄存器来存储一个整数，并且有一个原子增量和获取操作【28】。或者，原子比较和设置操作也可以完成这项工作。
该算法很简单：对于每个要通过全部订单广播发送的消息，您将递增并获取可线性化的整数，然后将从寄存器获得的值作为序号附加到消息中。然后，您可以将消息发送到所有节点（重新发送任何丢失的消息），并且收件人将按序号连续发送消息。
该算法很简单：对于每个要通过全部顺序广播发送的消息，您将递增并获取可线性化的整数，然后将从寄存器获得的值作为序号附加到消息中。然后，您可以将消息发送到所有节点（重新发送任何丢失的消息），并且收件人将按序号连续发送消息。
请注意，与Lamport时间戳不同，您通过递增可线性化寄存器获得的数字形成一个没有间隙的序列。因此，如果一个节点已经发送了消息4并且接收到序列号为6的传入消息，则它知道它在传递消息6之前必须等待消息5.同样的情况并非如此
与Lamport时间戳 - 事实上，这是总订单广播和时间戳订购之间的关键区别。
与Lamport时间戳 - 事实上，这是总顺序广播和时间戳订购之间的关键区别。
使用原子增量和获取操作来创建线性化整数有多困难？像往常一样，如果事情从来没有失败过，那很容易：你可以把它保存在一个节点的变量中。问题在于处理当该节点的网络连接中断时的情况，并在该节点失败时恢复该值【59】。一般来说，如果你对可线性化序列号的产生者认真思考，你不可避免地会得出一个一致的算法。
@ -646,7 +646,7 @@ Lamport时间戳有时会与版本向量混淆，我们在第184页上的“检
如果协调员在发送准备请求之前失败，参与者可以安全地中止交易。但是，一旦参与者收到了准备请求并投了“是”，就不能再单方面放弃 - 必须等待协调者回答交易是否已经发生或中止。如果此时协调器崩溃或网络出现故障，参与者只能等待。参与者在这个状态下的交易被怀疑或不确定。
情况如图9-10所示。在这个特定的例子中，协调器实际上决定提交，数据库2收到提交请求。但是，协调器在将提交请求发送到数据库1之前发生崩溃，因此数据库1不知道是否提交或中止。即使超时在这里也没有帮助：如果数据库1在超时后单方面中止，它将最终与提交的数据库2不一致。同样，单方面犯也是不安全的，因为另一个参与者可能已经中止了。
情况如[图9-10](img/fig9-10)所示。在这个特定的例子中，协调器实际上决定提交，数据库2收到提交请求。但是，协调器在将提交请求发送到数据库1之前发生崩溃，因此数据库1不知道是否提交或中止。即使超时在这里也没有帮助：如果数据库1在超时后单方面中止，它将最终与提交的数据库2不一致。同样，单方面犯也是不安全的，因为另一个参与者可能已经中止了。
![](img/fig9-10.png)
 **图9-10 参与者投赞成票后，协调员崩溃。数据库1不知道是否提交或中止**
@ -708,9 +708,9 @@ XA假定您的应用程序使用网络驱动程序或客户端库来与参与者
#### 怀疑时持有锁
为什么我们非常关心交易被怀疑？系统的其他部分不能继续工作，而忽视最终将被清理的有问题的交易吗？
问题在于锁定。正如在第225页上的“读取已提交”中所讨论的那样，数据库事务通常对其修改的行进行行级别的排他锁定，以防止脏写入。此外，如果要使用可序列化的隔离，则使用两阶段锁定的数据库也必须对事务读取的任何行执行共享锁定（请参见“双相锁定（2PL）”（第249页））。
问题在于锁定。正如在第225页上的“读取已提交”中所讨论的那样，数据库事务通常对其修改的行进行行级别的排他锁定，以防止脏写入。此外，如果要使用可序列化的隔离，则使用两阶段锁定的数据库也必须对事务读取的任何行执行共享锁定（参见“[两阶段锁定（2PL）](ch7.md#两阶段锁定（2PL）)”）。
在事务提交或中止之前，数据库不能释放这些锁（如图9-9中的阴影区域所示）。因此，在使用两阶段提交时，交易必须在整个时间内保持锁定状态。如果协调员已经坠毁，需要20分钟才能重新启动，这些锁将会保持20分钟。如果协调员的日志由于某种原因完全丢失，这些锁将永久保存，或者至少在管理员手动解决该情况之前。
在事务提交或中止之前，数据库不能释放这些锁（如[图9-9](img/fig9-9.png)中的阴影区域所示）。因此，在使用两阶段提交时，交易必须在整个时间内保持锁定状态。如果协调员已经坠毁，需要20分钟才能重新启动，这些锁将会保持20分钟。如果协调员的日志由于某种原因完全丢失，这些锁将永久保存，或者至少在管理员手动解决该情况之前。
当这些锁被保留时，其他事务不能修改这些行。根据数据库的不同，其他事务甚至可能被阻止读取这些行。因此，其他交易不能简单地继续他们的业务 - 如果他们想访问相同的数据，他们将被阻止。这可能会导致大部分应用程序变得不可用，直到有问题的事务得到解决。
@ -774,15 +774,15 @@ XA事务解决了保持多个参与者数据系统一致的真实而重要的问
大多数一致性算法假定没有拜占庭式的错误，正如在“拜占庭式故障”一节中所讨论的那样。也就是说，如果一个节点没有正确地遵循协议（例如，如果它发送矛盾的消息到不同的节点），它可能会破坏协议的安全属性。只要少于三分之一的节点是拜占庭故障【25,93】，就可以对拜占庭故障形成共识，但我们没有空间在本书中详细讨论这些算法。
#### 共识算法和总订单广播
#### 共识算法和总顺序广播
最着名的容错一致性算法是**视图戳复制（viewstamped replication）**（VSR）【94,95】，Paxos 【96,97,98,99】，Raft 【22,100,101】和Zab 【15,21,102】 。这些算法之间有相当多的相似之处，但它们并不相同【103】。在本书中，我们不会详细介绍不同的算法：除非你自己实现一个共识系统（这可能不是一个明智的做法），只要了解一些共同的高级思想就足够了这很难【98,104】）。
这些算法中的大多数实际上并不直接使用这里描述的形式化模型（建议和决定单个值，同时满足协议，完整性，有效性和终止性质）。相反，他们决定了一系列的值，这使得他们成为了订单广播算法，正如本章前面所讨论的那样（请参阅第348页上的“全部订单广播”）。
这些算法中的大多数实际上并不直接使用这里描述的形式化模型（建议和决定单个值，同时满足协议，完整性，有效性和终止性质）。相反，他们决定了一系列的值，这使得他们成为了顺序广播算法，正如本章前面所讨论的那样（请参阅第348页上的“全部顺序广播”）。
请记住，总订单广播要求将消息按照相同的顺序准确传送到所有节点。如果你仔细想想，这相当于进行了几轮的共识：在每一轮中，节点提出下一个要发送的消息，然后决定下一个要发送的消息总数【67】。
请记住，总顺序广播要求将消息按照相同的顺序准确传送到所有节点。如果你仔细想想，这相当于进行了几轮的共识：在每一轮中，节点提出下一个要发送的消息，然后决定下一个要发送的消息总数【67】。
所以，总的订单广播相当于重复的一轮共识（每个共同的决定对应于一个消息传递）：
所以，总的顺序广播相当于重复的一轮共识（每个共同的决定对应于一个消息传递）：
* 由于协商一致意见，所有节点决定以相同的顺序传递相同的消息。
@ -914,7 +914,7 @@ ZooKeeper和朋友们可以看作是成员服务研究的悠久历史的一部
数据库必须决定是否提交或中止分布式事务。
***全部订单广播***
***全部顺序广播***
消息传递系统必须决定传递消息的顺序。

11
ddia/part-i.md
View File

@ -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) |

83
ddia/part-ii.md
View File

@ -1,80 +1,73 @@
# 第二部分： 分布式数据
> 一个成功的技术，可行性的优先级必须高于PR，你可以糊弄别人，但糊弄不了自然规律。
> 一个成功的技术，现实的优先级必须高于公关，你可以糊弄别人，但糊弄不了自然规律。
>
> ——罗杰斯委员会报告（1986）
>
-------
在本书的第一部分中，我们讨论了数据存储在一台机器上数据系统的方方面面。现在到了第二部分中，我们提一个更高级的问题：如果**多台机器**参与数据的存储和检索会发生什么？
将数据库分布到多台机器上可能会有很多原因：
在本书的[第一部分](part-i.md)中，我们讨论了数据系统的各个方面，但仅限于数据存储在单台机器上的情况。现在我们到了[第二部分](part-ii.md)，进入更高的层次，并提出一个问题：如果**多台机器**参与数据的存储和检索，会发生什么？
你可能会出于各种各样的原因，希望将数据库分布到多台机器上：
***可扩展性***
如果您的数据量读取负载/写入负载比单台计算机可以处理的还要大，则可以将负载分散到多台计算机上。
如果你的数据量、读取负载、写入负载超出单台机器的处理能力，可以将负载分散到多台计算机上。
***容错/高可用性***
如果即使一台机器（或多台机器，网络或整个数据中心）出现故障，您的应用程序仍然需要继续工作，您可以使用多台机器来提供冗余。当一台故障时，另一台可以接管。
如果你的应用需要在单台机器（或多台机器，网络或整个数据中心）出现故障的情况下仍然能继续工作，则可使用多台机器，以提供冗余。一台故障时，另一台可以接管。
***延迟***
如果在世界各地都有用户，也许你会考虑在全球多处部署服务器，既而每个用户从地理上相近的数据中心获取服务，以免用户需要等待网络数据包穿越半个世界。
如果在世界各地都有用户，你也许会考虑在全球范围部署多个服务器，从而每个用户可以从地理上最近的数据中心获取服务，避免了等待网络数据包穿越半个世界。
### 扩展到更高的负载
### 扩展至更高的载荷
如果只是需要扩展到支持更高的负载，最简单的方法就是购买更强大的机器（有时称为垂直扩展 vertical scaling或scaling up）。许多CPU、RAM芯片和磁盘可以在一个操作系统内相互连接，快速互连允许任何CPU访问存储器或磁盘的任何部分。在这种共享内存架构中，所有的组件都可以看作是一台单独的机器（在大型机中，尽管任何CPU都可以访问内存的任何部分，但是总有一些内存区域与一些CPU更接近[^i]。 为了有效地利用这种架构特性，需要对处理进行细分，以便每个CPU主要访问临近的内存，这意味着底层仍然进行了分区，即使表面上看起来只有一台机器在运行）
如果你需要的只是扩展至更高的**载荷（load）**，最简单的方法就是购买更强大的机器（有时称为**垂直扩展（vertical scaling）**或**向上扩展（scale up）**）。许多处理器，内存和磁盘可以在同一个操作系统下相互连接，快速的相互连接允许任意处理器访问内存或磁盘的任意部分。在这种**共享内存架构（shared-memory architecture）**中，所有的组件都可以看作一台单独的机器。
[^i]: 称为非均匀内存访问 nonuniform memory access，或者NUMA
[^i]: 在大型机中，尽管任意处理器都可以访问内存的任意部分，但总有一些内存区域与一些处理器更接近（称为**非均匀内存访问（nonuniform memory access, NUMA）**【1】）。 为了有效利用这种架构特性，需要对处理进行细分，以便每个处理器主要访问临近的内存，这意味着即使表面上看起来只有一台机器在运行，**分区（partitioning）**仍然是必要的。
共享内存方法的问题在于，开销的增长速度快于线性增长：一台机器的CPU数量翻倍，内存大小也翻倍，磁盘大小翻倍，但成本通常多的可不止一倍。而且由于瓶颈存在，一台双倍规格机器不一定能处理双倍的负载。
共享内存方法的问题在于，成本增长速度快于线性增长：一台有着双倍处理器数量，双倍内存大小，双倍磁盘容量的机器，通常成本会远远超过原来的两倍。而且可能因为存在瓶颈，并不足以处理双倍的载荷。
共享内存体系结构可以提供有限的容错能力，相比之下，使用高端机器虽然具有热插拔组件（可以不关机更换磁盘，内存模块，甚至CPU），但是它必然局限于单个地理位置。
共享内存架构可以提供有限的容错能力，高端机器可以使用热插拔的组件（不关机更换磁盘，内存模块，甚至处理器）——但它必然囿于单个地理位置的桎梏。
另一种方法是**共享磁盘架构**，它使用多台具有独立CPU和RAM的机器，但将数据存储在机器之间共享的磁盘阵列上，这些磁盘通过快速网络连接（Network Attached Storage, Storage Area Network）。此架构用于某些数据仓储，但竞争和锁定的开销限制了共享磁盘方法的可扩展性[2]。
另一种方法是**共享磁盘架构（shared-disk architecture）**，它使用多台具有独立处理器和内存的机器，但将数据存储在机器之间共享的磁盘阵列上，这些磁盘通过快速网络连接[^ii]。这种架构用于某些数据仓库，但竞争和锁定的开销限制了共享磁盘方法的可扩展性【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)
​ 将一个大型数据库拆分成较小的子集（称为**分区（partitions）**），从而不同的分区可以指派给不同的**节点（node）**（亦称**分片（shard）**）。 [第六章](ch6.md)将讨论分区。
将大型数据库拆分成称为分区的较小子集，以便不同的分区可以指派:给不同的节点（也称为分片 sharding）。
[第六章](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)
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) |

32
ddia/part-iii.md
View File

@ -1,10 +1,10 @@
# 第三部分：衍生数据
本书的第一部分和第二部分，自底向上把所有关于分布式数据库的主要考量都讲了一遍。从数据在磁盘上的布局，一直到故障时关于分布式系统一致性的局限性。但所有的讨论都假定了应用程序中只用了一种数据库。
在本书的[第一部分](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) |

39
ddia/preface.md
View File

@ -1,19 +1,19 @@
# 序
如果您近几年从业于软件工程领域，特别是服务器端和后端开发，那么您很可能已经被大量关于数据存储和处理的时髦词汇轰炸过了： 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广告
## O‘Reilly Safari
blah blah 不想翻
[Safari](http://oreilly.com/safari)赛高！