轉自：https://my.oschina.net/u/2982571/blog/775452
設計背景
百度的鏈接處理系統每天處理萬億級的超鏈數據，在過去，這是一系列Mapreduce的批量過程，對時效性收錄很不友好。在新一代搜索引擎架構設計中，我們采用流式、增量處理替代了之前的批量、全量處理。鏈接從被發現到存入鏈接庫再到被調度程序選出，變成一個全實時的過程。在這個實時處理過程中，無論鏈接的入庫還是選取，都需要對鏈接庫進行修改，存儲系統需要支持千萬甚至上億QPS的隨機讀寫。舊的存儲系統無論在單機性能，還是在擴展性方面，都無法滿足，所以我們設計了Tera。
鏈接存儲的需求
1. 數據按序存儲
支持主域、站點和前綴等多維度統計、讀取。
2. 自動負載均衡
分區可以動態調整，在一個分區數據量變大或者訪問頻率過高時，可以自動切分，小的分區也可以自動合並。
3. 記錄包含時間戳和多個版本
對於鏈接歷史抓取狀態等記錄，需要保留多個版本，對於策略回灌等場景，需要根據時間戳判斷，避免舊的數據覆蓋新的。
4. 強一致性
寫入成功，立即可被所有的用戶看到。
5. 支持列存儲
在用戶只訪問固定的少數幾列時，能使用更小的IO，提供更高的性能（相對於訪問全記錄），要求底層存儲將這部分列在物理上單獨存儲。
設計目標
功能目標
1. 全局有序
key可以是任意字符串(二進制串)，不限長度，比較邏輯可由用戶定義，按Key的范圍分區，分區內由單機維護有序，分區間由Master維護有序。
2. 多版本
每個字段（單元格）都可以保留指定多個版本，系統自動回收過期版本，用戶可以按時間戳存取。
3. 自動分片
用戶不需要關心分片信息，系統自動處理熱點區間的分裂，數據稀疏區間的合並。
單個分區的數據量超過閾值，自動切分為多個，單個分區的讀寫頻率增高時，自動切分。
4. 自動負載均衡和擴容
單機上保存多個分區，分區的總大小和總訪問量達到閾值時，可以觸發將部分分區遷移到空閑的機器。
性能指標
Tera設計使用SSD+SATA磁盤混布機型。
1. 單機吞吐
順序讀寫: 100MB/S
隨機讀1KB: 30000QPS
隨機寫1KB: 30000QPS
2. 延遲
延遲和吞吐需要折衷考慮，在延遲敏感性不高的場合，使用延遲換吞吐策略，延遲定位在10ms級，寫操作延遲<50ms，讀延遲<10ms。
對於對延遲要求高的場合，讀寫延遲定位在<1ms，但吞吐會有損失，初期不做優化重點。
3. 擴展性
水平擴展至萬台級別機器，單機管理百級別數據分片。
| 數據量 | 系統吞吐 | |
|---|---|---|
| 站點信息服務 | 10TB | 百億次/天 |
| 用戶行為分析 | 1PB | 百億次/天 |
| 超鏈存儲 | 10PB | 萬億次/天 |
| 頁面存儲 | 100PB | 萬億次/天 |
設計思路
數據存儲
1. 數據持久性
為保證數據安全性，要使用三副本存儲，但維護副本的一致性與副本丟失恢復需要處理大量細節，基於一個分布式的文件系統構建，可以顯著降低開發代價，所以我們選擇了使用DFS（如BFS）。
系統的所有數據（用戶數據和系統元數據）都存儲在DFS上，通過DFS+WriteAheadLog保證數據的持久性，每次寫入，保證在DFS上三副本落地后，才返回成功。
2. 強一致性
數據會按key分區存儲在DFS上，分區信息由Master統一管理，Master保證每個分區同一時間只由一個數據節點提供讀寫服務，保證一致性。
3. 延遲換吞吐
每次寫操作落地一次導致的性能問題可以通過批量落地實現，比如每10ms數據落地一次，在數據落地前寫操作不返回，代價是增加了5ms的平均響應時間。
4. 存儲接口封裝
Tera不會以某一種DFS作為唯一選擇，而是通過底層存儲接口的封裝，使其可搭建在其他分布式存儲之上，方便用戶根據個性化需求靈活地部署Tera。
希望了解更多？請點擊 https://github.com/baidu/tera