??需求變更是信息化過程中的家常便飯，而在變更過程中如何盡可能小的影響在線業(yè)務(wù)是比較頭疼的事情。舉個(gè)車聯(lián)網(wǎng)監(jiān)控的例子：原終端設(shè)備上傳車輛的經(jīng)緯度數(shù)據(jù)，新的終端設(shè)備支持同時(shí)上傳速度數(shù)據(jù)，而舊的車輛狀態(tài)表數(shù)據(jù)量超過億級(jí)，此時(shí)如果Alter table add column將會(huì)造成數(shù)據(jù)表上鎖，導(dǎo)致上傳或查詢車輛狀態(tài)數(shù)據(jù)等待。AppBoxFuture的存儲(chǔ)引擎在設(shè)計(jì)之初也是采用鎖表的方案，后來考慮到上述應(yīng)用場景決定支持online schema change，但帶來了另一個(gè)難題是如何保證分布式環(huán)境下的一致性。

??在權(quán)衡了利弊后，作者決定采用如下草圖所示的變更方案，主要是考慮工程實(shí)現(xiàn)上的便利性。實(shí)現(xiàn)的關(guān)鍵點(diǎn)是實(shí)體模型內(nèi)有SchemaVersion標(biāo)記，在添加刪除列、索引、EntityRef引用外鍵時(shí)，SchemaVersion+1, 同時(shí)所有表分區(qū)的狀態(tài)機(jī)內(nèi)也有SchemaVersion標(biāo)記當(dāng)前的版本，如果變更過程中有舊版本的Insert\Update\Delete命令，則拋出SchemaChanged錯(cuò)誤，由上層邏輯加載新的模型后重試。該方案的優(yōu)點(diǎn)是實(shí)現(xiàn)簡單，且變更過程對在線業(yè)務(wù)的影響較小，缺點(diǎn)是變更任務(wù)不支持回滾，如遇到網(wǎng)絡(luò)或磁盤錯(cuò)誤則任務(wù)會(huì)稍候重試（冪等），添加惟一索引例外，遇到主鍵沖突任務(wù)不會(huì)重試，改為通知上層刪除該索引。

??作者在虛擬機(jī)（I74C8G）內(nèi)做了個(gè)單分區(qū)80萬行記錄添加列變更性能測試，如下動(dòng)圖所示：

測試結(jié)果如下約0.8秒就處理完一個(gè)分區(qū)80萬行記錄：

#01/17/2019 11:17:07 [Debug] [StoreService.UpdateModelAsync]: Entity[VehicleState] schema changed, 2 -> 3 MetaAlterTable::TryRunAsTask: 開始提議分區(qū)變更任務(wù)至68719476742 MetaAlterTable::TryRunAsTask: 分區(qū)提議成功68719476742 KVAlterPartion::TryRunAsTask: 分區(qū)批次處理完成 MetaAlterTable::TryRunAsTask: all partition done, elapsed time:0.847791s MetaAlterTableDone::Apply: 移除變更任務(wù), 剩余任務(wù):0 KVAlterPartionDone::Apply: 移除分區(qū)變更任務(wù), 剩余任務(wù):0

??如果您有問題或Bug報(bào)告，請留言或在Github提交Issue。

轉(zhuǎn)載于:https://www.cnblogs.com/BaiCai/p/10284611.html

總結(jié)

以上是生活随笔為你收集整理的AppBoxFuture(四). 随需而变-Online Schema Change的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。