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 a typo, update zh-tw content

Browse Source
This commit is contained in:
Gang Yin 2023-06-27 19:05:53 +08:00
parent dd67063ab3
commit 5cd1cde9ca
3 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
ch12.md
View File

@ -592,7 +592,7 @@ COMMIT;
我断言在大多数应用中，完整性比及时性重要得多。违反及时性可能令人困惑与讨厌，但违反完整性的结果可能是灾难性的。
例如在你的信用卡对账单上，如果某一笔过去 24 小时内完成的交易尚未出现并不令人奇怪 —— 这些系统有一定的滞后是正常的。我们知道银行是异步核算与敲定交易的，这里的及时性并不是非常重要【3】。但果当期对账单余额与上期对账单余额加交易总额对不上（求和错误），或者出现一笔向你收费但未向商家付款的交易（消失的钱），那实在是太糟糕了。这样的问题就违背了系统的完整性。
例如在你的信用卡对账单上，如果某一笔过去 24 小时内完成的交易尚未出现并不令人奇怪 —— 这些系统有一定的滞后是正常的。我们知道银行是异步核算与敲定交易的，这里的及时性并不是非常重要【3】。但如果当期对账单余额与上期对账单余额加交易总额对不上（求和错误），或者出现一笔向你收费但未向商家付款的交易（消失的钱），那就实在是太糟糕了，这样的问题就违背了系统的完整性。
#### 数据流系统的正确性

2
zh-tw/ch11.md
View File

@ -537,7 +537,7 @@ CEP 的實現包括 Esper【69】、IBM InfoSphere Streams【70】、Apama、TIB
透過從第三個時間戳中減去第二個時間戳，可以估算裝置時鐘和伺服器時鐘之間的偏移（假設網路延遲與所需的時間戳精度相比可忽略不計）。然後可以將該偏移應用於事件時間戳，從而估計事件實際發生的真實時間（假設裝置時鐘偏移在事件發生時與送往伺服器之間沒有變化）。
這並不是流處理獨有的問題，批處理有著完全一樣的時 間推理問題。只是在流處理的上下文中，我們更容易意識到時間的流逝。
這並不是流處理獨有的問題，批處理有著完全一樣的時間推理問題。只是在流處理的上下文中，我們更容易意識到時間的流逝。
#### 視窗的型別

6
zh-tw/ch12.md
View File

@ -377,7 +377,7 @@ Unix 和關係資料庫以非常不同的哲學來處理資訊管理問題。Uni
一些應用（如即時訊息傳遞與線上遊戲）已經具有這種 “實時” 架構（在低延遲互動的意義上，不是在 “[響應時間保證](ch8.md#響應時間保證)” 中的意義上）。但我們為什麼不用這種方式構建所有的應用？
挑戰在於，關於無狀態客戶端和請求 / 響應互動的假設已經根深蒂固地植入在在我們的資料庫、庫、框架以及協議之中。許多資料儲存支援讀取與寫入操作，為請求返回一個響應，但只有極少數提供訂閱變更的能力 —— 請求返回一個隨時間推移的響應流（請參閱 “[變更流的 API 支援](ch11.md#變更流的API支援)” ）。
挑戰在於，關於無狀態客戶端和請求 / 響應互動的假設已經根深蒂固地植入在我們的資料庫、庫、框架以及協議之中。許多資料儲存支援讀取與寫入操作，為請求返回一個響應，但只有極少數提供訂閱變更的能力 —— 請求返回一個隨時間推移的響應流（請參閱 “[變更流的 API 支援](ch11.md#變更流的API支援)” ）。
為了將寫路徑延伸至終端使用者，我們需要從根本上重新思考我們構建這些系統的方式：從請求 / 響應互動轉向釋出 / 訂閱資料流【27】。更具響應性的使用者介面與更好的離線支援，我認為這些優勢值得我們付出努力。如果你正在設計資料系統，我希望你對訂閱變更的選項留有印象，而不只是查詢當前狀態。
@ -438,7 +438,7 @@ MPP 資料庫的內部查詢執行圖有著類似的特徵（請參閱 “[Hadoo
處理兩次是資料損壞的一種形式：為同樣的服務向客戶收費兩次（收費太多）或增長計數器兩次（誇大指標）都不是我們想要的。在這種情況下，恰好一次意味著安排計算，使得最終效果與沒有發生錯誤的情況一樣，即使操作實際上因為某種錯誤而重試。我們先前討論過實現這一目標的幾種方法。
最有效的方法之一是使操作 **冪等**（idempotent，請參閱 “[冪等性](ch11.md#冪等性)”）；即確保它無論是執行一次還是執行多次都具有相同的效果。但是，將不是天生冪等的操作變為冪等的操作需要一些額外的努力與關注：你可能需要維護一些額外的元資料（例如更新了值的操作 ID 集合），並在從一個節點故障切換至另一個節點時做好防護（請參閱 “[領導者和鎖](ch8.md#領導者和鎖)”）。
最有效的方法之一是使操作 **冪等**（idempotent，請參閱 “[冪等性](ch11.md#冪等性)”）：即確保它無論是執行一次還是執行多次都具有相同的效果。但是，將不是天生冪等的操作變為冪等的操作需要一些額外的努力與關注：你可能需要維護一些額外的元資料（例如更新了值的操作 ID 集合），並在從一個節點故障切換至另一個節點時做好防護（請參閱 “[領導者和鎖](ch8.md#領導者和鎖)”）。
#### 抑制重複
@ -592,7 +592,7 @@ COMMIT;
我斷言在大多數應用中，完整性比及時性重要得多。違反及時性可能令人困惑與討厭，但違反完整性的結果可能是災難性的。
例如在你的信用卡對賬單上，如果某一筆過去 24 小時內完成的交易尚未出現並不令人奇怪 —— 這些系統有一定的滯後是正常的。我們知道銀行是非同步核算與敲定交易的，這裡的及時性並不是非常重要【3】。但果當期對賬單餘額與上期對賬單餘額加交易總額對不上（求和錯誤），或者出現一筆向你收費但未向商家付款的交易（消失的錢），那實在是太糟糕了。這樣的問題就違背了系統的完整性。
例如在你的信用卡對賬單上，如果某一筆過去 24 小時內完成的交易尚未出現並不令人奇怪 —— 這些系統有一定的滯後是正常的。我們知道銀行是非同步核算與敲定交易的，這裡的及時性並不是非常重要【3】。但如果當期對賬單餘額與上期對賬單餘額加交易總額對不上（求和錯誤），或者出現一筆向你收費但未向商家付款的交易（消失的錢），那就實在是太糟糕了，這樣的問題就違背了系統的完整性。
#### 資料流系統的正確性