From 22b61e1c1cfa441c45c0b0094a0638bebdbeb422 Mon Sep 17 00:00:00 2001 From: Gang Yin <1246410+yingang@users.noreply.github.com> Date: Thu, 5 May 2022 22:16:36 +0800 Subject: [PATCH] update the translation of last paragraph in ch5.md --- ch5.md | 2 +- zh-tw/ch5.md | 2 +- zh-tw/ch7.md | 6 +++--- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/ch5.md b/ch5.md index 791fc4a..8a219af 100644 --- a/ch5.md +++ b/ch5.md @@ -761,7 +761,7 @@ LWW 实现了最终收敛的目标，但以 **持久性** 为代价：如果同 最后，我们讨论了多主复制和无主复制方法所固有的并发问题：因为他们允许多个写入并发发生，这可能会导致冲突。我们研究了一个数据库可以使用的算法来确定一个操作是否发生在另一个操作之前，或者它们是否并发发生。我们还谈到了通过合并并发更新来解决冲突的方法。 -在下一章中，我们将继续研究分布在多个机器上的数据，通过复制的同僚：将大数据集分割成分区。 +在下一章中，我们将继续考察数据分布在多台机器间的另一种不同于 **复制** 的形式：将大数据集分割成 **分区**。 ## 参考文献 diff --git a/zh-tw/ch5.md b/zh-tw/ch5.md index 200e055..926810b 100644 --- a/zh-tw/ch5.md +++ b/zh-tw/ch5.md @@ -761,7 +761,7 @@ LWW 實現了最終收斂的目標，但以 **永續性** 為代價：如果同 最後，我們討論了多主複製和無主複製方法所固有的併發問題：因為他們允許多個寫入併發發生，這可能會導致衝突。我們研究了一個數據庫可以使用的演算法來確定一個操作是否發生在另一個操作之前，或者它們是否併發發生。我們還談到了透過合併併發更新來解決衝突的方法。 -在下一章中，我們將繼續研究分佈在多個機器上的資料，透過複製的同僚：將大資料集分割成分割槽。 +在下一章中，我們將繼續考察資料分佈在多臺機器間的另一種不同於 **複製** 的形式：將大資料集分割成 **分割槽**。 ## 參考文獻 diff --git a/zh-tw/ch7.md b/zh-tw/ch7.md index 4f3b095..5696258 100644 --- a/zh-tw/ch7.md +++ b/zh-tw/ch7.md @@ -42,7 +42,7 @@ 隨著這種新型分散式資料庫的炒作，人們普遍認為事務是可伸縮性的對立面，任何大型系統都必須放棄事務以保持良好的效能和高可用性【5,6】。另一方面，資料庫廠商有時將事務保證作為 “重要應用” 和 “有價值資料” 的基本要求。這兩種觀點都是 **純粹的誇張**。 -事實並非如此簡單：與其他技術設計選擇一樣，事務有其優勢和侷限性。為了理解這些權衡，讓我們瞭解事務所提供的保證的細節 —— 無論是在正常執行中還是在各種極端（但是現實存在）的情況下。 +事實並非如此簡單：與其他技術設計選擇一樣，事務有其優勢和侷限性。為了理解這些權衡，讓我們瞭解事務所提供保證的細節 —— 無論是在正常執行中還是在各種極端（但是現實存在）的情況下。 ### ACID的含義 @@ -224,7 +224,7 @@ SELECT COUNT（*）FROM emails WHERE recipient_id = 2 AND unread_flag = true 弱事務隔離級別導致的併發性錯誤不僅僅是一個理論問題。它們造成了很多的資金損失【24,25】，耗費了財務審計人員的調查【26】，並導致客戶資料被破壞【27】。關於這類問題的一個流行的評論是 “如果你正在處理財務資料，請使用 ACID 資料庫！” —— 但是這一點沒有提到。即使是很多流行的關係型資料庫系統（通常被認為是 “ACID”）也使用弱隔離級別，所以它們也不一定能防止這些錯誤的發生。 -比起盲目地依賴工具，我們應該對存在的併發問題的種類，以及如何防止這些問題有深入的理解。然後就可以使用我們所掌握的工具來構建可靠和正確的應用程式。 +比起盲目地依賴工具，我們需要對存在的各種併發問題，以及如何防止這些問題有深入的理解。然後就可以使用我們所掌握的工具來構建可靠和正確的應用程式。 在本節中，我們將看幾個在實踐中使用的弱（**非序列的**，即 nonserializable）隔離級別，並詳細討論哪種競爭條件可能發生也可能不發生，以便你可以決定什麼級別適合你的應用程式。一旦我們完成了這個工作，我們將詳細討論可序列化（請參閱 “[可序列化](#可序列化)”）。我們討論的隔離級別將是非正式的，透過示例來進行。如果你需要嚴格的定義和分析它們的屬性，你可以在學術文獻中找到它們【28,29,30】。 @@ -285,7 +285,7 @@ SELECT COUNT（*）FROM emails WHERE recipient_id = 2 AND unread_flag = true ### 快照隔離和可重複讀 -如果只從表面上看讀已提交隔離級別你就認為它完成了事務所需的一切，那是可以原諒的。它允許 **中止**（原子性的要求）；它防止讀取不完整的事務結果，並且防止併發寫入造成的混亂。事實上這些功能非常有用，比起沒有事務的系統來，可以提供更多的保證。 +如果只從表面上看讀已提交隔離級別你就認為它完成了事務所需的一切，這是情有可原的。它允許 **中止**（原子性的要求）；它防止讀取不完整的事務結果，並且防止併發寫入造成的混亂。事實上這些功能非常有用，比起沒有事務的系統來，可以提供更多的保證。 但是在使用此隔離級別時，仍然有很多地方可能會產生併發錯誤。例如 [圖 7-6](../img/fig7-6.png) 說明了讀已提交時可能發生的問題。