維基基金會的 2014 年八月月報

維基基金會釋出八月月報 (好像晚了三個月?):「Wikimedia Foundation Report, August 2014」,在「Wikimedia Highlights, August 2014」有比較精簡的版本。

維基基金會在報告裡有提供一些 PV 相關的數據,包括 comScore 的數字與自己 server log 所統計出來的數據。另外也包含了財務狀況。

其中技術相關的是取自「Wikimedia Engineering/Report/2014/August」這頁。另外因為這是八月的資料,我順便偷看了九月與十月的「Wikimedia Engineering/Report/2014/September」與「Wikimedia Engineering/Report/2014/October」。

可以看到在測試 HHVM 的計畫,而且目前看起來還不錯:「[Wikitech-l] [Engineering] Migrating test.wikipedia.org to HHVM」,拿了 test.wikipedia.org 測試,其中 speed test 的部份有大幅改善:

1) Speed test: measure the time taken to request the page 1000 times over just 10 concurrent connections:

                        HHVM    Zend    diff
Mean time (ms):         233     441     -47%
99th percentile (ms):   370     869     -57%
Request/s:              43      22.6    +90%

而負載測試的成果更好:

2) Load test: measure how much thoughput we obtain when hogging the appserver with 50 concurrent requests for a grand total of 10000 requests. What I wanted to test in this case was the performance degradation and the systems resource consumption

                        HHVM    Zend    diff
Mean time (ms):         355     906     -61%
99th percentile (ms):   791     1453    -45%
Request/s:              141     55.1    +156%
Network (Mbytes/s)      17      7       +142%
RAM used (GBs):         5(1)    11(4)
CPU usage (%):          90(75)  100(90)

維基百科之所以沒有遇到太多問題,主要是因為所使用的軟體是 open source 而且夠大的關係,直接成為 HHVM 測試的一環:「Compatibility Update」。

不過目前看起來應該還是跑 PHP,沒有看到整個都轉換過去的計畫。

另外一方面,搜尋引擎的更換就沒有這麼順利,雖然換到 Elasticsearch 後改善不少,不過可以看到八月的報告這樣寫:

tarted deploying Cirrus as the primary search back-end to more of the remaining wikis and we found what looks like our biggest open performance bottleneck. Next month's goal is to fix it and deploy to more wikis (probably not all). We're also working on getting more hardware.

而九月時就講到沒有銀彈,要加硬體去拼:

In September we worked to mitigate the performance bottleneck that we found in August. We found there to be no silver bullet but used the information we learned to pick and order appropriate hardware to handle the remaining wikis. We also implemented out significantly improved wikitext Regular Expression search. In October we've begun rolling out the wikitext Regular Expression search and received some of the hardware we need to finish cutting over the remaining wikis. We believe we'll get it all installed in October and cut the remaining wikis over in November.

十月的時候弄到機器了:

In October we prepared for November in which we deployed Cirrus to all the remaining wikis by installing new servers installing new versions of Elasticsearch and our plugins. We also fixed up regex search which had caused a search outage.

這些報告的連結裡面其實有些不會在對外新聞稿上面的評語... XD

修正 Mac OS X Yosemite (10.10) 的設定以確保隱私

Hacker New Daily 上看到的:「Fix Mac OS X Yosemite」。原因是 Spotlight 的部份 AppleBing 合作:

If you've upgraded to Mac OS X Yosemite (10.10) and you're using the default settings, each time you start typing in Spotlight (to open an application or search for a file on your computer), your local search terms and location are sent to Apple and third parties (including Microsoft).

有兩個地方要關閉。一個是系統設定,一個是 Safari 設定,細節在原文裡面有,這邊就不抄過來了。

Elasticsearch 1.2.0

由於 Elasticsearch 的想法與實做比起 Solr 吸引人,可以看到愈來愈多團體換過去...

而前幾天 Elasticsearch 的官方放出 1.2.0 與 1.1.2 的消息:「elasticsearch 1.2.0 and 1.1.2 released」。

1.2.0 最大的改變是強制使用 Java 7 了,也就是不能在 Ubuntu 12.04 下安裝 default-jre 了,變成要裝 openjdk-7-jre。(要注意,官方建議的是 Oracle 官方的 JDK,而非 OpenJDK)

如果是 Ubuntu 14.04 就沒這個問題。(因為 default-jre 會裝 Java 7)

另外一個大改變是,之前產生安全問題的 dynamic scripting 預設關掉了,也就是 CVE-2014-3120

目前我的進度只到看完 mapping,但還沒實際開始塞資料進去玩...

Google Searchbot 將開始有能力解讀 JavaScript...

GoogleOfficial Google Webmaster Central Blog 上正式向全世界公告他們的 Searchbot 將會解讀 JavaScript:「Understanding web pages better」。

也就是說,再這次改版後,就算你的頁面全部用 JavaScript 產生,Google 也有能力解讀出來。這顛覆了以前學到的觀念...

其他家 (DuckDuckGo?) 會支援嗎?不知道會不會跳下去做...

Wikimedia 將搜尋系統換到 Elasticsearch...

Wikimedia 打算把搜尋系統換到 Elasticsearch 上:「Wikimedia moving to Elasticsearch」。

之前的搜尋系統是他們自己刻的 lucene-search-2,現在則要換成 Elasticsearch。

可以注意到最近 Elasticsearch 的聲音愈來愈大,而 Solr 沒什麼長大的感覺...

對於學術研究用的 Big Data...

面試的時候曾經有面試者說手上沒有 big data 可以研究,所以對 big data 的理解僅限於理論,不過我對這種講法就...

網路上有很多資料是很有用的:

能玩的東西明明就很多... 另外還可以掃各種公開資料。

電子發票的數據...

iThome 上看到「財政部財政資訊中心將釋出40億張電子發票的消費分析」,裡面提到:

為期3年的電子發票試辦期,終於要在2013年底告一段落,並於2014年正式上路。光是2012年,臺灣就開出了24.6億張的電子發票,財政部財政資訊中心(以下簡稱資訊中心)電子發票科科長劉醇錕更表示,以成長速度推估,2013年將開出40億張電子發票,占發票總開立數的一半。劉醇錕表示,這些電子發票將在未來以政府公開資料方式釋出,供企業、研究機構等使用。

資料的處理:

但在公開電子發票資訊之前,劉醇錕表示,資訊中心會進行「去識別化」,最終公開的資料,會以一個街區、或一個小行政區為單位,來模糊原始資料夾帶的資訊,而非以哪家店、哪個使用者為單位直接釋出原始資料(Raw Data),藉此來避免讓有心人士交叉分析出企業、消費者的個人資訊。

我馬上想到 AOL 當初 2006 年也是自信滿滿的匿名化後放出:

這讓人超期待的...

DuckDuckGo 用一個禮拜後...

還是換回 Google Search 了...

因為最近 NSA 事件愈來愈精彩的關係,有不少人號召跳去 DuckDuckGo 就跑去跟風了,主要是看看 search quality 夠不夠用... 用了一個禮拜後發現有兩個主要的問題:

  • 資料不夠完整,有些站台沒有被收到 DuckDuckGo 裡面。不過比起 DuckDuckGo 剛出來那陣子,感覺已經好很多了... (當初是用兩個小時就放棄了)
  • 反應速度太慢,等五秒是常態... 以前沒那麼慢,應該是跟這陣子爆炸性成長有關。

所以還是換回 Google 了...

可以看出 DuckDuckGo 成長的速度愈來愈快了:(出自「DuckDuckGo Direct queries per day (28d avg)」)

Google 的 site: 限制更少了...

以往在使用 Googlesite: 只知道能放 suffix,譬如 site:edu.tw

而剛剛在「Advanced Uses for Google's Site: Operator」則是看到了 site:blog.* 這種用法,或是 site:blog.*.com 這種用法,不過原作者目前測試發現有漏,我自己測試是沒什麼問題 :p

另外這個技巧在圖片搜尋也可以使用 :p