今天對一套環(huán)境的數(shù)據(jù)從SQL Server遷移到MySQL,中間涉及諸多的架構改進，我們主要說一下數(shù)據(jù)遷移的一些基本思路，以下是一個開始，會在后面不斷的迭代改進一些方案。

整體來說，遷移的數(shù)據(jù)量聽起來不是很多，大概是300G左右。

整體的步驟是：

1）數(shù)據(jù)從SQL Server導出為csv文件

2）數(shù)據(jù)流轉到MySQL中間服務器上

因為文件較大，比如有的文件有幾十G，單次導入會直接拋錯，所以需要做下切分，比如按照1000萬的數(shù)據(jù)維度切分。

3）數(shù)據(jù)切分

數(shù)據(jù)會被切分成相對規(guī)整的分片，比如按照1000萬的基準，一個4億數(shù)據(jù)量的文件會被切分為近40個500M的文件

4）因為切分后的文件太多，所以在導入前需要把這些任務劃分為幾個組

5）導入的時候，是按照并發(fā)進程的方式，因為數(shù)據(jù)庫后端已經(jīng)做了分片，所以就不需要調用是開啟太多的線程了。

6）數(shù)據(jù)通過中間件導入，數(shù)據(jù)落盤在多個分片節(jié)點上，物理分片是4個，每個物理分片上有4個邏輯分片，即一共有16個邏輯分片。

數(shù)據(jù)流程圖如下：

從目前的測試來看，如果是4個物理分片，通過中間件使用load data的方式，速度基本在80萬每秒。和單機的20萬相比，效率和性能是很明顯的。 

從目前的數(shù)據(jù)遷移來看，還是存在一些使用風險，一來轉儲數(shù)據(jù)為csv文件的時間較長，中間還涉及數(shù)據(jù)流轉和數(shù)據(jù)切分，等到數(shù)據(jù)真正導入的時候，流量和性能的損耗已經(jīng)很高了。 

目前的測試，有些分片節(jié)點的負載高達30以上，算是充分利用了服務器資源。

按照目前的基本數(shù)據(jù)情況，導入近70億數(shù)據(jù)需要2個小時左右，而這個過程還不包括中間環(huán)節(jié)的銜接和數(shù)據(jù)流轉，實際的時間會在近5個小時，從數(shù)據(jù)遷移窗口來算，這個時間明顯是不符合需求的，如果把時間控制在1個小時，有沒有更好的方法？