LinkBench--社交圖譜的數(shù)據(jù)庫性能測試工具
在數(shù)據(jù)庫工程團隊實習期間，我花費了上個暑假的時間分析了Facebook的數(shù)據(jù)庫工作負載(workload)并幫助開發(fā)了一款稱為LinkBench的數(shù)據(jù)庫性能測試工具。這個周我們很榮幸的將LinkBench發(fā)布到了 GitHub上，并希望它能夠成為每個需要進行性能測試和數(shù)據(jù)庫調優(yōu)工作的開發(fā)者手中的利器。
Facebook社交圖譜(social graph)和MySQL
MySQL作為公司基礎架構的重要組件，早期就被Facebook用于存儲像文章，評論，贊(likes)和頁面之類的數(shù)據(jù)。
我們展現(xiàn)數(shù)據(jù)的一種方式就是社交圖譜(social graph)，其中的對象如人(people),文章(posts),評論(comments)和頁面(pages)是通過節(jié)點間不同的關系類型(模型) 相互關聯(lián)(圖中的有向邊-directed edges)的。不同的關聯(lián)關系類型可以表示好友關系(friendship between two users)，用戶喜歡某個對象的關系(user like another object)，還可以表示文章屬主(ownership of post)關系等等。
為什么需要一款新的數(shù)據(jù)庫性能測試工具？
過去的5到10年里，數(shù)據(jù)庫領域又迎來了一次創(chuàng)新的高潮，像NoSQL和NewSQL已經成為了關系數(shù)據(jù)庫(relational databases)的強力競爭者。與此同時硬件領域也在迅速地發(fā)展，固態(tài)存儲設備和多核CPU已經成為業(yè)界的主流，能夠為數(shù)據(jù)庫提供巨大的性能提升。雖然我們已經能夠通過讓MySQL使用FlashCache來發(fā)揮出固態(tài)存儲設備的優(yōu)勢，但是對基于固態(tài)存儲的數(shù)據(jù)庫優(yōu)化還有很多工作要做，只有這樣才能最大限度的發(fā)掘出硬件的性能。
這些改變對Facebook來說意味著什么？首先，它意味著在提高響應速度的同時我們有更多的機會來提高數(shù)據(jù)庫基礎設施(infrastructure) 的效率，如降低能源的使用和硬件的開銷。其次，它意味著我們需要對那些為解決Facebook負載而即將上線的數(shù)據(jù)庫系統(tǒng)在適應性 (suitability)和性能方面做一次系統(tǒng)的評估。
MySQL很好地兼顧了靈活性、性能和易于管理的特性，但是我們的數(shù)據(jù)庫項目團隊仍不斷地探索在MySQL中存儲社交圖譜數(shù)據(jù)的其他方法。起初我們使用一些開源的性能測試工具來評測數(shù)據(jù)庫系統(tǒng)。然而，數(shù)據(jù)庫性能測試的黃金法則是要在真實的產品負載情況下去測試系統(tǒng)的性能，但是一般的工具都達不到這樣的要求。當需要對Facebook基礎設施中的某個重要組件進行調整時，我們需要理解在生產負載的情況下數(shù)據(jù)庫系統(tǒng)是如何運作的。
并且我們認為對于其他構建于數(shù)據(jù)庫和社交應用之上的社區(qū)來說它們也能夠從基于數(shù)據(jù)存儲、檢索社交網絡和其他具有圖譜結構數(shù)據(jù)的性能評測中獲益。對于那些迅速發(fā)展、擁有海量數(shù)據(jù)和豐富的數(shù)據(jù)模型的應用來說，它們對數(shù)據(jù)庫系統(tǒng)的需求都是各不相同的，但是用于測試這些系統(tǒng)負載的性能測試工具卻沒有幾個。
LinkBench通過生成(replicate)混合了數(shù)據(jù)模型，圖譜結構和請求等數(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插入一個好友關系的邊到user63459821”。
理解Facebook社交圖譜的工作負載
我實習的大部分時間都用于分析社交圖譜的數(shù)據(jù)和數(shù)據(jù)庫查詢時的負載，因而我提取了許多LinkBench可以用來對負載進行建模的關鍵參數(shù)。
LinkBench使用的一個特別重要的屬性就是出度分布(out-degree distribution)，它控制圖中每個節(jié)點的出度。出度在過去人們研究過的許多網絡中像人際關系網或網頁間的鏈接都遵循著冪律分布(power- law distributions)，這對于包含著各種節(jié)點類型的社交圖譜也同樣適用，如下圖所示：
LinkBench也需要模擬在生產環(huán)境下對數(shù)據(jù)庫的查詢操作。Facebook網站和手機應用所使用的數(shù)據(jù)大部分來自于內存緩存，只有所有寫操作和小部分讀緩存缺失(cache-miss)情況下才會使用到MySQL。Facebook的工作負載主要是以大量的讀操作為主的，因此即使在緩存命中率很高時，讀操作缺失(read miss)也遠大于寫操作的。
通過將數(shù)據(jù)庫查詢劃分為針對關系(邊)和對象(節(jié)點)的許多小的核心操作，我們就可以逐個地分析在生產數(shù)據(jù)庫環(huán)境下對社交圖譜的每個操作的性能了。下面的表列出了用于保存或查詢圖譜時所對應的查詢或更新操作。
下面的圖展示了在生產環(huán)境中的某個數(shù)據(jù)庫實例上不同的操作隨著時間的推移而產生的負載變化。從圖中可以看到對于邊的操作和讀操作，特別是邊界掃描 (edge range scan)會給系統(tǒng)帶來極大的負擔。舉個邊界掃描的例子，如“按最早到最近的時間順序找出某個文章的所有評論”或“找出某個用戶的所有好友”。
在真實環(huán)境中的MySQL實例上，對社交圖譜的各種操作隨著時間的變化圖。百分比是按相對于當前實例上每秒平均操作數(shù)計算得來的。
通過對負載跟蹤(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之類的內存緩存技術，我們不確定這是否對訪問模式產生了影響。
- 圖譜的結構對訪問模式也有重要的影響：與高出度節(jié)點相連接的邊通常比那些與低出度節(jié)點相連接的邊會有更頻繁的讀、寫操作。
我可以從產生這些效果的負載跟蹤中提取到相關參數(shù)，并可以在LinkBench中重現(xiàn)。
#p#
LinkBench的架構
LinkBench被設計為可定制和可擴展的。它允許我們通過生成社交圖譜的子集來模擬負載，這一特性對評估數(shù)據(jù)庫處理特定關聯(lián)類型的性能來說是至關重要的。例如，將以寫為主(write-heavy)和讀為主(read-heavy)的關聯(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ù)。
測試結果
我們對打了Facebook補丁(請看http://www.facebook.com/MySQLatFacebook) 的MySQL 5.1.53進行性能測試。我們在數(shù)據(jù)庫中生成了12億個節(jié)點和49億條邊，用MySQL標準的未經壓縮的InnoDB表存儲，占用了1.4TB硬盤空間。MySQL服務器擁有2個CPU，8+核心(8+ cores/socket)，144G內存，以及16kB讀取延遲(read latency at 16kB)小于500μs的固態(tài)硬盤。
我們對不同級別的負載進行了一系列的性能測試。為了測試MySQL服務器的最大吞吐量，我們運行了100個請求線程，每個線程都以最快的速度對MySQL 進行請求。我們獲得了一個在每秒11029個請求條件下系統(tǒng)吞吐量的測試結果。這次試驗的請求延遲如下表所示，表明系統(tǒng)在極高的負載下仍能進行響應。即使 MySQL處于吞吐量滿載的情況時，延遲的中位數(shù)(median latencies)也是很低的。為了模擬真實產品環(huán)境下服務器不會一直滿載運行的場景，LinkBench能夠調節(jié)(throttle)請求的數(shù)量，在這種情況下延遲還可以再低。
MySQL LinkBench的操作延遲是以ms計算的。延遲指的是從LinkBench driver調用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以及更多關于使用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
