remove redundant spaces

ch3.md

@@ -197,7 +197,7 @@ Lucene，是一种全文搜索的索引引擎，在 Elasticsearch 和 Solr 被
 
 #### 性能优化
 
-与往常一样，要让存储引擎在实践中表现良好涉及到大量设计细节。例如，当查找数据库中不存在的键时，LSM 树算法可能会很慢：你必须先检查内存表，然后查看从最近的到最旧的所有的段（可能还必须从硬盘读取每一个段文件），然后才能确定这个键不存在。为了优化这种访问，存储引擎通常使用额外的布隆过滤器（Bloom filters）【15】。 （布隆过滤器是一种节省内存的数据结构，用于近似表达集合的内容，它可以告诉你数据库中是否存在某个键，从而为不存在的键节省掉许多不必要的硬盘读取操作。)
+与往常一样，要让存储引擎在实践中表现良好涉及到大量设计细节。例如，当查找数据库中不存在的键时，LSM 树算法可能会很慢：你必须先检查内存表，然后查看从最近的到最旧的所有的段（可能还必须从硬盘读取每一个段文件），然后才能确定这个键不存在。为了优化这种访问，存储引擎通常使用额外的布隆过滤器（Bloom filters）【15】。（布隆过滤器是一种节省内存的数据结构，用于近似表达集合的内容，它可以告诉你数据库中是否存在某个键，从而为不存在的键节省掉许多不必要的硬盘读取操作。）
 
 还有一些不同的策略来确定 SSTables 被压缩和合并的顺序和时间。最常见的选择是 size-tiered 和 leveled compaction。LevelDB 和 RocksDB 使用 leveled compaction（LevelDB 因此得名），HBase 使用 size-tiered，Cassandra 同时支持这两种【16】。对于 sized-tiered，较新和较小的 SSTables 相继被合并到较旧的和较大的 SSTable 中。对于 leveled compaction，key （按照分布范围）被拆分到较小的 SSTables，而较旧的数据被移动到单独的层级（level），这使得压缩（compaction）能够更加增量地进行，并且使用较少的硬盘空间。
 

ch4.md

@@ -47,7 +47,7 @@
 
 [^i]: 除一些特殊情况外，例如某些内存映射文件或直接在压缩数据上操作（如 “[列压缩](ch3.md#列压缩)” 中所述）。
 
-所以，需要在两种表示之间进行某种类型的翻译。 从内存中表示到字节序列的转换称为 **编码（Encoding）** （也称为 **序列化（serialization）** 或 **编组（marshalling）**），反过来称为 **解码（Decoding）**[^ii]（**解析（Parsing）**，**反序列化（deserialization）**，**反编组 (unmarshalling）**）[^译i]。
+所以，需要在两种表示之间进行某种类型的翻译。从内存中表示到字节序列的转换称为 **编码（Encoding）** （也称为 **序列化（serialization）** 或 **编组（marshalling）**），反过来称为 **解码（Decoding）**[^ii]（**解析（Parsing）**，**反序列化（deserialization）**，**反编组（unmarshalling）**）[^译i]。
 
 [^ii]: 请注意，**编码（encode）**  与 **加密（encryption）** 无关。本书不讨论加密。
 [^译i]: Marshal 与 Serialization 的区别：Marshal 不仅传输对象的状态，而且会一起传输对象的方法（相关代码）。

ch6.md

@@ -64,7 +64,7 @@
 
 键的范围不一定均匀分布，因为数据也很可能不均匀分布。例如在 [图 6-2](img/fig6-2.png) 中，第 1 卷包含以 A 和 B 开头的单词，但第 12 卷则包含以 T、U、V、X、Y 和 Z 开头的单词。只是简单的规定每个卷包含两个字母会导致一些卷比其他卷大。为了均匀分配数据，分区边界需要依据数据调整。
 
-分区边界可以由管理员手动选择，也可以由数据库自动选择（我们会在 “[分区再平衡](#分区再平衡)” 中更详细地讨论分区边界的选择）。 Bigtable 使用了这种分区策略，以及其开源等价物 HBase 【2, 3】，RethinkDB 和 2.4 版本之前的 MongoDB 【4】。
+分区边界可以由管理员手动选择，也可以由数据库自动选择（我们会在 “[分区再平衡](#分区再平衡)” 中更详细地讨论分区边界的选择）。Bigtable 使用了这种分区策略，以及其开源等价物 HBase 【2, 3】、RethinkDB 和 2.4 版本之前的 MongoDB 【4】。
 
 在每个分区中，我们可以按照一定的顺序保存键（请参阅 “[SSTables 和 LSM 树](ch3.md#SSTables和LSM树)”）。好处是进行范围扫描非常简单，你可以将键作为联合索引来处理，以便在一次查询中获取多个相关记录（请参阅 “[多列索引](ch3.md#多列索引)”）。例如，假设我们有一个程序来存储传感器网络的数据，其中主键是测量的时间戳（年月日时分秒）。范围扫描在这种情况下非常有用，因为我们可以轻松获取某个月份的所有数据。
 

zh-tw/ch3.md

@@ -197,7 +197,7 @@ Lucene，是一種全文搜尋的索引引擎，在 Elasticsearch 和 Solr 被
 
 #### 效能最佳化
 
-與往常一樣，要讓儲存引擎在實踐中表現良好涉及到大量設計細節。例如，當查詢資料庫中不存在的鍵時，LSM 樹演算法可能會很慢：你必須先檢查記憶體表，然後檢視從最近的到最舊的所有的段（可能還必須從硬碟讀取每一個段檔案），然後才能確定這個鍵不存在。為了最佳化這種訪問，儲存引擎通常使用額外的布隆過濾器（Bloom filters）【15】。 （布隆過濾器是一種節省記憶體的資料結構，用於近似表達集合的內容，它可以告訴你資料庫中是否存在某個鍵，從而為不存在的鍵節省掉許多不必要的硬碟讀取操作。)
+與往常一樣，要讓儲存引擎在實踐中表現良好涉及到大量設計細節。例如，當查詢資料庫中不存在的鍵時，LSM 樹演算法可能會很慢：你必須先檢查記憶體表，然後檢視從最近的到最舊的所有的段（可能還必須從硬碟讀取每一個段檔案），然後才能確定這個鍵不存在。為了最佳化這種訪問，儲存引擎通常使用額外的布隆過濾器（Bloom filters）【15】。（布隆過濾器是一種節省記憶體的資料結構，用於近似表達集合的內容，它可以告訴你資料庫中是否存在某個鍵，從而為不存在的鍵節省掉許多不必要的硬碟讀取操作。）
 
 還有一些不同的策略來確定 SSTables 被壓縮和合並的順序和時間。最常見的選擇是 size-tiered 和 leveled compaction。LevelDB 和 RocksDB 使用 leveled compaction（LevelDB 因此得名），HBase 使用 size-tiered，Cassandra 同時支援這兩種【16】。對於 sized-tiered，較新和較小的 SSTables 相繼被合併到較舊的和較大的 SSTable 中。對於 leveled compaction，key （按照分佈範圍）被拆分到較小的 SSTables，而較舊的資料被移動到單獨的層級（level），這使得壓縮（compaction）能夠更加增量地進行，並且使用較少的硬碟空間。
 

zh-tw/ch4.md

@@ -47,7 +47,7 @@
 
 [^i]: 除一些特殊情況外，例如某些記憶體對映檔案或直接在壓縮資料上操作（如 “[列壓縮](ch3.md#列壓縮)” 中所述）。
 
-所以，需要在兩種表示之間進行某種型別的翻譯。 從記憶體中表示到位元組序列的轉換稱為 **編碼（Encoding）** （也稱為 **序列化（serialization）** 或 **編組（marshalling）**），反過來稱為 **解碼（Decoding）**[^ii]（**解析（Parsing）**，**反序列化（deserialization）**，**反編組 (unmarshalling）**）[^譯i]。
+所以，需要在兩種表示之間進行某種型別的翻譯。從記憶體中表示到位元組序列的轉換稱為 **編碼（Encoding）** （也稱為 **序列化（serialization）** 或 **編組（marshalling）**），反過來稱為 **解碼（Decoding）**[^ii]（**解析（Parsing）**，**反序列化（deserialization）**，**反編組（unmarshalling）**）[^譯i]。
 
 [^ii]: 請注意，**編碼（encode）**  與 **加密（encryption）** 無關。本書不討論加密。
 [^譯i]: Marshal 與 Serialization 的區別：Marshal 不僅傳輸物件的狀態，而且會一起傳輸物件的方法（相關程式碼）。

zh-tw/ch6.md

@@ -64,7 +64,7 @@
 
 鍵的範圍不一定均勻分佈，因為資料也很可能不均勻分佈。例如在 [圖 6-2](../img/fig6-2.png) 中，第 1 捲包含以 A 和 B 開頭的單詞，但第 12 卷則包含以 T、U、V、X、Y 和 Z 開頭的單詞。只是簡單的規定每個捲包含兩個字母會導致一些卷比其他卷大。為了均勻分配資料，分割槽邊界需要依據資料調整。
 
-分割槽邊界可以由管理員手動選擇，也可以由資料庫自動選擇（我們會在 “[分割槽再平衡](#分割槽再平衡)” 中更詳細地討論分割槽邊界的選擇）。 Bigtable 使用了這種分割槽策略，以及其開源等價物 HBase 【2, 3】，RethinkDB 和 2.4 版本之前的 MongoDB 【4】。
+分割槽邊界可以由管理員手動選擇，也可以由資料庫自動選擇（我們會在 “[分割槽再平衡](#分割槽再平衡)” 中更詳細地討論分割槽邊界的選擇）。Bigtable 使用了這種分割槽策略，以及其開源等價物 HBase 【2, 3】、RethinkDB 和 2.4 版本之前的 MongoDB 【4】。
 
 在每個分割槽中，我們可以按照一定的順序儲存鍵（請參閱 “[SSTables 和 LSM 樹](ch3.md#SSTables和LSM樹)”）。好處是進行範圍掃描非常簡單，你可以將鍵作為聯合索引來處理，以便在一次查詢中獲取多個相關記錄（請參閱 “[多列索引](ch3.md#多列索引)”）。例如，假設我們有一個程式來儲存感測器網路的資料，其中主鍵是測量的時間戳（年月日時分秒）。範圍掃描在這種情況下非常有用，因為我們可以輕鬆獲取某個月份的所有資料。