在數(shù)據(jù)庫工程團(tuán)隊實習(xí)期間，我花費(fèi)了上個暑假的時間分析了Facebook的數(shù)據(jù)庫工作負(fù)載(workload)并幫助開發(fā)了一款稱為LinkBench的數(shù)據(jù)庫性能測試工具。這個周我們很榮幸的將LinkBench發(fā)布到了 GitHub上，并希望它能夠成為每個需要進(jìn)行性能測試和數(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é)點(diǎn)間不同的關(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ù)庫項目團(tuán)隊仍不斷地探索在MySQL中存儲社交圖譜數(shù)據(jù)的其他方法。起初我們使用一些開源的性能測試工具來評測數(shù)據(jù)庫系統(tǒng)。然而，數(shù)據(jù)庫性能測試的黃金法則是要在真實的產(chǎn)品負(fù)載情況下去測試系統(tǒng)的性能，但是一般的工具都達(dá)不到這樣的要求。當(dāng)需要對Facebook基礎(chǔ)設(shè)施中的某個重要組件進(jìn)行調(diào)整時，我們需要理解在生產(chǎn)負(fù)載的情況下數(shù)據(jù)庫系統(tǒng)是如何運(yùn)作的。

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

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

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

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

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

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

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

#p#

LinkBench的架構(gòu)

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

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

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

測試結(jié)果

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

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

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

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

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

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