雖然說我是蓋不出甚麼可以看的摩天大樓, 回頭來看部落格觀察, 就已經像海灘上的沙堡一樣脆弱. 尤其是昨晚回想部落格觀察時, 本以為是兩三年前的事, 但事實上已經是快六年前的事情了, 現在看起來從中要學習改善的地方太多了.
但這篇文章並不是要去規劃部落格觀察 2.0, 而是來講講以 Crawler 的觀點來看部落格觀察的缺失, 以及從中獲得的教訓, 因為就如第一篇 對黑帽 SEO 的回應 (SEO 鑑價系統的初探 I) 所說的, 這個系統的核心是未來部落格觀察 2.0 的基礎.
而在做新的部落格觀察 2.0 之前想要在 SEO 鑑價系統解決的問題有那些呢?
1. 主資料表與排程在同一個資料表, 會造成 Lock 的機會很高
2. 對於主資料表的依賴度太高, 許多資料沒有做 Redundancy (重複)
3. 抓資料常抓不到時的暫存與處理跟回復
4. 如何把每次抓到的資料利用最大化
5. 想辦法讓一個資料源的抓取保持一定間距
6. 把每次抓到的資料盡量存進歷史資料, 且不會造成太多多餘資料
7. 使用者輸入不應該有太多的先置處理才能進資料庫
很多人知道部落格觀察事實上也是一個晚上完成的, 當時並沒有想太多, 而是以一個自動化的角度去做出發, 並沒有考量到甚麼校能與負荷, 資料探勘 Data Mining, Big Data, 甚至 SEO, 簡而言之就是沒想到量會這麼大以及這麼多人用, 所以無論是資料, 計算, 排程等等, 都是靠一個資料表 Table 去完成的, 而這樣的社設計, 就是造成後來部落格觀察跑不動最大的原因之一.
雖然後來歷史資料轉到另一份資料表, 但對於這個主資料表的依賴還是相當的大, 很多資料的讀取都是必須要靠這個資料表才行, 因此這份資料表的 Table Lock 變成是最糟糕的問題, 雖然之後這系統做了大量的 Cache 機制, 只要是超過 10 次的 SQL Queries, 甚至 SQL Accesses, 就都有 Cache 的機制, 雖然這機制並沒有做得很好 (在 Plurk.tw 後來又改良一次), 但已經足以應付大部份的問題.
當然在之前就已經很清楚 SQL 最怕的是 Join, 所以除非是 Batch 的批次程式, 我是不敢用 Join 去拖垮資料庫, 但當資料量一大, 即使想 Join 也 Join 不動了, 只是這部份是還好, 但說要排序, 即使是資料庫受得了, 這台年壽將近的伺服器就會立刻熱當死給你看, 想算也算不了, 且在排序時並沒有做接續作業的可能性, 所以這變成是一個很大的問題, 因此部落格觀察已經好幾個月沒有重排名了.
上面的 6 點是最直接要在部落格觀察 2.0 及 SEO 鑑價系統要解決的問題, 所以做了幾項設計:
1. 使用者輸入的資料, 一開始先丟進一個 Queue
2. 將可以重覆使用的資料做統整
3. 把須要抓取的工作丟入排程
4. 每一個資料源有獨立的程式去排程資料庫抓
5. 資料回報時先放在工作完成的 Table
6. 確認資料的正確性之後才放進真正的資料表
7. 在 Rotate 時, 依每份資料的更新去做歷史
因此原本部落格觀察運作時, 只須要一個到兩個 Table(s) 就做到, 就變成須要 8~10 個資料表完成, 所以原本一兩隻程式可以解決的事, 變成 6~8 個流程才能完成, 雖然系統的複雜度變高了, 但能夠負荷的量是以百倍以上增加, 甚至是在效能更可以放大到足以承擔百億筆以上的負荷, 因為每一個流程與資料表的工作變少了, 且都能夠獨立運作, 所以遇到 Dead Lock 的機會變少了.
事實上有關 Crawler 的設計已經有專書了, 像 Building blocks of a scaleable web crawler, 還有 Crawling the web : discovery and maintenance of large-scale web data, 都是討論如何設計大量 Crawler 運作與設計的專書, 都是很值得大家的參考.
基本上在這種 Big Data 的 DataMining 中, 最重要的就是排程 Scheduling, 這部份的演算法與流程是最須要解決與開發的, 當寫完這部份, 問題就解決大半了.
沒有留言:
張貼留言