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

update: typo

Browse Source
This commit is contained in:
afunTW 2020-10-10 19:46:40 +08:00
parent 586d3d4a0f
commit df8c1736e7
2 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
zh-tw/ch1.md
View File

@ -160,7 +160,7 @@
***釋出推文*** ***釋出推文***
​ 使用者可以向其粉絲髮布新訊息（平均 4.6k請求/秒，峰值超過 12k請求/秒）。 ​ 使用者可以向其粉絲發佈新訊息（平均 4.6k請求/秒，峰值超過 12k請求/秒）。
***主頁時間線*** ***主頁時間線***
@ -195,7 +195,7 @@
推特的第一個版本使用了方法1，但系統很難跟上主頁時間線查詢的負載。所以公司轉向了方法2，方法2的效果更好，因為發推頻率比查詢主頁時間線的頻率幾乎低了兩個數量級，所以在這種情況下，最好在寫入時做更多的工作，而在讀取時做更少的工作。 推特的第一個版本使用了方法1，但系統很難跟上主頁時間線查詢的負載。所以公司轉向了方法2，方法2的效果更好，因為發推頻率比查詢主頁時間線的頻率幾乎低了兩個數量級，所以在這種情況下，最好在寫入時做更多的工作，而在讀取時做更少的工作。
​ 然而方法2的缺點是，發推現在需要大量的額外工作。平均來說，一條推文會發往約75個關注者，所以每秒4.6k的發推寫入，變成了對主頁時間線快取每秒345k的寫入。但這個平均值隱藏了使用者粉絲數差異巨大這一現實，一些使用者有超過3000萬的粉絲，這意味著一條推文就可能會導致主頁時間線快取的3000萬次寫入！及時完成這種操作是一個巨大的挑戰 —— 推特嘗試在5秒內向粉絲髮送推文。 ​ 然而方法2的缺點是，發推現在需要大量的額外工作。平均來說，一條推文會發往約75個關注者，所以每秒4.6k的發推寫入，變成了對主頁時間線快取每秒345k的寫入。但這個平均值隱藏了使用者粉絲數差異巨大這一現實，一些使用者有超過3000萬的粉絲，這意味著一條推文就可能會導致主頁時間線快取的3000萬次寫入！及時完成這種操作是一個巨大的挑戰 —— 推特嘗試在5秒內向粉絲發送推文。
​ 在推特的例子中，每個使用者粉絲數的分佈（可能按這些使用者的發推頻率來加權）是探討可擴充套件性的一個關鍵負載引數，因為它決定了扇出負載。你的應用程式可能具有非常不同的特徵，但可以採用相似的原則來考慮它的負載。 ​ 在推特的例子中，每個使用者粉絲數的分佈（可能按這些使用者的發推頻率來加權）是探討可擴充套件性的一個關鍵負載引數，因為它決定了扇出負載。你的應用程式可能具有非常不同的特徵，但可以採用相似的原則來考慮它的負載。

6
zh-tw/ch2.md
View File

@ -272,13 +272,13 @@ UPDATE users SET first_name = substring_index(name, ' ', 1); -- MySQL
在上述情況下，模式的壞處遠大於它的幫助，無模式文件可能是一個更加自然的資料模型。但是，要是所有記錄都具有相同的結構，那麼模式是記錄並強制這種結構的有效機制。第四章將更詳細地討論模式和模式演化。 在上述情況下，模式的壞處遠大於它的幫助，無模式文件可能是一個更加自然的資料模型。但是，要是所有記錄都具有相同的結構，那麼模式是記錄並強制這種結構的有效機制。第四章將更詳細地討論模式和模式演化。
#### 查詢的資料區域性性 #### 查詢的資料區域性
文件通常以單個連續字串形式進行儲存，編碼為JSON，XML或其二進位制變體（如MongoDB的BSON）。如果應用程式經常需要訪問整個文件（例如，將其渲染至網頁），那麼儲存區域性性會帶來效能優勢。如果將資料分割到多個表中（如[圖2-1](../img/fig2-1.png)所示），則需要進行多次索引查詢才能將其全部檢索出來，這可能需要更多的磁碟查詢並花費更多的時間。 文件通常以單個連續字串形式進行儲存，編碼為JSON，XML或其二進位制變體（如MongoDB的BSON）。如果應用程式經常需要訪問整個文件（例如，將其渲染至網頁），那麼儲存區域性會帶來效能優勢。如果將資料分割到多個表中（如[圖2-1](../img/fig2-1.png)所示），則需要進行多次索引查詢才能將其全部檢索出來，這可能需要更多的磁碟查詢並花費更多的時間。
區域性性僅僅適用於同時需要文件絕大部分內容的情況。資料庫通常需要載入整個文件，即使只訪問其中的一小部分，這對於大型文件來說是很浪費的。更新文件時，通常需要整個重寫。只有不改變文件大小的修改才可以容易地原地執行。因此，通常建議保持相對小的文件，並避免增加文件大小的寫入【9】。這些效能限制大大減少了文件資料庫的實用場景。 區域性性僅僅適用於同時需要文件絕大部分內容的情況。資料庫通常需要載入整個文件，即使只訪問其中的一小部分，這對於大型文件來說是很浪費的。更新文件時，通常需要整個重寫。只有不改變文件大小的修改才可以容易地原地執行。因此，通常建議保持相對小的文件，並避免增加文件大小的寫入【9】。這些效能限制大大減少了文件資料庫的實用場景。
值得指出的是，為了區域性性而分組集合相關資料的想法並不侷限於文件模型。例如，Google的Spanner資料庫在關係資料模型中提供了同樣的區域性性屬性，允許模式宣告一個表的行應該交錯（巢狀）在父表內【27】。Oracle類似地允許使用一個稱為 **多表索引叢集表（multi-table index cluster tables）** 的類似特性【28】。Bigtable資料模型（用於Cassandra和HBase）中的 **列族（column-family）** 概念與管理區域性性的目的類似【29】。 值得指出的是，為了區域性而分組集合相關資料的想法並不侷限於文件模型。例如，Google的Spanner資料庫在關係資料模型中提供了同樣的區域性性屬性，允許模式宣告一個表的行應該交錯（巢狀）在父表內【27】。Oracle類似地允許使用一個稱為 **多表索引叢集表（multi-table index cluster tables）** 的類似特性【28】。Bigtable資料模型（用於Cassandra和HBase）中的 **列族（column-family）** 概念與管理區域性性的目的類似【29】。
在[第3章](ch3.md)將還會看到更多關於區域性性的內容。 在[第3章](ch3.md)將還會看到更多關於區域性性的內容。