update translation for tombstone in ch3, update PR list in README.md

Ynjxsjmh · Dec 13, 2021 · ba60df5 · ba60df5
1 parent 7bb62dd
commit ba60df5
Show file tree

Hide file tree

Showing 5 changed files with 12 additions and 10 deletions.
diff --git a/README.md b/README.md
@@ -149,6 +149,7 @@
 
 | ISSUE & Pull Requests                          | USER                                                         | Title                                                        |
 | ----------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
+|  [151](https://github.com/Vonng/ddia/pull/151)  |  [@ZvanYang](https://github.com/ZvanYang)  |   ch5: 修订sibling相关的翻译  |
 |  [147](https://github.com/Vonng/ddia/pull/147)  |  [@ZvanYang](https://github.com/ZvanYang)  |   ch5: 更正一处不准确的翻译  |
 |  [145](https://github.com/Vonng/ddia/pull/145)  |  [@Hookey](https://github.com/Hookey)  |   识别了当前简繁转译过程中处理不当的地方，暂通过转换脚本规避  |
 |  [144](https://github.com/Vonng/ddia/issues/144)  |  [@secret4233](https://github.com/secret4233)  |   ch7: 不翻译`next-key locking`  |

diff --git a/ch3.md b/ch3.md
@@ -114,7 +114,7 @@ $ cat database
 
 * 删除记录
 
-  如果要删除一个键及其关联的值，则必须在数据文件中追加一个特殊的删除记录（有时称为逻辑删除（tombstone））。当日志段被合并时，逻辑删除告诉合并过程丢弃被删除键的任何以前的值。
+  如果要删除一个键及其关联的值，则必须在数据文件中追加一个特殊的删除记录（逻辑删除，有时称为墓碑（tombstone））。当日志段被合并时，逻辑删除告诉合并过程丢弃被删除键的任何以前的值。
 
 * 崩溃恢复
 

diff --git a/zh-tw/README.md b/zh-tw/README.md
@@ -149,6 +149,7 @@
 
 | ISSUE & Pull Requests                          | USER                                                         | Title                                                        |
 | ----------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
+|  [151](https://github.com/Vonng/ddia/pull/151)  |  [@ZvanYang](https://github.com/ZvanYang)  |   ch5: 修訂sibling相關的翻譯  |
 |  [147](https://github.com/Vonng/ddia/pull/147)  |  [@ZvanYang](https://github.com/ZvanYang)  |   ch5: 更正一處不準確的翻譯  |
 |  [145](https://github.com/Vonng/ddia/pull/145)  |  [@Hookey](https://github.com/Hookey)  |   識別了當前簡繁轉譯過程中處理不當的地方，暫透過轉換指令碼規避  |
 |  [144](https://github.com/Vonng/ddia/issues/144)  |  [@secret4233](https://github.com/secret4233)  |   ch7: 不翻譯`next-key locking`  |

diff --git a/zh-tw/ch3.md b/zh-tw/ch3.md
@@ -114,7 +114,7 @@ $ cat database
 
 * 刪除記錄
 
-  如果要刪除一個鍵及其關聯的值，則必須在資料檔案中追加一個特殊的刪除記錄（有時稱為邏輯刪除（tombstone））。當日志段被合併時，邏輯刪除告訴合併過程丟棄被刪除鍵的任何以前的值。
+  如果要刪除一個鍵及其關聯的值，則必須在資料檔案中追加一個特殊的刪除記錄（邏輯刪除，有時稱為墓碑（tombstone））。當日志段被合併時，邏輯刪除告訴合併過程丟棄被刪除鍵的任何以前的值。
 
 * 崩潰恢復
 

diff --git a/zh-tw/ch5.md b/zh-tw/ch5.md
@@ -682,27 +682,27 @@ LWW實現了最終收斂的目標，但以**永續性**為代價：如果同一
 
 #### 合併同時寫入的值
 
-這種演算法可以確保沒有資料被無聲地丟棄，但不幸的是，客戶端需要做一些額外的工作：如果多個操作併發發生，則客戶端必須透過合併併發寫入的值來擦屁股。 Riak稱這些併發值**兄弟（siblings）**。
+這種演算法可以確保沒有資料被無聲地丟棄，但不幸的是，客戶端需要做一些額外的工作：客戶端隨後必須透過合併併發寫入的值來進行清理。 Riak稱這些併發值為**兄弟（siblings）**。
 
-合併兄弟值，本質上是與多領導者複製中的衝突解決相同的問題，我們先前討論過（請參閱“[處理寫入衝突](#處理寫入衝突)”）。一個簡單的方法是根據版本號或時間戳（最後寫入勝利）選擇一個值，但這意味著丟失資料。所以，你可能需要在應用程式程式碼中做更聰明的事情。
+合併併發值，本質上是與多領導者複製中的衝突解決問題相同，我們先前討論過（請參閱“[處理寫入衝突](#處理寫入衝突)”）。一個簡單的方法是根據版本號或時間戳（最後寫入勝利）來選擇一個值，但這意味著丟失資料。所以，你可能需要在應用程式程式碼中額外做些更聰明的事情。
 
-以購物車為例，一種合理的合併兄弟方法就是集合求並集。在[圖5-14](../img/fig5-14.png)中，最後的兩個兄弟是[牛奶，麵粉，雞蛋，燻肉]和[雞蛋，牛奶，火腿]。注意牛奶和雞蛋同時出現在兩個兄弟裡，即使他們每個只被寫過一次。合併的值可以是[牛奶，麵粉，雞蛋，培根，火腿]，沒有重複。
+以購物車為例，一種合理的合併值的方法就是做並集。在[圖5-14](../img/fig5-14.png)中，最後的合併結果是[牛奶，麵粉，雞蛋，燻肉]和[雞蛋，牛奶，火腿]。注意牛奶和雞蛋同時出現在兩個併發值裡，即使他們每個只被寫過一次。合併的值可以是[牛奶，麵粉，雞蛋，培根，火腿]，他們沒有重複。
 
-然而，如果你想讓人們也可以從他們的購物車中**刪除**東西，而不是僅僅新增東西，那麼把兄弟求並集可能不會產生正確的結果：如果你合併了兩個兄弟購物車，並且只在其中一個兄弟值裡刪掉了它，那麼被刪除的專案會重新出現在並集終值中【37】。為了防止這個問題，一個專案在刪除時不能簡單地從資料庫中刪除；相反，系統必須留下一個具有合適版本號的標記，以指示合併兄弟時該專案已被刪除。這種刪除標記被稱為**墓碑（tombstone）**。 （我們之前在“[雜湊索引”](ch3.md#雜湊索引)中的日誌壓縮的上下文中看到了墓碑。）
+然而，如果你想讓人們也可以從他們的購物車中**刪除**東西，而不是僅僅新增東西，那麼把併發值做並集可能不會產生正確的結果：如果你合併了兩個客戶端的購物車，並且只在其中一個客戶端裡面刪掉了它，那麼被刪除的專案會重新出現在這兩個客戶端的交集結果中【37】。為了防止這個問題，一個專案在刪除時不能簡單地從資料庫中刪除；相反，系統必須留下一個具有適當版本號的標記，在合併兄弟時表明該專案已被刪除。這種刪除標記被稱為**墓碑（tombstone）**。 （我們之前在“[雜湊索引”](ch3.md#雜湊索引)中的日誌壓縮的上下文中看到了墓碑。）
 
-因為在應用程式程式碼中合併兄弟是複雜且容易出錯的，所以有一些資料結構被設計出來用於自動執行這種合併，如“[自動衝突解決](#自動衝突解決)”中討論的。例如，Riak的資料型別支援使用稱為CRDT的資料結構家族【38,39,55】可以以合理的方式自動合併兄弟，包括保留刪除。
+因為在應用程式程式碼中做合併是複雜且易出錯，所以有一些資料結構被設計出來用於自動執行這種合併，如“[自動衝突解決](#自動衝突解決)”中討論的。例如，Riak的資料型別支援使用稱為CRDT的資料結構家族【38,39,55】可以以合理的方式自動合併，包括保留刪除。
 
 #### 版本向量
 
 [圖5-13](../img/fig5-13.png)中的示例只使用一個副本。當有多個副本但沒有領導者時，演算法如何修改？
 
-[圖5-13](../img/fig5-13.png)使用單個版本號來捕獲操作之間的依賴關係，但是當多個副本併發接受寫入時，這是不夠的。相反，除了對每個鍵使用版本號之外，還需要在**每個副本**中使用版本號。每個副本在處理寫入時增加自己的版本號，並且跟蹤從其他副本中看到的版本號。這個資訊指出了要覆蓋哪些值，以及保留哪些值作為兄弟。
+[圖5-13](../img/fig5-13.png)使用單個版本號來捕獲操作之間的依賴關係，但是當多個副本併發接受寫入時，這是不夠的。相反，還需要在**每個副本**以及**每個鍵**使用版本號。每個副本在處理寫入時增加自己的版本號，並且跟蹤從其他副本中看到的版本號。這個資訊指出了要覆蓋哪些併發值，以及保留哪些併發值。
 
-所有副本的版本號集合稱為**版本向量（version vector）**【56】。這個想法的一些變體正在被使用，但最有趣的可能是在Riak 2.0 【58,59】中使用的**分散版本向量（dotted version vector）**【57】。我們不會深入細節，但是它的工作方式與我們在購物車示例中看到的非常相似。
+所有副本的版本號集合稱為**版本向量（version vector）**【56】。這個想法的一些變體正在被使用，但最有趣的可能是在Riak 2.0 【58,59】中使用的**虛線版本向量（dotted version vector）**【57】。我們不會深入細節，但是它的工作方式與我們在購物車示例中看到的非常相似。
 
 與[圖5-13](../img/fig5-13.png)中的版本號一樣，當讀取值時，版本向量會從資料庫副本傳送到客戶端，並且隨後寫入值時需要將其傳送回資料庫。（Riak將版本向量編碼為一個字串，它稱為**因果上下文（causal context）**）。版本向量允許資料庫區分覆蓋寫入和併發寫入。
 
-另外，就像在單個副本的例子中，應用程式可能需要合併兄弟。版本向量結構確保從一個副本讀取並隨後寫回到另一個副本是安全的。這樣做可能會建立兄弟，但只要兄弟姐妹合併正確，就不會丟失資料。
+另外，就像在單個副本中的情況一樣，應用程式可能需要合併併發值。版本向量結構能夠確保從一個副本讀取並隨後寫回到另一個副本是安全的。這樣做雖然可能會在其他副本上面建立資料，但只要能正確合併就不會丟失資料。
 
 > #### 版本向量和向量時鐘
 >