在淘寶，有一個業務系統，在一年半以前，這個業務系統很小，訪問量很低，相關的表跟核心數據庫放在一起，後來由於產品升級，新產品的許多功能很受會員的喜愛，會員大量使用，很快就對核心數據庫造成了相當程度的IOPS衝擊與威脅，也迅速消耗着核心存儲的空間，爲了不影響淘寶的核心業務，我們將此業務相關的表遷移出了核心庫，創建了一個獨立的ORACLE數據庫，這種拆分數據庫的方式，就是大家常說的垂直拆分。
這種拆分方式，對上層業務應用程序變動很小，只是需要改一下數據庫連接而已。儘管數據庫獨立了，但從本質上來講，並沒有優化這個業務的數據庫。在新的數據庫裏，此產品仍然在高速發展，每天都製造着大量的數據，表和索引越來越大，存儲空間達到了T級。由於此業務訪問的離散性，對存儲IOPS消耗極高，佔用了大量的寶貴的存儲資源。爲了減少這種消耗，我們首先在業務層面進行了優化，拿掉了一些不必要的產品功能，並加入了一些限制，控制了一部份不正常的數據增長；在數據庫層面，通過觀察MySQL，發現了應用程序中可以改進的業務邏輯以及進行必要有索引調整；還有對有些業務點加上適當的前端的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以上，稍微有點偏高。進行了一些MySQL調化，主要是索引調整後，負載降到2以下。說起索引調整，這也是第一次對這麼大的mysql集羣做DDL，做一次大概需要好幾個小時。這個時間消耗，超過了自己的預期。
項目一期已經完成，二期很快又會啓動，如果你想不斷挑戰自我，實現自我價值，加入淘寶DBA團隊，這裏有一流的環境，成爲一名優秀的mysql DBA指日可待。
文章來源http://zhaolinjnu.blog.sohu.com/116545760.html