mirror of
https://github.com/Vonng/ddia.git
synced 2024-12-06 15:20:12 +08:00
Merge pull request #99 from mrdrivingduck/master
ch6: fix the word rebalancing
This commit is contained in:
commit
72a79db945
2
ch6.md
2
ch6.md
@ -173,7 +173,7 @@
|
||||
* 数据集大小增加,所以您想添加更多的磁盘和RAM来存储它。
|
||||
* 机器出现故障,其他机器需要接管故障机器的责任。
|
||||
|
||||
所有这些更改都需要数据和请求从一个节点移动到另一个节点。 将负载从集群中的一个节点向另一个节点移动的过程称为**再平衡(reblancing)**。
|
||||
所有这些更改都需要数据和请求从一个节点移动到另一个节点。 将负载从集群中的一个节点向另一个节点移动的过程称为**再平衡(rebalancing)**。
|
||||
|
||||
无论使用哪种分区方案,再平衡通常都要满足一些最低要求:
|
||||
|
||||
|
2
ch7.md
2
ch7.md
@ -324,7 +324,7 @@ SELECT COUNT(*)FROM emails WHERE recipient_id = 2 AND unread_flag = true
|
||||
|
||||
与读取提交的隔离类似,快照隔离的实现通常使用写锁来防止脏写(请参阅“[读已提交](#读已提交)”),这意味着进行写入的事务会阻止另一个事务修改同一个对象。但是读取不需要任何锁定。从性能的角度来看,快照隔离的一个关键原则是:**读不阻塞写,写不阻塞读**。这允许数据库在处理一致性快照上的长时间查询时,可以正常地同时处理写入操作。且两者间没有任何锁定争用。
|
||||
|
||||
为了实现快照隔离,数据库使用了我们看到的用于防止[图7-4]()中的脏读的机制的一般化。数据库必须可能保留一个对象的几个不同的提交版本,因为各种正在进行的事务可能需要看到数据库在不同的时间点的状态。因为它并排维护着多个版本的对象,所以这种技术被称为**多版本并发控制(MVCC, multi-version concurrentcy control)**。
|
||||
为了实现快照隔离,数据库使用了我们看到的用于防止[图7-4]()中的脏读的机制的一般化。数据库必须可能保留一个对象的几个不同的提交版本,因为各种正在进行的事务可能需要看到数据库在不同的时间点的状态。因为它并排维护着多个版本的对象,所以这种技术被称为**多版本并发控制(MVCC, multi-version concurrency control)**。
|
||||
|
||||
如果一个数据库只需要提供**读已提交**的隔离级别,而不提供**快照隔离**,那么保留一个对象的两个版本就足够了:提交的版本和被覆盖但尚未提交的版本。支持快照隔离的存储引擎通常也使用MVCC来实现**读已提交**隔离级别。一种典型的方法是**读已提交**为每个查询使用单独的快照,而**快照隔离**对整个事务使用相同的快照。
|
||||
|
||||
|
@ -173,7 +173,7 @@
|
||||
* 資料集大小增加,所以您想新增更多的磁碟和RAM來儲存它。
|
||||
* 機器出現故障,其他機器需要接管故障機器的責任。
|
||||
|
||||
所有這些更改都需要資料和請求從一個節點移動到另一個節點。 將負載從叢集中的一個節點向另一個節點移動的過程稱為**再平衡(reblancing)**。
|
||||
所有這些更改都需要資料和請求從一個節點移動到另一個節點。 將負載從叢集中的一個節點向另一個節點移動的過程稱為**再平衡(rebalancing)**。
|
||||
|
||||
無論使用哪種分割槽方案,再平衡通常都要滿足一些最低要求:
|
||||
|
||||
|
@ -324,7 +324,7 @@ SELECT COUNT(*)FROM emails WHERE recipient_id = 2 AND unread_flag = true
|
||||
|
||||
與讀取提交的隔離類似,快照隔離的實現通常使用寫鎖來防止髒寫(請參閱“[讀已提交](#讀已提交)”),這意味著進行寫入的事務會阻止另一個事務修改同一個物件。但是讀取不需要任何鎖定。從效能的角度來看,快照隔離的一個關鍵原則是:**讀不阻塞寫,寫不阻塞讀**。這允許資料庫在處理一致性快照上的長時間查詢時,可以正常地同時處理寫入操作。且兩者間沒有任何鎖定爭用。
|
||||
|
||||
為了實現快照隔離,資料庫使用了我們看到的用於防止[圖7-4]()中的髒讀的機制的一般化。資料庫必須可能保留一個物件的幾個不同的提交版本,因為各種正在進行的事務可能需要看到資料庫在不同的時間點的狀態。因為它並排維護著多個版本的物件,所以這種技術被稱為**多版本併發控制(MVCC, multi-version concurrentcy control)**。
|
||||
為了實現快照隔離,資料庫使用了我們看到的用於防止[圖7-4]()中的髒讀的機制的一般化。資料庫必須可能保留一個物件的幾個不同的提交版本,因為各種正在進行的事務可能需要看到資料庫在不同的時間點的狀態。因為它並排維護著多個版本的物件,所以這種技術被稱為**多版本併發控制(MVCC, multi-version concurrency control)**。
|
||||
|
||||
如果一個數據庫只需要提供**讀已提交**的隔離級別,而不提供**快照隔離**,那麼保留一個物件的兩個版本就足夠了:提交的版本和被覆蓋但尚未提交的版本。支援快照隔離的儲存引擎通常也使用MVCC來實現**讀已提交**隔離級別。一種典型的方法是**讀已提交**為每個查詢使用單獨的快照,而**快照隔離**對整個事務使用相同的快照。
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user