fix a translation in ch6, suggested by @Lyianu

This commit is contained in:
Gang Yin 2023-09-24 10:18:14 +08:00
parent fcd2b77c0c
commit 3fc10b900e
2 changed files with 2 additions and 2 deletions

2
ch6.md
View File

@ -217,7 +217,7 @@ Cassandra 采取了折衷的策略【11, 12, 13】。Cassandra 中的表可以
#### 动态分区
对于使用键范围分区的数据库(请参阅 “[根据键的范围分区](#根据键的范围分区)”),具有固定边界的固定数量的分区将非常不便:如果出现边界错误,则可能会导致一个分区中的所有数据或者其他分区中的所有数据为空。手动重新配置分区边界将非常繁琐。
对于使用键范围分区的数据库(请参阅 “[根据键的范围分区](#根据键的范围分区)”),具有固定边界的固定数量的分区将非常不便:如果边界设置错误,可能会导致所有数据都在一个分区中,而其他分区则为空。手动重新配置分区边界将非常繁琐。
出于这个原因,按键的范围进行分区的数据库(如 HBase 和 RethinkDB会动态创建分区。当分区增长到超过配置的大小时在 HBase 上,默认值是 10GB会被分成两个分区每个分区约占一半的数据【26】。与之相反如果大量数据被删除并且分区缩小到某个阈值以下则可以将其与相邻分区合并。此过程与 B 树顶层发生的过程类似(请参阅 “[B 树](ch3.md#B树)”)。

View File

@ -217,7 +217,7 @@ Cassandra 採取了折衷的策略【11, 12, 13】。Cassandra 中的表可以
#### 動態分割槽
對於使用鍵範圍分割槽的資料庫(請參閱 “[根據鍵的範圍分割槽](#根據鍵的範圍分割槽)”),具有固定邊界的固定數量的分割槽將非常不便:如果出現邊界錯誤,則可能會導致一個分割槽中的所有資料或者其他分割槽中的所有資料為空。手動重新配置分割槽邊界將非常繁瑣。
對於使用鍵範圍分割槽的資料庫(請參閱 “[根據鍵的範圍分割槽](#根據鍵的範圍分割槽)”),具有固定邊界的固定數量的分割槽將非常不便:如果邊界設定錯誤,可能會導致所有資料都在一個分割槽中,而其他分割槽則為空。手動重新配置分割槽邊界將非常繁瑣。
出於這個原因,按鍵的範圍進行分割槽的資料庫(如 HBase 和 RethinkDB會動態建立分割槽。當分割槽增長到超過配置的大小時在 HBase 上,預設值是 10GB會被分成兩個分割槽每個分割槽約佔一半的資料【26】。與之相反如果大量資料被刪除並且分割槽縮小到某個閾值以下則可以將其與相鄰分割槽合併。此過程與 B 樹頂層發生的過程類似(請參閱 “[B 樹](ch3.md#B樹)”)。