淘寶網商品庫優化實踐訪談 餘鋒先生您好。歡迎您參加QCon0：04並給我們做精彩的演講。也謝謝您接受我們的採訪。您能向觀衆朋友大概介紹一下您自己，包括您現在負責的具體工作是什麼嗎？ 大家好，我隸屬於淘寶網核心系統數據庫組。我們的團隊在淘寶主要負責MySQL分支的維護。大家知道淘寶去年開始在做去Oracle化的工作，由於涉及到歷史數據保留，替代方案當時選擇的是MySQL。由於淘寶很多的產品都用到了數據庫，這也促使MySQL即將會慢慢被大規模使用。Oracle是一個商業的產品，所以它有很多的特性是非常適合大規模數據使用的。同時MySQL作爲一個開源的產品，也具有很多商業數據庫所沒有的特性，於是我們就要去填補這個空白。我們的工作就是在開源的MySQL基礎上做一些改進和優化，特別是性能方面的優化。MySQL最初的設計不是用來存儲大規模數據的，但淘寶的數據量非常驚人，所以在I/O方面，尤其是CPU I/O層面會有很大瓶頸，因此我們的主要目標也是解決IO方面的瓶頸問題 在談到具體的MySQL優化策略之前，我想大家都比較好奇，介於淘寶現在的數據容量，每天的吞吐量是一個什麼樣的情況？ 淘寶的產品線很多，以我們目前接觸到的淘寶的商品庫爲例，淘寶商品庫是什麼概念？就是賣家賣的所有的商品都保存在數據庫上。我們都知道淘寶商品是非常多的，有可能是十億級別的，而且淘寶每年的數據都會翻番，過去亦是如此，未來也會如此，動輒幾十億條的記錄。在淘寶上，由於賣家是非常活躍的，所以每天的交易數也是非常多的，而且每天的訪問量也是相當大的。更比如在一些高峯期，比如節假日，像去年的四個一光棍節促銷，當時一天的訪問量可就是平常的好幾倍，幾十倍的樣子。具體的數字，在網站上應該會看到，這個數字也在不停的變化，大概會在10億的這麼一個數量級上。 在Oracle 切換到MySQL後，可能會有一些商業上的特性在MySQL上無法得到體現。所以在做優化之前，是否設定了一些策略的標準，比如說一定要達到什麼樣的標準纔算是成功的優化？ 我們的標準主要基於以下三個方面，首先是安全性。因爲淘寶賣家的商品都存在上面，一大堆數據，商品沒了，淘寶就會很難受；其次是性能，因爲數據量大，而且未來增長的速度會非常快，以前我們的系統是跑在Oracle的小機上面，它的成本是非常高的。現在改用高性能的PC服務器，性價比較高，而且Oracle數據庫的能力不足以維持淘寶的更新速度；最後是可運維性，Oracle是有一套完整的工具，利用它們我們可隨時查看相關的狀態和預測它的一些變化。MySQL作爲開源產品，這部分的功能稍顯欠缺，因此我們就需要根據運維團隊和DBA的需求去開發一些工具。 就是在日常優化工作的過程中幫助你去運維？ 對，這也算優化的一方面，算過程的一個方面。 在產品的優化過程中，是否會發現用MySQL替代原來的Oracle有些問題還是無法避免的，您是如何處理的？ 是的，是有這樣的問題，比如Oracle的雙機備份，這塊就做得非常好，整體的方案都不錯。相比之下MySQL這點就比較弱，我們必須在過程中去深化解決這個問題。還有像Oracle使用的高端存儲，它的高端存儲的I/O能力是非常強的。現在我們改用PC服務器，如果用硬盤來做的話，I/O能力會很差，甚至說I/O的能力在一兩千I/O PS就已經算很高的了，這樣的話相比原來的高端存儲會相差一個數量級。我們在過去幾個月順利地解決了這個問題，而且結果證明，性能要比高端存儲還要好。 那麼這個優化的工作現在是一個什麼樣的狀態，進行中還是已經上線？ 從去年8月開始到現在已經持續了好幾個月，這個月就可以上線。其實主要的攻堅工作在兩個月前就已經做好了，由於要採購設備，所以安排在這月上線，上線後即可替代原來的Oracle數據庫。 就目前的結果來看優化成果如何？ 從機器的運算能力上來看的話，比原來要高很多，從設備的總體的價格來看的話，相比原來小機的價格，現在的價格相當於原來的幾分之一。說的通俗一點就是，花更少的錢做更多的事情，基本是這樣的一個情況。 優化MySQL的過程中有沒有涉及到水平分片，或者垂直分片，大概的策略是什麼？ 這塊因爲之前的MySQL從業務的角度上我們已經優化過了。涉及到業務上的複雜SQL查詢，基本上都把它當成Key-Value來處理。所以說在水平切割上就變得非常簡單，我們只需要根據用戶的這些ID把它平均地分割到集羣的各個機器上去即可，所以說這塊會做得非常簡單，也不會有那些非常複雜的SQL。 剛纔提到在去Oracle化過程中，最終選擇了MySQL。是怎樣的原因使你沒有去選擇NoSQL或是其它技術來作爲提高性能優化方面的考慮呢？ 主要考慮到以下這幾個方面，第一是因爲MySQL已經是非常成熟的產品，而且也是經過大規模系統考驗的，所以它的穩定性，開發的便捷性還是比較有優勢的。從另外一個角度上來講，也能最大限度的保障歷史系統的遷移，這是第一個方面。此外，之所以沒有采用NoSQL主要基於以下幾個方面的考慮，第一由於市面上流行的NoSQL方案相對來說都比較年輕。然而對於淘寶商品庫來講，它是作爲淘寶非常重要的庫，是不允許我們有絲毫閃失的，不能出現任何問題。第二點，現在流行的NoSQL方案，從程序的架構上來講，就是對傳統數據庫的過程進行了精簡。但是它的存儲、內存等問題其實還是存在的。只是解決問題的思路變得輕量。但是這些問題依舊在的。 現在我們在數據庫層面，因爲平常都是從引擎層面去開發，在原碼級別去做優化，甚至包括操作系統級的優化。所以我們可以很清楚的知道問題在哪裏，應該解決什麼問題，最終能達到什麼樣的效果。那這樣做的好處就是我們既能解決問題，又能充分利用傳統數據庫的方便性以及穩定性。 請您分享一下，在數據庫優化方面，尤其是MySQL優化這部分，在優化的過程種需要遵循那些原則？ 優化聽起來好像沒什麼內容，但實際上我們做了很多的工作。首先要有明確的目標，我們的目標是什麼，是爲了提高性能還是提高安全性，還是提高其他的什麼指標，這個目標要清晰和完整。第二點是測量，你不能說，我拍腦袋看到某某某，他怎麼優化的，然後我也上去這樣照着優化，這不是我們做事的風格。我們要測量現在的瓶頸在哪裏？我們的系統遇到了什麼問題，這點我們會藉助一些工具來實現。比如說測量CPU的使用，我們會非常精確的去測量I/O的使用，比如說在設備層面，I/O是怎麼使用的，在軟件系統層面I/O是怎麼使用的，在數據庫引擎層面I/O是怎麼使用的。通過非常精細的測量，我們就能找出，對I/O使用不恰當的地方，然後就是要去解決這種問題，爲什麼會比設想的要多呢，或者爲什麼要比設想的要慢呢，我們會針對此類問題做理論上的分析，甚至會去翻翻源碼它到底是怎麼實現的，這樣我們就可以比較有針對性將問題解決。需要特別提到的是，我們這次有一個創新，用高速的SSD盤去做2級Cache，因爲傳統的MySQL數據庫都是引擎裏面發揮pool的功能，然後直接在軟件系統存儲。就是引擎裏邊吐出來東西到那邊去，命不中東西從磁盤讀進去，由於是傳統的磁盤，所以它的尋道時間是非常長的。那它的I/O其實是不高的，但是吞吐量大。爲了解決問題，我們採用一種叫PCI-E的Flash卡。這個卡的特點是，它是電子盤，所以它沒有尋道時間，隨機特性非常好，同時它的讀寫吞吐量非常高，讀能大概到1G，寫能達到幾百兆。採用其作爲二級cache，數據從InnoDB引擎這邊出來，不到磁盤去，而是先寫到高速卡中。由於高速卡很快，它完成的I/O PS是微秒級的，幾十微秒就寫完了，然後傳統磁盤卻是十個毫秒級的。所以從數據庫引擎的角度來看，只需寫入幾十微妙就解決了。寫入數據開始是隨機的，隨機累計起來以後它就不是隨機的，我們通過把它排序，就可以使其變爲順序的。然後我們再把這順序的數據利用磁盤的高吞吐量特點，由於數據庫半夜時候它可能會比較輕鬆。那這時候，把它導到磁盤中去，這樣就大大的提高整個系統的IO能力。這是比較大的一個創新點。
轉載：http://www.cnblogs.com/end/archive/2011/05/20/2052462.html