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 也只是針對獨立的應用所產生的儲存引擎，亦即他內部可能針對了不同的應用，皆有不同的解法，所以如果要開發出一個新一代可通吃的資料庫引擎，可能至少需要資源非關聯與關聯式資料庫，並提供針對不同情況更詳細的設定，並可混合應用，才有可能符合未來世界資料不斷增加所需要處理這些資料的系統，但這種工作小公司又做不來，所以應該不太會賺錢…。

相關資源：

• http://www.slideshare.net/kevinweil/nosql-at-twitter-nosql-eu-2010
• http://www.slideshare.net/ryansking/scaling-twitter-with-cassandra
• http://www.slideshare.net/kevinweil/big-data-at-twitter-chirp-2010