From 41a8f14c8c013e783f084948510eb2c9a97fa07a Mon Sep 17 00:00:00 2001 From: Gang Yin <1246410+yingang@users.noreply.github.com> Date: Tue, 14 Sep 2021 09:27:19 +0800 Subject: [PATCH] update zh-tw content --- ch4.md | 2 +- zh-tw/ch2.md | 2 +- zh-tw/ch4.md | 12 ++++++------ zh-tw/ch5.md | 2 +- 4 files changed, 9 insertions(+), 9 deletions(-) diff --git a/ch4.md b/ch4.md index 81fad1e..d8c7e7f 100644 --- a/ch4.md +++ b/ch4.md @@ -11,7 +11,7 @@ [TOC] -应用程序不可避免地随时间而变化。新产品的推出，对需求的深入理解，或者商业环境的变化，总会伴随着**功能（feature）** 的增增改改。[第一章](ch1.md)介绍了**可演化性(evolvability)** 的概念：应该尽力构建能灵活适应变化的系统（请参阅“[可演化性：拥抱变化](ch1.md#可演化性：拥抱变化)”）。 +应用程序不可避免地随时间而变化。新产品的推出，对需求的深入理解，或者商业环境的变化，总会伴随着**功能（feature）** 的增增改改。[第一章](ch1.md)介绍了**可演化性（evolvability）** 的概念：应该尽力构建能灵活适应变化的系统（请参阅“[可演化性：拥抱变化](ch1.md#可演化性：拥抱变化)”）。 在大多数情况下，修改应用程序的功能也意味着需要更改其存储的数据：可能需要使用新的字段或记录类型，或者以新方式展示现有数据。 diff --git a/zh-tw/ch2.md b/zh-tw/ch2.md index 8de21d6..86ef6c7 100644 --- a/zh-tw/ch2.md +++ b/zh-tw/ch2.md @@ -174,7 +174,7 @@ JSON表示比[圖2-1](../img/fig2-1.png)中的多表模式具有更好的**區 ### 文件資料庫是否在重蹈覆轍？ -在多對多的關係和連線已常規用在關係資料庫時，文件資料庫和NoSQL重啟了辯論：如何最好地在資料庫中表示多對多關係。那場辯論可比NoSQL古老得多，事實上，最早可以追溯到計算機化資料庫系統。 +在多對多的關係和連線已常規用在關係資料庫時，文件資料庫和NoSQL重啟了辯論：如何以最佳方式在資料庫中表示多對多關係。那場辯論可比NoSQL古老得多，事實上，最早可以追溯到計算機化資料庫系統。 20世紀70年代最受歡迎的業務資料處理資料庫是IBM的資訊管理系統（IMS），最初是為了阿波羅太空計劃的庫存管理而開發的，並於1968年有了首次商業釋出【13】。目前它仍在使用和維護，執行在IBM大型機的OS/390上【14】。 diff --git a/zh-tw/ch4.md b/zh-tw/ch4.md index 1feed8e..1ee06e8 100644 --- a/zh-tw/ch4.md +++ b/zh-tw/ch4.md @@ -11,7 +11,7 @@ [TOC] -應用程式不可避免地隨時間而變化。新產品的推出，對需求的深入理解，或者商業環境的變化，總會伴隨著**功能（feature）** 的增增改改。[第一章](ch1.md)介紹了**可演化性(evolvability)**的概念：應該盡力構建能靈活適應變化的系統（請參閱“[可演化性：擁抱變化](ch1.md#可演化性：擁抱變化)”）。 +應用程式不可避免地隨時間而變化。新產品的推出，對需求的深入理解，或者商業環境的變化，總會伴隨著**功能（feature）** 的增增改改。[第一章](ch1.md)介紹了**可演化性（evolvability）** 的概念：應該盡力構建能靈活適應變化的系統（請參閱“[可演化性：擁抱變化](ch1.md#可演化性：擁抱變化)”）。 在大多數情況下，修改應用程式的功能也意味著需要更改其儲存的資料：可能需要使用新的欄位或記錄型別，或者以新方式展示現有資料。 @@ -90,7 +90,7 @@ JSON，XML和CSV屬於文字格式，因此具有人類可讀性（儘管它們 JSON比XML簡潔，但與二進位制格式相比還是太佔空間。這一事實導致大量二進位制編碼版本JSON（MessagePack，BSON，BJSON，UBJSON，BISON和Smile等） 和 XML（例如WBXML和Fast Infoset）的出現。這些格式已經在各種各樣的領域中採用，但是沒有一個能像文字版JSON和XML那樣被廣泛採用。 -這些格式中的一些擴充套件了一組資料型別（例如，區分整數和浮點數，或者增加對二進位制字串的支援），另一方面，它們沒有改變JSON / XML的資料模型。特別是由於它們沒有規定模式，所以它們需要在編碼資料中包含所有的物件欄位名稱。也就是說，在[例4-1]()中的JSON文件的二進位制編碼中，需要在某處包含字串`userName`，`favoriteNumber`和`interest`。 +這些格式中的一些擴充套件了一組資料型別（例如，區分整數和浮點數，或者增加對二進位制字串的支援），另一方面，它們沒有改變JSON / XML的資料模型。特別是由於它們沒有規定模式，所以它們需要在編碼資料中包含所有的物件欄位名稱。也就是說，在[例4-1]()中的JSON文件的二進位制編碼中，需要在某處包含字串`userName`，`favoriteNumber`和`interests`。 **例4-1 本章中用於展示二進位制編碼的示例記錄** @@ -152,7 +152,7 @@ Thrift和Protocol Buffers每一個都帶有一個程式碼生成工具，它採 與[圖4-1](Img/fig4-1.png)類似，每個欄位都有一個型別註釋（用於指示它是一個字串，整數，列表等），還可以根據需要指定長度（字串的長度，列表中的專案數） 。出現在資料中的字串`(“Martin”, “daydreaming”, “hacking”)`也被編碼為ASCII（或者說，UTF-8），與之前類似。 -與[圖4-1](../img/fig4-1.png)相比，最大的區別是沒有欄位名`(userName, favoriteNumber, interest)`。相反，編碼資料包含欄位標籤，它們是數字`(1, 2和3)`。這些是模式定義中出現的數字。欄位標記就像欄位的別名 - 它們是說我們正在談論的欄位的一種緊湊的方式，而不必拼出欄位名稱。 +與[圖4-1](../img/fig4-1.png)相比，最大的區別是沒有欄位名`(userName, favoriteNumber, interests)`。相反，編碼資料包含欄位標籤，它們是數字`(1, 2和3)`。這些是模式定義中出現的數字。欄位標記就像欄位的別名 - 它們是說我們正在談論的欄位的一種緊湊的方式，而不必拼出欄位名稱。 Thrift CompactProtocol編碼在語義上等同於BinaryProtocol，但是如[圖4-3](../img/fig4-3.png)所示，它只將相同的資訊打包成只有34個位元組。它透過將欄位型別和標籤號打包到單個位元組中，並使用可變長度整數來實現。數字1337不是使用全部八個位元組，而是用兩個位元組編碼，每個位元組的最高位用來指示是否還有更多的位元組來。這意味著-64到63之間的數字被編碼為一個位元組，-8192和8191之間的數字以兩個位元組編碼，等等。較大的數字使用更多的位元組。 @@ -248,9 +248,9 @@ Avro的關鍵思想是Writer模式和Reader模式不必是相同的 - 他們只 使用Avro，向前相容性意味著您可以將新版本的模式作為Writer，並將舊版本的模式作為Reader。相反，向後相容意味著你可以有一個作為Reader的新版本模式和作為Writer的舊版本模式。 -為了保持相容性，您只能新增或刪除具有預設值的欄位。 （我們的Avro模式中的欄位`favourNumber`的預設值為`null`）。例如，假設您添加了一個有預設值的欄位，這個新的欄位將存在於新模式而不是舊模式中。當使用新模式的Reader讀取使用舊模式寫入的記錄時，將為缺少的欄位填充預設值。 +為了保持相容性，您只能新增或刪除具有預設值的欄位。 （我們的Avro模式中的欄位`favoriteNumber`的預設值為`null`）。例如，假設您添加了一個有預設值的欄位，這個新的欄位將存在於新模式而不是舊模式中。當使用新模式的Reader讀取使用舊模式寫入的記錄時，將為缺少的欄位填充預設值。 -如果你要新增一個沒有預設值的欄位，新的Reader將無法讀取舊Writer寫的資料，所以你會破壞向後相容性。如果您要刪除沒有預設值的欄位，舊的Reader將無法讀取新Writer寫入的資料，因此您會打破向前相容性。在一些程式語言中，null是任何變數可以接受的預設值，但在Avro中並不是這樣：如果要允許一個欄位為`null`，則必須使用聯合型別。例如，`union {null，long，string} field;`表示field可以是數字或字串，也可以是`null`。如果要將null作為預設值，則它必須是union的分支之一[^iv]。這樣的寫法比預設情況下就允許任何變數是`null`顯得更加冗長，但是透過明確什麼可以和什麼不可以是`null`，有助於防止出錯【22】。 +如果你要新增一個沒有預設值的欄位，新的Reader將無法讀取舊Writer寫的資料，所以你會破壞向後相容性。如果您要刪除沒有預設值的欄位，舊的Reader將無法讀取新Writer寫入的資料，因此您會打破向前相容性。在一些程式語言中，null是任何變數可以接受的預設值，但在Avro中並不是這樣：如果要允許一個欄位為`null`，則必須使用聯合型別。例如，`union {null, long, string} field;`表示field可以是數字或字串，也可以是`null`。如果要將null作為預設值，則它必須是union的分支之一[^iv]。這樣的寫法比預設情況下就允許任何變數是`null`顯得更加冗長，但是透過明確什麼可以和什麼不可以是`null`，有助於防止出錯【22】。 [^iv]: 確切地說，預設值必須是聯合的第一個分支的型別，儘管這是Avro的特定限制，而不是聯合型別的一般特徵。 @@ -473,7 +473,7 @@ RPC方案的前後向相容性屬性從它使用的編碼方式中繼承： #### 訊息代理 -過去，**訊息代理（Message Broker）**主要是TIBCO，IBM WebSphere和webMethods等公司的商業軟體的秀場。最近像RabbitMQ，ActiveMQ，HornetQ，NATS和Apache Kafka這樣的開源實現已經流行起來。我們將在[第十一章](ch11.md)中對它們進行更詳細的比較。 +過去，**訊息代理（Message Broker）** 主要是TIBCO，IBM WebSphere和webMethods等公司的商業軟體的秀場。最近像RabbitMQ，ActiveMQ，HornetQ，NATS和Apache Kafka這樣的開源實現已經流行起來。我們將在[第十一章](ch11.md)中對它們進行更詳細的比較。 詳細的交付語義因實現和配置而異，但通常情況下，訊息代理的使用方式如下：一個程序將訊息傳送到指定的佇列或主題，代理確保將訊息傳遞給那個佇列或主題的一個或多個消費者或訂閱者。在同一主題上可以有許多生產者和許多消費者。 diff --git a/zh-tw/ch5.md b/zh-tw/ch5.md index c796d23..a953a3e 100644 --- a/zh-tw/ch5.md +++ b/zh-tw/ch5.md @@ -449,7 +449,7 @@ ​ 最普遍的拓撲是全部到全部（[圖5-8 (c)](../img/fig5-8.png)），其中每個領導者將其寫入每個其他領導。但是，也會使用更多受限制的拓撲：例如，預設情況下，MySQL僅支援**環形拓撲（circular topology）**【34】，其中每個節點接收來自一個節點的寫入，並將這些寫入（加上自己的任何寫入）轉發給另一個節點。另一種流行的拓撲結構具有星形的形狀[^v]。一個指定的根節點將寫入轉發給所有其他節點。星型拓撲可以推廣到樹。 -[^v]: 不要與星型模式混淆（請參閱“[星型和雪花型：分析的模式](ch2.md#星型和雪花型：分析的模式)”），其中描述了資料模型的結構，而不是節點之間的通訊拓撲。 +[^v]: 不要與星型模式混淆（請參閱“[星型和雪花型：分析的模式](ch3.md#星型和雪花型：分析的模式)”），其中描述了資料模型的結構，而不是節點之間的通訊拓撲。 ​ 在圓形和星形拓撲中，寫入可能需要在到達所有副本之前透過多個節點。因此，節點需要轉發從其他節點收到的資料更改。為了防止無限複製迴圈，每個節點被賦予一個唯一的識別符號，並且在複製日誌中，每個寫入都被標記了所有已經過的節點的識別符號【43】。當一個節點收到用自己的識別符號標記的資料更改時，該資料更改將被忽略，因為節點知道它已經被處理過。