題目
- 現在你是twitter搜索負責人，設計搜索系統，提供圖片、文字搜索
- 用戶1.5 billion，日活800 million
- 每天新增400 million tweets （每個tweet大小300B）
- 每天搜索次數500M
- 搜索格式包含多個words以及 and/or
- 設計高效存儲和查詢tweets的系統
約束
- 日存儲量120GB，月3.6TB，10年432TB
- tweet數量：日400M，月12B，年144B，5年740B
- 讀qps 6K， 寫qps 4.5K
- 讀寫均衡，高併發系統
服務
high level
- 索引服務 + 存儲服務
- 存儲數量很大，一臺機器存不下，sharding要能加快搜索；
- 存儲時需要做一些優化，加快搜索；生成索引信息，提取word和對應tweetId；可以快速找到某個word對應的tweetid列表；
- 用戶只會關心她關注的好友的信息，如果一個人粉絲特別多，pull可能不行；
存儲
存儲規模
- 機器數量：5年220TB，按照80%利用率；需要300TB；75臺機器；
- 1T數據條數，1000billion數據；需要一個發號器srv，7位62編碼即可實現
索引規模
-
預估index的大小：
- 一個word平均5B，500K個word，5 * 500KB = 2.5MB
- tweetID：每個tweetID的大小爲7B，5年，7B * 740B = 5TB；考慮每條tweet有50個word，有效word是20個；每個tweetID被重複使用20次；需要100TB
- 總大小 (100TB + 2.5MB) = 100TB
-
機器預估：
- 內存144GB，大概需要700臺機器存儲index
-
sharding on words 主要問題
- 訪問熱點word，導致機器負載過高
- 分佈不均勻，有些word是高頻詞，引用的tweet過多
- 解法：？？
-
sharding on tweetID
- 需要遍歷所有的index server，聚合tweetid集合
擴展
索引服務down掉如何處理
- 重建索引