Twitter公司已經步步發展并且走向成熟,因此在即時可用性之外、他們也開始意識到數據一致性保障的重要意義。
至少該公司通過打造的全新“曼哈頓”數據管理軟件將這一訴求擺上了核心地位,并在本周三的一篇博文中正式披露了這套基礎存儲系統的誕生。
雖然博文并沒有提到,但根據我們掌握的消息、Twitter正在開發一套所謂次級索引方案。這是一項被囊括在曼哈頓軟件中、具備巨大潛力的功能,能夠幫助公司員工在搜索社交網絡的龐大存儲數據時提供出色的靈活性,足以成為這家上市公司進一步推進商業運作的重要利器。
我們首先來分析Twitter本周在博文中所公開的相關信息。
“在過去幾年當中,我們發現自身對于一套能夠每秒處理百萬級別查詢并能在實時環境下實現極致低延遲的存儲系統的需求正變得愈發迫切。系統的可用性及速度當然同樣非常重要,不過這套存儲系統不僅要具備出色的性能表現、同時也需要擁有跨越全世界多個地區的卓越可擴展能力,”Twitter在其網站上寫道。
曼哈頓是一款由該社交網絡自家工程師所打造的軟件方案,旨在應對每秒接近六千條推文所帶來的巨大系統壓力。盡管六千條推文本身所涉及的數據量并不是很大,但這部分信息存在多種復雜特性,因為曼哈頓軟件還需要處理與之相關的回復以及針對每條推文的轉發——如果某位名人發布了新動態,數百萬關注者的回復將立即洶涌而來,這就讓原本看似簡單的問題變得復雜起來。
在這項技術的幫助下——也許曼哈頓軟件最終會走上開源道路——Twitter得以利用Cassandra的最終一致性功能外加其它工具通過單一大型系統實現堅實的一致性保障,而這也正是推動社交網絡下決心更替存儲系統的主要理由。根據我們掌握的情況,曼哈頓的開發工作已經持續了一年以上。
開發人員可以在從曼哈頓中讀取或者向其寫入的過程中選擇數據一致性級別,從而通過創建新服務的方式在可用性(即如何快速實現訪問)與一致性(即如何確保查詢結果的準確性)之間找到平衡點。
有鑒于此,Twitter的程序員們能夠訪問“高一致性服務”,它會將一致性算法與副本日志結合起來、從而確保事件按照實際順序對副本產生影響。
到目前為止,Twitter已經推出了LOCAL_CAS(單一數據中心內部的高一致性)與GLOBAL_CAS(跨越多個設施間的高一致性)。它們將“在應用程序以及數據建模方面采取不同的平衡點選取方式,”Twitter在一篇討論曼哈頓項目的博文中指出。
讓我們更進一步
該系統當中的數據會被保存在三套不同的系統當中:seadb是一種只讀型文件格式,sstable是一種面向高強度寫入工作負載的日志結構型合并樹,而btree則是一種重讀取而輕寫入的系統。曼哈頓項目的“Core”系統隨后會決定要把信息保存在磁盤、內在或者是固態硬盤(簡稱SSD)當中。
曼哈頓項目可以將輸入數據匹配為最合適的格式。舉例來說,Hadoop工作負載的輸出內容會以Hadoop文件系統的形式導入到曼哈頓當中,而后者則將其轉換成seadb文件格式“從而利用速度更快的SSD或者內存機制將其進一步導入至集群當中,”Twitter方面解釋道。
該數據庫支持多租戶機制并包含自有速率限制服務,從而避免Twitter開發者們的海量請求將系統徹底淹沒。這些系統被打包成前端,這樣工程技術人員就可以訪問這套“自助式”存儲系統了,Twitter解釋道。
“工程技術人員能夠針對其應用程序的具體需求進行配置(例如存儲規模乃至每秒查詢數量等等)并在幾秒鐘之內開始使用其存儲功能,而且完全不必等待硬件安裝或者模式設置過程,”Twitter在文中對該系統作出這樣的描述。
Twitter已經計劃在未來發布一份用于概述該技術的白皮書,甚至很有可能將該數據庫項目推向開源。當然,開源工作在短時間內還無法完成,因為一位前任Twitter工程師曾在一篇博文的在線留言板中表示:“這套數據庫中包含大量運作部件以及內部集成機制,因此將其轉為開源還有很多工作要做。”
下一布計劃?打造次級索引
根據我們了解到的情況,在未來的開發工作中,該公司將把工作重心放在次級索引機制的締造上。
次級索引機制允許開發人員向數據庫索引中添加一套額外鍵,從而顯著提升開發者在瀏覽并查詢大規模數據集時的速度表現。
舉例來說,Amazon Web Services的主力方案DynamoDB就以local與global(多數據中心)兩種格式實現了這一技術。
通過向曼哈頓數據庫內添加次級索引,Twitter為其開發者賦予了面向超大規模數據集編寫復雜查詢的能力,這套索引機制將被保存在內存當中。
這意味著,假如Twitter的商業團隊希望建立起一套速度出眾的廣告系統,則可以從多種不同因素出發、以更低的成本與遠超以往的靈活性向用戶呈現出近實時廣告內容。
要想提供更等級、針對性進一步細化的廣告內容呈現效果,次級索引這類系統可謂至關重要;而這類技術也將成為Twitter實現商業化運營的重要武器。
不過技術挑戰也仍然存在:次級索引初期只能實現單一數據中心內部的一致性保障,這是因為全局次級索引對計算量要求過高、暫時還無法實現。