Big Data in Real-Time at Twitter

http://www.slideshare.net/nkallen/q-con-3770885?from=ss_embed slideshare

http://qconsf.com/dl/qcon-sanfran-2010/slides/NickKallen_DataArchitectureAtTwitterScale.pdf pdf

Twitter 如何即時的處理龐大的資料,這篇投影片的出處是在 2010 年 http://qconsf.com/ 的演講內容,還有其他看起來很精彩的內容。

這是一個軟體開發的會議 http://qconferences.com/

從四個關鍵瓶頸開始思考,如何解決 twitter 資料不斷擴充查詢資料延遲時間不斷增加的問題。

  • 推特
  • 時間線
  • 社交圖
  • 搜尋索引

針對每個問題的問題,提出從前的問題,目前的解法

tweet

推特的單位文章,需透過作者與 id 搜尋

問題:主從伺服器架構不足,硬碟空間擴充限制,

解法:切割資料!用什麼切割?tweet id、作者?用 timestamp 切割

timelines

觀察所有好友最新的文章

問題:用關聯式資料庫需要先子查詢好友,再查詢文章,慢到爆炸

解法:先全部查好存到記憶體?不太確定…看不太懂

social graphs

列出跟隨者,有反跟隨者…等等好友關聯狀態

問題:資料量大到無法保持在記憶體

解法:反正規劃,把原先關聯的資料拆成兩份,並用作者來切割資料分散儲存。

search indices

即時文章內容關鍵字搜尋,將文章切割成數個關鍵字儲存。

問題:無法保持在記憶體太久

解法:用時間與關鍵字分割資料,分散儲存,用mysql,

結論:

  • 沒有最完美通用的解法,只有當下較適合的解法。
  • 擴展性幾乎透過幾個方式解決,分割、索引、副本。
  • 即時處理資料最好存在記憶體,其次才是硬碟。
  • 不是所有情況都可以先將資料計算好就可以解決的。

心得:

沒有萬靈丹,以往系統開發經驗裡都透過關聯資料庫,所有資料都可以藉由存入與索引就解決。

再遇到新的型態的資料庫時也會這樣想,那我就全部都丟給 HBase 來做好了,從 Twitter 的經驗來看,需要重新評估這個想法的正確性,他們針對了四個發生的瓶頸,仔細思考原先的問題,並針對每種的癥結點提出了不同的解法,切割資料的策略皆有些不同,也不一定應用相同的資料庫引擎來處理,但大部分思考的邏輯似乎有跡可循,像 facebook 原先用來 存 inbox 的 Cassandra 也只是針對獨立的應用所產生的儲存引擎,亦即他內部可能針對了不同的應用,皆有不同的解法,所以如果要開發出一個新一代可通吃的資料庫引擎,可能至少需要資源非關聯與關聯式資料庫,並提供針對不同情況更詳細的設定,並可混合應用,才有可能符合未來世界資料不斷增加所需要處理這些資料的系統,但這種工作小公司又做不來,所以應該不太會賺錢…。

相關資源:

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *