mirror of
https://github.com/Vonng/ddia.git
synced 2024-12-06 15:20:12 +08:00
update: typo
This commit is contained in:
parent
586d3d4a0f
commit
df8c1736e7
@ -160,7 +160,7 @@
|
||||
|
||||
***釋出推文***
|
||||
|
||||
使用者可以向其粉絲髮布新訊息(平均 4.6k請求/秒,峰值超過 12k請求/秒)。
|
||||
使用者可以向其粉絲發佈新訊息(平均 4.6k請求/秒,峰值超過 12k請求/秒)。
|
||||
|
||||
***主頁時間線***
|
||||
|
||||
@ -195,7 +195,7 @@
|
||||
|
||||
推特的第一個版本使用了方法1,但系統很難跟上主頁時間線查詢的負載。所以公司轉向了方法2,方法2的效果更好,因為發推頻率比查詢主頁時間線的頻率幾乎低了兩個數量級,所以在這種情況下,最好在寫入時做更多的工作,而在讀取時做更少的工作。
|
||||
|
||||
然而方法2的缺點是,發推現在需要大量的額外工作。平均來說,一條推文會發往約75個關注者,所以每秒4.6k的發推寫入,變成了對主頁時間線快取每秒345k的寫入。但這個平均值隱藏了使用者粉絲數差異巨大這一現實,一些使用者有超過3000萬的粉絲,這意味著一條推文就可能會導致主頁時間線快取的3000萬次寫入!及時完成這種操作是一個巨大的挑戰 —— 推特嘗試在5秒內向粉絲髮送推文。
|
||||
然而方法2的缺點是,發推現在需要大量的額外工作。平均來說,一條推文會發往約75個關注者,所以每秒4.6k的發推寫入,變成了對主頁時間線快取每秒345k的寫入。但這個平均值隱藏了使用者粉絲數差異巨大這一現實,一些使用者有超過3000萬的粉絲,這意味著一條推文就可能會導致主頁時間線快取的3000萬次寫入!及時完成這種操作是一個巨大的挑戰 —— 推特嘗試在5秒內向粉絲發送推文。
|
||||
|
||||
在推特的例子中,每個使用者粉絲數的分佈(可能按這些使用者的發推頻率來加權)是探討可擴充套件性的一個關鍵負載引數,因為它決定了扇出負載。你的應用程式可能具有非常不同的特徵,但可以採用相似的原則來考慮它的負載。
|
||||
|
||||
|
@ -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】。這些效能限制大大減少了文件資料庫的實用場景。
|
||||
|
||||
值得指出的是,為了區域性性而分組集合相關資料的想法並不侷限於文件模型。例如,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)將還會看到更多關於區域性性的內容。
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user