《MongoDB高手課》學習記錄（第二十四天）

寫在前面

第四章的內容就目前來看，有點失望。實際的東西很少，太理論，有點糊弄。說難據說太水了。特別像今天要學的內容，本覺得有不少乾貨，結果講本身的產品說了半天，測試版還得連線使用。就像極客時間上的《Vue開發實戰》課程，花了大量的時間去講 Ant Design，還沒講透。
好了，不吐槽了，換個角度看，也說明攢一門的不容易。開始今天的學習吧。

第二十四天

今天要學習的是《44 | 關係型數據庫遷移》、《45 | 數據庫遷移方式及工具》、《46 | Oracle遷移實戰》

從關係數據庫遷移到MongoDB的理由

1. 對於高併發的需求（數千-數十萬OPS），關係型數據庫不容易擴展（相對的）
2. 快速迭代，關係型模式太嚴謹（因此說模式設計很重要，預戴皇冠，必承其重）
3. 靈活的JSON模式
4. 大數據量需求
5. 地理位置查詢
6. 多數據中跨地域部署（關係數據庫不是不行，太光錢了）

應用遷移難度

1. 關係型數據庫之間遷移相對簡單
2. 但關係型到文檔型，則相對複雜

3. 須要考慮；

   1. 整體架構（好比單機式改爲分佈式）
   2. 模式設計（從關係模型改爲文檔模型）
   3. SQL語句/存儲過程/JDBC/ORM等
   4. 數據遷移（如何處理已有數據）

整體架構

這是說的三倍資源，是由於MongoDB推薦最少要部署3個結點。

模式設計

這個纔是重中之重，原本想先學習這章的目的也是這個

遷移的主戰場

數據遷移

接下來的重點也是放在了數據如何遷移上，固然是藉助工具的

數據庫導出導入

這塊是以MySQL爲例，先將表導出成csv文件，而後用mongoimport將csv的表數據，直接轉成文檔。
適用於直接換庫的場景

批量同步

主要就是藉助於ETL工具了，既然是批量處理，固然對系統的性能影響就比較大了，適用於按期結轉。好比將歷史交易記錄轉到查詢機，用於業務分析等

實時同步

固然仍是藉助於工具好比GoldenGate，只是因爲是小批量時時結轉，因此對系統的影響小，但若是出了問題就另說了

應用主導遷移

就是在團隊協助，在不影響業務的同時，一步一步將應用從關係數據庫遷移到文檔數據庫，固然投入就大了，週期也長，但最保險

數據遷移方式總結

遷移實戰

這就不說太了，就是介紹了一下tapdata的使用

附錄

Golden Gate
Talend
Pentaho(Kettle)
Informatica