Merge pull request #367 from yhao3/main

Fix typo, formatting and punctuation

Author: yingang

content/tw/ch11.md

@@ -461,7 +461,7 @@ MapReduce 作業的輸出處理遵循同樣的原理。透過將輸入視為不
 
 ### Hadoop與分散式資料庫的對比
 
-正如我們所看到的，Hadoop 有點像 Unix 的分散式版本，其中 HDFS 是檔案系統，而 MapReduce 是 Unix 程序的怪異實現（總是在 Map 階段和 Reduce 階段執行 `sort` 工具）。我們瞭解瞭如何在這些原語的基礎上實現各種連線和分組操作。
+正如我們所看到的，Hadoop 有點像 Unix 的分散式版本，其中 HDFS 是檔案系統，而 MapReduce 是 Unix 程序的怪異實現（總是在 Map 階段和 Reduce 階段執行 `sort` 工具）。我們瞭解了如何在這些原語的基礎上實現各種連線和分組操作。
 
 當 MapReduce 論文發表時【1】，它從某種意義上來說 —— 並不新鮮。我們在前幾節中討論的所有處理和並行連線演算法已經在十多年前所謂的 **大規模並行處理（MPP，massively parallel processing）** 資料庫中實現了【3,40】。比如 Gamma database machine、Teradata 和 Tandem NonStop SQL 就是這方面的先驅【52】。
 
@@ -477,7 +477,7 @@ MapReduce 作業的輸出處理遵循同樣的原理。透過將輸入視為不
 
 這個想法與資料倉庫類似（請參閱 “[資料倉庫](/tw/ch3#資料倉庫)”）：將大型組織的各個部分的資料集中在一起是很有價值的，因為它可以跨越以前相互分離的資料集進行連線。MPP 資料庫所要求的謹慎模式設計拖慢了集中式資料收集速度；以原始形式收集資料，稍後再操心模式的設計，能使資料收集速度加快（有時被稱為 “**資料湖（data lake）**” 或 “**企業資料中心（enterprise data hub）**”【55】）。
 
-不加區分的資料轉儲轉移瞭解釋資料的負擔：資料集的生產者不再需要強制將其轉化為標準格式，資料的解釋成為消費者的問題（**讀時模式** 方法【56】；請參閱 “[文件模型中的模式靈活性](/tw/ch2#文件模型中的模式靈活性)”）。如果生產者和消費者是不同優先順序的不同團隊，這可能是一種優勢。甚至可能不存在一個理想的資料模型，對於不同目的有不同的合適視角。以原始形式簡單地轉儲資料，可以允許多種這樣的轉換。這種方法被稱為 **壽司原則（sushi principle）**：“原始資料更好”【57】。
+不加區分的資料轉儲轉移了解釋資料的負擔：資料集的生產者不再需要強制將其轉化為標準格式，資料的解釋成為消費者的問題（**讀時模式** 方法【56】；請參閱 “[文件模型中的模式靈活性](/tw/ch2#文件模型中的模式靈活性)”）。如果生產者和消費者是不同優先順序的不同團隊，這可能是一種優勢。甚至可能不存在一個理想的資料模型，對於不同目的有不同的合適視角。以原始形式簡單地轉儲資料，可以允許多種這樣的轉換。這種方法被稱為 **壽司原則（sushi principle）**：“原始資料更好”【57】。
 
 因此，Hadoop 經常被用於實現 ETL 過程（請參閱 “[資料倉庫](/tw/ch3#資料倉庫)”）：事務處理系統中的資料以某種原始形式轉儲到分散式檔案系統中，然後編寫 MapReduce 作業來清理資料，將其轉換為關係形式，並將其匯入 MPP 資料倉庫以進行分析。資料建模仍然在進行，但它在一個單獨的步驟中進行，與資料收集相解耦。這種解耦是可行的，因為分散式檔案系統支援以任何格式編碼的資料。
 

content/tw/ch13.md

@@ -48,7 +48,7 @@ breadcrumbs: false
 
 例如，你可能會首先將資料寫入 **記錄系統** 資料庫，捕獲對該資料庫所做的變更（請參閱 “[變更資料捕獲](/tw/ch12#變更資料捕獲)”），然後將變更以相同的順序應用於搜尋索引。如果變更資料捕獲（CDC）是更新索引的唯一方式，則可以確定該索引完全派生自記錄系統，因此與其保持一致（除軟體錯誤外）。寫入資料庫是向該系統提供新輸入的唯一方式。
 
-允許應用程式直接寫入搜尋索引和資料庫引入瞭如 [圖 11-4](/fig/ddia_1204.png) 所示的問題，其中兩個客戶端同時傳送衝突的寫入，且兩個儲存系統按不同順序處理它們。在這種情況下，既不是資料庫說了算，也不是搜尋索引說了算，所以它們做出了相反的決定，進入彼此間永續性的不一致狀態。
+允許應用程式直接寫入搜尋索引和資料庫引入了如 [圖 11-4](/fig/ddia_1204.png) 所示的問題，其中兩個客戶端同時傳送衝突的寫入，且兩個儲存系統按不同順序處理它們。在這種情況下，既不是資料庫說了算，也不是搜尋索引說了算，所以它們做出了相反的決定，進入彼此間永續性的不一致狀態。
 
 如果你可以透過單個系統來提供所有使用者輸入，從而決定所有寫入的排序，則透過按相同順序處理寫入，可以更容易地派生出其他資料表示。這是狀態機複製方法的一個應用，我們在 “[全序廣播](/tw/ch9#全序廣播)” 中看到。無論你使用變更資料捕獲還是事件溯源日誌，都不如簡單的基於全序的決策原則更重要。
 
@@ -181,7 +181,7 @@ Unix 和關係資料庫以非常不同的哲學來處理資訊管理問題。Uni
 * 複製日誌，保持其他節點上資料的副本最新（請參閱 “[複製日誌的實現](/tw/ch5#複製日誌的實現)”）
 * 全文檢索索引，允許在文字中進行關鍵字搜尋（請參閱 “[全文檢索與模糊索引](/tw/ch3#全文檢索與模糊索引)”），也內置於某些關係資料庫【1】
 
-在 [第十一章](/tw/ch11) 和 [第十二章](/tw/ch12) 中，出現了類似的主題。我們討論了如何構建全文檢索索引（請參閱 “[批處理工作流的輸出](/tw/ch11#批處理工作流的輸出)”），瞭解瞭如何維護物化檢視（請參閱 “[維護物化檢視](/tw/ch12#維護物化檢視)”）以及如何將變更從資料庫複製到派生資料系統（請參閱 “[變更資料捕獲](/tw/ch12#變更資料捕獲)”）。
+在 [第十一章](/tw/ch11) 和 [第十二章](/tw/ch12) 中，出現了類似的主題。我們討論了如何構建全文檢索索引（請參閱 “[批處理工作流的輸出](/tw/ch11#批處理工作流的輸出)”），瞭解了如何維護物化檢視（請參閱 “[維護物化檢視](/tw/ch12#維護物化檢視)”）以及如何將變更從資料庫複製到派生資料系統（請參閱 “[變更資料捕獲](/tw/ch12#變更資料捕獲)”）。
 
 資料庫中內建的功能與人們用批處理和流處理器構建的派生資料系統似乎有相似之處。
 

content/tw/ch3.md

@@ -17,7 +17,7 @@ breadcrumbs: false
 1. 作為應用程式開發者，你觀察現實世界（其中有人員、組織、貨物、行為、資金流動、感測器等），並用物件或資料結構，以及操作這些資料結構的 API 來建模。這些結構通常是特定於應用程式的。
 2. 當你想要儲存這些資料結構時，你用通用的資料模型來表達它們，例如 JSON 或 XML 文件、關係資料庫中的表，或者圖中的頂點和邊。這些資料模型是本章的主題。
 3. 構建你的資料庫軟體的工程師決定了如何用記憶體、磁碟或網路上的位元組來表示文件/關係/圖資料。這種表示可能允許以各種方式查詢、搜尋、操作和處理資料。我們將在 [第 4 章](/tw/ch4#ch_storage) 中討論這些儲存引擎的設計。
-4. 在更低的層次上，硬體工程師已經想出瞭如何用電流、光脈衝、磁場等來表示位元組的方法。
+4. 在更低的層次上，硬體工程師已經想出了如何用電流、光脈衝、磁場等來表示位元組的方法。
 
 在複雜的應用程式中可能有更多的中間層，例如基於 API 之上的 API，但基本思想仍然相同：每一層透過提供一個簡潔的資料模型來隱藏下層的複雜性。這些抽象允許不同的人群 —— 例如，資料庫供應商的工程師和使用他們資料庫的應用程式開發者 —— 有效地合作。
 
@@ -499,7 +499,7 @@ CREATE
 
 當 [圖 3-6](/tw/ch3#fig_datamodels_graph) 的所有頂點和邊都新增到資料庫後，我們可以開始提出有趣的問題：例如，*查詢所有從美國移民到歐洲的人的姓名*。也就是說，找到所有具有指向美國境內位置的 `BORN_IN` 邊，以及指向歐洲境內位置的 `LIVING_IN` 邊的頂點，並返回每個頂點的 `name` 屬性。
 
-[示例 3-5](/tw/ch3#fig_cypher_query) 顯示瞭如何在 Cypher 中表達該查詢。相同的箭頭符號用於 `MATCH` 子句中以在圖中查詢模式：`(person) -[:BORN_IN]-> ()` 匹配由標記為 `BORN_IN` 的邊相關的任意兩個頂點。該邊的尾頂點繫結到變數 `person`，頭頂點未命名。
+[示例 3-5](/tw/ch3#fig_cypher_query) 顯示了如何在 Cypher 中表達該查詢。相同的箭頭符號用於 `MATCH` 子句中以在圖中查詢模式：`(person) -[:BORN_IN]-> ()` 匹配由標記為 `BORN_IN` 的邊相關的任意兩個頂點。該邊的尾頂點繫結到變數 `person`，頭頂點未命名。
 
 {{< figure id="fig_cypher_query" title="示例 3-5. Cypher 查詢查詢從美國移民到歐洲的人" class="w-full my-4" >}}
 
@@ -741,7 +741,7 @@ Datalog 實際上基於關係資料模型，而不是圖，但它出現在本書
 
 Datalog 資料庫的內容由 *事實* 組成，每個事實對應於關係表中的一行。例如，假設我們有一個包含位置的表 *location*，它有三列：*ID*、*name* 和 *type*。美國是一個國家的事實可以寫成 `location(2, "United States", "country")`，其中 `2` 是美國的 ID。一般來說，語句 `table(val1, val2, …​)` 意味著 `table` 包含一行，其中第一列包含 `val1`，第二列包含 `val2`，依此類推。
 
-[示例 3-11](/tw/ch3#fig_datalog_triples) 顯示瞭如何在 Datalog 中編寫 [圖 3-6](/tw/ch3#fig_datamodels_graph) 左側的資料。圖的邊（`within`、`born_in` 和 `lives_in`）表示為兩列連線表。例如，Lucy 的 ID 是 100，愛達荷州的 ID 是 3，所以關係"Lucy 出生在愛達荷州"表示為 `born_in(100, 3)`。
+[示例 3-11](/tw/ch3#fig_datalog_triples) 顯示了如何在 Datalog 中編寫 [圖 3-6](/tw/ch3#fig_datamodels_graph) 左側的資料。圖的邊（`within`、`born_in` 和 `lives_in`）表示為兩列連線表。例如，Lucy 的 ID 是 100，愛達荷州的 ID 是 3，所以關係"Lucy 出生在愛達荷州"表示為 `born_in(100, 3)`。
 
 {{< figure id="fig_datalog_triples" title="示例 3-11. [圖 3-6](/tw/ch3#fig_datamodels_graph) 中資料的子集，表示為 Datalog 事實" class="w-full my-4" >}}
 
@@ -805,7 +805,7 @@ GraphQL 是一種查詢語言，從設計上講，它比我們在本章中看到
 
 GraphQL 的靈活性是有代價的。採用 GraphQL 的組織通常需要工具將 GraphQL 查詢轉換為對內部服務的請求，這些服務通常使用 REST 或 gRPC（參見 [第 5 章](/tw/ch5#ch_encoding)）。授權、速率限制和效能挑戰是額外的關注點 [^61]。GraphQL 的查詢語言也受到限制，因為 GraphQL 來自不受信任的來源。該語言不允許任何可能執行成本高昂的操作，否則使用者可能透過執行大量昂貴的查詢對伺服器執行拒絕服務攻擊。特別是，GraphQL 不允許遞迴查詢（與 Cypher、SPARQL、SQL 或 Datalog 不同），並且不允許任意搜尋條件，如"查詢在美國出生並現在居住在歐洲的人"（除非服務所有者特別選擇提供此類搜尋功能）。
 
-儘管如此，GraphQL 還是很有用的。[示例 3-13](/tw/ch3#fig_graphql_query) 顯示瞭如何使用 GraphQL 實現 Discord 或 Slack 等群聊應用程式。查詢請求使用者有權訪問的所有頻道，包括頻道名稱和每個頻道中的 50 條最新訊息。對於每條訊息，它請求時間戳、訊息內容以及訊息傳送者的姓名和個人資料圖片 URL。此外，如果訊息是對另一條訊息的回覆，查詢還會請求傳送者姓名和它所回覆的訊息內容（可能以較小的字型呈現在回覆上方，以提供一些上下文）。
+儘管如此，GraphQL 還是很有用的。[示例 3-13](/tw/ch3#fig_graphql_query) 顯示了如何使用 GraphQL 實現 Discord 或 Slack 等群聊應用程式。查詢請求使用者有權訪問的所有頻道，包括頻道名稱和每個頻道中的 50 條最新訊息。對於每條訊息，它請求時間戳、訊息內容以及訊息傳送者的姓名和個人資料圖片 URL。此外，如果訊息是對另一條訊息的回覆，查詢還會請求傳送者姓名和它所回覆的訊息內容（可能以較小的字型呈現在回覆上方，以提供一些上下文）。
 
 {{< figure id="fig_graphql_query" title="示例 3-13. 群聊應用程式的示例 GraphQL 查詢" class="w-full my-4" >}}
 

content/tw/ch5.md

@@ -131,7 +131,7 @@ JSON 比 XML 更簡潔，但與二進位制格式相比，兩者仍然使用大
 }
 ```
 
-讓我們看一個 MessagePack 的例子，它是 JSON 的二進位制編碼。[圖 5-2](/tw/ch5#fig_encoding_messagepack) 顯示瞭如果你使用 MessagePack 編碼 [示例 5-2](/tw/ch5#fig_encoding_json) 中的 JSON 文件所得到的位元組序列。前幾個位元組如下：
+讓我們看一個 MessagePack 的例子，它是 JSON 的二進位制編碼。[圖 5-2](/tw/ch5#fig_encoding_messagepack) 顯示了如果你使用 MessagePack 編碼 [示例 5-2](/tw/ch5#fig_encoding_json) 中的 JSON 文件所得到的位元組序列。前幾個位元組如下：
 
 1. 第一個位元組 `0x83` 表示接下來是一個物件（前四位 = `0x80`），有三個欄位（後四位 = `0x03`）。（如果你想知道如果物件有超過 15 個欄位會發生什麼，以至於欄位數無法裝入四位，那麼它會獲得不同的型別指示符，欄位數會以兩個或四個位元組編碼。）
 2. 第二個位元組 `0xa8` 表示接下來是一個字串（前四位 = `0xa0`），長度為八個位元組（後四位 = `0x08`）。

content/tw/ch8.md

@@ -128,7 +128,7 @@ ACID 意義上的*隔離性*意味著同時執行的事務彼此隔離：它們
 
 ### 單物件與多物件操作 {#sec_transactions_multi_object}
 
-回顧一下，在 ACID 中，原子性和隔離性描述瞭如果客戶端在同一事務中進行多次寫入，資料庫應該做什麼：
+回顧一下，在 ACID 中，原子性和隔離性描述了如果客戶端在同一事務中進行多次寫入，資料庫應該做什麼：
 
 原子性
 : 如果在寫入序列的中途發生錯誤，事務應該被中止，並且到該點為止所做的寫入應該被丟棄。換句話說，資料庫讓你免於擔心部分失敗，透過提供全有或全無的保證。
@@ -689,7 +689,7 @@ VoltDB 還使用儲存過程進行復制：它不是將事務的寫入從一個
 * 如果事務首先讀取然後寫入物件，它可以將其共享鎖升級為獨佔鎖。升級的工作方式與直接獲取獨佔鎖相同。
 * 獲取鎖後，事務必須繼續持有鎖直到事務結束（提交或中止）。這就是"兩階段"名稱的來源：第一階段（事務執行時）是獲取鎖，第二階段（事務結束時）是釋放所有鎖。
 
-由於使用瞭如此多的鎖，很容易發生事務 A 等待事務 B 釋放其鎖，反之亦然的情況。這種情況稱為*死鎖*。資料庫自動檢測事務之間的死鎖並中止其中一個，以便其他事務可以取得進展。中止的事務需要由應用程式重試。
+由於使用了如此多的鎖，很容易發生事務 A 等待事務 B 釋放其鎖，反之亦然的情況。這種情況稱為*死鎖*。資料庫自動檢測事務之間的死鎖並中止其中一個，以便其他事務可以取得進展。中止的事務需要由應用程式重試。
 
 #### 兩階段鎖定的效能 {#performance-of-two-phase-locking}