在數(shù)據(jù)庫工程團隊實習期間，我花費了上個暑假的時間分析了Facebook的數(shù)據(jù)庫工作負載(workload)并幫助開發(fā)了一款稱為LinkBench的數(shù)據(jù)庫性能測試工具。這個周我們很榮幸的將LinkBench發(fā)布到了 GitHub上，并希望它能夠成為每個需要進行性能測試和數(shù)據(jù)庫調(diào)優(yōu)工作的開發(fā)者手中的利器。 

Facebook社交圖譜(social graph)和MySQL

MySQL作為公司基礎(chǔ)架構(gòu)的重要組件，早期就被Facebook用于存儲像文章，評論，贊(likes)和頁面之類的數(shù)據(jù)。

我們展現(xiàn)數(shù)據(jù)的一種方式就是社交圖譜(social graph)，其中的對象如人(people),文章(posts),評論(comments)和頁面(pages)是通過節(jié)點間不同的關(guān)系類型(模型) 相互關(guān)聯(lián)(圖中的有向邊-directed edges)的。不同的關(guān)聯(lián)關(guān)系類型可以表示好友關(guān)系(friendship between two users)，用戶喜歡某個對象的關(guān)系(user like another object)，還可以表示文章屬主(ownership of post)關(guān)系等等。

MySQL很好地兼顧了靈活性、性能和易于管理的特性，但是我們的數(shù)據(jù)庫項目團隊仍不斷地探索在MySQL中存儲社交圖譜數(shù)據(jù)的其他方法。起初我們使用一些開源的性能測試工具來評測數(shù)據(jù)庫系統(tǒng)。然而，數(shù)據(jù)庫性能測試的黃金法則是要在真實的產(chǎn)品負載情況下去測試系統(tǒng)的性能，但是一般的工具都達不到這樣的要求。當需要對Facebook基礎(chǔ)設施中的某個重要組件進行調(diào)整時，我們需要理解在生產(chǎn)負載的情況下數(shù)據(jù)庫系統(tǒng)是如何運作的。

并且我們認為對于其他構(gòu)建于數(shù)據(jù)庫和社交應用之上的社區(qū)來說它們也能夠從基于數(shù)據(jù)存儲、檢索社交網(wǎng)絡和其他具有圖譜結(jié)構(gòu)數(shù)據(jù)的性能評測中獲益。對于那些迅速發(fā)展、擁有海量數(shù)據(jù)和豐富的數(shù)據(jù)模型的應用來說，它們對數(shù)據(jù)庫系統(tǒng)的需求都是各不相同的，但是用于測試這些系統(tǒng)負載的性能測試工具卻沒有幾個。

LinkBench通過生成(replicate)混合了數(shù)據(jù)模型，圖譜結(jié)構(gòu)和請求等數(shù)據(jù)來填充數(shù)據(jù)庫的方式實現(xiàn)了對存儲著社交圖譜的MySQL進行負載測試的目標。LinkBench是一個用于生成圖(graph-serving)的性能測試工具，而不是處理圖(graph-processing)的測試工具--區(qū)別在于前者會模擬在一個交互式的社交應用中的那些具有事務性的動作(transactional workload)，而后者只是模擬動作的流程(analytics workload)。這個測試工具不是用于解決圖的社區(qū)發(fā)現(xiàn)問題(find graph communities)或圖的切分問題(graph partitioning)，而是用來實時地查詢并更新數(shù)據(jù)庫中的圖譜。例如，對于圖的查詢比較常見的形式就是找到所有來自節(jié)點X并且是A類型的所有的邊，而更新操作就是插入、刪除邊或者更新圖中的節(jié)點或邊。舉個更新操作的例子，如“從user4插入一個好友關(guān)系的邊到user63459821”。

LinkBench也需要模擬在生產(chǎn)環(huán)境下對數(shù)據(jù)庫的查詢操作。Facebook網(wǎng)站和手機應用所使用的數(shù)據(jù)大部分來自于內(nèi)存緩存，只有所有寫操作和小部分讀緩存缺失(cache-miss)情況下才會使用到MySQL。Facebook的工作負載主要是以大量的讀操作為主的，因此即使在緩存命中率很高時，讀操作缺失(read miss)也遠大于寫操作的。

 
通過將數(shù)據(jù)庫查詢劃分為針對關(guān)系(邊)和對象(節(jié)點)的許多小的核心操作，我們就可以逐個地分析在生產(chǎn)數(shù)據(jù)庫環(huán)境下對社交圖譜的每個操作的性能了。下面的表列出了用于保存或查詢圖譜時所對應的查詢或更新操作。
 

通過對負載跟蹤(workload trace)，并進一步分析了不同操作的訪問模式(access pattern)后，我發(fā)現(xiàn)了一些更有趣的東西： 

• 通過對數(shù)據(jù)庫中一些使用頻繁(hot)、次頻繁(warm)和大量不頻繁(cold)的行(rows)進行實驗，發(fā)現(xiàn)對節(jié)點(nodes)和邊 (edges)的讀、寫訪問模式也都遵循著冪律分布(power-law distribution)。這對一般的數(shù)據(jù)庫來說是正常的，但是由于Facebook使用了像memcached之類的內(nèi)存緩存技術(shù)，我們不確定這是否對訪問模式產(chǎn)生了影響。
• 圖譜的結(jié)構(gòu)對訪問模式也有重要的影響：與高出度節(jié)點相連接的邊通常比那些與低出度節(jié)點相連接的邊會有更頻繁的讀、寫操作。

我可以從產(chǎn)生這些效果的負載跟蹤中提取到相關(guān)參數(shù)，并可以在LinkBench中重現(xiàn)。

#p#

LinkBench的架構(gòu)

LinkBench被設計為可定制和可擴展的。它允許我們通過生成社交圖譜的子集來模擬負載，這一特性對評估數(shù)據(jù)庫處理特定關(guān)聯(lián)類型的性能來說是至關(guān)重要的。例如，將以寫為主(write-heavy)和讀為主(read-heavy)的關(guān)聯(lián)類型分別存儲到不同的數(shù)據(jù)庫后端是有必要的，因此我們可以針對每種類型做單獨的性能測試。它也允許我們使用比較容易的方法來編寫適配器從而支持新的數(shù)據(jù)庫系統(tǒng)，因此我們可以比較出在相同的負載下它與MySQL的性能差異。

真正的性能測試工作是由LinkBench driver負責的，它是一個用于生成社交圖譜和各種操作的Java程序。測試工作分為兩個階段：載入階段(load phase)，會生成一個初始的圖譜并載入(loaded in bulk)到數(shù)據(jù)庫中;請求階段(request phase)，許多請求線程會用各種操作對數(shù)據(jù)庫進行并發(fā)訪問。在請求階段，各種操作的延遲和吞吐量都會被統(tǒng)計并給出報告。

Driver在兩個階段的具體行為是通過一個配置文件進行控制的，通過這個配置文件可以輕松地控制性能測試中的各個參數(shù)。
 
 

測試結(jié)果

我們對打了Facebook補丁(請看http://www.facebook.com/MySQLatFacebook) 的MySQL 5.1.53進行性能測試。我們在數(shù)據(jù)庫中生成了12億個節(jié)點和49億條邊，用MySQL標準的未經(jīng)壓縮的InnoDB表存儲，占用了1.4TB硬盤空間。MySQL服務器擁有2個CPU，8+核心(8+ cores/socket)，144G內(nèi)存，以及16kB讀取延遲(read latency at 16kB)小于500μs的固態(tài)硬盤。

我們對不同級別的負載進行了一系列的性能測試。為了測試MySQL服務器的最大吞吐量，我們運行了100個請求線程，每個線程都以最快的速度對MySQL 進行請求。我們獲得了一個在每秒11029個請求條件下系統(tǒng)吞吐量的測試結(jié)果。這次試驗的請求延遲如下表所示，表明系統(tǒng)在極高的負載下仍能進行響應。即使 MySQL處于吞吐量滿載的情況時，延遲的中位數(shù)(median latencies)也是很低的。為了模擬真實產(chǎn)品環(huán)境下服務器不會一直滿載運行的場景，LinkBench能夠調(diào)節(jié)(throttle)請求的數(shù)量，在這種情況下延遲還可以再低。
 

MySQL LinkBench的操作延遲是以ms計算的。延遲指的是從LinkBench driver調(diào)用Graph Store adapter開始，到返回時為止。

我們也收集了系統(tǒng)資源利用的跟蹤報告來更好地理解服務器的行為。

下面展示的吞吐量和I/O利用率隨時間的變化圖表明服務器需要一些時間來“熱身(warm up)”才能達到一個穩(wěn)定的狀態(tài)。當MySQL處于“熱身”狀態(tài)時，兩種競爭效應(two competing effects)會引起吞吐量上下波動。數(shù)據(jù)庫緩沖池(buffer pool)起初是空的，因此很少的操作可以通過緩存的數(shù)據(jù)來完成。當數(shù)據(jù)庫“熱身”完后，緩沖池充滿了來自磁盤的頁面(pages)，因此大部分的讀就不需要進行I/O操作并能迅速地完成。然而，隨著時間的推移，緩沖池中的大部分頁面(pages)都變成了臟數(shù)據(jù)--例如，頁面包含了還未寫入磁盤的數(shù)據(jù)- 因此當清除臟數(shù)據(jù)(dirty pages)時會導致對磁盤更頻繁的寫操作。

CPU利用率統(tǒng)計圖表明MySQL服務器的性能在當前負載下是不依賴于計算量(not compute-bound)大小的，因為用戶的CPU利用率一直處于50%左右。以 每秒的操作數(shù)(operations/second) 或MB/s測得的高I/O利用率表明MySQL在固態(tài)存儲設備上可獲得更高的I/O能力。

獲取LinkBench

想要獲取LinkBench以及更多關(guān)于使用LinkBench和按需定制的信息請訪問我們的Github頁面: http://github.com/facebook/linkbench

英文原文：LinkBench: A database benchmark for the social graph

譯文鏈接：http://www.oschina.net/translate/linkbench-a-database-benchmark-for-the-social-graph