大型互聯網應用去Oracle改造經驗總結

爲何要去Oracle

如今好像是個互聯網公司好像都在談去IOE，也有人問過咱們，去IOE到底有什麼受益？咱們公司爲何要去IOE呢？固然實際狀況是由於咱們上層領導決定的，因此咱們都熱火朝天的幹起來了，就跟咱們當時爲何將已經開發的系統從MySQL數據庫改爲Oralce同樣，都是上層領導決定的。對此我只能哈哈哈了。

可是我有本身的思考，爲何咱們要去Oracle呢？對咱們到底會帶來什麼受益呢？我我的以爲對於大型互聯網公司用MySQL替代Oracle的緣由有這樣一些。

大規模部署成本可大幅度下降

由於大型互聯網公司每每存儲很是大規模的數據，數據庫的讀寫流量也每每巨大，有數以千計的各類應用都須要用到數據庫，這樣購買硬件、軟件license的成本巨大，隨着業務不斷髮展，部署規模不斷增長，咱們的成本也將持續增長，這個賬應該很簡單，沒必要細算。所以從成本考量咱們是動力去作這個改造的。

可是我以爲規模可控範圍以內的企業級應用，而且數據價值極高的業務，好比典型的銀行，他們還依舊會選擇使用Oracle更加合適。

有財力養MySQL專家團隊能夠搞定一切

因爲互聯網的集中化部署和維護的特色，使得咱們開發和運維團隊的價值較高，所以大規模互聯網公司有財力聘請專門的MySQL專家技術團隊，這些專家能夠把MySQL的使用、部署、運維、原理源碼都搞得很是透徹，他們有能力搞定MySQL出現的一切問題，他們能夠針對本身公司的需求對MySQL作各類類型的定製和擴展，讓數據庫更加符合本身的需求，使用起來更加順手，與系統內部的技術體系結合得更加機密，好比雲平臺、自動化運維繫統等等。

固然這還由於MySQL是開源的，結構簡單，代碼量相對少，這樣專家團隊可以更容易的駕馭MySQL。

那爲何不少中小企互聯網公司也使用MySQL呢？那是由於MySQL的簡單、開源免費、開放，這符合小公司的不少特色，對於一些價值不高的數據存儲來講也沒有多大問題，並且中小互聯網公司的數據剛開始的價值都不過高，因此他們會選擇他。

因此，對於從可行性角度考慮咱們是可使用MySQL做爲本身的主要數據存儲服務器的。

改造前的架構

咱們要改造的系統是一個核心的業務系統，它是提供實時生成的業務系統，對於系統的穩定性要求高，天天產生的數據量也較大。目前Oracle數據庫服務器的狀況是這樣的架構。

當天系統數據架構存在的問題有這些：

• 共享的Oracle數據庫集羣，多個大型互聯網系統之間的耦合性很是重。一損俱損，一榮俱榮。
• 業務發展迅速，要求支持單日數據量1億，當前數據架構可擴展性受限。
• 公司總體技術戰略遷移到MySQL。MySQL的運維力量大大增長。
• Oracle的小型機沒法遷移到新的機房。

所以諸多重要因素決定了咱們必須遷移到基於MySQL的分佈式數據架構上。

改造後的架構

從圖中能夠看出，過渡期Oracle和MySQL兩個庫是同時共存的，兩個庫是一個互爲準備的關係，主庫的數據寫入會異步寫入到從庫上去。

上述爲改造後的數據架構的全貌，主要由這些要點。

• 業務操做日誌類數據遷移到Canssandra中。
• mysql分庫按照冷熱庫分開。
• 熱庫分爲256片，分佈在多個MySQL實例上。

改造以後的好處有這些。

• 核心業務庫的壓力大幅度降低，能夠承擔更多的業務量。
• 核心業務庫具有了較強的可擴展性，可以支持更多的業務量。
• 冷庫壓力不大能夠共享，冷熱分離能夠分開優化。

架構改造的挑戰

1.物流核心的業務系統，系統的可用性不能有任何影響。

2.共有81張業務表有待遷移，工程量巨大。

3.有1張表4億數據，4張1多條數據，這些核心業務數據遷移到MySQL後須要作分庫。

4.分庫後的跨庫join，跨庫事務沒法實現的問題須要解決。

5.下游的監控報表平臺、大數據平臺的數據接入須要調整。

架構改造設計和實現

選擇分庫實現方案

分庫策略設計

全局id生成

跨庫join解決方案

跨庫事務解決方案

平滑切換方案

數據同步方案