[[194803]]

現(xiàn)在NoSQL流行，有一個原因也是因為不需要去刻意處理table的schema，直接存儲數(shù)據(jù)，這樣簡單!所以也不會有數(shù)據(jù)庫表的遷移問題。數(shù)據(jù)庫表遷移這一塊兒一直是一個麻煩點，但我最近用了sqlite3做了個小項目，所以總結(jié)下數(shù)據(jù)庫遷移的方案。

原理

1. 每一次數(shù)據(jù)表改動，都對應(yīng)一個數(shù)據(jù)庫版本號
2. 數(shù)據(jù)遷移是漸進式的，比如把數(shù)據(jù)庫版本從1 升級到n，那么就升級n-1次，版本1到2，2到3，直到n-1到n。

實施

1. 使用sqlite3的user_version 存貯自定義的數(shù)據(jù)庫版 

/*設(shè)置版本號*/ 
 
PRAGMA user_version=1; 
 
/*讀取版本號*/ 
 
PRAGMA user_version;  

 2. 所有的數(shù)據(jù)庫升級文件，放在一個文件中，都直接使用sql文件，方便直接查看管理。文件結(jié)構(gòu)如下

文件結(jié)構(gòu)設(shè)計

• v1.sql v2.sql, v3.sql等 是每個數(shù)據(jù)庫版本，完整的數(shù)據(jù)庫定義文件
• v1tov2.sql, v2tov3.sql等 是間隔版本數(shù)據(jù)庫升級文件。一個數(shù)據(jù)m到n升級的過程就是，運行 v[m]tov[m+1].sql, v[m+1]tov[m+2].sql, 直到 v[n-1]tov[n].sql
• run.sh 就是每次要跑的數(shù)據(jù)遷移腳本，包括了當前的版本號和遷移邏輯
• 其中的v2.sql 到v[n].sql 不是必須的，只是為了方便查看當前***的數(shù)據(jù)表設(shè)計，如果存在v[n].sql 那么創(chuàng)建新數(shù)據(jù)庫也可以直接從這個文件來創(chuàng)建

3. 遷移腳本如下， 具體邏輯注釋中已經(jīng)寫明

4. v[n].sql 和v[n-1]tov[n].sql 文件的***都去需要通過user_version來設(shè)置數(shù)據(jù)版本為n，一個v2tov3.sql 的demo如下：

總結(jié)

使用場景

目前這套方案適合數(shù)據(jù)量小，對停機維護可以接受的業(yè)務(wù)情況，因為需要停機升級，但是這個方案，足夠簡單清晰且能滿足所有不同版本間的數(shù)據(jù)升級。

不足與展望

1. 這個方案沒有考慮到數(shù)據(jù)升級失敗的回滾。由于是小業(yè)務(wù)，所以考慮更多的是簡單易維護。所以針對這種情況的，首先要保證升級腳本經(jīng)過了足夠的線上數(shù)據(jù)測試，經(jīng)的起考驗。其次，一旦發(fā)生問題，線上可以直接操作維護，寫腳本。這樣說，因為你都沒有測試到這種需要rollback的case，你也不能在寫升級腳本的時候，知道這種case是怎樣，所以提前寫好rollback的邏輯不一定可行或者合適。
2. 部署時，數(shù)據(jù)遷移之前要備份，數(shù)據(jù)量較大些，用增量備份，節(jié)省時間。備份有成熟的工具，而且備份方便升級失敗時rollback。部署的步驟應(yīng)該是: 拉代碼build(或者拉docker鏡像)-> 備份數(shù)據(jù)庫 -> 升級數(shù)據(jù)庫 -> 跑新的代碼
3. 對于Android，iOS的設(shè)備中使用sqlite3的情況，數(shù)據(jù)遷移的邏輯是一樣。sql文件結(jié)構(gòu)設(shè)計可以重用，也可以寫到代碼里去管理。遷移腳本需要轉(zhuǎn)換成native的Java或者Objective-C，Swift的代碼。
4. 對于更大的業(yè)務(wù)，多實例的的數(shù)據(jù)庫遷移可以使用Flyway