Computer – Page 514 – Gea-Suan Lin's BLOG

Google 對字串處理的最佳化

在 Google Research 上看到 Google 針對字串處理最佳化問題所發的論文：「Automated Locality Optimization Based on the Reuse Distance of String Operations (PDF)」。

大原則是想辦法善用 L2/L3 cache，這沒什麼特別的，比較有趣的地方是解決方案，除了自動化的方式外，另外還有工具「提醒」撰寫程式的人，另外還有一些數據以及 code name 可以看...

維基百科機房搬遷 (從佛羅里達州搬到維吉尼亞州)

在 Wikimedia 的官方網誌上看到 Wikimedia 的主機房將從 Tampa, Florida 搬遷到 Ashburn, Virginia (當然，這包括 Wikipedia)：「Wikimedia sites to move to primary data center in Ashburn, Virginia」。

當初機房在 Florida 的原因是... Jimmy Wales 住附近 XDDD

A major reason for choosing Tampa, Florida as the location of the primary data center in 2004 was its proximity to founder Jimmy Wales' home, at a time when he was much more involved in the technical operations of the site.

搬遷到 Virginia 除了有比較穩定的網路以外，還包括了天氣因素 (颶風比較少)。

2011 年 11 月時，bits.wikimedia.org (主要是放 CSS 與 JavaScript) 已經改用新機房服務，2012 年 2 月時成功將 read-only page 拆到 cache server 上，同年 4 月時 upload.wikimedia.org (多媒體資料，包括使用者上傳的部份) 也導到新機房。

這幾個改變讓無法 cache 而丟到後端 Apache 與 MySQL 的量只剩下 10%，這次打算把這 10% 的量從 Florida 搬到 Virginia。

文末也說明了目前機器數量與 PV：

The Wikimedia Foundation currently operates a total of about 885 servers, and serves about 20 billion page views a month, on a non-profit budget that relies almost entirely on donations from readers.

全世界第六大的網站，每天約六億次 PV，現在只用了 885 台 server :p

Instagram 說明用 PostgreSQL 的五個優點...

先不管 Instagram 最近的負成長以及反駁，剛剛在 Instagram Engineering 上看到對 PostgreSQL 的稱讚：「Handling Growth with Postgres: 5 Tips From Instagram」

Facebook 在 MySQL 的領域裡的實力以及貢獻度可是數一數二，但 Instagram 在被 Facebook 買下後仍然繼續使用 PostgreSQL，總是有些原因存在... 雖然真正的原因不一定是技術，但這篇試著用技術解釋的內容還是可以看一看，了解 PostgreSQL 有哪些特點...

第一個是講 partial indexes，這與 MySQL community 常講的 partial index 是不同的東西。

MySQL 的 partial index 是指只 index 某個欄位的一部分，像是 VARCHAR(255) 裡面只 index 前面的 10 chars；而 PostgreSQL 的 partial indexes 則是指符合某個條件的 row 才 index。

第二個是 functional indexes，可以針對欄位計算後再 index。MySQL 的 partial index 在 PostgreSQL 裡可以用 functional indexes + substr() 達到相同的效果，而且還有其他 function 可以用，花樣更多。

兩個都是 MySQL 做不到 (或是做不好)，但 PostgreSQL 做的不錯的。一般在 MySQL 要達到 PostgreSQL 的這兩個功能需要另外開一個欄位，在裡面儲存去正規化後的值，再對這個欄位 index。

第三個是講 defrag 的事情，這部份 MySQL 也可以用第三方的工具 Percona Toolkit 搞定。第四個講 PostgreSQL 的 Write-Ahead Log，有點像是 MySQL 的 binlog。最後一個講 Python 上的 psycopg2。

看來看去就是 index 那塊最明顯。可以直接減少去正規化的欄位...

iOS 上可以跑 OpenVPN 了...

在 pfSense 的 blog 上看到的：「OpenVPN client now available on Apple iOS!」，應用程式是這個：「OpenVPN Connect」。

剛裝好跑起來是這樣：

看起來要先生出 .ovpn 檔案才能用，晚點再來測看看...

Percona 將辦 Webinar 說明資料庫讀寫分離時的處理...

MySQL replication 通常是資料庫擴充的第一步，因為架設很簡單。但一般 MySQL replication 的讀寫必須分開 (寫入只能在 master)。

在「Webinar on Read/Write Splitting with PHP」看到 Percona 下星期會辦 Webinar，說明在 MySQL replication 架構下要如何處理讀寫分離。

看起來包括對 replication lag 時的處理 (slave 因為各種原因，導致跟不上 master)，有興趣的人可以去報名聽聽看... 雖然是講 PHP，但這個問題在其他的語言也會遇到，聽觀念也應該有幫助。

資料庫裡的浮點數：MySQL 5.1 到 MySQL 5.5 的差異...

Mozilla 最近在升級 MySQL 採「先建後拆」的步驟，發現用 pt-table-checksum 檢查時不一致：「MySQL 5.1 vs. MySQL 5.5: Floats, Doubles, and Scientific Notation」。

後來發現，在 MySQL 5.1 (5.1.65-rel14.0-log Percona Server (GPL), 14.0, Revision 475) 的查詢結果是：(Mozilla 的範例)

mysql> select float_field from db.tbl where id=218964;
+-------------+
| float_field |
+-------------+
| 9.58084e-05 |
+-------------+
1 row in set (0.04 sec)

而在 MySQL 5.5 (5.5.28a-MariaDB-log MariaDB Server) 的查詢結果是：

MariaDB [(none)]> select float_field from db.tbl where id=218964;
+--------------+
| float_field |
+--------------+
| 0.0000958084 |
+--------------+
1 row in set (0.24 sec)

最後是讓 pt-table-checksum 把 float/double 欄位忽略掉。在 comment 有人提出來是在 MySQL 5.5.3 的時候改變的，不過作者蠻意外沒什麼人提到...

ISP 架設 NAT 解決 IPv4 不夠的問題...

在 Slashdot 上看到 PlusNet 決定測試用 CGNAT (Carrier-grade NAT) 解決 IPv4 不夠的問題：「UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6」。

用超大型 NAT 並不是特別的新聞 (某些 mobile network 上就是這樣做)，但 ISP 如果用在一般網路上則很有可能會跟客戶的 NAT device (可能是公司，也可能是家庭) 發生 Private Network 相同而導致問題。

2012 年 4 月的 RFC 6598 (IANA-Reserved IPv4 Prefix for Shared Address Space) 將 100.64.0.0/10 (Shared Address Space) 這個網段保留，拿來給營運 CGNAT 的 ISP 使用：

NetRange:       100.64.0.0 - 100.127.255.255
CIDR:           100.64.0.0/10
OriginAS:
NetName:        SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED
NetHandle:      NET-100-64-0-0-1
Parent:         NET-100-0-0-0-0
NetType:        IANA Special Use

在 RFC 裡規定 100.64.0.0/10 只能拿來內部使用不得交換；如果要交換必須要有能力將不同介面的 100.64.0.0/10 當作不同網段 NAT (也就是 CGNAT 會做的事情)：

In particular, Shared Address Space can only be used in Service Provider networks or on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces.

另外文件裡還定義了使用 100.64.0.0/10 時對 DNS 的過濾。

如果 CGNAT 上不能打洞，那麼很多應用就很苦了 (得靠 UDP hole punching 打洞，這還得在沒有 randomized NAT port 的情況下才打的通)，不過非 P2P 的應用應該不會有問題...

會不會做一做之後就維持這個方式？IPv6 遙遙無期... XD

Adobe 的客服機器人...

在 Twitter 上看到 John Merriman 寫的「I talked to Adobe yesterday」：

I talked to Adobe yesterday: twitter.com/jmerriman/stat…

— John Merriman (@jmerriman) January 16, 2013

這回答看起來就像機器人 XDDD

這時候就要拿出經典的「On the Internet, nobody knows you're a dog」出來：

On the Internet, nobody knows you're a dog

白宮 We the People 提高答覆連署人數

白宮宣佈提昇 We the People 的強制答覆連署上限，將原本 25k 人提昇至 100k 人：「Why We're Raising the Signature Threshold for We the People」。

因為最近參與的人變多太多：

另外白宮給了一份 Infograph，更詳細的說明參與的狀況：

英國有個 data.gov.uk，美國有個 We the People，再加上昨天看到的 alpha.data.gov (A collection of open data from the government, private sector, and non-profits that are fueling a new economy.)，感覺台灣跟世界上的已開發國家愈差愈遠了...