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

fix several punctuation marks, update zh-tw content

Browse Source
This commit is contained in:
Gang Yin 2021-08-29 18:46:25 +08:00
parent 65e28c45e8
commit f240158a3c
6 changed files with 67 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
ch1.md
View File

@ -56,23 +56,19 @@
***可靠性（Reliability）***
​ 系统在**困境（adversity）**（硬件故障、软件故障、人为错误）中仍可正常工作（正确完成功能，并能达到期望的性能水准）。
​ 系统在**困境（adversity）**（硬件故障、软件故障、人为错误）中仍可正常工作（正确完成功能，并能达到期望的性能水准）。请参阅“[可靠性](#可靠性)”。
***可伸缩性（Scalability）***
​ 有合理的办法应对系统的增长（数据量、流量、复杂性）（请参阅“[可伸缩性](#可伸缩性)”）
​ 有合理的办法应对系统的增长（数据量、流量、复杂性）。请参阅“[可伸缩性](#可伸缩性)”。
***可维护性（Maintainability）***
​ 许多不同的人（工程师、运维）在不同的生命周期，都能高效地在系统上工作（使系统保持现有行为，并适应新的应用场景）。（请参阅”[可维护性](#可维护性)“）
​ 许多不同的人（工程师、运维）在不同的生命周期，都能高效地在系统上工作（使系统保持现有行为，并适应新的应用场景）。请参阅“[可维护性](#可维护性)”。
​ 人们经常追求这些词汇，却没有清楚理解它们到底意味着什么。为了工程的严谨性，本章的剩余部分将探讨可靠性、可伸缩性、可维护性的含义。为实现这些目标而使用的各种技术，架构和算法将在后续的章节中研究。
## 可靠性
人们对于一个东西是否可靠，都有一个直观的想法。人们对可靠软件的典型期望包括：

6
ch7.md
View File

@ -590,11 +590,11 @@ COMMIT;
**可串行化（Serializability）**隔离通常被认为是最强的隔离级别。它保证即使事务可以并行执行，最终的结果也是一样的，就好像它们没有任何并发性，连续挨个执行一样。因此数据库保证，如果事务在单独运行时正常运行，则它们在并发运行时继续保持正确 —— 换句话说，数据库可以防止**所有**可能的竞争条件。
但如果可串行化隔离级别比弱隔离级别的烂摊子要好得多，那为什么没有人见人爱？为了回答这个问题，我们需要看看实现可串行化的选项，以及它们如何执行。目前大多数提供可串行化的数据库都使用了三种技术之一，本章的剩余部分将会介绍这些技术。
但如果可串行化隔离级别比弱隔离级别的烂摊子要好得多，那为什么没有人见人爱？为了回答这个问题，我们需要看看实现可串行化的选项，以及它们如何执行。目前大多数提供可串行化的数据库都使用了三种技术之一，本章的剩余部分将会介绍这些技术：
- 字面意义上地串行顺序执行事务（请参阅“[真的串行执行](#真的串行执行)”）
- **两阶段锁定（2PL, two-phase locking）**，几十年来唯一可行的选择。（请参阅“[两阶段锁定](#两阶段锁定)”）
- 乐观并发控制技术，例如**可串行化快照隔离（serializable snapshot isolation）**（请参阅“[可串行化快照隔离](#可串行化快照隔离)”
- **两阶段锁定（2PL, two-phase locking）**，几十年来唯一可行的选择（请参阅“[两阶段锁定](#两阶段锁定)”）
- 乐观并发控制技术，例如**可串行化快照隔离（serializable snapshot isolation）**（请参阅“[可串行化快照隔离](#可串行化快照隔离)”）
现在将主要在单节点数据库的背景下讨论这些技术；在[第九章](ch9.md)中，我们将研究如何将它们推广到涉及分布式系统中多个节点的事务。

54
zh-tw/SUMMARY.md
View File

@ -4,19 +4,73 @@
* [序言](preface.md)
* [第一部分：資料系統的基石](part-i.md)
* [第一章：可靠性、可伸縮性、可維護性](ch1.md)
* [關於資料系統的思考](ch1.md#關於資料系統的思考)
* [可靠性](ch1.md#可靠性)
* [可伸縮性](ch1.md#可伸縮性)
* [可維護性](ch1.md#可維護性)
* [本章小結](ch1.md#本章小結)
* [第二章：資料模型與查詢語言](ch2.md)
* [關係模型與文件模型](ch2.md#關係模型與文件模型)
* [資料查詢語言](ch2.md#資料查詢語言)
* [圖資料模型](ch2.md#圖資料模型)
* [本章小結](ch2.md#本章小結)
* [第三章：儲存與檢索](ch3.md)
* [驅動資料庫的資料結構](ch3.md#驅動資料庫的資料結構)
* [事務處理還是分析？](ch3.md#事務處理還是分析？)
* [列儲存](ch3.md#列儲存)
* [本章小結](ch3.md#本章小結)
* [第四章：編碼與演化](ch4.md)
* [編碼資料的格式](ch4.md#編碼資料的格式)
* [資料流的型別](ch4.md#資料流的型別)
* [本章小結](ch4.md#本章小結)
* [第二部分：分散式資料](part-ii.md)
* [第五章：複製](ch5.md)
* [領導者與追隨者](ch5.md#領導者與追隨者)
* [複製延遲問題](ch5.md#複製延遲問題)
* [多主複製](ch5.md#多主複製)
* [無主複製](ch5.md#無主複製)
* [本章小結](ch5.md#本章小結)
* [第六章：分割槽](ch6.md)
* [分割槽與複製](ch6.md#分割槽與複製)
* [鍵值資料的分割槽](ch6.md#鍵值資料的分割槽)
* [分割槽與次級索引](ch6.md#分割槽與次級索引)
* [分割槽再平衡](ch6.md#分割槽再平衡)
* [請求路由](ch6.md#請求路由)
* [本章小結](ch6.md#本章小結)
* [第七章：事務](ch7.md)
* [事務的棘手概念](ch7.md#事務的棘手概念)
* [弱隔離級別](ch7.md#弱隔離級別)
* [可序列化](ch7.md#可序列化)
* [本章小結](ch7.md#本章小結)
* [第八章：分散式系統的麻煩](ch8.md)
* [故障與部分失效](ch8.md#故障與部分失效)
* [不可靠的網路](ch8.md#不可靠的網路)
* [不可靠的時鐘](ch8.md#不可靠的時鐘)
* [知識、真相與謊言](ch8.md#知識、真相與謊言)
* [本章小結](ch8.md#本章小結)
* [第九章：一致性與共識](ch9.md)
* [一致性保證](ch9.md#一致性保證)
* [線性一致性](ch9.md#線性一致性)
* [順序保證](ch9.md#順序保證)
* [分散式事務與共識](ch9.md#分散式事務與共識)
* [本章小結](ch9.md#本章小結)
* [第三部分：衍生資料](part-iii.md)
* [第十章：批處理](ch10.md)
* [使用Unix工具的批處理](ch10.md#使用Unix工具的批處理)
* [MapReduce和分散式檔案系統](ch10.md#MapReduce和分散式檔案系統)
* [MapReduce之後](ch10.md#MapReduce之後)
* [本章小結](ch10.md#本章小結)
* [第十一章：流處理](ch11.md)
* [傳遞事件流](ch11.md#傳遞事件流)
* [資料庫與流](ch11.md#資料庫與流)
* [流處理](ch11.md#流處理)
* [本章小結](ch11.md#本章小結)
* [第十二章：資料系統的未來](ch12.md)
* [資料整合](ch12.md#資料整合)
* [分拆資料庫](ch12.md#分拆資料庫)
* [將事情做正確](ch12.md#將事情做正確)
* [做正確的事情](ch12.md#做正確的事情)
* [本章小結](ch12.md#本章小結)
* [術語表](glossary.md)
* [後記](colophon.md)

10
zh-tw/ch1.md
View File

@ -56,23 +56,19 @@
***可靠性（Reliability）***
​ 系統在**困境（adversity）**（硬體故障、軟體故障、人為錯誤）中仍可正常工作（正確完成功能，並能達到期望的效能水準）。
​ 系統在**困境（adversity）**（硬體故障、軟體故障、人為錯誤）中仍可正常工作（正確完成功能，並能達到期望的效能水準）。請參閱“[可靠性](#可靠性)”。
***可伸縮性（Scalability）***
​ 有合理的辦法應對系統的增長（資料量、流量、複雜性）（請參閱“[可伸縮性](#可伸縮性)”）
​ 有合理的辦法應對系統的增長（資料量、流量、複雜性）。請參閱“[可伸縮性](#可伸縮性)”。
***可維護性（Maintainability）***
​ 許多不同的人（工程師、運維）在不同的生命週期，都能高效地在系統上工作（使系統保持現有行為，並適應新的應用場景）。（請參閱”[可維護性](#可維護性)“）
​ 許多不同的人（工程師、運維）在不同的生命週期，都能高效地在系統上工作（使系統保持現有行為，並適應新的應用場景）。請參閱“[可維護性](#可維護性)”。
​ 人們經常追求這些詞彙，卻沒有清楚理解它們到底意味著什麼。為了工程的嚴謹性，本章的剩餘部分將探討可靠性、可伸縮性、可維護性的含義。為實現這些目標而使用的各種技術，架構和演算法將在後續的章節中研究。
## 可靠性
人們對於一個東西是否可靠，都有一個直觀的想法。人們對可靠軟體的典型期望包括：

2
zh-tw/ch10.md
View File

@ -562,7 +562,7 @@ top5.each{|count, url| puts "#{count} #{url}" } # 5
​ 由於它們將工作流顯式建模為資料從幾個處理階段穿過，所以這些系統被稱為**資料流引擎（dataflow engines）**。像MapReduce一樣，它們在一條線上透過反覆呼叫使用者定義的函式來一次處理一條記錄，它們透過輸入分割槽來並行化載荷，它們透過網路將一個函式的輸出複製到另一個函式的輸入。
​ 與MapReduce不同，這些功能不需要嚴格扮演交織的Map與Reduce的角色，而是可以以更靈活的方式進行組合。我們稱這些函式為**運算元（operators）**，資料流引擎提供了幾種不同的選項來將一個運算元的輸出連線到另一個運算元的輸入：
​ 與MapReduce不同，這些函式不需要嚴格扮演交織的Map與Reduce的角色，而是可以以更靈活的方式進行組合。我們稱這些函式為**運算元（operators）**，資料流引擎提供了幾種不同的選項來將一個運算元的輸出連線到另一個運算元的輸入：
- 一種選項是對記錄按鍵重新分割槽並排序，就像在MapReduce的混洗階段一樣（請參閱“[分散式執行MapReduce](#分散式執行MapReduce)”）。這種功能可以用於實現排序合併連線和分組，就像在MapReduce中一樣。
- 另一種可能是接受多個輸入，並以相同的方式進行分割槽，但跳過排序。當記錄的分割槽重要但順序無關緊要時，這省去了分割槽雜湊連線的工作，因為構建散列表還是會把順序隨機打亂。

6
zh-tw/ch7.md
View File

@ -590,11 +590,11 @@ COMMIT;
**可序列化（Serializability）**隔離通常被認為是最強的隔離級別。它保證即使事務可以並行執行，最終的結果也是一樣的，就好像它們沒有任何併發性，連續挨個執行一樣。因此資料庫保證，如果事務在單獨執行時正常執行，則它們在併發執行時繼續保持正確 —— 換句話說，資料庫可以防止**所有**可能的競爭條件。
但如果可序列化隔離級別比弱隔離級別的爛攤子要好得多，那為什麼沒有人見人愛？為了回答這個問題，我們需要看看實現可序列化的選項，以及它們如何執行。目前大多數提供可序列化的資料庫都使用了三種技術之一，本章的剩餘部分將會介紹這些技術。
但如果可序列化隔離級別比弱隔離級別的爛攤子要好得多，那為什麼沒有人見人愛？為了回答這個問題，我們需要看看實現可序列化的選項，以及它們如何執行。目前大多數提供可序列化的資料庫都使用了三種技術之一，本章的剩餘部分將會介紹這些技術：
- 字面意義上地序列順序執行事務（請參閱“[真的序列執行](#真的序列執行)”）
- **兩階段鎖定（2PL, two-phase locking）**，幾十年來唯一可行的選擇。（請參閱“[兩階段鎖定](#兩階段鎖定)”）
- 樂觀併發控制技術，例如**可序列化快照隔離（serializable snapshot isolation）**（請參閱“[可序列化快照隔離](#可序列化快照隔離)”
- **兩階段鎖定（2PL, two-phase locking）**，幾十年來唯一可行的選擇（請參閱“[兩階段鎖定](#兩階段鎖定)”）
- 樂觀併發控制技術，例如**可序列化快照隔離（serializable snapshot isolation）**（請參閱“[可序列化快照隔離](#可序列化快照隔離)”）
現在將主要在單節點資料庫的背景下討論這些技術；在[第九章](ch9.md)中，我們將研究如何將它們推廣到涉及分散式系統中多個節點的事務。