據我們了解在整個從小型機到PC server的遷移，包含從Oracle到MySQL數據庫的遷移，你們在做這個事情的時候。都做過好幾個月的壓力測試。你講講這個背景和故事。
是這樣的，今年我們年初決定。我們商品庫從小型機遷到PC server上面去，這是淘寶壓力最大的一個數據庫，當時是用四臺小型機加兩個高端存儲來支撐的。要把這麽大一個數據庫進行遷移。我們心裏面也是沒有底的，由於不知道要多少臺PC server可以支撐。須要什麽樣的配置來支撐這個壓力？當時我們可以想到一個非常直觀的想法就是模擬線上全然一樣的壓力。甚至加上幾倍的壓力來測它的極限值。
我們和開發團隊、我們的性能測試團隊，加上DBA團隊和ops團隊，成立了一個非常大的項目組，然後做了接近兩個月的性能測試，在整個測試過程中發現了非常多的問題，包含我們給Oracle、MySQL等廠商都提交了非常多Bug，有些Bug也得到廠商回應。進行修復。

那總體的轉變的過程到如今進行到了什麽樣的程度？包含你在整個轉變的過程中遇到哪些問題？?
我們如今最核心的用戶數據庫今年已經徹底完畢了從小型機、存儲和Oracle切入到PC server加MySQL的架構。
我們內部有一個提法叫做去O、去I、去E。事實上就是我們要從高端硬件Scale up模式到低端硬件的Scal out水平擴展的模式，這是淘寶內部最大最核心的系統。今年已經順利完畢了全部區的水平擴展。其它幾個系統，比方說交易和商品已經完畢了一部分，完畢了水平拆分的一部分，可是沒有達到我們希望的進度。這可能是明年我們須要做的事情。

在轉型過程中主要遇到哪些問題？?
讓我們認為比較大的問題就是我們從可靠的小型機遷移到大規模，大數據量的PC server上來，從架構上就對我們就是一個非常大的挑戰。大家都知道。每個PC server的穩定性肯定和單臺小型機會有一定的差距。再加上我們一個機群有可能是32臺或者64臺PC server。

每一臺PC server即使有四個9的可用性。但假設我們整個系統合在一起。可能它最後的兩個9的可用性都達不到。

這就須要我們從軟件層、架構層要做非常多的改進。可以要讓單點的一些失效對總體的系統不造成不論什麽影響，由於我們和架構部門、開發部門一起做了非常多事情，才幹保證我們的集群穩定上線。

事實上“雙十一”這個時間應該說是對過去的技術轉變的檢驗，如今回頭來看，這個檢驗的結果怎麽樣？?
當時是有點提心吊膽的，之後又認為相對來說今年我們做的非常多事情還是非常成功的。可是如今再回頭細致想想還是有點後怕，“雙十一”那天的淩晨零點不是有一次Ipad的秒殺嗎。當天晚上我們都在線上觀察數據，在零點的一瞬間，就看到全部數據庫指標已經達到了曾經正常時候最高峰的指標，有些甚至還超過了。

當天晚上睡覺的時候心裏就有點在打鼓：才零點就這個樣子了，明天下午明天晚上最高峰的時候我們應該怎麽渡過？所以第二天早上八點多的時候我們一進到指揮部裏面就看到全部的指標， 包含CDN的指標、各個業務線的指標、數據庫的指標都是噌噌的往上漲，這時心裏面事實上是非常忐忑不安的。

可是我們比較放心的是這三大核心系統，商品、用戶和交易，在我們今年全部的水平擴展項目做完了以後，比方說商品功能做完了以後。從我們的機械壓測裏面它是有十倍的流量的，所以當天百分之中的一個百，百分之兩百的流量基本上對數據庫沒有造成太大的影響，所以當時還是非常開心的看到這個指標高速的往上漲，希望交易可以通過10個億、20個億，我認為都是可以承受的。

那對於整個數據庫架構的演進下一步有什麽打算？?
下一步事實上就是剛剛說的我們有幾個核心系統還沒有全然的做到這個水平擴展，加上“雙十一”那天我們還是有一個小驚險：我們有一個數據庫，跟交易核心有一點點聯系的，但它還是放在小型機上面。當時已經提前為它準備了百分之中的一個百的余量，就是說它可以承擔平時最高壓力的兩倍。
可是那天已經達到平時最高壓力的1.8倍左右的時候，把我們嚇出了一身冷汗。假設當時淘寶的交易最高峰的流量再增長20%的話，有可能數據庫就會到瓶頸了。

所以我們明年是要把很多其它這樣的Scale up可以看到天花板的數據庫全部要拆分成水平庫存這樣的數據庫。

那你剛才所提到的去Oracle，去小型機。去高端存儲，這個“三去”的總體思路給淘寶網帶來了哪些經濟上的效應？?
當時我們知道小型機和存儲的價格是非常昂貴的，還是拿我們剛才說壓力最大的商品數據庫舉個樣例，當初我們數據庫是用了四臺高端的小型機。兩套高端的存儲，成本加起來起碼都是三千萬以上。

那眼下我們用的是32臺PC server來搭建的一個機群，價格也就是300萬~500萬的級別。相對來說我們做完這個事情以後。攻克了兩三千萬的硬件成本。

這樣來講。總體的經濟效益還是非常不錯的。可是事實上剛才我們在前期溝通的時候也提到，你要從Oracle轉到MySQL，包含從小型機轉到PC server。事實上裏面還是會遇到蠻多問題的，包含它的不穩定性等等。那對於這一方面你有沒有什麽經驗可談？
在這一方面，我認為有兩個非常重要的因素。第一個是我們須要和我們的開發前端應用架構部門可以緊密的合作，可以讓我們的應用融入剛才說的整個機群的單點失效和容災的問題。

都須要我們和架構部門一起來考慮的；第二個比較大的經驗就是眼下我們在做的。深入研究MySQL的源碼。我們從研究和壓力測試的過程中。發現MySQL它本身代碼的一些缺陷。可能在高並發大壓力下會有非常多隱藏的Bug。
在我們近期的這次測試其中。我們還發現了Facebook公布的FlashCache二級緩存的軟件。當時我們是測出它一個非常大的Bug：並發壓力非常大的情況下，它會導致MySQL成為一個僵屍進程。

我們發現了以後。非常快反饋給Face book，然後Face book非常快就修復了這個問題，這也是我們對使用開源軟件帶來更大的一個信心，就是開源可以在全球得到很多其它的支持，大家都可以從原代碼層面來解決更深層次的一個問題。

我想這也可能是淘寶技術團隊如今那麽開放，那麽註重開源的動力之中的一個。那假設說想對MySQL的一些核心代碼做編譯，就須要對人才的儲備，包含各方面資源整合的要求還是蠻大的，那你在這方面有沒有什麽感觸？
說到人才這個話題。08年的時候，淘寶當時準備大規模的往MySQL方向上轉。我們內部也是有一些置疑的聲音。他們說淘寶DDA團隊曾經都是在Oracle方面比較專精，在業界來說，淘寶的DDA團隊在Oracle方面更加有名氣一些。所以我們內部有置疑的聲音。就是說你們有MySQL專家嗎，MySQL出問題了以後能非常快的解決嗎？所以從08年到如今，我們慢慢的一路走過來，內部培養了非常多的MySQL的人才，包含這幾年我們的應屆生的成長。再加上我們從外部招到一些專家，我們對MySQL的理解已經越來越深。
剛才說到，我們已經可以給MySQL打Patch。已經可以給MySQL report這些Bug。到如今為止。我認為MySQL的成長已經達到了非常高的一個程度。我們對MySQL已經越來越有信心，可是未來淘寶的MySQL肯定是要做得越來越大的，淘寶還有非常多小型機上面擴展不太easy的系統須要遷移到可擴展的機群上面來，但我們也希望業界可以有很多其它的MySQL夥伴增加我們。和我們一起來做這麽一件非常有意義的事情。

我想可以增加到淘寶的技術團隊，去經歷那麽多有大交易量的技術實踐還是非常寶貴的。另外一個問題就是盡管說如今我們用的越來越多的是MySQL。可是如今大家也知道MySQL已經被Oracle收購了，那對像淘寶這樣的團隊有什麽影響呢？
大家都知道MySQL事實上是基於GPL的協議來開源的軟件，那淘寶在使用過程中，前期是已經考慮到一些風險。所以我們全部的MySQL都是自己來做編譯做優化的，並且我想MySQL被Oracle收購了以後。如今看起來Oracle應該是給MySQL在開發這方面是提供了更大的幫助，像之前在Sun的時候，MySQL的版本號相對來說是比較混亂的，包含我們如今在用的5.0和5.1的正式版本號，近期還有包含開發方面就還有兩個。一個6.0，一個5.4。這些特性會互相交織在一起，讓我們選擇的時候也有點不知道究竟選哪個版本號會更好一點。

但如今Oracle收購MySQL以後，他把5.4跟6.0這些版本號已經合成了一個比較規範的5.5的版本號，並且為它制訂了非常好的一個milestone15：31，未來要怎麽發展這個裏程碑，M1、M2、M3、M4這樣的發展方向。而到如今為止這個5.5已經發展到5.6、5.7的版本號，並且已經是IC版本號了，非常快就要GA了，那我想這對於MySQL來說應該是一個好消息。我們可以用到很多其它更穩定的新特性。 5.5版本號裏有幾個新的特性是我們非常關註的，比方Google已經達到英文15：57這個pach。所以我們認為對我們未來的這個MySQL這個系統非常實用的一個功能。那我們也等著Oracle的5.5這個版本號可以盡快的GA出來。

淘寶數據庫負責人介紹淘寶數據庫設計