挑戰 YouTube 的聲音辨識系統

YouTube 能夠以聲音自動判斷影片內容是否在資料庫內,如果在資料庫內他就會將聲音拔除 (不是移除影片)。這個辨識系統是個黑盒子,於是就有人挑戰 YouTube 的聲音辨識系統,找出底線在哪裡:「Fun with YouTube's Audio Content ID System」。

方法很簡單 (trial-and-error,試誤法),但結論很機車,像是居然抱怨 YouTube 沒有機制停權 XDDD:「我用了同一個帳號傳了 82 個影片,收到 35 封 Content ID email,但帳號沒事...」

Cacheboy CDN

因為今年 OSDC.TW 講的 CDN 主題是偏向怎麼選與怎麼用,就沒有提到 Cacheboy CDN

Cacheboy 本來是一套改自 Squid 2 的 Web proxy cache software,後來軟體改名叫 Lusca,而 Cacheboy 原本的 domain 就拿來開 CDN 服務。

Cacheboy CDN 這個計畫是希望募集機器與頻寬,解決 Open Source 軟體在發行時爆量而造成當機不順的問題,也順便找出 Lusca 有什麼地方還不夠好。像是「Lusca and Cacheboy improvements in the pipeline..」這篇就是在 tune CDN 的時候找到問題。

WhatIsBeingMirrored 這頁可以看到目前使用 Cacheboy CDN 的服務,目前比較大 (也比較有名) 的是 http://mozilla.cdn.cacheboy.net/ 這個,據說 Mozilla Firefox 3.0.9 更新就是靠他,然後流量就大爆發了...

這個 CDN 計畫還蠻有趣的...

MySQL 5.4

MySQL Conference & Expo 2009 上除了 OracleSun 以外的另外一個大新聞:MySQL 5.4

這個版本的狀態是 beta,把 Google MySQL Tools 裡相當多 patch 併入 MySQL。(尤其是對 InnoDB 的部份)

MySQL Planet 上面已經有不少 Sun 自己的測試報告。不過 MySQL Planet 上資料有點雜,要花點時間消化。想要看個大概的人可以從 A Quick Look at MySQL 5.4 開始看,這邊用圖表解釋效能的改善。

四月 TWNIC 連線頻寬登錄查詢系統

上面的資料還蠻有趣的,可惜沒有 diff log 之類的紀錄?查起來頗麻煩...

中華電信 HiNet對美國的頻寬從 57G 一口氣拉到 77G,對日本與香港也都有繼續增加...

台固對日本 (7.1G 降到 2G) 及香港 (5G 降到 4G) 縮減了不少,增加的部份包括美國頻寬 (2.4G 升到 4G) 以及中國頻寬 (1.1G 升到 3.4G),整體的量看起來下降不少。

速博SEEDNet 整合,以遠傳的品牌重新出發,在 TWNIC 的圖上面則是以 ncic (速博) 的名字出現,稍微算了一下,頻寬的部份似乎沒有太大的變動...

加上最近 HiNet-TFN 的事情,hmmm...

Oracle 買 Sun

一回到家就看到 breaking news... Oracle 買下 Sun MicrosystemsOracle Buys Sun

雙方的網站都已經公告了,Sun 的公告是:

Sun and Oracle today announced a definitive agreement for Oracle to acquire Sun for $9.50 per share in cash. The Sun Board of Directors has unanimously approved the transaction. It is anticipated to close this summer.

而 Oracle 的網站連不太上 XDDD

MySQL Conference & Expo 2009 剛好是 4/20 - 4/23,看起來這三天會很熱鬧...

MySQL replication lag 的解法

MySQL replication 不是同步進行,也就是說,在 master 寫入或刪除了某筆資料後,在 slave 上可能會讀到舊的資訊。解法主要是依照程度而決定要怎麼做。

如果 replication lag 不太影響整體的觀感,那麼不管這個問題是一個還蠻直接的解法。

如果在一個 application 裡會需要一致性,那麼都到 master 讀寫也是一個還可以的解法。而一般只讀取的 application 只到 slave 取得資料。

如果要求很嚴謹,可以考慮用 SemiSyncReplication,強迫 master 寫入時等到 slave 回應 okay 後才會完成。這種主要是用在寫入不多,但一致性很重要的場合。

MySQL multi-thread replication

MySQL 的 replication 一直都是 single thread。即使 slave 有能力同時跑多個 SQL query 也必須是 single thread,這是為了資料的正確性而考量,但產生了一些缺點:

  • 負荷量大的時候容易產生 replication lag。
  • replication thread 只能用一顆 CPU resource。

現在在 MySQL 5.1 上有放出 patch 讓大家測試 multi-thread replication 了:「Feature Preview: Multi-threaded Slave」,雖然有不少限制,但是總是個開始。

依照文件,主要的限制包括:

  • 只支援 transaction storage engine (像是 InnoDB)。
  • 只有 row-based events 才有辦法平行化。
  • isolation level 必須是 SERIALIZABLE。

另外,目前主要的限制還包括:(未來有機會移除)

  • 目前 table 的 primary key 必須是 integer。
  • 目前只有 INSERT 與 DELETE 能被平行處理。
  • 當 slave 在 commit 時 crash 不能保證全部都會恢復。(喂喂 XD)

有興趣的人可以測測效能,看起來還要花一段時間開發。