吳悅，騰訊大講堂特約講師，騰訊T4技術專家。先后參與騰訊分布式文件系統（TFS），K-V存儲，SQL集群，接入網關（TGW）的設計與研發。見證了騰訊NoSQL從07年誕生，08、09批量應用，10年至今應用于騰訊開放平臺讓更多的第三方開發者使用；關注于構建具有低成本、高性能、高可用，可擴展，易運營特點的互聯網海量后臺服務。目前任騰訊架構平臺部平臺開發中心技術總監。

　　此文已發表在《程序員》雜志。

　　一、前言

　　NoSQL的歷史很長，最早可以追朔到Berkeley DB等嵌入式數據庫的年代。互聯網行業的高速發展對大數據的需求，為NoSQL的發展起到了推波助瀾的作用。互聯網時代的NoSQL，源起于Google為解決大數據的存儲與計算而提出的GFS + Bigtable + Map Reduce。隨后Hadoop(Hdfs+Hbase+MapReduce)、 Hypertable、Memcached，Tokyo cabinet，Redis， Dynamo，Cassandra等等NoSQL產品雨后春筍般的推出，使得NoSQL技術廣泛應用于互聯網各個領域。

　　在騰訊過去的幾年中，互聯網社交平臺取得令人矚目的發展。包括平臺用戶基數、在線、應用數都取得突飛猛進的增長；另外隨著開放的加劇，還有越來越多的第三方選擇社交平臺開發應用。這些外部條件的變化對技術平臺的而言，也帶來了新挑戰：除需要為用戶提供更強的海量服務外，同時還需要提供開放的軟件基礎架構來幫助第三方開發海量服務。

　　在解決這些問題的實踐中，總結了很多經驗。其中關鍵一點則是通過NoSQL技術來構建海量服務的數據層，并通過分析和總結出不同的業務場景和技術特點，為各種場景提供更合適的數據層解決方案。具體而言：

• 相冊、日志等UGC類應用，主要是自我產生數據，他人以瀏覽為主，其技術特點是讀取量巨大，修改量低于讀取量一個量級，數據量從幾百T至P級不等。提供SAS、SATA級的TDB、TFS解決方案。
• 農牧場等Social Game類應用，核心數據是用戶背包數據，互動性很強，其技術特點是巨大讀取量與修改量，數據量在百G級別。提供MEM級的TMEM解決方案。
• 信息中心的Feeds類應用，其技術特點是巨大的修改量與讀取量，數據量也在幾十T到幾百T不等。提供SSD級的TSSD解決方案。

　　二、【2006~2008】因QQ相冊而研發TFS、TDB

　　回顧NoSQL在騰訊的發展歷程，需要從2006年騰訊分布式文件系統TFS的研發開始談起，TFS目的是在公司內部構建統一的存儲平臺，為各個BU提供文件系統服務。第一期的重點是要能夠支持到QQ相冊的快速發展。當時QQ相冊使用傳統企業級存儲硬件+標準Linux文件系統的老架構，在數百億的圖片數，每天近10億長尾下載的規模下已難以為繼。通過分析，老架構主要有下面三個問題：

• 采用FC-SAN等高端企業級存儲硬件，這些硬件主要是針對電信、銀行等高ARPU值的行業客戶而生，價格通常比較貴，對盛行免費的互聯網企業來說，成本壓力大。
• 使用通用的Linux文件系統，對相冊海量小文件的場景，空間利用和IO性能都不能很好的滿足要求。
• 元數據與對象數據耦合，擴展性和可維護性較差，單機故障以及擴容都是異常繁瑣的運維操作。

　　TFS采用廉價的存儲設備，在軟件層面使用類似軟raid的技術來滿足系統基于不可靠硬件的可靠性要求。將對象數據與元數據分離：對象數據存儲采用自研的CHUNK文件系統，inode節點更小，空間分配采用了基于append + delete更為緊湊的管理方式，使得單機最大可以支持數10億的圖片文件；元數據使用MYSQL存儲。系統架構如下：

　　上面的架構很好的滿足了數百億級別規模下的QQ相冊業務發展。大致在2007年的時候，QQ相冊采用TFS的新架構趨于穩定，同時業務發展需要，對用戶上傳也放開了限制，用戶上傳瀏覽的活躍度上升的一個新的量級，用戶目錄、文件索引等元數據規模突破千億。在使用MySQL應對如此大規模的元數據的場景下，暴露出一些問題：

• 索引低效：在QQ相冊的場景，上千億的記錄，使用MySQL的B樹索引索引的存儲量消耗都在數TB到數十TB。 海量索引在無法全內存的情況會帶來IO的多次訪問，一方面增加了單次訪問的時延，另一方面降低了磁盤的IO利用率。
• 數據搬遷：每天數億的圖片上傳導致系統擴容，IDC分布策略，導致數據搬遷是常態。使用MySQL，使用select逐條記錄方式搬遷，不同的記錄分散在不同的磁盤偏移，一方面搬遷速度較慢，另一方面由遷移導致的磁盤隨機IO與業務正常訪問相互交織在一起，從而影響到在線業務訪問。
• 系統控制：MySQL更多針對是各種數據通用場景所做的設計與開發，實現較復雜。在使用中遇到性能問題，異常故障時難以定位原因，對業務系統來說，已經是無法打破的天花板。

　　針對上面的問題結合業務需求，2007年底研發出TDB用以替代MySQL，TDB是一個典型的K-V存儲系統。其特點是：接口簡單，性能高效，具備優秀的擴展能力。

　　數據層面，索引設計使用HASH，通過KEY可直接定位磁盤物理偏移，避免B樹設計導致的二次定位磁盤性能開銷，解決索引低效的問題。同時采用16MB大磁盤塊的設計，使得TDB的數據遷移速度可達網卡性能上限，解決遷移性能問題。另外系統可控性更強，一方面因為是專用場景，所以可以簡化設計，方便定位問題與優化更新；另一方面打通了存儲系統到磁盤IO的控制路徑，避免MySQL的系統天花板。

　　接入層面，為業務提供透明的訪問代理，從而實現無縫的水平擴展。由于接口簡單，并且是PAAS，業務使用非常方便，從2007年底開始，在Qzone、朋友、群空間等社區應用中逐步取得了廣泛應用。

　　三、【2009】Social Game催生的TMEM

　　2009年有一款叫農場的游戲大家應該不會陌生，農場的火爆帶動了一批Social Game應用的興起。其典型特點（1）好友間互動性很強，用戶背包數據會被頻繁的修改與讀取；（2）交叉訪問，無明顯熱點數據；舉個例子來說，對于傳統的應用來說，用戶間交互相對較弱，活躍用戶數據就是熱點數據；而對于Social Game而言，用戶交互性強，通過交叉訪問，活躍用戶也會頻繁訪問與修改非活躍用戶數據。（3）放大效果明顯；比如用戶每次登陸，通常會遍歷好友的農場，會遍歷菜地偷菜，捉蟲，一次偷菜、捉蟲會導致多個用戶的多個背包數據修改。這些行為一方面導致整個系統中無明顯熱點數據，用戶傳統的讀緩存+寫落地的方式則難以很好的滿足這些業務的需求；另一方面龐大的用戶基數之上的火爆應用，往往單款應用就會有每秒數百萬次的訪問量，這種海量訪問不光對存儲層面，同時對網絡通訊層面提出更高的性能要求。

　　針對以上新興面臨的問題，很明顯TDB并不能很好的解決，所以09年圍繞著網絡通信，內存持久化兩個方面，做了大量的設計與論證。2009年底左右推出新的服務TMEM。

　　核心有兩點：

• 提供內核級KCCD網絡通訊組件，提升網絡通信性能，在網絡包量吞吐方面相對于應用層提升了接近1倍的性能。
• 通過將操作流水加數據鏡像落地TFS，解決了內存持久化的問題。

　　TMEM的出現很好的滿足了業務海量訪問的需求。不過畢竟內存介質的成本比較高，所以TMEM在小數據量的場景下，性價比比較高。但針對于中大數據規模的海量訪問的場景，使用TMEM的成本偏高，而使用SAS介質的TDB，則IO性能又不能很好的滿足。比如社區中各類應用產生的Feeds，數據量數十TB至數百TB，每天訪問量數十億至數百億，應對該場景傳統的做法必須得是前端內存緩存加上后端落地存儲。分級存儲導致的內存數據保護，各級間數據一致性，另外最為關鍵的一點，與Social Game類似，Feeds也是典型交叉訪問，熱點不是非常明顯，等等這些都是數據層亟需解決的難題。

　　四、【2010】順SSD之勢的TSSD

　　在2010年的時候，引入了SSD存儲介質，開始構建TSSD K-V存儲系統。SSD的特點：有著很好的隨機讀取性能，往往單盤可達數萬IOPS，遠高于SAS、SATA的數百隨機IOPS。容量方面也接近SAS盤的容量，可達數百GB。但SSD也有弊端：（1）壽命有限，隨機寫入的壽命相對于順序寫入為1/10左右；（2）隨機寫入場景，性能易受干擾，毛刺率較高；具體而言：受限于物理機制，SSD的存儲單元只能先擦除才能寫入，并且擦除次數有限，針對NAND芯片，在3000~5000次左右。其中擦除單元是512KB，寫入單元是4KB。隨機寫入的場景，會帶來寫入放大。

　　因此應用SSD存儲介質，必須優化隨機寫入性能。TSSD通過構建地址映射，增加隨機寫入內存緩沖區，實現隨機轉順序的寫入；通過定期的垃圾回收機制，回收垃圾數據。

　　TSSD系統中，單機可以支持容量數TB，性能隨機數萬次IOPS。這樣基于TSSD使用簡單的架構，更少的機器便可支持到容量數十至數百TB，性能數十萬IOPS的Feeds類應用。

　　五、NoSQL小結

　　至此，業已構建出基于內存、SSD、SAS、SATA各類存儲介質的存儲系統，在上面也已提到各類存儲系統所對應的使用場景。實際應用中，各種業務場景千變萬化，有沒有統一的方法來判別和選擇合適的存儲系統呢？大致在1987年，Jim Gray發表了這個"五分鐘法則"的觀點，簡而言之，如果一條記錄頻繁被訪問，就應該放到內存里，否則的話就應該待在硬盤上按需要再訪問。這個臨界點就是五分鐘。這個看似經驗公式，隱含的是硬件性能和成本兩個方面的因素。大約在1997年的時候，Jim Gray再次回顧了該法則，并引入了SSD，驗證了該法則依然正確。這里不在贅述該法則。

　　很多情況下需要一種直接根據業務的訪問模型，因此使用IO訪問密度，即每GB的存儲的IO訪問次數，會更為直觀。那看看目前常用的幾種存儲介質：

　　SATA：希捷2TB/7200轉/SATA(ST32000644NS)

　　SAS：希捷300GB/15000轉/SAS(ST3300657SS)

　　SSD：Intel 160GB X25-M G2 34nm

　　DRAM：三星8GB DDR3 1333 REG ECC

　　(中關村在線報價，人民幣美元匯率：6.3157，2012/4/16)

　　根據業務IO訪問密度，選擇合適的存儲介質，就是根據存儲介質的IO訪問密度特性與價格來選擇性價比最高的存儲介質，即找到每種存儲介質之間IO訪問密度的臨界點。

　　臨界點G（X,Y）.IO per sec per GB = X.IO per sec per GB * Y.price per GB / X. price per GB，X與Y分別表示對比的兩種存儲介質，且Y.IO per sec per GB 大于 X.IO per sec per GB。根據上面的公式，可以得到表格如下：

　　怎么理解上面的公式呢?舉計算SATA與SAS之間的臨界點為例，G(SATA,SAS).IO per sec per GB = SATA.IO per sec per GB* SAS.price per GB/SATA.price per GB = 1/20 * 0.71/0.23 = 0.15 per sec per GB。假設現在有1GB的數據，訪問密度是X，X小于2/3，那么使用SAS介質則需要0.71$，如果選擇SATA介質，則需要X/(1/20) * 0.23 $。當X為0.15時，選擇SATA與SAS的成本是一樣的，當大于0.15時，則使用SATA的成本相對于SAS則高；否則則低。SAS比SSD，SSD比DRAM也是類似。

　　實際上對于一款存儲介質而言，IO訪問特性與單位每GB的成本是決定了其存在與生命力的關鍵因素。通常來講，其IO訪問特性一般來講不會有革命性的變化，而單位每GB的成本卻是可以控制的，所以廠商總是會圍繞容量來不斷的深入優化。

　　六、開放的挑戰

　　2010年底開始，隨著開放的加劇，越來越多的第三方選擇社交平臺開發應用。這些外部條件的變化對技術平臺的而言，也帶來了新挑戰：除需要為用戶提供更強的海量服務外，同時還需要提供開放的軟件基礎架構來幫助第三方開發海量服務。現有已成熟的NoSQL的架構能否被外部第三方接受，其關鍵的一點是接口的友好性和兼容性。采用的標準化的接口，會大大降低外部開發者的使用門檻。因此，在2011年推出了CMEM 的NoSQL云存儲服務，開發者可直接使用memcached接口，并即將支持redis接口。同時也提供了SQL云存儲服務，開發者可用MySQL客戶端直接訪問。后續推出CFS文件系統云存儲服務，開發者可使用posix接口訪問到TFS。

　　回顧TFS、TDB、TMEM、TSSD、CMEM、CDB、CFS等一系列存儲系統過去近6個年頭的演進發展。有兩點經驗可供分享：

　　1、建議NoSQL開發者盡量選擇構建PAAS服務。一方面對業務開發者而言，不需關心日常運維，使用更為方便，易于接受；另一方面更容易形成用戶需求提出、實現與發布的閉環，從而方便小步快跑，快速迭代出完善的服務。

　　2、建議中小業務開發者盡量使用云服務。通常一個NoSQL服務所面臨的挑戰有兩個方面：一方面是大家所直觀感受的產品本身；另一方面是服務背后的運營體系。類似與鐵路系統、消防系統，用戶所直觀感受到的火車、鐵路，消防栓、消防車只是整個服務其中一個部分，是冰山海平面之上的部分；用戶所感受不到的鐵路規劃、調度系統、消防規劃、消防演練，報警系統等后臺運營體系通常是冰山海平面以下的部分，往往需要有大量的人力和財力投入，可能是中小公司難以投入的。而在沒有穩固的后臺運營體系支撐下，類似動車事故、火災等生產系統故障難以避免，并最終為業務帶來不可估量的損失。

　　從過去幾年來看，硬件在變，存儲介質的性能與容量在不斷提升，并不斷會有新存儲介質的產生；業務在變，不斷有新興的產品和新的業務體驗，并對后臺系統提出新的挑戰和需求；唯一不變的就是需要擁抱變化，為業務提供更貼切與更優化的存儲服務。想了解更多關于騰訊TFS、TDB、TMEM、TSSD、CMEM、CDB、CFS等一系列存儲系統過去近6個年頭的演進發展，大家可以到騰訊大講堂網站(djt.qq.com)翻閱架構平臺部的分享文章，謝謝。