利用分片避免鎖住

分片在內容上是一個流程把大資料庫分離成小片段或稱碎片。經驗告訴我們一些描述發行到我們的資料庫可能花上可觀的執行時間。在這段期間資料庫是鎖住應用是不能用的。這意味我們對使用者產生了停機時間。

我們不能控制ALTER TABLE描述要花多久，但至少在ㄧ些市場流行的資料庫管理系統發行一個ALTER TABLE ADD COLUMN 描述不會導致鎖住。相較在我們遷移時於資料庫下的UPDATE 描述，我們可認定為鎖住時間。

安全的架設執行描述的時間跟被更新得資料與表格列數成正比。你選擇的一個單一UPDATE描述越多的資料和列數花越久的執行時間。我們分解我們的更新至多個碎片去最小化每一個描述的鎖住時間。

假設我們的帳戶表格有一百萬號碼連續例數。一個傳統的UPDATE描述增加10%總計如下：

UPDATE Account SET amount=amount*1.1;

假設這個敘述會花10秒,對我們使用者來說10秒停機時間不合理。或許兩秒是可接受的。我們拆分資料串敘述成為五個更小的碎片來達成兩秒停機時間。我們會有下列的UPDATE描述列:

UPDATE Account SET amount=amount*1.1;

WHERE number BETWEEN 1 AND 20000;

UPDATE Account SET amount=amount*1.1;

WHERE number BETWEEN 20001 AND 40000;

UPDATE Account SET amount=amount*1.1;

WHERE number BETWEEN 40001 AND 60000;

UPDATE Account SET amount=amount*1.1;

WHERE number BETWEEN 60001 AND 80000;

UPDATE Account SET amount=amount*1.1;

WHERE number BETWEEN 80001 AND 100000;

這就是用碎片背後的理由：最小化在UPDATE描述資料庫鎖住時間。你或許會抱怨會有各式的鎖住，這不是真正的零停機。然而零停機真正的目的是達成零中斷我們的使用者。你的商業行為會主宰允許資料庫鎖住的最大週期時間。

你該如何知道你的UPDATE描述在量產上所花的總時間？真相是你不知道。但我們可以透過持續演練遷移發行做更安全的賭注。

3.可能過度簡化計算這個執行時間但就教學目的,這是安全賭注

盡力的演練你的遷移

我們必須盡力強調必須演練我們的遷移在軟體開發產線的多重步驟。遷移操作長久資料有時錯誤的描述會造成量產上連續的災難。

你的維運團隊將可能有一個備援方案在手以防某些案例發生。但這狀況你要避免所有的成本。第一這導致應用不能用意味著停機時間。第二不是所有的錯誤都能提早偵測，透過備案置換你的資料。有時這要花上小時至天才發現資料處於不一致狀態，這已太遲從最後的備份去還原所有東西。

應在你自己的開發機開始遷移演練然後在每一個你的軟體開發產線階段重覆演練。

在遷移步驟檢查你的資料

我們要運行更安全，總是這樣，我們盡力的演練我們的遷移，我們依舊想要檢查不會在產線搞砸。

在你的每個發行後你應該檢查你的應用行為正確性不只本身還要檢查資料庫。

打開你資料庫的命令列介面(CLI) ，執行多個SELECT敘述並確保在執行新版本前確保每件事都正常。