update zh-tw content

content/tw/ch4.md

@@ -112,7 +112,7 @@ $ cat database
 
 #### 構建和合並 SSTable {#constructing-and-merging-sstables}
 
-SSTable 檔案格式在讀取方面比僅追加日誌更好，但它使寫入更加困難。我們不能簡單地追加到末尾，因為那樣檔案就不再排序了（除非鍵恰好按升序寫入）。如果我們每次在中間某處插入鍵時都必須重寫整個 SSTable，寫入將變得太昂貴。
+SSTable 檔案格式在讀取方面比僅追加日誌更好，但它使寫入更加困難。我們不能簡單地追加到末尾，因為那樣檔案就不再有序了（除非鍵恰好按升序寫入）。如果我們每次在中間某處插入鍵時都必須重寫整個 SSTable，寫入將變得太昂貴。
 
 我們可以用 *日誌結構* 方法解決這個問題，這是僅追加日誌和排序檔案之間的混合：
 
@@ -237,7 +237,7 @@ B 樹的基本底層寫操作是用新資料覆蓋磁碟上的頁。假設覆蓋
 
 #### 讀取效能 {#read-performance}
 
-在 B 樹中，查詢鍵涉及在 B 樹的每個級別讀取一個頁。由於級別數通常很小，這意味著從 B 樹讀取通常很快並且具有可預測的效能。在 LSM 儲存引擎中，讀取通常必須檢查處於不同壓實階段的幾個不同 SSTable，但布隆過濾器有助於減少所需的實際磁碟 I/O 運算元。兩種方法都可以表現良好，哪個更快取決於儲存引擎的細節和工作負載。
+在 B 樹中，查詢鍵涉及在 B 樹的每個層級讀取一個頁。由於層級數通常很小，這意味著從 B 樹讀取通常很快並且具有可預測的效能。在 LSM 儲存引擎中，讀取通常必須檢查處於不同壓實階段的幾個不同 SSTable，但布隆過濾器有助於減少所需的實際磁碟 I/O 運算元。兩種方法都可以表現良好，哪個更快取決於儲存引擎的細節和工作負載。
 
 範圍查詢在 B 樹上簡單而快速，因為它們可以使用樹的排序結構。在 LSM 儲存上，範圍查詢也可以利用 SSTable 排序，但它們需要並行掃描所有段並組合結果。布隆過濾器對範圍查詢沒有幫助（因為你需要計算範圍內每個可能鍵的雜湊，這是不切實際的），使得範圍查詢在 LSM 方法中比點查詢更昂貴 [^29]。
 
@@ -326,7 +326,7 @@ Redis 和 Couchbase 透過非同步寫入磁碟提供弱永續性。
 
 反直覺的是，記憶體資料庫的效能優勢不是因為它們不需要從磁碟讀取。即使是基於磁碟的儲存引擎，如果你有足夠的記憶體，也可能永遠不需要從磁碟讀取，因為作業系統無論如何都會在記憶體中快取最近使用的磁碟塊。相反，它們可以更快，因為它們可以避免將記憶體資料結構編碼為可以寫入磁碟的形式的開銷 [^49]。
 
-除了效能，記憶體資料庫的另一個有趣領域是提供難以使用基於磁碟的索引實現的資料模型。例如，Redis 為各種資料結構（例如優先佇列和集合）提供類似資料庫的介面。因為它將所有資料保留在記憶體中，其實現相對簡單。
+除了效能，記憶體資料庫的另一個有趣領域是提供了基於磁碟的索引難以實現的資料模型。例如，Redis 為各種資料結構（例如優先佇列和集合）提供類似資料庫的介面。因為它將所有資料保留在記憶體中，其實現相對簡單。
 
 
 ## 分析型資料儲存 {#sec_storage_analytics}