這種拆分方式，對上層業務應用程序變動很小，只是需要改一下數據庫連接而已。盡管數據庫獨立了，但從本質上來講，並沒有優化這個業務的數據庫。在新的數據庫裡，此產品仍然在高速發展，每天都制造著大量的數據，表和索引越來越大，存儲空間達到了T級。由於此業務訪問的離散性，對存儲IOPS消耗極高，占用了大量的寶貴的存儲資源。為了減少這種消耗，我們首先在業務層面進行了優化，拿掉了一些不必要的產品功能，並加入了一些限制，控制了一部份不正常的數據增長；在數據庫層面，通過觀察SQL，發現了應用程序中可以改進的業務邏輯以及進行必要有索引調整；還有對有些業務點加上適當的前端的Cache策略。通過以上的改進，在一定程度上緩解了整個系統的壓力。 對整個系統的根本性改造，我們一直在探索。對於技術出身的我們來說，一個小小的xx業務系統，占用了這麼多的昂貴的存儲硬件資源與ORACLE軟件資源，心裡總有一些不平靜，要去改造它。而且這個業務系統仍然在不斷的膨脹，好幾個表的數據都超過了十億級，進行索引調整的難度越來越大，對於前端業務的不斷變化，這種調整又是必須的。采用集中式的Oracle數據庫方式，在前期，會在相當程度上減少前端應用程序的復雜性，但到了一定的規模過後，你會發現你要付出的代價也會呈指數級的增長，可維護性在逐漸降低。而且在這種高IOPS，高並發的情況下，數據庫也會很容易出問題。
從去年開始，taobao開始在一些小系統上采用MySQL數據庫，但使用的方式跟Oracle並沒有什麼不同。搭建master-slave主從復制結構，應用程序訪問master，slave只起到接管的作用。為了改造這個業務系統，采用這麼簡單的結構是不行的。我們確立了幾點目標，第一搭建一個分布式集群；第二集群采用廉價的PC；第三實現讀寫分離，slave也要承擔一定的業務讀；第四是用內存來支撐IOPS，不是硬盤。對於此項目業務的數據庫，根據什麼規則做sharding，又是擺在我們面前一個問題？在做這個架構設計的時候，我們sharding的原則，是要保證大量的訪問都是在單庫上完成的，不需要跨庫merge與sort。我們確立了基本方案過後，聯合開發與架構，細化了設計方案，在幾個月前，開始了這場攻堅。
因為是要對大表做數據的水平拆分，將數據拆分到多個數據庫上，有幾個重要的問題需要思考：
1.怎麼把在Oracle中幾十億的數據按規則遷到MySQL集群中；
2.如何產生主鍵唯一值；
3.大表根據規則拆成小表，具體拆分粒度是多少？每個庫多少表？
4.如何解決這麼多庫這麼多表的路由問題；
5.如何解決跨庫的merge與sort；
6.如何對連接進行管理；
7.如何做數據訂正；
8.我們需要開發哪些集群管理工具，比如說建表工具；
9.集群遇到停電怎麼辦？
10.如何對集群中的數據進行歷史遷移？
11.盡管集群采用廉價的PC，但具體采用何種PC,差別還是挺大的，如何平衡集群的規模與可管理性方面的問題?
12.集群對機房電力的消耗與機櫃占用問題?
在項目進行期間，DBA團隊先後進行了幾次數據遷移測試，在數據倉庫與SA團隊的幫助下，盡管經歷了一些困難與挑戰，但最終這些問題，大都一一解決。這個項目先後進行了三次程序發布，發布期間平滑遷移數據32億條左右，感謝負責此項目的DBA同事們與可敬可愛的開發工程師們。這個項目，也使得我們的分布式中間件有了進一步的發展與完善，大大減化了上層業務系統開發的復雜度，不必關心下層業務數據的存放邏輯，感謝架構團隊的精益求精。
項目發布後，經過觀察，各庫不管是master與slave,負載基本相同，但集群中各庫負載基本上都在6以上，稍微有點偏高。進行了一些SQL調化，主要是索引調整後，負載降到2以下。說起索引調整，這也是第一次對這麼大的MySQL集群做DDL，做一次大概需要好幾個小時。這個時間消耗，超過了自己的預期。
項目一期已經完成，二期很快又會啟動，如果你想不斷挑戰自我，實現自我價值，加入淘寶DBA團隊，這裡有一流的環境，成為一名優秀的MySQL DBA指日可待。
