淘寶網擁有國內最具商業價值的海量數據。截至當前，每天有超過30億的店鋪、商品瀏覽記錄，10億在線商品數，上千萬的成交、收藏和評價數據。如何從這些數據中挖掘出真正的商業價值，進而幫助淘寶、商家進行企業的數據化運營，幫助消費者進行理性的購物決策，是淘寶數據平臺與產品部的使命。

數據產品的一個最大特點是數據的非實時寫入，正因為如此，我們可以認為，在一定的時間段內，整個系統的數據是只讀的。這為我們設計緩存奠定了非常重要的基礎。

關系型數據庫（RDBMS）自20世紀70年代提出以來，在工業生產中得到了廣泛的使用。經過三十多年的長足發展，誕生了一批優秀的數據庫軟件，例如Oracle、MySQL、DB2、Sybase和SQL Server等。

盡管相對於非關系型數據庫而言，關系型數據庫在分區容忍性（Tolerance to Network Partitions）方面存在劣勢，但由於它強大的語義表達能力以及數據之間的關系表達能力，在數據產品中仍然占據著不可替代的作用。

在MyFOX出現之後，一切都看起來那麽完美，開發人員甚至不會意識到MyFOX的存在，一條不用任何特殊修飾的SQL語句就可以滿足需求。這個狀態持續了很長一段時間，直到有一天，我們碰到了傳統的關系型數據庫無法解決的問題——全屬性選擇器

這是一個非常典型的例子。為了說明問題，我們仍然以關系型數據庫的思路來描述。對於筆記本電腦這個類目，用戶某一次查詢所選擇的過濾條件可能包括 “筆記本尺寸”、“筆記本定位”、“硬盤容量”等一系列屬性（字段），並且在每個可能用在過濾條件的屬性上，屬性值的分布是極不均勻的。在圖5中我們可以看到，筆記本電腦的尺寸這一屬性有著10個枚舉值，而“藍牙功能”這個屬性值是個布爾值，數據的篩選性非常差。

正是基於本文所描述的架構特點，數據魔方目前已經能夠提供壓縮前80TB的數據存儲空間，數據中間層glider支持每天4000萬的查詢請求，平均響應時間在28毫秒（6月1日數據），足以滿足未來一段時間內的業務增長需求。

盡管如此，整個系統中仍然存在很多不完善的地方。一個典型的例子莫過於各個分層之間使用短連接模式的HTTP協議進行通信。這樣的策略直接導致在流量高峰期單機的TCP連接數非常高。所以說，一個良好的架構固然能夠在很大程度上降低開發和維護的成本，但它自身一定是隨著數據量和流量的變化而不斷變化的。我相信，過不了幾年，淘寶數據產品的技術架構一定會是另外的樣子。

《淘寶數據魔方技術架構解析》閱讀心得