晚上參加了伯朗咖啡館的聚會。
馬上有個心得，台灣網路市場肯定要變盤了，速度會比任何想像的要快。
這麼多的人以及沒有看到的人將會用facebook開放平台將高姿態的無名與雅虎踢出去。
facebook大軍衝啊~
不明究理
Web 2.0、Ruby On Rails、網路技術團隊創業、Joobii、inside.com.tw
Google還在小時候的時候就爬這個速度了：
In total it took roughly 9 days to download the 26 million pages (including errors). However, once the system was running smoothly, it ran much faster, downloading the last 11 million pages in just 63 hours, averaging just over 4 million pages per day or 48.5 pages per second.
要做搜尋引擎的話…一般會問:
我們缺搜尋引擎嗎?
基本上是不缺的，以搜尋資訊的角度來說不缺
但以搜尋人性的角度來說還有很多可做的，人性的需求目前還沒能被今天的搜尋引擎解決。
以人的行為模式與心理狀態來思考搜尋這件事情，站在巨人的肩膀上，思考接下來該做的是甚麼樣的搜尋服務，要提供給使用者甚麼樣的體驗。
觀察台灣市場，還是缺搜尋引擎的。
1. crawl 網頁
2. 網頁組成成分與web server相關協定
3. 全文檢索與排名原理
4. 中文字詞處理
5. regular expression
6. DB, server, 網路基於處理大量資料的性能調整,並能有效處理分散運算
7. 對特定搜尋領域需求的理解與規劃
8. 實做特定搜尋領域所需的介面與功能
9. 觀察使用者搜尋行為的介面設計與改善計畫
10. 內容產生策略與運作
11. 搜尋廣告處理與運作
12. ….
存放在資料庫中，所以當資料越多時，要刪除＂同樣的網頁＂就會很花時間。隨著資料越多，刪除重複的等待時間就越長，甚至可能timeout.
思考：
1. 重複不刪，日後批次刪除。
2. 增加DB欄位，透過重複標記的拆分比對，降低mysql的負擔。例如以32位做特徵碼來搜尋，不如切成4, 6, 11, 11四個欄位，逐欄比對，覺得可以增加效率 => 待實驗。
待處理：
1. 有效的爬行策略
2. 有效的網頁更新策略。
Google最多顯示前一千筆資料
很合理。
1. sphinx.yml得照YML規矩寫…
2. zh_cn.utf-8的charset_typ應搭配charset_dicpath寫在config裡面. 否則會出現錯誤:unknown charset type ‘zh_cn.utf-8′
幾個觀察與想法：
1. 一台雙核的server，開兩個thread爬網頁，每個網址爬六十秒，快的網站可以抓回一千來頁。慢的網站可以抓回200頁，平均頻寬需求約2M/sec.
2. 一天可以爬幾個網站？如果每個網址爬一分鐘，一台server一天只能抓1440個網站。限制的是爬行時間，如果要抓回最多的網頁，則應在crawler的演算法，機器的規格上面做加強，以提升抓取速度，例如 1,000頁變成10,000頁。那麼，倘若有一百萬個對象，想在七天內爬完，則需1,000,000 / 7/ 1440 ~= 100台。需要100台機器以及約莫 100*2MB = 200MB/sec的頻寬
針對100萬個對象crawling所需設備之成本粗估:
- 伺服器 +網路設備 : 500萬
- 頻寬+機房(10 rack) + 200MB/sec = 60萬 /month => 一年 = 720萬
- 其他架構設備（高檔switch, storage, 備份…)：這部分先不估計，但針對這樣的架構，可能需要考慮。
3. 假設要做一個台灣內容的搜尋引擎。雖然台灣有許多知名網頁不是.tw結尾，例如tw.bid.yahoo.com, www.hinet.net, wretch.cc….等。 先假設我們針對的是 .tw的網頁，估計一下有多少網址應列入對像。
另外，網址的定義是不同的uri. 例如 shopping.pchome.com.tw與 www.pchome.com.tw就是不同的了。
根據twnic的資料，台灣的 .tw網域申請情況如左圖，約莫有50萬個.tw網址被註冊申請了。
又，twnic的統計也顯示了，www server大概有十一萬台。
以上這兩個資訊給了個感覺，我們要爬的對象基本上不會低於100萬個，只會超過100萬個。
4. 在Google上打 site:.tw，他已經index的網頁有八億四千萬頁。
=> 假設對象是100萬個，平均每個對像抓了842頁。
=> 假設平均每頁存了1k的資料，需要842GB的空間儲存。
思考：
怎麼在最少的時間或者最少的crawler內抓到最多的網頁？（數量跟深度）
=> 正：提升資料的recency與abundancy; 減少crawler的資本支出。
=> 負：頻寬需求增加 => 因為變動成本增加，運行成本增加。
極端的scenario是：僅使用一台5萬元的server，加上1GB的網路頻寬，一天內爬完全台灣的網頁。
因此，兩種考量方式來設計crawler爬行策略:
1. 以爬的時間來考量：例- 每個對象只爬一分鐘，特定對象例外處理。 => 以crawler為主的限制條件。
2. 以單位時間內抓取的網頁kb數來考量：例- 每分鐘要從網路上抓回50GB的資料量，藉以安排排程（優先順序，分配抓取資料量，…）。 => 可以控制頻寬購買需求。
估計上述兩種方法，必然會在某個條件之後互相影響，最後影響成本最大的應該都還是頻寬，畢竟這是個變動成本。
Todo:
1. crawler最佳化
2. search logic