Twitter 的熱門搜尋演算法 (以及背後的機制)

昨天的 Twitter Engineering Blog 上說明了 Twitter 這陣子改善搜尋演算法背後的故事:「Improving Twitter search with real-time human computation」。

因為搜尋的量夠大,所以可以拿搜尋的 keyword 計算。

而系統會一直分析搜尋的關鍵字,當發現有詞彙在某個時間內超過設定的水位時,就發 API 到 AmazonMechanical Turk 讓真人分析 (分類),分析完成後就可以再回到自動化的流程進行後續的步驟...

Mechanical Turk 就是 crowdsourcing 類型的服務,這個服務因為法令限制,到現在還是只能讓美國的公司或是個人使用,是少數還沒玩過的服務,應該來找看看有沒有其他 crowdsourcing 服務可以玩...

Netflix 的 Open Connect,以及 Super HD 與 3D 電影...

Netflix 在半年前就開始推廣 Open Connect Content Delivery Network,類似於 Google 的 Google Global Cache (GGC)。

Netflix 的 Open Connect 計畫提供兩種方式讓 ISP 參與,第一種方式是在各地機房 peering (地點在「Open Connect Peering Locations」這份資料裡有條列出來),需要用 10Gbps 以上的線路介接,實際流量以 95% 計算後必須在 2Gbps 以上。

另一種更進接的方式是讓各 ISP 在自己的網路放 Netflix 所設計的快取伺服器,Netflix 會把該 ISP 的流量導到這組伺服器上面 (4U 的伺服器,有兩個 10Gbps SR/LR,36 顆 3TB SATA,加上 2 顆 512GB SSD),這對於 ISP 與內容業者都可以節省頻寬成本。

這佈局佈一陣子了 (大約半年),Netflix 前幾天宣佈有 Open Connect 計畫合作的 ISP 將可以看 Super HD 與 3D 電影:「Netflix Announces Major ISPs Deploying Their CDN Caches; New 3D Streaming」,這些電影將會用掉 7Mbps~12Mbps 的頻寬。

Netflix 在北美流量比 YouTube 還大,除了之前的 Multi CDN vendor 策略以外,很自然會想要建自己的 CDN,畢竟有量之後很多事情自己做會比較節省成本...

MySQL 平行執行的 Replication...

MySQL Replication – Multi-Threaded Slaves (Parallel Event Execution)」這篇在講 MySQL 5.6 的 multi-threaded replication。

在文章裡提到,在 5.6.3 之前的版本,MySQL replication 都是 single-threaded,所以當 master 可以充分發揮多 CPU 能力時,slave 仍然要一個更新跑完才會跑下一個更新。

舉例來說,假設 master server 上有兩個 thread 在跑:

  • thread 1 正在執行 UPDATE table1 SET foo = 0 WHERE ...; (SQL 1,假定是 CPU bound,需要跑 100 秒)
  • thread 2 正在執行 UPDATE table2 SET bar = 1 WHERE ...; (SQL 2,也假定是 CPU bound,也需要跑 100 秒)

假設 thread 1 先執行完,這時候 slave 就會在跑完的時候收到 SQL 1,然後把資料同步進去。等到 100 秒過去後,再跑 SQL 2,再花 100 秒。這導致了最少 100 秒的 replication lag (master 與 slave 不同步的時間)。

在 master server 執行時會是這樣:

兩個 SQL query 可以同時跑。

到了 slave 時,在 MySQL 5.6.3 之前的 replication 會變成這樣:

可以看到還是得先執行 SQL 1 再執行 SQL 2,所以最長會有 200 秒的 replication lag。

而 5.6.3 之後支援 multi-threaded replication,可以用 slave_parallel_workers 指定平行執行 SQL query 的數量,這讓 master server 與 slave server 之間的 replication lag 降低不少:

在收到同步的 SQL 指令後就可以同時跑,這讓 replication lag 降到 100 秒。

不過還是要提,如果希望把資料同步問題降到最低,那麼 Galera Cluster 可以解的更徹底,不論是寫入的那台 master server,或是其他的 master server (在 Galera Cluster 架構裡都是為 master),一律都是同步執行:

不會有 master server 與 slave server 不同步的問題,可以減少很多 application 層的麻煩...

建一個 Root CA 的開銷...

cryptography mailing list 上有人問了這個問題,結果 Entrust 的 CTO,Jon Callas 跑出來回答:「How much does it cost to start a root CA ?」。

答案是,第一次的費用大約 25 萬美金,其中人事費用佔很大一塊。另外每年還有固定的維護費用 (設備與稽核):所有的行為都必須被稽核,而且所有的的控管都必須是雙重認證,以確保一個人無法破壞 CA 的安全性。

還蠻有趣的回覆...

這次 TURKTRUST 誤發 *.google.com SSL 憑證...

這次 TURKTRUST 誤發 *.google.com 憑證被 Google 當初佈下的網子抓到:「Enhancing digital certificate security」。

首先是每次 CA 出問題後都會對目前的 PKI 提出質疑的文章 (像是「TURKTRUST Incident Raises Renewed Questions About CA System」),在沒有有效的方法可以取代目前的 PKI 前,都是吵一吵之後就沒有結論,所以先不管這個題目。

想要提出來的是 Google 這次抓到的機制:「Public Key Pinning Extension for HTTP」,目前狀態仍是 draft。不過 Google 在 Google Chrome 13 就已經實作一部分了,並且把一堆 domain 寫死進去:「View of /trunk/src/net/base/transport_security_state_static.json」,可以看到 Google 的 domain 只允許這些 CA 簽:

      "name": "google",
      "static_spki_hashes": [
        "VeriSignClass3",
        "VeriSignClass3_G3",
        "Google1024",
        "Google2048",
        "EquifaxSecureCA",
        "GeoTrustGlobal"
      ],

任何想要在太歲爺上動土的都會被抓包 XD

另外 Google Chrome 還是沒有 Certificate 相關的 API,目前只有 API Proposal 掛著:「webRequest SSL Hooks」,相較於 Firefox 有不少 extension 可以用,這方面 Google Chrome 就差了不少...

CloudFlare 的速度...

CloudFlare 是一種 CDN 服務,相較於其他 CDN 會被歸類到 AkamaiDynamic Site AcceleratorLimelight NetworksDynamic Site Platform,或是 EdgeCastApplication Delivery Network

這類型的 CDN 加速服務,如果用在完全沒有考慮最佳化的網站上,效果應該會很明顯。但如果拿到 WordPress 或是其他 open source 軟體上,反而會因為軟體已經做了不少處理,上了 CloudFlare 反而因為多了一層而變慢。

不過會變慢多少呢?有人跳下去測試寫報告了:「Cloudflare Showdown」,如果懶得看中間的數據,可以看最後的結論「Conclusion」。

如果用在已經最佳化過的網站上,用 CloudFlare 會慢不少,如果是 WordPress 及其他 open source 軟體,最好的情況是快一點點,但最差的情況會慢個幾倍... 作者下的結論是「不要用」。

跟預期差不多,動態資料的加速基本上是個商業包裝而已,真正需要加速還是得自己把可以 cache 的部份切割出來。

法國 ISP「Free」主動更新上機盒韌體,主動擋掉廣告...

出自「French ISP blocks online ads by default – just a beta feature glitch?」與「France’s second-largest ISP deploys ad blocking via firmware update」。

Freebox

法國第二大的 ISP「Free」在最近一次的韌體更新裡,增加了「過濾廣告 (adblock)」的功能,並標為 beta:「Mise à jour Freebox Server 1.1.9」,不過,有很多人發現這個 beta 功能預設是開啟的... 然後就看到所有以網路廣告為生的科技新聞網站一面負評... XDDD

前幾天 Free 才爆出擋 YouTube 的新聞「YouTube sucks on French ISP Free, and French regulators want to know why」,ARCEP (法國的電信監管組織) 喊說要查網路中立性問題,結果馬上就來個下馬威 xDDD

話說回來,中華電信色情守門員的名單改一改,應該也可以推出類似的服務?XDDD

請僅快確認這次 RoR 所提供的安全性公告

下午遇到布丁大長輩的時候他還很開心說「我用 2.3 沒問題的啊~」XDDD

今天 Ruby on Rails 官方對 Active Record 發出安全性通報以及更新 (類別為 SQL Injection):「[ANN] Rails 3.2.10, 3.1.9, and 3.0.18 have been released!」。

請不要只看標題,這次的安全性問題包括所有版本,而非 3.x 而已。這次的安全性問題太過歡樂,所以除了在支援的版本以外 (3.1 與 3.2),這次的安全性問題還是提供了 2.3 與 3.0 的 patch 讓人下載,並提供當無法使用 patch 時的 workaround:「SQL Injection Vulnerability in Ruby on Rails (CVE-2012-5664)」。