淘寶用什麼資料庫

A. 淘寶為什麼使用HBase及如何優化的

1 前言
hbase是從hadoop中 分離出來的apache頂級開源項目。由於它很好地用java實現了google的bigtable系統大部分特性，因此在數據量猛增的今天非常受到歡 迎。對於淘寶而言，隨著市場規模的擴大，產品與技術的發展，業務數據量越來越大，對海量數據的高效插入和讀取變得越來越重要。由於淘寶擁有也許是國內最大 的單一hadoop集群(雲梯)，因此對hadoop系列的產品有比較深入的了解，也就自然希望使用hbase來做這樣一種海量數據讀寫服務。本篇文章將 對淘寶最近一年來在online應用上使用和優化hbase的情況做一次小結。

2 原因
為什麼要使用hbase？
淘寶在2011年之前所有的後端持久化存儲基本上都是在mysql上進行的(不排除少量oracle/bdb/tair/mongdb等)，mysql由於開源，並且生態系統良好，本身擁有分庫分表等多種解決方案，因此很長一段時間內都滿足淘寶大量業務的需求。

但是由於業務的多樣化發展，有越來越多的業務系統的需求開始發生了變化。一般來說有以下幾類變化：

a) 數據量變得越來越多，事實上現在淘寶幾乎任何一個與用戶相關的在線業務的數據量都在億級別，每日系統調用次數從億到百億都有，且歷史數據不能輕易刪除。這需要有一個海量分布式文件系統，能對TB級甚至PB級別的數據提供在線服務
b) 數據量的增長很快且不一定能准確預計，大多數應用系統從上線起在一段時間內數據量都呈很快的上升趨勢，因此從成本的角度考慮對系統水平擴展能力有比較強烈的需求，且不希望存在單點制約
c) 只需要簡單的kv讀取，沒有復雜的join等需求。但對系統的並發能力以及吞吐量、響應延時有非常高的需求，並且希望系統能夠保持強一致性
d) 通常系統的寫入非常頻繁，尤其是大量系統依賴於實時的日誌分析
e) 希望能夠快速讀取批量數據
f ) schema靈活多變，可能經常更新列屬性或新增列
g) 希望能夠方便使用，有良好且語義清晰的java介面

以上需求綜合在一起，我們認為hbase是一種比較適合的選擇。首先它的數據由hdfs天然地做了數據冗餘，雲梯三年的穩定運行，數據100%可靠 己經證明了hdfs集群的安全性，以及服務於海量數據的能力。其次hbase本身的數據讀寫服務沒有單點的限制，服務能力可以隨伺服器的增長而線性增長， 達到幾十上百台的規模。LSM-Tree模式的設計讓hbase的寫入性能非常良好，單次寫入通常在1-3ms內即可響應完成，且性能不隨數據量的增長而 下降。

region（相當於資料庫的分表）可以ms級動態的切分和移動，保證了負載均衡性。由於hbase上的數據模型是按rowkey排序存儲的，而讀 取時會一次讀取連續的整塊數據做為cache，因此良好的rowkey設計可以讓批量讀取變得十分容易，甚至只需要1次io就能獲取幾十上百條用戶想要的 數據。最後，淘寶大部分工程師是java背景的同學，因此hbase的api對於他們來說非常容易上手，培訓成本相對較低。

當然也必須指出，在大數據量的背景下銀彈是不存在的，hbase本身也有不適合的場景。比如，索引只支持主索引（或看成主組合索引），又比如服務是 單點的，單台機器宕機後在master恢復它期間它所負責的部分數據將無法服務等。這就要求在選型上需要對自己的應用系統有足夠了解。

3 應用情況
我們從2011年3月開始研究hbase如何用於在線服務。盡管之前在一淘搜索中己經有了幾十節點的離線服務。這是因為hbase早期版本的目標就 是一個海量數據中的離線服務。2009年9月發布的0.20.0版本是一個里程碑，online應用正式成為了hbase的目標，為此hbase引入了 zookeeper來做為backupmaster以及regionserver的管理。2011年1月0.90.0版本是另一個里程碑，基本上我們今天 看到的各大網站，如facebook/ebay/yahoo內所使用於生產的hbase都是基於這一個版本(fb所採用的0.89版本結構與0.90.x 相近)。bloomfilter等諸多屬性加入了進來，性能也有極大提升。基於此，淘寶也選用了0.90.x分支作為線上版本的基礎。

第一個上線的應用是數據魔方中的prom。prom原先是基於redis構建的，因為數據量持續增大以及需求的變化，因此我們用hbase重構了它 的存儲層。准確的說prom更適合0.92版本的hbase，因為它不僅需要高速的在線讀寫，更需要count/group by等復雜應用。但由於當時0.92版本尚未成熟，因此我們自己單獨實現了coprocessor。prom的數據導入是來源於雲梯，因此我們每天晚上花 半個小時將數據從雲梯上寫入hbase所在的hdfs，然後在web層做了一個client轉發。經過一個月的數據比對，確認了速度比之redis並未有 明顯下降，以及數據的准確性，因此得以順利上線。

第二個上線的應用是TimeTunnel，TimeTunnel是一個高效的、可靠的、可擴展的實時數據傳輸平台，廣泛應用於實時日誌收集、數據實 時監控、廣告效果實時反饋、資料庫實時同步等領域。它與prom相比的特點是增加了在線寫。動態的數據增加使hbase上compact/balance /split/recovery等諸多特性受到了極大的挑戰。TT的寫入量大約一天20TB，讀的量約為此的1.5倍，我們為此准備了20台 regionserver的集群，當然底層的hdfs是公用的，數量更為龐大（下文會提到）。每天TT會為不同的業務在hbase上建不同的表，然後往該 表上寫入數據，即使我們將region的大小上限設為1GB，最大的幾個業務也會達到數千個region這樣的規模，可以說每一分鍾都會有數次 split。在TT的上線過程中，我們修復了hbase很多關於split方面的bug，有好幾個commit到了hbase社區，同時也將社區一些最新 的patch打在了我們的版本上。split相關的bug應該說是hbase中會導致數據丟失最大的風險之一，這一點對於每個想使用hbase的開發者來 說必須牢記。hbase由於採用了LSM-Tree模型，從架構原理上來說數據幾乎沒有丟失的可能，但是在實際使用中不小心謹慎就有丟失風險。原因後面會 單獨強調。TT在預發過程中我們分別因為Meta表損壞以及split方面的bug曾經丟失過數據，因此也單獨寫了meta表恢復工具，確保今後不發生類 似問題(hbase-0.90.5以後的版本都增加了類似工具)。另外，由於我們存放TT的機房並不穩定，發生過很多次宕機事故，甚至發生過假死現象。因 此我們也著手修改了一些patch，以提高宕機恢復時間，以及增強了監控的強度。

CTU以及會員中心項目是兩個對在線要求比較高的項目，在這兩個項目中我們特別對hbase的慢響應問題進行了研究。hbase的慢響應現在一般歸 納為四類原因：網路原因、gc問題、命中率以及client的反序列化問題。我們現在對它們做了一些解決方案(後面會有介紹)，以更好地對慢響應有控制 力。

和Facebook類似，我們也使用了hbase做為實時計算類項目的存儲層。目前對內部己經上線了部分實時項目，比如實時頁面點擊系 統，galaxy實時交易推薦以及直播間等內部項目，用戶則是散布到公司內各部門的運營小二們。與facebook的puma不同的是淘寶使用了多種方式 做實時計算層，比如galaxy是使用類似affa的actor模式處理交易數據，同時關聯商品表等維度表計算排行(TopN)，而實時頁面點擊系統則是 基於twitter開源的storm進行開發，後台通過TT獲取實時的日誌數據，計算流將中間結果以及動態維表持久化到hbase上，比如我們將 rowkey設計為url+userid，並讀出實時的數據，從而實現實時計算各個維度上的uv。

最後要特別提一下歷史交易訂單項目。這個項目實際上也是一個重構項目，目的是從以前的solr+bdb的方案上遷移到hbase上來。由於它關繫到 己買到頁面，用戶使用頻率非常高，重要程度接近核心應用，對數據丟失以及服務中斷是零容忍。它對compact做了優化，避免大數據量的compact在 服務時間內發生。新增了定製的filter來實現分頁查詢，rowkey上對應用進行了巧妙的設計以避免了冗餘數據的傳輸以及90%以上的讀轉化成了順序 讀。目前該集群存儲了超過百億的訂單數據以及數千億的索引數據，線上故障率為0。

隨著業務的發展，目前我們定製的hbase集群己經應用到了線上超過二十個應用，數百台伺服器上。包括淘寶首頁的商品實時推薦、廣泛用於賣家的實時量子統計等應用，並且還有繼續增多以及向核心應用靠近的趨勢。

4 部署、運維和監控
Facebook之前曾經透露過Facebook的hbase架構，可以說是非常不錯的。如他們將message服務的hbase集群按用戶分為數 個集群，每個集群100台伺服器，擁有一台namenode以及分為5個機架，每個機架上一台zookeeper。可以說對於大數據量的服務這是一種優良 的架構。對於淘寶來說，由於數據量遠沒有那麼大，應用也沒有那麼核心，因此我們採用公用hdfs以及zookeeper集群的架構。每個hdfs集群盡量 不超過100台規模（這是為了盡量限制namenode單點問題）。在其上架設數個hbase集群，每個集群一個master以及一個 backupmaster。公用hdfs的好處是可以盡量減少compact的影響，以及均攤掉硬碟的成本，因為總有集群對磁碟空間要求高，也總有集群對 磁碟空間要求低，混合在一起用從成本上是比較合算的。zookeeper集群公用，每個hbase集群在zk上分屬不同的根節點。通過zk的許可權機制來保 證hbase集群的相互獨立。zk的公用原因則僅僅是為了運維方便。

由於是在線應用，運維和監控就變得更加重要，由於之前的經驗接近0，因此很難招到專門的hbase運維人員。我們的開發團隊和運維團隊從一開始就很重視該問題，很早就開始自行培養。以下講一些我們的運維和監控經驗。

我們定製的hbase很重要的一部分功能就是增加監控。hbase本身可以發送ganglia監控數據，只是監控項遠遠不夠，並且ganglia的 展示方式並不直觀和突出。因此一方面我們在代碼中侵入式地增加了很多監控點，比如compact/split/balance/flush隊列以及各個階 段的耗時、讀寫各個階段的響應時間、讀寫次數、region的open/close，以及具體到表和region級別的讀寫次數等等。仍然將它們通過 socket的方式發送到ganglia中，ganglia會把它們記錄到rrd文件中，rrd文件的特點是歷史數據的精度會越來越低，因此我們自己編寫 程序從rrd中讀出相應的數據並持久化到其它地方，然後自己用js實現了一套監控界面，將我們關心的數據以趨勢圖、餅圖等各種方式重點匯總和顯示出來，並 且可以無精度損失地查看任意歷史數據。在顯示的同時會把部分非常重要的數據，如讀寫次數、響應時間等寫入資料庫，實現波動報警等自定義的報警。經過以上措 施，保證了我們總是能先於用戶發現集群的問題並及時修復。我們利用redis高效的排序演算法實時地將每個region的讀寫次數進行排序，能夠在高負載的 情況下找到具體請求次數排名較高的那些region，並把它們移到空閑的regionserver上去。在高峰期我們能對上百台機器的數十萬個 region進行實時排序。

為了隔離應用的影響，我們在代碼層面實現了可以檢查不同client過來的連接，並且切斷某些client的連接，以在發生故障時，將故障隔離在某個應用內部而不擴大化。maprece的應用也會控制在低峰期運行，比如在白天我們會關閉jobtracker等。

此外，為了保障服務從結果上的可用，我們也會定期跑讀寫測試、建表測試、hbck等命令。hbck是一個非常有用的工具，不過要注意它也是一個很重 的工操作，因此盡量減少hbck的調用次數，盡量不要並行運行hbck服務。在0.90.4以前的hbck會有一些機率使hbase宕機。另外為了確保 hdfs的安全性，需要定期運行fsck等以檢查hdfs的狀態，如block的replica數量等。

我們會每天根蹤所有線上伺服器的日誌，將錯誤日誌全部找出來並且郵件給開發人員，以查明每一次error以上的問題原因和fix。直至錯誤降低為0。另外 每一次的hbck結果如果有問題也會郵件給開發人員以處理掉。盡管並不是每一次error都會引發問題，甚至大部分error都只是分布式系統中的正常現 象，但明白它們問題的原因是非常重要的。

5 測試與發布
因為是未知的系統，我們從一開始就非常注重測試。測試從一開始就分為性能測試和功能測試。性能測試主要是注意基準測試，分很多場景，比如不同混合讀 寫比例，不同k/v大小，不同列族數，不同命中率，是否做presharding等等。每次運行都會持續數小時以得到准確的結果。因此我們寫了一套自動化 系統，從web上選擇不同的場景，後台會自動將測試參數傳到各台伺服器上去執行。由於是測試分布式系統，因此client也必須是分布式的。

我們判斷測試是否准確的依據是同一個場景跑多次，是否數據，以及運行曲線達到99%以上的重合度，這個工作非常煩瑣，以至於消耗了很多時間，但後來 的事實證明它非常有意義。因為我們對它建立了100%的信任，這非常重要，比如後期我們的改進哪怕只提高2%的性能也能被准確捕捉到，又比如某次代碼修改 使compact隊列曲線有了一些起伏而被我們看到，從而找出了程序的bug，等等。

功能測試上則主要是介面測試和異常測試。介面測試一般作用不是很明顯，因為hbase本身的單元測試己經使這部分被覆蓋到了。但異常測試非常重要， 我們絕大部分bug修改都是在異常測試中發現的，這幫助我們去掉了很多生產環境中可能存在的不穩定因素，我們也提交了十幾個相應的patch到社區，並受 到了重視和commit。分布式系統設計的難點和復雜度都在異常處理上，我們必須認為系統在通訊的任何時候都是不可靠的。某些難以復現的問題我們會通過查 看代碼大體定位到問題以後，在代碼層面強行拋出異常來復現它。事實證明這非常有用。

為了方便和快速定位問題，我們設計了一套日誌收集和處理的程序，以方便地從每台伺服器上抓取相應的日誌並按一定規律匯總。這非常重要，避免浪費大量的時間到登錄不同的伺服器以尋找一個bug的線索。

由於hbase社區在不停發展，以及線上或測試環境發現的新的bug，我們需要制定一套有規律的發布模式。它既要避免頻繁的發布引起的不穩定，又要 避免長期不發布導致生產版本離開發版本越來越遠或是隱藏的bug爆發。我們強行規定每兩周從內部trunk上release一個版本，該版本必須通過所有 的測試包括回歸測試，並且在release後在一個小型的集群上24小時不受甘擾不停地運行。每個月會有一次發布，發布時採用最新release的版本， 並且將現有的集群按重要性分級發布，以確保重要應用不受新版本的潛在bug影響。事實證明自從我們引入這套發布機制後，由發布帶來的不穩定因素大大下降 了，並且線上版本也能保持不落後太多。

6 改進和優化
Facebook是一家非常值得尊敬的公司，他們毫無保留地對外公布了對hbase的所有改造，並且將他們內部實際使用的版本開源到了社區。 facebook線上應用的一個重要特點是他們關閉了split，以降低split帶來的風險。與facebook不同，淘寶的業務數據量相對沒有如此龐 大，並且由於應用類型非常豐富，我們並們並沒有要求用戶強行選擇關閉split，而是盡量去修改split中可能存在的bug。到目前為止，雖然我們並不 能說完全解決了這個問題，但是從0.90.2中暴露出來的諸多跟split以及宕機相關的可能引發的bug我們的測試環境上己經被修復到接近了0，也為社 區提交了10數個穩定性相關的patch，比較重要的有以下幾個：

https://issues.apache.org/jira/browse/HBASE-4562
https://issues.apache.org/jira/browse/HBASE-4563
https://issues.apache.org/jira/browse/HBASE-5152
https://issues.apache.org/jira/browse/HBASE-5100
https://issues.apache.org/jira/browse/HBASE-4880
https://issues.apache.org/jira/browse/HBASE-4878
https://issues.apache.org/jira/browse/HBASE-4899

還有其它一些，我們主要將patch提交到0.92版本，社區會有commitor幫助我們backport回0.90版本。所以社區從 0.90.2一直到0.90.6一共發布了5個bugfix版本後，0.90.6版本其實己經比較穩定了。建議生產環境可以考慮這個版本。

split這是一個很重的事務，它有一個嚴重的問題就是會修改meta表（當然宕機恢復時也有這個問題）。如果在此期間發生異常，很有可能meta 表、rs內存、master內存以及hdfs上的文件會發生不一致，導致之後region重新分配時發生錯誤。其中一個錯誤就是有可能同一個region 被兩個以上的regionserver所服務，那麼就可能出現這一個region所服務的數據會隨機分別寫到多台rs上，讀取的時候也會分別讀取，導致數 據丟失。想要恢復原狀，必須刪除掉其中一個rs上的region，這就導致了不得不主動刪掉數據，從而引發數據丟失。

前面說到慢響應的問題歸納為網路原因、gc問題、命中率以及client的反序列化問題。網路原因一般是網路不穩定引起的，不過也有可能是tcp參 數設置問題，必須保證盡量減少包的延遲，如nodelay需要設置為true等，這些問題我們通過tcpmp等一系列工具專門定位過，證明tcp參數 對包的組裝確實會造成慢連接。gc要根據應用的類型來，一般在讀比較多的應用中新生代不能設置得太小。命中率極大影響了響應的時間，我們會盡量將 version數設為1以增加緩存的容量，良好的balance也能幫助充分應用好每台機器的命中率。我們為此設計了表級別的balance。

由於hbase服務是單點的，即宕機一台，則該台機器所服務的數據在恢復前是無法讀寫的。宕機恢復速度決定了我們服務的可用率。為此主要做了幾點優 化。首先是將zk的宕機發現時間盡量縮短到1分鍾，其次改進了master恢復日誌為並行恢復，大大提高了master恢復日誌的速度，然後我們修改了 openhandler中可能出現的一些超時異常，以及死鎖，去掉了日誌中可能發生的open…too long等異常。原生的hbase在宕機恢復時有可能發生10幾分鍾甚至半小時無法重啟的問題己經被修復掉了。另外，hdfs層面我們將 socket.timeout時間以及重試時間也縮短了，以降低datanode宕機引起的長時間block現象。

hbase本身讀寫層面的優化我們目前並沒有做太多的工作，唯一打的patch是region增加時寫性能嚴重下降的問題。因為由於hbase本身 良好的性能，我們通過大量測試找到了各種應用場景中比較優良的參數並應用於生產環境後，都基本滿足需求。不過這是我們接下來的重要工作。

7 將來計劃
我們目前維護著淘寶內基於社區0.90.x而定製的hbase版本。接下來除繼續fix它的bug外，會維護基於0.92.x修改的版本。之所以這 樣，是因為0.92.x和0.90.x的兼容性並不是非常好，而且0.92.x修改掉的代碼非常多，粗略統計會超過30%。0.92中有我們非常看重的一 些特性。

0.92版本改進了hfile為hfileV2，v2版本的特點是將索引以及bloomfilter進行了大幅改造，以支持單個大hfile文 件。現有的HFile在文件大到一定程度時，index會佔用大量的內存，並且載入文件的速度會因此下降非常多。而如果HFile不增大的 話，region就無法擴大，從而導致region數量非常多。這是我們想盡量避免的事。
0.92版本改進了通訊層協議，在通訊層中增加了length，這非常重要，它讓我們可以寫出nio的客戶端，使反序列化不再成為影響client性能的地方。
0.92版本增加了coprocessor特性，這支持了少量想要在rs上進行count等的應用。
還有其它很多優化，比如改進了balance演算法、改進了compact演算法、改進了scan演算法、compact變為CF級別、動態做ddl等等特性。

除了0.92版本外，0.94版本以及最新的trunk(0.96)也有很多不錯的特性，0.94是一個性能優化版本。它做了很多革命性工作，比如去掉root表，比如HLog進行壓縮，replication上支持多個slave集群，等等。

我們自己也有一些優化，比如自行實現的二級索引、backup策略等都會在內部版本上實現。
另外值得一提的是hdfs層面的優化也非常重要，hadoop-1.0.0以及cloudera-3u3的改進對hbase非常有幫助，比如本地化 讀、checksum的改進、datanode的keepalive設置、namenode的HA策略等。我們有一支優秀的hdfs團隊來支持我們的 hdfs層面工作，比如定位以及fix一些hdfs層面的bug,幫助提供一些hdfs上參數的建議，以及幫助實現namenode的HA等。最新的測試 表明，3u3的checksum+本地化讀可以將隨機讀性能提升至少一倍。
我們正在做的一件有意義的事是實時監控和調整regionserver的負載，能夠動態地將負載不足的集群上的伺服器挪到負載較高的集群中，而整個過程對用戶完全透明。

總的來說，我們的策略是盡量和社區合作，以推動hbase在整個apache生態鏈以及業界的發展，使其能更穩定地部署到更多的應用中去，以降低使用門檻以及使用成本。

B. 淘寶伺服器 什麼系統

淘寶用的是JBoss，框架是iBATIS，緩存伺服器是自己開發的，基本遵循SNA架構，水平擴展，資料庫是Oracle，阿里集團的DBA幾乎是國內最強悍的。目前淘寶的系統架構正在重構，計劃用兩到三年時間重寫，目標有兩個：
1、水平擴展已經不滿足需求了，還需要水平加垂直擴展
2、開放API，讓店家可以把外部網站資源集成到淘寶，不必直接在淘寶開店
淘寶首席架構師是原來JBoss的Ben Wang，現在正在招募技術高手加盟，從事這項很有挑戰性的工作：設計下一代開放性、支撐數十億訪問量的在線電子商務網站

C. 淘寶CSV文件是什麼東西可以在CSV文件裡面編輯寶貝嗎

可以，其是用相應的助理軟體（淘寶助理）直接導出相應的csv文件，將自己網店商品的相關數據（如商品屬性圖片等信息）打包備份或以便下次編輯修改再導入上傳到自己的網店。

以淘寶助理V4.3Beta1為例，支持本地圖片上傳寶貝時自動將本地圖片上傳圖片空間，讓本地圖片在寶貝描述中盡情展現。支持視頻、flash。批量編輯寶貝，對寶貝描述、類目、屬性全新改版。交易管理批量編輯批量編輯物流公司和運單號。CSV導入導出，自由的批量編輯出售中的寶貝。

(3)淘寶用什麼資料庫擴展閱讀

資料庫功能：

提供寶貝基本信息，包括類目、屬性、名稱、價格、郵費等；

提供寶貝描述信息：以HTML的形式，圖文並茂地提供對寶貝詳細的描述；

還可以提供寶貝的銷售屬性，例如尺碼和顏色等組合信息。寶貝模板為了更快的創建寶貝，您可以新建若干模板，將常用的寶貝信息保存起來，以後新建寶貝時，就可以從這些模板中創建，不再填寫這些常用的信息。

D. 淘寶的資料庫怎麼搭建

我們也了解到，現在淘寶的整個的資料庫團隊在逐漸的把一些資料庫從Oracle遷移到MySQL，然後呢，把一些伺服器由小型機轉到PC server，那你們整個轉變的動機是什麼？
主要是因為業務壓力給了我們最大的動力。07年我來到淘寶的時候，當時只有三個主要的資料庫，全部在小型機和存儲上面。以當時的壓力來看，它跑起來是非常順利的，而且大家也知道小型機它從Unix操作系統到硬體，穩定性都會比PC server其實要高很多，當時的情況下淘寶用小型機是一個非常自然的選擇。
從07年開始淘寶的業務量保持每年自然翻一番的增長，資料庫質量感覺到非常大的壓力。那麼前端業務量增長一倍，在資料庫上有可能增長是好幾倍，它有一個放大效應在里邊。當時我們第一步能夠想到很自然的架構，就是把三個資料庫拆成更多的資料庫，或每一個資料庫支持一個比較單一的業務。比如用戶、商品和交易，都會分成獨立的資料庫，然後放到獨立的小型計算中去，這是我們08年做的很大的事情就是垂直拆分，然後08年的業務我們就頂住了。
當時我們就預估09年、10年會有更大的壓力增長，這個時候我們應該怎麼辦？當時我們從業界能看到很多的經驗分享，包括eBay、亞馬遜這些國外的大公司，他們的經驗分享裡面，水平拆分是我們資料庫漲到一定程度後的架構選擇。我們從Oracle到MySQL轉移，主要是用水平拆分，這是我們未來的一個弱點，那水平拆分後機器、資料庫的數量都會多很多，那Oracle它本身的成本也是我們考慮的一個重要因素，所以當時從成本考慮的話，那個時候我們自然會選擇用MySQL資料庫。
給我們再簡單總結一下這幾年，淘寶整個資料庫的演變過程？
剛才說到08年我們做完垂直拆分以後，09年到今年我們主要做的工作其實就是水平拆分。今年在十月份之前我們全部完成了淘寶最核心的三個系統：交易資料庫、商品資料庫和用戶資料庫的水平拆分。所以到「雙十一」之前，在我們內部采訪中，我一直跟采訪人員說，當時資料庫情緒穩定。基本上我們沒有做什麼事情，只是在不停的看報表，看數據，然後很開心的看到交易曲線以超過45度的趨勢往上漲。
那前期還是做了非常完善的准備。據我們了解在整個從小型機到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肯定是要做得越來越大的，淘寶還有很多小型機上面擴展不太容易的系統需要遷移到可擴展的機群上面來，但我們也希望業界能夠有更多的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出來。

E. 大家知道淘寶網、京東、當當網、美團、餓了么可能使用了什麼資料庫嗎

應該是mysql，因為免費。

F. 淘寶和騰訊這種大公司，開發網站主要使用的語言是什麼一般是用Linux系統和MysqL資料庫嗎

淘寶據說以前是PHP寫的，現在變為Java PHP和Java都是流行的編程語言，但是實際用起來就要區分了。一般小公司小網站用PHP 多，像淘寶這種大型網站就要用Java了，畢竟各方面的優勢都比較好！

G. 淘寶 用的資料庫 是 mysql 還是 sql server

大型網站用的多數是oracle或DB2。其他資料庫數據量大了就跑不動了

H. 淘寶的資料庫怎麼搭建

淘寶的整個的資料庫團隊在逐漸的把一些資料庫從Oracle遷移到MySQL，然後呢，把一些伺服器由小型機轉到PC server，MySQL其實是基於GPL的協議來開源的軟體，那淘寶在使用過程中，前期是已經考慮到一些風險。
MySQL的版本相對來說是比較混亂的，包括我們現在在用的5.0和5.1的正式版本，最近還有包括開發方面就還有兩個，一個6.0，一個5.4，這些特性會互相交織在一起，讓我們選擇的時候也有點不知道到底選哪個版本會更好一點。
做網站的時候要找出性價比更高的合作夥伴,從價格,服務,技術等多方面考慮,而不是為做網站而做網站,不懂網站SEM的或只懂技術的最好別用，SEO的目的。

I. 淘寶網用的資料庫是Mysql嗎

現在開始全面去oracle化，由於技術團隊實力雄厚，已經開始自主開發使用開源資料庫了

J. 列族資料庫對於淘寶有哪些優點

方便查詢了。
列族資料庫將數據存儲在列族中，而列族裡的行則把許多列數據與本行的「行鍵」（row key）關聯起來。列族用來把通常需要一並訪問的相關數據分成組。例如，可能要同時訪問多個客戶的配置信息，但是很少需要同時訪問他們的訂單。 Cassandra是一種能快速執行跨集群寫入操作並易於對此擴展的資料庫。集群中沒有主節點，其中每個節點均可以處理讀取與寫入請求。